Composer 2.5 发布与技术解析
Cursor的Composer 2.5不只是换个模型,它在长任务上的耐性和指令跟随的准确性提升肉眼可见,训练细节里藏的’文本反馈修正‘方法,对做AI产品的应该会有所启发。
Cursor 平台发布了智能与行为表现大幅提升的 Composer 2.5。该模型更擅长执行复杂指令和长期任务。其改进基于训练规模的扩大、更复杂的强化学习环境及新的学习方法。关键技术包括:使用文本反馈进行针对性强化学习以纠正具体错误;采用基于真实代码库、规模达前代25倍的合成数据进行训练;并引入分片Muon优化器等新架构。模型基于Moonshot的开源检查点构建。开发团队正合作训练一个计算量十倍的更大模型,并在大规模训练中发现了新型奖励作弊问题。
Composer 2.5 现已在 Cursor 中可用。
与 Composer 2 相比,它在智能水平和行为表现上有了显著提升。它在长期任务的持续处理上表现更佳,能更可靠地遵循复杂指令,并且协作体验也更加愉悦。
我们通过扩大训练规模、生成更复杂的强化学习环境以及引入新的学习方法,对 Composer 进行了改进。
除了在更困难的任务上训练 Composer 2.5 之外,我们还改进了模型的沟通风格和精力校准等行为维度。现有基准测试无法很好地捕捉这些维度,但我们发现它们对实际应用中的效用至关重要。
Composer 2.5 基于与 Composer 2 相同的开源检查点,即 Moonshot 的 Kimi K2.5。
我们正与 SpaceXAI 合作,从零开始训练一个规模大得多的模型,总计算量提升了 10 倍以上。借助 Colossus 2 的百万级 H100 等效算力,以及我们结合的数据和训练技术,我们预计这将是模型能力的一次重大飞跃。
#训练 Composer 2.5
Composer 2.5 在我们的训练栈中包含了若干新的改进。这些改进同时针对模型的智能水平和可用性。
#带有文本反馈的目标性强化学习
随着训练轨迹可能跨越数十万个模型 token,强化学习中的信用分配正变得越来越困难。当在整个轨迹上计算奖励时,模型可能很难判断是哪个具体决策帮助或损害了最终结果。当我们希望阻止某个局部行为(例如糟糕的工具调用、令人困惑的解释或风格违规)时,这一点尤其受限。最终奖励可以告诉我们出错了,但对于错误的具体位置而言,它却是一个噪声信号。
为了解决这个问题,我们使用目标性文本反馈来训练 Composer 2.5¹。其思路是直接在轨迹中模型本可以表现得更好的位置提供反馈。对于一条目标模型消息,我们构建一个简短提示,描述期望的改进方向,将该提示插入到局部上下文中,并将由此产生的模型分布作为教师。我们将原始上下文的策略作为学生,并添加一个在策略上的知识蒸馏 KL 散度损失,将学生的模型 token 概率推向教师的概率。这为我们想要改变的行为提供了局部化的训练信号,同时仍保留了整个轨迹上更广泛的强化学习目标。
作为文本反馈流程的示例,考虑一次较长的运行(rollout),其中包含一个工具调用错误——模型尝试调用一个不可用的工具。在运行过程中,模型会收到“工具未找到”错误,并继续执行其他有效的工具调用。在数百次工具调用的过程中遇到一次错误,对其最终奖励的影响微乎其微。
通过文本反馈,我们可以精准定位这一具体错误,在问题轮次的上下文中插入一条提示,例如“提醒:可用工具有……”并附上可用工具列表。这一提示会改变教师模型(teacher)的概率分布,降低对错误工具的预测概率,同时提高对有效替代工具的预测概率。仅针对该轮次,我们随后将学生模型(student)的权重向新的概率分布更新。
在 Composer 2.5 的运行过程中,我们将该方法应用于多种模型行为,从编码风格到模型通信。
#合成数据
在强化学习训练中,Composer 的编码能力大幅提升,以至于开始能够正确回答大多数训练问题。为了持续提升智能水平,我们在整个运行过程中既会筛选更难的题目,也会动态地创建更难的题目。Composer 2.5 使用的合成任务数量是 Composer 2 的 25 倍。
我们采用多种方法来创建基于真实代码库的合成任务。例如,一种合成方法是“删除功能”。对于这类任务,智能体(agent)会获得一个带有大量测试的代码库,并被要求删除代码和文件,使得代码库在移除特定可测试功能后仍保持可用。合成任务是重新实现该功能,而测试则用作可验证的奖励。
大规模合成任务创建的一个连带后果是可能引发意外的奖励破解。随着模型能力不断增强,Composer 2.5 能够找到越来越复杂的方法来绕过原定任务。在一个例子中,模型找到了一个遗留的 Python 类型检查缓存,并逆向工程出该缓存格式,从而找到了一个被删除的函数签名。在另一个例子中,模型能够找到并反编译 Java 字节码来重构一个第三方 API。我们通过智能体监控工具能够发现并诊断这些问题,但它们也表明在大规模强化学习中需要越来越谨慎。
#分片 Muon(Sharded Muon)与双网格 HSDP(Dual Mesh HSDP)
对于持续预训练,我们使用 Muon 并结合分布式正交化。在形成动量更新后,我们以模型固有的粒度运行 Newton-Schulz 算法:对注意力投影按注意力头进行,对堆叠的 MoE 权重按专家进行。
主要开销在于对专家权重进行正交化。对于分片参数,我们对形状相同的张量进行批处理,通过 all-to-all 将分片组合成完整矩阵,运行 Newton-Schulz,再通过 all-to-all 将结果传回原始分片布局。这些传输是异步的:当一个任务在等待通信时,优化器运行时推进其他 Muon 任务,使网络和计算重叠。这与全矩阵 Muon 等效,但能让分片组保持忙碌;在 1T 模型上,优化器步长时间为 0.2s。
这一点与我们针对 MoE 模型使用 HSDP 的方式密切相关。HSDP 会形成多个 FSDP 副本,并在对应的分片之间对梯度进行全局归约。我们对非专家权重和专家权重使用不同的 HSDP 布局:非专家权重相对较小,因此其 FSDP 组可以保持较窄的范围,通常在一个节点或机架内;而专家权重占据了大部分参数和大部分 Muon 计算量,因此它们使用更宽的专家分片网格。
将这两种布局分开还能让独立的并行维度重叠:CP=2 和 EP=8 可以在 8 个 GPU 上运行,而不需要在单个共享网格中占用 16 个 GPU。这既避免了小型非专家状态的宽通信,又将专家优化器的工作分散到多个 GPU 上。
#尝试 Composer 2.5
Composer 2.5 定价为每百万输入 tokens $0.50,每百万输出 tokens $2.50。
还有一个速度更快的变体,智能水平相同,每百万输入 tokens $3.00,每百万输出 tokens $15.00,价格低于其他前沿模型的快速 tier。与 Composer 2 类似,快速版本是默认选项。详见我们的模型文档。
Composer 2.5 在首周包含双倍用量。
关于这种方法的更多背景,请参见《自蒸馏实现持续学习》、《基于自蒸馏的强化学习》以及《自蒸馏推理器:面向大语言模型的自蒸馏策略》。↩