vllm-project/vllm

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 链路，建议重点吸收其能力声明与契约测试的组织方式。

新增非 MegaMoE 共享专家分片选项，单卡省 16.98 GiB 显存

值得精读。核心看点：1) 用删除参数的方式把"场景是否可分片"从模型代码中移除，分片决策收敛到 env + 维度整除性，接口更简洁；2) `_disable_shared_experts_overlap` 通过 getattr 隐性契约耦合模型层与 FusedMoE runner，是一个值得记录的设计约定；3) PR body 中的 benchmark 脚本（CUDA graph + max-rank 同步 + 多 token 规模扫描）可作为模型级性能评估模板。使用时需明确边界：仅建议 PD 分离的 decode 节点 + 小 batch 场景开启。

Kimi-K2.5 ViT 编码器接入完整 CUDA graph 捕获

值得精读：这是 vLLM v1 encoder CUDA graph 协议的一份相对完整的模型侧实现范例，特别是 `pad_cu_seqlens()` 对 varlen attention 行数约束的处理、RoPE 尺寸约束下的 dummy 网格构造，以及用哨兵值表达 eager fallback 的权衡。建议重点对照 Codex 三条 P1 评论理解 CG 与 encoder DP、FlashInfer 之间的交互边界；若生产环境使用 K2.5/K2.6 且会开启 `flashinfer` 或 `mm-encoder-tp-mode data`，应等待后续修复或自行回填补齐。

显式管理 worker 的 torch 线程数，修复结构化输出解码 2-6x 吞吐回归

值得精读。这是一个从用户报障（#49013）到 bisect 定位、根因分析、系统修复、review 竞态再修复的完整范例，对任何做推理引擎或高性能服务的人都有参考价值。重点关注四个设计决策：① 启动期/服务期两阶段线程策略；② cgroup v1/v2 配额感知的可用 CPU 计数；③ 用环境变量所有权标记（`VLLM_OMP_NUM_THREADS_SET_BY_VLLM`）区分「系统设置」与「用户设置」；④ 将线程池创建前移到父进程以规避 dlopen 竞态与 fork 死锁。若在容器内跑 vLLM 或维护多 worker 部署，建议结合 #49013 的 bisect 日志一起阅读，理解 spin-wait 与 CFS 配额如何酿成 2 倍级性能落差。