前OpenAI CTO新动向:Thinking Machines Lab的大模型后训练策略揭秘

前OpenAI CTO新公司Thinking Machines Lab的技术理念揭秘:大模型后训练策略是“少量SFT+大量RL”,并重视高吞吐量和灵活的团队协作。

原文标题:大模型江湖,算法与工程孰执生意牛耳?

原文作者:机器之心

冷月清谈:

本文解读了前OpenAI CTO Mira Murati创立的Thinking Machines Lab的技术理念,重点关注其研究科学家Luke Metz在拉美人工智能会议上的演讲。演讲围绕大模型后训练展开,强调了少量监督微调(SFT)与大量强化学习(RL)相结合的重要性,并分享了团队在产品、计算资源、软件系统以及组织复杂性方面的经验与挑战。后训练阶段需要关注推理目标,尽可能提高吞吐量,而团队协作方面,则需要建立有效的机制来整合各个小组的改进,并快速回滚问题。

怜星夜思:

1、文章提到"少少 SFT+大量 RL"是后训练的关键,那么在实际应用中,如何去衡量 SFT 和 RL 的投入比例,有没有什么通用的准则或者需要考虑的因素?
2、文章中提到后训练要关注高吞吐量,除了增加 Batch Size,还有什么其他的工程优化手段可以提高大模型的推理效率?
3、文章提到了团队协作的问题,当团队规模扩大时,如何保证各个小组独立改进的部分能够顺利整合到主模型中,避免出现灾难性的后果?

原文内容

机器之心PRO · 会员通讯 Week 12

--- 本周为您解读 ② 个值得细品的 AI & Robotics 业内要事 ---

1. 大模型江湖,算法与工程孰执生意牛耳?
前 OpenAI CTO 的新生意打算怎么做?「出走版 OpenAI」 后训练的生意经=少少 SFT+大量 RL?Thinking Machines Lab 重视哪些 RL 技巧?推理起量要做大吞吐?大吞吐除了堆 Batch Size 还有哪些要点?...
2. 2025 年,通用机器人要从实验室走向市场了吗?
为什么 2025 年,各家都在卷通用具身智能机器人的「大脑」?这些关键玩家谁能做成具身机器人的通用「基座」?通用具身智能模型技术路线还没有收敛?真机数据还是合成数据,具身机器人核心问题数据如何解决?具身机器人领域的关键玩家们近期都在做什么?...

...本期完整版通讯含 2 项专题解读 + 31 项本周 AI & Robotics 赛道要事速递,其中技术方面 10 项,国内方面 9 项,国外方面 12 项。
本期通讯总计 22998 字,可免费试读至 11% 
 消耗 99 微信豆即可兑换完整本期解读(约合人民币 9.9 元) 


要事解读①  大模型江湖,算法与工程孰执生意牛耳?
引言:OpenAI 前 CTO Mira Murati 的新公司的目标之一是「帮助人们调整人工智能系统,以满足他们的特定需求」,但至今尚未透露任何商业计划与项目信息。近期,该团队研究科学家Luke Metz首次在公开场合分享了他们对当前大模型技术的趋势与工程化经验,或在某种程度映射了Thinking Machines Lab的技术理念。
还是大模型,前 OpenAI CTO 的新生意打算怎么做?[1-1] 

1、近期,Thingking Machines Lab 的研究科学家兼工程师 Luke Metz 于拉美人工智能会议 KHIPU 2025 发表主题演讲。

① 2025 年 2 月 19 日,前 OpenAI CTO Mira Murati 宣布成立人工智能研究和产品公司「Thinking Machines Lab」。其豪华的团队阵容引起业内大量关注,但目前尚未公开任何实际项目。

2、该场演讲以「Large scale RL on language models」为题,探讨了预训练与后训练技术的工艺和见解,并「非常模糊」地分享了 Thingking Machines Lab 近期的进展。

① Luke Metz 的演讲主要围绕模型后训练的相关工艺展开。他以海绵为比喻,预训练的目的是在海绵中尽可能多的信息,而后训练则是为了让海绵以特定的人设/目的/需求把对应的信息呈现出来,因此工艺也更为复杂。

3、Luke Metz 强调了模型后训练的核心策略是整合从演示中学习(SFT)和强化学习(RL)两种技术。两者以「少少 SFT+大量 RL」的配比相结合往往能带来更好的效果。

① SFT 本质上是让模型从演示中学习,结束少量经过筛选和标注的演示数据为模型呈现任务执行的基础行为模式,让模型得到良好的初始策略(Do a bit of SFT to get a good initial policy)。

② 强化学习则是后训练的核心构成,奖励函数则是决定模型学习方向的关键因素。在 SFT 搭建的基础之上,通过精心设计的奖励函数,为模型行为提供精确导向,通过持续试错让模型逐步摸索出解决复杂任务的最优策略,(RL a bunch to maximize performance)

③ 结合 SFT 与 RL,以「Do a bit of SFT to get a good initial policy,RL a bunch to maximize performance」的模式设计往往会得到让人经验的结果(works surprisingly well)。

