vllm-project/vllm

Mooncake 改用全局 DP 索引，修复 wide-TP 崩溃

值得精读。该 PR 对理解 vLLM 并行配置中 `data_parallel_index`、`data_parallel_rank`、`data_parallel_rank_local` 三个字段的语义差异有直接帮助：`data_parallel_index` 是全局稳定的引擎标识，`data_parallel_rank_local` 只在部分启动路径填充，而 `data_parallel_rank` 在 dense-model DP 下会被重置为 0。对维护 KV connector 或分布式启动链路的工程师，这是一个"小改动、大修复"的典型示例，展示了"节点本地相对标识"与"全局唯一标识"在分布式寻址中的选择原则。

新增 logits NaN fail-fast 开关，CI 全局检测

值得精读，但精读重点不是代码量（仅 +60/-3），而是其设计演进过程：从 per-eval 指标抓取到全局 fail-fast 环境变量的转变，体现了 CI 诊断能力的基础设施化思路。可以关注 raise_if_nan_logits 的实现细节（成功路径零分配、异常消息携带请求级信息）以及 env 变量间隐式联动的写法；对需要构建类似检测开关的团队有参考价值。

SM100 新增 CuTeDSL 融合 query 内核，Triton 兜底

值得精读。本 PR 有两点设计可借鉴：一是分派闸门函数把'宁可不走也不要错走'的原则显式化，所有不满足条件的情况一律回退 Triton；二是'非 torch.compile 路径上不要注册 custom op'这一 review 结论，对后续 kernel 接入方式有指导意义。CuTeDSL 侧的 CTA 特化、PDL launch 与 inline asm 绕 bug 的写法也值得关注。建议阅读时结合 #48597 跟踪页理解其在系列中的定位，并留意后续是否补充与 Triton 输出的数值对比测试。

CI 通知工作流 PR 权限从只读改为写入

这是一个非常小的配置改动，无需精读。但值得关注的是权限配置的调整方向：在 GitHub Actions 中，`GITHUB_TOKEN` 的权限应遵循最小化原则，此 PR 将 `pull-requests` 从 `read` 提升为 `write`，建议确认确实需要该权限（例如工作流要评论 PR 或更新标签）。如果只是发通知，`read` 可能已足够。

GLM-5.2 PCP 评估启用 expandable segments 修复 OOM

值得快速浏览（约 5 分钟）：变更本身只有 1 行，但 PR body 的根因分析方法很有参考价值——区分表面超时与真实崩溃、用历史 Buildkite run 对照排除模型回归、把重复工作排查写进描述。设计决策上值得借鉴的是：将分配器行为收敛到确有内存压力的特定配置，而不是全局开启 `expandable_segments`，避免影响其他场景。建议关注后续是否有针对 FlashInfer MoE workspace 分配策略的长期优化 PR。

Humming 后端白名单新增 SITU，使能 Kimi-K3

建议快速阅读，可作为“为模型使能新激活”的最小变更范例。重点关注 `_supports_activation` 白名单机制与 `apply_moe_activation()` 回调的对应关系，理解声明与实现的契约边界。

Inkling 共享专家 partial 加法融合进 Lamport collective，单层省 1.6us

值得精读，尤其是 lamport.py 中 publish 阶段融合加法、避免单独 kernel launch 的思路，以及 model.py 中用 tuple 扩展数据契约的做法。建议关注：缺少自动化测试、NCCL fallback 的 in-place 合并语义、kernel 中 shared_ptr 占位传参的方式。若后续要推广到其他 MoE 模型，可以借鉴 `forward_partials` 的拆分模式。

TokenSpeed MLA 开启非因果融合解码，DSpark 草稿注意力提速达 7.3 倍

值得精读。PR 体积很小，但展示了两个可复用模式：一是后端通过静态能力属性（`supports_non_causal_multi_token_decode`）与类方法（`supports_non_causal()`）向上层宣传自身能力；二是将 metadata 中已有的 `causal` 信息显式透传给 kernel，从而解锁融合解码路径而无需改动 kernel。测试从单一 DCP 契约用例重构为双模式参数化测试的写法也值得参考。若团队在维护 MLA backend 或 spec decode 链路，建议重点吸收其能力声明与契约测试的组织方式。