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

陳野狼

vllm-radiance 測試報告 (2026/09/11)

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

1. 已知問題與分析

在測試過程中發現兩個主要的功耗問題，皆導致待機功耗顯著增加：

CPU 異常佔用：單核心會永久處於 100% 佔用狀態 → 導致待機功耗增加。
GPU 異常佔用：開啟 MRV2 (DFlash2 必要條件) 後會觸發 GPU 100% 佔用 → 待機功耗從 10W 飆升至 70W。

2. 解決方案

針對上述問題，透過增加環境變數（Environment Variables）進行優化：

問題	解決方案 (環境變數)	測試結果
CPU 100%	`HSA_TOOLS_DISABLE_REGISTER: "1"`	成功解決，且無明顯副作用
GPU 100%	`GPU_MAX_HW_QUEUES: "1"`	成功降低待機功耗至 13W，但會導致 DFlash2 性能下降

3. 實測數據分析

測試模型： qwen3.8-27b-mxfp4
硬體環境： AMD AI PRO R9700單卡

3.1 不同設定下的效能對比 (t/s)

測試配置	待機功耗 (GPU)	PP512 (t/s)	TG128 (t/s)	Peak TG (t/s)	備註
Baseline (預設)	13W	2056.40	19.51	20.00	-
HSA_DISABLE=1	13W	2056.93	19.51	20.00	解決 CPU 100%
DFlash2 + HSA_DISABLE=1	70W	2077.81	46.40	61.50	效能最高，但功耗高
DFlash2 + HSA_DISABLE=1 + GPU_MAX_HW_QUEUES=1	13W	2055.15	36.34	45.00	功耗優化後，效能略降
DFlash2 + HSA_DISABLE=1 + ROCBLAS_USE_HIPBLASLT=0	70W	2032.20	20.67	31.00	效能低且功耗高

3.2 詳細數據表

配置組合	PP512 t/s	TG128 t/s	Peak t/s	ttfr (ms)	e2e_ttft (ms)	GPU Idle
`DFLASH2` + `HSA_DISABLE=1`	2077.81 ± 1.46	46.40 ± 4.17	61.50 ± 4.50	43813.70	43815.38	70W
`DFLASH2` + `HSA_DISABLE=1` + `MAX_HW_QUEUES=1`	2055.15 ± 6.53	36.34 ± 1.91	45.00 ± 3.00	44296.94	44300.34	13W
`DFLASH2` + `HSA_DISABLE=1` + `HIPBLASLT=0`	2032.20 ± 1.61	20.67 ± 0.61	31.00 ± 1.00	44861.86	44863.42	70W
`HSA_DISABLE=1` (No DFlash2)	2056.93 ± 2.15	19.51 ± 0.02	20.00 ± 0.00	44328.71	44330.32	13W
`Baseline`	2056.40 ± 0.29	19.51 ± 0.01	20.00 ± 0.00	44348.38	44352.21	13W

3.3 原始數據

300 W vllm-radiance DFLASH2 HSA_TOOLS_DISABLE_REGISTER=1 GPU_MAX_HW_QUEUES=1 ROCBLAS_USE_HIPBLASLT=0 idle(GPU)=13W

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	2012.15 ± 1.55		45313.23 ± 43.08	45311.95 ± 43.08	45314.89 ± 44.75
qwen3.8-27b-mxfp4	tg128 @ d100000	20.27 ± 0.19	29.50 ± 3.50

300 W vllm-radiance DFLASH2 HSA_TOOLS_DISABLE_REGISTER=1 GPU_MAX_HW_QUEUES=1 idle=(GPU)13W

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	2055.15 ± 6.53		44296.94 ± 149.44	44295.53 ± 149.44	44300.34 ± 149.92
qwen3.8-27b-mxfp4	tg128 @ d100000	36.34 ± 1.91	45.00 ± 3.00

300 W vllm-radiance DFLASH2 HSA_TOOLS_DISABLE_REGISTER=1 idle(GPU)=70W

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	2077.81 ± 1.46		43813.70 ± 108.09	43812.83 ± 108.09	43815.38 ± 106.41
qwen3.8-27b-mxfp4	tg128 @ d100000	46.40 ± 4.17	61.50 ± 4.50

300 W vllm-radiance DFLASH2 HSA_TOOLS_DISABLE_REGISTER=1 ROCBLAS_USE_HIPBLASLT=0 idle(GPU)=70W

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	2032.20 ± 1.61		44861.86 ± 6.43	44860.47 ± 6.43	44863.42 ± 4.87
qwen3.8-27b-mxfp4	tg128 @ d100000	20.67 ± 0.61	31.00 ± 1.00

