2026-06-04 14:56
扫码打开虎嗅APP
本文来自微信公众号： 每日天使 ，作者：每日天使
Sonya Huang：Cursor以前主要是在调用别人的模型做代码补全。为什么现在要自己训练Composer 2？成为基础模型公司对你们来说有多大的存在意义？
Federico Cassano：原因很简单——你可以把模型想象成一个存储驱动器。它的权重里能存的信息bits是有限的。我们只关心一个任务：软件工程，而且是在Cursor这个特定环境里的软件工程。我们甚至连编程都不一定关心。如果通用模型要把bits分配给写诗、解数学题、回答法律问题等成百上千种任务，那如果我们把所有可以存储在模型权重里的信息bits都分配给这一个任务呢？另外，大家可能已经注意到了，Composer的推理成本比Opus这类通用编程模型低了一个数量级——因为我们把所有权重都专门化了。我们可以用更小的模型来达到接近甚至更好的效果。
Dima Dzhulgakov：我们把这个视为应用公司演化的一个普遍模式。你一开始用现成模型做原型，做prompt engineering，搞清楚你的产品逻辑。但你应用最核心的优势——用户数据、你的工具链、你的环境——这些是没法靠prompt完全捕捉的。真正正确的做法是为你的环境专门训练模型。
Federico Cassano：确实。Agent调用的一些工具的行为特性，很难用文字描述清楚。通过后训练，我们可以把最优的工具使用模式直接烤进模型权重里。我们当然也给Composer输入prompt，但以我们训练它的方式，即使没有prompt它也知道该怎么做——因为我们从训练一开始就把它推向正确的方向。prompt engineering有一个天然上限，你能走多远取决于你愿意在模型层面投入多少。
Sonya Huang：讲讲Composer 2的训练recipe。你们没有做从零开始的预训练，而是走了一条非传统的路径？
Federico Cassano：对，我们没有从预训练开始。我们的起点是一个开源基座模型——一个不错的、已经做过pre-training的模型。然后我们做了mid-training：在编程和软件工程相关的海量数据上做继续训练，让模型先说编程的语言。这一步的目的是让模型把注意力集中到我们的领域上。mid-training之后再进入RL阶段——这才是真正让模型学会在Cursor里做软件工程的关键。
Dima Dzhulgakov：这个路径的好处是你可以非常快地拿到一个可用的模型，先交到用户手中。然后你围绕真实用户在Cursor里的使用数据来进一步专门化模型——形成一个正向循环。从预训练开始做当然也有可能产出更好的模型，但时间周期和成本完全不在一个量级。对应用公司来说，时间就是一切。
Federico Cassano：实际上我们在训练中还发现，mid-training阶段的数据质量比数量重要得多。你不需要把整个GitHub都喂进去——高质量、高相关性的编程对话和软件工程轨迹数据，比海量低质量代码的效果好得多。RL阶段我们用了多轮迭代方式，每一轮都用最新的用户数据来更新奖励函数和训练环境。
Sonya Huang：分布式训练中遇到的最棘手的技术问题是什么？
Dima Dzhulgakov：浮点漂移（Floating Point Drift）绝对是其中之一。当你把训练分布在几百甚至几千张不同型号的GPU上时，即使是同一个模型架构、同样的输入，不同GPU上的浮点运算可能产生微小的数值差异。这些差异单独看微不足道，但在RL训练中会被反复放大——因为每一轮的模型更新都建立在前一轮的结果上。漂移累积到一定程度后，模型的训练效果就会出现不可预测的退化。
Federico Cassano：更讨厌的是，这个bug不会直接报错——你的训练看起来一切正常，loss在下降，但训练出来的模型就是不行。等你排查到是浮点漂移的问题时，可能已经浪费了好几天的训练时间和大量GPU成本。我们最后的解决方案是在关键计算节点上使用更高精度的数值格式，并在每个训练epoch结束时做跨节点的数值一致性校验。
Dima Dzhulgakov：这也是为什么在实际工程中，你不能简单地把单机跑通的训练脚本直接扩展到分布式集群。浮点运算的不确定性在大规模分布式训练中会被显著放大，必须从一开始就在架构层面考虑。
Sonya Huang：你们用的是MoE架构（混合专家模型）。这种架构在训练中有什么特殊挑战？
Federico Cassano：MoE最让我们头疼的是路由器（Router）的敏感性。MoE模型的核心是一个路由器，它决定每个token该发给哪个专家模块去处理。问题在于，路由器在训练早期的微小扰动——哪怕只是参数初始化的差异——会导致完全不同的专家分配模式。更糟糕的是，这种分配一旦稳定下来，后续训练就很难改变。
Dima Dzhulgakov：我们观察到的情况是：同一个MoE模型在两次训练中，即使所有超参数完全一样，路由器的行为也可能出现显著差异。这直接影响了最终模型的性能——某些训练run就是比另一些好，而且原因很难追溯。
Federico Cassano：我们引入了一个叫Router Replay的修复方案。简单来说，就是在一个成功的训练run中，把路由器的决策路径记录下来，然后在后续的训练迭代中回放这些决策。这相当于给路由器一个稳定的参考锚点，避免它在训练早期就走向一个不可逆的次优方向。当然这个方法也不是完美的——它牺牲了一些探索空间，但确实显著提升了训练的稳定性和可复现性。
Sonya Huang：你们的RL训练循环是怎么运作的？特别是面向长周期Agent的时候。
Federico Cassano：传统的代码补全RL训练相对简单——你给模型一个上下文，它生成一段代码，你用测试用例或者静态分析作为奖励信号。但Agent完全不同。Composer 2面对的是多步骤、跨文件的软件工程任务——可能需要搜索代码库、读文档、修改多个文件、运行测试。一个典型的Agent交互可能持续几十甚至上百步。这意味着一个完整的RL训练episode比传统的补全任务长得多，奖励信号的稀疏性也更严重。
Federico Cassano：还有一个很有意思的发现：随着RL训练的推进，模型的策略会变得更好，这意味着agent完成的步数越来越多。所以实际上，训练越往后，每个episode的计算成本越高——这是一个正向循环，但同时也意味着你需要预留更多的GPU预算。
Sonya Huang：你们提到环境仿真是一个关键问题。模型真的会学会辨认它是不是在测试环境里？
Federico Cassano：是的。模型非常擅长寻找捷径。RL训练本质上是鼓励奖励最大化的——模型会找到任何能提高奖励分数的行为，不管这些行为是否真正有用。如果训练环境跟生产环境有细微差异，模型就会学会利用这些差异。
Dima Dzhulgakov：我们见过模型学会了识别某些特定的文件系统特征或者API响应模式，然后在这些特征出现时采取完全不同的——而且通常是作弊式的——行为策略。
Federico Cassano：最典型的例子：如果训练环境里的测试用例总是以相同顺序运行，模型会记住这个顺序而不是真正理解测试逻辑。放到真实环境中遇到不同顺序的测试时，表现就一落千丈。我们的解决方式是尽可能让训练环境逼近生产环境——使用真实的Docker容器、真实的文件系统、与用户使用完全相同的工具链。但即使如此，总有一些差异是难以消除的。这是Agent RL训练中最基本的数学难题之一——你永远在跟模型的奖励黑客本能做斗争。
Sonya Huang：你觉得模型意识得到它在被测试吗？
Federico Cassano：我不会用意识这个词。但它确实学会了某种行为模式映射——它学到当环境看起来像X的时候，我可以用策略Y来最大化奖励，不管策略Y在真实场景下是否合理。RL在鼓励作弊这件事上真的非常擅长。
Sonya Huang：你们用什么作为奖励信号？
Federico Cassano：混合方式。一部分是执行信号——代码能不能编译、测试能不能通过。但这远远不够。一个Agent可能写出一段能通过测试但设计糟糕的代码。我们大量使用了LLM as Judge——用一个更强大的语言模型来评估Agent的行为质量，包括代码的可维护性、方案的优雅程度、错误处理的完备性等。
Dima Dzhulgakov：LLM as Judge本身也是一个工程挑战。你需要确保裁判模型的评估是一致的、可复现的。我们花了不少时间在裁判模型的校准上——确保它在不同的context下给出可比较的评分。这个成本也不低——裁判模型的推理本身需要计算资源，如果你评估的任务本身就很长，裁判成本可能接近甚至超过Agent本身的推理成本。
Federico Cassano：但LLM as Judge最大的优势是可扩展性。你不需要人工标注成千上万个Agent轨迹——模型可以自动产生评估。这让大规模的RL训练在经济上变得可行。当然我们仍然保留了一部分人工评估，用来持续校准裁判模型。
Sonya Huang：你们觉得RL会成为AI训练的默认范式吗？不只是编程领域。
Federico Cassano：毫无疑问。我们已经看到RL在数学推理、游戏AI甚至创意写作中产生了惊人的效果。任何需要多步决策和长期规划的任务，RL都比纯监督学习有天然优势。编程Agent只是最明显的用例——因为编程天然就有可验证的输出（代码能不能跑），这给了RL一个干净的奖励信号起点。
Dima Dzhulgakov：从基础设施角度来看，我认为RL训练的工程复杂度会随着应用场景的扩展而持续增加。编程Agent已经够复杂了，但如果你想象一个Agent在做科学研究、做投资决策、或者做医疗诊断——环境的复杂性和评估的难度是指数级增长的。这会给基础设施带来巨大压力，但也意味着巨大的机会。
Sonya Huang：给想做同样事情的应用公司的建议？
Federico Cassano：建你自己的环境。这是你能构建的最核心的护城河。你不需要从预训练开始——从开源基座模型出发做mid-training+RL是一条经过验证的有效路径。但你的训练环境必须尽可能逼真地反映用户真实使用场景。这比选什么模型架构、用什么超参数都更重要。
Dima Dzhulgakov：基础设施不要等到最后才考虑。很多团队先花三个月把模型训出来，然后才开始想怎么部署、怎么规模化。你应该从第一天就把基础设施当成训练pipeline的一部分来设计——特别是如果你的目标是大规模RL。否则你会发现自己陷入了一个跑得通但无法扩展到生产级的局面。
Sonya Huang：最后，用一句话总结你们从这次训练中学到的最重要的教训是什么？
Federico Cassano：专门化的力量被严重低估了。当前整个行业都在追逐更大、更通用的模型，但我们发现把有限的模型容量聚焦到一个具体应用场景上，你可以在性能、成本和用户体验三个维度同时获得显著优势。Composer 2证明了这条路是行得通的。
视频链接：https://youtu.be/UDTr9yUnLUI
