基于 LLamaFactory 和 EasyR1 打造一站式无代码大模型强化学习和部署平台 LLM Model Hub

1. 前言

大语言模型（Large Language Models, LLMs）在近几年经历了前所未有的发展。从 2020 年的 GPT-3 到 2024 年的 o1 和 Claude 3.5，再到 2025 年的 Qwen3 和 DeepSeek R1 开源模型，LLM 的规模和能力都在不断扩展。然而，随着模型参数量的增加和应用场景的复杂化，如何高效地进行模型微调和部署，成为了开发者和研究人员面临的关键挑战。之前我们已经推出过《基于 Amazon SageMaker 和 LLaMA-Factory 打造一站式无代码模型微调部署平台 Model Hub》，文中主要介绍了如何使用这一平台利用 Amazon Sagemaker AI 的动态算力资源进行高效的监督微调（Supervised Fine-tuning, SFT）和模型部署。训练一个高质量的 LLM 通常包括预训练（Pre-training）、和后训练（Post-training），而后训练中，又包含监督微调（Supervised Fine-tuning, SFT）和对齐（Alignment）等阶段。随着 DeepSeek-R1 的出现，强化学习（Reinforcement Learning, RL）在后训练阶段越来越被重视，它能更好地激发模型的推理能力，提升在代码，数学，逻辑方面的能力。然而，传统的强化学习方法在应用到 LLM 训练时面临着诸多挑战：

1. 计算资源消耗巨大：传统 RL 方法如 PPO（Proximal Policy Optimization）需要维护单独的价值网络，对于已经很大的 LLM 来说，这意味着几乎翻倍的内存需求。
2. 训练不稳定：大模型训练本身就容易出现梯度消失、爆炸等问题，而 RL 方法还可能引入额外的不稳定性。
3. 奖励稀疏问题：在复杂的推理任务中，有意义的反馈可能很稀疏，使得模型难以有效学习。
4. 长序列处理困难：当处理需要长链思考（Chain-of-Thought）的复杂推理任务时，传统 RL 方法效果往往不尽如人意。

在这一背景下，Group Relative Policy Optimization（GRPO，群组相对策略优化）应运而生，GRPO 最早由 DeepSeek 团队在其论文《DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models》中提出，旨在解决传统 RL 方法在 LLM 训练中的局限性。

GRPO 的核心创新在于它摒弃了传统 PPO 中需要单独价值网络的设计，转而采用群组相对优势估计的方式。对于每个输入问题，模型生成多个回答，然后通过奖励模型对这些回答进行评分，并使用群组平均分作为基线来计算每个回答的相对优势。这种方法不仅大幅降低了内存需求，还提高了训练效率和稳定性。

GRPO 的成功应用首先体现在 DeepSeekMath 模型上，它在数学推理任务上取得了突破性进展。随后，DeepSeek 团队将 GRPO 应用于其 DeepSeek-R1 模型的训练，使该模型在多项推理基准测试上达到了接近甚至超过闭源商业模型的水平。这一成功引起了学术界和工业界的广泛关注，GRPO 迅速成为 LLM 训练领域的热门研究方向。

2. GRPO 算法简介

GRPO 算法通过巧妙的群组相对优势估计机制，成功解决了传统 PPO 算法在 LLM 训练中的内存瓶颈问题，同时保持了训练效果和稳定性。它不仅是一种算法创新，更代表了一种强化学习应用于大型语言模型的新思路，即如何在有限资源约束下实现高效的策略优化。GRPO 的基本思路可以概括为：对于每个输入问题，让模型生成多个可能的回答，然后使用奖励模型对这些回答进行评分，并以群组内回答的平均分作为基线，计算每个回答相对于该基线的优势值。这种方法不仅简化了算法结构，还保持了训练的稳定性和效果。

2.1 GRPO 工作流程

1. 为每个问题生成多个回答

对于训练集中的每个问题或提示 s_j，使用当前策略模型 Πθ_old 生成多个回答：

在 DeepSeekMath 的实践中，每个问题通常生成 64 个样本，最大长度为 1024 个 tokens。

生成过程通常使用温度采样（temperature sampling），以确保回答的多样性。

2. 使用奖励模型评分

每个生成的回答 a_jk 都会通过奖励模型获得一个分数 。奖励模型可以是：

• 规则型奖励：例如，对于数学问题，可以根据最终答案的正确性给出二元奖励（正确为 1，错误为 0）。
• 学习型奖励：使用单独训练的模型或者使用其他的 LLM 作为裁判来评估回答质量，这在没有明确标准答案的任务中有用。
• 混合奖励：结合多种信号，如答案正确性、解题过程的清晰度、格式规范性等。

在 DeepSeek-R1 的训练中，奖励模型使用的是规则型奖励，不仅包括答案的准确性，也考虑了回答的格式质量。

3. 计算群组平均奖励

对于每个问题 s_j，计算其所有回答的平均奖励：

这个平均值将作为估计优势值的基线。

4. 相对优势计算

计算每个回答的相对优势值：

并进行标准化以减少方差：

