單張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比較香吧。

[陳野狼]

@paul-hou

請問一下我只要開 MRV2(VLLM_USE_V2_MODEL_RUNNER) 待機 GPU 100% 瓦數 70W 但是測速等等都正常
(CPU也會100% 加HSA_TOOLS_DISABLE_REGISTER=1 就解決CPU 100%)
待機 GPU 100%是正常的嗎????
沒開MRV2 待機 GPU 0% 瓦數 12W

MRV2	DFlash	Async	Idle GFX
OFF	OFF	任意	0%
ON	OFF	ON/OFF	100%
ON	ON	任意	100%

240 W vllm-radiance DFLASH2

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	1936.29 ± 0.00		47053.08 ± 0.00	47051.81 ± 0.00	47056.48 ± 0.00
qwen3.8-27b-mxfp4	tg128 @ d100000	61.57 ± 0.00	69.00 ± 0.00

240 W vllm-radiance

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	1927.44 ± 0.00		47275.50 ± 0.00	47274.08 ± 0.00	47275.50 ± 0.00
qwen3.8-27b-mxfp4	tg128 @ d100000	18.48 ± 0.00	19.00 ± 0.00

.env 如下
IMAGE=magiccodingman/vllm-radiance:latest
MODELS=/home/mark/models
VLLM_CACHE=./vllm-cache
PORT=8090

TP=1
HIP_VISIBLE_DEVICES=0
GPU_UTIL=0.98

MODEL_PATH=/models/Qwen3.8-27B-MXFP4-mtpfp8
SERVED_MODEL_NAME=qwen3.8-27b-mxfp4
WEIGHT_QUANTIZATION=auto

KV_CACHE_DTYPE=fp8
MAX_MODEL_LEN=131072
MAX_NUM_SEQS=8
MAX_NUM_BATCHED_TOKENS=8192
MAMBA_CACHE_MODE=align

RADIANCE_MXFP4=1
RADIANCE_MXFP4_W4A8=1
RADIANCE_MXFP4_W4A8_MIN_M=0
RADIANCE_MXFP4_DECODE_MAX_M=64
RADIANCE_MXFP4_TN4_MIN_M=2048
RADIANCE_MXFP4_WPERM=1
RADIANCE_MXFP4_DECODE_NT=1

RADIANCE_HOIST_QUANT=1
RADIANCE_EPIFAST=1
RADIANCE_SKINNY_GEMM=1

ATTENTION_BACKEND=R4D
RADIANCE_USE_R4D_GDN=1
RADIANCE_USE_R4D_AR=1
RADIANCE_USE_R4D_AR_QUANT=1

AITER_UNIFIED_ATTENTION=1
AITER_EXTRA_MHA=0
AITER_EXTRA_MOE=0
AITER_EXTRA_MLA=0
AITER_EXTRA_RMSNORM=0
AITER_EXTRA_FP4BMM=0
AITER_EXTRA_FP8BMM=0

VLLM_USE_V2_MODEL_RUNNER=1
RADIANCE_COMPILATION_CONFIG='{"cudagraph_mode":"PIECEWISE"}'
RADIANCE_FAST_DRAFT=1
RADIANCE_SPECULATIVE_CONFIG='{"method":"dflash","model":"/models/Qwen3.8-27B-DFlash2-FP8","num_speculative_tokens":7,"draft_tensor_parallel_size":1,"attention_backend":"TRITON_ATTN","max_model_len":131072,"disable_padded_drafter_batch":true}'

[Xiaote]

@陳野狼 这个现象有上游记录，不是你配错了，先把「是否真在满载」这件事分开看。

判据：功耗是准的，util 不是。 你表里 70W 那档被报成 100% 但只有 70W；DFlash+Async 全开那档 240W。amdgpu/ROCm 下的「GPU 利用率」是「有没有活着的队列、有没有在提交工作」的粗略指标——进程挂着设备、队列不进 idle，它就一直是 100%。所以 70W 的 100% 不等于满载，240W 那档才是真在干活。

上游在同一条线上：