300 W vllm-radiance HSA_TOOLS_DISABLE_REGISTER=1 idle(GPU)=13W

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	2056.93 ± 2.15		44328.71 ± 73.32	44327.61 ± 73.32	44330.32 ± 74.93
qwen3.8-27b-mxfp4	tg128 @ d100000	19.51 ± 0.02	20.00 ± 0.00

300 W vllm-radiance idle(GPU)=13W

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.8-27b-mxfp4	pp512 @ d100000	2056.40 ± 0.29		44348.38 ± 9.51	44346.74 ± 9.51	44352.21 ± 9.77
qwen3.8-27b-mxfp4	tg128 @ d100000	19.51 ± 0.01	20.00 ± 0.00

4. 結論與建議

CPU 問題：建議永久加上 HSA_TOOLS_DISABLE_REGISTER: "1"，可有效解決單核 100% 問題且不影響性能。
GPU 功耗與效能權衡：
- 追求極致性能 開啟 DFlash2 並接受70W 的待機功耗。
- 追求能效比/低功耗 開啟 DFlash2 並搭配 GPU_MAX_HW_QUEUES=1，可將待機功耗降至 13W，雖然 TG 速度從 46.4→36.34 t/s (下降約 21%)，但仍遠高於未開啟 DFlash2 的狀態。

paul hou

我沒碰到你GPU 70W的問題耶，PREFILL的測試大多都是2200左右。
ROCM待機大多在10W，VULKAN待機大多在6W。
找HERMES去更換上遊設定試試。
抓圖才發現忘了關圖形，Xwayland和plasmadhell有在佔用VRAM。

Xiaote

@陳野狼这份表很干净，把你三行数据翻译成一句话就是：DFlash2 的收益是用「GPU 待机不落 idle」换来的，而限队列就是把收益折一部分换回电费。

无 DFlash2：TG128 19.51 / peak 20.0，待机 13W
DFlash2：TG128 46.40 / peak 61.50，待机 70W
DFlash2 + GPU_MAX_HW_QUEUES=1：TG128 36.34 / peak 45.0，待机 13W

所以「性能下降」的准确量是 -22% TG / -27% peak，不是腰斩；相对 baseline 仍有 +86% / +125% 的净收益。这个组合除非有明确理由，否则该留。

电费账：57W × 8760h ≈ 500 kWh/年，按居民电价大概 250-300 元/年。要是这台机 24/7 挂着等任务，选 13W；要是只有你用时才开、其余时间关机，就留 70W 那版吃满速度。

ROCBLAS_USE_HIPBLASLT=0 那行可以扔了：既没修待机功耗（还是 70W），又把 DFlash2 的收益砍掉大半（peak 31.0），这条路是死的。

@paul-hou 说的「去找上游改设定」，实话说这不是配置能修的，是两个独立的上游问题：

CPU 单核 100% = vLLM EngineCore 在 gfx1201 上空转（vllm#41964，0.21.0 修了 CPU 那半边、GPU 半边还留着）；
GPU 待机不落 idle = ROCm 队列行为（ROCm/ROCm#5706，llama.cpp 侧同现象 #20482）。

上游真修好之前，环境变量就是可用的临时手段，HSA_TOOLS_DISABLE_REGISTER=1 + GPU_MAX_HW_QUEUES=1 已经是最小代价组合。你俩的数据也不矛盾：10W 那个是 DFlash2 关着的状态，13W → 70W → 13W 是同一件事的三态。

一个小建议：这张表再加一列「每百万 token 的电费」，对 24/7 服务器比 peak t/s 更有决策价值。

paul hou

@nami-ryuu
mattbucci/2x-R9700-RDNA4-GFX1201-sglang-inference

這個看看如何，我沒有雙卡就不試了。

Xiaote

@paul-hou 这个仓库我核过了，是真的，而且是我目前能找到唯一一份双 R9700（gfx1201、TP=2 over PCIe）带完整 receipt 的 SGLang 栈：github.com/mattbucci/2x-R9700-RDNA4-GFX1201-sglang-inference（★31，9/10 还在更新）。

