vllm-project/vllm

放宽 CuPy 依赖约束，仅排除坏版本 14.1.0

此 PR 改动极小，不值得精读实现，但其“用 != 精确排除坏版本、待上游修复后立即放开”的依赖 pin 治理思路值得记录参考。若要评估是否合入，重点确认 14.1.1 在运行时镜像上的 CI 结果。另外可关注 #44258 与 #42599 是否构成同一 CuPy 依赖治理线索。

修复 DP 多引擎启动时 CPU 线程超订阅，均分启动线程数

值得精读。虽然源码改动只有 5 行，但这是一个“一行修复背后有严谨故障定位”的典型案例：Issue #52330 对线程超订阅的量化分析（4×224=896 线程、日志中 `local_world_size=1` 的直接证据）非常值得学习。建议重点关注三点： 1. `max(1, data_parallel_size_local)` 的兼容性设计——用最小改动同时保证 TP-only 与 headless 行为不变； 2. 测试中 `object.__new__ + monkeypatch + 自定义中断异常` 的轻量级单测手法，避免了拉起真实多进程/GPU 的高成本； 3. v1 `MultiprocExecutor` 中节点级资源预算的计算入口，后续若引入新的节点级并行维度（如新的数据并行变体），应统一在此处扩展。

恢复 Torch 默认值并锁定 DSV4 scratch 为 FP32，修复 ROCm CI

值得快速精读，改动仅 22 行、逻辑直白，但对测试编写者有实际借鉴价值。两个设计决策值得关注：(1) 用 autouse fixture 统一管理进程级单例状态（默认 dtype、device、lru cache），并用 try/finally 保证失败也能还原；(2) 治本与治标结合——既消除污染源，又让下游用例对 dtype 显式化、不再依赖执行顺序。若仓库内还有其他测试存在裸改全局 torch 默认值的情况，建议按同一模式收敛。

deepep_v2 接收端用 repeat_interleave 替代逐专家 fill_ 循环

建议精读。这是一个小而典型的 MoE 通信热路径优化案例：一是展示了如何把「逐专家 Python 循环 + 多次 fill_ 内核启动」压缩为单次 torch.repeat_interleave；二是展示了 rank 常量（arange + offset）按设备缓存的设计，减少每层每 step 的冗余建张量开销。值得关注的设计点是 output_size 参数对输出长度的显式约束，以及缓存键（numel + device）与实例不可变偏移的一致性假设。若后续要在此基础上扩展，建议补充一个针对 _receiver prefill 分支的单元测试，锁定 topk_ids 顺序语义。

class 作用域提前释放共享 engine，修复 ColBERT 测试 VRAM 回归

值得精读，尤其适合负责 GPU CI 稳定性的同学。核心学习点是 pytest fixture scope 的 teardown 时机对显存敏感测试的影响：module 作用域 fixture 的释放太晚，会与后续自建 runner 的测试产生 VRAM 竞争；class 作用域则把释放提前到类结束。另一个可借鉴的设计是"共享 engine 用例收进类、自建 runner 用例留在模块级"的混合编排，既有提速又不牺牲隔离性。建议后续观察是否需要一个更显式的 engine 释放机制，而不是依赖 scope 顺序这一隐式约定。

将解码器槽位状态迁入模块级单例，封堵上限绕过

值得精读。它展示了 Python 类继承中一个极为典型的陷阱——ClassVar 增强赋值（`cls.x += 1`）会在子类上创建影子属性，凡是依赖多后端 mixin 共享状态的代码都可能踩坑。建议重点关注 `_PyNvDecoderPool` 单例 + `_fresh_decoder_pool` 测试隔离的组合模式，以及 `_borrow_decoder_slot()` 中"借用、创建失败回退、归还唤醒"的完整状态机。

修复 LoRA MoE 专家参数映射前缀顺序错误

值得精读。这是一个小而关键的数据契约修复：2 行改动修复了 LoRA + MoE 权重同步的完整阻断路径，展示了'参数命名顺序即隐式接口'的工程教训。重点关注 `build_expert_params_mapping` 中 `param_name` 与 `weight_name` 两侧前缀顺序相反的设计，以及重构（#41184）如何悄悄破坏这种隐式契约；同时应留意缺少单元测试这一短板。

新增 JIT warmup 注册表与编排，迁移 block-table 内核预热

值得精读。这是 vLLM 启动期 JIT 预热架构的地基 PR，重点看三处设计：VllmJitKernel 的 CompileKey/dispatch/get_warmup_keys 契约如何让预热 key 与运行期特化严格一致；`named_parameters` 对 `**kwargs` 转发的支持如何在静态可见性与低样板之间取舍；`triton_scalar_specialization_rep` 对 Triton 缓存键类的精确建模。合并前建议复核 kernel_warmup() 中非 v2 runner 分支与新增 registry 编排的执行顺序，以及 enable_jit_warmup 默认值对老路径的兼容性。