抡锤者

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

dardeaw feng

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

dardeaw feng

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

dardeaw feng

@张光璞其實還好耶，這台很好玩呀，可以當服務器，zen5 16核32線超強，x86的docker生態又好，然後裝個steam搞個3A玩4K特效開中也跑得不錯，各種Comfy UI節點都可以搞來慢慢折騰，其實買這圖的就是可玩性不是生產力

一般要AI裝個MOE模型可以噴到80~90 Tokens，平常做通用agent服務、調度檔案、文件、上網爬文都可以過得去
是硬要跑27B dense模型才會變這樣，連雲端Flash服務器也知道要MOE+MTP，是Qwen3.8死不出一個35B A3B

dardeaw feng

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

dardeaw feng

留給機器思考，浪費時間，也不可能做到零錯誤
不如快點生出來快點測，早點發現問題繼續罵他個祖宗十八代
就跟圍棋下快棋一樣，高手落子快還是高手，資質不足給他再多時間依舊廢物

dardeaw feng

早先有發了一個帖子是講ROCmFP4的llama.cpp分支，有興趣的可以去參考
但更早之前我有試著在這台迷你主機配置過SGLang，我都是用Opencode內建MuseSpark 1.3免費版去做配置，全程沒有任何蛋疼過程

SGLang on AMD Ryzen AI Max+ 395（Strix Halo）部署與效能實測全記錄

實測平台：FEVM FAEX1（AMD Ryzen AI Max+ 395 / 64-128GB UMA / ROCm 7.2.4）
目標模型：Qwen3.8-27B（GPTQ-Int4 + MTP Heads）
架構定位：Linux 推論 Server（Fedora）提供 OpenAI 相容接口（:8081/v1），Windows 用戶端透過 OpenCode 遠端掛載。

1. 軟硬體環境與關鍵認知

1.1 硬體規格配置

項目	規格參數	架構限制與關鍵說明
APU	AMD Ryzen AI Max+ 395	`gfx1151`（Radeon 8060S，40 CU），ROCm 7.2.4
VRAM	68.7 GB（BIOS Carve 固定）	開機即鎖死，進入 OS 無法動態重劃。
Host RAM	62 GiB 實體記憶體 + 76 GiB Swap	UMA 共用同一實體記憶體池，Host 與 GPU 存在資源爭搶風險。
同機其他服務	`lemonade`（NPU 專屬）	監聽埠 `13305`，不佔用 GPU VRAM；`llama-router` 已停用。

️ 核心硬體認知（UMA 邊界限制）：
UMA 架構不等於「VRAM 不足時能無痛借用 Host RAM」。BIOS Carve-out 大小一旦決定即為硬上限，PyTorch 的裝置記憶體配置器（Device Malloc）無法溢出至 GTT。68.7 GB 是絕對硬上限，所有權重載入、KV Cache 與運算圖配置均以此邊界為基準。

1.2 軟體環境建置

SGLang 核心分支：專為 gfx1151 移植之社群 Fork（整合 gfx1151 架構補丁、C++20 編譯修正、MoE Kernel 修正，並順利通過 AOT sgl_kernel 編譯）。
Python 虛擬環境：獨立 Python 3.12 虛擬環境（Torch 2.14+rocm7.2、Triton 3.8.0），SGLang 採 Editable 模式安裝。
模型套件：Qwen3.8-27B GPTQ + MTP Heads（已修正 MTP Config，使 Draft Path 指向同層目錄）。

2. 產線定案啟動配置

2.1 一鍵啟動指令

#!/usr/bin/env bash
python3 -m sglang.launch_server \
  --port 8081 \
  --served-model-name qwen3.8-27b \
  --tp-size 1 \
  --quantization gptq \
  --kv-cache-dtype fp8_e4m3 \
  --dtype bfloat16 \
  --attention-backend triton \
  --context-length 262144 \
  --mem-fraction-static 0.55 \
  --max-running-requests 4 \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 5 \
  --speculative-eagle-topk 4 \
  --speculative-num-draft-tokens 8 \
  --default-chat-template-kwargs '{"enable_thinking": false}' \
  --tool-call-parser qwen3_coder \
  --sleep-on-idle

常駐機制：透過 systemd 服務常駐管理。
記憶體配額：模型權重＋靜態 KV Cache 佔用約 51 GB，預留 17 GB 作為動態請求與系統緩衝。

2.2 核心參數設計理由

