Prhub

#52494 [AMD][kimik3][ROCm][Perf] Fuse MLA q/kv RMSNorm in AMD Kimi-K3 MLA wrapper

原始 PR 作者 rbrugaro-amd 合并时间 2026-09-04 18:14 文件变更 2 提交数 3 评论 15 代码增减 +123 / -2

执行摘要

为 AMD Kimi-K3 MLA 层实现融合 q/kv RMSNorm,提升解码性能。

Kimi-K3 模型(未标记 @support_torch_compile)在 eager 模式下运行时,MLA 层的 q_a_layernorm 和 kv_a_layernorm 保持为两个独立的 AITER RMSNorm 启动,引入不必要的内核启动开销。目标是将这对归一化操作融合为单个 fused_qk_rmsnorm 内核以提升性能,同时遵循 NVIDIA 侧已有的 vendor-local 模型布局(vllm/models/kimi_k3/nvidia/),保持共享 mla.py 的纯净。PR body 明确提到 "Pair per-MLA add_rmsnorm launches for the q/kv latents are gone",并提供了详细的性能对比数据。

该 PR 值得精读,特别是对于关注性能优化模式、硬件特定实现或 MLA 架构的工程师。它展示了一个将性能优化与代码结构保持清洁的良好实践:通过子类化实现特定硬件优化,而不污染共享代码。PR 中详尽的性能数据和准确性验证也值得学习。

讨论亮点

讨论的核心集中在性能数据的准确性上。争议点:用户 jamesETsmith 指出并发度 8 (C=8) 的 ITL/TTFT 数据与其他并发度的变化趋势不一致,质疑其为异常值。决策结论:作者 rbrugaro-amd 详细解释了差异原因:C=8 的基线和优化数据分别来自独立运行(idle-node)和扫描测试(zip sweep),前缀缓存混合情况不同。作者提供了修正后的、更一致的性能表格(所有并发度均来自同一次 zip sweep),消除了疑虑。未解决疑虑:无,讨论已闭环。整个 review 过程高效,主要集中在性能验证上。

实现拆解

  1. 新增 AMD 专用 MLA 包装器:创建 vllm/models/kimi_k3/amd/mla.py 文件,定义 KimiK3MultiHeadLatentAttentionWrapper 类,继承自共享的 MultiHeadLatentAttentionWrapper。
  2. 实现融合逻辑:在 __init__ 中检查 AITER 是否启用,设置标志 _use_eager_qk_rmsnorm_fusion。重写 _normalize_q_kv 方法:当标志为真且未编译时,调用融合算子 torch.ops.vllm.fused_mla_dual_rms_norm;否则回退到两个独立的 RMSNorm 层。
  3. 接入模型初始化:修改 vllm/models/kimi_k3/amd/linear.py,在 KimiAttention.__init__ 中,将 self.mla_attn 的实例化从 MultiHeadLatentAttentionWrapper 更改为 KimiK3MultiHeadLatentAttentionWrapper。
  4. 测试与验证:PR 未包含新增单元测试,但作者提供了详细的 torch profile 和 aiperf 基准测试数据(MI355X TP=8),证明了融合内核的生效和性能提升,并通过 GSM8k 评估确认了模型精度。
文件 模块 状态 重要度
vllm/models/kimi_k3/amd/mla.py MLA 包装器 added 8.85
vllm/models/kimi_k3/amd/linear.py 模型初始化 modified 5.51

关键符号

KimiK3MultiHeadLatentAttentionWrapper.__init__ KimiK3MultiHeadLatentAttentionWrapper._normalize_q_kv KimiK3MultiHeadLatentAttentionWrapper.forward

关键源码片段

vllm/models/kimi_k3/amd/mla.py core-logic

核心新增文件,实现了 AMD 平台 Kimi-K3 MLA 层的融合 RMSNorm 优化逻辑。

# vllm/models/kimi_k3/amd/mla.py
# ... (imports)
​
class KimiK3MultiHeadLatentAttentionWrapper(MultiHeadLatentAttentionWrapper):
    """Kimi-K3 MLA wrapper with eager AITER q/kv RMSNorm fusion."""
​
    def __init__(self, *args, **kwargs) -> None:
        super().__init__(*args, **kwargs)
        # 关键标志:检查 AITER 是否启用,用于后续融合路径选择
        self._use_eager_qk_rmsnorm_fusion = bool(rocm_aiter_ops.is_enabled())
​
    def _normalize_q_kv(
        self,
        q_c: torch.Tensor,
        kv_c: torch.Tensor,
    ) -> tuple[torch.Tensor, torch.Tensor]:
        q_layernorm = cast(RMSNorm, self.q_a_layernorm)
        kv_layernorm = cast(RMSNorm, self.kv_a_layernorm)
​
        # 核心融合逻辑:当 AITER 可用且未处于 torch.compile 编译状态时,
        # 使用单一的融合内核替代两个独立的 RMSNorm 计算
        if self._use_eager_qk_rmsnorm_fusion and not torch.compiler.is_compiling():
            return torch.ops.vllm.fused_mla_dual_rms_norm(
                q_c,
                q_layernorm.weight,
                kv_c,
                kv_layernorm.weight,
                q_layernorm.variance_epsilon,
                kv_layernorm.variance_epsilon,
            )
​
        # 回退路径:使用独立的 RMSNorm 层(兼容编译器图或其他场景)
        return q_layernorm(q_c), kv_layernorm(kv_c)
​
    def forward(
        self,
        positions: torch.Tensor,
        hidden_states: torch.Tensor,
        llama_4_scaling: torch.Tensor | None = None,
    ) -> torch.Tensor:
        # ... (forward 方法主体与基类逻辑基本一致,但会调用重写后的 _normalize_q_kv)

评论区精华

性能数据一致性质疑 测试

用户 @jamesETsmith 指出,原始性能表中并发度 8 的 ITL/TTFT 改善方向与其他并发度相反,询问是否为异常值。

结论:作者 @rbrugaro-amd 解释了差异源于测试方法不同(独立重跑 vs. 扫描测试),并提供了修正后、更一致的性能数据表格,确认了优化效果。 · 已解决

风险与影响

  1. 厂商锁定风险:将优化逻辑封装在 vllm/models/kimi_k3/amd/ 路径下,符合现有设计模式(如 NVIDIA 侧),避免了向共享核心代码引入 if ROCm 判断,维护风险可控。
  2. 向后兼容性:变更仅影响启用 AITER (VLLM_ROCM_USE_AITER=1) 且运行 Kimi-K3 模型的 AMD 环境。对于其他平台或未启用 AITER 的场景,行为不变。
  3. 编译器交互:通过 torch.compiler.is_compiling() 检查确保在 torch.compile 图中回退到基础实现,避免与编译器融合 pass 冲突,设计合理。
  4. 测试覆盖:PR 未包含新的单元测试来验证融合路径的正确性,但通过详尽的性能基准和模型准确性评估(GSM8k)间接进行了验证。
  1. 对用户:在 AMD ROCm (MI355X) 上运行 Kimi-K3 模型的用户将获得解码阶段的性能提升(吞吐量增加 1-5%,延迟降低),改善推理体验。
  2. 对系统:减少了内核启动次数,降低了 GPU 运行时开销。变更范围严格限定在 vllm/models/kimi_k3/amd/ 目录下,不影响其他模型或其他硬件后端。
  3. 对团队:为 vendor-specific 性能优化提供了一个清晰、可维护的模式(子类化共享层,在厂商目录实现)。后续其他 AMD 优化可参考此模式。
厂商特定实现 缺少直接单元测试

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。

完整报告

参与讨论