ROCmFPX for llama.cpp

ROCmFPX adds experimental AMD-focused 2-, 3-, 4-, 6-, and 8-bit GGUF model-weight formats to llama.cpp, with CPU reference paths and accelerated HIP/ROCm and Vulkan kernels.

Status: ROCmFPX is an experimental feature family on the canonical main branch. APIs, tuning choices, and performance can change. Results depend on hardware, drivers, model, prompt, and quantization recipe; use BF16/F16 sources for quality comparisons.

This tree is based directly on official ggml-org/llama.cpp commit 15586e2d7165570fb3aa7c26e0d442e289ef69de (b10297 plus one commit, 2026-08-06). It therefore includes the upstream decode overhaul through b10218. See UPSTREAM.md for the synchronization policy and verification commands.

The first reproducible DualView/Ornith release remains tagged dualview-ornith-35b-v1; this branch forward-ports that runtime onto the maintained ROCmFPX/llama.cpp line.

ROCmFP2 is now available on the canonical main branch as Q2_0_ROCMFPX. It uses a 2.50-bpw block layout with an S40 {-4, -1, +1, +4} codebook and dual UE4M3 scales. The smaller blocks reduce model storage and memory traffic compared with ROCmFP4. The 2.50-bpw figure describes native ROCmFP2 weight blocks; complete GGUF BPW can be higher because files also contain metadata and tensors stored in other types. The latest Vulkan dense and routed/MoE Q8_1 decode kernels are included on main.

Download the current main source (ZIP) or use the clone command in Quick Start. Older tags and previously built binaries do not receive these updates automatically.

Fresh matched Qwen3.6-35B-A3B tests used the same prompt and 256-token, non-speculative decode workload from an internal NVMe:

ROCmFP2 also passed exhaustive packed-codebook validation and dense/routed Vulkan kernel gates. These measurements demonstrate the benefit on the tested system, not a universal speed or quality guarantee. ROCmFP2 is more lossy than ROCmFP4, so compare important workloads against the BF16/F16 source.

• AMD-first weight formats: ROCmFP2, ROCmFP3, ROCmFP4, ROCmFP6, and ROCmFP8 are real GGUF model-weight quants, not just K/V-cache compression.
• Native accelerated paths: HIP/ROCm and Vulkan kernels are backed by CPU reference implementations for correctness testing.
• Speed and size choices: ROCmFP2 is the smallest optimized family, while ROCmFP4 is the speed-first 4-bit family; existing Qwen comparisons put ROCmFP4 files about 12% below the matched Q4_K_M size.
• Agent-aware presets: coherent/agent recipes protect tensors that matter for code, JSON, tool calling, and structured output.
• Built-in MTP acceleration: models with an MTP/NextN head—including M-RoPE Qwen models—can use target-verified self-speculative decoding without loading a separate draft model.
• Broad validation: the promoted source was exercised through local CPU/Vulkan/ROCm tests and cross-platform CI covering Windows, macOS/Metal, WebUI provisioning, and Apple packaging.

Start with Quick Start, choose a format in Which Format Should I Pick?, or jump directly to MTP Speculative Decoding.

These are local command-line decode results from the promoted main source on Strix Halo (gfx1151). Throughput is the final Generation: rate from llama-cli; runs used full GPU offload, FlashAttention, -c 4096, greedy sampling (--temp 0), -b 512 -ub 512, the same prompt within each row, and one model at a time.

Qwable is a matched single 64-token pair. Qwen no-MTP is one 256-token run; the MTP values are the median and peak of three matched 256-token runs.

The promoted source and the pre-promotion experimental build were effectively tied on Qwen3.6: median differences were -0.7% on Vulkan and -0.3% on ROCm. On a longer 512-token Vulkan run, the promoted source reached 110.7 t/s versus 107.2 t/s for the experimental build. Qwable's 256-token branch comparison was also tied: promoted/experimental measured 32.9/33.0 t/s on Vulkan and 32.3/32.3 t/s on ROCm.

MTP gains are content-dependent: predictable code, JSON, and lists usually accept more draft tokens than creative prose. Treat the profiles above as tested starting points, not universal defaults.

Four commands from clone to a running model. For other AMD GPUs, swap the build script using the Clone And Build table.

