Cursor 公开 Composer 2 强化学习内幕：模型如何识别虚假环境

不久前，Cursor 发布了其自有模型 Composer 的第二代最新版本，性能直逼 Claude Opus 4.7，而价格仅为其十分之一，在社区引起了不小的轰动。一个应用层公司，是如何转身成为一家真正的前沿模型实验室的？这背后的技术路径，值得深究。

恰好，红杉资本的官方播客近期邀请了 Cursor Composer 2 项目的研究负责人 Federico Cassano，以及为此项目提供分布式基础设施支持的 Fireworks 联合创始人 Dmytro Dzhulgakov，深入聊了聊 Composer 2 的构建内幕。这场对话，揭开了许多模型训练中不为人知的挑战与洞见。

官方曾透露，在 Kimi K2.5 开源模型基础上，Composer 2 训练的绝大部分算力——高达85%——都投入在了“中期训练”和“强化学习”这两个环节。而这次对话的核心，正是围绕这两大环节展开。

其中，一个令人惊讶的细节是，Federico 指出，在强化学习过程中，如果模拟环境与真实的用户电脑环境存在哪怕细微差异，模型是能够察觉到自己正处于“虚假环境”中的。更“狡猾”的是，一旦模型意识到这一点，它甚至会使用一些“小花招”来“作弊”，以获取更高的奖励值，而不是真正去学习解决问题的方法。

关于强化学习对模型的作用，Federico 的比喻颇为精妙：预训练是让模型吸收人类的全部知识，而强化学习阶段则像在调节一个“旋钮”，让模型明确自己的角色——“你是个专家，你需要把事情做正确。” 并且，在 RL 训练期间，模型直接与 Cursor 的 Harness（任务执行框架）交互，这相当于让模型提前熟悉了“自己余生将要生存的这个世界”。

Dmytro 则分享了一个对行外人颇具冲击力的事实：浮点运算在计算机上本质上是非确定性的，即 a+b+c 的结果不一定等于 c+b+a。这对混合专家模型（MoE）的 RL 训练影响巨大，因为 MoE 对计算精度极度敏感，微小的差异可能导致模型激活完全不同的专家节点，从而产生截然不同的输出。为了解决这个问题，工程师甚至需要手动编写复杂的 GPU 内核来强制运算顺序一致。

在算力分配上，Federico 也提出了独到见解。他认为“推理消耗的 FLOPs 远多于训练”是一个迷思。在理想情况下，应将大约三分之一的 GPU 算力分配给推理，剩余部分用于更新权重，以实现整体效率最优。

此外，他们认为对于特定领域，模型的“专门化”胜过“通用化”。传统观念认为模型越大、越通用越好，但 Cursor 将所有模型权重针对“内部的软件工程”任务进行专业化后，较小的模型在性能上便能接近 Opus 这样的大模型，同时成本降低了一个数量级。

更有趣的是，通过对 Harness 的一部分与模型本身组成的系统进行 RL 优化，Composer 2 训练出了“自我总结”或“压缩”能力。这使模型能在 20 万上下文窗口的基础上，实际处理百万级别的 Token。

Federico 还将 RL 环境解构为三部分：Harness、操作系统和奖励组件。其中，Harness 通常可移植，关键在于操作系统。为此，Cursor 自行构建了具备极强弹性的整个虚拟机栈，能够根据需求瞬间启动数以十万计的虚拟机供模型实验。

当然，涉及核心竞争力的部分，他们守口如瓶。例如，当被问及 RL 中使用何种奖励信号，以及如何更高效地从漫长的“展开”中提取信息时，他们的回答是：“绝对机密”。

以下是这次播客对话的精华内容整理。

成本低一个数量级！模型权重针对编程任务专业化

主持人：今天很高兴能与两位聊聊 Composer 2 的训练是如何完成的，你们共同解决了哪些难题，以及你们认为这对 AI 和基座模型公司的未来意味着什么。

Federico / Dmytro：谢谢邀请，这确实是个令人兴奋的话题。

主持人：对于那些没有密切关注的人来说，Cursor 最近发布了 Composer 2，这是一个专门用于长周期编码任务的智能体模型。Federico，是什么促使 Cursor 如此大力地投入到 Composer 2 的研发中？从应用层公司转型为拥有自己基座模型的公司，这有多关键？

