verl v0.5 Preview 镜像解析CUDA 12.8 PyTorch 2.7.1 下的 SGLang 与 Megatron 训练部署方案【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verlverlHybridFlow是一个面向大模型 RL 后训练PPO/GRPO 等的高效训练框架其 Docker 镜像体系直接决定了训练与推理引擎的组装方式。本文围绕 docker/verl0.5-preview-cu128-torch2.7.1-fa2.8.0/README.md 展开结合同目录下的 Dockerfile.base 与 Dockerfile.app.sglang.megatron 逐层拆解这套 v0.5 preview 镜像的软件栈选型、构建步骤与使用前提帮助读者理解Base 镜像 App 镜像的两级镜像设计并据此搭建可复现的 verl 运行环境。一、镜像定位v0.5 Preview 的软件栈概览该目录提供的是 verl v0.5 预览版preview对应的镜像体系核心软件版本如下原文中列出的关键包版本cuda12.8 cudnn9.8.0 torch2.7.1 flash_attn2.8.0 sglang0.4.8 transformer_engine2.5 megatron.corecore_r0.13.0 nvidia-cudnn-cu129.8.0.87这套组合对应两条明确的训练 推理主线训练后端Megatron-LMmegatron.corecore_r0.13.0配合 TransformerEngine 2.5面向追求大规模扩展性的用户推理后端SGLang 0.4.8 承担 rollout 生成配套 FlashInfer 0.2.6.post1 加速注意力计算。值得注意的是vLLM 在此版本暂时不支持最新版本README 原文vllm temporarily not support latest version因此在 v0.5 preview 阶段官方提供的应用镜像只覆盖 SGLang 这一条推理引擎路线。从仓库当前状态看verl 已演进到 verl/version/version 中的0.10.0.dev而 docker/README.md 说明自 v0.6.0 起镜像体系改为以 vLLM/SGLang 官方 release 镜像为基底。本文介绍的 v0.5 preview 镜像属于此前的独立构建路线理解它可以清楚看到 verl 镜像从全手动装配走向基于上游引擎镜像的演进脉络。二、两级镜像设计Base 镜像与 App 镜像该目录采用 verl 长期沿用的Base App两级镜像结构官方预构建镜像标签如下层级镜像标签说明Base 镜像verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0内置 FlashInfer 0.2.6.post1 的基础镜像App 镜像verlai/verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview在 Base 之上叠加 SGLang 0.4.8 与 Megatron core_r0.13.0设计意图很清晰Base 镜像负责最重、最容易出错的底层编译产物——CUDA/Torch/FlashAttention/Apex/TransformerEngine且不携带任何推理或训练框架保证单一职责、可复用、可缓存App 镜像在 Base 之上按需叠加具体引擎此处为 SGLang Megatron从而在不同 App 镜像之间共享同一份底层 Base显著降低镜像体积与构建时间。对应到文件即 Dockerfile.base构建 Base 镜像与 Dockerfile.app.sglang.megatron构建 App 镜像。三、Base 镜像逐层拆解CUDA 12.8 训练底座是如何装配的Dockerfile.base 的注释明确说明其目标是Base Docker Image of verl, with CUDA/Torch/FlashAttn/Apex/TransformerEngine, without other frameworks。下面按构建顺序逐层说明。3.1 基底镜像与全局环境变量FROM nvcr.io/nvidia/pytorch:25.02-py3 ENV MAX_JOBS16 ENV VLLM_WORKER_MULTIPROC_METHODspawn ENV DEBIAN_FRONTENDnoninteractive ENV NODE_OPTIONS ENV PIP_ROOT_USER_ACTIONignore ENV HF_HUB_ENABLE_HF_TRANSFER1基底采用 NVIDIA NGC 的nvcr.io/nvidia/pytorch:25.02-py3Ubuntu 22.04 系容器。几个环境变量的作用MAX_JOBS16限制源码编译时的并行任务数防止pip install编译 Apex/FlashAttention 时把宿主机 CPU/内存打满VLLM_WORKER_MULTIPROC_METHODspawn固定 vLLM 多进程启动方式为spawn规避 fork 方式在多线程 CUDA 环境下的隐患DEBIAN_FRONTENDnoninteractiveapt 安装过程无需交互PIP_ROOT_USER_ACTIONignore允许在 root 下直接执行 pipHF_HUB_ENABLE_HF_TRANSFER1启用 hf-transfer 加速 Hugging Face 模型与数据集的下载Base 镜像安装清单中确实包含hf-transfer。3.2 镜像源替换面向国内网络环境ARG APT_SOURCEhttps://mirrors.tuna.tsinghua.edu.cn/ubuntu/ ARG PIP_INDEXhttps://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple通过ARG默认指向清华大学 TUNA 镜像先备份原 apt 源再整体替换为 jammy 系列源随后安装systemd、tini、aria2、libfreeimage3等基础工具并把 pip 默认 index 切到清华 PyPI 镜像最后在构建末尾用pip config unset还原避免污染镜像内默认 pip 配置。3.3 卸载 NGC fork 版本重装官方 PyTorch 2.7.1NGC 的 PyTorch 容器自带定制版 torch 全家桶与 verl 依赖的版本往往不匹配因此先整体卸载RUN pip uninstall -y torch torchvision torchaudio \ pytorch-quantization pytorch-triton torch-tensorrt \ xgboost transformer_engine flash_attn apex megatron-core grpcio再从官方 wheel 源安装与 CUDA 12.8 配套的版本RUN pip install --resume-retries 999 --no-cache-dir torch2.7.1 torchvision0.22.1 torchaudio2.7.1 --index-url https://download.pytorch.org/whl/cu128注意--resume-retries 999这一参数在后续所有大包安装中反复出现用于应对大体积 wheel 下载中断后的断点续传是长时间构建稳定性保障的关键细节。3.4 FlashAttention 2.8.0.post2按 CXX11 ABI 精确匹配RUN ABI_FLAG$(python -c import torch; print(TRUE if torch._C._GLIBCXX_USE_CXX11_ABI else FALSE)) \ URLhttps://github.com/Dao-AILab/flash-attention/releases/download/v2.8.0.post2/flash_attn-2.8.0.post2cu12torch2.7cxx11abi${ABI_FLAG}-cp312-cp312-linux_x86_64.whl \ FILEflash_attn-2.8.0.post2cu12torch2.7cxx11abi${ABI_FLAG}-cp312-cp312-linux_x86_64.whl \ wget -nv ${URL} \ pip install --no-cache-dir ${FILE}这里有一个非常关键的工程细节FlashAttention 的预编译 wheel 与 PyTorch 的_GLIBCXX_USE_CXX11_ABI标记强绑定。脚本先运行时探测当前 torch 的 ABI 标记再拼接出对应的cxx11abiTRUE/FALSE文件名下载 wheel保证二进制 ABI 完全一致避免运行时出现符号解析错误。这也是 README 版本清单中flash_attn2.8.0实际安装为2.8.0.post2被重点标注的原因。3.5 依赖修复与 cuDNN 9.8.0RUN pip uninstall -y pynvml nvidia-ml-py \ pip install --no-cache-dir --upgrade nvidia-ml-py12.560.30 fastapi[standard]0.115.0 optree0.13.0 pydantic2.9 grpcio1.62.1先卸载可能与 NGC 基线冲突的pynvml/nvidia-ml-py再升级nvidia-ml-pyGPU 监控/健康检查所需、fastapi、optree、pydantic、grpcio推理服务与 Ray 通信链路的公共依赖。cuDNN 9.8.0 通过 NVIDIA 官方本地仓库 deb 包安装RUN aria2c --max-tries9999 https://developer.download.nvidia.com/compute/cudnn/9.8.0/local_installers/cudnn-local-repo-ubuntu2204-9.8.0_1.0-1_amd64.deb \ dpkg -i cudnn-local-repo-ubuntu2204-9.8.0_1.0-1_amd64.deb \ cp /var/cudnn-local-repo-ubuntu2204-9.8.0/cudnn-*-keyring.gpg /usr/share/keyrings/ \ apt-get update \ apt-get -y install cudnn-cuda-12 \ rm cudnn-local-repo-ubuntu2204-9.8.0_1.0-1_amd64.deb这里使用aria2c而非 wget/curl并设置--max-tries9999同样是针对大文件下载的稳定性优化——这也是前面安装aria2的原因。3.6 Apex、NVIDIA Nsight Systems 与科学计算/RL 依赖Apex 从源码安装并显式开启--cpp_ext与--cuda_ext扩展RUN pip install -v --disable-pip-version-check --no-cache-dir --no-build-isolation --config-settings --build-option--cpp_ext --config-settings --build-option--cuda_ext --resume-retries 999 githttps://github.com/NVIDIA/apex.git调试工具链方面镜像内嵌 Nsight Systems 2025.3.1并把nsys/nsys-ui软链接到/usr/local/cuda/bin/便于在容器内直接做性能剖析。最后一批 Python 依赖覆盖了 verl 的运行时与开发需求RUN pip install --resume-retries 999 --no-cache-dir tensordict0.6.2 torchdata transformers[hf_xet]4.51.0 accelerate datasets peft hf-transfer \ numpy2.0.0 pyarrow19.0.1 pandas cuda-bindings \ ray[default] codetiming hydra-core pylatexenc qwen-vl-utils wandb dill pybind11 liger-kernel mathruler blobfile xgrammar \ pytest py-spy pre-commit ruff要点解读tensordict0.6.2verl 在 v0.5 时期的数据结构依赖当前仓库 setup.py 已升级到tensordict0.8.0,0.10.0可看到版本策略的演进transformers[hf_xet]4.51.0引入 hf_xet 加速 HF 下载numpy2.0.0v0.5 时期为兼容性锁定的下限约束liger-kernel、mathruler、qwen-vl-utils分别对应多模态、数学推理等 RL 训练场景的算子与工具依赖ray[default]verl 分布式调度Ray 驱动的核心依赖对应 verl/single_controller/ray 的实现。至此一个不带任何推理/训练框架的 CUDA 12.8 训练底座构建完成。四、App 镜像装配 SGLang 0.4.8 与 Megatron core_r0.13.0Dockerfile.app.sglang.megatron 直接以 Base 镜像为起点FROM verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0-fi0.2.6标签中的-fi0.2.6即指 Base 镜像内置 FlashInfer 0.2.6.post1README 中明确说明 We offer a base image with flash infer 0.2.6.post1 built in。随后按序装配4.1 FlashInfer 与 SGLangRUN pip install --resume-retries 999 --no-cache-dir --no-build-isolation flashinfer-python0.2.6.post1 RUN pip install --resume-retries 999 --no-cache-dir sglang[all]0.4.8 pip install torch-memory-saver --no-cache-dirflashinfer-python0.2.6.post1提供 SGLang 默认使用的 FlashInfer 注意力后端与 Base 镜像中 flash_attn 2.8.0.post2 形成双注意力加速配置sglang[all]0.4.8安装 SGLang 全功能依赖含 openai 兼容服务端等torch-memory-saver用于推理阶段的显存优化。4.2 依赖版本收敛App 镜像重复执行 Base 中的修复包操作nvidia-ml-py12.560.30、fastapi、optree、pydantic、grpcio并重新固定nvidia-cudnn-cu129.8.0.87目的与 Base 相同把 SGLang 及其传递依赖可能拉高/拉低的版本重新收敛到 verl 验证过的组合这正是多引擎镜像装配中版本漂移问题的典型处理手法。4.3 TransformerEngine 2.5 与 Megatron core_r0.13.0RUN export NVTE_FRAMEWORKpytorch pip3 install --resume-retries 999 --no-deps --no-cache-dir --no-build-isolation githttps://github.com/NVIDIA/TransformerEngine.gitrelease_v2.5 RUN pip3 install --no-deps --no-cache-dir --no-build-isolation githttps://github.com/NVIDIA/Megatron-LM.gitcore_r0.13.0 RUN pip3 install --no-cache-dir mbridgeTransformerEngine 从release_v2.5分支源码安装NVTE_FRAMEWORKpytorch声明框架后端Megatron-LM 锁定core_r0.13.0提交与 README 版本清单一致两者均使用--no-deps避免其传递依赖覆盖镜像内已收敛的版本mbridge是 verl 与 Megatron 之间的 bridge 依赖。当前仓库的 setup.py 中MCORE_REQUIRES [megatron-bridge, mbridge]仍然保留了这一依赖族印证其在整个 verl 演进过程中的持续地位。4.4 依赖版本汇总表综合 README 与两个 Dockerfile可将该 App 镜像的最终关键版本整理如下组件版本安装来源CUDA12.8NGC 25.02-py3 基底 cu128 torch wheelcuDNN9.8.0nvidia-cudnn-cu129.8.0.87NVIDIA 本地仓库 deb pip wheelPyTorch2.7.1torchvision 0.22.1 / torchaudio 2.7.1download.pytorch.org cu128FlashAttention2.8.0.post2cxx11abi 匹配Dao-AILab 预编译 wheelFlashInfer0.2.6.post1PyPISGLang0.4.8PyPIsglang[all]TransformerEngine2.5release_v2.5源码安装--no-depsMegatron-LMcore_r0.13.0源码安装--no-depsApex最新 git 主分支源码安装cpp_ext cuda_extNsight Systems2025.3.1NVIDIA 官方 deb五、重要使用须知vLLM 与 pyext 的限制README 以!!!Notice!!!明确列出两条约束任何基于该镜像搭建环境的人都必须知晓5.1 vLLM 暂不支持最新版本v0.5 preview 阶段仅提供 SGLang 推理引擎的应用镜像vLLM 最新版本在该组合下不受支持。若需使用 vLLM应转向其他镜像路线例如 docker/verl0.5-cu126-torch2.7-fa2.7.4 对应 CUDA 12.6 的镜像或当前仓库 docker/README.md 中基于 vLLM release 镜像的新体系。5.2 pyext 已进入弃用轨道pyext is lack of maintainace and cannot work with python 3.12, consider using replacement and deprecating this package.pyext原用于 PRIME 代码评分缺少维护且无法兼容 Python 3.12应寻找替代方案并推进弃用。这一预警在仓库源码中得到了落实当前 setup.py 中PRIME_REQUIRES []注释明确写道 Empty since PRIME code scoring droppedpyext; kept soverl[prime]stays installable——即新版 verl 已从代码评分链路中移除 pyext仅保留空依赖以维持verl[prime]的可安装性。这与镜像 README 的 Notice 形成完整的预警→落实弃用闭环。六、从镜像到运行拉取与使用方式6.1 直接拉取预构建镜像docker pull verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0 docker pull verlai/verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview6.2 本地构建可选若需从源码构建在仓库根目录执行# 先构建 Base 镜像含 FlashInfer 0.2.6.post1注意 FROM 标签与构建产物一致 docker build -f docker/verl0.5-preview-cu128-torch2.7.1-fa2.8.0/Dockerfile.base \ -t verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0-fi0.2.6 . # 再构建 App 镜像 docker build -f docker/verl0.5-preview-cu128-torch2.7.1-fa2.8.0/Dockerfile.app.sglang.megatron \ -t verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview .注意App 镜像的FROM引用的是带-fi0.2.6后缀的 Base 标签本地构建时需保证该标签已存在或先按上述命令构建。构建涉及 Apex、TransformerEngine、Megatron-LM 的源码编译耗时较长MAX_JOBS与--resume-retries 999等参数即为这类构建的稳定性而设。6.3 容器启动与 verl 安装启动容器并挂载工作区遵循 docker/README.md 中的通用启动方式docker create --runtimenvidia --gpus all --nethost --shm-size10g \ --cap-addSYS_ADMIN -v .:/workspace/verl \ --name verl verlai/verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview sleep infinity docker start verl docker exec -it verl bash容器内安装 verl镜像已含全部依赖故使用--no-depsgit clone https://github.com/verl-project/verl cd verl pip3 install --no-deps -e .之后即可通过python3 -m verl.trainer.main_ppo启动训练verl 的入口模块位于 verl/trainer/main_ppo.py由 SGLang 承担 rollout、FSDP 或 Megatron 承担训练具体参数可参考 verl/trainer/config 下的 YAML 配置。七、写在最后这套镜像在 verl 演进中的位置从当前仓库的视角回看v0.5 preview 镜像体现了 verl 镜像工程的两个核心方法论并在此后被继承与改进两级镜像隔离构建成本把最重的 CUDA/Torch/FlashAttention/Apex 编译产物沉淀在 Base 层App 层只做引擎装配与版本收敛。当前仓库 docker/README.md 描述的 v0.6.0 体系虽然将 Base 换成 vLLM/SGLang 官方 release 镜像v0.7.0 起改为nvidia/cuda基础镜像 独立装配但分层、可复用、可缓存的思路一脉相承精确版本锁定 ABI 匹配 下载稳定性从cxx11abi${ABI_FLAG}的动态 wheel 选择到aria2c --max-tries、pip --resume-retries 999再到 App 镜像内反复出现的版本收敛修复都指向同一个目标——让大模型 RL 训练环境在异构机器上可复现、可部署。对想要在 CUDA 12.8 PyTorch 2.7.1 上复现 verl v0.5 训练流程的读者直接使用app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview镜像是最稳妥的起点对希望理解 verl 镜像设计演进的读者Dockerfile.base 与 Dockerfile.app.sglang.megatron 则是不可多得的完整样例。【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
verl v0.5 Preview 镜像解析：CUDA 12.8 + PyTorch 2.7.1 下的 SGLang 与 Megatron 训练部署方案
verl v0.5 Preview 镜像解析CUDA 12.8 PyTorch 2.7.1 下的 SGLang 与 Megatron 训练部署方案【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verlverlHybridFlow是一个面向大模型 RL 后训练PPO/GRPO 等的高效训练框架其 Docker 镜像体系直接决定了训练与推理引擎的组装方式。本文围绕 docker/verl0.5-preview-cu128-torch2.7.1-fa2.8.0/README.md 展开结合同目录下的 Dockerfile.base 与 Dockerfile.app.sglang.megatron 逐层拆解这套 v0.5 preview 镜像的软件栈选型、构建步骤与使用前提帮助读者理解Base 镜像 App 镜像的两级镜像设计并据此搭建可复现的 verl 运行环境。一、镜像定位v0.5 Preview 的软件栈概览该目录提供的是 verl v0.5 预览版preview对应的镜像体系核心软件版本如下原文中列出的关键包版本cuda12.8 cudnn9.8.0 torch2.7.1 flash_attn2.8.0 sglang0.4.8 transformer_engine2.5 megatron.corecore_r0.13.0 nvidia-cudnn-cu129.8.0.87这套组合对应两条明确的训练 推理主线训练后端Megatron-LMmegatron.corecore_r0.13.0配合 TransformerEngine 2.5面向追求大规模扩展性的用户推理后端SGLang 0.4.8 承担 rollout 生成配套 FlashInfer 0.2.6.post1 加速注意力计算。值得注意的是vLLM 在此版本暂时不支持最新版本README 原文vllm temporarily not support latest version因此在 v0.5 preview 阶段官方提供的应用镜像只覆盖 SGLang 这一条推理引擎路线。从仓库当前状态看verl 已演进到 verl/version/version 中的0.10.0.dev而 docker/README.md 说明自 v0.6.0 起镜像体系改为以 vLLM/SGLang 官方 release 镜像为基底。本文介绍的 v0.5 preview 镜像属于此前的独立构建路线理解它可以清楚看到 verl 镜像从全手动装配走向基于上游引擎镜像的演进脉络。二、两级镜像设计Base 镜像与 App 镜像该目录采用 verl 长期沿用的Base App两级镜像结构官方预构建镜像标签如下层级镜像标签说明Base 镜像verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0内置 FlashInfer 0.2.6.post1 的基础镜像App 镜像verlai/verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview在 Base 之上叠加 SGLang 0.4.8 与 Megatron core_r0.13.0设计意图很清晰Base 镜像负责最重、最容易出错的底层编译产物——CUDA/Torch/FlashAttention/Apex/TransformerEngine且不携带任何推理或训练框架保证单一职责、可复用、可缓存App 镜像在 Base 之上按需叠加具体引擎此处为 SGLang Megatron从而在不同 App 镜像之间共享同一份底层 Base显著降低镜像体积与构建时间。对应到文件即 Dockerfile.base构建 Base 镜像与 Dockerfile.app.sglang.megatron构建 App 镜像。三、Base 镜像逐层拆解CUDA 12.8 训练底座是如何装配的Dockerfile.base 的注释明确说明其目标是Base Docker Image of verl, with CUDA/Torch/FlashAttn/Apex/TransformerEngine, without other frameworks。下面按构建顺序逐层说明。3.1 基底镜像与全局环境变量FROM nvcr.io/nvidia/pytorch:25.02-py3 ENV MAX_JOBS16 ENV VLLM_WORKER_MULTIPROC_METHODspawn ENV DEBIAN_FRONTENDnoninteractive ENV NODE_OPTIONS ENV PIP_ROOT_USER_ACTIONignore ENV HF_HUB_ENABLE_HF_TRANSFER1基底采用 NVIDIA NGC 的nvcr.io/nvidia/pytorch:25.02-py3Ubuntu 22.04 系容器。几个环境变量的作用MAX_JOBS16限制源码编译时的并行任务数防止pip install编译 Apex/FlashAttention 时把宿主机 CPU/内存打满VLLM_WORKER_MULTIPROC_METHODspawn固定 vLLM 多进程启动方式为spawn规避 fork 方式在多线程 CUDA 环境下的隐患DEBIAN_FRONTENDnoninteractiveapt 安装过程无需交互PIP_ROOT_USER_ACTIONignore允许在 root 下直接执行 pipHF_HUB_ENABLE_HF_TRANSFER1启用 hf-transfer 加速 Hugging Face 模型与数据集的下载Base 镜像安装清单中确实包含hf-transfer。3.2 镜像源替换面向国内网络环境ARG APT_SOURCEhttps://mirrors.tuna.tsinghua.edu.cn/ubuntu/ ARG PIP_INDEXhttps://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple通过ARG默认指向清华大学 TUNA 镜像先备份原 apt 源再整体替换为 jammy 系列源随后安装systemd、tini、aria2、libfreeimage3等基础工具并把 pip 默认 index 切到清华 PyPI 镜像最后在构建末尾用pip config unset还原避免污染镜像内默认 pip 配置。3.3 卸载 NGC fork 版本重装官方 PyTorch 2.7.1NGC 的 PyTorch 容器自带定制版 torch 全家桶与 verl 依赖的版本往往不匹配因此先整体卸载RUN pip uninstall -y torch torchvision torchaudio \ pytorch-quantization pytorch-triton torch-tensorrt \ xgboost transformer_engine flash_attn apex megatron-core grpcio再从官方 wheel 源安装与 CUDA 12.8 配套的版本RUN pip install --resume-retries 999 --no-cache-dir torch2.7.1 torchvision0.22.1 torchaudio2.7.1 --index-url https://download.pytorch.org/whl/cu128注意--resume-retries 999这一参数在后续所有大包安装中反复出现用于应对大体积 wheel 下载中断后的断点续传是长时间构建稳定性保障的关键细节。3.4 FlashAttention 2.8.0.post2按 CXX11 ABI 精确匹配RUN ABI_FLAG$(python -c import torch; print(TRUE if torch._C._GLIBCXX_USE_CXX11_ABI else FALSE)) \ URLhttps://github.com/Dao-AILab/flash-attention/releases/download/v2.8.0.post2/flash_attn-2.8.0.post2cu12torch2.7cxx11abi${ABI_FLAG}-cp312-cp312-linux_x86_64.whl \ FILEflash_attn-2.8.0.post2cu12torch2.7cxx11abi${ABI_FLAG}-cp312-cp312-linux_x86_64.whl \ wget -nv ${URL} \ pip install --no-cache-dir ${FILE}这里有一个非常关键的工程细节FlashAttention 的预编译 wheel 与 PyTorch 的_GLIBCXX_USE_CXX11_ABI标记强绑定。脚本先运行时探测当前 torch 的 ABI 标记再拼接出对应的cxx11abiTRUE/FALSE文件名下载 wheel保证二进制 ABI 完全一致避免运行时出现符号解析错误。这也是 README 版本清单中flash_attn2.8.0实际安装为2.8.0.post2被重点标注的原因。3.5 依赖修复与 cuDNN 9.8.0RUN pip uninstall -y pynvml nvidia-ml-py \ pip install --no-cache-dir --upgrade nvidia-ml-py12.560.30 fastapi[standard]0.115.0 optree0.13.0 pydantic2.9 grpcio1.62.1先卸载可能与 NGC 基线冲突的pynvml/nvidia-ml-py再升级nvidia-ml-pyGPU 监控/健康检查所需、fastapi、optree、pydantic、grpcio推理服务与 Ray 通信链路的公共依赖。cuDNN 9.8.0 通过 NVIDIA 官方本地仓库 deb 包安装RUN aria2c --max-tries9999 https://developer.download.nvidia.com/compute/cudnn/9.8.0/local_installers/cudnn-local-repo-ubuntu2204-9.8.0_1.0-1_amd64.deb \ dpkg -i cudnn-local-repo-ubuntu2204-9.8.0_1.0-1_amd64.deb \ cp /var/cudnn-local-repo-ubuntu2204-9.8.0/cudnn-*-keyring.gpg /usr/share/keyrings/ \ apt-get update \ apt-get -y install cudnn-cuda-12 \ rm cudnn-local-repo-ubuntu2204-9.8.0_1.0-1_amd64.deb这里使用aria2c而非 wget/curl并设置--max-tries9999同样是针对大文件下载的稳定性优化——这也是前面安装aria2的原因。3.6 Apex、NVIDIA Nsight Systems 与科学计算/RL 依赖Apex 从源码安装并显式开启--cpp_ext与--cuda_ext扩展RUN pip install -v --disable-pip-version-check --no-cache-dir --no-build-isolation --config-settings --build-option--cpp_ext --config-settings --build-option--cuda_ext --resume-retries 999 githttps://github.com/NVIDIA/apex.git调试工具链方面镜像内嵌 Nsight Systems 2025.3.1并把nsys/nsys-ui软链接到/usr/local/cuda/bin/便于在容器内直接做性能剖析。最后一批 Python 依赖覆盖了 verl 的运行时与开发需求RUN pip install --resume-retries 999 --no-cache-dir tensordict0.6.2 torchdata transformers[hf_xet]4.51.0 accelerate datasets peft hf-transfer \ numpy2.0.0 pyarrow19.0.1 pandas cuda-bindings \ ray[default] codetiming hydra-core pylatexenc qwen-vl-utils wandb dill pybind11 liger-kernel mathruler blobfile xgrammar \ pytest py-spy pre-commit ruff要点解读tensordict0.6.2verl 在 v0.5 时期的数据结构依赖当前仓库 setup.py 已升级到tensordict0.8.0,0.10.0可看到版本策略的演进transformers[hf_xet]4.51.0引入 hf_xet 加速 HF 下载numpy2.0.0v0.5 时期为兼容性锁定的下限约束liger-kernel、mathruler、qwen-vl-utils分别对应多模态、数学推理等 RL 训练场景的算子与工具依赖ray[default]verl 分布式调度Ray 驱动的核心依赖对应 verl/single_controller/ray 的实现。至此一个不带任何推理/训练框架的 CUDA 12.8 训练底座构建完成。四、App 镜像装配 SGLang 0.4.8 与 Megatron core_r0.13.0Dockerfile.app.sglang.megatron 直接以 Base 镜像为起点FROM verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0-fi0.2.6标签中的-fi0.2.6即指 Base 镜像内置 FlashInfer 0.2.6.post1README 中明确说明 We offer a base image with flash infer 0.2.6.post1 built in。随后按序装配4.1 FlashInfer 与 SGLangRUN pip install --resume-retries 999 --no-cache-dir --no-build-isolation flashinfer-python0.2.6.post1 RUN pip install --resume-retries 999 --no-cache-dir sglang[all]0.4.8 pip install torch-memory-saver --no-cache-dirflashinfer-python0.2.6.post1提供 SGLang 默认使用的 FlashInfer 注意力后端与 Base 镜像中 flash_attn 2.8.0.post2 形成双注意力加速配置sglang[all]0.4.8安装 SGLang 全功能依赖含 openai 兼容服务端等torch-memory-saver用于推理阶段的显存优化。4.2 依赖版本收敛App 镜像重复执行 Base 中的修复包操作nvidia-ml-py12.560.30、fastapi、optree、pydantic、grpcio并重新固定nvidia-cudnn-cu129.8.0.87目的与 Base 相同把 SGLang 及其传递依赖可能拉高/拉低的版本重新收敛到 verl 验证过的组合这正是多引擎镜像装配中版本漂移问题的典型处理手法。4.3 TransformerEngine 2.5 与 Megatron core_r0.13.0RUN export NVTE_FRAMEWORKpytorch pip3 install --resume-retries 999 --no-deps --no-cache-dir --no-build-isolation githttps://github.com/NVIDIA/TransformerEngine.gitrelease_v2.5 RUN pip3 install --no-deps --no-cache-dir --no-build-isolation githttps://github.com/NVIDIA/Megatron-LM.gitcore_r0.13.0 RUN pip3 install --no-cache-dir mbridgeTransformerEngine 从release_v2.5分支源码安装NVTE_FRAMEWORKpytorch声明框架后端Megatron-LM 锁定core_r0.13.0提交与 README 版本清单一致两者均使用--no-deps避免其传递依赖覆盖镜像内已收敛的版本mbridge是 verl 与 Megatron 之间的 bridge 依赖。当前仓库的 setup.py 中MCORE_REQUIRES [megatron-bridge, mbridge]仍然保留了这一依赖族印证其在整个 verl 演进过程中的持续地位。4.4 依赖版本汇总表综合 README 与两个 Dockerfile可将该 App 镜像的最终关键版本整理如下组件版本安装来源CUDA12.8NGC 25.02-py3 基底 cu128 torch wheelcuDNN9.8.0nvidia-cudnn-cu129.8.0.87NVIDIA 本地仓库 deb pip wheelPyTorch2.7.1torchvision 0.22.1 / torchaudio 2.7.1download.pytorch.org cu128FlashAttention2.8.0.post2cxx11abi 匹配Dao-AILab 预编译 wheelFlashInfer0.2.6.post1PyPISGLang0.4.8PyPIsglang[all]TransformerEngine2.5release_v2.5源码安装--no-depsMegatron-LMcore_r0.13.0源码安装--no-depsApex最新 git 主分支源码安装cpp_ext cuda_extNsight Systems2025.3.1NVIDIA 官方 deb五、重要使用须知vLLM 与 pyext 的限制README 以!!!Notice!!!明确列出两条约束任何基于该镜像搭建环境的人都必须知晓5.1 vLLM 暂不支持最新版本v0.5 preview 阶段仅提供 SGLang 推理引擎的应用镜像vLLM 最新版本在该组合下不受支持。若需使用 vLLM应转向其他镜像路线例如 docker/verl0.5-cu126-torch2.7-fa2.7.4 对应 CUDA 12.6 的镜像或当前仓库 docker/README.md 中基于 vLLM release 镜像的新体系。5.2 pyext 已进入弃用轨道pyext is lack of maintainace and cannot work with python 3.12, consider using replacement and deprecating this package.pyext原用于 PRIME 代码评分缺少维护且无法兼容 Python 3.12应寻找替代方案并推进弃用。这一预警在仓库源码中得到了落实当前 setup.py 中PRIME_REQUIRES []注释明确写道 Empty since PRIME code scoring droppedpyext; kept soverl[prime]stays installable——即新版 verl 已从代码评分链路中移除 pyext仅保留空依赖以维持verl[prime]的可安装性。这与镜像 README 的 Notice 形成完整的预警→落实弃用闭环。六、从镜像到运行拉取与使用方式6.1 直接拉取预构建镜像docker pull verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0 docker pull verlai/verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview6.2 本地构建可选若需从源码构建在仓库根目录执行# 先构建 Base 镜像含 FlashInfer 0.2.6.post1注意 FROM 标签与构建产物一致 docker build -f docker/verl0.5-preview-cu128-torch2.7.1-fa2.8.0/Dockerfile.base \ -t verlai/verl:base-verl0.5-preview-cu128-cudnn9.8-torch2.7.1-fa2.8.0-fi0.2.6 . # 再构建 App 镜像 docker build -f docker/verl0.5-preview-cu128-torch2.7.1-fa2.8.0/Dockerfile.app.sglang.megatron \ -t verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview .注意App 镜像的FROM引用的是带-fi0.2.6后缀的 Base 标签本地构建时需保证该标签已存在或先按上述命令构建。构建涉及 Apex、TransformerEngine、Megatron-LM 的源码编译耗时较长MAX_JOBS与--resume-retries 999等参数即为这类构建的稳定性而设。6.3 容器启动与 verl 安装启动容器并挂载工作区遵循 docker/README.md 中的通用启动方式docker create --runtimenvidia --gpus all --nethost --shm-size10g \ --cap-addSYS_ADMIN -v .:/workspace/verl \ --name verl verlai/verl:app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview sleep infinity docker start verl docker exec -it verl bash容器内安装 verl镜像已含全部依赖故使用--no-depsgit clone https://github.com/verl-project/verl cd verl pip3 install --no-deps -e .之后即可通过python3 -m verl.trainer.main_ppo启动训练verl 的入口模块位于 verl/trainer/main_ppo.py由 SGLang 承担 rollout、FSDP 或 Megatron 承担训练具体参数可参考 verl/trainer/config 下的 YAML 配置。七、写在最后这套镜像在 verl 演进中的位置从当前仓库的视角回看v0.5 preview 镜像体现了 verl 镜像工程的两个核心方法论并在此后被继承与改进两级镜像隔离构建成本把最重的 CUDA/Torch/FlashAttention/Apex 编译产物沉淀在 Base 层App 层只做引擎装配与版本收敛。当前仓库 docker/README.md 描述的 v0.6.0 体系虽然将 Base 换成 vLLM/SGLang 官方 release 镜像v0.7.0 起改为nvidia/cuda基础镜像 独立装配但分层、可复用、可缓存的思路一脉相承精确版本锁定 ABI 匹配 下载稳定性从cxx11abi${ABI_FLAG}的动态 wheel 选择到aria2c --max-tries、pip --resume-retries 999再到 App 镜像内反复出现的版本收敛修复都指向同一个目标——让大模型 RL 训练环境在异构机器上可复现、可部署。对想要在 CUDA 12.8 PyTorch 2.7.1 上复现 verl v0.5 训练流程的读者直接使用app-verl0.5-preview-sglang0.4.8-mcore0.13.0-preview镜像是最稳妥的起点对希望理解 verl 镜像设计演进的读者Dockerfile.base 与 Dockerfile.app.sglang.megatron 则是不可多得的完整样例。【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考