單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試

[applejuice]

@fcme 据了解 这次的速度提升不在mxfp4 而是社区优化了 vllm/sglang
mxfp4 只是用更小的vram

[fcme]

@applejuice
不是，速度起来是因为R9700本身是支持FP4的，这次这个框架可以把nvfp4的模型转换为AMD的mxfp4，这样就能充分利用9700的FP4能力了。纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧，狗头保命，哈哈。

[applejuice]

@fcme 说:

@applejuice
不是，速度起来是因为R9700本身是支持FP4的，这次这个框架可以把nvfp4的模型转换为AMD的mxfp4，这样就能充分利用9700的FP4能力了。纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧，狗头保命，哈哈。

@xiaote 可以解释吗？

[terry]

挺好的测试，我对VLLM的实测不太多，偶尔玩玩，这样的帖子很有意义。毕竟是主力框架之一！

[kos or]

@fcme said:

买！这个库是新出的，有了这个库以后跑27b的FP4模型3000以上的pp速度和100左右的tg在本地模型里面就是最甜的甜点了，综合了价格和性能，还有输出质量。

我今天剛完成 雙卡RTX5070 Ti -NInfer-Qwen3.6-27B-NVFP4
純文字速度大約 100 TPS
解題速度大約 140 TPS
Prefill 約 3300 tok/s
但CP值不高

雙卡 R97000 Prefill 可以高達6000 tok/s 這真誘人
而且看過4卡是12,000 tok/s的數據

[kos or]

@applejuice said:

纳闷为啥以前没人弄这个，估计也是和现在AI能力强了以后有想法的牛人更加可以用Claude之类牛逼模型把这么小众的需求给满足了。根本上还是5090太贵了吧

一張5090 32G 價格接近4張R9700 (128G) 這性價比出來了 在LLM單一模型上

[paul hou]

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）。

[fcme]

@paul-hou
他这个把上下文调短了以后，貌似是为了优化多并发的场景。在agent时代65k的上下文有点不够看啊，单人使用还是老的200k版本好些。

[paul hou]

調回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。

[paul hou]

@fcme

我是把65K-R3又重新調整了一次設定成單請求不併發，最大上下文就192K左右。
200K的改成2併發150K，設成一些DRAM給他超出VRAM備用，還要試試超出的情況。

[fcme]

@paul-hou
等你作业了，不过我主要是办公场景，不开发，感觉差的这点点区别不是很大就先不折腾了。paiton这个仓库现在就很好了，和普通的框架1100左右的pp已经是云泥之别了。

[suboyang]

@fcme

关键是他说的是一张卡
Tested on one Radeon AI PRO R9700 (32 GB, RDNA4, gfx1201). Other GPUs have not been qualified.

双卡TP性能，决定R9700双卡有没有价值。如果双卡TP性能单流速度很低，那么R9700价值也不是很高。真正用本地模型干活，速度还是很重要的。

[fcme]

@suboyang
双卡tp会有不同的框架吧。个人使用的话单卡就很好了，我现在200k上下文，pp/tg3500/100左右，双卡的话基本就是为了多开更长的长下文才有意义。

[paul hou]

@fcme
雙卡可用一樣的prefill可以超過6000。
單卡併發試完了，結論就不適合，看來要雙卡以上才適合併發。
後來有發現沒啟用到緩存功能，打開後上下文下降到174k。這10%的加速要用60k上下文來換。

[fcme]

@paul-hou
那就不值得了，不需要识图的话用识图能力换也行，能顶到240k左右。开了就只有200k了，我这几天用下来也基本够了，配合dsh非常非常好用了。感觉有用DS v4 flash的感觉，和V4.1的拉稀一样的速度没法比。

[Xiaote]

@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]

@fcme

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 tokens
CUDA 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 編碼場景)

[applejuice]

@paul-hou prefill 高就是爽

[paul hou]

@applejuice

對話都是秒起動，真的比較爽，少那近20K上下文就認了。

[fcme]

我今天带小孩出去无聊的时候也升级到了R3，还是200k的上下文，带图。PP和tg都有提升，tg甚至到了125左右，比上个版本快个30%左右。老天，这个也太牛逼了！哈哈