單張R9700 AI PRO 32G + VLLM + amd/Qwen3.8-27B-Quark-AWQ-MXFP4

[paul hou]

電費，設備，預算，使用情境，老婆的臉色，目前只支持一張R9700。

[zhenyu huang]

@paul-hou profill速度怎么那么快 是因为量化等级小吗

[zhenyu huang]

还是前缀缓存命中了？

[paul hou]

不確定是dflash2有加快，還是整個vllm設定和amd自己量化的模型有特別的優化，過程中裝了三種vllm，確實另外二個就是1200左右的prefill，decode 還有慢到只有15左右的。

今天整天用下來比之前用vulkan + Q6或Q4快很多，不過2併發的編程就不用想了，run2只能做很簡單的小事，不然會整體拖慢速度。

[kos or]

@paul-hou said:

2,319 tok/s

Prefill 這速度讓人訝異, 難道是 MXFP4 + DFlas2-FP8 有神奇效果

[paul hou]

@kos-or 有測試內建的MTP，結果就是9xx的prefill，30左右的decode，看來真的跟dflash2有關了。

[paul hou]

讓HERMES寫的報告

vLLM + Qwen3.8-27B-Quark-AWQ-MXFP4 安裝與測試報告

報告日期：2026-09-06　硬體：AMD Radeon AI PRO R9700（RDNA4 / gfx1201 / 32GB VRAM）　容器：vllm-radiance-mxfp4（magiccodingman/vllm-radiance:1.0.15）　服務位址：0.0.0.0:8080

本報告完整記錄在 R9700 上部署 vLLM 並服務 amd/Qwen3.8-27B-Quark-AWQ-MXFP4 模型的整個過程：環境決策、安裝步驟、啟動配置、啟動時間軸、功能驗證、效能基準測試、各種調優實驗的對比結果，以及踩過的坑與最終結論。

1. 背景與決策

目標：在本機 R9700 上以 vLLM 服務 Qwen3.8-27B 的 Quark MXFP4 量化模型（amd/Qwen3.8-27B-Quark-AWQ-MXFP4），並搭配推測解碼（speculative decoding）提升 decode 速度。

關鍵決策：RDNA4（gfx1201）沒有原生 MXFP4 運算單元，通用 rocm/vllm 映像會退回「模擬反量化」（BF16 高精度計算），速度落後 3-5 倍。因此本部署採用社群 fork vllm-radiance（magiccodingman/vllm-radiance:1.0.15，源自 codeberg.org/ggz14/radiance-vllm-mxfp4），它為 gfx1201 實作了原生 MXFP4 W4A8 kernel（RadianceMxfp4W4A8LinearKernel）與 R4D attention 後端。啟動後日誌確認快取路徑全部生效：

• Using RadianceMxfp4W4A8LinearKernel for MXFP4 GEMM（W4A8 fp8-WMMA GEMM 啟用）
• [radiance] R4D kernel selection: libr4d 全部 query 解析成功
• [radiance.gdn] all-R4D prefill / decode(fused) / prefill+spec path live
• [radiance] int2 draft head armed（dflash 推測解碼堆疊就緒）

注意：啟動日誌中出現「The current platform does not support native MXFP4/MXFP6 computation」一行是 quark 模組另一支 supports_mx() 呼叫的誤報（上游 repo 文件已註明），不代表 MXFP4 kernel 未啟用；真實狀態以上述 RadianceMxfp4W4A8LinearKernel 行為為準。

2. 環境

項目	值
主機	CachyOS Linux，192.168.1.241
GPU	AMD Radeon AI PRO R9700（RDNA4 / gfx1201 / 32GB VRAM）
容器映像	magiccodingman/vllm-radiance:1.0.15（vLLM 0.28.0 / Python 3.12 / ROCm）
容器名稱	vllm-radiance-mxfp4（2026-09-06 02:19 建立）
主模型	amd/Qwen3.8-27B-Quark-AWQ-MXFP4（19GB，arch qwen3_5，quant_method=quark）
推測解碼 drafter	tcclaviger/Qwen3.8-27B-DFlash2-FP8（2GB，FP8，block 128）
模型存放	/mnt/NVME/qwen38-27b-R9700/models/（bind mount → 容器 /models:ro）
快取目錄	/mnt/NVME/qwen38-27b-R9700/vllm-cache/mxfp4（Triton / inductor / aiter 快取）
啟動腳本	~/vllm-start（start|stop|status|logs）
下游	Open WebUI（8080 串接）+ DSH 使用同一端點
VRAM 使用	34.03 / 34.2 GB（gpu-memory-utilization 0.98 預留，屬正常）