• vllm-project/vllm#41964：R9700(gfx1201) 上 EngineCore 线程空转 100% CPU（strace 全是 AMDKFD_IOC_WAIT_EVENTS 死循环）。vLLM 0.21.0 修掉了 CPU 那半边，但多个用户反馈「GPU 仍报 100%、待机 80–90W」这半边留了下来。
• 根因指向 ROCm/ROCm#5706（HSA/异步队列），同一现象在 llama.cpp 上也复现过（ggml-org/llama.cpp#20482）。所以位置在 ROCm 层，不在 vllm-radiance。

可以试的开关（社区实测有效）：
GPU_MAX_HW_QUEUES=1 —— 加进 docker compose 的 environment（systemd 就写 Environment=）。同一批报告里有人用 ROCBLAS_USE_HIPBLASLT=0 也能绕；还有 RDNA4 用户反馈这行顺带把 MTP 的性能回归修回来了（41 → 81 t/s），所以对你这种带 MTP/DFlash 的栈值得优先试。

你找到的 HSA_TOOLS_DISABLE_REGISTER=1 解决 CPU 100%，说明方向对了——那属于 HSA 忙等这一族，GPU 侧对应的就是上面那条。

要不要管？ 不影响正确性，代价只有两个：电费，以及进不了 GFXOFF 所以待机功耗降不下来。建议加了 env 之后把你那套 pp512/tg128 基准再跑一遍，确认没掉速再定留不留。

顺手记一下你这组数据：同配置 tg128，DFLASH2 开 61.57 关 18.48，3.3 倍，很有参考价值。

[nami ryuu]

@paul-hou 双卡，我问了hermes好像没有成熟的sglang方案可以用，没解决mtp，现在就是7900xtx论坛里有魔改方案。

[paul hou]

@陳野狼

我是有碰到CPU 100%的問題但沒有GUP 100%
GPU 的待機功耗ROCM比VULKAN高似乎是一直以來都是如此，所以就沒放在心上。
以下是我目前最新的設定，這個單請求上下文最大化的版本

vllm-start-8080-upstream 設定說明

來源腳本：/home/paul/vllm-start-8080-upstream
上游腳本：/mnt/NVME/qwen38-27b-R9700/ggz14-mxfp4-new/serve-mxfp4.sh（GGZ14/vllm-mxfp4 0.12.0）
更新：Launch80 / GGZ14，2026-09-08

以 GGZ14/vllm-mxfp4 0.12.0 上游 serve-mxfp4.sh 原樣啟動 Qwen3.8-27B native MXFP4（4-bit）
server（AMD RDNA4 gfx1201，FP8 speculative drafter，vllm-radiance 映像），僅加上「單卡承載覆蓋」。

1. 與舊 stack（~/vllm-start-8080）完全分離

項目	舊 stack（zzpanic launcher，單卡調校）	本腳本（upstream）
Repo	舊 repo	獨立 clone：/mnt/NVME/qwen38-27b-R9700/ggz14-mxfp4-new（0.12.0）
容器名	qwen38-27b-mxfp4-nv	qwen38-27b-mxfp4-upstream
torch.compile cache	舊目錄	明確指定 ~/.radiance-cache-w4a8-093-upstream（避免兩套 patch 集合共用同一 cache 互相覆蓋）
libr4d	舊 patch	新版 patch 含 rx6（ar_oneshot_3rank_exact），首次啟動自動預編譯

2. 用法

./vllm-start-8080-upstream          # 等同 start
./vllm-start-8080-upstream start    # 啟動（nohup 背景執行，log 見下）
./vllm-start-8080-upstream stop     # docker stop + rm 本容器
./vllm-start-8080-upstream status   # docker ps 過濾本容器
./vllm-start-8080-upstream logs     # docker logs --tail 200 -f

• Log 檔：/mnt/NVME/qwen38-27b-R9700/upstream-mxfp4-background.log
• 監聽：http://localhost:8080/v1

同埠／同卡互斥

啟動前會自動停掉舊 radiance 容器（不會並發）：

