执行摘要

本 PR 对 DeepSeek-V4 稀疏 MLA 路径中的全局 top-k 索引内核做了一次“零行为变化”的编译期优化：把 stride、topk、block_size 等 5 个参数标记为 Triton 的 tl.constexpr，让内核在编译期完成常量特化。微基准显示内核延迟从约 7.50 us 降到 6.37 us（快 15.1%），端到端 serving 吞吐 +0.50%、TPOT -0.98%。改动仅 5 行，风险很低。

功能与动机

_compute_global_topk_indices_and_lens_kernel 负责在稀疏注意力中把 token 局部 top-k 索引映射成全局索引，并计算每个 token 的有效 top-k 长度。这些映射所需的 block 表步长、topk 数量、block size 等参数在一次运行中固定不变；作者将这类“运行时其实不变”的参数改为编译期常量，能让 Triton 在编译时特化循环与地址计算，减少运行时绑定的开销。PR body 用内核微基准（7.50 us → 6.37 us）和 vllm bench serve（吞吐 +0.50%）给出了直接证据，没有引用外部 issue。

实现拆解

1. 变更入口：vllm/models/deepseek_v4/common/ops/cache_utils.py 中的 Triton JIT 内核 _compute_global_topk_indices_and_lens_kernel。
2. 参数特化：把 global_topk_indices_stride、topk_indices_stride、topk、block_table_stride、block_size 这 5 个参数的类型标注改为 tl.constexpr；TRITON_BLOCK_SIZE 原本就是编译期常量，保持不变。
3. 调用方兼容：外层 compute_global_topk_indices_and_lens 通过关键字参数传入这些值，传入的 Python 整数天然满足 constexpr 绑定条件，因此调用代码与下游逻辑无需任何同步修改，这也是本 PR 只有 5 行改动的原因。
4. 验证配套：未新增单元测试；作者用一段随机 top-k 索引的微基准脚本单独测内核延迟，并用 vllm serve + vllm bench serve 做了 128 请求的端到端吞吐对比，Buildkite CI 三轮均通过。

本 PR 只修改了 Triton 内核的函数签名（5 个参数加 : tl.constexpr），函数体未被改动，且材料未提供可独立阅读的完整内核实现，因此这里不贴来源不可靠的片段。建议直接查看 vllm/models/deepseek_v4/common/ops/cache_utils.py 中 _compute_global_topk_indices_and_lens_kernel 的签名与调用点。

评论区精华

该 PR 没有实质技术讨论：作者 @chaunceyjiang 请求 @zyongye 审阅，zyongye 触发了两轮 Buildkite CI，claude[bot] 提示“fork PR 自动审查被禁用”，zyongye 最后直接批准通过。整个 review 属于流程性操作，没有设计权衡或未解决疑虑可提炼。

风险与影响

• 编译期特化副作用：Triton 会对每个不同的常量组合单独编译一份内核；若未来某个调用方用运行时变量传入这些参数，会在 launch 时报错或显著增加编译时间。当前工程内只有固定配置，无实际风险。
• 无新增测试：改动没有配套单测，回归保护依赖现有 DSV4 CI 用例；由于改动仅限类型标注且行为不变，风险可控。
• 影响面：仅 DeepSeek-V4/Flash 系列稀疏 MLA 的 top-k 索引计算路径，端到端提升约 0.5%，属于可累积的低成本优化，无 API、部署或配置变更。

关联脉络

本 PR 与 #52084（同样优化 cache_utils.py 中 sparse top-k 元数据内核，prefill 吞吐 +15%~37%）位于同一批 DSV4 性能优化线上，两者都聚焦于稀疏 MLA 的 top-k 元数据生成；#52212 则在同一文件族内继续做 ROCm/Triton 稀疏解码内核优化。后续可把这类“运行时不变参数打入编译期常量”的手法沉淀为仓库内 Triton 内核的通用性能规范。