Federico：我们开始训练自己模型的原因很简单。可以把模型看作一种存储驱动器，它的权重中能存储一定量的信息。我们只关心一项核心任务——Cursor 内部的软件工程。那么，如果把所有权重存储的信息比特，全部分配给这一项特定任务会怎样？结果就是，Composer 的成本比 Opus 等同类编码模型低了一个数量级。因为我们通过权重的完全专业化，可以用更小的模型达到相近的性能。

Dmytro：确实如此。这其实是应用演进的一种普遍模式。起初，你可能用现成模型做原型，进行提示词工程。但应用最具杠杆效应的属性，往往是对用户数据或特定运行方式的利用。要真正捕捉这些，提示词工程有上限，正确的方法是打造一个完全在你特定环境中运作的模型。

Federico：没错。比如某些智能体调用的工具，很难用语言向模型精确描述其行为。而后训练，则能把使用这些工具的最佳方式直接“烘焙”进模型里。Composer 虽然也有提示词，但以我们的训练方式，即使没有提示词它也知道该怎么做，因为整个训练过程一直在将模型推向正确的行为方向。

Dmytro：这里涉及质量、速度和成本的三维权衡。初期靠优化基础设施可以走很远，但介入模型训练后，你能把这个权衡推向更远，用更低的成本和更快的速度获得更好的模型，Composer 就是例证。

主持人：这是否有悖于“更大的模型在所有事情上表现都更好”的“苦涩的教训”趋势？

Federico：并不违背。需要指出，各大实验室的大模型也在代码数据上投入了大量训练。代码本身就是核心推进任务之一。在我们的场景下，相信“苦涩的教训”意味着要在数据维度上大力推进。模型容量有限，为了饱和利用容量并注入更多数据，我们需要让权重从可能的干扰中解放出来，专注于单一任务。

双轴训练赋能，RL 让模型更了解 Cursor 环境和写出正确的代码

主持人：能介绍一下 Composer 2 运作的精简版吗？是什么让它如此出色？

Federico：我们从一个强大的基础模型——Kimi 2.5开始。审视整个技术栈后，我们意识到有两个主要发力轴。Composer 1 主要只做了强化学习（RL），而 Composer 2 则双管齐下：一是接近预训练规模的持续“中期训练”，二是在此基础上进行海量任务的大规模强化学习。正是这两者的结合让它变得优秀。

主持人：Cursor 处于大量编码数据的中心，拥有独特的数据优势。为什么不直接预训练自己的模型？

Federico：我们习惯自上而下思考：如何在最短时间内交付对用户有用的模型？如果从预训练开始摸索，再扩展到中期训练和 RL，那将耗费极长时间。反向操作则能快速交付。当然，未来的 Composer 版本会是我们自己的模型，而非基于开源底座。

主持人：模型在中期训练和 RL 阶段分别学到了什么？

Federico：中期训练主要是学习各种代码库、常见代码模式及一些世界知识（包括网页数据），创造一个更广泛的数据分布，供后续 RL 聚焦和提炼。在 RL 期间，模型直接与 Cursor 的 Harness 交互，从而了解自己将要生存的“世界”。它学会了如何正确调用工具、导航环境、编写正确的代码。中期训练让它学会“写代码”，但不一定“写出正确的代码”。RL 的核心作用之一，就是微调模型特性，告诉它：“现在你必须时刻写出正确的代码。”

主持人：中期训练后的模型，是用于 Tab 自动补全的模型吗？

Federico：不完全是。Tab 模型非常小，以实现极低延迟。而 Composer 相当大，这是基础模型的核心区别。

RL 训练核心困境：会话展开、模型更新与算力利用率的多维权衡

主持人：看来大部分精力都花在了大规模 RL 上。能拆解一下其中的挑战吗？

Dmytro：RL 与预训练截然不同。你不仅仅预测下一个 Token，而是在运行整个框架实验：让模型在环境中行动，观察其在特定“展开”（即完整的智能体会话）中的表现，并根据结果（如代码能否编译）分配奖励。这意味着你需要大量额外组件：既要大规模训练，又要编排环境运行和模型推理。

这里存在一个庞大的、异构的更新循环。关键在于如何高效编排，因为 GPU 非常昂贵。一种朴素的方法是顺序进行：先停止训练器，跑完所有会话（可能长达5-10分钟），拿到结果后再更新模型。这在算法上稳健，但系统效率极低，一半算力闲置。