# 1. Get the code (canonical main branch)
git clone https://github.com/ciru-ai/ROCmFPX.git
cd ROCmFPX && git checkout main

# 2. Build for Strix Halo
env JOBS=16 scripts/build-strix-rocmfp4-mtp.sh          # -> build-strix-rocmfp4/

# 3. Quantize a BF16/F16 GGUF to ROCmFP4 (4.25 bpw, speed-first layout)
build-strix-rocmfp4/bin/llama-quantize model-BF16.gguf model-ROCMFP4_FAST.gguf Q4_0_ROCMFP4_FAST

# 4. Run it with the fastest backend measured on this Strix Halo system
build-strix-rocmfp4/bin/llama-cli \
  -m model-ROCMFP4_FAST.gguf -dev Vulkan0 -ngl 999 -fa on --jinja

That is the whole loop: build → quantize → run. The sections below explain each format, how to convert an existing NVFP4 model, and how to squeeze more decode speed with speculative decoding.

For the smallest optimized format, replace step 3 with:

build-strix-rocmfp4/bin/llama-quantize \
  model-BF16.gguf model-ROCMFP2.gguf Q2_0_ROCMFPX

The same llama-cli command can then load model-ROCMFP2.gguf.

For a model that contains an MTP/NextN head, add a tested starting profile:

build-strix-rocmfp4/bin/llama-cli \
  -m model-with-MTP.gguf -dev Vulkan0 -ngl 999 -fa on --jinja \
  --temp 0 --spec-type draft-mtp \
  --spec-draft-n-max 6 --spec-draft-p-min 0.6

For Qwen3.6-35B-A3B on the tested Strix Halo system, n4 / p0.55 was faster:

--spec-draft-n-max 4 --spec-draft-p-min 0.55

To use HIP/ROCm instead of Vulkan:

export HSA_OVERRIDE_GFX_VERSION=11.5.1
export GGML_HIP_ENABLE_UNIFIED_MEMORY=1
build-strix-rocmfp4/bin/llama-cli \
  -m model-ROCMFP4_FAST.gguf -dev ROCm0 -ngl 999 -fa on --jinja

Rule of thumb: choose Q2_0_ROCMFPX when capacity and memory traffic matter most, or start with Q4_0_ROCMFP4_FAST for a less aggressive speed-oriented quant. Use a *_COHERENT / *_AGENT preset if the model does tool-calling, JSON, or coding. Always compare against your BF16/F16 source for real quality checks.

DualView is a new execution architecture for local LLM inference. A model keeps compact signed Q7 codes as its source of truth, then exposes those exact integer values to the GPU in two different physical forms:

• Decode: packed Q7_0_ROCMFPX, reducing the bytes read for every generated token.
• Prefill: an exact signed-Q8 compute view, opening the native INT8 dot-product and WMMA path for wide prompt processing.

The Q7-to-Q8 view change is lossless with respect to the stored Q7 code: it sign-extends the integer and reuses the same scale. It does not claim that Q7 itself is lossless relative to BF16.

The first public model is Ornith1.0-35B-CIRU-DUALVIEW-FPX7+Q8-MTP. Its retained quality-max target measured 1,236.156 tok/s at PP4096 on a Radeon 8060S / gfx1151, ahead of both the original Q7S8 recipe and the official Q8_0 control under the matched full-model protocol.

• Learn DualView visually
• Architecture, build, and run guide
• Complete Ornith 35B research record

Install a current ROCm Core SDK first, then:

sudo apt update
sudo apt install -y build-essential cmake git ninja-build pkg-config \
  libcurl4-openssl-dev

git clone --branch dualview --single-branch \
  https://github.com/ciru-ai/ROCmFPX.git
cd ROCmFPX
JOBS="$(nproc)" ./scripts/build-strix-dualview.sh

Run the integrated Ornith target with its official Q8 MTP head:

export GGML_ROCM_GFX1151_Q7_Q8_VIEW=no-output
# Recommended for large UMA loads:
export GGML_HIP_ENABLE_UNIFIED_MEMORY=1
# Only for an older ROCm stack that does not identify the APU as gfx1151:
# export HSA_OVERRIDE_GFX_VERSION=11.5.1

