單張R9700 AI PRO 32G + VLLM + amd/Qwen3.8-27B-Quark-AWQ-MXFP4
-
@nami-ryuu 我是双卡sglang fp8 模型 3并发 速度很慢， 一共九40-45左右。现在想拿单卡抄个作业。
-
-
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的
-
今天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
/metricscounter 差量精算 - 日期: 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。- 短輸出情境可改測並發請求以反映真實服務吞吐。
-
I iamvirus 于 引用了 此主题
-
今天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
/metricscounter 差量精算 - 日期: 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。- 短輸出情境可改測並發請求以反映真實服務吞吐。
-
-
-
-
-
-
vllm 我跑了。长链接会智障。跑个程序开发。就跑一半多点。任务很LOW。自己写都能搞定。（简单任务而已，只改一个操作反馈）。
重新搞了下流程。每次思考要先搜索再开始。有了很大的改善。 -
-
@terry 我双卡R9700 以前一直用fp8 sglang 三并发 速度很慢，而且经常任务中断；昨天刚刚抄了这个作业，不过我部署在双卡上，速度明显快了很多，目前运行任务也非常顺畅。
@Luke-Mao
这个是针对单卡的包吧，你是怎么用在双卡上的？速度有接近翻倍么？相比楼主的测试来说。 -
-
@fcme
https://github.com/magiccodingman/vllm-radiance這個方案就是針對雙卡的，不過這個已經算很舊了。
paiton還是能調整出雙卡用的。 -
vllm 我跑了。长链接会智障。跑个程序开发。就跑一半多点。任务很LOW。自己写都能搞定。（简单任务而已，只改一个操作反馈）。
重新搞了下流程。每次思考要先搜索再开始。有了很大的改善。 -
@williamlouis 是的，我现在用的双卡转到 SGLang 上，打了 N 多补丁，现在跑单路 116t/s，基本满足 8-10 人并发使用
-
-
-
有個問題W4A8妳使用的引擎有直接支援嘛？如果沒有，可能會多一層轉換W4A8 -> W4A4...這樣可能反而浪費效率?
