vllm-project/vllm

全词表 EAGLE3 草稿跳过冗余重映射，对齐 dspark 契约

值得精读，但只需 10 分钟：改动只有 24 行且集中在三处结构相同的构造逻辑。建议重点关注三个设计点——(1) 用 `None` 作为身份映射的 sentinel，把判断从热路径挪到构造期，是这类「参数化语义」的经典手法；(2) 比较对象选择 `vllm_config.model_config.get_vocab_size()` 而非草稿配置自身，这个选择决定了哪些真实模型能命中快速路径；(3) 维护者删除测试的权衡是否可接受。若后续要控制维护成本，更经济的做法不是放弃守卫，而是把这段条件逻辑抽成一个共享 helper（例如 `maybe_create_draft_id_to_target_id()`），在 eagle3 / dspark / dflash 之间复用，既消除四处重复代码，也能用单测覆盖一个函数而不是四个模型。阅读时另需注意本 PR 由 AI 辅助（Claude Code / GLM-5.3）编写、作者自审，且关键契约确认（@benchislett）未获回复。

Gemma 4 unified 变体按音频预算推算 dummy 长度，修启动崩溃

值得精读，但重点不在 diff 本身（新增一个 24 行的 helper），而在两处：一是 PR 描述对 latent bug 触发条件的完整推导——`compute_mm_encoder_budget` 的 `max()` 选择机制、per-item token 对比表（image 280 / audio 750 / video 2496）、以及 `min(t, audio_seq_length)` 与 25 token/s 分帧如何把 750 token 绑定到 30.0 s，这套分析可以复用到其它多模态模型的 dummy 输入与 profiling 问题上；二是 `getattr` 探测改为 `isinstance` 分流的评审交锋，作者在 commit message 中对「症状 vs 类型区分」的总结值得借鉴。阅读时建议同时关注 PR 描述末尾关于 `fft_length` 语义的遗留问题，它是后续可能的独立修复入口。

多 API server 进程共享全局准入计数

值得精读，尤其是负责前端多进程、过载保护与背压的工程师。建议重点关注三个设计决策：一是用 cache line 对齐槽位 + 单写多读实现无锁跨进程计数器（以及 64 字节常量为什么必须显式写出）；二是把“硬上限”主动降级为“近似全局上限”并用 docstring 固化契约，这是本次 review 最有价值的结论，也是引入任何跨进程准入机制时都要面对的取舍；三是把计数刷新挂在 `OutputProcessor` 的 add/abort/finish 三个生命周期出口上，理解这一点才能判断计数什么时候可能失真。落地前建议补两件事：在 `SchedulerConfig`/CLI 帮助文本中同步“近似”措辞，并考虑进程异常退出时的槽位回收或周期性重算。

修复 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 工具维护者和性能团队阅读。