@srush_nlp: Talk: Training Composer https://youtube.com/watch?v=uTgqYeVxy2c… Overview of the methods that we use at Cursor to build…

Talk: Training Composer https://youtube.com/watch?v=uTgqYeVxy2c… Overview of the methods that we use at Cursor to build our model.

TL;DR: Cursor 自研编程模型 Composer 2 通过大规模持续预训练、长程强化学习和内部基准 CursorBench，实现了顶级编程智能体性能，并在成本、速度和真实任务表现上取得突破。

Composer 2 概述

Composer 2 是 Cursor 为智能体编程打造的模型。它实力强劲，发布时性能与 Opus 4.6 相当，略低于 GPT-5.4。兼具顶级的编程速度和极具竞争力的价格，处理各类编程任务时极其高效，每 Token 成本也很实惠。

过去一年，Cursor 一直在研发编程模型。第一代模型 Composer 1 的目标是提供强有力的交互辅助过程。用户正从逐个选项卡的手动编码，转向更依赖智能体的方式，这个过程在过去几个月里加速明显。

最初设计模型时，目标是回答这类编码风格的任务：用户请求发送到模型，模型调用一系列工具（读取文件、编辑文件、使用代码库搜索、收集 Lint、运行终端命令）。智能体在这些工具间循环，完成修改。

过去几个月里，人们从单次代码变更转向完整的软件工程。Composer 2 的目标正是为这样的世界构建一个编程智能体。对于典型的 Cursor 开发者，智能体几乎能编写 100% 的代码。他们会花时间做编码之外的事情：拆解问题、审查产物、运行测试和提供反馈。同时，人们期望能同时启动多个智能体，无需时刻盯着它们，只希望它们能完成任务。

带着这个目标，我们设定了三个具体子目标：

• 智能体对代码有广泛而深入的理解。
• 能完成困难的任务。
• 在人们考虑的真实任务中表现良好。

知识：大规模持续预训练

我们希望构建一个对代码有广泛深入知识的智能体，为此引入了一个大规模持续预训练阶段。这个额外阶段的目的是提升系统的核心知识，但不是通用聊天机器人式的知识，而是特定编程类型的知识。

基础模型选择

我们使用了 Kimmy K 2.5 作为系统的基础模型。这个模型有 1 万亿参数，其中 320 亿参数被激活。它有 61 层，上下文长度为 256K。对于一个开源模型来说非常令人印象深刻。它还使用了多头潜在注意力，便于提供服务。

在决定基础模型时，我们在几个不同的基准上测试了几个不同的开源模型，包括内部代码和其他属性。很多开源模型都相当强大。最终选择 Chimney（即 Kimmy K 2.5）而非其他模型，主要是基于基础设施因素，以及它适配已开发的一些系统。

训练阶段

我们运行了一个相对标准但规模巨大的流程：

1. 短上下文预训练阶段：对大量 Token 运行，目标是让模型在希望使用的主题上知识更丰富。
2. 长上下文扩展阶段：提供更多 256K Token 级别的数据。
3. 最终监督微调阶段：使用更接近实践的智能体数据。

持续预训练的图表显示损失随时间下降。我们验证了其必要性：考虑三种不同的预训练量变体（小、中、大），得到不同的负对数似然值。在运行标准强化学习阶段后，这三个系统获得了不同的奖励。有能力进行这类实验就能看到其中的好处。

长程强化学习

系统下一个主要阶段是长程强化学习，旨在构建一个真正能够运行并完成非常困难任务的智能体模型。强化学习尽可能模拟人们在 Cursor 中实际运行的查询，除了提高智能水平，还允许调整行为以最大化用户体验。

收集问题

我们处理的问题（左侧图表）针对大量的现实世界编程问题：迭代功能、调试代码、添加新功能。但越来越多地包含软件开发过程部分的任务：包含文档、进行迁移、管理不同的项目结构。任务难度差异巨大，要找到足够困难、能真正挑战模型的问题正变得越来越有挑战性。

自动安装（Auto-install）

这是我最喜欢这个系统的部分之一，展示了开发模型如何能够改进模型本身的未来版本。使用之前的模型 Composer 1.5 分两个阶段运行：

• 第一阶段：探索仓库并阅读文档，提出 10 个安装命令，然后编写测试来检查这些命令是否可验证。
• 第二阶段：Composer 安装环境，运行 UV 设置及所有可能需要的不同命令，确保测试通过，模拟依赖关系，安装第一次没起作用的包。

如果通过第一阶段的验证，环境就设置成功并用于强化学习训练。

强化学习过程

