Prhub

verl-project/verl · 标签视图

标签列表

聚合结果

rollout 相关 PR

2026-09-15

#7873 [perf] fix: remove full gc during weight refit

原始 PR · 作者 wuxibin89 · 合并时间 2026-09-15 22:25

性能优化 重要性 7.03 洞察度 8.00

移除权重同步 full GC 并修复 IPC ACK 竞态

值得精读,尤其是 `verl/workers/rollout/vllm_rollout/bucketed_weight_transfer.py`:它演示了如何用内存快照把“性能优化”还原成“跨进程竞态修复”,以及 CUDA IPC 的 `CudaIPCSentDataLimbo_` + `ipc_collect()` 组合在什么条件下无法回收 block。建议关注三个设计决策:最后一帧 ACK 推迟到 `_cleanup` 之后、`_ack_pending` 守卫如何维持 REP socket 的收发热度、`del weights, tensor` 前置如何顺带覆盖 `_direct_send_large_weight`。需要提醒读者的未闭环项:接收方 `_cleanup` 异常时的发送方永久阻塞(应尽快与 #7366 的 ACK 超时对齐或补 try/except 兜底 ACK),以及 `tests/utils/test_bucketed_weight_transfer.py` 缺失的 ACK 顺序断言——后者是未来重构最容易踩的坑。若团队正在维护 #7780 的 GC 开关,本 PR 之后应考虑废弃或标注为过渡方案。

缺陷修复 重要性 7.20 洞察度 8.00

SGLang rollout 补齐视频特征转发,修复视频 VLM 盲答

值得精读,尤其是维护 rollout/多模态链路的同学:本案是“静默降级类 bug”的教科书样本——TODO 注释无告警、特征算完即丢、两个后端行为不一致,三者叠加后表现为模型输出流畅但完全虚构。建议重点看三处设计决策:(1) 用 `format="processor_output"` 复用 verl 已算好的 processor 输出而不是让 SGLang 重新抽帧,避免 fps 采样不一致这一隐形 desync;(2) 把后端差异收敛到 `LLMServerClient.generate` 的一处分支,并用无条件传参 + `TypeError` 换取“漏改即失败”的可见性;(3) teacher/OPD 路径与 rollout 路径共用同一 payload,避免修复只覆盖一半。阅读时建议同时关注作者未解决的遗留:非 Qwen 视频家族的静默丢弃、多轮 ToolAgentLoop 重复传帧、以及缺失的单测(作者愿意贡献 CPU-only mRoPE 对齐测试,可作为后续 PR 的补位点)。

性能优化 重要性 5.28 洞察度 6.00

权重恢复前改用轻量 empty_cache,去掉关键路径 full GC

值得精读,但重点不在代码而在推理链:改动本身只有一行,真正的价值是 Issue #7848 + PR body 中“拆分 empty_cache / GC / retry 各自耗时与释放量”的实验方法,可直接迁移到其他显存清理、profiler、同步点的性能排查。 阅读时建议关注三个设计决策:一是为什么普通 `empty_cache()` 在这个边界上已经足够(进程间 allocator handoff 语义 vs 释放活跃张量);二是为什么 aggressive cleanup 在权重传输后、KV-cache resume 前的那处被保留(本 PR 的边界克制);三是无单测情况下的回归防线如何建立——建议后续为 `update_weights()` 的关键路径加一个轻量守卫(例如断言该边界不再调用 `aggressive_empty_cache`,或把 GPU A/B 数据纳入 nightly 基准),否则同类回退仍可能被静默引入。

2026-09-14
缺陷修复 重要性 5.90 洞察度 6.00

权重同步后加跨 rank barrier,避免非 leader 恢复 KV cache 时 OOM

值得精读(约 5 行,10 分钟以内),特别是正在维护权重同步、rollout 显存管理或遇到过“非 0 号 rank OOM”的工程师:它是理解“leader 抢先分配资源 → 其它 rank OOM”这类跨 rank 竞态的典型样本,也是 `asyncio.to_thread` 包装阻塞式集合通信的现成写法。 阅读时重点确认三点:一是 barrier 的位置是否确实覆盖了所有会持有显存的重 rank(本例放在 offload 与 aggressive_empty_cache 之后、resume 之前,逻辑正确);二是是否应加 `torch.distributed.is_initialized()` 守卫或改用带超时的 barrier,以降低挂起/异常风险;三是其它未覆盖的同步路径(disaggregated、TRT-LLM 之外的专用后端)是否需要同样处理。此外建议补一个最小的多 rank/异步单测或在 PR 描述中说明手工验证方法,弥补当前评审与测试证据不足的问题。

2026-09-10
测试 重要性 7.33 洞察度 5.00

新增 Ascend NPU batch-invariant 开关回归测试(14 例)

值得精读,但读的是测试脚手架而不是代码改动本身。 - 重点看 `run_on_npu` 的 spawn 子进程隔离设计:对于会在全局注册 torch dispatch 表或替换 `torch.sum`、`torch_npu.npu_add_rms_norm` 这类入口的开关,进程级隔离是唯一可靠的隔离手段,这套写法可直接迁移到其他 NPU 补丁测试。 - 重点看 `_run_check` 如何用真实 `vLLMHttpServer` 加最小 mock(模型元数据 + Ray 上下文 + 引擎配置单例)触发真实的 `init_batch_invariance()`,避免了「只测 mock」的假阳性,同时不付出加载权重与拉起推理引擎的代价。 - 关键设计决策:enabled/disabled 双向断言(特别是 disabled 时要求 `batch_invariant_ops::` 事件数必须为 0),这比只测开启路径更能捕获 dispatch 注册泄漏。 - 若要真正确认能力,建议后续补一个跨 batch size 的一致性用例:同一条样本分别放进 batch=1 与 batch=N 比较 logprob 位级一致,才覆盖 `full_determinism` 的语义;并补齐 CI 收集与算子包安装的验证,避免长期 skipped。 - 维护建议:把对 `bi._batch_invariant_LIB` 等私有符号的依赖在注释中显式标注为「随 vllm-ascend 版本可能变动」,并在 PR 描述中把文件名与 body 里的 `test_batch_invariant_switch.py` 对齐。

2026-09-09
缺陷修复 重要性 5.78 洞察度 6.00

修复 Mooncake 检查点引擎中跨权重版本未消费完成槽位导致的缓冲区过早释放问题。

此 PR 值得精读。它解决了一个在分布式权重同步中微妙但严重的数据竞争条件,修复方案精准且最小化。对于从事分布式训练、检查点引擎或 RDMA 通信的工程师,理解其设计(尤其是完成槽位的双缓冲消费模式)非常有价值。建议关注其手动验证的严谨性,并思考如何为这类底层修复补充自动化测试,以防未来回归。

2026-09-07
缺陷修复 重要性 7.38 洞察度 5.00

修复 Ascend A5 硬件因 HDK 版本问题无法开启 IPC 的 bug

本 PR 是一个重要的、针对性强的 bugfix。它解决了特定硬件上的功能阻断问题,且实现清晰,测试覆盖全面。推荐精读,关注点在于:1) `AscendHardwareVersion` 枚举的设计及其作为未来硬件适配扩展点的潜力;2) `get_npu_versions` 返回值签名变更的影响范围确认;3) 测试中通过 `@patch.dict(sys.modules, {...})` 模拟 `torch_npu` 模块的方法。

功能 重要性 9.11 洞察度 7.00

为 Continuous Token 构建器增加 rollback 风格的 assistant 角色上下文合并支持。

此 PR 是一个具有重要设计决策的功能增强。建议相关工程师精读,特别关注: 1. `merge_context_tokens` 和分组编码的新逻辑,以及 `MergeResult` 语义的变化。 2. 模型特定子类(尤其是 DeepSeek)如何通过钩子适配新逻辑。 3. `scripts/chat_template_checker.py` 中的更新,以理解 CT 的新行为如何被验证。 4. 新增的测试用例,特别是那些模拟 rollback 场景的,以理解边界条件。 该 PR 的洞察价值较高,因为它展示了如何通过引入中间层(钩子)和约束来解决一个复杂的、与模型模板紧密相关的工程问题,其设计模式值得借鉴。