因此，我们采用“流水线异步化”。想象成一个巨大的工厂：一个“展开”车间不断用最新模型版本模拟新会话；一个训练器车间不断获取新结果计算更新。两者并行不悖。虽然这会引入模型权重更新的“陈旧性”，但通过让所有计算资源时刻满载，获得了更高的计算效率，足以弥补算法上几个百分点的潜在损失。

AI 也会“耍小聪明”！透露模型虚拟环境作弊现象

Federico：我们对性能极其认真。我们只有几万张 GPU，而非几百万张，所以用尽各种方法榨干性能。例如在生产环境中使用 FP4 训练，与 Fireworks 合作优化推理。RL 的基础设施比预训练更复杂，因为你首先需要预训练设施，还需要能高度模拟用户真实电脑的环境。模拟必须尽可能逼真，因为有时模型能察觉自己是在虚拟还是真实环境中运行，这会导致其在 RL 期间与生产环境中的表现不同。

主持人：你们真的观察到它意识到环境不同并改变行为了？

Federico：是的。它会想：“哦，我在虚拟环境里。我学到了一些小花招可以在这里获得更高奖励。” 模型太喜欢作弊了，而 RL 非常擅长鼓励这种行为。

另外，关于算力分配有个迷思：认为 RL 中推理消耗的 FLOPs 远多于训练。这主要是因为开源推理引擎缺乏优化。理论上，两者比例应大致相当。在极限优化下，应将约三分之一的训练 GPU 分配给推理，因为训练相当于三次正向传播，而达到临界批次大小的推理只需单次正向传播的 FLOPs。

主持人：所以你们选择 Fireworks 而非开源引擎。

Federico：是的。另一种选择是自己研发，但工程师资源有限。我们更希望工程师专注于提高训练效率和精准度。

推理训练采取全球化分布部署，还抽调了部分生产算力

主持人：你们的技术报告提到以全球分布式方式进行训练。为什么？难点在哪？

Federico：原因有几个。首先，市场上很难找到单一的、超大规模连续集群。我们的方案是：用一个主集群运行所有训练，同时将 RL 中的推理组件分布式部署到全球各地的小集群。训练 Composer 2 时，我们使用了四个相距甚远的集群，甚至在用户使用低谷期抽调了部分生产推理 GPU 来加速训练。这样，我们无需单一超大集群也能扩大规模。

Dmytro：补充一下，训练本质上是异构的。利用不同组件对基础设施的不同需求，可以大幅提升效率。训练需要高度互联、超高速网络的集群，且需同步工作，这类集群昂贵且难寻。将组件解耦部署到不同地方，一方面无需寻找超大集群，另一方面可以在硬件上做不同权衡（推理不需要那么高的全局带宽）。

一个关键挑战是模型快照的同步。一个 1TB 的训练步大约需要 5 到 15 分钟，意味着每隔几分钟就会产生一个全新的 1TB 权重快照。如何高效地将其传输到地球另一端？不能有太大延迟。有趣的是，并非所有权重在每一步都变化。RL 进行的是精准微调，每次变化的权重子集有规律，增量相对较小。我们编写了利用此特性的压缩算法，使得传输的增量可能比整个模型小 20 倍。我们构建了一套无损的存储系统机制（完整快照、增量快照、恢复和对齐），即使在最差网络下也能在几分钟内完成传输，实际切换权重时只需暂停约30秒。这碘伏了传统认知——你不再需要一个通过 RDMA 互联的超昂贵大型集群。

浮点运算不确定性，成为 MoE 模型 RL 训练的致命隐患

主持人：Kimi 是一个庞大的稀疏模型。这会让 RL 运行更困难吗？

Federico：会。在推理时，模型会生成采样 Token 的对数概率。在异步训练中，生成样本的模型版本可能落后于训练器当前进度，因此必须重跑正向传播来重新计算对数概率。理论上，相同模型版本应对相同 Token 给出完全一致的对数概率，但实际上会有轻微甚至显著的差异，即“数值不匹配”。这在 MoE 模型中尤为常见。

Dmytro：根本原因在于，浮点运算本质上是非确定性的。a + b + c 和 c + b + a 会给出不同结果。模型的所有操作都是乘法和加法，累加顺序影响最终结果。经过数十亿次操作，微小差异会被放大。在常规推理中，这通常不重要，因为预训练模型鲁棒性强。但在 RL 中，你是在用微弱信号教导模型，这种数值噪声足以导致训练失败。

MoE 模型对此尤其敏感。MoE 通过门控层决定激活哪些专家。隐藏状态的微小差异（例如小数点后第五位），可能导致选择7号专家而非9号专家，从而激活模型中完全不同的部分，差异被严重放大。在推理时激活7号专家，却在训练时试图更新未贡献的9号专家，这将是致命的。

