verl-project/verl · 标签视图

Ascend 镜像将 transformers 固定为 5.10.4

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

修复 transformers 升级后 CI 失败，更新模型和依赖配置。

这是一个常规的 CI 修复 PR，主要涉及配置调整和测试适配。值得快速浏览以了解 transformers 升级后的兼容性问题，但无需深度精读核心逻辑。建议关注测试模型变更和依赖添加，以确保后续类似升级时有参考。

统一项目所有后端的 transformers 版本至 5.9.0，简化依赖管理。

这是一个重要的依赖维护 PR，虽然代码变更简单，但影响面较广。建议精读 `pyproject.toml` 中关于 `override-dependencies` 新策略的注释，理解其设计意图。对于所有使用者，需要在更新环境后运行测试套件，特别是与 `transformers` 交互紧密的功能，以确保升级无破坏性。该 PR 是项目依赖治理简化的积极一步，值得肯定。

修复 trl 新版本下 value-head critic 导入崩溃

建议快速精读（约 5 分钟），是低风险、高收益的兼容性修复样板。值得关注的设计决策：（1）用 try/except 而非版本条件判断（如 `packaging.version` 比较）处理依赖 API 迁移，写法更简洁且天然向前兼容；（2）与 #6539 保持完全一致的导入模式，避免同一仓库出现多种兼容写法；（3）PR body 中「先自查 open PR 再提交」的去重流程值得团队沿用。后续动作建议：在 trl 1.x 依赖升级（#7478）落地时，全局扫描 `from trl import` 确认无其他受影响符号，并考虑补充导入级回归测试。

uv 锁与镜像支持 aarch64 双架构，配套流程重写

值得精读。该 PR 展示了“架构作为解析维度而非 extra 维度”的 uv 多架构设计，以及两个非常具体的坑：nvidia-cusparselt-cu13 的 wheel 内部 tag 不一致导致 uv 反复重装、megatron-core VCS 版本号导致锁文件与实际构建不一致。这些细节对任何维护 uv 单锁多平台的团队都有借鉴价值；Docker 多架构构建与 manifest 合并的实操说明也可直接复用。重点关注 `pyproject.toml` 的 `[tool.uv]` 配置注释和 `docker/Dockerfile.uv.cu130` 的构建说明。

接入 Liger 融合算子，actor 更新提速 13.53%、显存降 5.56%

值得精读。重点看 FusedLinearForPPO.forward 的可选依赖降级模式、2D/3D 形状保真处理，以及 test_experimental_torch_functional_on_cpu.py 中 FakeLiger 的 dispatch 验证方式。若团队在 GPU 上使用 fused kernel，建议合入后跑一次 H100 短训练回归；若维护 NPU/其他硬件栈，需确认 Liger 内核在目标硬件上的可用性。

全项目切换到 uv 统一管理多后端依赖与安装流程

值得精读，这是 verl 包管理架构的里程碑级迁移。重点看三处设计：manage_envs.py 的 universal lock + conflicts 方案（一个锁文件、运行期 materialize 一个无冲突组合）、prefetch 与 Docker 镜像“先烘焙缓存、运行时离线 sync”的配合、以及用 check_uv_gpu_only.py 静态分析强制 GPU/NPU 使用路径分离的做法。建议同时关注后续对 trtllm / veomni（cu12.9 世界）恢复解锁的演进，以及 `DEVICE:-gpu` 默认值对 NPU 用户的隐性要求。

NPU CI 添加环境变量抑制日志并更新安装文档

该 PR 属于机械的 CI 维护，不值得精读，但可作为 NPU CI 环境治理的参考。值得关注的设计决策是使用 `TRANSFORMERS_VERBOSITY` 环境变量从第三方库层面统一收敛日志，并在同一个 PR 中顺手升级依赖版本（trl 0.28.0）以保持流水线依赖新鲜；若要复用到自有 CI，可借鉴该模式。