vLLM AITER a4w4：高并发收益，为什么仍需显式开启？

1. 合并的是一条显式选择的执行路径

vLLM #58819 于 2026 年 9 月 30 日 07:07 UTC 合并，为 DeepSeek V4.1 的 ROCm／AITER MXFP4 MoE 增加 a4w4 路径。本文固定阅读提交 77e8b02c8d69。默认仍为 a8w4；VLLM_ROCM_USE_AITER_MOE_A4W4_DSV4=1 才申请 FP4 activation。两条路径权重均为 MXFP4。

开关在 FusedMoEConfig 初始化时解析，先要求 AITER fused MoE 已启用，再检查模型类型属于 deepseek_v41 或 deepseek_v41_text。其他模型类型会报错，包括同样采用 MoE 的 DeepSeek V4。合并代码还探测已安装的 aiter.fused_moe 是否接受 quant_dtype_a 参数；旧版本缺少该能力时，给出升级 AITER 或关闭开关的错误，而不是悄悄回退。

这些是模型与 API 能力边界。此次没有新增通用的 token 数、expert 数或隐藏维度白名单。实际执行仍受既有 backend、量化分支和 padding 约束，不能只凭开关判断最终使用的 GEMM。

2. activation dtype 与权重布局必须成对切换

沿调用链看，配置标记会同时进入 checkpoint MXFP4 和在线 MXFP4 的权重格式转换。oracle/mxfp4.py 将 use_separated_a4w4 转换为 is_guinterleave=False，交给 AITER 的 shuffle_weight 与 shuffle_scale；gate/up 权重及对应 scales 一起按 SEPARATED 布局准备。只在 forward 中强制 FP4，保留原来的 INTERLEAVE 布局，会破坏这组约定。

运行时的 rocm_aiter_fused_experts 在 MXFP4 分支选择 GateMode.SEPARATED，并将 q_dtype_a 设为 dtypes.fp4x2；封装层再以 quant_dtype_a 传给 AITER。原有 SITU 分支先于这个分支判断，继续使用自己的布局选择。默认 a8w4 则保留 INTERLEAVE，没有被该补丁统一替换。

因此这不是可以随意热切换的纯计算选项：布局在权重加载阶段已经确定，执行阶段必须读取匹配的布局。模型类型硬检查的价值也在这里。错误的开关可能影响加载格式，不能期待 forward 的另一条分支自动把已经变换的权重恢复回来。

3. 微内核检查怎样漏过真实模型错误

PR 作者报告，早期版本只强制 a4w4 activation，却保持 INTERLEAVE。该形状缺少调优后的 FP4 FlyDSL stage-1 配置，AITER 转入启发式 kernel。独立 MoE 测试的 cosine-similarity 检查没有发现问题，但真实模型 GSM8K 出现接近随机的准确率与乱码式推理。后续改为匹配的 SEPARATED 权重布局，才得到文中展示的模型结果。

独立算子的相似度不足以覆盖模型风险。加载变换、量化参数、路由分布与多层误差共同影响输出，测试样本也未必覆盖服务形状。上述失败经过来自作者报告，本文未独立重跑早期提交。

当前报告中，DeepSeek-V4.1-Flash、TP2、AITER MXFP4_BF16 backend 配合 DSpark 的真实 block rejection sampling，两条路径的 GSM8K strict／flexible 分数均为 0.9712／0.9704。作者另报 45 项测试通过、1 项既有 JIT 模块问题。相同分数支持该测试集上的一致表现，不等于逐 token 相同，也不是其他模型或任务的无损承诺。

4. +10.5% 的收益带着并发与采样前提

AgentX 性能测试每组运行 3600 秒，使用 aiperf 的 inferencex-agentx-mvp 场景，报告零请求错误。c1 的输出吞吐为 142.7 对 144.1 token/s，a4w4 下降约 1.0%；c8 为 404.1 对 404.5，基本持平；c64 为 303.4 对 274.5，上升约 10.5%。对应 c64 inter-token latency 为 138.8 对 149.0 ms，下降约 6.9%。这些结果来自 PR 作者，未在本站复现。

硬件来源也需分层：PR 正文未直接披露这组 A/B 的 GPU 型号与数量。链接的 InferenceX 参考 run 标有 MI355X，公开 job 同时包含 TP2 与 TP4；这确认了参考环境，不能据此补写作者实验的完整硬件配置。

关键边界是：这组 AgentX 性能数据使用 DSpark synthetic acceptance length 3.51；前面的 GSM8K 正确性测试使用真实拒绝采样。两组实验分别回答性能与模型行为问题，不能合并成“真实接受率下端到端提速 10.5%”的结论。也不能把不同并发点的吞吐直接解释为独立 kernel 的加速倍数。

数据呈现低并发略退、高并发受益的交叉，适合保留为 opt-in。PR 将其解释为量化固定成本与带宽收益的权衡，但两条路径的权重均为 MXFP4；仅凭这些数字不能归因为权重读取字节减半。activation 精度、布局和 kernel dispatch 同时变化，各自的贡献需要独立 profiling 或消融实验。

5. 部署判断先确认路径，再确认收益

准备评估时，先固定 vLLM 提交、AITER 版本和 checkpoint，记录模型类型、TP／EP、并发、实际 token 形状、shuffle 与最终 kernel。能力探测只证明参数可传入，无法保证目标形状的调优质量，也不替代模型准确率验证。

下一步可把实验分成两层：以固定 token／expert 分布测量量化、shuffle 之外的 steady-state GEMM、路由与通信时间；再使用真实 DSpark 接受行为、实际提示长度和请求分布，测输出吞吐、延迟尾部、错误率与任务准确率。该实验设计尚未执行，应保持默认 a8w4 作为配对基线。

这次合并把加载布局、运行时量化和 kernel API 作为同一契约。c64 的收益提供评估线索，c1 回退与兼容性检查划出使用边界。