參數設定	數值 / 選項	設定理由與技術依據
`--context-length`	`262144` (262K)	為超長歷史對話與程式碼庫預留天花板；64K 內載入耗時可接受。
`--mem-fraction-static`	`0.55`	安全防線。數值若再提高，權重＋動態 KV＋運算圖將直接擊穿 68 GB 邊界引發崩潰。
`--kv-cache-dtype`	`fp8_e4m3`	實測已驗證可用。KV 佔用空間直接減半，是 262K 極限上下文能夠落地的物理前提。
MTP 組合參數	`5 / 4 / 8`<br>
<br>(steps/topk/tokens)	針對 Code / JSON 場景最佳化，實測平均接受長度達 3.9～4.8 tokens，推測解碼增益顯著。
`--default-chat-template-kwargs`	`{"enable_thinking": false}`	Agent 與編程輔助場景不需要思考鏈，關閉可省去無效 Token 浪費並大幅降低延遲。
`--tool-call-parser`	`qwen3_coder`	若使用通用 `qwen` parser 會吞掉 Tool-call（經 `get_weather` 回歸測試驗證確定修復）。
`--max-running-requests`	`4`	實測 4 併發時 Decode 總吞吐達單路 2.2 倍，剛好壓榨滿 APU 頻寬；更大隻會增加排隊延遲。

3. 地雷導航與避坑指南（重大踩坑複盤）

避坑 1：嚴禁啟用 HiCache（Host 記憶體自毀死循環）

現象：設定 --hicache-size 20 鎖定 20 GB Host RAM，但在模型加載時 Host 端自身也需十數 GB 空間。
後果：62 GB 系統實體記憶體瞬時見底，觸發 Linux OOM-Killer 強制中斷，systemd 隨後重啟服務，陷入全機死循環卡死。
教訓：在 UMA 架構下，Host RAM 與 VRAM 實質為同一實體池，開啟 HiCache 等同於「左右手互搶記憶體」，嚴禁開啟。

避坑 2：Adaptive MTP 效益低且佔資源

現象：使用 --speculative-adaptive 會被底層強制設定 topk=1（與靜態 topk=4 互斥）。
A/B 實測對比：自適應模式為 20.9 tok/s，靜態配置則達到 21.4 tok/s。寬推測樹（Tree-based）的收益明確高於動態步數，且自適應模式冷啟動更慢、佔用更多 VRAM。

避坑 3：Quark AWQ MXFP4（safetensors）是硬體死路

現象：缺少 aiter 時拋出 NotImplementedError；編譯安裝 aiter 後，源碼中 is_fp4_avail() 白名單明確僅支援 gfx950 與 gfx1250。
本質：gfx1151 晶片層面缺乏硬體級 FP4 WMMA 張量指令，任何純軟體模擬方案皆無法繞過此物理限制。

避坑 4：連接埠與顯存互斥衝突

規範：連接埠 8080 保留給 llama 生態，SGLang 獨佔 8081。
維護原則：切換推論引擎前，必須先停止另一側服務，並透過 rocm-smi 確認 VRAM 佔用從 41GB～51GB 徹底回落至基準狀態（約 0.6 GB）。

4. 效能實測數據（代碼／JSON 密集場景）

測試基準：全部輸入與輸出均為 Code / JSON 格式，數據取自 API 返回之精確 usage 欄位。

4.1 Prefix Cache 命中效益（6K Prompt）

測試情境	首字延遲（TTFT）	效益解析
冷啟動預填充（Cold Prefill）	17 ～ 68 秒	需完整計算 Attention 矩陣與權重解包
完整重複 Prompt（Cache Hit）	~ 1 秒	透過 Radix Tree 秒級載入，幾乎免去重複運算

4.2 MTP 推測解碼接受率（Server Log 統計）

運作配置：靜態 topk=4（現行定案）
平均接受長度（Accept Length）：3.9 ～ 4.8 tokens
整體接受率（Accept Rate）：0.41 ～ 0.55

4.3 單併發 Prefill 吞吐階梯（2K → 64K）

Prefill 速率變化 (tok/s)
  600 |
  500 |             [4K 峰值: 504.4]
  400 |     [2K: 369.7]     [8K: 390.1]
  300 |                             [16K: 266.2]
  200 |                                             [32K: 140.2]
  100 |                                                             [64K: 112.6]
    0 +-------------------------------------------------------------------------
      0      8K     16K     24K     32K     40K     48K     56K     64K

