# R9700 单卡跑 Qwen3.8-27B MXFP4：prefill 3300 tok/s 的完整配置与 4 个坑

> RDNA4 没有原生 MXFP4 运算单元，原生 ROCm vLLM 会退回 BF16 模拟反量化慢 3-5 倍。4 组 R9700 单卡实测：vllm-radiance 原生 kernel 下 prefill 2300-3300 tok/s、decode 峰值 161 tok/s、8 并发聚合 152。附三套方案（打包镜像/裸配/NVFP4）完整启动参数和显存、并发、ROCm 版本四个坑。

![R9700 单卡 Qwen3.8-27B MXFP4 配置实战](/assets/articles/lcz/r9700-mxfp4-qwen27b-config/hero.jpg)

> 你正在用 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 投机解码全配好：

```bash
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），配置与数据可直接溯源：

- 单卡 vLLM Radiance + MXFP4 完整测试报告：lcz.me/topic/1529
- NVFP4 权重 DECODE/PREFILL 性能测试报告：lcz.me/topic/1820
- paiton-vllm-plugin 打包镜像折腾实录：lcz.me/topic/1963
- Strata 125B 单卡部署与 27B 对比（含 ROCm 版本坑）：lcz.me/topic/2046


---
来源：https://laobanclaw.top/articles/r9700-mxfp4-qwen27b-config/（AI 军火库）