verl 在 AMD ROCm 上快速启动与性能调优实战指南【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl本篇技术指南基于 docs/amd_tutorial 系列文档系统讲解如何在 AMD 数据中心 GPUMI300X / MI325X / MI350X / MI355X上使用 ROCm 软件栈运行 verlHybridFlow RL 后训练框架从容器启动、环境验证到 GRPO / DAPO 训练示例的完整投产式流程并深入介绍 vLLM Sleep Mode、CUDA Graph 等 AMD 平台特有的性能调优手段。读者读完本文后将能够在 AMD ROCm 环境下一键拉起 verl 训练容器、跑通 FSDP / FSDP2 / Megatron 三套训练后端与 vLLM / SGLang 两种推理引擎的组合并针对长上下文与多节点场景显著降低显存占用、提升 rollout 吞吐。支持范围概览AMD 教程覆盖的运行时范围如下当前仓库文档声明运行时模式完整支持Fully Async全异步与Colocate同址两种模式推理引擎完整支持vLLM与SGLang训练后端FSDP、FSDP2与Megatron三类GPU 目标MI300X / MI325Xgfx942架构MI350X / MI355Xgfx950架构。其中gfx942/gfx950架构目标同样在 docker/rocm/Dockerfile.rocm 中通过ENV PYTORCH_ROCM_ARCHgfx942;gfx950与HIP_ARCHITECTURESgfx942,gfx950显式固化作为镜像编译阶段的默认架构。若需在更老的 MI200 / MI250gfx90a上构建可以覆盖架构参数但仓库明确标注“未经验证”。软件基线预构建镜像与从源码构建教程提供了两种获取运行环境的方式。方式一使用预构建镜像推荐教程与验证推荐的预构建镜像为amdagi/verl-dev:rocm7.14_torch2.12_release_0724该镜像对应 ROCm 7.14 PyTorch 2.12 的软件基线可直接docker pull后进入容器使用。方式二从源码构建 Dockerfile.rocm仓库提供了完整的 ROCm 构建配方 docker/rocm/Dockerfile.rocm。从 docker/rocm/README.md 可以看到其关键版本组合组件版本ROCm7.14Python3.12PyTorch2.12.0rocm7.14Triton3.7.0vLLM0.22.1rc1 源码 18d87a87dSGLang0.5.15 源码 0801cc05edFlash AttentionROCm forkCK 后端v2.8.3TransformerEngine2.14.0 ROCm fork e6ede467aiterROCm b5e03ed19megatron-core0.18.0该 Dockerfile 基于rocm/primus:v26.4基础镜像预构建下载而非编译ROCm 运行时、torch / apex / triton 等组件而从源码编译 vLLM 与 SGLang均固定到特定 commit并额外安装cupy-rocm、mbridge、megatron-core、megatron-bridge与 verl 本体。由于 Dockerfile 使用了 BuildKit 缓存挂载RUN --mount...本地构建必须启用 BuildKit含buildx插件例如DOCKER_BUILDKIT1 docker build \ -f docker/rocm/Dockerfile.rocm \ -t verl-rocm:local .README 还提供了两个常用的构建参数GPU_ARCH默认gfx942;gfx950可只留单一架构如gfx942以将 Flash Attention 编译时间缩短近一半和MAX_JOBS默认取nprocvLLM 编译内存不足时可调低如 64DOCKER_BUILDKIT1 docker build \ -f docker/rocm/Dockerfile.rocm \ --build-arg GPU_ARCHgfx942 \ --build-arg MAX_JOBS64 \ -t verl-rocm:mi300 .需要注意目录下其余Dockerfile.rocm*/Apptainerfile.rocm仅为旧版本ROCm 6.x、verl 0.3.x / 0.4.x的历史参考新工作应统一以Dockerfile.rocm为准。主机前置条件启动容器之前宿主机需满足以下三项条件ROCm 7.14 主机驱动栈已安装且运行健康Docker 可访问/dev/kfd与/dev/driROCm 设备文件数据集与模型存储路径已准备就绪例如挂载到容器内的训练数据与 HuggingFace 模型目录。启动容器教程给出的生产风格启动命令如下容器内工作目录固定为/workspaceNAMEverl_release DOCKERamdagi/verl-dev:rocm7.14_torch2.12_release_0724 docker pull $DOCKER docker run -it --name $NAME --device /dev/kfd --device /dev/dri \ --privileged --networkhost \ --group-add video --cap-addSYS_PTRACE --security-opt seccompunconfined \ --shm-size2048g \ --ulimit memlock-1 --ulimit stack67108864 \ -w /workspace \ $DOCKER \ /bin/bash各关键参数的作用说明--device /dev/kfd --device /dev/dri将 AMD GPU 的计算设备节点kfd与渲染/显示节点dri透传进容器是 ROCm 容器化运行的基础--privileged --networkhost便于 Ray 集群通信与 GPU 探测verl 基于 Ray 做分布式调度host 网络模式可规避容器网络对 NCCL/RAY 通信的干扰--group-add video使容器内进程具备访问 video 设备的组权限--cap-addSYS_PTRACE --security-opt seccompunconfined放宽容器安全策略适配 ROCm 驱动与调试工具需求--shm-size2048g放大共享内存支撑大 batch 下数据张量的跨进程传输--ulimit memlock-1 --ulimit stack67108864解除内存锁限制并加大栈空间避免大规模训练时缺页抖动或栈溢出。容器内环境检查进入容器后先验证 ROCm 与 PyTorch 环境是否就绪。第一步确认可见的 GPU 架构rocminfo | grep -E gfx942|gfx950 || true第二步PyTorch ROCm 冒烟检查python - PY import torch print(torch:, torch.__version__) print(rocm :, torch.version.hip) print(cuda_available:, torch.cuda.is_available()) if torch.cuda.is_available(): print(gpu_count:, torch.cuda.device_count()) print(device_0:, torch.cuda.get_device_name(0)) PY注意在 ROCm 构建中torch.cuda.is_available()返回的是 HIP 设备可用性PyTorch ROCm 版复用 CUDA 前端 APItorch.version.hip给出 ROCm 版本号。只有确认gpu_count与期望的卡数一致再进入下一步训练脚本。功能支持矩阵类别说明运行时模式Fully Async、Colocate推理引擎vLLM、SGLang训练后端FSDP、FSDP2、Megatron硬件MI300X / MI325Xgfx942、MI350X / MI355Xgfx950示例工作流8 种组合一键启动AMD 教程给出了运行时模式 × 推理引擎 × 训练后端的完整示例脚本矩阵。所有脚本均为仓库内真实存在的文件可直接从仓库根目录执行。运行时模式推理引擎训练后端示例脚本ColocatevLLMFSDPbash examples/grpo_trainer/run_qwen3_8b_fsdp.shColocatevLLMMegatronbash examples/grpo_trainer/run_qwen3_5_35b_megatron.shFully AsyncvLLMFSDP2bash verl/experimental/fully_async_policy/shell/dapo_7b_math_fsdp2_4_4.shFully AsyncvLLMMegatronbash verl/experimental/fully_async_policy/shell/geo3k_qwen25vl_7b_megatron_4_4.shColocateSGLangFSDP同 FSDP 脚本推理引擎 vllm→sglangColocateSGLangMegatron同 Megatron 脚本推理引擎 vllm→sglangFully AsyncSGLangFSDP2同 Fully Async FSDP2 脚本推理引擎 vllm→sglangFully AsyncSGLangMegatron同 Fully Async Megatron 脚本推理引擎 vllm→sglang其中 SGLang 组合通过把示例脚本中的推理引擎名由vllm切换为sglang实现脚本已内置INFER_BACKEND等开关无需另写脚本。Colocate vLLM FSDP 示例run_qwen3_8b_fsdp.shexamples/grpo_trainer/run_qwen3_8b_fsdp.sh 是一个 GRPO Qwen3-8B FSDP 的可调脚本。它提供了一批用户级旋钮便于在 AMD 平台微调INFER_BACKENDrollout 后端vllm/sglang/trtllm默认vllmDEVICE默认自动探测检测到torch_npu则为npu否则为gpu数据规模train_batch_size1024、ppo_mini_batch_size256、max_prompt_length1024、max_response_length2048、ppo_max_token_len_per_gpu24576优化器actor_lr1e-6、kl_loss_coef0.001、kl_loss_typelow_var_kl、entropy_coeff0rollouttensor_model_parallel_size默认 2、gpu_memory_utilization默认 0.6、n5次采样训练total_epochs15、save_freq20、test_freq5日志写入 console wandb。脚本在 GPU 分支默认关闭参数/优化器 offloadparam_offloadFalse、optimizer_offloadFalse并将actor_rollout_ref.rollout.name${INFER_BACKEND}传入verl.trainer.main_ppo最终启动命令为python3 -m verl.trainer.main_ppo ...。若希望使用系统 Python 直跑而非 uv 环境可设置VERL_USE_UV0。Colocate vLLM Megatron 示例run_qwen3_5_35b_megatron.shexamples/grpo_trainer/run_qwen3_5_35b_megatron.sh 展示 MoE 模型Qwen3.5-35B-A3BGDN 线性注意力在 8 卡单机上的 Megatron 训练已验证的并行配置为TP2 PP1 CP1 EP8 ETP1 GEN_TP8。脚本中与 AMD/ROCm 相关的要点由于 Qwen3.5 的 GDN 线性注意力暂不支持 Megatron 的 THD 打包序列格式脚本强制model.use_remove_paddingFalse、actor.megatron.use_remove_paddingFalse、actor.use_dynamic_bszFalse即 bshd 计算格式未来 Megatron 支持 THD 后可开启以获得更好性能通过actor_rollout_ref.actor.megatron.override_transformer_config.attention_backendauto等覆盖项控制注意力后端与 recompute 策略recompute_methoduniform、recompute_granularityfullMoE 相关覆盖项包括moe_aux_loss_coeff0.01、moe_z_loss_coeff0.001、moe_permute_fusionTrue、moe_grouped_gemmTruemodel_enginemegatron作为EXTRA参数显式指定训练后端。Fully Async FSDP2 示例dapo_7b_math_fsdp2_4_4.shverl/experimental/fully_async_policy/shell/dapo_7b_math_fsdp2_4_4.sh 是全异步 DAPO 训练脚本4 卡 rollout 4 卡训练包含rollout_modeasync、export VLLM_USE_V11、return_raw_chatTrue全异步模式要求 vLLM V1 引擎与原始对话返回算法参数adv_estimatorgrpo、clip_ratio_low0.2、clip_ratio_high0.28、loss_agg_modetoken-mean长上下文max_prompt_length2048、max_response_length8192、enable_overlong_bufferTrue、overlong_buffer_len4096、overlong_penalty_factor1.0异步流水参数staleness_threshold0.1、trigger_parameter_sync_step4、require_batches4、partial_rolloutTruen_gpus_rollout4、n_gpus_training$((NGPUS_PER_NODE - n_gpus_rollout))将节点内 GPU 划分为 rollout 组与训练组。该脚本头部注释特别提醒使用 Qwen2.5-Math-7B 时下载模型后必须将config.json中的max_position_embeddings修改为 32768与 AMD 教程“已知问题”第 1 条一致。已知问题与规避AMD 平台AMD 教程明确列出了四条已知问题这是 AMD 平台上跑通训练的关键前置知识Qwen2.5-Math-7B 的max_position_embeddings模型下载后需将config.json中的max_position_embeddings更新为 32768否则长上下文训练会因位置编码上限报错PYTORCH_ALLOC_CONFexpandable_segments:True与disable_custom_all_reduce为防止 OOMdocker/rocm/Dockerfile.rocm 默认设置PYTORCH_ALLOC_CONFexpandable_segments:True但该设置可能与 vLLM 的vllm_custom_all_reduce冲突因此 Dockerfile 在安装 verl 时通过 sed 把rollout.yaml中的vllm.disable_custom_all_reduce与sglang.disable_custom_all_reduce默认置为True待 ROCm 侧解决冲突后这一默认会被移除SGLang 的attention_backend必须设置为tritonDockerfile 在安装阶段同步写入sglang.attention_backend: triton并设置环境变量SGLANG_ATTENTION_BACKENDtriton、SGLANG_USE_AITER0vLLM / SGLang 的 ROCm 专用补丁部分 ROCm 相关的上游 PR 尚未合入官方主线Dockerfile 目前直接在构建阶段以sed打入补丁例如 vLLM 的 cumem_allocator 显存清零、MoE 权重存储修复SGLang 的 fused_add_rms_norm 修复等未来将转向官方稳定版本。此外docker/rocm/Dockerfile.rocm 还固化了一批对 AMD 运行至关重要的环境变量可作为排障依据ENV NVTE_USE_GROUPED_GEMM_TRITON1TransformerEngine 使用 Triton grouped GEMMENV NCCL_DEBUGERROR收敛 NCCL 日志级别ENV HSA_ENABLE_IPC_MODE_LEGACY1启用 HSA IPC 传统模式保证跨进程共享内存可用ENV MIOPEN_DEBUG_FORCE_IMMED_MODE_FALLBACK1规避 MIOpen 即时模式在部分场景的编译卡死。vLLM Sleep Mode 性能调优MI3xx 系列在 AMD MI3xx 系列 GPU 上verl 默认要求 vLLM 启用sleep moderollout 结束后 vLLM 将 GPU 显存卸载offload到 CPU 内存。该特性已合入 vLLM 0.11.0 之后的主线版本。构建启用 Sleep Mode 的 vLLM在官方 ROCm wheel 尚未就绪vLLM 0.11.0 版本的情况下可按如下步骤从源码构建git clone https://github.com/vllm-project/vllm.git cd vllm git reset --hard 4ca5cd5740c0cd7788cdfa8b7ec6a27335607a48 # 也可使用更新的 commit python -m pip install -r requirements/rocm.txt VLLM_TARGET_DEVICErocm ROCM_PATH/opt/rocm/ python3 setup.py develop同时建议 ROCm 版本不低于 7.0。升级完成后可通过 sleep 前后显存占用是否显著下降来验证 sleep mode 是否生效sleep 之后显存占用应明显降低。在 verl 中启用 Sleep Mode 的收益在 verl 配置中启用 sleep mode 后verl 可以在 rollout 阶段卸载未使用的 GPU 显存从而显著降低长上下文训练或多节点强化学习过程中的显存足迹——这也是 AMD 平台跑大模型 RL 的关键优化手段之一。说明仓库内 docker/rocm/Dockerfile.rocm 为 vLLM 集成了 sleep/wake 相关的 ROCm 修复如csrc/cumem_allocator.cpp中新增的hipMemset清零逻辑对应上游 PR #44972该修复正是保证 sleep 后重新唤醒时显存数据干净、不出现 stale 数据的关键补丁。启用 CUDA Graph 并绕过 ROCm 相关问题问题背景在 ROCm 上CUDA graph在 AMD 平台实际为 HIP graph捕获存在潜在问题verl 在 AMD 平台 vLLM V1 模式下无法在多节点上启用 vLLM 的 CUDA graph这会导致 rollout 性能显著下降。调查表明 ROCm 在捕获大 batch 的 CUDA graph 时可能触发意外崩溃。解决方案第一步限定 cudagraph 捕获的 batch 尺寸集合在 verl 配置文件中设置actor_rollout_ref.rollout.cudagraph_capture_sizes[1, 2, 4, 8, 16, 32, 64]具体数值需根据 GPU 显存大小调整。从 verl/trainer/config/rollout/rollout.yaml 的注释可知该参数的设计意图cudagraph_capture_sizes只有在enforce_eager: False时生效由于推理引擎的 cudagraph 在策略更新阶段无法被 offload使用更小的 batch 尺寸集合如[1, 2, 4, 8, 16, 32]可以节省 cudagraph 占用的显存该选项当前仅 vLLM 引擎支持。第二步显式关闭 eager 模式以启用 CUDA graphactor_rollout_ref.rollout.enforce_eagerFalseenforce_eager的默认值即False对应 rollout.yaml 中“默认 False 以获得最佳性能”的注释但在 AMD 平台需确认配置文件中未被误置为True。同时可结合free_cache_engineTrue默认值见 rollout.yaml在生成结束后释放引擎 KV cache进一步缓解显存压力。延伸阅读AMD 快速上手原文档docs/amd_tutorial/amd_quick_start.rstAMD vLLM 性能调优原文档docs/amd_tutorial/amd_vllm_page.rstROCm 镜像构建配方与版本清单docker/rocm/Dockerfile.rocm、docker/rocm/README.mdNVIDIA 镜像说明AMD 环境不可用需改用 ROCm 镜像docker/README.md更多训练示例脚本见 examples/grpo_trainer 与 verl/experimental/fully_async_policy/shell多芯片平台支持总览docs/hardware/multi_chip_support.rst【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 verl 在 AMD ROCm 上快速启动与性能调优实战指南
verl 在 AMD ROCm 上快速启动与性能调优实战指南【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl本篇技术指南基于 docs/amd_tutorial 系列文档系统讲解如何在 AMD 数据中心 GPUMI300X / MI325X / MI350X / MI355X上使用 ROCm 软件栈运行 verlHybridFlow RL 后训练框架从容器启动、环境验证到 GRPO / DAPO 训练示例的完整投产式流程并深入介绍 vLLM Sleep Mode、CUDA Graph 等 AMD 平台特有的性能调优手段。读者读完本文后将能够在 AMD ROCm 环境下一键拉起 verl 训练容器、跑通 FSDP / FSDP2 / Megatron 三套训练后端与 vLLM / SGLang 两种推理引擎的组合并针对长上下文与多节点场景显著降低显存占用、提升 rollout 吞吐。支持范围概览AMD 教程覆盖的运行时范围如下当前仓库文档声明运行时模式完整支持Fully Async全异步与Colocate同址两种模式推理引擎完整支持vLLM与SGLang训练后端FSDP、FSDP2与Megatron三类GPU 目标MI300X / MI325Xgfx942架构MI350X / MI355Xgfx950架构。其中gfx942/gfx950架构目标同样在 docker/rocm/Dockerfile.rocm 中通过ENV PYTORCH_ROCM_ARCHgfx942;gfx950与HIP_ARCHITECTURESgfx942,gfx950显式固化作为镜像编译阶段的默认架构。若需在更老的 MI200 / MI250gfx90a上构建可以覆盖架构参数但仓库明确标注“未经验证”。软件基线预构建镜像与从源码构建教程提供了两种获取运行环境的方式。方式一使用预构建镜像推荐教程与验证推荐的预构建镜像为amdagi/verl-dev:rocm7.14_torch2.12_release_0724该镜像对应 ROCm 7.14 PyTorch 2.12 的软件基线可直接docker pull后进入容器使用。方式二从源码构建 Dockerfile.rocm仓库提供了完整的 ROCm 构建配方 docker/rocm/Dockerfile.rocm。从 docker/rocm/README.md 可以看到其关键版本组合组件版本ROCm7.14Python3.12PyTorch2.12.0rocm7.14Triton3.7.0vLLM0.22.1rc1 源码 18d87a87dSGLang0.5.15 源码 0801cc05edFlash AttentionROCm forkCK 后端v2.8.3TransformerEngine2.14.0 ROCm fork e6ede467aiterROCm b5e03ed19megatron-core0.18.0该 Dockerfile 基于rocm/primus:v26.4基础镜像预构建下载而非编译ROCm 运行时、torch / apex / triton 等组件而从源码编译 vLLM 与 SGLang均固定到特定 commit并额外安装cupy-rocm、mbridge、megatron-core、megatron-bridge与 verl 本体。由于 Dockerfile 使用了 BuildKit 缓存挂载RUN --mount...本地构建必须启用 BuildKit含buildx插件例如DOCKER_BUILDKIT1 docker build \ -f docker/rocm/Dockerfile.rocm \ -t verl-rocm:local .README 还提供了两个常用的构建参数GPU_ARCH默认gfx942;gfx950可只留单一架构如gfx942以将 Flash Attention 编译时间缩短近一半和MAX_JOBS默认取nprocvLLM 编译内存不足时可调低如 64DOCKER_BUILDKIT1 docker build \ -f docker/rocm/Dockerfile.rocm \ --build-arg GPU_ARCHgfx942 \ --build-arg MAX_JOBS64 \ -t verl-rocm:mi300 .需要注意目录下其余Dockerfile.rocm*/Apptainerfile.rocm仅为旧版本ROCm 6.x、verl 0.3.x / 0.4.x的历史参考新工作应统一以Dockerfile.rocm为准。主机前置条件启动容器之前宿主机需满足以下三项条件ROCm 7.14 主机驱动栈已安装且运行健康Docker 可访问/dev/kfd与/dev/driROCm 设备文件数据集与模型存储路径已准备就绪例如挂载到容器内的训练数据与 HuggingFace 模型目录。启动容器教程给出的生产风格启动命令如下容器内工作目录固定为/workspaceNAMEverl_release DOCKERamdagi/verl-dev:rocm7.14_torch2.12_release_0724 docker pull $DOCKER docker run -it --name $NAME --device /dev/kfd --device /dev/dri \ --privileged --networkhost \ --group-add video --cap-addSYS_PTRACE --security-opt seccompunconfined \ --shm-size2048g \ --ulimit memlock-1 --ulimit stack67108864 \ -w /workspace \ $DOCKER \ /bin/bash各关键参数的作用说明--device /dev/kfd --device /dev/dri将 AMD GPU 的计算设备节点kfd与渲染/显示节点dri透传进容器是 ROCm 容器化运行的基础--privileged --networkhost便于 Ray 集群通信与 GPU 探测verl 基于 Ray 做分布式调度host 网络模式可规避容器网络对 NCCL/RAY 通信的干扰--group-add video使容器内进程具备访问 video 设备的组权限--cap-addSYS_PTRACE --security-opt seccompunconfined放宽容器安全策略适配 ROCm 驱动与调试工具需求--shm-size2048g放大共享内存支撑大 batch 下数据张量的跨进程传输--ulimit memlock-1 --ulimit stack67108864解除内存锁限制并加大栈空间避免大规模训练时缺页抖动或栈溢出。容器内环境检查进入容器后先验证 ROCm 与 PyTorch 环境是否就绪。第一步确认可见的 GPU 架构rocminfo | grep -E gfx942|gfx950 || true第二步PyTorch ROCm 冒烟检查python - PY import torch print(torch:, torch.__version__) print(rocm :, torch.version.hip) print(cuda_available:, torch.cuda.is_available()) if torch.cuda.is_available(): print(gpu_count:, torch.cuda.device_count()) print(device_0:, torch.cuda.get_device_name(0)) PY注意在 ROCm 构建中torch.cuda.is_available()返回的是 HIP 设备可用性PyTorch ROCm 版复用 CUDA 前端 APItorch.version.hip给出 ROCm 版本号。只有确认gpu_count与期望的卡数一致再进入下一步训练脚本。功能支持矩阵类别说明运行时模式Fully Async、Colocate推理引擎vLLM、SGLang训练后端FSDP、FSDP2、Megatron硬件MI300X / MI325Xgfx942、MI350X / MI355Xgfx950示例工作流8 种组合一键启动AMD 教程给出了运行时模式 × 推理引擎 × 训练后端的完整示例脚本矩阵。所有脚本均为仓库内真实存在的文件可直接从仓库根目录执行。运行时模式推理引擎训练后端示例脚本ColocatevLLMFSDPbash examples/grpo_trainer/run_qwen3_8b_fsdp.shColocatevLLMMegatronbash examples/grpo_trainer/run_qwen3_5_35b_megatron.shFully AsyncvLLMFSDP2bash verl/experimental/fully_async_policy/shell/dapo_7b_math_fsdp2_4_4.shFully AsyncvLLMMegatronbash verl/experimental/fully_async_policy/shell/geo3k_qwen25vl_7b_megatron_4_4.shColocateSGLangFSDP同 FSDP 脚本推理引擎 vllm→sglangColocateSGLangMegatron同 Megatron 脚本推理引擎 vllm→sglangFully AsyncSGLangFSDP2同 Fully Async FSDP2 脚本推理引擎 vllm→sglangFully AsyncSGLangMegatron同 Fully Async Megatron 脚本推理引擎 vllm→sglang其中 SGLang 组合通过把示例脚本中的推理引擎名由vllm切换为sglang实现脚本已内置INFER_BACKEND等开关无需另写脚本。Colocate vLLM FSDP 示例run_qwen3_8b_fsdp.shexamples/grpo_trainer/run_qwen3_8b_fsdp.sh 是一个 GRPO Qwen3-8B FSDP 的可调脚本。它提供了一批用户级旋钮便于在 AMD 平台微调INFER_BACKENDrollout 后端vllm/sglang/trtllm默认vllmDEVICE默认自动探测检测到torch_npu则为npu否则为gpu数据规模train_batch_size1024、ppo_mini_batch_size256、max_prompt_length1024、max_response_length2048、ppo_max_token_len_per_gpu24576优化器actor_lr1e-6、kl_loss_coef0.001、kl_loss_typelow_var_kl、entropy_coeff0rollouttensor_model_parallel_size默认 2、gpu_memory_utilization默认 0.6、n5次采样训练total_epochs15、save_freq20、test_freq5日志写入 console wandb。脚本在 GPU 分支默认关闭参数/优化器 offloadparam_offloadFalse、optimizer_offloadFalse并将actor_rollout_ref.rollout.name${INFER_BACKEND}传入verl.trainer.main_ppo最终启动命令为python3 -m verl.trainer.main_ppo ...。若希望使用系统 Python 直跑而非 uv 环境可设置VERL_USE_UV0。Colocate vLLM Megatron 示例run_qwen3_5_35b_megatron.shexamples/grpo_trainer/run_qwen3_5_35b_megatron.sh 展示 MoE 模型Qwen3.5-35B-A3BGDN 线性注意力在 8 卡单机上的 Megatron 训练已验证的并行配置为TP2 PP1 CP1 EP8 ETP1 GEN_TP8。脚本中与 AMD/ROCm 相关的要点由于 Qwen3.5 的 GDN 线性注意力暂不支持 Megatron 的 THD 打包序列格式脚本强制model.use_remove_paddingFalse、actor.megatron.use_remove_paddingFalse、actor.use_dynamic_bszFalse即 bshd 计算格式未来 Megatron 支持 THD 后可开启以获得更好性能通过actor_rollout_ref.actor.megatron.override_transformer_config.attention_backendauto等覆盖项控制注意力后端与 recompute 策略recompute_methoduniform、recompute_granularityfullMoE 相关覆盖项包括moe_aux_loss_coeff0.01、moe_z_loss_coeff0.001、moe_permute_fusionTrue、moe_grouped_gemmTruemodel_enginemegatron作为EXTRA参数显式指定训练后端。Fully Async FSDP2 示例dapo_7b_math_fsdp2_4_4.shverl/experimental/fully_async_policy/shell/dapo_7b_math_fsdp2_4_4.sh 是全异步 DAPO 训练脚本4 卡 rollout 4 卡训练包含rollout_modeasync、export VLLM_USE_V11、return_raw_chatTrue全异步模式要求 vLLM V1 引擎与原始对话返回算法参数adv_estimatorgrpo、clip_ratio_low0.2、clip_ratio_high0.28、loss_agg_modetoken-mean长上下文max_prompt_length2048、max_response_length8192、enable_overlong_bufferTrue、overlong_buffer_len4096、overlong_penalty_factor1.0异步流水参数staleness_threshold0.1、trigger_parameter_sync_step4、require_batches4、partial_rolloutTruen_gpus_rollout4、n_gpus_training$((NGPUS_PER_NODE - n_gpus_rollout))将节点内 GPU 划分为 rollout 组与训练组。该脚本头部注释特别提醒使用 Qwen2.5-Math-7B 时下载模型后必须将config.json中的max_position_embeddings修改为 32768与 AMD 教程“已知问题”第 1 条一致。已知问题与规避AMD 平台AMD 教程明确列出了四条已知问题这是 AMD 平台上跑通训练的关键前置知识Qwen2.5-Math-7B 的max_position_embeddings模型下载后需将config.json中的max_position_embeddings更新为 32768否则长上下文训练会因位置编码上限报错PYTORCH_ALLOC_CONFexpandable_segments:True与disable_custom_all_reduce为防止 OOMdocker/rocm/Dockerfile.rocm 默认设置PYTORCH_ALLOC_CONFexpandable_segments:True但该设置可能与 vLLM 的vllm_custom_all_reduce冲突因此 Dockerfile 在安装 verl 时通过 sed 把rollout.yaml中的vllm.disable_custom_all_reduce与sglang.disable_custom_all_reduce默认置为True待 ROCm 侧解决冲突后这一默认会被移除SGLang 的attention_backend必须设置为tritonDockerfile 在安装阶段同步写入sglang.attention_backend: triton并设置环境变量SGLANG_ATTENTION_BACKENDtriton、SGLANG_USE_AITER0vLLM / SGLang 的 ROCm 专用补丁部分 ROCm 相关的上游 PR 尚未合入官方主线Dockerfile 目前直接在构建阶段以sed打入补丁例如 vLLM 的 cumem_allocator 显存清零、MoE 权重存储修复SGLang 的 fused_add_rms_norm 修复等未来将转向官方稳定版本。此外docker/rocm/Dockerfile.rocm 还固化了一批对 AMD 运行至关重要的环境变量可作为排障依据ENV NVTE_USE_GROUPED_GEMM_TRITON1TransformerEngine 使用 Triton grouped GEMMENV NCCL_DEBUGERROR收敛 NCCL 日志级别ENV HSA_ENABLE_IPC_MODE_LEGACY1启用 HSA IPC 传统模式保证跨进程共享内存可用ENV MIOPEN_DEBUG_FORCE_IMMED_MODE_FALLBACK1规避 MIOpen 即时模式在部分场景的编译卡死。vLLM Sleep Mode 性能调优MI3xx 系列在 AMD MI3xx 系列 GPU 上verl 默认要求 vLLM 启用sleep moderollout 结束后 vLLM 将 GPU 显存卸载offload到 CPU 内存。该特性已合入 vLLM 0.11.0 之后的主线版本。构建启用 Sleep Mode 的 vLLM在官方 ROCm wheel 尚未就绪vLLM 0.11.0 版本的情况下可按如下步骤从源码构建git clone https://github.com/vllm-project/vllm.git cd vllm git reset --hard 4ca5cd5740c0cd7788cdfa8b7ec6a27335607a48 # 也可使用更新的 commit python -m pip install -r requirements/rocm.txt VLLM_TARGET_DEVICErocm ROCM_PATH/opt/rocm/ python3 setup.py develop同时建议 ROCm 版本不低于 7.0。升级完成后可通过 sleep 前后显存占用是否显著下降来验证 sleep mode 是否生效sleep 之后显存占用应明显降低。在 verl 中启用 Sleep Mode 的收益在 verl 配置中启用 sleep mode 后verl 可以在 rollout 阶段卸载未使用的 GPU 显存从而显著降低长上下文训练或多节点强化学习过程中的显存足迹——这也是 AMD 平台跑大模型 RL 的关键优化手段之一。说明仓库内 docker/rocm/Dockerfile.rocm 为 vLLM 集成了 sleep/wake 相关的 ROCm 修复如csrc/cumem_allocator.cpp中新增的hipMemset清零逻辑对应上游 PR #44972该修复正是保证 sleep 后重新唤醒时显存数据干净、不出现 stale 数据的关键补丁。启用 CUDA Graph 并绕过 ROCm 相关问题问题背景在 ROCm 上CUDA graph在 AMD 平台实际为 HIP graph捕获存在潜在问题verl 在 AMD 平台 vLLM V1 模式下无法在多节点上启用 vLLM 的 CUDA graph这会导致 rollout 性能显著下降。调查表明 ROCm 在捕获大 batch 的 CUDA graph 时可能触发意外崩溃。解决方案第一步限定 cudagraph 捕获的 batch 尺寸集合在 verl 配置文件中设置actor_rollout_ref.rollout.cudagraph_capture_sizes[1, 2, 4, 8, 16, 32, 64]具体数值需根据 GPU 显存大小调整。从 verl/trainer/config/rollout/rollout.yaml 的注释可知该参数的设计意图cudagraph_capture_sizes只有在enforce_eager: False时生效由于推理引擎的 cudagraph 在策略更新阶段无法被 offload使用更小的 batch 尺寸集合如[1, 2, 4, 8, 16, 32]可以节省 cudagraph 占用的显存该选项当前仅 vLLM 引擎支持。第二步显式关闭 eager 模式以启用 CUDA graphactor_rollout_ref.rollout.enforce_eagerFalseenforce_eager的默认值即False对应 rollout.yaml 中“默认 False 以获得最佳性能”的注释但在 AMD 平台需确认配置文件中未被误置为True。同时可结合free_cache_engineTrue默认值见 rollout.yaml在生成结束后释放引擎 KV cache进一步缓解显存压力。延伸阅读AMD 快速上手原文档docs/amd_tutorial/amd_quick_start.rstAMD vLLM 性能调优原文档docs/amd_tutorial/amd_vllm_page.rstROCm 镜像构建配方与版本清单docker/rocm/Dockerfile.rocm、docker/rocm/README.mdNVIDIA 镜像说明AMD 环境不可用需改用 ROCm 镜像docker/README.md更多训练示例脚本见 examples/grpo_trainer 与 verl/experimental/fully_async_policy/shell多芯片平台支持总览docs/hardware/multi_chip_support.rst【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考