vllm-project/vllm

修复 DSv4.1 DSpark 在 EPLB 下启动崩溃

值得精读，但重点不是 26 行源码，而是 abmfy 那段关于 deepcopy 生命周期的分析——它是理解 vLLM 草稿模型与目标模型“浅共享 config、深共享运行时状态”这一约定的最佳教材。建议关注三个设计点：一是为什么隔离点必须放在共享 `load_dspark_model()` 而不是模型私有文件（`vllm/models/deepseek_v4_1/nvidia/dspark.py` 的早期实现已被删除）；二是 `enable_eplb` / `num_redundant_experts` / `enable_elastic_ep` 为什么必须在一次 `replace()` 中原子关闭；三是测试如何用 fake config 复刻不变量来锁定“原子性”。如果要在此基础上继续做，优先补齐草稿 MoE 关闭 EPLB 后的吞吐基准，以及在 EPLB multi-model 机制里支持异构专家拓扑。

Nemotron 潜在 MoE 省一次 all-reduce，修复 TP>1 解码回归

值得精读，且成本极低（21 行）：这是一个“用 21 行换 13% 解码性能”的高杠杆修复，同时是 latent-MoE 通信契约的一个范本。建议关注三处设计决策：其一，默认 False 的 opt-in 语义如何把风险限制在单个模型内；其二，量化判定为什么必须看构造好的层（`isinstance(self.fc2_latent_proj.quant_method, UnquantizedLinearMethod)`）而不是模型级 `quant_config`，这一条对任何做“模型级配置 = 层实际实现”假设的代码都有借鉴意义；其三，作者对“大 batch 下收益衰减”的诚实量化，说明通信延迟与带宽瓶颈的分野。若准备跟进后续工作，首要建议是补一个 mock `tensor_model_parallel_all_reduce` 的调用计数单测，覆盖 `reduce_commutative` 开/关两种情形；次要建议是把该契约写进 latent MoE 相关的设计文档，避免后来者在非线性 transform 上误设标记。

XPU CI 追加 deselect，摘除 llama3.2 工具调用用例

不建议精读源码（本 PR 无源码），但值得花 1 分钟了解“CI 豁免如何被记录”的反面案例：本次跳过既没写失败原因、也没留恢复条件，是典型的可维护性折损。建议关注三点：（1）由 Intel 侧补一个 tracking issue，写清 llama3.2 在 XPU 上的具体失败模式与预期恢复条件；（2）考虑把多处 `--deselect` 抽成 job 级别的变量或 quarantine 列表，便于批量回滚与审计；（3）对 `optional: true` 的作业建立定期 review 机制，避免 deselect 列表无限增长。

重构结构化输出与投机解码的约束起点契约

值得精读，且建议按「契约 → 消费方 → 测试」的顺序读：先看 `vllm/v1/structured_output/__init__.py` 的 `_get_constraint_start()`，它是整个 PR 唯一的语义来源；再看 `scheduler.py` 三个调用点确认新契约的用法；最后看 `test_structured_output_manager.py` 的 `FlowCase` / `_run_real_flow()` 理解验证方式。重点关注四个设计决策：(1) 用 `len + 1` 哨兵而非 `None` 表达「本窗口无约束」，三个消费点的 `>=` / `>` / `<=` 各有语义，不要「顺手统一」；(2) 降序扫描把语义从「第一次边界」改成「最后一次边界」，这对交错思考模型更合理但改变了行为；(3) 断言降级为日志是刻意的（避免 engine core 被打挂），代价是失败请求要等 accept 阶段兜底；(4) 「reasoning parser 必须无状态」目前只是文档契约，落地前不建议在生产上把 stateful parser 与投机解码 + 结构化输出组合使用。

Pooling 基准修复：度量完整响应体并支持 bytes_only

值得精读的小型 bugfix。它清晰展示了异步 HTTP 客户端中“延迟测量点”与“响应体消费”之间常见的陷阱，`iter_any()` 增量消费避免内存膨胀的做法有借鉴价值；`bytes_only` 无 metadata 时回退客户端估算的取舍也可作为后续协议设计的参考。适合 benchmark 工具维护者和性能团队阅读。

Rust 前端新增迭代 token 直方图指标

值得精读，尤其是只关注 Rust 前端的工程师：它示范了「指标句柄按 engine 预缓存 + 零值 series 初始化 + 在 dispatcher 单点采样」的完整落地套路，也是理解 vLLM 前端/引擎指标职责边界的一手材料。阅读时建议重点看三处：一是 `rust/src/metrics/src/request.rs` 中被删除的那段设计注释，理解为什么这次决定把统计放在前端；二是 `rust/src/engine-core-client/src/client/imp.rs` 中 `has_outputs` 与 sender 过滤的错位，判断是否需要用 `iteration_tokens > 0` 或 sender 命中数来收紧观测条件；三是 PR body 里对验证边界的坦诚说明，直接对应「缺少落库测试」这一后续待补项。

DSv4.1 接入 DeepGEMM Mega-mHC 融合核

建议精读，重点看三处：(1) `vllm/models/deepseek_v41/nvidia/ops/mega_mhc.py` 的分派条件与返回契约——它决定了哪些请求会走新内核、哪些留在 TileLang，是理解本 PR 行为边界的关键；(2) `vllm/utils/deep_gemm.py` 的惰性符号探测，理解「依赖缺失 = 静默降级」的设计取舍，评估是否要为生产环境补一条 warning 或能力探测指标；(3) `tests/kernels/test_mhc_kernels.py::test_deep_gemm_mega_mhc_correctness` 中的容差选择与 stream 预热 + CUDA graph replay 写法，这是判断数值安全边际的直接证据。若团队在 SM100 上跑 DSv4.1，建议在升级后对 mHC 阶段做一次 PTQ/精度回归对比，并确认部署环境的 DeepGEMM 确实提供 `mega_mhc`。

headless 模式提前导入 reasoning parser 插件，修复启动 KeyError

值得花 5 分钟精读，属于“改动小、信息密度高”的启动顺序修复。重点看三处：①`run_headless()` 中插件导入必须早于 `create_engine_config()` 的时序原因（配置期 `ReasoningConfig.initialize_token_ids()` 解析 `--reasoning-parser`）；②测试用 `_StopAfterEngineConfig` 异常 + `MagicMock.side_effect` 做“进入配置构造前必须已导入”的断言写法，是低成本验证启动顺序的可复用模式；③QwertyJack 提出的 CI 目录覆盖未落实，说明这条回归保护实际可能悬空——建议后续把该类测试迁入 `tests/entrypoints/launchers/` 或扩展 entrypoints-unit-tests 作业，同时考虑是否有其他 headless/DP 入口需要同样的插件预导入。