执行摘要

本 PR 修复了 Qwen3.5/Qwen3-Next 模型中 Gated Delta Net 层在 V1 profiling 阶段因 Triton autotuner 未触发导致的首次推理 OOM 问题。通过在 profiling 阶段运行小规模前向传递来预热 kernels，确保 autotuning 在内存充足时完成，从而避免运行时内存竞争。该修复仅影响非 SM90 GPU（如 RTX 5090），提升了模型推理稳定性和资源利用率。

功能与动机

本 PR 旨在解决 Qwen3.5/Qwen3-Next 模型在非 SM90 GPU 上因 Triton autotuner 触发 OOM 的问题。根据 PR body，在 V1 profile 运行中，_forward_core 因 attn_metadata 为 None 而提前返回，导致 chunk_gated_delta_rule 中的 Triton-autotuned kernels 从未被调用。随后，KV 缓存分配占用大部分 GPU 内存，首次推理时 autotuner 进行基准测试所需临时内存引发 OOM。此问题仅影响使用 Triton 路径的 GPU（非 SM90），SM90 GPU 使用 FlashInfer 路径无此风险。

实现拆解

实现集中在 vllm/model_executor/models/qwen3_next.py 文件，主要改动如下：

1. 新增 _warmup_prefill_kernels 方法：使用 dummy tensors（B=1, T=16、32、64）调用 chunk_gated_delta_rule，覆盖 chunk_fwd_kernel_o 的所有可能 BT 值（16、32、64），其他 kernels 使用固定 BT=64。方法中从模型配置获取参数，确保 autotune key 与真实推理匹配。
2. 修改 _forward_core 方法：在 attn_metadata 为 None 时调用 _warmup_prefill_kernels，确保在 profiling 阶段完成预热。
3. 代码优化：移除不必要的 @torch.no_grad，添加异常处理日志，使用 get_state_dtype() 增强配置鲁棒性。

评论区精华

评审讨论中突出了以下技术交锋：

• 日志优化：gemini-code-assist[bot] 指出："The logger.info call is currently outside the try...finally block... leading to a potentially misleading success log message." 作者及时修正，将日志移入 try 块。
• 设计权衡：ZJY0516 询问："Do we also need to warmup decode kernel?" 作者解释："The decode path does not need warming up... uses fixed parameters and no autotune." 确认仅预热 prefill 路径。
• 上游同步：lgeiger 提到："Upstream removed the different BT values... Should we do the same?" 讨论指向后续评估，反映了对依赖管理的关注。

风险与影响

风险分析：

• 新增代码可能引入异常处理缺陷，但 warmup 使用小 tensor 且已测试，风险低。
• autotune key 覆盖不完全的风险已通过验证 T=16、32、64 解决。
• 兼容性风险限于特定硬件，无全局影响。

影响分析：

• 用户受益于 OOM 问题的解决，Qwen 模型在非 SM90 GPU 上推理更稳定。
• 系统层面，profiling 时间微增但避免运行时内存瓶颈，提升整体性能。
• 团队可借鉴此模式优化其他内存敏感场景。

关联脉络

本 PR 与历史 PR #37975 相关，后者将 GatedDeltaNetAttention 提取为共享层，统一了 Qwen3Next 和 Qwen3.5 的实现。这表明 vLLM 项目正在持续重构模型组件以提升代码复用性，本 PR 的修复可能受益于这种架构演进。此外，review 中提到的 issue #38343 涉及上游同步问题，暗示未来可能进一步简化 warmup 逻辑。整体上，此 PR 是 vLLM 在优化高性能注意力机制和内存管理方面的持续改进的一部分。