8.0
热点
AI SCORE
技术实践2026-10-21 01:48
GPT-OSS多语言微调：如何选择SFT与GRPO
AWS ML Blog#模型微调#多语言#强化学习
Editor brief · 编辑速览
文章介绍在SageMaker HyperPod上微调GPT-OSS-20B的方法，并比较SFT与GRPO的适用条件。案例中SFT将推理语言准确率从22%提升至100%，GRPO则在仍有提升空间的任务上带来额外收益。
GPT-OSS-20B 是一个以英语思考的开放权重推理模型。要求它用法语、德语、西班牙语或意大利语进行推理时，它会表示接受指令，却依然用英语生成思维链。在一项包含 50 个样例的多语言推理测试中，基础模型仅有 22% 的情况使用了正确的目标语言进行推理。这 22% 几乎全部来自英语样例（英语 100%、法语 0%、德语 10%、西班牙语 0%、意大利语 0%）。
对于面向非英语用户部署推理模型的团队来说，这一差距不容忽视。用户用法语提问，自然希望模型用法语推理并作答，而不是在思考过程中切换到英语。弥合这一差距需要微调。这也引出了每个开始定制开放权重模型的团队都会面临的问题：应该采用监督微调（SFT）、使用组相对策略优化（GRPO）的强化学习，还是将两者结合？
本文将介绍我们如何在 Amazon SageMaker HyperPod 上对 GPT-OSS-20B 进行多语言推理微调。我们会展示什么情况下仅用 SFT 就已足够，以及什么情况下叠加 GRPO 能带来可量化的收益。为了更全面地了解 GRPO 何时有效，我们还使用 Qwen2.5-7B，在两项能力差距不同的任务上开展了对照实验。简而言之：SFT 完成了大部分工作，GRPO 在仍有优化空间时进一步改进，而最终效果取决于所选技术是否与能力差距相匹配。
本节将介绍多语言推理任务及其数据集、SFT 与 GRPO 如何互补，以及我们在 Amazon SageMaker HyperPod 上运行的训练技术栈。
使用的数据集是 HuggingFaceH4/Multilingual-Thinking。这是一个思维链推理数据集，除英语外，还提供了法语、西班牙语、德语和意大利语译文，包含约 949 个训练样例和 50 个验证样例。模型会在系统提示词中收到一条 reasoning language: 指令，必须克服其强烈的英语先验倾向，使用指定的目标语言进行推理并作答。评估包含 50 个测试用例：10 道数学或逻辑题，每道题覆盖 5 种语言（EN/FR/DE/ES/IT）。
推理语言正确——思维链是否使用了指定语言？
答案语言正确——最终答案是否使用了指定语言？
理解这两种技术最清晰的方式是：SFT 教会模型尚未掌握的行为，GRPO 则优化模型已经偶尔能够表现出的行为。GRPO 会针对每个提示词采样一组回答，并推动策略向其中表现高于平均水平的回答靠拢。如果期望行为在基础分布中的概率为零，GRPO 就几乎没有可供强化的对象。仅凭这一点，就能解释本文中几乎所有的实验结果。
我们使用 Amazon Elastic Kubernetes Service（Amazon EKS）编排，在 Amazon SageMaker HyperPod 上运行训练。对 GPT-OSS-20B 进行最初的 SFT 和 GRPO 训练时，我们使用了 PyTorch TRL 库。在 Qwen 对照实验中，我们改用 veRL 作为训练器，使用 Ray 和 KubeRay 进行分布式编排，并通过 vLLM 快速生成 rollout。检查点和数据集存储在 Amazon FSx for Lustre 上，节点间通信使用 Elastic Fabric Adapter（EFA）。所有微调均采用低秩适应（LoRA），这种方法具有较高的参数效率，也非常适合 SFT 和 GRPO。
下图展示了端到端的训练数据流。用户提交的任务首先到达 Amazon SageMaker HyperPod 集群的 Amazon EKS 控制平面。Amazon EKS 随后调度一个 Ray head Pod，以及运行 veRL 训练器和 vLLM rollout worker 的 worker Pod。这两组 Pod 都挂载 Amazon FSx for Lustre，用于访问基础模型、训练数据和检查点。节点间的集合通信使用 EFA。rollout 从 vLLM 流式传回 veRL 训练器，训练器再将检查点写回 Amazon FSx for Lustre。
图 1：Qwen 对照实验中，在 Amazon SageMaker HyperPod 上使用 veRL、Ray、KubeRay、vLLM 和 Amazon FSx for Lustre 进行 SFT 与 GRPO 微调的端到端训练数据流
下面进一步说明各个环节。任务提交者从 Amazon SageMaker Studio 或 AWS Command Line Interface（AWS CLI）启动训练。Amazon SageMaker HyperPod 上的 Amazon EKS 控制平面将 Pod 调度到 GPU 节点，并启动 Ray head，以及供 veRL 训练器和 vLLM rollout worker 使用的 worker Pod。Amazon FSx for Lustre 为基础模型、训练数据和检查点提供共享的高吞吐量存储。训练完成后，训练器会将 LoRA 适配器写回 Amazon FSx for Lustre，用于后续评估或推理服务。
要跟随本文操作，你需要：
一个使用 Amazon EKS 编排的 Amazon SageMaker HyperPod 集群。GPT-OSS 的 SFT 使用了 4 台 ml.g6e.12xlarge（共 16 块 L40S 48GB GPU）。Qwen 对照实验使用了 2 台 g6e.48xlarge（共 16 块 L40S GPU）。
一个挂载到集群的 Amazon FSx for Lustre 文件系统，通过名为 fsx-claim 的 PersistentVolumeClaim 挂载到 /fsx。
启用 EFA 的实例，以及正常工作的 NVIDIA Collective Communications Library（NCCL）和 aws-ofi-nccl 技术栈，用于多节点 SFT。
一个容器镜像仓库，例如 Amazon Elastic Container Registry（Amazon ECR），用于存放基于参考代码仓库构建的训练镜像。
一个 HuggingFace 访问令牌，用于访问 openai/gpt-oss-20b 和 HuggingFaceH4/Multilingual-Thinking 数据集。
工作站上已安装 AWS Command Line Interface（AWS CLI）、kubectl、docker 和 envsubst。
下文引用的所有命令、清单文件和脚本，都位于 awsome-distributed-ai GitHub 仓库的 3.test_cases/pytorch/trl/gpt-oss-lora-grpo/ 目录下。克隆仓库并进入测试用例目录：
git clone https://github.com/awslabs/awsome-distributed-ai
cd awsome-distributed-ai/3.test_cases/pytorch/trl/gpt-oss-lora-grpo
复制环境变量模板，然后编辑 env_vars，设置 ECR 镜像仓库、镜像名称、标签和 HuggingFace 令牌：
cp env_vars.example env_vars
source env_vars
构建训练镜像并推送到镜像仓库。该镜像包含 PyTorch、TRL、HuggingFace Transformers、PEFT，以及训练和推理脚本：
cd artifacts && ./build_push.sh && cd ..
将 kubectl 配置为连接你的集群，并应用 FSx 存储管理 Pod 的配置。通过这个存储管理 Pod，你可以进入共享文件系统的 shell，转换检查点并查看评估日志：
aws eks update-kubeconfig --name <YOUR_CLUSTER_NAME> --region us-east-2
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< kubernetes/fsx-storage-manager.yaml | kubectl apply -f -
我们先评估基础模型，然后配置 SFT 训练并分析结果。
在包含 50 个用例的评估中，基础版 GPT-OSS-20B 的推理语言正确率为 22%（11/50）。各语言的结果为：英语 100%、法语 0%、德语 10%、西班牙语 0%、意大利语 0%。无论指令如何要求，模型都会默认用英语推理。
SFT 配置采用 LoRA，参数为 r=8、α=16，在 4 台 ml.g6e.12xlarge（共 16 块 L40S 48GB GPU）上训练 1,000 步，使用完全分片数据并行（FSDP）的 full-shard 模式、bf16 精度和梯度检查点。训练任务以弹性 HyperPodPyTorchJob 的形式运行，由 Kueue 管理，并通过 hyperpodrun 启动。
应用 SFT 清单文件：
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< hyperpod-eks/train-lora-hyperpod-elastic-g6e.yaml | kubectl apply -f -
查看训练进度：
kubectl get pods -l app=gpt-oss-lora-elastic
kubectl logs -f -l app=gpt-oss-lora-elastic
每一步都会输出损失和梯度范数。正常运行时的日志如下：
{'loss': 1.035, 'grad_norm': 0.163, 'learning_rate': 0.0002, 'mean_token_accuracy': 0.716, 'epoch': 3.25}
{'loss': 1.003, 'grad_norm': 0.171, 'lr': 0.0002, 'acc': 0.722, 'epoch': 3.32}
{'loss': 0.976, 'grad_norm': 0.159, 'lr': 0.0002, 'acc': 0.726, 'epoch': 3.57}
训练完成后，将 FSDP 检查点转换为 TRL 的 GRPO 训练器和推理脚本所需的参数高效微调（PEFT）格式：
kubectl exec -it fsx-storage-manager -- python /app/convert_fsdp_checkpoint.py \
--checkpoint /fsx/checkpoints/checkpoint-1000 \
--output /fsx/checkpoints/converted-peft/lora-checkpoint-1000-peft
经过 SFT 后，模型在全部五种语言中都能使用正确的语言进行推理，正确率达到 100%（50/50）。SFT 分两个阶段学会了这一行为：
在大约第 200 步时，模型学会了使用目标语言推理（推理语言正确率达到 100%）。
在大约第 1000 步时，模型进一步学会了使用目标语言给出答案。
最终 SFT 评估结果（第 1000 步）：
推理语言正确率：100%（50/50）。
答案语言正确率：62%（31/50）。
两者均正确的比例：62%（31/50）。
各语言的答案正确率：法语 60%、德语 60%、西班牙语 30%、意大利语 60%、英语 100%。
要点：在这里，SFT 是必不可少的。基础模型完全无法遵循推理语言指令，而 SFT 将推理语言正确率从 22% 提升到了 100%。剩下的差距在于答案语言，其正确率为 62%。这部分更难，因为最终答案很短，而模型在这一部分使用英语的先验倾向最强。
答案语言显然是 GRPO 应当优化的目标。经过 SFT，模型的推理语言正确率已经达到 100%，而且有时也能使用正确的语言作答，因此存在可以强化的信号。
我们使用 TRL 的 GRPOTrainer，从 SFT 检查点开始运行 GRPO。具体配置为：加载 SFT LoRA，调用 merge_and_unload，然后添加一个新的 LoRA（r=8、α=16，可训练参数约占 0.068%，即 200 亿参数中的 1360 万）。训练时，每个提示生成 K=8 个回答，使用 device_map=auto，学习率为 1e-6，训练 10 个 epoch。奖励函数对答案语言（±5.0）、推理语言（±1.5）和简洁程度（+0.5 或 −1.0）进行评分，总分范围为 −7.5 到 +7.0。
从转换后的 SFT 检查点启动 GRPO：
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< kubernetes/train-grpo-singlenode.yaml | kubectl apply -f -
kubectl logs -f grpo-single
GRPO 将检查点写入 /fsx/checkpoints/grpo-singlenode/。使用预留评估集选出最佳检查点（在本次运行中，答案语言指标较早就达到了峰值），然后将其转换为 PEFT 格式，用于推理和评估。
结果（以 SFT 检查点为起点）：
推理语言正确率：100%（保持不变：GRPO 没有破坏 SFT 学到的能力）。
答案语言正确率：从 62% 提升至 70%（提高 8 个百分点，35/50）。
两者均正确：70%。
各语言的答案语言正确率：法语 70%、德语 80%、西班牙语 60%、意大利语 40%、英语 100%。
GRPO 将答案语言指标实实在在地提高了 8 个百分点，同时将推理语言正确率保持在 100%。提升发生在仍有改进空间的地方。使用正确的答案语言，是一种模型有时能够做到、但 SFT 尚未使其完全收敛的行为，GRPO 则强化了这种行为。
要观察输出的实际差异，可以部署三个推理 Pod，它们共享同一个基础模型，但加载不同的适配器：
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< kubernetes/inference-g6e-base.yaml | kubectl apply -f -
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< kubernetes/inference-g6e-trained.yaml | kubectl apply -f -
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< kubernetes/inference-g6e-grpo.yaml | kubectl apply -f -
向每个版本输入同一个要求使用法语推理的提示：
kubectl exec -it inference-base -- python /app/inference_g6e.py \
--reasoning_language French
kubectl exec -it inference-trained -- python /app/inference_g6e.py \
--checkpoint /fsx/checkpoints/converted-peft/lora-checkpoint-1000-peft \
--reasoning_language French
kubectl exec -it inference-grpo -- python /app/inference_grpo_new.py \
--use_grpo \
--grpo_checkpoint /fsx/checkpoints/converted-peft/checkpoint-1470-peft \
--reasoning_language French
基础模型 Pod 无视指令，仍然使用英语推理。SFT Pod 使用法语推理，但经常用英语作答。GRPO Pod 则使用法语推理并作答。要复现前面各项数据所对应的完整 50 个用例评估，请运行评估清单，并通过 FSx 存储管理器读取结果文件：
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
< kubernetes/eval-grpo.yaml | kubectl apply -f -
kubectl logs -f eval-grpo
kubectl exec fsx-storage-manager -- \
cat /fsx/experiments/grpo_eval_checkpoint1470_*.txt
为了更全面地理解 GRPO 何时能够带来价值，我们在 Qwen2.5-7B 上，针对两个能力差距不同的任务开展了对照实验。
为了在不同模型和不同任务上检验“根据能力差距选择技术”这一论点，我们对 Qwen2.5-7B-Instruct 进行了对照实验。第一个任务是相同的多语言推理任务（仍有提升空间）。第二个任务是 GSM8K，模型在该任务上已经达到准确率峰值。这是一项内部实验，公开仓库尚未发布。
基础设施：2× g6e.48xlarge（16× L40S）、EFA 100Gbps、FSx Lustre、Ray 2.44 + KubeRay 1.4.2、veRL v0.6.1、vLLM 0.8.4。
实验组：A = 基础模型，B = 仅 SFT，C = SFT+GRPO。
在 GSM8K 上，基础 Qwen2.5-7B 的得分已经达到 90.5%（181/200）。GRPO 在第 30 步时的得分同样为 90.5%。当大多数采样组中的回答全部正确时，组内相对优势就会退化为零，因此没有学习信号。这是上述论点的另一面：GRPO 需要提升空间（pass@k >> pass@1），才有可优化的目标。没有提升空间，就没有收益。
从 SFT 开始。GRPO 无法教会模型一种在基础模型中出现概率为零的行为。它只能强化模型已经偶尔能够生成的回答。SFT 将推理语言正确率从 22% 提升到了 100%，本项工作中 GRPO 带来的每一次提升，都建立在这个 SFT 检查点之上。
SFT 和 GRPO 都使用 LoRA。LoRA r=8/α=16 的参数效率很高（可训练参数占 0.068%），而且在 Qwen 对照实验中，它在整个 GRPO 训练过程中都保持了数值稳定（梯度范数为 0.23，每块 GPU 的显存占用约为 11.7 GB）。如果希望 SFT 和 GRPO 使用相同的适配器结构，这是一个很好的默认配置。
根据能力差距选择技术。对于缺失的行为，使用 SFT。对于已经存在、但只是偶尔正确的行为，使用 GRPO 进行改进。在这里，GRPO 实际可达到的提升上限约为 6 到 8 个百分点。
在投入 GPU 小时之前，先检查奖励是否有提升空间。如果大多数组中的回答全部正确（GSM8K 基础模型正确率为 90.5%），组内相对优势就会退化为零，GRPO 也就无法获得梯度。在启动 GRPO 训练之前，请确认存在提升空间（pass@k >> pass@1）。
为避免持续产生费用，请先删除工作负载资源，再删除底层基础设施：
删除训练和推理 Pod 及作业：kubectl delete hyperpodpytorchjob lora-hyperpod-elastic --ignore-not-found kubectl delete pod grpo-single inference-base inference-trained inference-grpo \ eval-grpo fsx-storage-manager --ignore-not-found
kubectl delete hyperpodpytorchjob lora-hyperpod-elastic --ignore-not-found
kubectl delete pod grpo-single inference-base inference-trained inference-grpo \
eval-grpo fsx-storage-manager --ignore-not-found
缩容或删除 Amazon SageMaker HyperPod 集群或其节点组。
导出所有需要保留的检查点后，删除 Amazon FSx for Lustre 文件系统。
删除用于训练数据或检查点归档的所有 Amazon Simple Storage Service（Amazon S3）存储桶或对象。
我们展示了如何在 Amazon SageMaker HyperPod 上对 GPT-OSS-20B 进行多语言推理微调，以及如何在 SFT 和 GRPO 之间做出选择。SFT 完成了大部分工作：推理语言正确率从 22% 提升到了 100%。在仍有提升空间的地方，GRPO 在此基础上带来了切实但幅度有限的改进（答案语言正确率从 62% 提升至 70%）。并行开展的 Qwen2.5-7B 对照实验也验证了这一规律。在仍有改进空间的多语言推理任务上，GRPO 带来了 6 个百分点的提升。而在模型已经达到准确率峰值（90.5%）的 GSM8K 上，它没有带来任何提升。
模型完全不会的行为：使用 SFT。
模型有时能做到、而且仍有提升空间的行为：先使用 SFT，再通过 GRPO 多争取几个百分点。
模型已经达到准确率峰值，或者目标行为在基础模型中的出现概率为零：GRPO 无法提供帮助。
如果想亲自尝试，可以按照 awsome-distributed-ai 仓库中的测试用例操作。有关 Amazon SageMaker HyperPod 的更多信息，请参阅服务详情页和 Amazon SageMaker HyperPod 文档。有关在 Amazon SageMaker HyperPod 上使用 Ray 的操作指南，请参阅相关文章《使用 Ray 和 Amazon SageMaker Studio 在 Amazon SageMaker HyperPod 上运行分布式训练》。该文章发布后将补充链接。欢迎在评论区分享你的结果。