ROCmFP4搭配DFlash2演進實測（AMD AI Max+395）

dardeaw feng

繼下午分享幾個實測包含SGLang與Llama.cpp的ROCmFP4的配置
小弟繼續操這台迷你主機能想到的方法都上
前幾天搞ROCmFP4的優化框架與模型我是滿意的，但當時用的是mtp解碼，其實那個版本沒上DFlash2
現在開幹給兄弟們找樂子，適用於所有RDNA3以後的架構(RDNA2的卡我手上沒有，無法告知有沒有用)

ROCmFP4 搭配 DFlash2 演進實測指南（AMD Strix Halo gfx1151）

實測日期：2026-09-09
測試主機：FEVM FAEX1（Ryzen AI Max+ 395 / Nobara 44 / ROCm 7.2.4）
核心結論：DFlash2 全面取代 MTP。生成吞吐打平微幅領先、推測接受率更高、預填充（Prefill）長短兩端全勝、Draft 權重體積縮減 500 MB，且長文本深度無衰減。Preset 已平滑切換，可直接套用。

1. 軟硬體環境與模型規格

1.1 主機硬體與系統配置

項目	規格參數	備註與說明
APU	AMD Ryzen AI Max+ 395	`gfx1151`，32 線程
統一記憶體（UMA）	68.7 GB（實用約 58～62 GB）	依賴 UMA 直通，全層完全卸載至顯存
系統碟	NVMe 0 (`nvme0n1`)	Toshiba KXG6 1 TB，PCIe Gen3 x4（系統與 `/home`）
資料碟	NVMe 1 (`nvme1n1`)	Kingston Renegade 2 TB，PCIe Gen4 x4，掛載於 `/mnt/nvme-data`（權重放置處）
OS / Kernel	Nobara Linux 44（Fedora 系）	核心版本：`7.1.4-200.nobara.fc44`
ROCm 運行庫	ROCm 7.2.4	必要環境變數：`HSA_OVERRIDE_GFX_VERSION=11.5.1` `GGML_HIP_ENABLE_UNIFIED_MEMORY=1`

1.2 推論框架：ROCmFPX 分支llama.cpp（原 charlie12345 / 官方線）

標準 Stock llama.cpp 無法識別 ROCmFP4 格式（GGML Type 100–106），必須採用專屬 Fork 分支編譯：

# 取得 ROCmFPX 源碼並編譯
git clone https://github.com/ROCmFPX/ROCmFPX.git /mnt/nvme-data/ROCmFPX
cd /mnt/nvme-data/ROCmFPX
export PATH=/opt/rocm-7.2.4/bin:$PATH
export HIP_PATH=/opt/rocm-7.2.4

bash scripts/build-strix-rocmfp4-mtp.sh
# 編譯產物：build-strix-rocmfp4/bin/llama-server
# 具備 HIP + Vulkan 雙後端，32 核心耗時約 30～60 分鐘

分支特性解構：針對 AMD RDNA 3.5 架構深度客製。內建手寫 HIP Dequant 算子、gfx1151 原生 INT4（IU4）指令對齊、修復 MTP 崩潰問題、整合 TurboQuant KV 傳輸路徑，並對 Agent 任務進行敏感層（Embedding / Attention）位元保留。

1.3 測試模型權重清單

檔案名稱	容量	來源倉庫	角色說明
`Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf`	13.75 GB	`kingjones777/Qwen3.8-27B-ROCmFP4-STRIX-MTP-GGUF`	主模型（專用 FP4 矩陣）
`mtp-Qwen3.8-27B-Q4_0.gguf`	1.60 GB	同上	原 MTP Draft Head（正式退役）
`Qwen3.8-27B-DFlash2-Q4_K_M.gguf`	1.10 GB	`z-lab/Qwen3.8-27B-DFlash2-GGUF`	DFlash2 Draft（本次升級核心）
`mmproj-Qwen3.8-27B-F16.gguf`	885 MB	`unsloth/Qwen3.8-27B-GGUF`（原檔更名）	多模態 Vision 投影層

# 下載官方 DFlash2 草稿模型
hf download z-lab/Qwen3.8-27B-DFlash2-GGUF \
  --include 'Qwen3.8-27B-DFlash2-Q4_K_M.gguf' \
  --local-dir /mnt/nvme-data/models/

2. DFlash2 整合與部署

2.1 框架支援度驗證（無需重新編譯）