模型權重檢查：config.json 的 quantization_config.quant_method 為 quark、algo_config 為 null（mapper 相容性要求，見第 6 節坑 1）；checkpoint 18.44 GiB 單一 safetensors 檔；config.json 保留 config.json.orig_with_algo_config 備份。

3. 安裝步驟

1. 準備 NVMe 目錄：/mnt/NVME/qwen38-27b-R9700/ 下建立 models/、vllm-cache/、ggz14-mxfp4/（radiance repo 的 git clone，含 patches 與 chat template）。
2. 下載主模型 amd/Qwen3.8-27B-Quark-AWQ-MXFP4（19GB）與 drafter tcclaviger/Qwen3.8-27B-DFlash2-FP8（2GB）到 models/ 下。
3. 拉取映像 magiccodingman/vllm-radiance:1.0.15（映像已內建 ROCm、vLLM 0.28.0、libr4d 與 repo patches，無需自建 Dockerfile）。
4. 準備 chat template：ggz14-mxfp4/qwen-fixed-v22.3.jinja（reasoning_effort → Qwen think 控制 token 的映射），以唯讀方式 bind 進容器。
5. 撰寫 ~/vllm-start 啟動腳本（docker run 全參數 + 約 60 個 RADIANCE_* 環境變數），作為唯一權威啟動器（repo 內舊 start-mxfp4.sh 已於 2026-09 刪除，避免誤用過期設定）。
6. 啟動容器：掛載 /dev/kfd、/dev/dri，模型唯讀掛載，快取目錄持久化，端口 0.0.0.0:8080 → 8080。
7. 驗證：/v1/models 回傳 qwen3.8-27b-mxfp4（max_model_len 163840）；/v1/chat/completions 冒煙測試成功。

4. 啟動配置

vllm serve 關鍵參數（來自 ~/vllm-start，可調變數在腳本頭部）：

參數	值	說明
--kv-cache-dtype	fp8	FP8 KV cache，容量翻倍（需顯式指定，非預設）
--gpu-memory-utilization	0.98	VRAM 預留比例
--kv-cache-memory	7783339733 (7.25 GiB)	顯式 KV 預算，優先於 gpu-memory-utilization
--max-num-seqs	8	短 ctx 爆發用；長 agent 情境建議 2-4
--max-model-len	163840	避免 repo 預設 262144 引發 FLA-GDN OOM
--max-num-batched-tokens	8192	調高至 16384 曾 OOM（見第 6 節坑 5），已固定
--attention-backend	R4D	radiance 原生 R4D attention（僅支援 GQA=6）
--enable-prefix-caching	（啟用）	前綴快取；實測 hit rate 可達 91%
--speculative-config	dflash, spec tokens=7, TRITON_ATTN	DFlash2 FP8 drafter，7 為 block_size 8 的硬上限
--no-async-scheduling	（同步調度）	調優穩定配置；A/B 測試顯示無效能差異（見第 5.4）
--enable-auto-tool-choice + --tool-call-parser	qwen3_xml	工具呼叫解析
--reasoning-parser	qwen3	思考解析（讀 enable_thinking）
--override-generation-config	temp 0.7 / top_p 0.95 / top_k 20	預設採樣參數
--enable-per-request-metrics	（啟用）	基準測試所需的 per-request 直方圖
--chat-template	/chat-template.jinja	reasoning_effort 映射模板
--language-model-only	（啟用）	略過 VLM vision tower
--tensor-parallel-size	1	單卡
環境變數（節選）	RADIANCE_MXFP4=1, W4A8, FAST_DRAFT, DYNAMIC_WIDTH=1, DYNAMIC_DRAFT=1 (schedule 1:8,2:7,4:6,8:5,16:4), DRAFT_TAU=0.20, DRAFT_RERANK=80, USE_R4D=1, GDN 融合系列=1, R4D_ATTN_FP8=0, HF_HUB_OFFLINE=1	完整清單見 ~/vllm-start

