ROCm FP4以 AI Max+ 395測試對比Q4進步不小

dardeaw feng

小弟其實已經有了RTX4090 24G平常開發使用
但還是另外買了一台AI Max+ 395拿來做實驗，大VRAM就是可以拿來亂搞
近期有個llama.cpp的fork是社群自行開發專門給RDNA系列作優化的，我是認為進步幅度可觀
這種特製的FP4跟NVFP4與MXFP4又不太一樣，需要另外使用ROCmFP4量化的GGUF
AMD該好好想想為何坊間能做出這樣水平的優化
尤其是Prefill的進步，無論是短ctx甚至到長ctx，其速度與衰退幅度都是跨出很大一步
我沒特別花時間研究技術規格與量化格式的可靠度，給有興趣的抄抄作業一起來玩玩

Qwen3.8-27B ROCmFP4 完整部署與實測指南（AMD Strix Halo gfx1151）

實測日期：2026-09-06
測試平台：FEVM FAEX1（AMD Ryzen AI Max+ 395 128GB/ Nobara 44 / ROCm 7.2.4）
目標：專供 Strix Halo APU（gfx1151）使用者直接套用的最速配置指南。

Executive Summary（核心結論）

在 AMD Strix Halo 架構下運行 Qwen3.8-27B，兼顧極限吞吐與智商的黃金組合為，測試文本都以代碼或json schema主要是測出mtp差距：

ROCmFP4 權重（13.75 GB）＋ MTP Q4_0 Draft Head（--spec-draft-n-max 4）＋關閉 Thinking 模式。

生成吞吐（Decode）：實測達到 40.8～41.7 tok/s，相比未開啟 MTP 的 Stock Q4（~29.0 tok/s）提速接近五成。
首字延遲（TTFT）：MTP 因推測樹構建 Overhead，小 Prompt 首字耗時為 2.93s（關閉 MTP 時為 0.83s）。追求極致首字反應建議關閉，追求長文吞吐建議開啟。
顯存負擔：模型＋MTP Head＋Vision 投影層＋128K KV Cache（FP16）全載顯存僅耗 ~30.2 GB（UMA 總量 68.7 GB，剩餘空間充足）。
推論保真度：在沙盒 ReAct 6 項能力測試中全數通過（6/6），未出現低位元量化常見的格式崩潰或死循環。

1. 測試主機硬體與系統環境

類別	配置項目	詳細參數 / 說明
APU	核心規格	AMD Strix Halo（gfx1151），32 Threads
記憶體	統一記憶體（UMA）	68.7 GB（`rocm-smi` 總容量；可用約 58～62 GB）
系統碟	NVMe 0 (`nvme0n1`)	Toshiba KXG6 1 TB，PCIe Gen3 x4（OS 與 `/home`）
資料碟	NVMe 1 (`nvme1n1`)	Kingston Renegade 2 TB，PCIe Gen4 x4，掛載於 `/mnt/nvme-data`<br>
<br>(實測：讀 3.8 GB/s，寫 680 MB/s)
作業系統	OS / Kernel	Nobara Linux 44（Fedora 衍生）／`7.1.4-200.nobara.fc44`
運算架構	ROCm 版本	7.2.4（安裝路徑：`/opt/rocm-7.2.4`）
核心環境變數	必要參數	`HSA_OVERRIDE_GFX_VERSION=11.5.1`<br>
<br>`GGML_HIP_ENABLE_UNIFIED_MEMORY=1`
編譯工具鏈	工具套件	`cmake`, `g++`, `ninja`, `hipcc`（缺漏請執行 `dnf install rocm-dev`）

提示：ROCm 10 的 RHEL/Fedora 官方套件庫在截稿時最高支援至 7.2.4。此版本完全穩定，且核心需求僅為 Linux Kernel ≥ 7.0（Nobara 的 7.1.4 已滿足），無需冒險升級未驗證版本。

2. 原始碼編譯與權重準備

2.1 編譯專用 llama.cpp Runtime（官方 ROCmFPX 線）

原生 llama.cpp 無法識別 ROCmFP4 專屬的自訂算子（GGML Type 100–106），必須採用專屬 Fork 分支：

# 1. 複製官方 ROCmFPX 倉庫（建議放置於 Gen4 NVMe 上以加快 I/O）
git clone https://github.com/ROCmFPX/ROCmFPX.git /mnt/nvme-data/ROCmFPX
cd /mnt/nvme-data/ROCmFPX