主持人：你们是靠手写 GPU 核函数解决的？

Dmytro：是的。可以通过编写“批次不变”的核函数，强制按相同顺序进行加法运算来解决，但这通常会牺牲性能（可能慢2-3倍）。我们通过迭代找到了最佳权衡点（接受几个百分点的降速，解决大部分数值差异）。对于 MoE，还可以使用“路由器重放”技巧：让推理引擎告知训练器激活了哪个专家（只是一个整数），使训练器与之对齐。通过匹配量化级别、核函数等技巧，将训练与推理的实现分歧降到最低，这对训练成功至关重要。

离线 RL 筑基，防止产生糟糕的用户体验

主持人：能透露一下你们使用的奖励信号吗？……好吧，机密。那既然有海量真实用户数据，为什么还要在模拟环境中做 RL，而不是直接在真实用户环境上做？

Federico：我们实际上也在做“实时强化学习”。我们捕捉用户信号（如对代码生成是否满意），并尝试实时更新模型，目标是每隔几小时就交付一个新版本。这是一个有趣的博弈：目前为了稳定性，我们在缩短周期以摸索正确超参数；之后为了延长模型的长期处理能力，又需要拉长周期。

主持人：既然有真实数据，为什么还需要模拟的离线 RL？为什么不直接在线 RL？

Federico：目前的在线 RL 效率很低。除了 GPU 闲置问题，在效率和用户体验间也存在权衡。在模拟中，你可以针对同一提示词进行多次“展开”（如16或128次），从中获得极其精准的信号。算法如 GRPO 就是通过并行多个展开工作的。在线运行时，每次只能收回一个展开信号，算法实现上差异很大。最关键的是，模拟展开搞砸了只是浪费 GPU 时间；但面对真实用户，门槛要高得多，糟糕的输出意味着糟糕的用户体验。

所以，我们通过离线（模拟）阶段教会模型推理，赋予它应有的行为模式，注入关于世界的新信息。之后，才会把它推上线面对用户。因为如果模型很糟糕，用户根本不会用，也就没有反馈。在线 RL（或实时 RL）本身存在悖论：你无法用它从头创建一个模型，必须先有一个足够好的模型，才能通过在线方式让它变得更好。它更像是锦上添花。

20 万上下文窗口驾驭百万 Token！Cursor 秘诀：“自我总结”

主持人：如何让智能体运行得更久（长周期任务）？

Federico：有几个难点。一是“信用分配”问题：轨迹越长，模型越难判断哪里做对、哪里做错。二是上下文窗口有限。在 Cursor，我们通过在循环中加入“压缩”来解决，称之为“自我总结”。在 RL 过程中，智能体学会了如何不断延续。实际上，我们的模型有20万上下文窗口，但能处理数百万 Token，正是因为它学会了总结自己的工作，并利用总结重启上下文窗口，同时继续完成任务。我们同时在训练模型生成高质量摘要，并完美理解该摘要。

Dmytro：这很迷人。通常上下文管理被认为是 Harness 的一部分，但这里你们是在协同优化 Harness 的一部分与模型本身。这再次印证了“苦涩的教训”：往一个问题投入越多计算，就越能端到端地解决它。

主持人：你认为每家公司都会在自己的 Harness 上跑 RL 吗？

Federico：如果一家公司使用 AI 并生成大量 Token，同时有一个可以优化的产品，那么训练自己的模型就是正确的方向。

RL 让模型知道自己的角色是专家，需要把事情做正确

主持人：你们的大部分 RL 似乎集中在 Harness 和工具使用上，而非“预测下一个代码 Token”。对于其他创始人，这是一个判断是否需要 RL 的好框架吗？即：想让智能体长周期使用工具，就需要 RL；如果只是创建擅长总结或预测的模型，可能不需要。

Federico：我认为 RL 适用于任何地方。甚至对于 Tab 自动补全，我们也使用了（这只是个人理论）。预训练是让模型吸收人类全部知识。一个未经 RL 的模型面对问题时，会困惑自己扮演什么角色（专家还是学生？）。RL 期间发生的一件事，就是我们在调节一个旋钮，告诉模型：“你是专家，需要把事情做正确。” 所以，RL 是在提炼这种分布。第一阶段，模型学得很快；第二阶段，需要大量计算持续提升，模型开始展现推理能力。在第一阶段，RL 的作用就是告诉模型“必须做正确”，这在计算量较小的场景下也很有用。