这一步的核心思想是：对于同一个问题，那些获得高于平均奖励的回答应该被强化，而那些低于平均值的回答则应该被抑制。

5. 策略更新

基于计算出的优势值和目标函数，使用梯度下降法更新策略网络的参数：

在实践中，通常使用小批量梯度下降，并控制每次更新的幅度确保训练稳定。DeepSeek-R1 采用的学习率为 1e-6。

2.2 GRPO 实现细节

除了基本算法外，GRPO 的成功实现还依赖于一些关键技巧：

1. 批量大小与更新频率

DeepSeek-R1 使用 1024 的批量大小，并在每个探索阶段仅进行一次更新，这有助于保持训练稳定性。

2. KL 散度系数调节

KL 散度系数 β 的选择至关重要：太小会导致模型偏离过快，丧失通用能力；太大则会使模型更新过于保守，学习效率低下。

3. 回答长度控制

在生成多个回答时，需要控制最大生成长度，在 DeepSeek 的实践中通常设置为 1024 个 tokens，这既保证了足够的推理空间，又避免了过长序列带来的计算负担。

4. 奖励标准化

除了群组内标准化外，有时还会进行全局奖励标准化，即根据所有问题的奖励分布来标准化每个奖励，这有助于处理不同问题难度差异带来的奖励分布不均匀问题。

5. 参考策略选择

KL 散度正则化中的参考策略 Πθ_ref 通常选择初始的 SFT 模型，这有助于保持模型的通用能力，防止过度专注于特定任务而忽略基础能力。

3. EasyR1 框架介绍

EasyR1 是基于火山引擎 veRL 框架开发的专为大语言模型 / 视觉语言模型（LLM / VLM）设计的高性能强化学习训练框架，支持 GRPO 等多种强化学习算法。

3.1 EasyR1 核心特点

1. 高效性能：由于采用了 HybridEngine 设计和 vLLM 最新版本的 SPMD（单程序多数据）模式，EasyR1 在训练效率上表现出色。
2. 多模态支持：不同于仅支持文本模型的框架，EasyR1 专门支持视觉语言模型，能够处理包含图像和文本的复杂数据。
3. 可扩展性：支持多节点分布式训练环境，能够训练超过 70B 参数的大型语言模型。
4. 算法丰富：内置多种先进的强化学习算法，包括 GRPO、Reinforce++、ReMax 和 RLOO 等。
5. 模型兼容性：支持多种主流大型语言模型和视觉语言模型，如 Llama3、Qwen2、5、Qwen3 系列语言模型，以及 Qwen2-VL、Qwen2.5-VL 视觉语言模型、DeepSeek-R1 蒸馏模型等。

3.2 EasyR1 算法流程

以 GRPO 算法为例，EasyR1 在进行训练时，分为以下几个主要步骤：

1. 轨迹采样（左上）：从数据中选取批量大小（batch-size）个问题，由当前的策略模型对每个问题生成多个答案，作为当前策略模型的推理轨迹。
2. 计算策略概率（右上）：将所有的推理轨迹输入到策略模型中，计算当前策略模型选择这些轨迹的概率分布。
3. 计算参考概率（右下）：再将上述的所有推理轨迹输入到参考模型中，计算参考模型选择这些轨迹的概率分布，用于计算 KL 散度。如果 KL 散度被关闭，则该步跳过。
4. 计算奖励和优势函数：基于预先设置的奖励模型或者规则验证器，对所有的模型回答计算奖励分数，再按照群组归一化方式得到优势函数。
5. 更新策略模型（左下）：根据问答对的策略概率和优势函数，分小批量（mini-batch）更新当前策略模型的参数。
6. 将更新后的策略模型作为新的模型，对新的一批数据进行下一轮的轨迹采样（左上），不断循环这一过程。

更详细的内容可阅读 EasyR1 的项目仓库。

4. EasyR1 与 Amazon SageMaker AI Training Job 集成

4.1 Amazon SageMaker AI Training Job 的特点和优势

全托管式训练服务：Amazon SageMaker AI Training Job 提供完全托管的模型训练服务，负责基础设施设置、资源分配和故障恢复，让开发者专注于模型开发本身，而无需管理基础设施。并且提供分布式训练能力。

资源优化和成本效益：随启随用，按需付费，只按训练任务时间收费，训练结束，停止计费。提供 Spot 训练实例选项，使团队能够利用闲时资源折扣，进行可中断的实验任务。

灵活的训练选项：支持使用内置算法，也可自带代码脚本或容器。

4.2 自定义训练镜像（Bring Your Own Container ）

由于 SageMaker Traning Job 是随启随用的方式，不会长期占用服务器，所以我们每次启动一个训练任务的时候，SageMaker 控制平面会去申请服务器，然后安装训练代码并运行，为了提高训练准备的效率，我们需要把 EasyR1 以及训练代码提前构建成为一个 training 镜像，并且推送到 AWS ECR（Elastic Container Registry）中，然后在SageMaker训练任务创建时指定这个镜像地址，SageMaker 启动任务时会下载这个镜像到服务器中，通过这种方式我们可以使用任何算法或库，极大的提高的 SageMaker 的灵活性，同时又保留了 SageMaker 的所有基础设施优势。这种方式简称 BYOC（Bring Your Own Container ），使用BYOC功能只需几个关键步骤：创建 Dockerfile、构建容器、将其推送至 Amazon ECR，然后在创建 SageMaker 训练任务时指定镜像地址，而训练任务需要的参数，则可以通过环境变量的形式，传入到镜像中。

