GRPO与LoRA在多GPU上训练Qwen2.5的工程实践

1. 项目概述：GRPO与LoRA在多GPU上训练Qwen2.5的工程实践

在当前的AI领域，强化学习（RL）已经成为提升大语言模型（LLM）推理能力的关键技术。然而，传统的PPO（Proximal Policy Optimization）方法存在内存占用高、计算开销大的问题。GRPO（Group Relative Policy Optimization）通过创新的基线估计方式，显著降低了资源消耗。本文将详细介绍如何在多GPU环境下，使用Verl框架结合LoRA技术高效训练Qwen2.5-3B-Instruct模型。

1.1 为什么选择GRPO+LoRA架构

传统PPO需要同时加载四个组件到VRAM：Actor（策略模型）、Critic（价值函数）、Reference（参考模型）和Reward模型。其中Critic通常是主要瓶颈，其大小通常与Actor相当，这相当于使内存使用量翻倍。GRPO通过改变基线估计方式解决了这个问题：

• 组响应采样：对同一提示生成一组响应（例如G=5）
• 平均奖励基线：计算组内响应的平均奖励作为基线
• 相对强化：根据每个响应相对于组平均的表现进行强化或惩罚

这种方法的优势显而易见：

• VRAM使用降低约50%（无需单独的价值函数模型）
• 训练循环更简单快速（无需计算Critic损失）
• 自我纠正机制：鼓励模型超越自身平均水平，自然促进更强的推理能力

1.2 模型选择：Qwen 2.5 3B Instruct

我们选择Qwen 2.5 3B Instruct作为基础模型，主要基于以下考虑：

1. 3B参数的效率优势：

   • 足够小以实现快速迭代（高吞吐量）
   • 足够智能以学习GSM8K数学推理
   • 在A100等高端GPU上可以实现高并行度

2. Instruct版本的稳定性：

   • 从指令调优的检查点开始，为RL提供稳定的"冷启动"
   • 避免从零开始RL调优时常见的无意义输出问题
   • 已经具备基本的指令跟随能力，减少训练初期的不稳定性

1.3 框架选择：VERL + vLLM

RL后训练是一种混合工作负载，需要在生成（内存带宽受限）和训练（计算受限）之间交替进行。我们选择的框架组合解决了这一挑战：

• vLLM：专为高效生成设计，提供高吞吐量的推理能力
• Verl：管理训练循环和推理引擎之间的复杂状态传递
  • 协调生成和训练阶段的资源分配
  • 实现A100 GPU的饱和利用
  • 提供工业级分布式训练支持

这种组合特别适合生产环境，已被字节跳动等顶级实验室的团队广泛采用。然而，企业级框架的强大功能往往伴随着陡峭的学习曲线，这也是本文旨在解决的问题之一。

2. 基础设施设置与环境配置

2.1 硬件配置

我们在RunPod实例上进行部署，具体配置如下：

• GPU：4×NVIDIA A100（80GB）SXM
• 基础镜像：runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
• 目标：建立干净、可复现的Conda环境

提示：在实际操作中，确保你的云实例有足够的临时存储空间（至少200GB），以容纳大型检查点和数据集。

2.2 环境初始化步骤

2.2.1 Miniconda安装

首先安装Miniconda，将我们的环境与系统Python解耦，防止版本冲突：

bash复制# 1. 安装Miniconda（如果尚未安装）
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash ./Miniconda3-latest-Linux-x86_64.sh

2.2.2 Python环境创建

我们使用Python 3.12以确保与最新框架的完全兼容：

bash复制# 2. 创建环境
conda create -n verl python=3.12 -y
conda activate verl

2.2.3 仓库克隆

获取Verl框架源代码：

bash复制# 3. 克隆仓库
git clone https://github.com/volcengine/verl
cd verl

2.3 框架安装与依赖管理

Verl提供了一个便捷脚本(install_vllm_sglang_mcore.sh)来处理复杂的依赖关系树：