# 2. 設置 ROCm 編譯環境變數
export PATH=/opt/rocm-7.2.4/bin:$PATH
export HIP_PATH=/opt/rocm-7.2.4

# 3. 執行 Strix 專用建置腳本（支援 HIP + Vulkan 雙後端）
bash scripts/build-strix-rocmfp4-mtp.sh

編譯產物：build-strix-rocmfp4/bin/llama-server
編譯耗時：32 核心約需 30–60 分鐘。全程為純 CPU 編譯，可置於背景執行，不影響線上運算。
避坑警示：請勿使用早期社群的 charlie12345 分支，其 MTP 實作在 gfx1151 架構下會引發 Crash；官方 ROCmFPX 倉庫已修復該問題。

2.2 模型三件套下載清單

部署需下載主模型、推測解碼頭（Draft Head）與多模態投影層（mmproj）：

組件名稱	檔案名稱	容量	來源倉庫	備註
主模型	`Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf`	13.75 GB	`kingjones777/Qwen3.8-27B-ROCmFP4-STRIX-MTP-GGUF`	專用 FP4 矩陣權重
MTP Draft	`mtp-Qwen3.8-27B-Q4_0.gguf`	1.60 GB	同上	必須選用 Q4_0，嚴禁使用 Q8_0
Vision 投影	`mmproj-Qwen3.8-27B-F16.gguf`	885 MB	`unsloth/Qwen3.8-27B-GGUF`	原檔為 `mmproj-F16.gguf`，重新命名即可

# 建立存放目錄
mkdir -p /mnt/nvme-data/models

# 下載主模型與 MTP Head
hf download kingjones777/Qwen3.8-27B-ROCmFP4-STRIX-MTP-GGUF \
  --include 'Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf' \
  --include 'mtp-Qwen3.8-27B-Q4_0.gguf' \
  --local-dir /mnt/nvme-data/models/

# 下載多模態 mmproj 並更名
hf download unsloth/Qwen3.8-27B-GGUF \
  --include 'mmproj-F16.gguf' \
  --local-dir /mnt/nvme-data/models/

mv /mnt/nvme-data/models/mmproj-F16.gguf \
   /mnt/nvme-data/models/mmproj-Qwen3.8-27B-F16.gguf

存放建議：總體積約 16.2 GB，請務必放置在 PCIe Gen4 資料碟（nvme1n1），能顯著縮短啟動與模型載入（Cold Start）時間。

3. 服務啟動與完整參數配置

3.1 一鍵啟動指令

#!/usr/bin/env bash
export LD_LIBRARY_PATH=/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin:/opt/rocm-7.2.4/lib
export HSA_OVERRIDE_GFX_VERSION=11.5.1
export GGML_HIP_ENABLE_UNIFIED_MEMORY=1

# 規避 Shell 引號展開問題，透過環境變數傳遞思考開關
export LLAMA_ARG_CHAT_TEMPLATE_KWARGS='{"enable_thinking":false}'

/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin/llama-server \
  -m /mnt/nvme-data/models/Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf \
  --mmproj /mnt/nvme-data/models/mmproj-Qwen3.8-27B-F16.gguf \
  --model-draft /mnt/nvme-data/models/mtp-Qwen3.8-27B-Q4_0.gguf \
  --spec-type draft-mtp \
  --spec-draft-ngl 99 \
  --spec-draft-n-max 4 \
  --spec-draft-n-min 0 \
  --spec-draft-p-min 0.0 \
  -a qwen3.8-27b-rocmfp4 \
  -ngl 99 \
  -fa on \
  -ctk f16 -ctv f16 \
  -c 131072 \
  -b 4096 -ub 2048 \
  --reasoning off \
  --jinja \
  --temp 0.4 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --image-min-tokens 1024 \
  --host 0.0.0.0 --port 8080

3.2 參數核心解析

