2026-09-16
清理 4 处 no-op 自赋值，零行为变更
- **是否精读**：不需要逐行精读，属于低风险清理类 PR；但建议阅读 `vllm/multimodal/audio.py` 的 review 线程，它是「删死代码差点删掉潜在 bug」的典型案例。
- **值得关注的设计决策**：① `routed_experts.py` 中用 `quant_method_name in (...) and is_transposed` 替代嵌套 if，既满足 SIM102 又保留全部语义，可作为同类清理模板；② 类型分派场景下两个分支写法相同，往往意味着「意图未写完」而非冗余，删除前应先追问原始设计假设。
- **建议跟进**：为 audio.py 的 tensor 语义单独开 issue/PR（若确认是 bug，修复为 `else: audio` 并补 numpy/tensor 双路径测试）；评估在 ruff 中启用 `PLW0127`，让这类 no-op 在 CI 阶段被自动拦截；为 `deepencoder.py` 的 `patch_embeds` 传入路径补一条针对性单测。
退役 Buf schema 发布，统一到 crates.io 分发
值得花 10 分钟快速阅读，重点看三点设计决策：
1. **先立后破的渠道迁移模式**：先在 #56365 建立 crates.io 发布并让 Rust 前端消费同一 crate，再在本 PR 退役 BSR，避免出现无发布渠道的空窗期。
2. **保留 buf build/lint 而非整体删除 workflow**：发布路径可以退，但 schema 质量门禁不能退，且移除 owner 限定后 fork 也能校验。
3. **文档对消费契约的明示**：README 直接写明 "no longer published" 并给出替代路径，比在 release note 里提一句更可靠。
该 PR 逻辑直白，不需要深挖源码，适合作为“发布基础设施收口”的参考案例。
修复 warning_once 缓存异常对象导致的 LLM 实例内存泄漏
建议精读。改动本身很小，但揭示了 `logger.warning_once` 的 `lru_cache` 缓存参数这一容易被忽视的引用生命周期陷阱：向日志系统传入活对象（异常、traceback）会让去重缓存变成对象引用的永久锚点。PR review 中「只修具体调用点、不动日志层、不加测试」的取舍也很有参考价值——对于小而隐晦的修复，最小化改动面可以降低核心路径回归风险。关注点：该修复未根治日志层语义，后续若遇到类似告警去重 + 大对象组合，应回到 `warning_once` 的缓存契约上重新评估。
清理 8 文件 1895 行死内核代码，覆盖 AMD 与量化算子路径
值得快速浏览，不必精读。它展示了 vLLM 中临时代码生命周期的管理实践：在 docstring 中写明删除条件（如 AITER 修复版本），到期后由维护者执行清理。对于内核与算子维护者，建议关注两个设计决策：一是 lamport.py 中基于 PDL 的死锁规避证明方法，这是跨 GPU 通信 kernel 的高价值设计文档，即使代码被删除也值得从 git 历史中学习；二是 triton_fp8_mqa_logits.py 中针对 gfx942 LDS 预算的 tile 大小自适应判断，展示了 Triton kernel 在特定硬件上做 occupancy 与硬件上限双重校验的思路。另外，本 PR 完全没有 review 讨论，阅读时建议自行核对删除边界，或在需要修改这些目录时通过 git blame 追溯删除决策。
移除 /v1/score 别名上的嵌套装饰器，修复负载计数泄漏
值得花 3-5 分钟精读，但重点不在代码本身（+0/-2），而在它揭示的装饰器组合陷阱与 PR body 中的复现方法论。建议关注三点：(1) 记住 `with_cancellation`/`load_aware_call` 这类「每请求一次」的装饰器不可在委托链上重复应用，别名必须只做委托；(2) 参考作者用 `SimpleNamespace` + `asyncio.Queue` 伪造 ASGI receive 的验证手法，把该场景补成回归测试；(3) 顺带审一遍仓库里其他 deprecated 别名（如 rerank 之外的转发路由），确认没有残留的嵌套包装。