bash复制# 1. 运行官方脚本安装基础依赖
chmod +x ./scripts/install_vllm_sglang_mcore.sh
bash ./scripts/install_vllm_sglang_mcore.sh

注意：在"Building Megatron-LM"阶段可能会挂起15分钟以上，这属于正常现象。

基础架构就绪后，以可编辑模式完成Verl安装：

bash复制# 2. 安装Verl
pip install --no-deps -e .

专业提示：如果遇到Python 3.12导致的递归或导入错误，可以回退到Python 3.11。在这种情况下，可能需要手动安装预编译的Flash Attention wheel文件。

3. 数据管道准备

3.1 数据集格式化

强化学习对数据格式非常敏感。常见的陷阱是在没有将提示结构与奖励函数对齐的情况下将原始数据集输入训练器。对于本实验，我们使用标准的GSM8K数据集。

运行预处理器以构建训练/测试集的parquet文件：

bash复制# 生成'train.parquet'和'test.parquet'到./data/gsm8k
python3 examples/data_preprocess/gsm8k.py --local_dir "./data/gsm8k"

关于"Think Tags"的说明：与DeepSeek-R1不同，标准Verl预处理器使用通用的思维链提示("Let's think step by step")，默认不注入标签。这意味着我们的模型将学习用纯文本进行推理，这在数学上是等效的，但在评估时需要不同的解析逻辑。

3.2 数据加载优化

为提高训练效率，我们进行了以下数据加载优化：

1. 批处理大小：根据GPU内存容量调整train_batch_size
2. 长度过滤：设置max_prompt_length=512和max_response_length=1024
3. 内存映射：使用parquet格式实现高效的内存映射加载
4. 预处理缓存：在首次运行时预处理并缓存数据，减少后续启动时间

这些优化显著减少了训练迭代间的等待时间，使GPU保持高利用率。

4. 训练配置与优化

4.1 基础训练脚本

我们使用LoRA+GRPO工作流，Verl提供了参考脚本：examples/grpo_trainer/run_qwen2_5-3b_gsm8k_grpo_lora.sh。默认配置如下：

bash复制set -x
python3 -m verl.trainer.main_ppo \
  algorithm.adv_estimator=grpo \
  trainer.val_before_train=False \
  data.train_files=$HOME/data/gsm8k/train.parquet \
  data.val_files=$HOME/data/gsm8k/test.parquet \
  data.train_batch_size=16 \
  data.max_prompt_length=512 \
  data.max_response_length=1024 \
  data.filter_overlong_prompts=True \
  data.truncation='error' \
  data.shuffle=False \
  actor_rollout_ref.model.path=Qwen/Qwen2.5-3B-Instruct \
  actor_rollout_ref.model.lora_rank=64 \
  actor_rollout_ref.model.lora_alpha=32 \
  actor_rollout_ref.actor.optim.lr=3e-6 \
  actor_rollout_ref.model.use_remove_padding=True \
  actor_rollout_ref.actor.ppo_mini_batch_size=16 \
  actor_rollout_ref.actor.ppo_micro_batch_size_per_gpu=40 \
  actor_rollout_ref.actor.use_kl_loss=True \
  actor_rollout_ref.actor.kl_loss_coef=0.001 \
  actor_rollout_ref.actor.kl_loss_type=low_var_kl \
  actor_rollout_ref.actor.entropy_coeff=0 \
  actor_rollout_ref.model.enable_gradient_checkpointing=True \
  actor_rollout_ref.actor.fsdp_config.param_offload=False \
  actor_rollout_ref.actor.fsdp_config.optimizer_offload=False \
  actor_rollout_ref.rollout.log_prob_micro_batch_size_per_gpu=40 \
  actor_rollout_ref.rollout.tensor_model_parallel_size=2 \
  actor_rollout_ref.rollout.name=vllm \
  actor_rollout_ref.rollout.gpu_memory_utilization=0.6 \
  actor_rollout_ref.rollout.n=5 \
  actor_rollout_ref.rollout.load_format=safetensors \
  actor_rollout_ref.rollout.layered_summon=True \
  actor_rollout_ref.ref.log_prob_micro_batch_size_per_gpu=40 \
  actor_rollout_ref.ref.fsdp_config.param_offload=True \
  algorithm.use_kl_in_reward=False \
  trainer.critic_warmup=0 \
  trainer.logger='["console","wandb"]' \
  trainer.project_name='verl_grpo_example_gsm8k' \
  trainer.experiment_name='qwen2.5_3b_grpo_lora' \
  trainer.n_gpus_per_node=2 \
  trainer.nnodes=1 \
  trainer.save_freq=20 \
  trainer.test_freq=5 \
  trainer.total_epochs=15 $@