构建镜像的 Dockerfile 示例：

# 安装sagemaker依赖
RUN pip3 install sagemaker-training boto3
# 复制训练代码到镜像中
COPY train.py /opt/ml/code/
# 复制EasyR1代码到镜像中
COPY EasyR1/ /opt/ml/code/
# 设置工作目录
WORKDIR /opt/ml/code/
# 安装EasyR1项目
RUN python -m pip install --upgrade pip && \
    pip install -e . 
WORKDIR /
# 定义 train.py 作为镜像启动的自运行代码
ENV SAGEMAKER_PROGRAM train.py

示例代码如下：

self.estimator = Estimator(image_uri=os.environ['easyr1_training_image'],#easyr1镜像
                                    role=role,
                                    use_spot_instances=use_spot,
                                    sagemaker_session=sagemaker_session,
                                    base_job_name=base_job_name,
                                    environment=environment,#环境变量
                                    instance_count=instance_num,#服务器数量
                                    instance_type=instance_type,#服务器类型
                                    max_wait= 3600*max_spot_wait if use_spot else None,
                                    max_run=3600*max_job_run_hour
                                    )

4.3 Ray 框架适配

Ray 是一个专为大规模 AI 模型训练和推理的分布式计算框架，Ray 一般是运行在具有相对固定的服务器资源集群内，由一台服务器作为头节点 +N 台服务器作为工作节点组成计算集群。EasyR1 底层使用 Ray 作为分布式计算框架，以支持多节点的分布式训练。如果直接使用 EasyR1 在集群中做分布式训练，只需要:

1. 在一台服务器中启动 Ray 作为头节点：

ray start --head --port=6379 --dashboard-host=0.0.0.0

2. 在其他服务器中，运行以下命令，作为工作节点连接到头节点：

ray start --address=<head_node_ip>:6379

3. 然后在头节点中提交训练脚本：

bash train.sh

然而这种启动方式在 SageMaker AI Training Job 中存在几个主要问题：

1. SageMaker AI Training Job 是按需启动计算节点，并不是事先配置安装好的固定的集群，且不能直接登陆到服务器去运行命令（通过 remote debug 模式可以，但是需手动操作，且不够优雅）。
2. SageMaker 多节点下的启动顺序是并行启动，并不是依次启动，所以各个节点的启动脚本的执行顺序也不固定，需要考虑各个节点之间的状态依赖问题，例如 ray 头节点启动完成之后，才能在工作节点中执行 ray start 连接到头节点，并且头节点需要等待所有的工作节点都连接成功之后，才能执行训练代码开始训练。
3. SageMaker 的计算节点启动后会自动执行用户指定的训练代码（例如：上面 Dockerfile 中py），一旦代码执行完成或者异常退出，计算节点的资源将被释放。但是在 Ray 框架下，工作节点中并没有显式的代码执行过程，而是由头节点把任务分发过去，在后台执行。

为了解决上面的问题，我们需要在 SageMaker AI 的任务启动代码 train.py 中做出改造：

1. 在启动代码中，加入 ray start 命令执行，且通过 SageMaker 自带的环境变量判断节点编号，把第一个节点作为头节点，执行”ray start –head –port=6379 –dashboard-host=0.0.0.0″ ，其余节点作为工作节点，执行”ray start –address=${SM_MASTER_ADDR}:6379″。并且考虑到 SageMaker 多节点下的启动顺序是并行启动，工作节点在执行“ray start”连接到头节点时，这时头节点可能还没有启动成功，所以，我们还需要在工作节点加入 wait and retry 机制，去尝试连接头节点，直到连接成功。代码示例：

   def connect_to_ray_with_retry(head_ip, max_retries=30, wait_time=10):    
       for attempt in range(max_retries):
           try:
               logger.info(f"Attempt {attempt+1} to connect to Ray head at {head_ip}:6379")
               os.system(f"ray start --address={head_ip}:6379")
               ray.init(address="auto")  
               logger.info("Successfully connected to Ray head node!")
               return True
           except Exception as e:
               logger.info(f"Connection failed: {e}")
               logger.info(f"Waiting {wait_time} seconds before retrying...")
               time.sleep(wait_time)
       logger.info("Maximum retries reached. Could not connect to Ray head node.")
       return False
   

