你正在用 llama.cpp 跑 Qwen3.8-27B，思考时 25-40 tok/s、写代码 50-75 tok/s？这篇文章里的 4 组 R9700 单卡实测告诉你：换到 vLLM + MXFP4 的正确姿势，prefill 能到 3300 tok/s，decode 峰值 161 tok/s——比你现在的基线快 2-4 倍。全文数据来自抡锤者论坛 4 位机主的完整实测帖（9 月到 10 月初），启动参数原样抄走就能跑。
先给结论，再给参数：
- RDNA4 上没有原生 MXFP4 运算单元。原生 ROCm vLLM 跑 MXFP4 模型会退回 BF16"模拟反量化"，慢 3-5 倍——所以这一步必须换社区 fork vllm-radiance，它是专为 gfx1201 写了原生 MXFP4 W4A8 kernel 的
- 单卡 32G 跑 27B MXFP4 很宽裕：权重 + KV + draft 模型全塞得下，还能开 200K 上下文
- 单流速度天花板在 100-160 tok/s 区间；想要 150+ 的单流，论坛里的共识是上两张 R9700
为什么必须用 vllm-radiance 这个 fork
这是全文最重要的一个坑。9 月初一位机主测了整整两天 vLLM，装了三种不同版本，结果差异极大：
| 引擎版本 | prefill | decode |
|---|---|---|
| 某原生 ROCm 版 | ~1200 tok/s | 最低只有 15 tok/s |
| 另一版本 | ~1200 tok/s | 明显偏慢 |
| vllm-radiance 1.0.15 | 2300-3300 tok/s | 思考 40 / 编程 70-80 tok/s |
原因在启动日志里看得很清楚。RDNA4（gfx1201）没有原生 MXFP4 运算单元，原生映像会退回"BF16 高精度模拟反量化"——等于每次 GEMM 都先反量化再算，算力白费。而 vllm-radiance 为 gfx1201 实现了 RadianceMxfp4W4A8LinearKernel（W4A8 fp8-WMMA GEMM）和 R4D attention 后端，启动后日志确认全部生效：
Using RadianceMxfp4W4A8LinearKernel for MXFP4 GEMM
[radiance] R4D kernel selection: libr4d 全部 query 解析成功
[radiance.gdn] all-R4D prefill / decode(fused) / prefill+spec path live还有一个容易吓到人的假警报：启动日志里会出现一行 The current platform does not support native MXFP4/MXFP6 computation——这是 quark 模块另一支 supports_mx() 调用的误报，上游 repo 文档里已注明，不代表 MXFP4 kernel 没启用。判断真实状态只看上面那三行 Radiance kernel 日志。
三套方案，按省事程度排
方案 A：paiton 打包镜像（最省事，推荐先试）
9 月底的帖子给了现成镜像，27B NVFP4 + DFlash2 投机解码全配好：
docker run -d --name qwen38 --network host --ipc host \
--device /dev/kfd --device /dev/dri --group-add video \
-e ROCR_VISIBLE_DEVICES -e HIP_VISIBLE_DEVICES -e CUDA_VISIBLE_DEVICES \
-e PAITON_NGRAM_CODRAFT=1 -e PYTORCH_ALLOC_CONF=max_split_size_mb:64 -e RADIANCE_GDN_LAZY=0 \
-v /data/models/qwen38-nvfp4:/models/target:ro \
-v /data/models/qwen38-dflash2:/models/draft:ro \
--restart unless-stopped \
ghcr.io/eliovp/paiton-vllm-plugin:qwen38-rocm10-vllm029-65k-20260924-r3 \
serve /models/target --tokenizer /models/target \
--served-model-name Qwen3.8 --host 0.0.0.0 --port 8080 \
--tensor-parallel-size 1 --max-model-len 65536 --max-num-seqs 1 \
--max-num-batched-tokens 4096 --kv-cache-dtype fp8 \
--gpu-memory-utilization 0.98 --attention-backend R4D \
--enable-prefix-caching --enable-chunked-prefill这位机主的结论：prefill ~3.3k、decode 100-110，"比裸跑快一个量级"。260W 功耗，支持多模态（10 张图，每张 512-16K tokens）。
方案 B：vllm-radiance 裸配（要榨性能看这个）
9 月初的完整实测方案，模型是 amd/Qwen3.8-27B-Quark-AWQ-MXFP4（主）+ tcclaviger/Qwen3.8-27B-DFlash2-FP8（draft），关键参数：
| 参数 | 值 |
|---|---|
| tensor-parallel-size | 1（单卡） |
| gpu-memory-utilization | 0.98 |
| kv-cache-dtype | fp8（固定分配 ~7.3GB） |
| max-model-len | 163,840（约 160K） |
| max-num-batched-tokens | 8,192（后调 2,048 更稳） |
| attention-backend | R4D |
| speculative decoding | dflash，num_speculative_tokens=7，TRITON_ATTN |
| prefix caching | 开启 |
| no-async-scheduling | 是 |
| tool call / reasoning | qwen3_xml parser / qwen3 |
| 生成配置 | temperature 0.7 / top_p 0.95 / top_k 20 |
方案 C：NVFP4 权重（换量化方案）
同款 fork，把权重换成 unsloth/Qwen3.8-27B-NVFP4，max-model-len 可以拉到 225,000（NVFP4 上限），KV 给到 8.6GB。9 月 19 日的完整测试报告含全部启动命令（含 speculative-config 和 compilation-config 的 JSON），配置上和方案 B 基本一致，只是权重和上下文上限不同。
实测数据（全部来自单卡 R9700）
Prefill：对上下文长度基本不敏感
| prompt 长度 | prefill 速度 |
|---|---|
| 8K | 2,319 tok/s |
| 32K | 2,589 tok/s |
| 64K | 3,311 tok/s |
| 128K | 2,609 tok/s（45.5 秒填完） |
| 256-4K（NVFP4 测试） | 2,249-2,884 tok/s |
128K 上下文 45 秒填完，对本地跑 27B 来说非常能打。长 prompt 时速度略降（瓶颈从 compute 转向显存带宽），但没有断崖。
Decode：投机解码是主力
- 单流：思考模式稳定 ~40 tok/s，写代码场景 70-80 tok/s
- 峰值：NVFP4 测试里短输出（128 tokens）测到 161 tok/s，长输出回落到 101-120（KV cache 压力）
- 投机解码接受率：DFlash2 整体 ~35%，position 0 接受率 69%、逐位递减到 position 6 约 15%——前几位是主要贡献者
- 有人试了 vLLM 内置 MTP 对比：只有 900 多 prefill、30 左右 decode，确认 DFlash2 效果明显更好
并发：8 路聚合 152 tok/s
| 并发路数 | 聚合速度 | 单路 |
|---|---|---|
| 1 | 41.5 tok/s | 41.5 |
| 2 | 61.4 tok/s | 29-34 |
| 4 | 113.5 tok/s | 25-42 |
| 8 | 152.4 tok/s | 27-42 |
日常用 2 并发很舒服；2 并发同时跑重度编程任务就别想了，会整体拖慢。
prefix cache 是隐藏大招：实测命中率 75.9%（1.85M / 2.44M），新会话 3 秒就开始输出——这正是 prefill 能"破 3000"的另一个原因。
四个坑，都是真实踩出来的
坑一：显存差 2G 装不下
同款配置有人复现时显存不够（多了约 2G），他自己的开机占用 100MB 而人家 65MB。解法就两条：关掉所有图形界面（纯 LLM server 模式）+ language-model-only 不载多模态。这两条做到，32G 全部榨给推理。
坑二：长上下文档别开并发
9 月 27 日的帖子把这事测得很透：200K context 档开 2 并发，只有线性扩展的 45%，GPU 六成时间空转，瓶颈在主机侧（CPU/内存带宽喂不饱）。他的结论原话："200K 档别开并发，想要并发请回 65K 档"（65K 档官方 8 路，聚合从 122.8 到 422.9）。
坑三：vLLM 日志的 prefill 数字不能信
"照论坛抄，pp 只有 1300，一度怀疑卡买错。翻日志才知 vLLM 只报 10 秒窗口均值，不能当 pp"——那位机主后来自写受控脚本才发现：空闲时 2.9k、一忙 1.3k，是排队不是算力。测性能要用随机 nonce 破前缀缓存 + TTFT 口径，别人的数据先看上下文档位再信。
坑四：ROCm 版本太旧，decode 慢 51 倍还 GPU 挂死
10 月 2 日刚出的帖子：Strata 跑 125B 时 decode 只有 1.2 tok/s（参考值 91），大 prompt 直接 GPU hang 后 SIGABRT。排查了硬件、磁盘、降频、NUMA、hugepage 全部排除，最后根因是编译用的系统 ROCm 7.2.1 缺 gfx1201 的 kernel 调优，换成 TheRock ROCm 7.10 后 decode 直接到 61.7 tok/s、prefill 1190 tok/s。注意 Strata 的 setup.py 会自动选中 /opt/rocm 里"≥7.0"的旧版本，要用环境变量骗过它。
和你现在的 llama.cpp 基线比
论坛里那位机主的直接对比（同一张卡）：
| llama.cpp + Q4_K_XL | vLLM Radiance + MXFP4 | |
|---|---|---|
| 思考模式 | 25-40 tok/s | ~40 tok/s（新会话 3 秒出字） |
| 写代码 | 50-75 tok/s | 70-80 tok/s |
| prefill | 常规水平 | 2,300-3,300 tok/s |
decode 差距不算断崖，但 prefill 是量级差——27B 级别的模型 prefill 破 2000 意味着长文档、大 system prompt、RAG 场景的体感完全不同。
什么时候才需要第二张卡
单流速度想上 150+，论坛共识很一致：上两张 R9700（双卡 TP 方案论坛里也有完整帖子，P2P 打通后 4 并发 × 160K 稳跑）。单卡的合理用法是：日常对话 + 2 并发 + 长上下文单路，这套组合下 27B MXFP4 是 32G 单卡能榨到的最甜点位。
数据出处
本文所有数据来自抡锤者论坛 4 篇 R9700 单卡实测帖（2026-09-06 ~ 2026-10-02），配置与数据可直接溯源：