單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試
-
vLLM Radiance DECODE / PREFILL 性能測試報告
測試時間: 2026-09-19 23:40 CST
測試目標:192.168.1.241:8080
模型: unsloth/Qwen3.8-27B-NVFP4
硬體: AMD Radeon AI PRO R9700 (32GB VRAM, RDNA4 gfx1201)
1. 模型配置
參數 值 模型 Qwen3.8-27B-MXFP4 (不想重設就都用一樣的) 最大模型長度 225,000 tokens (NVFP4最大值就這麼多) KV Cache 資料類型 FP8 KV Cache 大小 8.6 GB GPU 記憶體使用率 0.98 張量並行 1 最大並行序列 1 最大批次 tokens 2,560 注意力後端 R4D 投機解碼 DFlash2 (Qwen3.8-27B-DFlash2-FP8) 投機 tokens 數量 7 投機取樣方法 Greedy 投機注意力後端 TRITON_ATTN 禁用填充草稿批次 true 前綴快取 已啟用 非同步排程 已禁用 溫度 / Top-P / Top-K 0.7 / 0.95 / 20 (溫度我最終都還是會設成1.0) 語言模型 only 是 啟用提示 tokens 詳細資訊 是 完整啟動命令
/opt/vllm/bin/python3 /opt/vllm/bin/vllm serve /models/paiton-qwen38/target \ --served-model-name Qwen3.8 Qwen3.6 Qwen3.8-MXFP4 \ --host 0.0.0.0 --port 8080 \ --kv-cache-dtype fp8 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.98 \ --kv-cache-memory 8600000000 \ --max-model-len 225000 \ --max-num-seqs 1 \ --max-num-batched-tokens 2560 \ --attention-backend R4D \ --speculative-config {"method":"dflash","model":"/models/qwen38-27b-R9700/models/tcclaviger/Qwen3.8-27B-DFlash2-FP8","num_speculative_tokens":7,"attention_backend":"TRITON_ATTN","disable_padded_drafter_batch":true,"draft_sample_method":"greedy"} \ --no-async-scheduling \ --mamba-cache-dtype bfloat16 \ --mamba-ssm-cache-dtype float16 \ --compilation-config {"cudagraph_capture_sizes":[1,2,4,8],"pass_config":{"fuse_norm_quant":true,"fuse_act_quant":true}} \ --enable-prefix-caching \ --mamba-cache-mode align \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --reasoning-parser qwen3 \ --override-generation-config {"temperature":0.7,"top_p":0.95,"top_k":20} \ --chat-template /patches/qwen-fixed-v22.5.jinja \ --served-model-name qwen3.8-27b-mxfp4 \ --language-model-only \ --enable-prompt-tokens-details \ --enable-force-include-usage
2. 測試方法論
避免緩存的策略
- 隨機 Prompt 內容: 每個測試使用完全不同的隨機字串作為 prompt，避免前綴快取（prefix caching）命中
- 丟棄預熱請求: 每個測試回合前先發送一次丟棄的預熱請求，確保 GPU 處於穩定狀態
- 隨機 Token 長度: 每個字詞長度為 3-12 個字元（英數混合），避免固定模式
測試分類
- PREFILL 測試: 不同 prompt 長度（256-4096 tokens 目標），只生成 1 token → 測量純 prefill 吞吐
- DECODE 測試: 極短 prompt（~20 tokens），不同輸出長度（32-512 tokens）→ 測量純 decode 吞吐
- 混合場景測試: 不同 prompt + 輸出長度組合 → 模擬真實使用情境
3. PREFILL 性能測試
測量不同 prompt 長度下的 prefill 處理速度（prefill tokens / 秒）
目標 Prompt Tokens 實際 Prompt Tokens Wall Time (s) Prefill 速度 (tok/s) 256 4,428 1.535 2,883.9 512 8,818 3.118 2,828.3 1,024 17,495 6.345 2,757.2 2,048 35,276 13.724 2,570.4 4,096 70,563 31.370 2,249.4 分析
- 短 prompt 可達 ~2,884 tok/s 的 prefill 吞吐
- 隨著 prompt 長度增加，prefill 速度略微下降（瓶頸從 compute 轉向 memory bandwidth）
- 4K tokens 仍有 2,249 tok/s，表現穩定
4. DECODE 性能測試
使用極短 prompt（~20 tokens），測量純 decode 速度
要求 Tokens 實際輸出 Tokens Wall Time (s) 解碼時間估計 (s) Decode 速度 (tok/s) 32 32 0.459 0.439 72.9 64 64 0.542 0.522 122.6 128 128 0.814 0.794 161.2 256 256 2.151 2.131 120.1 512 512 5.071 5.051 101.4 分析
- 峰值 decode 速度 ~161 tok/s（128 tokens 情境）
- 較長輸出時速度回落（101-120 tok/s），可能受 KV cache 壓力影響
- 投機解碼（DFlash2）在短輸出時可能尚未完全啟動
5. 混合場景測試
模擬真實使用：不同 prompt + 輸出長度組合
場景 Prompt Tokens 輸出 Tokens Wall Time (s) 整體吞吐 (tok/s) Short (597t → 64t) 597 64 1.047 631.2 Medium (5,804t → 128t) 5,804 128 3.628 1,634.9 Long (22,985t → 256t) 22,985 256 12.083 1,923.4 分析
- 混合場景下 prefill 主導整體吞吐（prompt 越長，prefill 佔比越高）
- Long 場景達到 1,923 tok/s 整體吞吐（prefill 貢獻最大）
6. vLLM /metrics 分析
測試期間的 Metrics 變化
指標 開始值 結束值 差異 成功請求數 225 259 +34 Prompt Tokens 總量 2,479,447 2,651,764 +172,317 Generation Tokens 總量 54,457 56,685 +2,228 投機解碼草稿總數 17,257 17,723 +466 投機接受 tokens 37,322 39,088 +1,766 前綴快取命中 1,473,120 1,473,120 0 (確認無緩存) 關鍵性能指標（來自 Histogram）
指標 平均值 TTFT (Time to First Token) 738.1s / 260 req = 2.84s Inter-token Latency 751.4s / 17,723 tokens = 42.4ms Prefill Time 551.9s / 259 req = 2.13s Decode Time 711.7s / 259 req = 2.75s E2E Latency 1,447.8s / 259 req = 5.59s 投碼解碼效率
指標 值 每次迭代平均接受 tokens 1,766 / 466 = 3.79 tokens/step 投碼接受率 39,088 / (17,723 × 7) = 31.5% 解碼加速比（vs 逐 token） ~3.79x
7. 總結
測試項目 最佳表現 備註 Prefill 速度 2,884 tok/s 短 prompt（256 tokens） Decode 速度 161 tok/s 128 tokens 輸出 混合場景吞吐 1,923 tok/s Long prompt + medium output 投碼加速比 3.79x DFlash2 每次迭代產出 3.79 tokens Inter-token 延遲 42.4 ms 包含投碼驗證的整體延遲 關鍵發現
- Prefill 無瓶頸: 即使是 4K tokens 仍有 2,249 tok/s，compute-bound 表現優秀
- Decode 受投碼影響: 128 tokens 時達到峰值 161 tok/s，更長輸出時回落至 101-120 tok/s
- DFlash2 效率: 每次投碼迭代產出 3.79 tokens（預期 7 tokens 的 54%），投碼接受率約 31.5%
- 前綴快取正確避開: 測試期間
prefix_cache_hits_total無變化（增加 0），確認緩存完全避免 - FP8 KV Cache 穩定: 8.6GB 配置下無 OOM 或效能衰退
這是R9700單卡目前的最速配置了，就是上下文最大就225K(不載入視覺)，但很夠用了。AMD能跑NVFP4真的很神，而且還這麼快。推薦裝一個來試試。
@paul hou 报告做得细，补三点。
1）Decode 量级是对的：27B NVFP4 权重约 13 到 14G，R9700 是 640 GB/s 带宽，dense 天花板大约 45 到 48 tok/s。你能看到 100 到 160，靠的就是 DFlash2 一次权重 pass 验证多个 token。
2）接受率那栏算法要修：3.79 accepted/step、k=7，若每档接受率近似恒定，E[L] = p + p² + … + p⁷ 约等于 3.79，反推 p 约 0.84，不是 31.5%。31.5% 是把累计的 39,088 除以累计草稿 17,723 乘 7，而 3.79 用的是增量 1,766 / 466，两个口径混了。请对同一时间窗取 spec_decode 草稿与接受两个计数器的增量来算，并确认你装的 vLLM 版本里这两个 metric 数的是 token 还是 iteration。
3）ITL 42.4ms 是每一步（iteration）不是每 token：3.79 token/step 除以 0.0424s 约等于 89 tok/s，和实测 decode 对得上；当成 per-token 报会低一个接受长度的倍数。
另外 decode 在 256 / 512 回落，单流下更像 KV 增长加固定开销在短输出里占比大；建议直接看 ITL 直方图分布，别只用 wall 减 prefill 再平均。前缀缓存 0 命中那步很干净，这点做得好。
-
-
R9700 prefill 居然可以上到2800了
我感觉我错过1个亿
-
-
-
-
-
Dual AMD R9700 - Real Performance. Local LLM Inference
版本/环境: Betterbench 0.6.0 | Localhost.localdomain | GGZ14 MXFP4 • vLLM Build
Decode Performance
Category Decode T/S (tokens per second) chat 144.4 code 262.0 file_edit 280.0 json 290.0 math 259.8 prose 124.6 reasoning 237.9 summarization 215.1 combined 237.9 Prefill Performance
Depth Tok/s (tokens per second) 2000 5769.4 8000 6043.8 16000 5959.3 32000 5741.7 64000 5395.5 Technical Stack & Features
- DUAL AMD R9700: Maximum throughput. Real world performance.
- GGZ14 MXFP4: Our custom vLLM support.
- vLLM: High performance. Open source.
- BETTERBENCH 0.6.0: Real benchmarks. Real numbers.
-
-
-
-
-
測試傳說中的Generate an SVG of a pelican riding a bicycle.
方案：https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
目前思考強度的設定是無效的，所以思考強度是被VLLM強設在MEDIUM。
-
-
模型优化团队也是自杀群体。
越优化的越好。卡越涨价。。。。。。。。
无解 -
-
-
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
這方案讓QWEN3.8 27B NVFP4去安裝，只修改一次就啟動成功了
就不貼一大篇了，講差異就行了。
vllm版本 ： 0.27.1 => 0.29.0
ROCM版本 ： 7.14.0 => 10
PREFILL ： 少不到100，也許是誤差
DECODE ： +5~10%左右@paul-hou
我们用同一张 R9700 测试了不同功耗和上下文配置，数据如下，供参考。测试环境
项目 值 显卡 AMD Radeon AI PRO R9700 32 GB (RDNA4 gfx1201) TP 1 方案 Eliovp-BV/paiton-vllm-plugin vLLM 0.29.0 + ROCm 10 官方镜像 v1.1.0 (sha256:28af1731cfd8) 模型 Qwen3.8-27B MXFP4 KV cache 8 GiB fp8 chunk size 4096 spec decode DFlash2, num_speculative_tokens=7 测试工具 BetterBench 0.6.0 采样 temp 0.7 / top_p 0.95，每类别 n=20，8 类别共 160 A. 功耗对比 — Paiton vLLM 0.29 ROCm10, 65K preset
Prefill（tok/s）
深度 (tok) 260 W 300 W ~1.5K 3,160 3,498 ~5.9K 3,149 3,433 ~11.8K 3,219 3,471 ~23.5K 3,069 3,292 ~47.0K 2,859 3,054 Decode（weighted t/s，8 类别合并）
功耗 Weighted decode 260 W 138.4 300 W 141.5 两组为同一张卡、同一镜像、同一天、同一组测试参数，只修改
power1_cap（260 W
300 W）。B. 三种上下文配置对比 — Paiton v1.1.0 官方镜像，全部 260 W
本节三个配置使用同一个官方 v1.1.0 镜像。其中 64K×8 为官方 preset；100K×2 为官方 entrypoint override（
--max-model-len 100000 --max-num-seqs 2），非官方 preset，未经官方完整 benchmark 认证。TG（weighted decode t/s）
配置 上下文 max_num_seqs TG wt 64K×8 65,536 8 103.89 200K×1 200,000 1 103.91 100K×2 100,000 2 103.84 Prefill（tok/s）
深度 (tok) 64K×8 200K×1 100K×2 ~1.5K 3,228 3,234 3,229 ~5.9K 3,130 3,143 3,153 ~11.8K 3,048 3,066 3,072 ~23.5K 2,862 2,876 2,883 ~47.0K 2,522 2,538 2,540 并发（aggregate t/s ／ TTFT p50 ms，48 请求／档位）
配置 c1 c2 c4 c8 64K×8 87.2 ／ 109 ms 151.1 ／ 162 ms 226.2 ／ 179 ms 309.6 ／ 201 ms 100K×2 87.1 ／ 109 ms 147.7 ／ 162 ms 151.3 ／ 2,771 ms 148.2 ／ 8,588 ms 200K×1 87.1 ／ 109 ms 87.0 ／ 2,227 ms 85.8 ／ 7,835 ms 87.4 ／ 15,396 ms
-
@paul-hou
我们用同一张 R9700 测试了不同功耗和上下文配置，数据如下，供参考。测试环境
项目 值 显卡 AMD Radeon AI PRO R9700 32 GB (RDNA4 gfx1201) TP 1 方案 Eliovp-BV/paiton-vllm-plugin vLLM 0.29.0 + ROCm 10 官方镜像 v1.1.0 (sha256:28af1731cfd8) 模型 Qwen3.8-27B MXFP4 KV cache 8 GiB fp8 chunk size 4096 spec decode DFlash2, num_speculative_tokens=7 测试工具 BetterBench 0.6.0 采样 temp 0.7 / top_p 0.95，每类别 n=20，8 类别共 160 A. 功耗对比 — Paiton vLLM 0.29 ROCm10, 65K preset
Prefill（tok/s）
深度 (tok) 260 W 300 W ~1.5K 3,160 3,498 ~5.9K 3,149 3,433 ~11.8K 3,219 3,471 ~23.5K 3,069 3,292 ~47.0K 2,859 3,054 Decode（weighted t/s，8 类别合并）
功耗 Weighted decode 260 W 138.4 300 W 141.5 两组为同一张卡、同一镜像、同一天、同一组测试参数，只修改
power1_cap（260 W 300 W）。B. 三种上下文配置对比 — Paiton v1.1.0 官方镜像，全部 260 W
本节三个配置使用同一个官方 v1.1.0 镜像。其中 64K×8 为官方 preset；100K×2 为官方 entrypoint override（
--max-model-len 100000 --max-num-seqs 2），非官方 preset，未经官方完整 benchmark 认证。TG（weighted decode t/s）
配置 上下文 max_num_seqs TG wt 64K×8 65,536 8 103.89 200K×1 200,000 1 103.91 100K×2 100,000 2 103.84 Prefill（tok/s）
深度 (tok) 64K×8 200K×1 100K×2 ~1.5K 3,228 3,234 3,229 ~5.9K 3,130 3,143 3,153 ~11.8K 3,048 3,066 3,072 ~23.5K 2,862 2,876 2,883 ~47.0K 2,522 2,538 2,540 并发（aggregate t/s ／ TTFT p50 ms，48 请求／档位）
配置 c1 c2 c4 c8 64K×8 87.2 ／ 109 ms 151.1 ／ 162 ms 226.2 ／ 179 ms 309.6 ／ 201 ms 100K×2 87.1 ／ 109 ms 147.7 ／ 162 ms 151.3 ／ 2,771 ms 148.2 ／ 8,588 ms 200K×1 87.1 ／ 109 ms 87.0 ／ 2,227 ms 85.8 ／ 7,835 ms 87.4 ／ 15,396 ms
-
我是降到210W，降速約30%，PREFILL慢了近22%，真是一分電源一分速度。
DEOCDE差異就小很多了。
所以還是降功率比較好。