2. 头节点需要等待工作节点连接成功之后，才开始启动训练代码，因此还需在头节点执行分支中加入等待机制, 直到所有节点都连接成功，示例代码如下，其中 expected_nodes 可以从 SageMaker 自带的环境变量中获取：

   def wait_for_complete_cluster(expected_nodes, timeout_seconds=300):
       """
       Wait until all expected nodes have joined the Ray cluster.
       
       Args:
           expected_nodes: Total number of nodes (including head node)
           timeout_seconds: Maximum waiting time
       """
       start_time = time.time()
       
       while time.time() - start_time < timeout_seconds:
           logger.info('---waite for other nodes-----')
           # Get current cluster nodes
           current_nodes = len(ray.nodes())
           logger.info(f"Connected nodes: {current_nodes}/{expected_nodes}")
           
           if current_nodes >= expected_nodes:
               logger.info("✓ Complete cluster formed!")
               return True
               
           time.sleep(10)  # Check every 10 seconds
           
       logger.info(f"✗ Timeout after {timeout_seconds}s. Only {len(ray.nodes())}/{expected_nodes} nodes connected.")
       return False
   

头节点完整的流程示意：

3. 在整个运行过程中，工作节点的调度完全是由头节点分配，且在后台执行，因此工作节点的执行程序（train.py）中需要获取训练状态，并判断是否完成，如果未完成则需要保持等待，防止工作节点的执行程序退出，导致节点资源被释放。因此我们新创建一个对象，用于保存任务状态，并转换为 Ray 远程 Actor，使得在分布式训练环境中跨节点共享训练状态。

   @ray.remote
   class TrainingStatus:
       def __init__(self):
           self.status = {"training_complete": False}
           
       def set_status(self, status):
           self.status = status
           return True
           
       def get_status(self):
           return self.status
   

而头节点在执行完训练代码之后，需要更新状态：

# Run training as before
train_command = f"python3 -m verl.trainer.main {train_args}"
ret = run_command(train_command)
if not ret:
    logger.info(f"Train failed")
    status_actor.set_status.remote({"training_complete": True})
    time.sleep(5)
    ray.shutdown()
    stop_and_exit(1)
    
logger.info("Train completed!")
# 更新状态
status_actor.set_status.remote({"training_complete": True})

在工作节点中，获取训练状态并等待，示例代码如下：

# 工作节点等待循环
while True:
    # 检查训练是否完成
    try:
        retry_count = 0
        status_actor = None
        status_actor = ray.get_actor("training_status", namespace="distributed_training")
        if status_actor:
            status = ray.get(status_actor.get_status.remote())
            if status.get("training_complete", False):
                logger.info("Training complete signal received. Worker exiting.")
                break
    except Exception as e:
        logger.info(f"Could not get training status: {str(e)}")
    logger.info("Worker node still active.")
    time.sleep(30)

完整的工作节点流程示意：

4.4 checkpoint 检查点实时保存

大模型在训练过程中，可能会出现各种非预期情况，例如碰到过拟合情况，最佳效果的模型并不是最后训练出来的模型，而是之前某个步骤的模型。如果是欠拟合情况，说明模型训练还不够，我们可以继续基于最后一步，增加新的数据或训练轮数。有时候甚至是一些意外，例如机器故障，程序异常等，因此 checkpoint 检查点理解为模型训练过程中的某个阶段的镜像，即使训练中断，我们可以基于这些 checkpoint 恢复训练，或者回退到之前的某个阶段。

在分布式环境中，各个节点分别保存各自的 checkpoint 分片，我们只需在各节点中启动一个进程，各自把本机中的 checkpoint 同步回一个集中的 S3 bucket 中即可，同步完成之后，还需要创建一个 sync_completed_{host_rank}.flag 文件用于标记本节点的 checkpoint 已经同步完毕。

流程示意如下：

4.5 中断后自动恢复训练

Spot 实例是一种竞价计算资源，使用亚马逊云中的闲置计算资源，与按需实例相比，可节省高达 90% 的训练成本。SageMaker Training Job 可以使用 Spot 实例进行训练，达到更好的经济性，但是 Spot 实例可能会在按需资源用量较大时被回收，从而造成训练中断，当 Spot 资源变的可用时，又会被 SageMaker 重新分配回原先的任务中，重新分配回之后，计算实例会重新启动，并运行训练脚本，由于我们已经把 checkpoint 上传到 S3，这时我们需要在脚本中实现去 S3 查找最近的且完整的 checkpoint，并自动从 checkpoint 恢复训练。

5. LLM Model Hub 进行 GRPO 训练的使用介绍

LLM Model Hub 是亚马逊云科技在 Github 上的一个开源项目，基于Amazon SageMaker 的计算资源，集成 LlamaFactory/EasyR1/vLLM/SGLang 框架，提供了一站式的模型微调、部署、调试的零代码可视化平台，可以帮助用户快速微调各类开源模型，高效同时地进行大量的实验和验证，提升模型微调的工程效率。这个方案不仅可以在亚马逊云全球区部署，也专门针对中国区做了镜像源适配，可以顺畅的在中国区部署，使用中国区 SageMaker AI 的计算资源。本次主要新增了 EasyR1 框架集成，支持 GRPO 训练。系统架构和安装方法等在本篇博客中不再赘述，具体可以参考上一篇博客《基于 Amazon SageMaker 和 LLaMA-Factory 打造一站式无代码模型微调部署平台 Model Hub》。