./build-strix-dualview/bin/llama-server \
  -m /path/to/Ornith1.0-35b-CIRU-DUALVIEW-FPX7+Q8-MTP.gguf \
  -a Ornith1.0-35b-CIRU-DUALVIEW-FPX7+Q8-MTP \
  --host 127.0.0.1 --port 8080 --jinja \
  --reasoning on --reasoning-format deepseek --reasoning-budget -1 \
  -dev ROCm0 -sm none -ngl 999 -fa on \
  -n 16384 -c 131072 -b 2048 -ub 512 -t 16 -tb 16 \
  -ctk f16 -ctv f16 --parallel 1 --metrics --mmap --no-repack \
  --no-cache-prompt --no-context-shift -fit off \
  --spec-type draft-mtp --spec-draft-p-min 0.50 \
  --spec-draft-n-max 7 -ctkd f16 -ctvd f16

For short prompts, depth 6 was the stronger general mean. For 16K–64K prompts, depth 7 was the retained decode profile. For prompt-heavy requests with short answers, disable MTP (--spec-type none) so speculative-prefill overhead does not dominate wall time.

ROCmFPX is a family of GGUF model-weight quants:

Agent-specific versions are also available:

ROCmFPX is not a K/V-cache-only compression trick. It is a set of actual GGUF model-weight tensor formats with CPU reference paths plus ROCm/HIP and Vulkan kernel coverage.

This work builds on llama.cpp; upstream authors and contributors retain credit under the MIT license. See AUTHORS, LICENSE, and THIRD_PARTY_NOTICES.md.

Ciru maintains this repository and its ROCmFPX integration. Earlier ROCmFP4 and ROCmFPX work remains credited through the repository history and project notices.

Major contributions in this tree include:

• ciru-ai: ROCmFP2 core format/runtime and frozen codebook; ROCmFP3 Vulkan matvec/dequant speed path.
• Tom Turney / PlunderStruck / Aydan S.: TurboQuant turbo3/turbo4 K/V-cache quantization paths for ROCm/HIP and Vulkan.

Most regular GGUF quants target broad size/quality tradeoffs. ROCmFPX is AMD-oriented and keeps the ROCmFP4 discipline:

• 32-weight blocks for CPU, HIP, and Vulkan kernel compatibility
• finite unsigned UE4M3 scale bytes
• explicit integer-code-times-decoded-scale dequant math
• reconstruction-MSE scale selection where low-bit coherency needs it
• tensor-aware routing for low-bit coherency instead of applying one blunt type everywhere
• optional agent presets for JSON, tool calling, coding, and chat coherency

The agent presets do not invent a separate dequant kernel. They use the same ROCmFPX math but protect the tensors that tend to break structured output: token/output embeddings, attention Q/K/V/O, selected FFN-down, and selected FFN-gate tensors.

These are additional pre-promotion comparisons from a Strix Halo / gfx1151 system. Treat them as historical local data, not a universal benchmark. All rows within each table used the same model pair, backend, batch shape, K/V cache, FlashAttention setting, and one test at a time.

Model pair:

• Baseline: Qwen3.6-27B-Q4_K_M.gguf, 16.55 GB
• ROCmFPX: Qwen3.6-27B-VANILLA-NO-MTP-BF16-to-ROCmFP4-STRIX_LEAN.gguf, 14.59 GB
• Size delta: ROCmFP4 is 11.82% smaller
• Test: llama-bench, pp512 + tg128, MTP/speculative decoding disabled

On this 27B vanilla run, ROCmFP4 was slightly behind Q4_K_M for ROCm prompt fill, but faster for decode on both ROCm and Vulkan. Vulkan ROCmFP4 also led prompt fill.

Model pair:

• Baseline: Qwen3.6-35B-A3B-MTP-Q4_K_M.gguf, 21.71 GB
• ROCmFPX: Qwen3.6-35B-A3B-MTP-BF16-to-ROCmFP4-STRIX_LEAN-ROCmFPXCLONE.gguf, 19.05 GB
• Size delta: ROCmFP4 is 12.28% smaller
• Test: llama-bench, pp512 + tg128; this table measures the weight quants, not speculative MTP acceleration

The same 35B A3B pair was also run through a 20-prompt Hermes-style agent smoke:

On this 35B A3B comparison, ROCmFP4 was smaller and faster on decode/generation across ROCm and Vulkan. ROCm prompt fill was still slightly behind Q4_K_M in llama-bench, while Vulkan prompt fill and Hermes-style prompts favored ROCmFP4.

