MTP / DFlash2 / MXFP4 加速矩阵：N 卡 vs A 卡支持情况 + R9700 实测

N卡 vs A卡推理加速支持矩阵

同一个 Qwen3.8 27B，在 N 卡上开 MTP 快 2.5 倍，在 R9700 上却只比基线快一点点——甚至配错了还会掉速。这篇把 2026 年 10 月时点，MTP、DFlash2、MXFP4/NVFP4 量化、FP8 KV、前缀缓存这些加速技术在 N 卡（CUDA 线）和 A 卡（ROCm 线） 上的支持矩阵和实测数据一次讲清，数据来自 R9700 社区完整实测报告 + vLLM/SGLang 官方 release notes，口径全部标注。

先说结论

MTP：N 卡已原生支持且收益大（RTX 50 系 NVFP4 + MTP 快 2.5 倍）；A 卡能跑但 R9700 实测比 DFlash2 慢 2.8 倍 decode，只适合"不想挂外部 drafter"的场景
DFlash2：N 卡 A 卡都能用，A 卡 R9700 实测 decode 67 tok/s（spec=7），是 R9700 上的主力加速方案；spec tokens 硬上限 7，超了直接开机崩
MXFP4：N 卡（Blackwell）原生硬件支持；A 卡 RDNA4 没有 MXFP4 运算单元，通用 rocm/vllm 映像退回 BF16 模拟反量化，慢 3-5 倍——必须走社区 fork（vllm-radiance）才有原生 W4A8 kernel
量化选择：N 卡 Blackwell 选 NVFP4（NVIDIA 自研）；A 卡走 MXFP4（OCP 微缩放标准）+ 社区 kernel，两者硬件路径完全不同
单流 R9700 稳态 decode 约 40-127 tok/s（随配置），prefill 2300-3300 tok/s；decode 是带宽瓶颈、prefill 是算力瓶颈

一、环境硬件条件（这套东西要什么才能跑通）

A 卡 R9700（本文实测基线）

组件	规格 / 要求
GPU	AMD Radeon AI PRO R9700，RDNA4 / gfx1201 / 32GB GDDR6（640 GB/s）
引擎	vLLM 0.28.0（走社区 fork `magiccodingman/vllm-radiance:1.0.15`，非通用 rocm 映像）
系统	Linux（CachyOS 实测），ROCm；关闭图形界面后开机 VRAM 仅占 65MB
主模型	`amd/Qwen3.8-27B-Quark-AWQ-MXFP4`（19GB，MXFP4/W4A8）
Drafter	`tcclaviger/Qwen3.8-27B-DFlash2-FP8`（2GB，FP8，block 128）
关键 kernel	`RadianceMxfp4W4A8LinearKernel`（原生 MXFP4 W4A8 GEMM）+ R4D attention（仅支持 GQA=6）

为什么 A 卡必须走社区 fork：RDNA4（gfx1201）没有原生 MXFP4 运算单元。通用 rocm/vllm 映像遇到 MXFP4 会退回"模拟反量化"（BF16 高精度计算），速度落后 3-5 倍。社区 fork vllm-radiance 为 gfx1201 实作了原生 MXFP4 W4A8 kernel 与 R4D attention 后端——这是 R9700 能跑到 2300+ prefill 的前提。启动日志出现 "The current platform does not support native MXFP4/MXFP6 computation" 是 quark 模块另一支 supports_mx() 的误报，真实 kernel 状态以 RadianceMxfp4W4A8LinearKernel for MXFP4 GEMM 行为为准。

N 卡（对照）

档位	引擎	量化	说明
RTX 50 系 / Blackwell	vLLM 0.31.0 / SGLang	NVFP4 / MXFP4（SM100/SM103 原生）	NVFP4 走 torch linear backend（#53319）
H 系列数据中心	vLLM / SGLang	FP8 / NVFP4	DeepSeek-V4.1-Flash NVFP4 压缩 KV 成 SM100 默认

二、实测数据（全部带口径）

1. MTP vs DFlash2 正面对比（R9700，8 并发 / 4.2K prompt / greedy / 128 out）

指标	MTP spec=3	MTP spec=5	DFlash2 spec=7（采用）
decode（1/TPOT）	23.7 tok/s	23.9 tok/s	67.1 tok/s
e2e 吞吐	82.4 tok/s	55.6 tok/s	181 tok/s
prefill	897 tok/s	913 tok/s	2235 tok/s
draft 接受率	74.7%	59.4%	42.2%

结论：MTP 能跑，但 1 层 MTP 头每步自回归跑 N 次，spec 越多浪费越多——比 DFlash2 慢约 2.8 倍 decode、2-3 倍 e2e。 MTP 仅在需要"零外部 drafter 占用"时使用。另 MTP spec=5 在 7.25GiB KV 预算下无法开机（需 7.32GiB），spec≥4 要把 max_model_len 降到 160000。