• vllm-radiance-mxfp4
• qwen38-27b-mxfp4
• qwen38-27b-mxfp4-nv

並 docker rm -f 掉舊的 qwen38-27b-mxfp4-upstream 容器。

3. 設定值總表

所有變數以環境變數形式傳入 serve-mxfp4.sh（上游腳本全部是 ${VAR:-default}，可隨時覆蓋）。

3.1 本腳本明確指定的值

變數	值	說明
REPO	/mnt/NVME/qwen38-27b-R9700/ggz14-mxfp4-new	0.12.0 獨立 repo clone
MODELS	/mnt/NVME/qwen38-27b-R9700/models	checkpoint 目錄（bind-mount 到 /models）
DRAFTER	/mnt/NVME/qwen38-27b-R9700/models/tcclaviger/Qwen3.8-27B-DFlash2-FP8	FP8 block-diffusion drafter（SPEC_METHOD=dflash 用）
PORT	8080	監聽埠
RUNTIME	docker	容器 runtime
NAME	qwen38-27b-mxfp4-upstream	容器名
CACHE	~/.radiance-cache-w4a8-093-upstream	獨立編譯 cache（見 §1）
EXTRA	--language-model-only	不載 vision tower（單卡覆蓋，見 §4）
MAXSEQS	1	最大並發 seq（單卡覆蓋）
MAXLEN	262144	最大 context 長度
KV_MEM	10600000000（≈ 9.87 GiB）	KV cache 顯式 pin（單卡覆蓋）
CHUNK	2048	prefill chunk / --max-num-batched-tokens（單卡覆蓋）
HSA_TOOLS_DISABLE_REGISTER	1	ROCm runtime knob：關閉 HSA tools（profiling/追蹤工具）對 runtime 的註冊攔截（需上游 serve-mxfp4.sh 的 pass-through，見 §7）

3.2 照上游預設的項目（未覆蓋）

項目	值
IMAGE	stilldeadcode/vllm-radiance:0.9.3（與舊 stack 同張映像；CACHE 對映像版本有 key 綁定，兩者要一起換）
R4D_PIN	b9e42ab（+ rx6 patch）
SPEC_METHOD / SPEC	dflash / 7
TP	自動偵測 → 本機單卡 = TP1
GPU_UTIL	0.98
FAST_DRAFT	1（int2 draft head + exact rerank）
RERANK	80
VHEAD / WPERM 等	上游預設

4. 單卡覆蓋的理由（為什麼不照上游預設）

上游預設（MAXSEQS=8 / MAXLEN=262144 / CHUNK=8192 / GPU_UTIL=0.98）是 2× R9700 TP2
的量：每卡只扛 9.4 GiB weights，KV 空間充裕。

單卡 32G 要載整顆 18.6 GiB weights，同設定下 vLLM 只給出 ~4.6 GiB KV，
而 262144 需要 9.61 GiB → 啟動直接掛：

ValueError: KV cache 9.61 GiB needed > 4.62 GiB available, est. max len 98880

因此覆蓋值 = 舊無視覺版（novision）在同一張卡上實證過的承載上限：

覆蓋	理由
EXTRA="--language-model-only"	不載 vision tower，省 ~0.9 GiB + encoder cache
MAXSEQS=1	單卡 262144 長上下文路線（9.61 GiB/滿 seq）
MAXLEN=262144	搭配 KV_MEM pin 10.6G > 9.61G 需求，冷／暖 boot 行為一致
KV_MEM=10600000000	顯式 pin，跳過 vLLM 保守 profiling（profile 只給 4.6G）
CHUNK=2048	上游 8192 的 activation 暫態太大：cudagraph capture 時 weights 18.6G + KV 9.87G 已吃掉 ~31G，8192 的暫態直接 OOM（實測）；2048 是舊版在同卡驗證過的峰值

想改走高並發短上下文：MAXSEQS=8 MAXLEN=90000 KV_MEM=auto

5. 啟動後驗證（看 log）

