verl-project/verl · 标签视图

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` 的构建说明。

Ascend 镜像改两阶段推送，规避 Quay GC 销毁中间镜像

建议镜像发布与 CI 维护同学精读该 PR：两阶段推送、digest 传递、防 GC tag、凭据隔离的组合是容器镜像 CI 的通用最佳实践。对一般训练框架使用者无需关注。后续可改进的点：将临时仓库迁移到组织级命名空间以消除单点依赖；为 merge 阶段补充 `DIGESTS` 为空时的显式失败断言；统一 a2/a3 的临时 tag 命名风格。

新增 Ascend Docker 受支持镜像标签文档

值得快速浏览（约 1 分钟）：对 Ascend 部署用户有直接参考价值。值得关注的模式是把"最新 / 版本发布 / 模型专用 / 历史归档"分表组织，兼顾检索效率与历史留存；建议后续在 docs/ascend_tutorial 安装文档中引用该文件，并考虑用 CI 校验表格标签与实际 Dockerfile 的一致性。

ROCm PPO CI 升级镜像并禁用 vLLM custom all-reduce

可以快速阅读本 PR 以了解 ROCm CI 的坑位：核心要点是 vLLM custom all-reduce 在 ROCm 上不可用，以及镜像内依赖应作为唯一事实来源。若后续在 ROCm 上继续开展 CI 优化，建议关注 `disable_custom_all_reduce` 配置在 vLLM 侧的实现，并考虑在更多 ROCm 工作流中复用 `VLLM_ROCM_OVERRIDE` 模式。

全项目切换到 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 用户的隐性要求。

更新 Ascend CI 镜像标签，调整 nightly 调度与依赖

该 PR 属于纯 CI 治理，逻辑机械，不建议逐文件精读；但如果你负责 CI 或 NPU 硬件支持，值得关注两点：一是镜像标签从长版本号收敛为「后端 + 硬件」短标签的治理思路，让版本升级从改 20 个文件变成换一个 latest 标签；二是 crane CLI 从 tag delete 迁移到 delete 的踩坑点。可与 #7345、#7338、#7311 结合起来看 Ascend CI 镜像体系的完整演进。

修复 NPU nightly CI，升级 Ascend 依赖版本

建议 CI 维护者精读，尤其是 Docker 临时 tag 清理逻辑和 veomni 安装方式，可作为 Ascend CI 标准配置参考。同时建议后续将依赖版本（Megatron / MindSpeed / triton-ascend）集中到常量或锁文件管理，避免散落在 workflow 和脚本中。值得关注的设计决策是：用 `pip install` 替代 `uv` 以支持 `--ignore-requires-python`，以及用 `crane` 清理临时 tag，这两点对快速维护 CI 有借鉴意义。

Ascend Docker 镜像 CANN 升级至 9.1.0 并同步 CI 与文档

该 PR 适合快速浏览，作为版本升级时对 CI 文件名联动影响的参考案例。值得关注的是：Dockerfile 重命名必须同步更新工作流中所有路径引用（触发过滤、grep 解析、build-push 参数），这是一个容易遗漏的联动点；建议维护者后续在 CHANGELOG 或发布说明中提示外部用户迁移文件路径。