verl-project/verl

Ascend 镜像将 transformers 固定为 5.10.4

不建议精读，属于常规依赖修复。值得留意的是固定版本的操作位置（bridge 安装之后、清理之前）以及注释习惯；更值得反思的是 PR 描述过于简短，缺少不兼容现象说明和验证方式，团队在后续依赖升级时应补充 issue 链接与冒烟验证步骤。

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 的合法性。

R2 回放模型作用域化并显式启用，修复 Megatron 回归

值得精读。重点学习三点：(1) opt-in + model-scoped 的双重机制如何从根上避免 #7106 的回归——这是"修复被回退后重做"的教科书案例；(2) 分布式集体通信中空 stage 用 0-layer 占位参与的设计，`pp_gather` 的防御性校验也值得借鉴；(3) 多模态 HF config 树遍历中"只走 text 分支、隔离兄弟配置"的约束，对 Qwen3-Omni 类模型接入有直接价值。此外，SamitHuang 的三条 review 展示了如何把"静默错误"审出来并推动作者用测试固化。

修复 GLM-5.2 Ascend 示例脚本：关闭 checkpoint 严格校验并更新依赖 refs

值得快速浏览，但无需精读。该 PR 是典型的 recipe 维护类变更，核心价值在于两点：一是学会在示例脚本中通过 `checkpoint.strict=False` 处理权重冗余/缺失场景；二是注意依赖 ref 与镜像栈的版本对齐。可作为 Ascend 示例脚本维护的参考。

README 新增 AMD Developer Cloud 可启动 DAPO 教程链接

该 PR 是纯文档链接增补，不值得精读代码。可关注的唯一设计点是：如何通过“可启动模板”降低 RL 训练框架的上手成本，以及教程版本与主仓库主线（trainer.v1）保持同步的后续计划。若团队重视 AMD 生态，可跟踪后续该教程链接的更新 commit。