4.2 关键超参数优化

默认值对于4×A100 80GB配置来说效率极低。我们识别了以下瓶颈并进行优化：

1. GPU数量：trainer.n_gpus_per_node从2增加到4
2. 全局批大小：data.train_batch_size从16增加到1024
3. 微批大小：ppo_micro_batch_size_per_gpu从40调整到更合适的值
4. PPO更新批大小：ppo_mini_batch_size从16增加到512
5. 模型并行度：rollout.tensor_model_parallel_size从2调整到1（改为数据并行）
6. VRAM利用率：rollout.gpu_memory_utilization从0.6提高到0.8
7. 组响应数量：rollout.n保持为5（测试发现增加到10会显著延长训练时间）

4.3 训练前检查

在启动训练运行前，必须完成以下准备工作：

1. WandB登录：

   bash复制wandb login
   

   避免训练脚本运行几分钟后因未认证而崩溃。

2. 监控工具安装：

   bash复制pip3 install nvitop
   nvitop
   

   实时监控GPU利用率和内存使用情况。

3. 脚本修改：根据上述超参数优化建议调整训练脚本。

4.4 启动基线实验

执行修改后的训练脚本：

bash复制chmod +x ./examples/grpo_trainer/run_qwen2_5-3b_gsm8k_grpo_lora.sh
./examples/grpo_trainer/run_qwen2_5-3b_gsm8k_grpo_lora.sh

5. 性能优化实战

5.1 从模型并行到数据并行

初始配置使用tensor_model_parallel_size=4，将模型权重分片到所有4个GPU。但对于3B参数的小模型（约6GB），这种过度分片会导致GPU花费大量时间等待通信。

优化方案：

• 将tensor_model_parallel_size从4改为1
• 改为数据并行，每个GPU运行独立的模型副本，仅在最后同步梯度

效果：

• 训练时间从9.5小时减少到6.5小时（减少33%）
• GPU利用率曲线变得更平滑，通信开销显著降低

5.2 VRAM利用率优化

尽管改为数据并行后性能提升，但VRAM使用率仍只有约78%，意味着每个A100有约20GB内存未被利用。

调整参数：rollout.gpu_memory_utilization

• 测试了0.7（仍利用不足）和0.9（导致OOM崩溃）
• 最终确定0.8为最佳值

效果：

• VRAM使用峰值达到>95%
• 训练时间进一步从6.5小时减少到6小时
• 总速度提升约38%（从9.5小时到6小时）

5.3 组响应数量实验

理论上，增加rollout.n（组响应数量）可以减少基线估计的方差，带来更稳定的训练更新。

测试：

• 从n=5增加到n=10
• 训练时间从6.5小时增加到11小时（+70%）
• 回报：基线估计更稳定，但成本效益比不佳

决策：保持n=5，因为3B模型在GSM8K上已经能很好收敛，额外的计算成本不划算。

6. 训练监控与问题排查

6.1 关键监控指标

1. 系统健康度：

   • VRAM使用率：应接近但不超出GPU内存容量
   • GPU利用率：应有明显的"锯齿"模式（生成阶段较低，训练阶段100%）