git clone https://github.com/ciru-ai/ROCmFPX.git
cd ROCmFPX

Most users should stay on main. The preserved experimental-rocmfpx-branch exists for history and rollback comparisons.

Pick the build script for your machine:

For Strix Halo, the common runtime environment is:

export HSA_OVERRIDE_GFX_VERSION=11.5.1
export GGML_HIP_ENABLE_UNIFIED_MEMORY=1

Key binaries after build:

build-strix-rocmfp4/bin/llama-quantize
build-strix-rocmfp4/bin/llama-cli
build-strix-rocmfp4/bin/llama-server
build-strix-rocmfp4/bin/llama-bench
build-strix-rocmfp4/bin/test-backend-ops

For RDNA2/RDNA3/RDNA4 builds, use the same binary names under that build folder, for example build-rdna3/bin/llama-quantize.

The build-rocmfp4-rocm714-local.sh script (RDNA4 / RX 9000) downloads the ROCm 7.14.0a20260624 toolchain automatically and bundles the required runtime libraries alongside the binaries. The resulting build is self-contained — no system-wide ROCm install or LD_LIBRARY_PATH needed at runtime.

Use BF16 or F16 GGUF sources. The wrapper keeps split GGUFs split by default.

ROCmFP2:

build-strix-rocmfp4/bin/llama-quantize \
  /path/to/model-BF16.gguf /path/to/model-Q2_0_ROCMFPX.gguf Q2_0_ROCMFPX

ROCmFP3:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q3_0_ROCMFPX.gguf \
  FORMAT=rocmfp3 PROFILE=straight scripts/quantize-rocmfpx-agent.sh

ROCmFP4:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q4_0_ROCMFP4.gguf \
  FORMAT=rocmfp4 PROFILE=straight scripts/quantize-rocmfpx-agent.sh

ROCmFP6:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q6_0_ROCMFPX.gguf \
  FORMAT=rocmfp6 PROFILE=straight scripts/quantize-rocmfpx-agent.sh

ROCmFP8:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q8_0_ROCMFPX.gguf \
  FORMAT=rocmfp8 PROFILE=straight scripts/quantize-rocmfpx-agent.sh

You can also call llama-quantize directly:

build-strix-rocmfp4/bin/llama-quantize source.gguf out-q2.gguf Q2_0_ROCMFPX
build-strix-rocmfp4/bin/llama-quantize source.gguf out-q3.gguf Q3_0_ROCMFPX
build-strix-rocmfp4/bin/llama-quantize source.gguf out-q4.gguf Q4_0_ROCMFP4
build-strix-rocmfp4/bin/llama-quantize source.gguf out-q6.gguf Q6_0_ROCMFPX
build-strix-rocmfp4/bin/llama-quantize source.gguf out-q8.gguf Q8_0_ROCMFPX

For low-bit ROCmFPX quants, pass an imatrix when you have one:

IMATRIX=/path/to/imatrix.gguf \
SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q3_0_ROCMFPX.gguf \
  FORMAT=rocmfp3 PROFILE=straight scripts/quantize-rocmfpx-agent.sh

The wrapper forwards IMATRIX to llama-quantize --imatrix. ROCmFP3, ROCmFP6, and ROCmFP8 use imatrix-weighted scale search; ROCmFP4 has its own imatrix path.

Use agent mode when the model will be used for Hermes/OpenClaw-style workflows, tool calling, JSON output, coding, or chat agents.

ROCmFP3 Agent:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q3_0_ROCMFPX_AGENT.gguf \
  FORMAT=rocmfp3 PROFILE=agent scripts/quantize-rocmfpx-agent.sh

ROCmFP6 Agent:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q6_0_ROCMFPX_AGENT.gguf \
  FORMAT=rocmfp6 PROFILE=agent scripts/quantize-rocmfpx-agent.sh

ROCmFP8 Agent:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q8_0_ROCMFPX_AGENT.gguf \
  FORMAT=rocmfp8 PROFILE=agent scripts/quantize-rocmfpx-agent.sh

ROCmFP4 Agent:

SRC=/path/to/model-BF16.gguf OUT=/path/to/model-Q4_0_ROCMFP4_COHERENT_AGENT.gguf \
  FORMAT=rocmfp4 PROFILE=agent scripts/quantize-rocmfpx-agent.sh

