vllm-project/vllm

修复 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 的测试范式参考。

DSv4.1 在 SM100 改用 FlashMLA 528 B MXFP8 KV 记录，KV 缩小 9.6%

值得精读，尤其是维护 KV cache 布局、attention 后端与跨内核一致性的人。 1. 重点看 `vllm/models/deepseek_v41/attention.py` 里 `_use_v41_mxfp8_kv_record()` 与 `kv_bytes_per_token` / `kv_page_alignment` 的绑定关系：把「记录宽度」和「页对齐」变成一组由单一 gate 派生的字段，是这次能在多处复用而不漂移的关键设计。 2. 看 `k_cache.shape[-1]` 作为记录标识的做法：用已经发布的 KV cache spec 宽度做隐式契约，好处是 V4 路径零改动地跑在同一条代码路径上，代价是魔法数字散落在分派点与测试里——这正是 reviewer 要重构的点。 3. 看索引器对齐这个「每个 spec 单独看都正确、合起来 block stride 不整除」的排障故事：它解释了为什么 `alignment=576 if ... and not _use_v41_mxfp8_kv_record() else 512` 必须存在，也提醒后续给同一 block 组加页类型的改动要先算总和。 4. 若要跟进：优先按 reviewer 建议把 576/512/528/584 收敛成记录描述对象；在合入 #56344 时确认索引器对齐修复被带走；并为 SM100 上非 FlashMLA sparse 后端的记录选择补一条显式断言或测试。

修复 Gemma4 解析器静默丢弃裸 tool_call

值得精读。该 PR 展示了 FSM 解析器应对模型非规范输出的一种最小干预模式：单个终端 + 单条转移即可修复整类静默丢失问题，且依赖 lexer 最长匹配优先级保证零回归。建议关注两点：一是 `TOOL_PREAMBLE -> TOOL_NAME` 转移与 #53657 逃逸舱口的协同设计，二是测试对"畸形+规范混合序列"的覆盖方式，这种场景最容易暴露 FSM 状态泄漏。