训练 GRPO 任务的大致步骤如下：

1. 创建一个训练任务，类型选择 “GRPO”和LLM模型作为基座模型。
   
2. 选择一个开源数据集（math12k）以及对应的提示词格式模板。我们也可以提前准备好训练和测试数据集存放到 S3 中，填入 S3 地址，以及定制我们的提示词格式模板。
   
3. 设置训练步骤，以及对应的奖励函数，如果是用上面的开源数据集，我们可以直接用预置的奖励函数。
   

   也可以使用参考代码中的函数签名自定义奖励函数：

4. 选择机型和数量，创建训练任务。LLM Model Hub 支持开启 Spot 实例训练，并且自动管理任务中断和恢复，会从最近的可用的 checkpoint 恢复继续训练，从而大幅度地降低训练成本。
   
5. 在任务详情下方看到任务日志以及结果保存地址，中间的 checkpoint 和最终模型文件都会同步回 S3 中：
   
6. 训练完成之后，我们可以回到任务列表，选中任务，点击部署，可以把这个模型直接部署到 SageMaker 推理端点中，并且在 LLM Model Hub Playground 访问，或者使用 SDK 调用。
   

6. 案例实战一：使用 SFT 和 GRPO 训练一个翻译检测模型

大模型进行翻译，常常会因为模型能力和输出稳定性问题导致一些翻译错误。这些问题产生也往往和模型的训练机制有关，比如语种夹杂的问题，这种情况就是和训练数据中大量出现的语言间借词有关，并不影响理解，但某些业务不接受这种情况。又比如格式变化问题，是因为大模型一般有较强的使用 markdown bullets 格式进行输出的倾向；此外，对于敏感内容的拒绝翻译问题，和大模型的安全性对齐机制有关。由于模型概率输出的特性，这些问题通用大模型无法完全避免。因此，通用大模型几乎不可能完全契合某些特定业务的要求，而通过微调可以让模型以业务诉求作为目标进行优化，在特定领域达到一个性能和质量的最优解。

6.1 数据构建

6.1.1 SFT 数据构建

我们首先用 LLM Model Hub 使用 Qwen3-8B-Instruct 进行了一轮 Supervised Finetune (SFT) 全参数微调训练， 在第一轮中，构建了如下的数据集，我们期望模型对翻译内容按 6 个条件进行打分，分值 0-5 分表示质量好坏，5 表示最高。规定 [0,1,2] 分需要进行人工校对，[3,4,5] 不需要引入人工校对。

{
    "messages":[
        {
            "role":"system",
            "content":"You are an expert linguist specializing in translation quality assessment. Your task is to evaluate the translation produced by translation model. Assess the translation based on the following criteria: 
            1. Sensitive content should not be refused to translate 
            2. No non-target language word appears 
            3. No irrelevant or useless repetitive words. 
            4. No Spelling, abnormal symbols and grammar errors detected 
            5. Quantity, Quantifiers and Units are translated accurately 
            6. Format maintained between source and translation. No added numbering/bullet 
            The target language is zh-cn, please evaluate translation quality, and give your rating(0.0-5.0). "
        },
        {
            "role":"user",
            "content":"Here is the source text in <src> tag and also its translation from an translator in <translation> tag. <src> Reformed Soteriology </src> <translation> 改革宗 Soteriology </translation>"
        },
        {
            "role":"assistant",
            "content":"<think>The translation contains untranslated English word 'Soteriology' which should be fully translated into Chinese. '改革宗' alone does not fully communicate the doctrine of salvation term.</think>, my ratings is [5, 2, 5, 5, 5, 5, 5]"
        }
    ]
}

通过 SFT 已经可以实现比较好的输出效果，无论是格式还是思考过程，但唯一有不足的地方是 SFT 在计算 loss 时，计算范围为整体 assistant 的输出 token，其中 answer 中，rating 部分就是一个 list，需要和样本比对的部分一般仅仅为一个数字，其在 Loss 中占比太小，无法让模型优化聚焦到这里。

下面是第一轮 SFT 训练后评估得到的准召指标：

其中类别 1 的准召都明显偏低，查验 bad case，发现了下面这个典型的例子。其分析部分相差无几，但分数一个是 2，一个是 3，由于业务中我们规定 [0,1,2] 分需要进行人工干预，[3,4,5] 是轻微不需要引入人工。这造成了最终业务上出现了两种不同的结论，实际可用性变差。

{
    "src": "MCLVN", 
    "translation": "无法翻译\"MCLVN\"，这似乎是一个不明确的缩写或产品代码。需要更多信息才能进行正确翻译。", 
    "label": "<think>The translation avoids translating the term by claiming it's unclear, violating the first criterion that requires an attempt at translation. The explanation is reasonable but doesn't fulfill the requirement to attempt translation.</think>, so my ratings is [2, 5, 5, 5, 5, 5, 5]", 
    "predition": "<think>The translator has declined to translate the source text by explaining that it's an unclear abbreviation. While the explanation is logical, the task requires attempting a translation rather than refusing it.</think>, my ratings is [3, 5, 5, 5, 5, 5, 5]"
}

