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 主機硬體與系統配置

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 測試模型權重清單

# 下載官方 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 啟動參數差異：

1. 調整為 --spec-type draft-dflash。
2. --model-draft 指向 DFlash2 權重檔。
3. 移除 --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）

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

4.2 Prefill 七階梯次吞吐測試

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

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

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

技術迭代本質：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。

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

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

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

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

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的來試