DFlash2 於 upstream PR #27342（2026-08-27，b10f9ca58）正式併入，ROCmFPX 最新 HEAD 已自動繼承。可透過以下兩步驟驗證二進位檔支援性：

# 1. 驗證源碼提交紀錄
git -C /mnt/nvme-data/ROCmFPX merge-base --is-ancestor b10f9ca58 HEAD && echo "IN-HEAD"

# 2. 驗證 llama-server 支援選項
export LD_LIBRARY_PATH=/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin:/opt/rocm-7.2.4/lib
/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin/llama-server --help | grep spec-type
# 輸出選單中若包含 draft-dflash 即表示完整支援

8 月底建置之 Binary 已包含此功能，無須重跑編譯。
僅在 Fork 長期落後 upstream 或 HIP 底層 Kernel 更新時才需執行 git pull 重新編譯。

2.2 機制特性：DFlash2 vs. MTP

機制原理：MTP 為傳統序列推測（一次預測單一前進方向）；DFlash2 採用 Block-Diffusion Drafter，利用小型擴散結構一次預測一整組 Token 區塊。
部署需求：需要加掛專屬 Draft 權重（1.1 GB），透過指定 --spec-type draft-dflash 與 --model-draft 即可啟用。

2.3 啟動命令與參數配置

#!/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

/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 \
  --spec-type draft-dflash \
  --model-draft /mnt/nvme-data/models/Qwen3.8-27B-DFlash2-Q4_K_M.gguf \
  --spec-draft-n-max 4 \
  -ngl 99 -fa on -dio --jinja -fit off --parallel 1 -dev ROCm0 \
  -c 131072 --reasoning off --image-min-tokens 1024 -b 4096 -ub 2048 \
  --temp 0.4 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --host 0.0.0.0 --port 8080

與 MTP 啟動參數差異：

調整為 --spec-type draft-dflash。

--model-draft 指向 DFlash2 權重檔。

移除 --spec-draft-ngl、--spec-draft-n-min、--spec-draft-p-min（DFlash2 算子不相容此類 MTP 專用標籤）。

2.4 Preset 設定檔

[qwen3.8-27b-rocmfp4]
model = /mnt/nvme-data/models/Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf
mmproj = /mnt/nvme-data/models/mmproj-Qwen3.8-27B-F16.gguf
spec-type = draft-dflash
model-draft = /mnt/nvme-data/models/Qwen3.8-27B-DFlash2-Q4_K_M.gguf
spec-draft-n-max = 4
c = 131072
load-on-startup = false

2.5 避坑導航（實戰經驗彙整）

推測長度必須固定為 4：測試驗證 spec-draft-n-max=4 為最佳甜蜜點。在 gfx1151 架構下，設為 7 反而會引發排程反轉，32K 上下文時寬度 4 的表現領先寬度 7 達 29%。
認明官方 Draft 來源：請務必選用 z-lab 官方倉庫；社群部分轉檔（如 incoai 版本）存在上游已知張量缺陷。
Vision 多模態相容性：DFlash2 草稿路徑僅負責純文字推測，不走多模態張量；因此舊版 mmproj 仍可正常支援主模型的多模態辨識。
多卡分散式限制：目前 DFlash2 在多 GPU 環境下仍存在已知 Issue；單顆 Strix Halo APU（全載 UMA）運作正常。
嚴禁改走 Vulkan 後端：DFlash2 在 Vulkan 後端存在數值無效的 Bug（PR #27805 尚在合併中），Strix Halo 請維持 -dev ROCm0。

3. 測試基準與實測方法

Decode 測試：固定 Prompt（Fibonacci 矩陣快速冪，輸入 53 tokens），max_tokens=250，temp=0.4。連續測試 3 次取平均，推測接受率（Draft Acceptance）取自 Server 日誌。對照組為相同 Prompt 之 MTP 配置。
Prefill 測試：標準英文填充文本放大至目標 Token 級距（2K～128K 共七階），max_tokens=3，統計 Wall-clock time 並換算 usage.prompt_tokens。
Agentic 實戰測試：自研 ReAct 沙盒測試集（t1–t6：檢索、連鎖呼叫、狀態恢復、複雜除錯、惡意陷阱、長日誌診斷），工具調用與推測解碼全開。

4. 效能對決：DFlash2 vs. MTP

4.1 Decode 吞吐與推測接受率（生成 250 Tokens）