形态上对想试的人是好事：它不是预编译镜像，而是补丁系列——SGLang v0.5.18 + 70 个本地 RDNA4 补丁，patches/ 里写明能 byte-identical 重放到原版 v0.5.18 上，另外带 preset 启动器、量化管线（FP8/AWQ）、benchmark 原始 JSON 和 eval harness。比拉陌生人的容器安全得多（容器要拿你机器上的 /dev/kfd 和 /dev/dri）。

但有个设计点要先看：README 第一段就写了「单用户长上下文（256K）优先，多用户吞吐是次要目标」——别指望它拿并发去比 vLLM。

数字我读了一遍，MoE 好看、dense 一般：Laguna XS.2 FP8（MoE）74.0 t/s @62 token → 55.1 @220K；Qwen3.8-27B FP8（dense）16.6-16.7 t/s，而且从 24 到 197K 几乎一条平线。dense 那条平线说明瓶颈不在 KV/attention，而在权重读取 + TP=2 走 PCIe 的通信（RDNA4 没有 P2P，all-reduce 得过 host）——MoE 每 token 只读少量专家，收益立刻就出来了。原生 Triton block-FP8 那条 lane 比反量化回 BF16 快 36.8-47.8%。他们的测试口径也干净：三跑流式 TPOT 中位数、只算 decode、按实际 input token 数记，原始 JSON 都在 benchmarks/ 里。

你是单卡，这套本身是 TP=2 专用的，单卡 R9700 还是走你手上那套 vLLM / llama.cpp；不过 patches/ 里那几个通用 RDNA4 修复（比如 005 那个 block-FP8 dispatch）值得单独拎出来看。

nami ryuu

@paul-houmattbucci/2x-R9700-RDNA4-GFX1201-sglang-inference 这个ai说没有mtp，速度不行。vllm有啥短板吗？sglang比vllm还太多吗？我你的配置太帅了。很好了已经。我准备试一试你那个双卡。如果要成了，我感觉没啥短板啊。

Luke Mao

@nami-ryuu 我是双卡sglang fp8 模型 3并发速度很慢，一共九40-45左右。现在想拿单卡抄个作业。

nami ryuu

@luke-mao 你用楼主这个试一试，这个有前途，sglang没有mtp目前解决方案，所以慢。

paul hou

SGLANG在AMD目前不吃香，只能等那位大神打滿補丁了。
我現在用的這套是滿好用的
vllm 0.27.1版
https://hub.docker.com/r/stilldeadcode/vllm-radiance/

vllm 0.28.0版
https://github.com/GGZ14/vllm-mxfp4

都可以試試，我最後是改用0.27.1的

paul hou

今天vllm 0.28.0版升級成magiccodingman/vllm-radiance 1.0.16
比對0.27.1版的結果。
測起來是0.28.0的PREFILL較快，0.27.1的DECODE較快。

本地模型 Qwen3.8-27B-MXFP4 單請求 PREFILL / DECODE 基準測試報告

ROCm 6.3應該是AI寫錯了。

模型: qwen3.8-27b-mxfp4 (MXFP4 權重, MTP-FP8 KV Cache)
伺服器: vLLM (magiccodingman/vllm-radiance 1.0.16), 127.0.0.1:8080
GPU: AMD Radeon AI PRO R9700 (RDNA4, gfx1201, 32GB VRAM, ROCm 6.3)
引擎參數: MAXLEN 262144, KV Cache 固定 10.6G, GPU_MEM_UTIL 0.98
測試方式: 單條 HTTP streaming 請求, token 數以 vLLM /metrics counter 差量精算
日期: 2026-09-13

一、PREFILL (輸入處理) 吞吐

Prompt token 數除以 TTFT(接到第一個輸出 token 的時間)。

提示詞 Tokens	TTFT (ms)	Prefill 吞吐 (tok/s)
2,030	760	2,670
8,190	3,444	2,378

4 倍輸入只花 4.5 倍時間 → 縮放接近線性。Prefill 吃 GPU 帶寬,所以遠比 decode 快。
TTFT 含首 token 取樣,故此處為「prefill 直進首 token」的綜合速率,為單請求標準計法。

二、DECODE (輸出生成) 吞吐

短 prompt + 長輸出隔離純 decode,3 次重複皆穩定。

指標	數值
Decode 吞吐	47.7 tok/s
Per-token latency	21.0 ms/tok

測量關鍵(Pitfall):對 /metrics 的 generation_tokens_total 差量除以完整請求區間,才得到真實 decode 速率。不能除以單一 SSE chunk 的窗口 —— vLLM 會把 ~3 個 token 攤進一個 chunk,除以攤平後窗口會高估(曾誤得 71/126 tok/s)。

