vllm-project/vllm

MRV2 DBO 微批步骤接入 FULL CUDA 图捕获与回放

值得精读，尤其是三类设计决策：(a) `_maybe_ubatch_twin` 用与 DP 握手完全相同的阈值函数生成候选，把“可捕获”与“可分发”强行绑定，这是避免多 rank 不对称执行的关键；(b) `run()` 拆成 `begin_capturable_run()` / `finish()`，把线程创建、device 设置与 cuBLAS 预热留在图外，只让 handoff 与 join 进图，这是 DBO 能捕获成功的前提；(c) `_capture_stream` 强制捕获流与微批线程 compute stream 一致，是移植 V1 `gpu_ubatch_wrapper.py::_capture_ubatches` 时最容易漏掉的一点。阅读时请结合 #50945 一起看（本 PR 的 diff 建立在它之上），并重点关注 dp_utils.py 中 `2 * min(num_tokens_across_dp) < ubatch_desc.num_tokens` 这一守卫——它已被确认存在边界 bug，跟进补丁前不建议在生产 DP 负载高度不均的场景依赖 FULL 微批回放。此外建议跟踪 coderabbitai 提出的“永不被回放的孪生图”是否会形成显存浪费的后续处理。

gRPC 服务端迁入 launchers，旧路径保留弃用 shim

建议精读，但重点不在业务逻辑（`serve_grpc` 与迁移前逐字一致），而在“模块搬迁 + 旧路径弃用 shim”这一可复用范式，以及它暴露出的把关缺口。值得关注三个设计决策：一是 shim 用 `DeprecationWarning` + `stacklevel=1` 的实现方式，是否足以让用户看到提示（默认 filter 下大概率看不到，考虑 `FutureWarning` 或启动日志更稳妥）；二是旧模块只做符号再导出，导致旧路径上的 monkeypatch 失效，是否应在 shim 里再加一层包装函数以保留可替换性；三是本次完全没有新增测试，建议补一条“新路径可导入 + 旧路径导入仍可用并告警”的最小用例，成本极低而收益明确。此外可顺手修复弃用文案里未闭合的反引号，并明确 shim 的移除版本。

MIG 切片 CI 内存遥测补齐，复用 NVML 绑定采集 used/total。

值得精读，尤其适合 CI/可观测性方向的同学。三个设计点可以复用：一是用 `importlib.util.find_spec` + `spec_from_file_location` 复用捆绑绑定而不引入重型运行时依赖；二是把 CUDA 驱动交互放进带超时的一次性子进程，避免在常驻采样进程里创建 CUDA 上下文；三是采样失败永远保持 unknown 而非合成零值，保证 dashboard 语义不会被污染。

H200 CI 负载下沉 18GB MIG，大内存用例拆分保留 35GB。

视频 base64 解码改为严格校验，畸形载荷报 400

**是否精读**：源码本身不值得精读——一行 `validate=True`，理解 pybase64 的宽松/严格语义即可；但 PR 正文与评论值得完整读一遍，它包含三个可复用的判断素材。 **值得关注的设计决策**： 1. **一致性 vs 宽松兼容**：作者拒绝为 video 单独定义“容忍折行 base64”的第三种语义，而是与 image/audio 对齐，并把统一 strip 留作跨模态 follow-up。这是典型的“先统一语义，再统一策略”的处理方式。 2. **错误归因的价值**：同样的 400，从“视频打不开”变成“编码非法”，对客户端集成方的调试体验是实质提升——这类“不改变状态码、只改变错误语义”的修复容易被低估。 3. **验证方式的选择**：作者的哨兵 backend 断言的是“解码器未被触达”，比断言“抛异常”更贴近真实性质；即便测试被删除，这个思路值得借鉴到其它输入校验场景。 4. **自我纠错的可追溯性**：把“已撤回的 500 结论仍留在 commit subject 与 docstring 中”当作一个独立问题显式修掉，是防止错误结论进入代码树的好实践。 **建议动作**：接受现状合并；同时跟进两项——(a) 决定是否在 image/audio/video 三个 loader 中统一 strip 空白以保住 RFC 2045 客户端；(b) 若维护者后续改变对“一行改动加测试”的态度，可把哨兵用例以更轻的形式补回。

回滚 XPU 量化 CI 的 V2 runner 禁用，恢复 V2 覆盖。

值得快速浏览，重点不是代码而是 PR body 的根因分析。这是一次教科书式的 "临时 workaround → 根因定位 → 硬件验证 → 基于根因修复回滚 workaround" 闭环，对处理跨后端（CUDA/XPU）行为差异的 bug 有参考价值。关注点：确认 #54809 确实已合入当前 main；后续若 XPU 量化 CI 再次挂起，应优先检查 V2 执行路径而非重新引入环境变量规避。

Rust 前端补齐 HTTP RL 权重同步生命周期端点

值得精读。本 PR 是 Rust 前端新增 dev-mode 管理端点的干净样板：可选 body 提取器（Option<Json>）、通过 From<JsonRejection> 统一错误转换、finish 成功后才提交版本的顺序设计，以及在 routes/tests.rs 中用 mock ZMQ EngineCore 断言 MessagePack wire 载荷的测试方法，都值得在后续端点开发中复用。建议重点阅读 rust/src/server/src/routes/weight_transfer.rs 和 tests.rs 中三个新测试。

修复 FSE 测试夹具缺 rswa_window 的 CI 回归

建议花少量时间阅读。变更本身只有一行，但它揭示了 backend 选择逻辑新增 model_config 字段读取时，测试 fixture 的手工模拟对象容易发生契约漂移；对维护 attention backend、mock fixture 或 CI 的工程师有借鉴价值。khluu 的复现排查过程（跨主机确认确定性失败、用精确 lane 验证）也是值得学习的 CI 问题定位方法。