verl-project/verl

分析结果尚未生成。

分析结果尚未生成。

夜间 Ascend 检查步骤增加日志等待与诊断

建议 CI 维护者精读这次改动，它示范了一种成本极低的「先吸收延迟、再落证据」的 flaky 处理策略：有界轮询加 `-s` 判定、诊断命令挂 `|| true`、路径收敛到变量，都值得复用到其他 Ascend 夜间作业的同类检查步骤。重点看三处设计决策：(1) 60s 上限与 10s 间隔的取舍；(2) 诊断只打尾部 4096 字节；(3) 把日志路径抽成 `LOG` 变量。若追求更彻底，可进一步讨论把检查输入改为 Actions stdout、或在训练脚本里给 `tee` 加 `stdbuf -oL` / 追加后 `sync`，以及把诊断文件作为 artifact 上传。同时务必在团队内同步：该作业要恢复全绿还需在 verl-project/verl-ascend-recipe 仓库重新生成 `baseline_qwen3_vl_8b_Instruct_fsdp2_npu.txt`，这不是本仓库能解决的。

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

补充昇腾 NPU 上 Checkpoint Engine 后端配置文档

该 PR 无需精读代码，建议用 3-5 分钟浏览文档正文即可，重点关注三个设计决策：(1) `nccl` 在 NPU 上被隐式解析为 HCCL——这是一个“配置名与实现后端不一致”的接口约定，值得确认其实现位置并在代码侧保留注释，避免后续被误当作 bug 改掉；(2) Mooncake 在 NPU 上依赖源码编译 `ascend_direct`，属于部署前置条件，建议在昇腾镜像或安装脚本文档中交叉引用；(3) 参数表默认值（2048 MB 桶、`group_name=default`、`rebuild_group=False`）与实现的一致性没有自动化保障，建议后续修改 checkpoint engine 的 PR（如 Mooncake 相关修复）把更新本文档纳入 checklist。若团队有英文文档镜像，建议同步一份以覆盖英文用户。

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