vllm-project/vllm

模型执行路径再消除多组 GPU-CPU 同步

值得精读。这是 vLLM 官方维护者在 GPU 同步消除主线上的第二批落地，展示了一类可复用的性能优化范式：用主机侧已有精确数据推导设备端元数据、用 async 拷贝与 fill_ 消除隐式同步、用 keep_on_cpu 避免无意义 staging。建议重点阅读 `vllm/v1/attention/backends/mamba_attn.py` 的 `_prefill_cpu_metadata` 抽取与 `mamba2_attn.py` 的推导替换、`gemma4_mm.py` 的 per-device 索引缓存模式、`diffusion_gemma.py` 的 `init_canvas` 契约收紧。若你维护多模态模型或自定义 attention backend，需要对照检查自己的 `MultiModalFieldConfig` 与元数据构建是否也存在同类同步。

加固 tensor IPC 多进程测试，修复 ROCm 超时误报

值得精读。虽然只是单文件测试改动，但它展示了多进程测试中两个常被忽视的设计点：一是通过 `get_context('spawn')` 局部化 start method，避免全局 `set_start_method` 的副作用；二是失败路径的有界进程回收与带状态信息的超时诊断。`_cleanup_processes` 的 join / terminate / kill 阶梯式清理可以推广到 vLLM 其他多进程测试，建议在后续 IPC 与 kernel 相关测试中复用该模式。

KV 提升触发时改返回 HIT_PENDING，避免多余前缀扫描

值得与 RFC #51439 一起精读。这是一个典型的“枚举语义收紧”修复：用 1 行改动厘清 `RETRY`（位置不确定）与 `HIT_PENDING`（位置确定、物化中）的边界，并给出误用所致的 IO 开销量化证据。可继续关注 `vllm/v1/kv_offload/tiering/manager.py` 的 `lookup()` 扫描策略演进，以及 offloading scheduler 对 `HIT_PENDING` 消费逻辑是否有配套优化。

重写权重传输文档并统一 RL 示例到 vllm serve + HTTP 模式

建议精读，尤其是三类读者：做 RLHF/RL 集成的工程师（文档 + 示例直接决定接入方式）、计划自定义 weight-transfer 后端的人（base.md 的 WeightSource 双通道契约与 VLLMWeightSyncClient 结构型 Protocol 是核心设计）、以及维护示例库的团队（自启 server + sleep/wake 编排是值得复用的模式）。值得关注的设计决策：用"传输即客户端"（the transport is the client you pass）消解 IPC/NCCL 的 send_mode 概念；用单个 vllm serve --data-parallel-size N 取代多 actor fan-out；用分级 sleep/wake 在传输前腾出显存。

支持 Recipes 转换的多数据类型变体与策略选择

值得快速浏览，特别是使用 vLLM Recipes 工具的用户。关注点在于 `strategy_sources` 与 `select_strategy` 的实现，以及它们如何遵循 API 而不是本地合成 URL。该 PR 展示了工具脚本随 API 演进而扩展的典型方式。

加速 ROCm Skinny GEMM 测试，参数化从 11040 降到 2644

值得精读。该 PR 展示了两个可迁移的技巧：一是通过分析参数之间的独立性，用配对采样替代完整笛卡尔积，在不显著损失覆盖的前提下将用例数量级压缩；二是用 `skip_global_cleanup` + 模块级 autouse fixture 把高频的元成本从“每用例”降为“每模块”。对 kernel 测试维护者和 CI 效率优化者均有直接参考价值。

ROCm 启用双流 shared experts 解码，DP 下 TPOT 提升数个点

值得精读。这是跨平台双流调度的一次关键重构：事件化同步（enqueue/wait）替代 `wait_stream` 是保证 hipgraph 安全的核心设计，`_should_enable_stream_overlap_heuristic` 用 benchmark 数据驱动平台差异开关的做法也值得借鉴。建议重点阅读 `shared_experts.py` 的 `maybe_forward_async`/`wait` 与 `moe_runner.py` 的 `_forward_impl` 编排改动，并关注后续是否有测试补充。

在 ROCm gfx11 设备上启用 DeepSeek-V4 检查点支持

值得精读。改动虽只有 24 行，但体现了"最小变更解锁平台能力"的设计方式：通过 op 级 fallback 而非整体放宽平台能力判断来复用既有 AITER 稀疏索引器路径；同时 review 中关于保留原始守卫的坚持值得借鉴，可关注该模式在后续 ROCm 平台适配 PR 中的延续。