單R9700 + VLLM(GGZ14/vllm-mxfp4) + unsloth/Qwen3.8-27B-NVFP4 測試
-
我是把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 編碼場景) -
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 編碼場景) -
@paul-hou prefill 高就是爽
-
-
，系统 取消固定了此主题
-
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！