The wrapper maps FORMAT and PROFILE like this:

If you already have an NVFP4 GGUF, you can re-map it onto the ROCmFP4 kernel path without re-quantizing from BF16. This is the closest-matching conversion ROCmFPX supports: NVFP4 and ROCmFP4 use the same UE4M3 scale and share 7 of 8 codebook levels — only the top magnitude level differs (NVFP4 12 vs ROCmFP4 10), so almost every weight maps over cleanly.

# Same 4.50 bpw as NVFP4 (closest quality match):
build-strix-rocmfp4/bin/llama-quantize --allow-requantize \
  model-NVFP4.gguf model-ROCMFP4.gguf Q4_0_ROCMFP4

# Smaller 4.25 bpw (speed-first layout, a little more loss):
build-strix-rocmfp4/bin/llama-quantize --allow-requantize \
  model-NVFP4.gguf model-ROCMFP4_FAST.gguf Q4_0_ROCMFP4_FAST

• --allow-requantize is required: NVFP4 GGUFs usually keep output.weight at a higher-precision type (e.g. q6_K), so the file has mixed source types.
• Example measured on a 9B NVFP4 model (wikitext-2, gfx1151): the 4.50 bpw target landed within noise of the NVFP4 source perplexity; the 4.25 bpw FAST target was ~5% higher perplexity for a ~10% smaller file. Numbers are model-dependent — always A/B against the NVFP4 source on your own prompts.
• To make every tensor ROCmFP4 (a uniform "even" file), use the Q4_0_ROCMFP4_EVEN / Q4_0_ROCMFP4_FAST_EVEN presets, which imply --pure.

If your model ships with an MTP / NextN draft head (many recent models do), you can turn on self-speculative decoding for a real decode speedup — no separate draft model needed. This is the most effective way to push decode throughput past what the weight format alone can do, because accepted draft tokens produce several tokens per weight read.

MTP helps both dense and MoE models here. On gfx1151, -dev Vulkan0 was the fastest backend in the validated Qwen3.6 and Qwable comparisons.

# General starting profile for a model with an embedded MTP/NextN head
build-strix-rocmfp4/bin/llama-cli \
  -m model-with-MTP.gguf -dev Vulkan0 -ngl 999 -fa on --jinja \
  --temp 0 \
  --spec-type draft-mtp --spec-draft-n-max 6 --spec-draft-p-min 0.6

• Tune per model and workload. n6 / p0.60 is a useful starting point, but the validated Qwen3.6-35B-A3B profile was faster at n4 / p0.55. Very low p_min can waste work on rejected drafts; an overly high value can miss useful draft tokens.
• The speedup is content-dependent: structured / predictable output (code, lists, JSON) accepts more drafts and gains most; free-form creative text gains less.
• It is lossless: at greedy (--temp 0) the output matches non-speculative decoding token-for-token (the target model verifies every drafted token).
• See Verified MTP Results for current Qwable and Qwen3.6 measurements, profiles, and branch-parity context.

M-RoPE models (qwen35 / qwen35moe, and any IMROPE/MROPE arch): MTP now works on these. They use 4-D M-RoPE positions, and the batch position check previously rejected the MTP draft/verify batch every step (for M-RoPE, it is required that the position satisfies: X < Y), so MTP silently fell back to plain decode. The MTP hook batch is a hybrid (token id plus an injected hidden-state row) and is allowed to reuse positions like an embedding batch, so the strict check is now gated on batch.token && !batch.embd (src/llama-batch.cpp). If you are on an older build and see that X < Y error spamming during MTP, this is the fix. NEOX-RoPE MTP (e.g. Gemma4 assistants) was never affected.

The agent profile is a tensor-routing choice. It keeps the ROCmFPX block formats but spends more bits on tensors that affect structured behavior:

• token and output embeddings
• attention Q/K/V/O tensors
• selected FFN-down tensors
• selective FFN-gate tensors
• bulk FFN-up tensors stay on the family quant where possible

This is why agent quants are slightly larger than straight quants. The goal is to preserve JSON shape, tool-call shape, coding behavior, and chat coherency without forcing the whole model to a generic high-bit quant.

Simple ROCm run:

