vllm-project/vllm

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 倍级性能落差。

新增 Mamba SSU 算法选择参数，吞吐最高提升约 6%

值得精读。PR 体量小（4 文件、+88/-5），但完整展示了'类型定义 → CLI 接线 → 配置校验 → 内核透传 → Mock 单测'的垂直实现链路，以及 review 驱动的设计演化：默认值从 'auto' 改为 None 延迟解析（保留'未指定'语义）、补日志、删除冗余测试。可关注的设计点：用 `Literal` 类型做配置契约并用 `get_args` 驱动校验；把默认值解析延迟到后端以区分'未指定'与'显式 auto'。阅读时留意一个未决点：flashinfer 版本约束是否需要收紧到支持 `algorithm` 参数的最小版本。

融合 AttnRes 前缀更新与归一化，AMD 解码吞吐 +14.2%

值得精读。两个核心看点：其一，如何用编译期常量开关（`HAS_DELTA`/`WRITE_BLOCK`/`APPLY_OUTPUT_NORM`）在一个 Triton 内核中组合 7 个算子的同时保持数值语义逐位一致，特别是 BF16 存储精度往返的设计；其二，性能 PR 的完整验证链条（契约测试矩阵、HIP graph 重放、GSM8K 双评估器、独立 cherry-pick 复测）可作团队模板。建议关注后续 #50682 跨层 delta 交接是否落地，以及融合内核在 Triton 升级后的稳定性。

EP 过滤识别 `.weight_packed`，修复冗余加载

建议快速阅读。核心改动仅 1 行，但揭示了一个值得注意的数据契约问题：checkpoint 张量命名后缀承载着所有权与过滤语义，加载过滤逻辑必须跟随量化打包格式演进。可与上游 PR #48891 对照阅读，理解 EP 过滤信息从生成（`local_expert_ids`）到消费（`should_skip_weight`）的完整链路。对涉及量化 MoE + EP 部署的团队，建议合并后补充一次真实 checkpoint 的端到端加载验证。