5. 測試

5.1 啟動時間軸（2026-09-06 實測）

階段	時間（容器內）	備註
容器啟動	02:19:27	docker run -d
引擎初始化	02:21:04	V1 LLM engine v0.28.0，spec config dflash/spec=7
主模型權重載入	02:21:06 → 02:21:22	18.44 GiB，15.64 秒
drafter 權重載入	02:21:24	1.20 秒
KV cache 配置	02:21:33	180,098 tokens；163,840 ctx 下最大並發 1.10x
CUDA graph 捕獲	02:21:33 → 02:21:37	PIECEWISE 19 組 + FULL 8 組 + dflash2 8 組
API server 就緒	02:22:42	Application startup complete
總耗時	約 3 分 15 秒	權重載入 15.6s 為主

5.2 功能驗證

• /v1/models：回傳 qwen3.8-27b-mxfp4，max_model_len=163840。
• /v1/chat/completions 冒煙測試：「1+1 等於幾？」→「1+1 等於 2。」，usage 正常（含 reasoning_tokens 統計）。
• 推測解碼健康：SpecDecoding 指標持續輸出，平均接受長度 2.8-3.0，draft 接受率 26-29%（生產負載下）。
• 前綴快取：多輪對話 hit rate 達 91.2%。
• Open WebUI 串接 8080 正常（容器 healthy）。
• VRAM 34.03/34.2 GB 為 0.98 預留設計，非洩漏；分配：權重 19GB + drafter 2GB + KV 7.25GB + 約 6GB workspace。

5.3 基準測試方法

基準協議（~/vllm-bench.py [並發數] [max_tokens] [tag]）：固定長 prompt（約 4K tokens 中文段落 x80），N 個相同請求並發，於請求前後對 /metrics 做 delta 取樣：prefill = Δprompt_tokens / Δprefill_time；decode = 1 / ΔTPOT；e2e = Δtokens / Δwall；接受率 = Δaccepted / Δdraft。注意兩點陷阱：(1) 指標是累計值，A/B 比較必須取 delta 或重啟容器重置；(2) 極短 prompt 會低估 prefill（固定開銷主導），必須用長 prompt。

5.4 調優實驗結果

實驗 1 — spec tokens 數（8 並發 / 4K prompt / 128 out，delta 取樣）：

指標	spec=7（採用）	spec=5
decode（1/TPOT）	67.1 tok/s	60.6 tok/s
e2e（含 prefill）	181 tok/s	162 tok/s
prefill	2235 tok/s	1747 tok/s
accepted / draft	2.96	2.52
接受率	42.2%	50.5%

結論：不能只看接受率——spec=5 單位接受率較高但每步 draft 位置較少，有效吞吐量反而輸。spec=7 全面勝利，為最終配置。

實驗 2 — 原生 MTP 頭 vs dflash drafter（8 並發 / 4.2K prompt / greedy / 128 out）：

指標	MTP spec=3	MTP spec=5	dflash2 spec=7（基準）
decode（1/TPOT）	23.7 tok/s	23.9 tok/s	67.1 tok/s
e2e 吞吐量	82.4 tok/s	55.6 tok/s	181 tok/s
prefill	897 tok/s	913 tok/s	2235 tok/s
draft 接受率	74.7%	59.4%	42.2%

結論：MTP 能跑（Qwen3_5MTP 架構解析成功，需 RADIANCE_QUARK_BF16_MTP=1 讓 BF16 的 mtp.fc 繞過 Quark recipe），但 1 層 MTP 頭每步自回歸跑 N 次，spec 越多浪費越多——比 dflash2 慢約 2.8 倍 decode、2-3 倍 e2e。保留 dflash2 @ spec=7；MTP 僅在需要零外部 drafter 佔用時使用。另 MTP spec=5 在此 KV 預算下無法開機（需要 7.32 GiB > 7.25 可用），spec>=4 需降 max_model_len 至 160000。

