你让一个推理模型“用法语思考”，它点头答应，然后照样用英语写完整段思维链。这不是模型在偷懒，而是它的先验在替你作答。OpenAI 开放权重的推理模型 GPT-OSS-20B 就是这样一台“英语脑”机器：在 AWS 设计的 50 题多语言推理测试里，基座模型用正确目标语言推理的比例只有 22%，而且这 22% 几乎全是英语题，英语 100%、法语 0%、德语 10%、西班牙语 0%、意大利语 0%。
AWS 的 AI/ML 基础设施团队没有绕开这个问题。他们在 SageMaker HyperPod 上对 GPT-OSS-20B 做了一套完整的微调实验，把监督微调（SFT）和 GRPO 强化学习分别推上台面，最后给了一个对行业有普遍意义的结论：SFT 干了绝大部分重活，把推理语言正确率从 22% 拉到 100%；GRPO 只在“还有提升空间”的地方做适度打磨，把答案语言从 62% 推到 70%。一句话，SFT 教模型它不会的行为，GRPO 优化它已经偶尔能做出的行为。
现象层：开源推理模型的“语言精神分裂”
GPT-OSS 是 OpenAI 向公众开放权重的推理模型系列，120B 和 20B 两个尺寸同时登陆亚马逊云、微软云和 Baseten。开放权重意味着企业可以把它搬进自己的 SageMaker HyperPod 集群，按自己的数据微调。但 GPT-OSS-20B 继承了推理模型最顽固的习惯：思维链只用英语写。
AWS 拿到的测试场景很具体。数据集是 HuggingFaceH4/Multilingual-Thinking，大约 949 条训练样本加 50 条验证，思维链被翻译成法语、西班牙语、德语、意大利语和英语。模型会收到一条“reasoning language:”的系统提示，被要求用目标语言完成推理和作答。评测则是 50 道题：5 种语言各 10 道数学或逻辑题。
结果毫不意外，也足够刺痛：基座模型在 50 题里只有 11 题用对了推理语言。更残酷的是语言维度的拆解，英语 100%，法语、西班牙语、意大利语全部挂零，德语勉强 10%。也就是说，一个法国客户用法语问一道推理题，模型大概率会用英语在脑子里“想”一遍，再给你答案。对部署多语言推理服务的企业来说，这不是体验瑕疵，是产品缺陷。
这里藏着一个容易被忽略的判断：语言切换不是翻译问题，而是推理路径问题。模型不是“想到了法语答案但用英语写出来”，而是整个推理过程都跑在了英语轨道上。你让它“用意大利语思考”，它听懂了这句话，但接下来生成的每一个推理 token 仍然沿着英语概率最高的路径走。这正是微调要解决的核心矛盾，不是让模型多会一门语言，而是让它在特定语言里重建推理路径。
分析层一：SFT 为什么必须上场
AWS 的第一刀是监督微调。配置很克制：LoRA r=8、α=16，训练 1000 步，4 台 ml.g6e.12xlarge 实例（共 16 张 L40S 48GB），用 FSDP 做分布式，训练框架是 PyTorch TRL。全部参数里只有约 0.068% 可训练，20B 参数里只动了 1360 万。
效果是决定性的。SFT 之后，模型在 50 题里 100% 用对了推理语言，五种语言全覆盖。AWS 还观察到 SFT 的学习曲线分成两个阶段：先学会“听指令”，再学会“用目标语言写思维链”。
但 SFT 没有解决全部问题。推理语言 100% 之后，答案语言停在 62%。AWS 的解释很直白：最终答案很短，而模型对英语的先验在短文本上最强。换句话说，SFT 教会了模型“怎么想”，但模型在“怎么说最后一句话”上还是会滑回英语。这也是为什么 AWS 在文章里写下那句判断：SFT 在这里不是可选项。基座模型根本不会遵循“推理语言”这条指令，你不做 SFT，后面什么都谈不上。
这个结果对行业有一个隐含提醒：很多企业一听到“强化学习提升推理”，第一反应是跳过 SFT 直接上 GRPO 或 PPO。AWS 的实验把顺序摆得很清楚，强化学习是放大器，不是启蒙老师。当目标行为在基座分布里的概率接近零时，强化学习连样本都采不到，更谈不上优化。
分析层二：GRPO 的价值边界在哪里
GRPO 上场的方式很讲究。它不是从零开始训，而是站在 SFT 的 checkpoint 上继续：先把 SFT 的 LoRA 合并卸载，再挂一层新的 LoRA，K=8 代采样，学习率 1e-6，10 个 epoch。奖励函数也设计得有针对性，答案语言 ±5.0 分，推理语言 ±1.5 分，简洁度 +0.5 或 −1.0，总分区间 −7.5 到 +7.0。
GRPO 确实带来了增益：答案语言从 62% 提升到 70%，同时推理语言稳在 100%。但请注意这个增幅的量级，+8 个百分点，而且只发生在“答案语言”这个 SFT 没完全收敛的指标上。AWS 对两种技术的分工给了一个可以复用的定义：SFT 教模型它没有的行为，GRPO 优化它已经偶尔能做出的行为。如果某个期望行为在基座分布里的概率是零，GRPO 几乎没有东西可以强化。
为了验证这条“技术要匹配能力缺口”的论题，AWS 还跑了一组 Qwen2.5-7B-Instruct 的对照实验，同样是 A=基座、B=SFT-only、C=SFT+GRPO 三组对照。在多语言推理任务上，GRPO 带来了结构化格式 +6、推理语言 +2、答案语言 +6、两项都正确 +6 的增益。但在 GSM8K 上，基座模型已经 90.5%（200 题对 181 题），GRPO 训到第 30 步还是 90.5%，零增益。
原因同样清晰：当大多数采样组已经全员正确时，组内相对优势会坍缩成零，学习信号消失。GRPO 需要 headroom，也就是 pass@k 明显大于 pass@1，才有东西可优化。没有提升空间，就没有增益。这句“No headroom means no gain”，可能是这篇 AWS 博客对行业最值钱的一句话。
把两张表放在一起看，GRPO 的画像就清楚了。它不是万能钥匙，而是一把精度很高的锉刀：只在你已经凿出形状、但边缘还不够平整的地方起作用。在多语言推理这种“基座完全不会”的任务上，SFT 完成了从零到一的 78 个百分点跨越，GRPO 只补了最后的 8 个点；在 GSM8K 这种“基座已经接近满分”的任务上，GRPO 连 0.1 个点都挤不出来。企业做技术选型时最该问的不是“哪个算法更先进”，而是“我的模型现在站在哪个位置”。
分析层三：HyperPod 栈为什么重要
这套实验不是跑在单卡笔记本上的。GPT-OSS-20B 的 SFT 和 GRPO 跑在 SageMaker HyperPod 上，用 Amazon EKS 编排，PyTorch TRL 做训练框架；Qwen 对照实验则切换到 veRL 0.6.1，配合 Ray 2.44、KubeRay 1.4.2 做分布式编排，vLLM 0.8.4 负责快速 rollout 生成。检查点和数据集放在 FSx for Lustre 上，节点间通信走 EFA 100Gbps。
这套栈的意义在于可复现。AWS 把整条数据路径做成了端到端架构：用户从 SageMaker Studio 或 CLI 提交任务，EKS 把 Ray head pod 和 worker pod 调度到 GPU 节点上，veRL trainer 和 vLLM rollout worker 都挂载 FSx for Lustre 读取基座模型、训练数据和写回检查点，rollout 从 vLLM 流回 trainer。代码放在 aws-samples/awsome-distributed-ai 仓库里，企业可以按图施工。
这里有一个细节值得注意：GPT-OSS-20B 的主实验用 TRL，Qwen 对照实验换 veRL。这不是随意切换，而是工具链与场景的匹配，TRL 对 GPT-OSS 这类 HuggingFace 生态模型更友好，而 veRL 在大规模分布式 RL 场景下与 Ray、vLLM 的集成更成熟。AWS 把两套工具链都跑通，等于给企业提供了两张现成的施工图：你想快速验证，用 TRL；你要上规模、做生产级 RL，切 veRL。
这也是亚马逊云在 OpenAI 开放权重之后的标准打法：既然模型谁都能拿到，差异化就落在“怎么训得快、训得省、训得可复现”。HyperPod 的 recipes 把分布式训练环境搭建成几分钟的事，企业省下的不是显卡钱，是调环境的时间。当模型权重变成 commodity，真正产生壁垒的是训练流水线的工程能力。
结论层：给企业微调路线图的三条判断
别一上来就迷信强化学习。如果你的模型连指令都听不懂、连目标语言都不会用，GRPO 帮不了你，先做 SFT。这篇实验里 SFT 完成了从 22% 到 100% 的跨越，GRPO 只是把已经及格的科目从 62 分提到 70 分。
用“能力缺口”来决定技术选型。缺口大、行为从零到一，用 SFT；行为已经偶尔出现、只是不稳定，用 GRPO 去强化；行为已经接近峰值，GRPO 的学习信号会坍缩，别浪费算力。
关注答案语言这个“最后一公里”。推理过程用对语言只是第一步，最终答案会不会滑回英语，才是用户体验的真正考场。在这个指标上，SFT 只到 62%，GRPO 补了 +8 个点，但 70% 远不是终点，后续可能还需要更强的奖励建模或者更多样化的多语言答案数据。
开源模型给了你权重，但没给你能力。SFT 是从零到一的铲子，GRPO 只是打磨刀锋的布，先确定刀刃存不存在，再决定要不要擦。
快报