單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試
-
@Magic629 我的配置就是照抄 paul hou 的作业，自己没怎么调过。
硬件：
- 显卡：单张 R9700 32G（ReBAR 开，PCIe 4.0 x8）
- CPU：Intel Core i9-13900HK ES（14C/20T）
- 内存：32G DDR4
- 功耗上限：260W
软件（全部照 paul hou 帖里的 paiton 方案来）：
- 镜像：
ghcr.io/eliovp/paiton-vllm-plugin - 模型：
amd/Qwen3.8-27B-Quark-AWQ-MXFP4 - 投机解码 draft：
tcclaviger/Qwen3.8-27B-DFlash2-FP8（dflash，7 tokens） - 上下文 200K，KV cache fp8（8G），prefix caching 开
实际跑起来：
日常跑 agent 的时候，DSH WebUI 状态栏大概 115 tok/s，cache 命中 91%。
要说明的是，这个 115 不是裸 benchmark 的 decode 速度 —— 91% 的输入命中缓存了，所以平均偏高。真要对比裸测数字，还是看 paul hou 帖里的 PP/TG 数据更准。
归根到底就是那套作业一字不改抄下来，能跑通就行。
-
我手上用着3090x2
看到这个帖我有冲动买 r9700 -
看到这个帖我有冲动买 r9700
哈哈 我跟你一樣有這個衝動
-
@kos-or
买！这个库是新出的，有了这个库以后跑27b的FP4模型3000以上的pp速度和100左右的tg在本地模型里面就是最甜的甜点了，综合了价格和性能，还有输出质量。
唯一的缺憾就是这个库的底层用的是vllm，框架开销比较大。我晕下来不带识图的话，上下文可以开到240左右，开了识图以后，上下文也就只能开到200~210k。基本上就把32g的显存跑满了。 -
@fcme 据了解 这次的速度提升不在mxfp4 而是社区优化了 vllm/sglang
mxfp4 只是用更小的vram -
@applejuice
不是，速度起来是因为R9700本身是支持FP4的，这次这个框架可以把nvfp4的模型转换为AMD的mxfp4，这样就能充分利用9700的FP4能力了。纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧，狗头保命，哈哈。 -
，
T terry 固定了此主题
-
-
@kos-or
买！这个库是新出的，有了这个库以后跑27b的FP4模型3000以上的pp速度和100左右的tg在本地模型里面就是最甜的甜点了，综合了价格和性能，还有输出质量。
唯一的缺憾就是这个库的底层用的是vllm，框架开销比较大。我晕下来不带识图的话，上下文可以开到240左右，开了识图以后，上下文也就只能开到200~210k。基本上就把32g的显存跑满了。 -
@applejuice
不是，速度起来是因为R9700本身是支持FP4的，这次这个框架可以把nvfp4的模型转换为AMD的mxfp4，这样就能充分利用9700的FP4能力了。纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧，狗头保命，哈哈。@xiaote 可以解释吗？
-
paiton方案又有新的鏡像，65K-R3版，調整了一下，單卡上下文的最大值又降到只剩192K左右。
效能又上升了一點(PREFILL滿大一個點)。
以下是限制功率在210W下的測試結果。2. DECODE 效能結果
固定 prompt ~256 tokens，thinking OFF：
Output tokens TTFT (ms) 生成時間 (s) TPOT (ms/token) Decode (tok/s) 64 114.1 0.85 11.63 86.0 128 113.8 1.41 10.21 98.0 256 114.0 2.84 10.71 93.4 結論：平均 DECODE ≈ 92.5 tok/s（TPOT ≈ 10.9 ms/token），穩定在 86–98 tok/s。
3. 編程（Programming）DECODE 效能結果
針對 5 種真實程式設計任務，thinking OFF、單請求、輸出固定 256 tokens、每設定 4 次取中位數：
任務 Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s) fibonacci 256 57.3 1.61 6.10 164.0 sorting 256 57.3 1.74 6.62 151.2 api 256 57.0 2.00 7.61 131.4 regex 256 57.0 1.96 7.45 134.2 class 256 59.0 2.26 8.63 115.8 結論：編程 DECODE 平均 ≈ 139.3 tok/s（中位數 ≈ 134.2 tok/s，範圍 115.8–164.0），TPOT ≈ 7.28 ms/token。
4. PREFILL 效能結果
固定 output ~32 tokens，變化輸入長度：
Prompt tokens TTFT (ms) 邊際 prefill (tok/s) 111 112.5 —（基準點） 507 220.7 3,660 1,002 356.6 3,642 1,992 693.3 2,940 4,071 1,373.2 3,058 8,031 2,757.3 2,861 結論：PREFILL 邊際速率 ≈ 2,900–3,600 tok/s，隨輸入變長收斂至約 3,000 tok/s；TTFT 隨 prompt 近似線性成長（~0.34 ms/輸入 token）。
-
paiton方案又有新的鏡像，65K-R3版，調整了一下，單卡上下文的最大值又降到只剩192K左右。
效能又上升了一點(PREFILL滿大一個點)。
以下是限制功率在210W下的測試結果。2. DECODE 效能結果
固定 prompt ~256 tokens，thinking OFF：
Output tokens TTFT (ms) 生成時間 (s) TPOT (ms/token) Decode (tok/s) 64 114.1 0.85 11.63 86.0 128 113.8 1.41 10.21 98.0 256 114.0 2.84 10.71 93.4 結論：平均 DECODE ≈ 92.5 tok/s（TPOT ≈ 10.9 ms/token），穩定在 86–98 tok/s。
3. 編程（Programming）DECODE 效能結果
針對 5 種真實程式設計任務，thinking OFF、單請求、輸出固定 256 tokens、每設定 4 次取中位數：
任務 Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s) fibonacci 256 57.3 1.61 6.10 164.0 sorting 256 57.3 1.74 6.62 151.2 api 256 57.0 2.00 7.61 131.4 regex 256 57.0 1.96 7.45 134.2 class 256 59.0 2.26 8.63 115.8 結論：編程 DECODE 平均 ≈ 139.3 tok/s（中位數 ≈ 134.2 tok/s，範圍 115.8–164.0），TPOT ≈ 7.28 ms/token。
4. PREFILL 效能結果
固定 output ~32 tokens，變化輸入長度：
Prompt tokens TTFT (ms) 邊際 prefill (tok/s) 111 112.5 —（基準點） 507 220.7 3,660 1,002 356.6 3,642 1,992 693.3 2,940 4,071 1,373.2 3,058 8,031 2,757.3 2,861 結論：PREFILL 邊際速率 ≈ 2,900–3,600 tok/s，隨輸入變長收斂至約 3,000 tok/s；TTFT 隨 prompt 近似線性成長（~0.34 ms/輸入 token）。
-
調回300W再測一次，調成300W似乎效能差異滿大的。
2. PREFILL 效能結果（本次全量重測）
固定 output ~32 tokens，變化輸入長度：
Prompt tokens TTFT (ms) 邊際 prefill (tok/s) 111 94.0 —（基準點） 507 177.0 4,377 1,002 290.1 3,564 1,992 567.9 3,645 4,071 1,138.2 3,464 8,031 2,281.3 3,472 結論：PREFILL 邊際速率 ≈ 3,460–4,380 tok/s，隨輸入變長收斂至約 3,500 tok/s；TTFT 隨 prompt 近似線性成長（~0.28 ms/輸入 token）。
3. DECODE 效能結果（通用自然語言，本次全量重測）
固定 prompt ~256 tokens，thinking OFF：
Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s) 64 98.5 0.66 8.97 111.4 128 95.5 1.10 7.92 126.3 256 95.6 2.21 8.28 120.7 結論：平均 DECODE ≈ 119.5 tok/s（TPOT ≈ 8.39 ms/token），穩定在 111–126 tok/s。
4. 編程（Programming）DECODE 效能結果（本次全量重測）
5 種真實程式設計任務，thinking OFF、單請求、輸出固定 256 tokens：
任務 Output tokens TTFT (ms) 總時間 (s) TPOT (ms/token) Decode (tok/s) fibonacci 256 52.3 1.26 4.73 211.4 sorting 256 50.7 1.36 5.13 195.1 api 256 50.8 1.56 5.91 169.2 regex 256 50.7 1.53 5.78 172.9 class 256 51.0 1.76 6.70 149.3 結論：編程 DECODE 平均 ≈ 179.6 tok/s（中位數 ≈ 172.9 tok/s，範圍 149.3–211.4），TPOT ≈ 5.65 ms/token。
-
-
我是把65K-R3又重新調整了一次設定成單請求不併發，最大上下文就192K左右。
200K的改成2併發150K，設成一些DRAM給他超出VRAM備用，還要試試超出的情況。 -
-
关键是他说的是一张卡
Tested on one Radeon AI PRO R9700 (32 GB, RDNA4, gfx1201). Other GPUs have not been qualified.双卡TP性能，决定R9700双卡有没有价值。如果双卡TP性能单流速度很低，那么R9700价值也不是很高。真正用本地模型干活，速度还是很重要的。
-
-
@fcme
雙卡可用一樣的prefill可以超過6000。
單卡併發試完了，結論就不適合，看來要雙卡以上才適合併發。
後來有發現沒啟用到緩存功能，打開後上下文下降到174k。這10%的加速要用60k上下文來換。 -
@applejuice 可以，拆两层说。
1）R9700「支持 FP4」指的是权重格式，不是 FP4 算力。
RDNA4/gfx1201 原生能吃 MXFP4 权重（e2m1 + 每 32 一组 e8m0 指数），但矩阵计算路径不是 FP4 MAC。这个仓库（GGZ14/vllm-mxfp4）跑的是 W4A8：4bit 权重 × FP8 激活、走 fp8 WMMA（gfx1201 上 fp8 WMMA 325 TFLOP/s，f16 只有 160）。上游 vLLM 默认跑不了，是三道软门槛：is_fp4_avail()白名单不含 gfx1201、aiter 模块路径变动、gfx1250 的 WMMA tile（本卡只有 16x16x16）；仓库用 patch + 手写 HIP kernel 绕过。2）NVFP4 → MXFP4 是在线重量化。
NVFP4 是 e2m1 + 每 16 一个 e4m3 scale + 每张量 fp32 scale；加载后 dequant 再重量化成 MXFP4（e2m1 + 每 32 一个 e8m0），按合并 linear 的 partition 做，约 10s/rank。这一步是 double rounding，实测 relRMS 0.113 → 0.158（直接 bf16→MXFP4 是 0.112），GSM8K 基本看不出来。3）为什么以前没人做、收益在哪。
以前缺的是愿意写 gfx1201 小众 kernel 的人；现在 AI 辅助编码让「只有几十个人要的优化」变得可做——不是硬件突然开放了 FP4。收益主要来自权重流量：27B 的 MXFP4 body 9.24 GiB/GPU，FP8 约 12.6 GiB，decode 省带宽，还腾出大量 KV（单卡 65k ctx 约 99k tokens；双卡 262k ctx、943k tokens）。decode 仍受带宽约束，4bit 是把墙推远一点，不是推倒。 -
@paul-hou
那就不值得了，不需要识图的话用识图能力换也行，能顶到240k左右。开了就只有200k了，我这几天用下来也基本够了，配合dsh非常非常好用了。感觉有用DS v4 flash的感觉，和V4.1的拉稀一样的速度没法比。65K-R3版雖然只有174K上下文，但在DSH中用起來真的更像線上API了，開新會話都是在2秒內就會開始跑起來，所以我還是研究了一下，把上下文調到了216000。
最終設定
項目 值 備註 max-model-len 216000 245 blocks × 880 = 215,600,在 pool 內 max-num-seqs 1 單請求 max-num-batched-tokens 2048 維持原值(改動 #2 不做) kv-cache-memory-bytes auto vLLM 依 gpu-mem-util 自動算 gpu-memory-utilization 0.98 KV pool(實測) 7.47 GiB = 216,480 tokens 開機日誌 GPU KV cache size: 216,480 tokensCUDA graphs [1,2,4,8] 改動 #1 defrag max_split_size_mb:64 改動 #3 prefix caching on RADIANCE_GDN_LAZY=0 KV dtype fp8 attention R4D speculative DFlash2 x7,TRITON_ATTN,draft_sample_method probabilistic mamba-cache-mode align served-model-name qwen3.8-27b-mxfp4 host / port 0.0.0.0 / 8080 reasoning effort medium 伺服器預設 n-gram co-drafting off(預設);PAITON_NGRAM=1 開啟 +27% decode(agentic 編碼場景)