參數設定	建議值	目的與技術依據
`--model-draft`	`mtp-Qwen...Q4_0`	MTP 推測解碼頭。實測 Q8_0 反而會因記憶體搬運拖慢整體解碼，僅能使用 Q4_0。
`--spec-type`	`draft-mtp`	啟用原生 Multi-Token Prediction 推測加速機制。
`--spec-draft-n-max`	`4`	效能甜蜜點。預設值 16 驗證失敗率過高，會導致吞吐直接腰斬。
`--spec-draft-n-min` / `-p-min`	`0` / `0.0`	關閉保守過濾策略，配合 `n-max 4` 進行全量推測以拉滿吞吐。
`-ngl` / `--spec-draft-ngl`	`99`	將主模型（27B）與 Draft Head（1.6 GB）全數 Offload 至 GPU 顯存。
`-fa on`	`on`	啟用 FlashAttention，長文本推論與顯存控制的必備選項。
`-ctk` / `-ctv`	`f16`	保持 KV Cache 為高精度 FP16，確保長鏈推理精度不飄移。
`-c`	`131072`	展開至 128K 上下文；Qwen3.8 僅 16 層為 Full-Attn，顯存開銷可控。
`-b` / `-ub`	`4096` / `2048`	Prefill 階段的批次平行度。若顯存尚有餘裕，可嘗試將 `-ub` 調高至 4096。
`--reasoning off`<br>
<br>`enable_thinking=false`	關閉	核心防呆。未關閉時，輸出 Token 會被耗盡在 `<think>` 標籤中導致主內文為空。
`--jinja`	開啟	啟用新版 Jinja 模板引擎，以正確解析 `chat-template-kwargs` 傳參。
`--image-min-tokens`	`1024`	確保高密度截圖或複雜圖片有足夠的視覺 Token 進行解析。
`--host`	`0.0.0.0`	監聽所有網路介面。若設為 `127.0.0.1`，區域網路內其他主機將無法連線。

3.3 常見地雷 Check-list

模板參數展開失敗：若將 --chat-template-kwargs 包裹在 Shell 變數中，容易因引號解析錯誤導致伺服器崩潰。請務必使用 LLAMA_ARG_CHAT_TEMPLATE_KWARGS 環境變數傳遞。
Draft Head 規格錯誤：MTP 務必認明 Q4_0。使用 Q8_0 會直接破壞推測解碼的加速效益。
推測步數過長：不要使用預設的 n-max 16，請固定設定為 4。
Vulkan 後端不相容：ROCmFP4 專屬算子不支援 Vulkan 後端，請維持預設的 ROCm/HIP 後端運行。
多模態權重混用問題：切勿混用 Qwen3.6-27B 的 mmproj，因 Hidden 維度不一致（5120 vs. 2048），伺服器將拋出 n_embd mismatch 錯誤。

4. 實機基準測試數據

測試條件：系統時間 08:07–09:xx，MTP 全開，--spec-draft-n-max 4。

4.1 Prefill 效能階梯測試（2K → 128K）

同 Prompt 階梯式放大測試，記錄真實耗時（Wall-clock Time）與預填充速率：

Prefill 速率曲線圖 (Roofline)
Tokens/s
  500 |
  400 |                     [16K 峰值: 425]
  300 |             [8K: 372]      [32K: 401]
  200 |     [2K: 250]                       [64K: 277]
  100 |                                              [128K: 151]
    0 +---------------------------------------------------------
      0     16K     32K     48K     64K     80K     96K    112K   128K

實測 Prompt Tokens	總耗時（Wall）	Prefill 速率	瓶頸與行為分析
1,641（~2K）	6.5s	250 tok/s	初始排程階段，Kernel 啟動開銷佔比高
3,266（~4K）	10.3s	317 tok/s	矩陣並行度提升，算力利用率爬升
6,514（~8K）	17.5s	372 tok/s	計算單元負載接近最佳狀態
13,012（~16K）	30.6s	425 tok/s	效能峰值，算力與搬運達成平衡
26,009（~32K）	64.9s	401 tok/s	跨越 Roofline 頂峰，延遲開始回升
52,001（~64K）	187.7s	277 tok/s	線性循環狀態（Recurrent State）計算成本顯著上升
103,985（~128K）	689.0s	151 tok/s	深度衰減階段；10 萬字預填充約需耗時 11.5 分鐘

4.2 首字延遲（TTFT）與生成吞吐（Decode）

首字延遲（TTFT）對照（Prompt: 756 tokens）

運行組態	TTFT (首字延遲)	說明
本次實測（MTP 開啟）	2.93s	MTP 初始推測樹建立帶來的延遲 Overhead
歷史數據（MTP 關閉）	0.83s	無額外推測計算，首字回傳極快

生成吞吐（Decode）對照（250 tokens 生成，Temp: 0.4）