2. DFlash2 spec tokens 数实验（8 并发 / 4K prompt / 128 out）

指标	spec=7（采用）	spec=5
decode	67.1 tok/s	60.6 tok/s
e2e	181 tok/s	162 tok/s
prefill	2235 tok/s	1747 tok/s
接受率	42.2%	50.5%

不能只看接受率：spec=5 单位接受率更高，但每步 draft 位置少，有效吞吐反而输。spec=7 全面胜出。

3. 生产负载实测（R9700，真实 agent 负载）

指标	数据
单路思考	稳定 ~40 t/s
编程场景	70-80 t/s
冷启动单序列 decode 稳态	~127 tok/s（batch=1，全 token 口径，7.9 ms/token）
prefill 冷启动	短 ctx ~2337 tok/s → 115K ctx ~1438 tok/s（随长度递减，KV 二次成本）
prefill 长 context	8K=2319 / 32K=2589 / 64K=3311 / 128K=2609 tok/s（稳定 2300-3300）
前缀缓存命中率	75.9% ~ 91.2%
DFlash2 接受率（生产）	26-29%（平均接受长度 2.83-3.04）
并发扩展（每路 max 256 tok）	1 路 41.5 → 8 路聚合 152.4 tok/s
对比 llama.cpp Q4_K_XL	思考 25-40 / 编程 50-75 t/s（vLLM+radiance 明显更快）

口径提醒：单流 127 tok/s 是 batch=1 全 token 吐速（reasoning token 占大头，纯 content 节奏仅 ~16/s）；210W 限功率下的数字（参考配置是 350W，功率差异会拉低 prefill）。

4. N 卡侧对照（官方 release + 社区口径）

指标	数据	来源
RTX 50 系 + Qwen3.6 27B NVFP4 + MTP	推理快 2.5 倍	社区实测（头条）
vLLM 0.31 MTP / EAGLE3 / DFlash / DSpark	均已支持（#46994 / #50514）	vLLM 官方 release
vLLM 0.31 NVFP4	torch linear backend（#53319）	vLLM 官方 release
vLLM 0.31 Fast Restart	含 MTP draft models（#57312）	vLLM 官方 release
SGLang MTP / Eagle 投机解码 / FP8 / 多 GPU	均支持（MTP #24955）	SGLang 官方 release
SGLang on ROCm	MI300X 首测通过（2026.6，RadixAttention 长上下文验证）	社区实测（CSDN，单源）

三、踩坑指南（按发生顺序，现象 → 原因 → 解法）

"平台不支持原生 MXFP4" 误报卡住判断：日志那行是 quark 模块另一支 supports_mx() 的误报。→ 看 RadianceMxfp4W4A8LinearKernel for MXFP4 GEMM 确认 kernel 真启用，别据日志误判 kernel 没开。
MTP 开了反而降速：1 层 MTP 头自回归 N 次 + A 卡带宽瓶颈，spec 越大浪费越多。→ R9700 上 MTP 只作备用，主力用 DFlash2 spec=7。
spec tokens > 7 直接开机崩：dflash2 draft window 8×(n+1)，n=10 时 torch.compile 把该维特化成常量 88 标为 DYNAMIC，torch.fx ConstraintViolationError 崩 EngineCore。→ 清缓存重编也无解，spec=7 是硬上限。
MoE 量化模型 decode 慢到 5.8 tok/s：MoE 量化模型（如 Qwen3.6-35B-A3B）在 radiance 映像走 on-the-fly 反量化，比 dense 27B+dflash 慢 4-8 倍。→ 已移除不保留，MoE 走 FP8 非量化路径。
INT4 drafter 无法加载：W4A16 Marlin pack 量化，linear 权重在 packed buffer，radiance DFlash loader 要求 dense .weight → AttributeError。→ 维持 tcclaviger FP8 drafter，改源码才行。
MAX_BATCHED_TOKENS 调高 OOM：8192→16384 使 activation/workspace 峰值翻倍，32GB（权重 19 + KV 7.25 已锁）长 prompt prefill 时 torch.OutOfMemoryError。→ 回退 8192；要重试先缩 KV_MEM。
Quark algo_config 非 null 崩 mapper：config.json 的 quantization_config.algo_config 若非 null，Quark mapper 把 dict 项当字符串 .endswith 检查 → AttributeError。→ 设 null 再加载（纯 mapper 兼容字段，不影响权重）。
R4D 后端只支持 GQA=6：GQA=8 的 MoE 模型（如 Qwen3.6）直接 NotImplementedError。→ 改 TRITON_ATTN 并关 R4D 环境变量。
MTP spec≥4 KV 不足：spec=5 需 7.32GiB > 7.25GiB 可用，engine-init 失败。→ 降 max_model_len 至 160000。

四、避坑指南（没踩但知道会翻车的）

