單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真的很神，而且還這麼快。推薦裝一個來試試。
-
-
-
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。
-
-
模型优化团队也是自杀群体。
越优化的越好。卡越涨价。。。。。。。。
无解 -
-