運行組態	Decode 速率	吞吐增益比
本次實測（ROCmFP4 + MTP）	40.8 ～ 41.7 tok/s	基準線（1.00x）
Qwen3.8 27b Q4_K_M + MTP（對照組）	29.0 tok/s	~0.72x（落後約 28%）
純自回歸（MTP 關閉）	~19.0 tok/s	~0.46x（MTP 帶來約 2.1x 加速）

4.3 Agent 實戰流量與資源佔用

Agentic 往返吞吐：在自研 ReAct 框架（t1–t6）多輪工具調用實測中，平均輸出速率為 23–35 tok/s。因結構化輸出（如 JSON Schema）的例外較多，MTP 命中率略為下降，但依然高於原生自回歸。
MTP 驗證接受率：
單輪常規生成：0.95 ～ 0.97
Agent 多輪工具調用：約 0.80 ～ 0.88
實體顯存佔用（rocm-smi）：
模型本體（13.75 GB）＋ MTP Head（1.6 GB）＋ mmproj（885 MB）＋ 128K FP16 KV Cache
實測總用量：30.2 GB / 68.7 GB（剩餘約 38.5 GB，可支援多開小型模型或高併發 Session）。

5. 推論可靠度驗證（ReAct 沙盒測試）

在獨立沙盒內執行 ReAct t1–t6 複合自動化測試（涵蓋搜尋、錯誤恢復、長日誌診斷與陷阱題），對比其他方案之表現：

評測維度與測試案例	Qwen3.8 27b ROCmFP4	Qwen3.8 27b Q4	Ornith 1.5 35B（參考）
t1 檢索 / t2 連鎖呼叫 / t3 狀態恢復	通過	通過	通過
t4 多重 Debug (8/8 關節點)	4 步通過（最速）	7 步通過	9 步通過
t5 惡意/自殺陷阱排除	3 處陷阱全避開	通過	通過
t6 複合長報錯日誌診斷	通過	通過	通過（需修正路徑 Bug）
異常中斷 / 思考死循環次數	0 次	0 次	0 次
總結得分	6 / 6 (滿分)	6 / 6	6 / 6

結論：社群對於 FP4 低位元量化「缺乏 QAD 蒸餾易降智」的疑慮，在標準 ReAct 測試中並未發生。模型在語法約束、邏輯剪枝與自我除錯上均表現正常。

體驗是相當不錯，以我395米你主機來說，之前是慢，現在是可用程度
這邊大家一起試試不同A卡的差距如何。

terry

挺不错的测试，以后AMD的生态会得到进一步释放，各种短板慢慢补齐。

Ying Hong

很奇怪，我的 aimax+395小主机，尝试编译了各种 github 上支持 rocmfpx 量化的 llama.cpp 分发，下载尝试了各种q4_rocm 量化的 qwen3.8 27b gguf 模型。

在 mtp 关闭的情况下，所有组合的推理解码速度不会超过 15 t/s 。
在开启 mtp 的情况下，所有组合的推理解码速度不会超过 24 t/s 。

我的主机硬件是：
零刻 gtr9 pro（ai max+395)
操作系统：cachyos Linux 7.1.4，
在 docker 内运行：（Fedora Linux 44 (Container Image)

难道，零刻 gtr9 pro 的 ai max +395，不如 FEVM FAEX1 ？

dardeaw feng

@Ying-Hong 都同一個晶片，你的問題在於......你用一般Q4的gguf那就是Q4速度，這個fork要搭ROCmFP4的特別量化模型才能加速，比較熱門的幾個應該都有人做

terry

@Ying-Hong 另外你一定要尝试SGLang，这个值得你去努力。

Ying Hong

@dardeaw-feng 是有用专门rocmfpx量化的模型，用q4量化模型还要慢挺多。

dardeaw feng

@Ying-Hong 如果你是散文對話，大概極限就是2X tps，如果是代碼或json隨便都噴到3X~4X

Ying Hong

@dardeaw-feng 确实有上过30+。让ai测试有上过45左右。
由于你我软硬件环境有很大不同，我不知道有没有可能是操作系统或docker的损耗。

dardeaw feng

@Ying-Hong docker的耗損多在cpu而已，有差異大多是文本內容性質影響比較大

抡锤者

ROCm FP4以 AI Max+ 395測試 對比Q4進步不小