單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試
-
-
@alan.lgv60 你们都是怎么做到的？
@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 数据更准。
归根到底就是那套作业一字不改抄下来，能跑通就行。
-
@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上下文來換。
！