4、Luke Metz 还在演讲中讨论了产品、计算资源和软件系统于后训练之间的关系,并分享了其团队对于适配后训练推理目标(Inference Demand)的设计理念。

① 软件系统在后训练阶段的复杂性显著增加。与预训练阶段侧重于大规模数据并行处理和模型参数初始化计算不同,后训练阶段因涉及强化学习、多种数据类型处理以及复杂评估流程,要求软件系统具备更灵活、可扩展的架构。

② 相较于预训练,后训练需要将推理作为训练过程的一部分,因而和以往的推理目标(Inference Demand)不同。

③ Metz 强调,提供推理能力的产品通常关注低延迟表现(low-Latency),因为用户不希望等待过长时间。但对于 RL 和后训练,其目标是从硬件中获得最佳性能,因此需要尽可能提高吞吐量(High throughput)。推理目标的差异将会改变很多设计决策,也会导致系统架构的差异。

④ 在后训练的推理目标下,Metz 的设计经验是「Batch Size 越大越好」(Get big batch sizes as much as you can)。

5、Luke Metz 在有关组织复杂性的话题中分享了其团队在 OpenAI 开始就面临的问题、尝试解决方案和当前的阶段性进展。(但没有指出是否是 Thingking Machines Lab)

① 他以自己在 OpenAI 的经历为例,其团队只有大约五个人,但随着模型功能的不断增加,团队规模迅速扩大到了 100 多人。这种快速的团队扩张带来了新的问题,因为现在有大量人员需要在同一个模型上进行协作。

② 团队尝试通过建立一种机制来解决这个问题,这种机制允许各个小组独立改进模型的不同部分,然后将这些改进整合到一个主模型中。他们将这个主模型称为「主线模型」。

③ 这种方法的核心在于,各个小组可以在较小的模型上、使用较少的数据或特定的评估集上进行实验,如果某个小组的改进通过了这些测试,那么这些改进就会被整合到主线模型中。然而,这种方法也有其局限性,因为当模型规模扩大时,一些在小规模实验中看似有效的方法可能会突然失效,导致灾难性的后果。

④ Metz 还提到,当出现问题时,团队需要有一种机制来快速回滚到之前的状态。但是,这种回滚机制并不总是有效,因为有时候问题的根源可能并不明确。

6、此外,Luke Metz 在演讲中还分享了奖励优化、监督微调(SFT)与强化学习(RL)的结合使用、不同的 RL 方法、在链式思维和工具使用等领域的应用、评估方法、产品集成、计算需求以及组织挑战等多个方面。


表:Thinking Machines Lab 创始团队成员名单[1-2] 


「出走版 OpenAI」 后训练的生意经:少少 SFT+大量 RL?[1-1] 

补充一点,SFT 的数据质量至关重要!如果 SFT 的数据噪音太大,可能会误导模型,导致 RL 难以纠正。所以在 SFT 阶段,要尽可能保证数据的准确性和一致性。我之前做项目的时候,因为 SFT 数据没处理好,结果 RL 训练了一百多个小时,效果还不如随机初始化。

Batch Size 确实是提升吞吐量的常用方法,但也不是唯一手段。还可以考虑模型量化,比如 INT8 甚至更低精度,牺牲一定的精度换取更快的推理速度。另外,模型蒸馏也是个不错的选择,用一个小模型去逼近大模型的输出,降低计算复杂度。

与其优化模型本身,不如优化serving框架,如TensorRT、FasterTransformer等,他们针对transformer结构有专门的优化,用起来也比较简单,效果也比较显着。另外,可以考虑使用异步推理,避免 CPU 和 GPU 的 idle 时间,从而提高整体的吞吐量。

这个问题确实是大型项目常见的问题。可以借鉴软件工程中的 CI/CD 流程,建立一套完善的测试和验证机制。每次小组提交代码后,都要进行自动化测试,包括单元测试、集成测试、性能测试等等。只有通过测试的代码才能被合并到主模型中。

这个问题问得好!感觉没有绝对的黄金比例,得具体问题具体分析。SFT 像是给模型一个“起跑姿势”,RL 才是真正长跑,比例失调可能导致起跑领先但后劲不足,或者一开始就落后。个人觉得需要考虑任务的复杂度、数据的质量和计算资源的限制,通过实验来调优。

可以考虑用 Feature Branch 的方式进行开发,每个小组都在自己的分支上进行修改,完成后再合并到主分支。这样可以避免直接修改主分支,降低出错的风险。另外,还可以用 A/B 测试的方式来评估各个小组的改进是否有效,避免引入负面影响。

从硬件层面来说,用更快的 GPU 或者 TPU 是最直接的。如果预算有限,可以考虑分布式推理,将模型部署在多个设备上并行计算。另外,还可以优化模型的结构,比如用更高效的 attention 机制,或者减少模型的层数等等。

除了技术手段,还需要建立良好的沟通机制。各个小组之间要定期开会,分享进展、讨论问题。另外,可以指定专门的团队负责模型的整合和维护,确保各个部分的兼容性。我觉得代码review也很重要,减少bug的同时也能让大家更了解代码