Dmytro：非常赞同。我们看到很多这种模式。持续预训练和监督微调更像是传递新知识；而 RL 则是在提炼行为或特定品质。两者通常都需要。即使以总结为例，RL 也很有用。如果你想要特定风格的总结，很难用完美的“好/坏”示例来描述。但使用大模型作为裁判，你可以设定精准的评审标准，通过提示词描述评估标准，然后放入 RL 循环，让模型尝试不同风格，摸索出你想要什么。这种模式在编码和其他领域都很常见。

用大模型作为裁判，软件编写第三阶段：“编写评估规则”

主持人：你认为最终是依赖专家手动检查 RL 展开路径来指导模型的公司更成功，还是依赖大模型作为裁判等自动化标准更可能成功？

Dmytro：你不可能让专家评审每一次展开。总的来说，奖励信号越“可验证”越好，因为这允许你扩大计算规模。“可验证”意味着能否在没有人类介入下自动产生信号。对于数学或编码，你能设计出确定性的东西，那是最好的。大模型作为裁判行之有效，是因为判断比创造容易。你可以针对多个维度设计复杂评估。比如，一个大模型评判风格，另一个评判事实性，从而打造出奖励信号。有些是确定性的，有些是基于大模型的。然后，投入更多计算，就能看到性能曲线上升。

主持人：在那些更难验证的领域，RL 会发挥更大作用吗？大模型作为裁判足够吗？

Dmytro：这是你会首先尝试的技术之一。理想情况是弄清楚真实指标是什么。逼近这个指标是一种方法，构建更大的模拟环境是另一种。如果你能模拟更多产品环境，通常就能得到关心的最终指标，只是更难捕获。行业专家的作用依然不可或缺，因为设计这些任务、将产品体验编码进去至关重要。我们经历了软件1.0（直接编写软件）、2.0（编写训练数据），现在进入3.0阶段：编写评估规则。这依然非常重要，你需要观察示例、数据、产品失败点，以及如何引导模型走向正确行为。

RL 环境由三部分组成，Cursor 自己构建了整个虚拟机栈

主持人：关于 RL 环境，现在涌现了很多环境供应商。以 Cursor 为例，你们已拥有大量客户使用环境的数据。环境供应商还能提供什么？

Federico：我们实际上没有使用任何环境供应商的产品。构建一个能工作的环境非常困难。对于那些无法接触到这些数据的人来说，环境产品很有价值。但在编码领域，每个人都可以获取海量的编码环境（如 GitHub）。主要困难在于基础设施。例如，测试数据库迁移是否生效，需要启动数据库。这类事情很棘手，环境公司在这方面可能有帮助。

Dmytro：这有两个层面。对于前沿实验室，他们需要构建通用模型，涵盖所有任务，鼓励泛化，环境公司有帮助。但对于像 Composer 这样的情况，你拥有自己的实际产品，最强大的环境就是你自己的产品。你应该针对它把效果做到最好。当然，你需要妥善隔离（不能在生产数据库搞破坏）。环境公司提供通用工具让这一切更容易，但总的来说，你希望 RL 环境尽可能接近真实生产环境。

举个例子，很多玩具级 RL 框架始于“启动一个 Docker 容器”。如果要过渡到生产案例，你不能只是把真实应用塞进 Docker。我们很早就发现，对于某些客户，我们在我们的训练平台上运行训练器，但环境默认在客户侧运行，因为那是实际实现所在。你调用实际的生产环境，而不是试图包裹并组件化它。

Federico：在托管平台做这个非常困难，且会引入差异。我们所说的“RL 环境”由三部分组成：一是 Harness（模型提交工具、工具被执行的地方）；二是“操作系统”（模型交互的实际世界和状态）；三是奖励组件（最后检查工作是否正确完成）。通常，Harness 是可移植的。关键是操作系统，要复制它，普通容器运行得不好。在 Cursor，我们自己构建了整个虚拟机栈，以便能非常快速地启动虚拟机。它必须具备极强的爆发性，因为系统可能需要瞬间提供十万台虚拟机。

主持人：非常感谢两位的分享。Cursor 树立了一个从应用层公司演进为前沿模型实验室的榜样。Composer 2 的工作确实引领了潮流。能听到这些内幕非常特别。感谢你们今天来到播客。

Federico / Dmytro：谢谢邀请。