vllm-project/vllm

修复 free_blocks 缓存关闭时块复用顺序被翻转的回归

值得精读。这是一个典型的"一行修复 + 深度语义讨论"案例：展示了队列头/尾操作如何静默改变 KV cache 复用语义，以及 review 中"最小改动 vs 性能重构"的取舍过程。对维护者而言，#48017 条件写反的教训表明：声称 no-op 的优化也需要验证行为等价性。建议阅读 `free_blocks` 的完整上下文、njhill 对 perf 数据的质疑，以及 orozery 关于 connector FIFO 假设的评论。普通用户直接升级即可。

投机解码调度预算自适应，低并发 TTFT 最多降 65%

值得精读：这是一次小改动（+54/-24）带来大收益（TTFT -55%~-65%）的典型性能优化，核心思想是把「最坏情况预留」改为「按实际调度动态记账」。重点关注 schedule() 中 input_budget 与 draft_slots 的四个记账点（RUNNING/WAITING/抢占归还/新请求）以及 vllm.py 中校验语义的放宽。若团队也维护投机解码部署，建议合入后在各自的注意力后端与模型组合上做一轮回归，并关注后续 benchislett 的可能 follow-on 意见。

canonical_layout 下保留 per-layer KV 注册，修复启动失败

值得精读，改动虽小但涉及 KV offload 与 canonical layout 两个设计约束的取舍。关注 prefer_cross_layer_blocks 的语义变化及其在调度器中的消费点，可作为理解 KV connector 配置体系的入口。

稳定 ROCm CI Docker 构建上下文与源码缓存

值得 ROCm 构建维护者和 CI 基建负责人精读，尤其是 `validate_ci_build_context_source()` 的物化上下文契约、Triton kernels 单一来源 stage 与 cache 刷新策略三处设计；对一般模型/推理开发者价值有限。建议关注后续 ROCm CI 实际命中率与失败的观测结果，并留意对非 pinned Triton 版本构建路径的兼容性。

修复 layerwise 加载遗漏注意力后处理，统一首载/重载生命周期

值得精读。对模型加载/RL 热更新链路的维护者，这是一个直接相关的 bugfix；对一般读者，亮点在于两处设计：一是用一个共享谓词同时约束标准加载与 layerwise 加载的延迟语义，二是 `_finalize_attention_layer` 用「kernel_tensors 是否为空」区分首次加载与 reload 两条生命周期，避免为首次加载单独维护一套路径。建议对照 `_layerwise_process` 与 `_reload_attention_scales` 的关系，理解「物化 + 重放」与「恢复 + 重放」两种模式的差异。

单槽导入缓存修复 packed IPC 多 chunk 传输的 producer 侧显存永久泄漏

值得精读。这是对 torch 跨进程 IPC refcount 语义的一次深入剖析，展示了'一次导出只能配对一次释放'的系统约束，以及用单槽缓存 + 精确释放时机解决协议失配的简洁设计。建议关注两个可改进点：把 fresh-export 假设固化为仓库内测试（当前只有临时 harness），以及在 PackedBufferImporter 中补充 key 不匹配时的显式替换语义注释，防止后续调用方误用导致双进程计数组失衡。

为 /generate 新增 content_parts 原始多模态输入

值得精读，尤其是评审中 SSRF 问题的发现与修复过程：它示范了「新入口复用时必须继承既有安全配置」的审查要点。建议关注三点：`_check_mm_fields_exclusive` 的互斥设计、`AsyncMultiModalItemTracker` 复用带来的防护一致性、以及 flat `MediaContentPart` schema 相对 RFC 原提案 `multi_modal_data` 的取舍。使用 /generate 做多模态推理的 RL 工程团队应直接采用该字段，并显式配置 `--allowed-media-domains`。

统一 spec-decode 测试基建，补 AMD CI 与失败诊断

值得精读。该 PR 是“大规模测试基建统一”的范本：vllm_runner 迁移中如何处理默认值语义差异（block_size/enable_chunked_prefill 显式传 None）、如何用共享工具函数收敛重复断言逻辑、以及如何在测试代码中做平台差异化（ROCm 的 AITER/FlashAttention 限制）都值得后续新增 spec-decode 测试时直接复用。重点文件是 tests/v1/e2e/spec_decode/utils.py 与 test_draft_model.py；若负责 CI 维护，还应关注 spec_decode.yaml 的 shard 平衡与新增 AMD 镜像。