評測指標	DFlash2（n-max 4）	MTP（n-max 4）	差異分析
第 1 次輸出	45.7 tok/s	45.3 tok/s	微幅勝出
第 2 次輸出	46.8 tok/s	—	穩定維持在 46+
第 3 次輸出	45.8 tok/s	—	波動極小
平均驗證接受率	0.98（198/202，均長 4.88）	0.95～0.97	區塊推測命中率更高

短序列 Decode 表現持平微勝（約 +1%～3%），與社群外部測試趨勢一致（如 RTX 3090 上 DFlash2 62.2 vs. MTP 57.8，+7.6%）。

4.2 Prefill 七階梯次吞吐測試

上下文級距	DFlash2 (tok/s)	MTP (tok/s)	增益幅度	運行分析
2K	315.6	250.5	+26%	起步階段開銷低，顯存佔用減小
4K	319.2	317.2	持平	進入 GEMM 矩陣計算常態
8K	376.1	371.5	持平	算力單元逐步吃滿
16K	431.6	424.9	持平	算力吞吐峰值區間
32K	415.8	400.7	+4%	序列拉長，記憶體搬運負擔顯現
64K	308.8	277.1	+11%	循環狀態與 Attention 負擔加重
128K	189.6	150.9	+26%	深度長文本下，VRAM 釋放效益顯著

Prefill 增益來源：中段計算密集區（4K～16K）兩者皆受限於硬體密集計算，因此表現持平；兩端（極短 2K 與極長 128K）DFlash2 提速達 26%，主要受益於 Draft 權重較輕（1.1 GB vs. 1.6 GB），降低了 UMA 記憶體頻寬與排程壓力。

4.3 長序列深度衰減表現（引用外部驗證數據）

以 gfx1151 測試基準為例，對比不同推測方案隨 Context 深度拉長之吞吐衰減趨勢：

上下文深度	Base (無推測)	DFlash v1	DFlash2 (n-max 4)
0（極短文本）	11.81 tok/s	21.09 tok/s	26.39 tok/s
8K	11.44 tok/s	12.87 tok/s	21.58 tok/s
32K	10.54 tok/s	10.75 tok/s (加成歸零)	21.11 tok/s (持續保持 2x 加速)

技術迭代本質：DFlash v1 在序列拉長至 32K 時推測命中率會徹底衰竭，吞吐退回至基準線；DFlash2 在全序列深度下皆能保持 2 倍左右的推測解碼增益，解決了長文本推理掉速的痛點。

5.AMD Strix Halo（gfx1151）跨框架推論實測全景總覽

測試基準：AMD Ryzen AI Max+ 395（gfx1151，40 CU，32 執行緒）；UMA 總計 68.7 GB（BIOS Carve 固定）；模型統一為 Qwen3.8-27B。

四大推論組態橫向規格對照

評測維度	1. Stock llama.cpp(官方非 Fork 主線)	2. ROCmFPX (MTP)(專用 Fork 舊版)	3. ROCmFPX (DFlash2)(專用 Fork 定案版)	4. SGLang(GPTQ + Triton)
底層運行核心	原生 HIP Kernel	客製 HIP Dequant 算子(對齊 RDNA 3.5 IU4)	客製 HIP Dequant 算子(對齊 RDNA 3.5 IU4)	Python 獨立 venvAOT `sgl_kernel` + Triton
支援模型格式	標準 Q4_K_M(~16.5 GB)	Q4_0_ROCMFP4(13.75 GB)	Q4_0_ROCMFP4(13.75 GB)	GPTQ-Int4(~19 GB)
推測解碼方案	無（純自回歸）或標準 MTP Draft	MTP Draft Head(`mtp-Q4_0`, 1.6 GB)	DFlash2 Block-Diffusion(`DFlash2-Q4_K_M`, 1.1 GB)	EAGLE / MTP(靜態 5/4/8 樹狀推測)
KV Cache 精度	FP16	FP16	FP16	FP8 (`fp8_e4m3`)
Prompt Cache	Slot 環狀序列(分叉即失效，依賴磁碟)	Slot 環狀序列(同左)	Slot 環狀序列(同左)	Radix Tree (基數樹)(跨 Session 秒級喚醒)

5.1 單路與併發解碼吞吐（Decode）