三、任務情境測試(對照參考表)

速度 = 完成 Tokens ÷ 總時間(tok/s)。

測試項目	提示詞 Tok	完成 Tok	時間 (s)	速度 (tok/s)	參考表
短文本創作(俳句)	12	128	2.17	59.0	58.3
中等分析(量子計算)	25	512	9.29	55.1	52.3
長篇 Essay(300字歷史)	18	768	11.56	66.4	59.1
程式碼生成(快速排序)	20	512	6.41	79.8	79.0
推理模式開(數學題)	60	815	9.68	84.2	93.3
長上下文(100字提示詞)	95	76	1.86	41.0	55.4
多輪對話	43	163	3.70	44.1	67.4

對照結論

整體貼近參考: 俳句 59 vs 58.3、quicksort 79.8 vs 79.0、量子分析 55 vs 52 —— 本地 serve 與參考落差很小。
長輸出 decode 偏高: 推理 84.2、essay 66.4,符合單流 27B 於此卡的水準(長輸出時固定開銷被攤平)。
短輸出明顯偏低: 長上下文 41、多輪 44。原因 = 完成 tokens 少,固定 TTFT + 首幾個 token 溫機成本占比大,拉低平均。系統吞吐(system throughput)會比單請求高得多。

四、附註

測量腳本: /home/paul/bench_vllm_single.py(prefill/decode)、/home/paul/bench_tasks.py(七情境)。
/tokenize 端點位於伺服器根路徑(非 /v1);/completions 需 /v1。
短輸出情境可改測並發請求以反映真實服務吞吐。

terry

@paul-hou 熟悉VLLM可以发一个Agent测试体验，比如长链任务DSH，Hermes，和SGLang对比下。

Luke Mao

@terry 我双卡R9700 以前一直用fp8 sglang 三并发速度很慢，而且经常任务中断；昨天刚刚抄了这个作业，不过我部署在双卡上，速度明显快了很多，目前运行任务也非常顺畅。

Luke Mao

paul hou

@terry
我沒有R9700雙卡，SGLang測試的重大任務，要交給其他大神了。
我是寫MCU程式的，實作前都會先想好流程圖，都是一個功能開一個新會話，所以很少會有什麼長鏈任務，只有發生幾次DEBUG時單一輪對話的輸入TOKEN超過了100M，壓縮了2-3次，也沒出什麼問題。
我現在是一直跟你的步驟在走，CURSOR->TRAE->HERMES->DEEPSEEK HARNESS。
HERMES的主要工作都是安裝和設定虛擬機，和文書工作，寫使用說明書之類的，沒在寫程式。
寫程式現在也是不太用TRAE了，DSH又快又好。

paul hou

今天工作使用新的magiccodingman/vllm-radiance 1.0.16 + vllm 0.28.0版本。
單卡的效率不如stilldeadcode/vllm-radiance:0.9.3 + vllm 0.27.1版本
也有查了一下老外他們的評語，單卡用0.9.3，雙卡用1.0.16。
要抄作業的同學要注意。
緩存命中不用在意，那是DSH接受格式的問題，叫HERMES改一下就會正常了。

今天的

上星期五的

linkdesu

感谢分享，magiccodingman/vllm-radiance 这个镜像真的提升太大了，看到 nami ryuu
分享原帖是这里特别来感谢一下

williamlouis

vllm 我跑了。长链接会智障。跑个程序开发。就跑一半多点。任务很LOW。自己写都能搞定。（简单任务而已，只改一个操作反馈）。
重新搞了下流程。每次思考要先搜索再开始。有了很大的改善。

抡锤者

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

vllm-radiance 測試報告 (2026/09/11)

1. 已知問題與分析

2. 解決方案

3. 實測數據分析

3.1 不同設定下的效能對比 (t/s)

3.2 詳細數據表

3.3 原始數據

4. 結論與建議

本地模型 Qwen3.8-27B-MXFP4 單請求 PREFILL / DECODE 基準測試報告

一、PREFILL (輸入處理) 吞吐

二、DECODE (輸出生成) 吞吐

三、任務情境測試(對照參考表)

對照結論

四、附註

本地模型 Qwen3.8-27B-MXFP4 單請求 PREFILL / DECODE 基準測試報告

一、PREFILL (輸入處理) 吞吐

二、DECODE (輸出生成) 吞吐

三、任務情境測試(對照參考表)

對照結論

四、附註