6.1.2 GRPO 数据集构建

我们使用 EasyR1 默认的数据格式，定义两个字段：problem, answer 分别代表输入和期望的最终答复，而原先 SFT 数据中<think>思考部分，则不在数据集中，这部分将由模型自己生成。例如：

Problem

Here is the source text in <src> tag and also its translation from an translator in <translation> tag.
<src>
MCLVN
</src>
<translation>
无法翻译\"MCLVN\"，这似乎是一个不明确的缩写或产品代码。需要更多信息才能进行正确翻译。
</translation>

Answer

[2, 5, 5, 5, 5, 5, 5]

6.2 奖励函数

接下来，我们使用 GRPO 来继续对前一阶段 SFT 之后的模型进行训练，用 Rule-Based Reward 来针对这个问题进行建模，当符合业务标准时，给出奖励 1，不符合业务标准，给奖励 0。下面的 reward_function, 从模型输出中抽取的得分数组，直接根据分数在业务上的正负来为模型训练提供 reward， 我们在任务创建页面中，选择 customize，填入自定义的奖励函数。

6.3 训练

SFT 训练阶段，采用了 Qwen3-8B-Instruct 作为基础模型，训练 SFT 的时候，选择 p4d.24xlarge（单台 8*A100 40GB）卡即可。由于 GRPO 训练相对复杂，需要同时支持 Policy Model 和 Reference Model， 需要 2 台 p4d.24xlarge 机器的显存支持。通过 LLM Model hub，如下图所示，仅需要在界面上选择 2 台实例即可进行多机分布式训练。

6.4 结果分析

下面两图为 GRPO 训练时准确率的 reward 曲线，左图训练集上经过 100 step 训练，从 0.8 左右提高到了 0.95 以上； 右图测试集也呈单调上升，从 0.8 左右提升到了 0.89 左右。

重新统计各个错误的指标如下：

针对前面具体提到的 Bad Case， 重新进行测试：

输入：

Here is the source text in <src> tag and also its translation from an translator in <translation> tag.
<src>
MCLVN
</src>
<translation>
无法翻译\"MCLVN\"，这似乎是一个不明确的缩写或产品代码。需要更多信息才能进行正确翻译。
</translation>

模型回复如下：

<think>The translator has declined to translate the source text by explaining it lacks clarity, which fails to meet the requirement to attempt a translation. The response provides analysis but doesn't attempt to translate the given text.</think>, my ratings is [1, 5, 5, 5, 5, 5, 5]

可以发现，其得分已经从 3 下降到 1，归入了需要人工干预的这一档，符合了对模型的预期。根据以上的统计指标和具体 case 分析得到结论，如果想进一步对使用 SFT 微调的大模型提高最终实际能力，通过 GRPO 的 Rule-based Reward 是一种有效方案。

7. 案例实战二：使用 GRPO 训练多模态 GUI Agent

在这一章节将展示用强化学习 GRPO 训练 GUI Agent。”GUI Agent”是一种用于图形用户界面（GUI）的自动化操作助手，可以理解用户的输入和指令,并作出相应的响应，实现人机（例如：手机、电脑等）之间的交互。其本质上是一个多模态的大语言模型，接受的输入是用户的自然语言命令以及屏幕截屏，输出需要执行的动作。在 GUI Agent 这个方向上，一个很明显的技术趋势是：提示词工程 –> 有监督训练（少量 DPO）–> 强化学习。在这一章节，本文将展示如何在 Model Hub 平台上使用 GRPO 训练 GUI Agent（这里只包含一张图像，不包含历史记录以及执行轨迹）。

7.1 数据构建

使用强化学习训练 GUI Agent，数据需要包含三个字段：image, problem, answer，分别表示设备当前屏幕截图、用户指令、正确执行步骤。

以下是一个数据示例：

Image

Problem

How to move to 'Sync Source'

Answer

{'action': ['UP', 'UP', 'UP']}

以上是一个完整的数据示例，想要训练时看到明显的效果，使用 GRPO 算法需要至少 500 条类似的数据，这里的困难点在于两点：1. 想要改变设备 UI 比较困难，很难对单一设备收集足够多样的屏幕截图；2. Answer 的构造，人工构造正确的操作序列成本很高。本文用数据合成的方法解决这些问题，下面将结合理解展示如何合成图像数据以及对应的 answer，由于涉及的代码较多，将注重方法而不展示代码。

第一步，对于一张从设备截取的图像，我们需要找到并分割其中的基本元素，这里的基本元素是指会根据用户操作产生变动的那些按钮，文本框等。如下左图, 展示的是 FireTV 的 Setting 页面的截图，在这一个页面，基本元素就是图中的方形 button，基于 opencv 切割并打乱重组这些 button，就得到一张如右图的全新图像。

第二步，由于是用脚本打乱并重组图像，所以生成图像的同时也能得到每个 button 的具体位置，基于这些位置信息，就能直接构造操作序列。例如，Network 的位置信息是第二行第一列，Notifications 的位置是第三行第三列。就可以构造一个 problem 以及 answer：”How to move from Network to Notifications?”,{‘action’: [‘DOWN’, ‘DOWN’, ‘RIGHT’, ‘RIGHT’]}”。