• "Using RadianceMxfp4W4A8LinearKernel for MXFP4 GEMM" → 自研 kernel 贏了選擇
• "[radiance] native MXFP4 enabled on gfx12x" → aiter fp4 gate 已放開
• R4D selections table（RADIANCE_R4D_REPORT=1）→ 哪些 kernel 被選中、為什麼
• 標準的 "current platform does not support native MXFP4/MXFP6" notice 仍會出現且是誤報
  （來自另一個 supports_mx() call），可忽略

6. 路徑總表

用途	路徑
啟動腳本	/home/paul/vllm-start-8080-upstream
Repo（0.12.0）	/mnt/NVME/qwen38-27b-R9700/ggz14-mxfp4-new
Checkpoints	/mnt/NVME/qwen38-27b-R9700/models
Drafter	/mnt/NVME/qwen38-27b-R9700/models/tcclaviger/Qwen3.8-27B-DFlash2-FP8
編譯 cache	~/.radiance-cache-w4a8-093-upstream
背景 log	/mnt/NVME/qwen38-27b-R9700/upstream-mxfp4-background.log

7. 對上游 serve-mxfp4.sh 的本地修改

上游的 docker 環境變數 pass-through 是固定清單（只有
HIP_FORCE_DEV_KERNARG / HSA_ENABLE_INTERRUPT / ROC_ACTIVE_WAIT_TIMEOUT
三個 ROCm knob 是「設定才傳」），HSA_TOOLS_DISABLE_REGISTER 不在其中。
因此在 repo clone 內做了最小修改（重clone 或升級 0.12.x 時需重新套用）：

1. pass-through（docker run 命令，緊接 ROC_ACTIVE_WAIT_TIMEOUT 之後）：

   ${HSA_TOOLS_DISABLE_REGISTER:+-e HSA_TOOLS_DISABLE_REGISTER="$HSA_TOOLS_DISABLE_REGISTER"} \
   

2. usage 說明：在 HIP_FORCE_DEV_KERNARG 那段 ROCm knobs 說明補上
   HSA_TOOLS_DISABLE_REGISTER=1 (off HSA tools registration)。

行為：只有在環境變數被設定時（本包裝腳本恆設為 1）才會傳進容器。

Qwen3.8-27B-MXFP4 本機效能測試報告

日期： 2026-09-10
硬體： AMD Radeon AI PRO R9700（32GB 顯示記憶體，gfx1201）
軟體： VLLM Radiance 0.9.3 + R4D 注意力機制 + DFlash2-FP8 投機解碼

設定

• 模型：Qwen3.8-27B-MXFP4（MXFP4 權重，FP8 KV cache）
• 注意力機制：R4D 後端
• 投機解碼：DFlash2-FP8（7 個投機 token，貪婪取樣）
• max_model_len：262144
• gpu_memory_utilization：0.98
• kv-cache-memory：10.6GB
• tensor-parallel-size：1

測試結果

測試項目	提示詞 Tokens	完成 Tokens	時間（秒）	速度（tok/s）
短文本創作（俳句）	17	128	2.20	58.3
中等分析（量子計算）	18	512	9.79	52.3
長篇 Essay（300 字歷史）	24	768	13.01	59.1
程式碼生成（快速排序）	19	512	6.48	79.0
推理模式開（數學題）	51	930	9.97	93.3
長上下文（100 字提示詞）	119	76	1.37	55.4
多輪對話	38	163	2.42	67.4

摘要

• 標準生成： 持續 ~55-60 tok/s
• 程式碼生成： ~79 tok/s（接受率較高）
• 推理模式： ~93 tok/s（長 CoT 攤薄 TTFT）
• TTFT： 短提示詞 1.4–2.2 秒
• 投機解碼： DFlash2-FP8 讓 27B 參數規模下 TTFT 維持在低水準

備註

• 關閉思考模式：透過 extra_body: {chat_template_kwargs: {enable_thinking: False}}
• 推理模式的回應會同時包含 reasoning 與 content 欄位
• 單卡 RDNA4 推理表現出色