運行組態	單路 Decode 速率	4 路併發 Decode 總量	推測驗證接受率
Stock llama.cpp (純自回歸)	~19.0 tok/s	45 ～ 50 tok/s	N/A
Stock llama.cpp (標準 MTP)	24.0 tok/s	~50.0 tok/s	0.60 ～ 0.70
SGLang (GPTQ + MTP)	28.9 tok/s (Code)~21.0 tok/s (常規)	63.3 tok/s	0.41 ～ 0.55 (Accept Len ~4.5)
ROCmFPX (MTP)	40.8 ～ 41.7 tok/s	62.0 tok/s	0.95 ～ 0.97
ROCmFPX (DFlash2)	45.7 ～ 46.8 tok/s(全場最快)	62.5 tok/s	0.98 (均長 4.88)

記憶體頻寬天花板：4 路併發解碼下，所有框架總吞吐皆受制於 Strix Halo 實體 256-bit 頻寬物理極限，上限鎖死在 62 ～ 63 tok/s。

5.3 預填充吞吐階梯（Prefill Sweep）

上下文級距	Stock llama.cpp	SGLang (GPTQ)	ROCmFPX (MTP)	ROCmFPX (DFlash2)
2K	~180.0 tok/s	369.7 tok/s	250.5 tok/s	315.6 tok/s
4K	~240.0 tok/s	504.4 tok/s (峰值)	317.2 tok/s	319.2 tok/s
8K	~230.0 tok/s	390.1 tok/s	371.5 tok/s	376.1 tok/s
16K	~200.0 tok/s	266.2 tok/s	424.9 tok/s	431.6 tok/s (峰值)
32K	~160.0 tok/s	140.2 tok/s	400.7 tok/s	415.8 tok/s
64K	~110.0 tok/s	112.6 tok/s	277.1 tok/s	308.8 tok/s
128K	嚴重溢出拖累	需靠 Cache 攤平	150.9 tok/s	189.6 tok/s (領先 26%)

5.4 推論引擎架構特點與瓶頸分析

Prefill 性能特徵對比
Tokens/s
  600 |         [SGLang 4K: 504.4]
  500 |                 \
  400 |                  \   [DFlash2 16K: 431.6]
  300 |                   \       \________ [DFlash2 64K: 308.8]
  200 |    [Stock 4K: 240] \               \
  100 |                     \_______________\[SGLang 64K: 112.6]
    0 +---------------------------------------------------------
      0        16K       32K       48K       64K       80K      128K

Stock llama.cpp（非 Fork 主線）：
運行標準 Q4_K_M 需承擔非對稱解包開銷，ALU 產生指令空泡，Prefill 峰值受限於 240 tok/s。
逐字生成需多搬運約 3 GB 權重，純自回歸速度僅 19 tok/s。
SGLang (GPTQ + FP8 KV)：
Triton GEMM Kernel 在短序列（4K）能將算力完全打滿，Prefill 峰值達 504.4 tok/s。
具備 Radix Tree 快取，6K 重複 Prompt 首字延遲自 17～68 秒降至約 1 秒。
序列拉長至 64K 時受 Attention $O(N^2)$ 計算拖累，Prefill 速率下滑至 112.6 tok/s。
ROCmFPX + DFlash2：
採用對齊 RDNA 3.5 向量暫存器的對稱 FP4 算子，權重壓縮至 13.75 GB。
結合 Block-Diffusion Drafter（1.1 GB Draft 檔），單路解碼達 45.7～46.8 tok/s。
64K～128K 超長文本預填充表現最佳（128K 達 189.6 tok/s），在長序列深度下保持約 2 倍推測加速。

6. 總結

DFlash2 在保持單路 Decode 峰值吞吐（~46 tok/s）的同時，實現了更高接受率、超長序列 Prefill 提速 26%、Draft 模型減重 500 MB、以及 32K+ 深度不衰減的全面優勢。

單人極限吞吐 / 超長文分析（>32K）：選用 ROCmFPX + DFlash2。單路輸出達 46+ tok/s，64K Prefill 速率領先其他組態 2.1～2.8 倍。
團隊高併發 / 多輪 Agent 工具調用：選用 SGLang (GPTQ)。依賴 Radix Tree 提示詞快取降低重覆 Prefill 開銷，搭配 Chunked Prefill 排程維持多路穩定響應。
Stock llama.cpp（非 Fork）：作為官方上游基準測試使用，不建議在 Strix Halo 產線環境作為主力推論引擎。

我用這小玩具測試是為了拋磚引玉，歡迎擁有更大SRAM的RX7900XTX 或是R9700的來試

抡锤者