第三步：基于以上方法就可以用一张基础图像创建大量数据。另外，也可以替换图像中的不相关 button 以增加数据多样性，比如将上面的 Youtube 替换为其他字符，或者随机增加噪点等。

最后，将创建的数据按照要求打包为 parquet 文件。

7.2 奖励函数

本节使用 GRPO 方法，使用基于规则的强化学习，其中奖励函数包含格式奖励和准确度奖励两部分，占最终奖励的权重分别为 0.5。

1. 格式奖励：检查模型输出是否符合基本格式：<think>…</think> <answer>{‘action’: […]}</answer>，符合则奖励为 1， 否则奖励为 0，代码如下：

   def format_reward_simple(predict: str) -> float:
       # 检查基本格式：<think>...</think> <answer>...</answer>
       pattern = r"<think>.*?</think>\s*<answer>.*?</answer>"
       if not re.fullmatch(pattern, predict, re.DOTALL):
           return 0.0
       
       # 提取<answer>标签内容
       start_tag = "<answer>"
       end_tag = "</answer>"
       start_idx = predict.find(start_tag) + len(start_tag)
       end_idx = predict.find(end_tag)
       action_str = predict[start_idx:end_idx]
       
       # 转换单引号为双引号并解析JSON
       action_str = action_str.replace("'", '"')
       action_data = json.loads(action_str)
       
       # 检查action字段是否存在
       if isinstance(action_data, list) and len(action_data) > 0 and 'action' in action_data[0]:
           return 1.0
       
       return 0.0
   

2. 准确度奖励：有两种准确度奖励，分别对应不同的训练阶段。在阶段一：准确度奖励的核心逻辑是：分别计算预测动作和正确动作导致的最终位置，然后计算两个位置之间的曼哈顿距离（横向+纵向距离和），最后根据距离给予奖励分数。评分机制：如果距离为 0（完全匹配）：得分为 0（满分）如果距离小于等于阈值（部分正确）：得分按比例线性衰减，如果距离大于阈值：得分为 0（不合格）。在阶段二：采用严格的匹配奖励，完全和答案匹配则准确度奖励为 1，否则为 0。

   def simplified_accuracy_reward(predict, ground_truth):
       # 从预测和真实答案中提取动作列表
       predicted_actions = extract_action_list(predict)
       correct_actions = extract_action_list(ground_truth)
       
       # 如果没有预测动作，返回0分
       if not predicted_actions:
           return 0.0
       
       # 计算动作序列导致的位置差距
       distance = calculate_distance(predicted_actions, correct_actions)
       
       # 设置最大容忍距离阈值
       max_distance_threshold = 5
       
       # 根据距离计算得分
       if distance == 0:  # 完全匹配
           return 1.0
       elif distance <= max_distance_threshold:  # 部分匹配，线性衰减
           return 1.0 - (distance / (max_distance_threshold + 1))
       else:  # 超出阈值，不得分
           return 0.0
           
   def calculate_distance(actions, correct_actions):
       # 辅助函数：计算动作序列的最终位置
       def get_final_position(action_list):
           pos = [0, 0]
           for act in action_list:
               act = act.lower() if isinstance(act, str) else act
               if act == "up": pos[1] -= 1
               elif act == "down": pos[1] += 1
               elif act == "left": pos[0] -= 1
               elif act == "right": pos[0] += 1
           return pos
       
       # 计算两个位置的最终坐标
       pos1 = get_final_position(actions)
       pos2 = get_final_position(correct_actions)
       
       # 返回曼哈顿距离
       return abs(pos1[0] - pos2[0]) + abs(pos1[1] - pos2[1])
   

   def strict_accuracy_reward(predict: Any, ground_truth: Any) -> float:
       """严格匹配奖励：完全相同为1，否则为0"""
       try:
           correct_actions = extract_action_list(ground_truth)
           predicted_actions = extract_action_list(predict)
           
           # 严格匹配：只有完全相同才返回1，否则返回0
           if predicted_actions == correct_actions:
               return 1.0
           else:
               return 0.0
       except Exception as e:
           return 0.0
   

7.3 训练

训练使用 Qwen2-5-VL-7B-Instruct 作为基础模型，在一台 g6e.48xlarge 实例上运行。数据集包含了 1600 条数据。训练分为两个阶段：

• 在第一阶段，使用线性平滑的准确度奖励（0-1 之间的任意值），格式奖励权重和准确度奖励权重分别为 0.5，这一阶段的目的是为了让模型能够稳定的学习到动作模式。
• 第二阶段，采用严格的 0 或者 1 的准确度奖励，格式奖励权重和准确度奖励权重分别为 0.1 和 0.9，目的是为了提高模型在真实使用场景下的执行准确度。

提示词设置如下：

