verl-project/verl · 标签视图

detach model_output 修复多引擎逐 micro-batch 显存泄漏

值得精读。建议关注四点： 1. 根因定位方法：`_record_memory_history` 栈归因锁定 `p2p_communication.py::create_tensor_recv_prev`，并用 `forward_only`（0.76 MiB/micro-batch）与 PP=1（0.31 MiB/micro-batch）两组对照实验把“图保留”机制钉死，是排查训练显存泄漏的范本。 2. `detach_tree` 设计：惰性 detach（已 detached 张量原样返回）避免逐 key 创建 `TensorImpl`；递归支持 dict / list / tuple，从而覆盖 jagged nested tensors 这类新型输出结构。 3. 回归测试设计：CPU-only 下用最小 checkpoint 模型 + weakref 复现“图被钉住”机制，再配合 AST 静态检查 4 个引擎调用点，绕开“必须 PP>=2 才可复现”与“无法在 CI 断言绝对显存”的双重困境。 4. 工程陷阱提醒：“detach 位置错误导致梯度静默归零且 loss 曲线正常”说明此类内存修复必须用梯度可达性断言（`requires_grad` 契约）双保险，而不能只靠数值曲线。

移除权重同步 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 之后应考虑废弃或标注为过渡方案。

V1 验证指标把失败会话按 acc=0 计入

值得精读。这是一个“小 diff、大语义”的指标修正：104 行改动里的核心只有三处（期望计数采集、源级 opt-in 补齐、None/has_pred 安全化），但直接改变了 Trainer V1 验证主指标的语义，阅读时建议重点看 `metric_utils.py` 的 `expected_acc_counts` 块与 `has_pred` 的判定条件，以及 `trainer_base.py` 中 `(str(data_source), str(uid))` 键的构造是否与指标侧分组严格对齐。建议配套动作：在监控中同时画 `acc` 与 `acc_success_only`，把两者差值作为失败率诊断；为 `_validate → _val_metrics_update` 补一个 CPU 级端到端单测（覆盖 `__rollout_n__` 缺省回退与键一致性）；明确 `pred` 是否也应随 `acc` 补齐，避免 `maj` 指标与 `mean` 基数不一致。

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 的补位点）。

NPU 补丁增加部分唤醒防护，修复 GLM-5.2 异步训练崩溃

建议精读。本 PR 是典型的“对外部引擎做安全 monkey-patch”的范本：源码指纹校验、幂等 marker、spawn 入口包装三件事结合得很好，对维护 vllm-ascend、sglang 等外部组件兼容层的开发者有直接参考价值。值得关注的设计决策是“先验证再替换”和“通过入口函数传播补丁到子进程”这两个模式。

权重恢复前改用轻量 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 基准），否则同类回退仍可能被静默引入。

权重同步后加跨 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 描述中说明手工验证方法，弥补当前评审与测试证据不足的问题。

补齐蒸馏 teacher 字段填充并支持 fsdp2 策略

值得精读，但只需读源码不必读讨论——PR 本身讨论为零。重点关注三个设计决策：一是 padding 模板选择 "按模板序列长度重建" 而非 "裁剪/丢弃教师字段"，意味着合成样本仍需保持可被蒸馏 loss 消费的完整张量结构；二是用 .new_full/.new_zeros 保留 topk 维与 dtype/device，写法克制，便于后续扩展更多 teacher 字段；三是把 fsdp2 直接并入 fsdp/veomni 分支而不是新建实现。建议阅读者在本地补一条 CPU 单测覆盖 teacher_ids/teacher_logprobs 存在与不存在两种情况，并确认跨 tokenizer 场景下 eos_token_id 作为 teacher topk id 的合法性。