build-strix-rocmfp4/bin/llama-cli \
  -m /path/to/model-Q8_0_ROCMFPX_AGENT.gguf \
  -dev ROCm0 \
  -ngl 999 \
  -fa on \
  -c 8192 \
  -b 512 \
  -ub 512 \
  --jinja

OpenAI-compatible server:

build-strix-rocmfp4/bin/llama-server \
  -m /path/to/model-Q8_0_ROCMFPX_AGENT.gguf \
  --host 127.0.0.1 \
  --port 8138 \
  -dev ROCm0 \
  -ngl 999 \
  -fa on \
  -c 8192 \
  -b 512 \
  -ub 512 \
  --jinja \
  --reasoning off

ROCmFPX model quants and K/V cache types are separate runtime controls.

The current guard promotes -ctk q3_0_rocmfpx to q6_0_rocmfpx because fp3 K cache was below the observed tool-call and agent coherency floor. q3_0_rocmfpx can still be used for V cache.

TurboQuant K/V cache support is already built into this tree as the turbo3 and turbo4 runtime cache types, including CPU reference tests plus ROCm/HIP and Vulkan paths. TurboQuant is not a ROCmFPX model-weight quant; use it with -ctk and -ctv at runtime.

The recommended safe TurboQuant+ style policy is asymmetric K/V:

build-strix-rocmfp4/bin/llama-server \
  -m /path/to/model-Q6_0_ROCMFPX_AGENT.gguf \
  -dev Vulkan0 \
  -ngl 999 \
  -fa on \
  -ctk q8_0 \
  -ctv turbo4 \
  --jinja

For the ROCmFPX MTP server wrapper, use the preset script:

MODEL=/path/to/model-Q6_0_ROCMFPX_AGENT.gguf \
DEVICE=Vulkan0 \
scripts/run-rocmfpx-turboquant-asym-server.sh

This keeps K cache at q8_0, where attention quality and tool calls are more sensitive, and uses turbo4 for V cache, where compression is usually cheaper. You can still run symmetric TurboQuant for sweeps with -ctk turbo3 -ctv turbo3 or -ctk turbo4 -ctv turbo4, but do not treat those as the default agentic serving profile.

For symmetric TurboQuant experiments, first/last-layer K protection is available as an opt-in compatibility knob:

LLAMA_KV_TURBO_BOUNDARY_LAYERS=2 \
build-strix-rocmfp4/bin/llama-server \
  -m /path/to/model.gguf \
  -ctk turbo4 \
  -ctv turbo4

With that flag, the first and last two model layers use q8_0 for K cache while the middle layers use the requested TurboQuant type. V boundary protection is off by default; enable it only for experiments with LLAMA_KV_TURBO_BOUNDARY_V=1.

Do not import the Python turboquant_plus research package into this C/C++ tree as-is. The low-risk production findings are the asymmetric K/V policy and documentation. QJL and turbo2 are intentionally not enabled here, and block-size 128 would require a GGML block-layout change and compatibility work.

The agentic smoke harness checks chat, coding, JSON, tool-call JSON, coherency, and streaming. It also refuses to start when ROCm reports an active KFD process, so each run starts after VRAM/process cleanup.

MODEL=/path/to/model-Q8_0_ROCMFPX_AGENT.gguf \
BACKEND=ROCm0 \
ALIAS=rocmfpx-agent \
OUT_DIR=/tmp/rocmfpx-agentic-smoke \
scripts/check-rocmfpx-agentic-smoke.sh

• ggml/rocmfpx/ - ROCmFP2/ROCmFP3/ROCmFP6/ROCmFP8 reference formats
• ggml/rocmfp4/ - ROCmFP4 reference path this family inherits from
• scripts/quantize-rocmfpx-agent.sh - simple straight-vs-agent quant wrapper
• scripts/check-rocmfpx-agentic-smoke.sh - OpenAI-compatible agent smoke test
• docs/ROCmFPX-HANDOFF.md - detailed handoff for reviewers and other agents
• docs/ROCmFPX-EXPERIMENT.md - experiment history, routing notes, and gates
• docs/BUILD-AMD-ARCHITECTURES.md - RDNA2/RDNA3/RDNA4/Strix build details

This repository is based on llama.cpp and keeps the upstream MIT license. See LICENSE for details. Bundled third-party notices are listed in THIRD_PARTY_NOTICES.md.