工作方式：从之前设置的问题开始，运行几个不同的展开。每个展开包含一个模拟版本的环境，智能体被赋予与在 Cursor 中相同的任务并尝试解决问题。基础设施挑战巨大——每个展开可能包含 20 万个 Token，调用数百个工具。对于每个问题要运行许多这样的展开。

结果中，有些展开更好（解决了问题），有些失败。我们找出好的展开让模型学习，坏的让模型远离。除了在基准上得分，我们还考虑行为特性，投入大量精力开发奖励来塑造用户体验。

其中一个有意思的是决定模型使用多少个 Token。我们探索了多种惩罚，最终确定了一个非线性长度惩罚（左下图）。想法是：惩罚短序列以促使模型更高效；如果问题容易，希望 Composer 2 高效解决然后继续。如果问题非常具有挑战性，希望花更多时间寻找正确答案，因此随着思考时间变长，惩罚会降低。

自我总结（Self-summarization）

为了鼓励模型解决非常长的问题，我们开发了一个系统：模型被允许工作超过其长度限制。例如，第一个例子运行了超过 200K 个 Token，达到触发点后要求模型总结到目前为止做了什么。将总结提供给智能体进行下一步，再次运行，可能再次总结，然后继续。在强化学习期间，这三个步骤被视为导致相同最终奖励的步骤。这训练模型有效应对无限长度，同时限制每个部分实际使用的长度。处理非常困难问题非常有效。

训练效果

运行强化学习时，通常训练时间越长，指标持续改善。图中有对数训练尺度，在许多问题上运行了许多步强化学习，准确率持续提高。学术文献中批评强化学习可能提高最佳性能但损害多样性，但在我们的方法中没有看到这种情况。考虑 16 次最佳的性能，也随着时间的推移而提高，说明模型没有过度集中在某一个特定解决方案上。

内部基准 CursorBench

我们的目标不仅仅是提高任意基准，而是在日常人们使用 Composer 的真实任务中表现良好。为此建立了内部评估体系，用于推动真实编程任务上的性能。目标是拥有更像软件工程师实践中实际做的事情的查询和面向目标的解决方案。

这是 CursorBench 项目的第三次迭代，包含了相当大量的解决方案，随着时间的推移变得更长、更难。左侧图表显示了每个示例的平均代码行数变化和涉及的文件数量。目标是保持未被污染、覆盖不同用例，并测试是否通过了测试（不仅限于通过测试）。我们使用了 Cursor 这里软件工程师的代码，来源于开发者实际提出的真实问题。

CursorBench 的特点

与一些著名的公开基准测试相比：

• 更长的代码差异：跨多个文件的百行更改，而非几行。
• 更短的问题描述：右侧图表显示平均问题描述长度（要求智能体做的事情）比其他基准测试短得多。起初看似缺点，因为规定更少。但我们认为这是优点——它更接近智能体在实践中必须解决的问题。解决歧义或猜测用户意图是模型核心工作。

例子

CursorBench 中的一个真实例子：底部问题陈述中，有些单词没有大写，有奇怪的标点符号，引用多个文件和多个日志。要求查看 DataDog 日志。在实践使用中，要求模型做非常困难的事情并期望它搞清楚是很常见的，但许多公开基准测试中看不到这类结构不良的问题。

CursorBench 比一些其他基准能更好地区分模型。例如，我们与认为非常好的模型（如 Opus 4.6）和认为不太好或来自上一代（如 Sonnet 4.5）的模型之间，结果差异要大得多。某些模型在 SWE-bench 上都得分很高，可能只是因为过去几年它们很好地针对了那种类型的问题。

使用 CursorBench 了解模型表现

从 Composer 1.5 到 Composer 2 的改进。还可以将其他大型实验室的模型绘制在这些性能图表上。我们发现在内部非常有帮助的一点是，不仅根据分数绘制图表，还要根据平均完成 Token 长度来绘制（实际使用了多少个 Token 找到答案）。对于 GPT 5.4 这样的模型，回答问题的能力基于它们使用的 Token 数量存在相当大的差异。图中可以看到模型的中等、高和极高版本，随着利用更多 Token 也在这些基准上有所改进。

未来

我们目前正在发布 Composer 2.5 的过程中。它会在不久的将来发布。也在构建扩展到更大训练集群的模型，使用 SpaceX 的集群训练 Composer 3 及未来的版本。编程模型非常出色，但还有很多工作要做。更大的预训练和更好的强化学习将继续提高性能。

短预览：Composer 2.5 将在终端命令得分以及其他类似基准测试上表现更强，这来自于优化强化学习过程和持续预训练过程。

Source

Video: Talk: Training Composer by @srush_nlp