执行摘要

• 一句话：B12x MoE 新增 GELU tanh 支持，解锁 Gemma 4 NVFP4
• 推荐动作：这是一个小而明确的功能补齐，值得快速浏览以理解 B12x MoE 模块的激活契约设计。重点关注 _ACTIVATION_MAP 与 _supports_activation 的同步关系，以及激活名字符串与 FlashInfer 内核版本的耦合。建议后续为 Gemma 4 NVFP4 走 flashinfer_b12x 后端补充一个端到端或算子级测试，避免类似激活类型遗漏再次出现。

功能与动机

PR body 明确说明目的是让 Gemma 4 NVFP4 能用 --moe-backend flashinfer_b12x：FlashInfer B12x MoE 后端原先只接受 silu 与 relu2 两种激活，而 Gemma 4 使用 GELU-tanh 激活，因此会被 _supports_activation 能力检查直接拒绝。作者在 DGX Spark 上用 nvidia/Gemma-4-26B-A4B-NVFP4 配合 FlashInfer 0.6.16.post3 做了实测验证。

实现拆解

1. 在 vllm/model_executor/layers/fused_moe/experts/flashinfer_b12x_moe.py 的类属性 _ACTIVATION_MAP 中新增 MoEActivation.GELU_TANH 到 "gelu_tanh" 的映射。该映射最终作为激活名字符串传给 FlashInfer 的 b12x_fused_moe 内核，是内核层的字符串契约。
2. 同步更新静态方法 _supports_activation，在原来的 (MoEActivation.SILU, MoEActivation.RELU2_NO_MUL) 元组中增加 MoEActivation.GELU_TANH。这样才能通过框架层的后端能力检查，让 Gemma 4 模型选择该后端。
3. 本次改动没有新增或修改测试文件，也未涉及配置项与部署脚本；验证方式为维护者在 DGX Spark 上针对 Gemma 4 26B A4B NVFP4 的手工运行。由于激活名与 FlashInfer 版本强相关，后续如果升级 FlashInfer 需要留意该字符串是否仍然被内核支持。

关键文件：

• vllm/model_executor/layers/fused_moe/experts/flashinfer_b12x_moe.py（模块 MoE专家层；类别 source；类型 data-contract；符号 FlashInferB12xExperts._ACTIVATION_MAP, FlashInferB12xExperts._supports_activation）: 这是本次变更唯一修改的文件，承载了 FlashInfer B12x MoE 后端的激活映射与能力声明，是解锁 Gemma 4 NVFP4 使用 flashinfer_b12x 后端的关键入口。

关键符号：FlashInferB12xExperts._supports_activation

关键源码片段

vllm/model_executor/layers/fused_moe/experts/flashinfer_b12x_moe.py

这是本次变更唯一修改的文件，承载了 FlashInfer B12x MoE 后端的激活映射与能力声明，是解锁 Gemma 4 NVFP4 使用 flashinfer_b12x 后端的关键入口。

class FlashInferB12xExperts(mk.FusedMoEExpertsModular):
    # 将 vLLM 的 MoEActivation 枚举映射为 FlashInfer b12x 内核接受的激活名字符串。
    # 新增 GELU_TANH 映射用于支持 Gemma 4 系模型（Gemma 4 使用 GELU-tanh 激活），
    # “gelu_tanh” 是 FlashInfer b12x_fused_moe 内核侧的字符串契约，需与内核版本匹配。
    _ACTIVATION_MAP: dict[MoEActivation, str] = {
        MoEActivation.SILU: "silu",
        MoEActivation.GELU_TANH: "gelu_tanh",
        MoEActivation.RELU2_NO_MUL: "relu2",
    }
​
    @staticmethod
    def _supports_activation(activation: MoEActivation) -> bool:
        # 与 _ACTIVATION_MAP 保持同步：只有映射表里存在对应激活名的枚举才宣告支持，
        # 避免出现框架层允许、但内核侧无法解析激活名而启动失败的不一致情况。
        return activation in (
            MoEActivation.SILU,
            MoEActivation.GELU_TANH,
            MoEActivation.RELU2_NO_MUL,
        )
​
    @staticmethod
    def _supports_quant_scheme(
        weight_key: QuantKey | None,
        activation_key: QuantKey | None,
    ) -> bool:
        # b12x 在 kernel 内完成 BF16 -> FP4 激活量化，因此 W4A16 NVFP4 检查点
        # （activation_key=None）在运行时也兼容。这里维持原有 NVFP4 Static 权重契约不变。
        return (weight_key, activation_key) in (
            (kNvfp4Static, kNvfp4Dynamic),
            (kNvfp4Static, None),
        )

评论区精华

该 PR 没有实质性的技术讨论。claude[bot] 指出这是 fork PR，自动 review 被禁用；维护者 benchislett 触发了 CI（Buildkite CI #83360）并直接 approve。提交历史中第二次提交是 merge 分支回 main，未引入额外变更。

• 暂无高价值评论线程

风险与影响

• 风险：风险集中在 vllm/model_executor/layers/fused_moe/experts/flashinfer_b12x_moe.py 中 "gelu_tanh" 这个字符串与 FlashInfer 内核的版本契约：如果运行环境的 FlashInfer 版本不支持该激活名，会在内核调用期失败。_ACTIVATION_MAP 与 _supports_activation 两处必须保持同步，否则可能出现能力声明通过但内核无法解析激活名的不一致状态。此外本次改动没有新增测试，回归验证只能依赖人工与 CI，后续 Gemma 4 相关路径缺少自动化保护。
• 影响：影响范围限于 SM12x 平台（RTX Pro 6000 / DGX Spark）并启用 NVFP4 量化与 flashinfer_b12x 后端的用户，具体受益场景是 Gemma 4 系列 MoE 模型。对其他后端、其他平台、其他激活函数均无影响。改动体量小、行为可预期，对现有已支持的 SiLU / relu2 路径不产生回归。
• 风险标记：缺少测试覆盖, 激活名契约依赖 FlashInfer 版本, 映射表与能力声明需同步

关联脉络

• 暂无明显关联 PR