2. 学习曲线：

   • 平均奖励：从~0.55稳步上升到~0.90
   • KL散度：应单调上升但有界（健康值约0.0027）
   • 梯度范数：应平稳无剧烈波动（健康值约0.005）

3. 响应长度：

   • 从~290 tokens减少到~220 tokens
   • 模型学会了用更简洁的方式表达正确解答

6.2 常见问题与解决方案

问题1：磁盘空间不足

现象：训练在Step 80/105时因磁盘满而崩溃。

原因：检查点文件过大，填满容器根卷。

解决方案：

1. 删除损坏的检查点：

   bash复制rm -rf /workspace/verl/checkpoints/verl_grpo_example_gsm8k/qwen2.5_3b_grpo_lora/global_step_80
   

2. 清理旧检查点释放空间：

   bash复制rm -rf /workspace/verl/checkpoints/verl_grpo_example_gsm8k/qwen2.5_3b_grpo_lora/global_step_20
   rm -rf /workspace/verl/checkpoints/verl_grpo_example_gsm8k/qwen2.5_3b_grpo_lora/global_step_40
   rm -rf /workspace/verl/checkpoints/verl_grpo_example_gsm8k/qwen2.5_3b_grpo_lora/global_step_60
   

3. 启用自动恢复模式：

   bash复制trainer.resume_mode="auto"
   

4. 重新启动训练。

预防措施：

• 设置trainer.save_total_limit=3只保留最近的3个检查点
• 增加trainer.save_freq从20到50，减少保存频率

问题2：WandB进程终止错误

现象：训练结束时出现"Signal Killed"或"Process Terminated"错误。

原因：WandB后台进程在关闭前被终止。

解决方案：无需处理，只要最终检查点存在即可。

7. 结果验证与分析

7.1 内部验证

在训练过程中，模型在保留测试集上的表现：

• 初始准确率：~59%
• 最终准确率：~85%
• 关键发现：模型在前3个epoch就达到了~83%准确率，后续12个epoch仅提升2%

建议：对于类似配置的小模型，可将trainer.total_epochs从15减少到5，节省约60%计算资源。

7.2 外部基准测试

使用LM Evaluation Harness在标准GSM8K和GSM8K-CoT任务上评估：

分析：

1. 最大提升出现在严格匹配指标，这与我们的二元奖励函数设计一致
2. 模型变得更加精确于最终答案格式
3. 在推理能力上的提升相对有限，说明主要优化了形式而非实质推理能力

8. 经验总结与未来方向

8.1 关键经验

1. GRPO的实际优势：

   • 确实减少约50%的VRAM使用
   • 训练循环更简单稳定
   • 特别适合资源受限但需要RL调优的场景

2. 3B模型的特性：

   • 小模型收敛速度快，不需要完整15个epoch
   • 对计算资源需求相对较低，适合快速实验迭代

3. Verl框架使用心得：

   • 工业级稳定性，但学习曲线陡峭
   • 分布式训练配置需要精细调整
   • 监控和恢复功能完善，适合生产环境

8.2 改进方向

1. 奖励函数工程：

   • 当前二元奖励导致模型追求简洁而非深入推理
   • 可尝试过程奖励（P-RMs），激励推理步骤而不仅是最终答案

2. 数据多样性增强：

   • 引入更多样化的数据集
   • 采用模板随机化，防止过拟合特定提示格式

3. 超参数优化：

   • 动态学习率调度
   • 早停机制（如验证集性能平台期停止）
   • LoRA秩和alpha参数的进一步调优

4. 架构扩展：

   • 尝试更大模型（如7B）与GRPO的组合
   • 探索混合并行策略（如管道并行+数据并行）

通过本项目的实践，我们建立了一个稳定、高效的GRPO训练管道，为后续更复杂的RLHF实验奠定了基础。最重要的是，我们验证了即使在小规模模型上，通过适当的工程优化和算法选择，也能实现显著的性能提升。