實驗 3 — async vs sync 調度（2 並發 / 4K / 128 out）：e2e 49.2 vs 49.7、prefill 4330 vs 4366、decode 44.4 vs 44.7、接受率 29.6% vs 29.6%——無可測量差異（先前「async 損失 5-10% decode」的說法未重現；首次 async 跑的 35 tok/s 是 Triton JIT 冷啟動）。維持 --no-async-scheduling。

實驗 4 — 對照上游 repo 預設（ggz14 serve-mxfp4.sh）：R4D_ATTN_FP8=0 vs 3 效能相同（e2e 46.9/52.9 vs 46.9/57.9，±10% 為 run-to-run 噪音）；GDN fused decode 的 triton fallback 只是 1.0.15 映像層級問題（torch.ops._C.fused_gdn_decode_post_conv_mtp 未編入），非環境變數可修，是相對於 repo 融合路徑的主要 decode 效能差距。其餘參數（TP=1、KV 7.25 GiB、163840、SANITIZE=1、DRAFT_TAU=0.20）皆合理。

實驗 5 — 新增 Quark 模型的兩個坑（Fable / Qwen3.6 MoE 實測）：(1) algo_config 非 null 會使 Quark mapper 崩潰（AttributeError: 'dict' object has no attribute 'endswith'），須在 config.json 設為 null（純 mapper 相容欄位，不影響權重品質）；(2) R4D 後端寫死 GQA=6，GQA=8 的 MoE 模型須改用 TRITON_ATTN 並關閉 R4D 環境變數。另：MoE 量化模型（Qwen3.6-35B-A3B）在此映像走 on-the-fly 反量化，decode 僅 5.8 tok/s，比 dense 27B+dflash 慢 4-8 倍，已移除不保留。

實驗 6 — reasoning_effort 行為（模板映射實測）：off→0 思考 token；low→約 49；high→150（吃光輸出預算，對 agent 危險）；max→約 91（反直覺地比 high 少）。模型實際上是 ON/OFF 思考，agent 負載建議 low。注意：把 reasoning_effort 加進 --override-generation-config 無效（不在 available_params 會被靜默丟棄），正確做法是改 chat template 預設值。

5.5 生產負載實測（2026-09-06 07:34 日誌）

指標	值
prompt 吞吐量	454.0 tok/s（長 prompt 請求中）
generation 吞吐量	20.5 - 44.7 tok/s（隨請求類型）
平均接受長度	2.83 - 3.04
draft 接受率	26.1% - 29.2%
KV cache 使用	33.4% - 34.5%
前綴快取 hit rate	91.2%

6. 踩過的坑（按嚴重度）

