vllm-project/vllm

MRV2 增加无 pinned memory 平台回退缓冲

值得精读。改动虽小，但展示了如何用最小的接口调整（uva 属性改方法）来包装一个平台相关的回退实现，保持上层调用方无感。建议重点关注 NonUvaBuffer 的同步拷贝开销以及 StagedWriteTensor 在无 UVA 时的显存回退策略，这两处决定了新平台的性能与稳定性。若团队计划支持更多无 pinned memory 平台，可在此基础上补充针对回退路径的基准测试。

NIXL 多句柄传输竞态修复：失败上报与块失效延后

值得精读。重点看三处：(1) `base_worker.py` 的失败记账模型与 `_try_release_xfer_handle` 的「释放失败即保留句柄」语义，这是整个修复成立的基础；(2) `get_transfer_results` 中失败上报、block 失效、pending notif 撤回三件事被合并到同一次 `done_recving` 循环，理解这一时序才能评估后续改动；(3) push 侧 `done_pushing - failed_pushing` 加 `_recving_metadata` 过滤的双重条件，以及由 njhill 内联建议触发、随后被作者修正的 `pull_worker` 判空回归。评审阅读时建议顺带确认是否有超时兜底来覆盖「句柄永不终态」的情况，以及 HMA 的 TODO 是否有后续跟进项。

修复 EC E2E 脚本未同步 --enable-scale-out 导致的 CI 404

OTel GPU 采样器降权运行，失败则禁用采样

值得精读，但重点不在代码量，而在“权限边界如何失败”的设计：一是 fail-closed 而不是 fail-back-to-root 的选择，二是通过 `stat` 推导 checkout 属主、再用 `setpriv … -- test -w` 做真实写权限探测，三是只给采样器而非整个命令链路降权。建议读者重点关注 `_ci_otel_prepare_gpu_user()` 的校验分支（`case "$1:$2" in`）与 `ci_otel_start()` 中三分支启动逻辑，以及测试如何用 shell stub 精确断言 `--reuid=997 --regid=996 --clear-groups --no-new-privs --` 与 `setpriv` 被调用 2 次（一次探测 + 一次启动）。若要在自己仓库复用该模式，需要额外确认 CI 镜像自带 `setpriv`，并为“采样静默消失”补一条告警。

扩展 CPU 镜像构建重试正则，覆盖下载流中断

建议 5 分钟内快速浏览即可，不必精读：改动是一行正则，实现意图清晰，风险边界也已被作者在 body 中显式说明。值得关注的设计决策有三点：一是「复用同一个有界重试框架、只扩模式不提上限」这一取舍，把不确定性风险封在 4 次尝试 / 70 秒退避内；二是签名集合来自真实失败日志（8 个样本逐条反推），而非凭空枚举；三是它暴露了 vLLM CI 中「靠长正则做故障分类」这一模式的脆弱性——若后续再出现同类 PR，建议推动把 `BUILD_RETRY_PATTERN` 拆成可测试的分类函数，并补一份「样例行命中 / 编译错误不命中」的脚本级测试。此外，读者应留意重试逻辑只能缓解 `aicf-jf-cicd-01` 这类宿主侧问题，根因排查不应止步于本 PR。

DeepEP v2 combine 异步化，解码 ITL 降 5-9%

值得精读，尤其是维护 MoE 专家并行、cudagraph 捕获区域或 DeepEP 相关代码的工程师。建议重点关注四个设计决策：(1) 把 `do_async` 从「被忽略的参数」变成真正的行为开关，`combine_async = do_async and not dbo_enabled()` 的内联回退如何与 HT 实现保持一致；(2) receiver 闭包 + `event.current_stream_wait()` 的图重放安全模式——为什么不能在这里做 host 同步、`combined_x` 与 event 的生命周期由谁持有；(3) 删除 env gate 与能力门控的权衡，读起来要与 PR 描述里的早期形态区分开，PR body 描述的 `VLLM_DEEPEP_V2_COMBINE_OVERLAP`、log-once、capture 期 `RuntimeError` 都是历史版本；(4) 契约测试的设计思路——用假 buffer 断言调用参数与 join 时序，而非伪造数值。后续若有条件，建议补一版最终 head 的 EP8 A/B、prefill/大 M 场景以及无 shared expert MoE 的 GPU 覆盖，并在 DeepEP 版本升级时回归 event 契约。

rerank 别名删除冗余取消装饰器，修复断连后仍处理

值得精读，但重点不在 2 行代码，而在讨论区展示的设计取舍： - 当症状出现在公共装饰器（`with_cancellation`）而根因在调用方重复包装时，应优先消除重复装饰而不是修改公共取消语义；本 PR 的 reviewer 三轮质疑（全局语义变更、清理循环使任务免疫取消、`return_exceptions=True` 吞异常）几乎覆盖了这类改法的全部陷阱，可作为反面清单复用。 - 建议后续补一个成本可控的回归测试（可沿用作者删除前用同一 `raw_request` 调用两个真实别名的写法，断言只发生一次 `receive()` 与 cancel 传播），把「别名不得再叠加 `@with_cancellation`」固化成可执行约束。 - 建议顺带审计 `vllm/entrypoints/pooling/scoring/api_router.py` 中其余别名/转发路由（如通往 `create_score` 的 Score 别名）以及所有返回 `await <已装饰 handler>(request, raw_request)` 的位置，确认不存在第二处嵌套取消监听。

修复满前缀命中请求永不结束导致的 KV 泄漏

值得精读。这是一个典型的“状态未闭环导致资源泄漏”bugfix，其核心设计——用 `awaiting_kvs` 区分“调度器真正在等 KV”与“仅通知 producer”——非常精巧，既修复了 full-hit 不释放的问题，又避免误报导致引擎核心断言崩溃。测试参数化覆盖了通知成功/失败 × 等待/仅通知四个组合，值得作为类似嵌套状态 bug 的测试范式参考。