上下文長度	SGLang 預填充速率	實測 Wall 耗時	運算狀態與架構特性分析
2,000 (~2K)	369.7 tok/s	6 秒	初始階段，計算核心利用率逐步爬升
4,000 (~4K)	504.4 tok/s	8 秒	效能甜蜜點，GEMM 矩陣計算達到完全飽和
8,000 (~8K)	390.1 tok/s	22 秒	開始受限於注意力機制運算負擔
16,000 (~16K)	266.2 tok/s	61 秒	序列拉長，記憶體搬運開銷逐步主導
32,000 (~32K)	140.2 tok/s	233 秒	Attention $O(N^2)$ 計算特性導致速率明顯下滑
64,000 (~64K)	112.6 tok/s	580 秒	載入需近 10 分鐘，長文本必須依賴 Prefix Cache 攤平開銷

4.4 生成吞吐（Decode）與高併發壓力測試

單併發解碼（256 Tokens 生成，代碼情境）

SGLang 單路輸出：28.9 tok/s
(備註：常規散文寫作約 ~21 tok/s；程式碼的高結構性與重複語法使 MTP 享受到顯著的猜測紅利)

高併發擴展（Concurrency = 4）

測試指標	實測總吞吐	併發擴展效益分析
Prefill 4 路總量（10.5K × 4）	307.2 tok/s	高於單路長文本速率，Chunked Prefill 機制排程發揮成效
Decode 4 路總量（256 × 4）	63.3 tok/s	達到單路吞吐的 2.2 倍，APU 記憶體頻寬在此完全飽和

5. 推論引擎對決：SGLang (GPTQ) vs. ROCmFP4 (llama.cpp Fork)

對照組環境：
ROCmFPX Fork（自訂 GGML Type 100–106，Strix 專用解量化路徑）＋ Qwen3.8-27B Q4_0_ROCMFP4（13.7 GB）＋ MTP Draft，Context 131072。

評測維度	SGLang (GPTQ + FP8 KV + MTP)	ROCmFP4 (llama.cpp Fork + MTP)	核心差異與架構優劣總結
Prefill 峰值	504.4 tok/s（4K 達成）	437.7 tok/s（16K 達成）	SGLang 在中短 Prompt 依賴 Triton Kernel 算力飽和度更高。
Prefill 64K 長文	112.6 tok/s（580 秒）	240.2 tok/s（272 秒）	ROCmFP4 快 2.1 倍；llama.cpp 的 C++ 原生分塊對超長文本搬運耗損更低。
Prefill 4 路併發	307.2 tok/s（併發不崩）	259.3 tok/s（低於單路）	SGLang 的 Chunked Prefill 排程極佳；llama.cpp 會出現排隊阻滯。
單路 Decode	28.9 tok/s	29.0 ～ 44.0 tok/s	ROCmFP4 領先約 50%；純 C++ 與專屬對稱微區塊使逐字搬運延遲更低。
4 路 Decode 總量	63.3 tok/s	62.0 tok/s	兩者打平；均撞上 APU 實體 256-bit 記憶體頻寬物理天花板。
磁碟與顯存模型體積	~19 GB	~14 GB	ROCmFP4 具備更極致的減重優勢，可省下約 5 GB 實體空間。

6. 一句話決策總結

選用 SGLang (GPTQ + MTP)：適合 高併發多人調用、多輪 Agent 密集對話，依賴其強大的 Radix Prefix Cache、Chunked Prefill 與成熟的 OpenAI API 生態。
選用 ROCmFP4 (llama.cpp Fork)：適合 單人極限吞吐、超長文一次性分析（>32K），可享有快 2.1 倍的長文本預填充與高達 40+ tok/s 的單路打字機極速。

SGLang最大的好處無非就是Radix Tree
相比llama.cpp的slot cache，Radix tree的token級快取還是比較細膩，多對話還可以更節省KV Cache
但SGLang缺點也是很明顯....就是肥，要不是我有這大VRAM玩具，不然本地部屬單人使用還是llama.cpp為主就夠了
以這主機來說，算力、帶寬、生態等瓶頸就擺在那，真的要強求高併發並不是它設計的場景，
如果有想要以AMD平台設置推論引擎應該還是預先裝llama.cpp能玩廣大的通用gguf再說，各位參考

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卡的差距如何。

抡锤者

dardeaw feng

帖子