N 卡 A 卡别混用量化格式：Blackwell 用 NVFP4（NVIDIA 自研，硬件原生）；RDNA4 用 MXFP4（OCP 微缩放标准）+ 社区 W4A8 kernel。两者硬件路径完全不同，把 NVFP4 模型直接丢给 R9700 只会退回 BF16 慢 3-5 倍。
别按 dense 参数估 MoE 显存/速度：MoE 激活小但 on-the-fly 反量化吃带宽，R9700 上直接慢 4-8 倍，dense 27B 才是当前 A 卡甜点。
单流快 ≠ 整机快：prefill（读整段 prompt）是算力密集，RDNA FP16/FP8 峰值算力不低，所以 prefill 能到几百上千 tok/s；decode（逐 token）才是带宽密集，是 AMD 卡真正的短板（单流 decode 40-60 tok/s 量级）。"prefill 猛"≠"整机猛"，agent 短请求场景 prefill 体验好，长生成/大上下文 decode 露馅。
接受率高 ≠ 吞吐高：spec tokens 选择看 e2e 吞吐，别只看接受率（spec=5 接受率 50% 但 e2e 输 spec=7）。
FP8 KV 不是"已校准 FP8"：checkpoint 无 q/k scale 时 vLLM 用 1.0 裸存（log 有 warning），对 27B 推理可接受，别当已校准 FP8 看待。
SGLang ROCm 消费卡别急：上游 ROCm 支持目前 MI300X 验证过，消费卡（RDNA4）gap 还在，主力推理继续走 vLLM + radiance fork 更稳。

五、配置清单（可照抄，分档）

A 卡 R9700 主力配置（实测验证）

参数	值
引擎映像	`magiccodingman/vllm-radiance:1.0.15`
量化	MXFP4（W4A8），`RADIANCE_MXFP4=1` + radiance 优化旗标（WPERM / HOIST_QUANT / EPIFAST / SKINNY_GEMM / R4D）
投机解码	dflash，`num_speculative_tokens=7`（硬上限），TRITON_ATTN
KV cache	`--kv-cache-dtype fp8` + `--kv-cache-memory 7,783,339,733`（7.25GiB 显式预算）
gpu-memory-utilization	0.98
max-model-len	163,840（想上 204,800 就把 max-num-batched-tokens 降到 2048）
max-num-batched-tokens	8,192（调高会 OOM）
max-num-seqs	8（长 agent 场景 2-4）
attention-backend	R4D（仅 GQA=6；GQA=8 改 TRITON_ATTN）
调度	`--no-async-scheduling`（实测 async 无收益）
MTP	仅备用（比 DFlash2 慢 2.8×，不推荐主力）

可用/不可用最终清单（R9700）

技术	状态
MXFP4（走 radiance fork）	✅ 能开，原生 W4A8 kernel
DFlash2 投机解码 spec=7	✅ 能开，主力方案
FP8 KV cache	✅ 能开（需显式指定，非默认）
Prefix caching	✅ 能开，命中率 75-91%
R4D attention	✅ 能开（限 GQA=6）
MTP	⚠️ 能跑但慢 2.8×，仅备用
spec tokens > 7	❌ 开机崩，硬上限 7
INT4 drafter	❌ 无法加载（W4A16 Marlin 不兼容）
MoE 量化模型	❌ on-the-fly 反量化慢 4-8×，不保留
NVFP4（直接丢 R9700）	❌ 退回 BF16 慢 3-5×，须走 MXFP4 路径
SGLang ROCm 消费卡	⏳ 上游 gap，继续等

N 卡 Blackwell 对照配置

参数	值
量化	NVFP4（`vllm serve unsloth/Qwen3.6-27B-NVFP4`）
投机解码	`--speculative-config '{ method: mtp, num_speculative_tokens: 2 }'`（vLLM 0.31 MTP #46994）
加速收益	推理快 2.5 倍（RTX 50 系实测）
可选	EAGLE3 / DFlash / DSpark（#50514）+ Fast Restart MTP draft（#57312）

硬件档位建议

档位	配置	适合
单卡 A 卡	R9700 + radiance fork + DFlash2 spec=7	27B 单流 40-127 t/s
双卡 A 卡	2× R9700（社区报告单流 150+ t/s）	70B / 高并发
N 卡消费级	RTX 50 系 + NVFP4 + MTP	2.5× 加速甜点
老平台升级	9950X + X870E（双 PCIe 5.0 x8/x8）+ R9700	host 调度瓶颈解除，撑到 2028

数据源：lcz.me t1529（R9700 完整实测报告，paul hou，2026-09-06，210W 限功率口径）、vLLM 0.31.0 官方 release notes（#46994/#50514/#53319/#57312）、SGLang 官方 release（MTP #24955）、RTX 50 系 NVFP4 社区实测（头条）、SGLang ROCm MI300X 首测（CSDN，单源）。单源/限功率口径均已标注。