执行摘要

• 一句话：修复 ROCm 平台 JIT 预热因编译不支持的 PDL 内核导致启动崩溃的问题。
• 推荐动作：此 PR 是一个针对特定平台启动崩溃问题的必要且低风险的修复。代码变更非常小且局部，逻辑清晰，直接解决了 Issue #56030 中描述的问题。审阅讨论显示作者采纳了社区建议，使修复更完整。建议所有使用 ROCm 平台部署 DeepSeek V4 的工程师关注此变更。对于其他内核维护者，可参考此修复审视自身代码中是否存在类似的平台条件不匹配问题。

功能与动机

根据 Issue #56030 的描述，在 PR #50176 引入新的 JIT 内核预热后，DeepSeek V4 在 ROCm 平台上的启动过程因编译包含 NVIDIA griddepcontrol PTX 的内核而失败。错误日志显示 ld.lld 无法将包含无效指令的 hsaco 文件链接成目标文件，导致 EngineCore 崩溃。该问题的根源是预热逻辑在枚举编译键时硬编码了 launch_pdl=(False, True)，而未像运行时分发那样根据平台过滤掉不支持的 PDL 变体。

实现拆解

1. 变更入口：修改了两个 JIT 内核预热的配置文件，分别是 DeepSeek V4 的融合 Q/KV RMSNorm 内核和融合逆向 RoPE FP8 量化内核。
2. 核心逻辑改造：在 get_warmup_keys 方法中，将 launch_pdl 参数从固定值 (False, True) 改为动态查询 current_platform.is_arch_support_pdl()。这使得预热逻辑的编译键枚举与运行时分发逻辑保持一致。
   - 在 vllm/models/common/ops/fused_qk_rmsnorm.py 中，将 launch_pdl=(False, True) 替换为 launch_pdl=current_platform.is_arch_support_pdl()。
   - 在 vllm/models/deepseek_v4/common/ops/fused_inv_rope_fp8_quant.py 中进行了相同的修改。
3. 影响：此更改确保了在 NVIDIA 平台上，JIT 预热仍会编译 PDL 和非 PDL 两种变体，而在不支持 PDL 的平台（如 AMD ROCm）上，则只预热非 PDL 变体。这修复了启动崩溃问题，并且无需修改运行时逻辑。

关键文件：

• vllm/models/common/ops/fused_qk_rmsnorm.py（模块 模型内核；类别 source；类型 configuration；符号 get_warmup_keys）: DeepSeek V4 融合 Q/KV RMSNorm 内核的预热配置文件，是修复的两个文件之一。
• vllm/models/deepseek_v4/common/ops/fused_inv_rope_fp8_quant.py（模块 模型内核；类别 source；类型 configuration；符号 get_warmup_keys）: DeepSeek V4 融合逆向 RoPE FP8 量化内核的预热配置文件，是修复的另一个文件，也是 PR #56048 遗漏的部分。

关键符号：get_warmup_keys

关键源码片段

vllm/models/common/ops/fused_qk_rmsnorm.py

DeepSeek V4 融合 Q/KV RMSNorm 内核的预热配置文件，是修复的两个文件之一。

# 在 get_warmup_keys 方法中，修改 launch_pdl 参数的枚举逻辑。
# 修复前：硬编码为 (False, True)，导致在不支持 PDL 的平台（如 AMD ROCm）上
# 也会尝试编译 NVIDIA 专有的 PDL 内核，引发链接错误。
launch_pdl=(False, True),
# 修复后：根据当前平台是否支持 PDL 来动态决定。
# 这确保了预热逻辑与运行时分发逻辑一致，避免了平台不兼容的编译。
launch_pdl=current_platform.is_arch_support_pdl(),

评论区精华

1. 竞争性修复方案：审阅者 @LopezCastroRoberto 指出存在另一个 PR #56048，其解决方案更简洁，但遗漏了 fused_inv_rope_fp8_quant.py 文件。他建议本 PR 的作者采纳 #56048 的风格。
2. 作者的整合：作者 @jimmy-adams 在第二轮提交中采纳了该建议，将代码风格统一为 launch_pdl=current_platform.is_arch_support_pdl()，并确保修复覆盖了被 #56048 遗漏的 fused_inv_rope_fp8_quant.py 文件。
3. 验证：作者提供了在 8x gfx950 (MI350-class) 硬件上使用 ROCm 7.2.3 的详细验证步骤和结果，证明修复后 DeepSeek V4 服务可以成功通过内核预热阶段并启动。

• 与竞争性修复方案 #56048 的整合 (design): 作者在第二轮提交中采纳了建议，将修复风格统一为 launch_pdl=current_platform.is_arch_support_pdl()，并覆盖了所有必要的文件，使修复方案更完整。

风险与影响

• 风险：
  1. 平台兼容性：修复的核心是正确利用 current_platform.is_arch_support_pdl() 进行平台判断。如果该函数本身存在缺陷或返回值不准确，可能导致问题。但这是项目内已有的标准判断机制（如在 vllm/models/deepseek_v4/compressor.py 中使用），风险较低。
  2. 功能回归：对于 NVIDIA 平台，预热行为未变（仍包含两种 PDL 变体），因此不会影响性能或功能。对于 AMD 平台，修复解决了启动崩溃，且运行时行为也因已有的平台过滤而保持正确。
  3. 遗漏风险：虽然本 PR 修复了这两个关键内核，但 Issue #56030 的描述中建议审计其他使用 tl.extra.cuda.gdc_* 或 launch_pdl=(False, True) 的内核。未来可能在其他内核中遇到类似问题。
• 影响：
  1. 用户影响：直接影响在 AMD ROCm 硬件上部署 DeepSeek V4 模型的用户。修复后，这些用户可以正常启用 JIT 内核预热（默认启用），从而获得更好的首次推理性能。此前，他们只能通过 --kernel-config.enable-jit-warmup=false 规避问题。
  2. 系统影响：修复范围限于两个 DeepSeek V4 相关的内核预热配置，不影响引擎核心、调度器或其他模型。变更是局部的，旨在恢复被 PR #50176 意外破坏的平台兼容性。
  3. 团队影响：此修复为团队提供了处理类似平台特定 JIT 编译问题的范例，即预热逻辑必须与运行时分发逻辑保持同步，遵循相同的平台条件。
     - 风险标记：平台兼容性修复, JIT 预热逻辑缺陷

关联脉络

• PR #50176 [4/N][warmup][DSv4] Migrate common attention kernels: 本 PR 修复的是由 PR #50176 引入的回归问题。#50176 在引入新的 JIT 内核预热时，未考虑平台差异，导致了本次修复所解决的启动崩溃。
• PR #56048 [Bugfix] Fix ROCm JIT warmup for PDL kernels: 这是解决同一问题的竞争性修复方案。本 PR 的审阅者建议采纳其更简洁的风格，但本 PR 修复了其遗漏的 fused_inv_rope_fp8_quant.py 文件。
• PR #49627 [Kernel] [1/N] warmup for DSv4: 这是跟踪 DeepSeek V4 内核预热迁移的父级跟踪 PR，本 PR 属于该系列工作的一部分，用于修复迁移过程中的平台兼容性问题。