You are a TV navigation assistant. You need to navigate to the target button from the current button. First think about the reasoning process in the mind and then provide the user with the answer. Select the appropriate sequence of actions from the allowed list (UP, DOWN, LEFT, RIGHT only). Follow these simple thinking steps: 1. Identify the current button and target button positions 2. Determine the shortest path to navigate from current to target button Output format: <think>Your reasoning (150-250 characters)</think> <answer>[{‘action’: [‘UP’, ‘RIGHT’, …]}]</answer> IMPORTANT RULES: – Use ONLY the allowed actions: UP, DOWN, LEFT, RIGHT – The ‘action’ field must appear exactly once – Keep your output valid and simple. Below is the user request.\n{{ content | trim }}

可以根据训练效果和需要设置最大 step 数。训练参数设置如下：

7.4 结果分析

7.4.1 阶段一

每个 step 大约需要 25 分钟，训练结果如下，经过 12 个 step, 训练集奖励从 0.82 提升到 0.927 ，验证集奖励从 0.86 提升到 0.945，提升明显。

7.4.2 阶段二

在第一阶段的训练中，使用的奖励函数为非线性的奖励。这么做是为了尽量平滑奖励，否则严格奖励将导致奖励稀疏问题，模型无法在训练中稳定的学习到正确行动模式。但这样的设置也会导致训练后期模型准确度提升上限较低。所以我们需要进行第二阶段的训练，将奖励函数改成严格的 0/1 奖励，并且大幅度降低格式奖励的权重。第二阶段模型是基于阶段一中训练的 step 20 的 checkpoint 的模型权重继续训练（对应下图中的红色的 base-train-equal-weight）。

二阶段我们尝试了 2 个不同的实验参数（分别对应 rollout 5 和 rollout 10）：

实验一：worker 设置 rollout 5， 准确度奖励修改为严格的 0/1 奖励，即完全和答案匹配则准确度奖励为 1，否则为 0。另外，将格式奖励权重调为 0.1， 准确度奖励为 0.9。奖励得分如图示：

从训练结果看（Rollout-5），20 个 Step 的 checkpoint 在更换奖励函数规则后，其初始准确度奖励从 0.96 降到 0.82。后续训练中，可以看到在前 10 个 step 稳定上升到 0.93，后续持续下降到 0.83，相比初始状态几乎没有提升。

实验二：在这个实验中，为了克服训练过程中的不稳定性，其他参数不变，将 rollout number 增加到 10。每个 step 的训练时长从 40 分钟（Rollout-5）涨到了 77 分钟。训练结果如下（Rollout-10）：

准确度奖励从 0.82 提高到 0.9，训练过程逐渐趋于稳定。

推理示例:

输入：

How to move to 'Hearing Aids'?

图片：

模型响应：

<think>Move down to 'Reset to Factory Defaults', then down again to 'HDMI-CEC Device Control', and finally down once more to reach 'Hearing Aids'.</think>
<answer>[{'action': ['DOWN', 'DOWN', 'DOWN']}]</answer>

通过这两个阶段的 GRPO 训练，我们最终得到了一个比较符合实际业务目标的模型，对比之前我们用 SFT 方法微调，GRPO 训练的数据利用率远高于 SFT，强化学习能用少于 10% 数据就达到 SFT 的效果。另外通过这个二阶段的训练，我们也总结出一些实践经验：

• 奖励函数不是一成不变的: 在训练初期，如果奖励函数过于严格，模型将无法从稀疏的奖励中获取优化方向，收敛比较困难。所以我们设计了平滑的奖励函数，让模型加快收敛。但是平滑的奖励函数无法反映最终的业务评价效果，所以在二阶段训练时，奖励函数改成严格的 0/1 奖励，以将模型的优化方向和真实业务情况对齐。
• 增加 rollout 数量能够提升模型训练的稳定性和收敛，但是会影响平均每个 step 的时间，需要根据资源和效果做出平衡。

8. 总结

本文介绍了大语言模型强化学习训练 Group Relative Policy Optimization（GRPO）算法及其在 EasyR1 框架中的实现原理, 并详细介绍了如何将 EasyR1 与 底层的 SageMaker Training Job 计算资源集成。并且通过两个实际应用案例：翻译质量检测模型和多模态 GUI Agent 的训练，演示了使用 LLM Model Hub 进行 SFT 和 GRPO 训练的便捷性，并最终通过训练取得进一步的优化效果。

EasyR1 框架为大模型强化学习训练提供了便利，高效、稳定的解决方案，通过 LLM Model Hub 的深度集成，实现了无代码，可视化，分布式训练、按需计费，以及利用 Spot 竞价计费实现成本优化。并且通过实战案例证明，这一方案在特定领域微调和能力增强方面具有显著效果，特别适合需要精确控制模型输出质量的业务场景。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

附录

本项目代码仓库：https://github.com/aws-samples/llm_model_hub

参考资料：

• EasyR1: An Efficient, Scalable, Multi-Modality RL Training Framework
• HybridFlow: A Flexible and Efficient RLHF Framework
• DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models
• 基于 Amazon SageMaker 和 LLaMA-Factory 打造一站式无代码模型微调部署平台 Model Hub

本篇作者