1. Quark algo_config 崩潰：config.json 的 quantization_config.algo_config 若非 null，vLLM Quark mapper 在 apply_vllm_mapper 拋 AttributeError（dict 項目被當字串 .endswith 檢查）。修法：設為 null 再重新載入。症狀是引擎在 init 前退出，根因不是 KV/OOM，別先調 163840/FP8。
2. R4D 後端僅支援 GQA=6：GQA=8 的模型（如 Qwen3.6 MoE）直接 NotImplementedError，須改 TRITON_ATTN 並關 R4D 環境變數。
3. spec tokens > 7 開機失敗：dflash2 的 draft window 為 8 x (n+1)，n=10 時 torch.compile 把該維度特化為常數 88 而標記為 DYNAMIC，torch.fx ConstraintViolationError 使 EngineCore 崩潰。spec=7 是硬上限，清快取重編也無解，須改回 7。
4. INT4 drafter 無法載入：syvai 的 W4A16 版本是 Marlin pack 量化，linear 權重住在 packed buffer，radiance DFlash loader 要求 dense .weight → AttributeError: 'QKVParallelLinear' object has no attribute 'weight'。需改源碼，維持 tcclaviger FP8。
5. MAX_BATCHED_TOKENS 調高 OOM：8192→16384 使 activation/workspace 峰值翻倍，在 32GB（權重 19 + KV 7.25 已鎖定）下長 prompt prefill 時 torch.OutOfMemoryError（嘗試分配 860 MiB，0 bytes free）。已回退 8192；要重試須先縮 KV_MEM。
6. MTP spec>=4 KV 不足：spec=5 需 7.32 GiB KV > 7.25 可用，engine-init 失敗；spec>=4 須降 max_model_len 至 160000。
7. /metrics 解析陷阱：prometheus 行格式是 name{labels} value，用「名稱+空白」匹配會全部回 0，bench 看似「什麼都沒跑」；要匹配 name{ 或名稱+空白。
8. sed 刪 --no-async-scheduling 行會吃掉行尾反斜線，docker run 參數列提前結束；必須整行刪除（sed '/--no-async-scheduling/d'）。
9. FP8 KV 未校準：checkpoint 無 q/k scale，vLLM 用 1.0 裸存（log 有 warning）；對 27B 推理可接受，但別當已校準 FP8 看待。
10. 「平台不支援原生 MXFP4」日誌為誤報：以 RadianceMxfp4W4A8LinearKernel 行確認真實 kernel 狀態，勿據此判斷 kernel 未啟用。

7. 結論

• 部署成功：vllm-radiance 1.0.15 + amd/Qwen3.8-27B-Quark-AWQ-MXFP4 + DFlash2 FP8 drafter（spec=7）在 R9700 穩定服務於 8080，啟動總耗時約 3 分 15 秒。
• 基準效能（8 並發 / 4K prompt / 128 out）：e2e 約 47-58 tok/s（spec=7 多請求 delta 實測 181 tok/s）、prefill 約 2000-2300 tok/s、decode 19-23 tok/s（生產負載 20-45 tok/s）、接受率 26-42%。
• 關鍵配置：KV FP8 顯式指定 + 7.25 GiB 顯式預算、max_model_len 163840、batched tokens 8192、R4D attention、同步調度、dflash spec=7。
• 已驗證排除的方案：原生 MTP（慢 2.8 倍）、INT4 drafter（無法載入）、MoE 量化模型（慢 4-8 倍）、async 調度（無收益）、batched tokens 16384（OOM）。
• 已知殘留差距：1.0.15 映像的 GDN 純 decode 步驟走 Triton 未融合路徑（映像層級，需換映像才能修）。
• KV 預算現實：180,098 tokens 約等於 1 個 163K 長請求或 8 個 <22K 短請求；agent 長多輪情境建議 max_num_seqs 2-4。

[Jun]

好快 我的天 已參考 謝謝

[paul hou]

再提供一個GITHUB，這個的各項數據都跟我測試的差不多，也是使用同一個VLLM。
還要再看看他的設定有什麼可以參考。
https://github.com/zzpanic/qwen3.6-vllm-gfx1201-launchers

*補充說明，我有限制GPU的功率在210W，這有可能是我的測試數據會比網上的差一點，我還要讓HERMES去分析看看。

[AGI]

7900xtx的prefill只有600左右，这个这么猛？

[paul hou]

@AGI
在DSH中跑起來是真的滿猛的，新會話都是3秒會開始動作llama.cpp大概是13~15秒，跑個5M左右的輸入，底下顯示的TOKEN數都有還有60左右。llama.cpp大多在40左右。

HERMES分析是GITHUB中的是TDP 350W的數據，我210W這數據是正常的。差別在我沒開ASYNC，我有把併發數限制在2，不需要開ASYNC。

抄作業測試中

1. KV_MEM 7,783,339,733 → 9,300,000,000（8.66 GiB pin）
2. MAX_MODEL_LEN 163,840 → 204,800
3. MAX_BATCHED_TOKENS 8,192 → 2,048
4. speculative-config 加 "draft_sample_method":"probabilistic"
5. start() 開頭加 gc_orphans（檢視孤立 radiance container + 清無持有者的 shm + 快取暫存檔）

照GITHUB的設定跑看看。

[Xiaote]

@AGI 别只看 prefill 一个数就下结论，prefill 和 decode 是两个完全不同的瓶颈：

• prefill（读整段 prompt）是算力密集。RDNA 系 FP16/FP8 峰值算力其实不低，所以 prefill 都能跑到几百上千 token/s；paul 这堆 radiance 优化旗标（SKINNY_GEMM、R4D attention、WPERM、HOIST_QUANT）是把 prefill 进一步往上顶的。输入越长、优化越足，prefill 越快，首 token 延迟自然就低。
• decode（逐 token 吐字）才是带宽密集，也是 AMD 卡真正的短板。带宽就摆在那，单流 decode 大概 40-60 token/s 这个量级，和你看到的一致。

所以「prefill 猛」≠「整机猛」：prefill 决定首 token 延迟（agent 场景短请求多，这边快体验明显好），decode 决定连续输出速度（长生成、大上下文就露馅）。paul 这方案的价值恰恰是把 prefill 顶上去再加长上下文撑住——这正是 agent 场景该发力的方向。

[paul hou]

@linghu007
MAX_BATCHED_TOKENS 8,192 → 2,048

這個參數可以多出不少VRAM，設成2048後我的上下文總數是246K。

[paul hou]

MAX_BATCHED_TOKENS 8,192 → 2,048
上下文調到了246K

以下是DSH的測試

模型速度測試報告：Prefill / Decode Throughput

模型與環境

• 模型：qwen3.8-27b-mxfp4
• 推理引擎：vLLM
• 端點：http://192.168.1.241:8080/v1（OpenAI 相容 API）
• 並行度：batch = 1（單序列測量）
• max_model_len：204,800

量測方法

• 使用 SSE 串流逐 chunk 記時。
• Prefill 速度 = prompt_tokens / TTFT（TTFT = 第一個 token chunk 的時間點）。
• Decode 速度 = completion_tokens / (total_time − TTFT)。
• Prefill 使用隨機文本，避免 vLLM prefix-cache 命中，量測「冷啟動」速率。
• 溫度 temperature = 0。

---

Prefill 結果（input tokens/s，冷啟動、無快取）

目標	實際 prompt tokens	TTFT (s)	Prefill 速度 (tok/s)
2,048	3,672	1.571	2,337
4,096	7,319	3.317	2,206
8,192	14,538	6.829	2,129
16,384	29,010	14.484	2,003
32,768	57,836	32.634	1,772
65,536	115,711	80.468	1,438

備註：因隨機單詞 token 化較密，實際 prompt tokens 比目標大；此處以實際 token 數計算。

觀察：短上下文約 2.3K tok/s，隨 context 變長因 attention / KV 二次成本遞減至 ~1.4K tok/s（115K tokens），符合預期。

---

Decode 結果（輸出 tokens/s，穩態）

任務	total tokens	content tokens	生成時間 (s)	吞吐 (tok/s)	中位間隔 (ms/token，間隔 content)
列 1..800	3,127	387	24.472	127.8	62.4
重複句子 ×200	4,096（觸頂）	507	32.256	127.0	62.7

觀察：穩態 ~127 tok/s（約 7.9 ms/token，全部 token 基準）。

---

重點發現與注意事項

1. Reasoning / thinking token 佔主流

   • 即使 agent 設定 reasoningEffort: off，vLLM 端點仍輸出大量 reasoning token。
   • 例：列數任務 3,127 個 total 中，僅 387 個是 content，其餘 ~2,740 個是思考 token。
   • 因此 127 tok/s 是「全部 token」的真實吐速；純 content 的出現節奏僅 ~16/s（中位 62ms/個），是因為思考 token 在間隔，並非模型變慢。

2. batch=1 的單序列速度

   • 127 tok/s 是單序列（單個 request）的 decode 速度。
   • vLLM 使用 continuous batching，實際聚合吞吐量在多併發下會更高。

3. Prefill 為冷啟動數字

   • 重複同一 prompt 會命中 vLLM prefix cache，TTFT 會更快、prefill 速度看起來更高。

4. 小 prompt 的 TTFT 含固定開銷

   • 排程 / 首 token 開銷使極短 prompt 的 TTFT 偏高，不代表真實 prefill 速率（以 3.7K 以上那組為準）。

---

總結

指標	結果
Prefill（冷啟動）	短 context ~2,337 tok/s，115K context ~1,438 tok/s
Decode（穩態、batch=1）	~127 tok/s（約 7.9 ms/token，全部 token 基準）

[nami ryuu]

@paul-hou 这个方法理论上支持双卡吗？双卡的话会更快吧？

[paul hou]

@nami-ryuu

https://github.com/magiccodingman/vllm-radiance

這個就是雙卡的DECODE效能看起來就是X1.8左右。
不過，雙卡研究SGLANG比較香吧。