性能直逼Claude Opus 4.7，价格仅为1/10！Cursor甩出史上最强模型Composer 2.5，X平台热度狂飙千万；内部几乎全员弃用旧模型！

就在今天凌晨，Cursor突发官宣，Composer 2.5正式上线，直言这是其史上最强模型，刚发布就引爆全网，X平台热度直接破千万了！

编辑 | 玉澄

出品 | 51CTO技术栈（微信号：blog51cto）

就在今天凌晨，Cursor突发官宣，Composer 2.5正式上线，直言这是其史上最强模型，刚发布就引爆全网，X平台热度直接破千万了！

图片

智能水平直逼Claude Opus 4.7，在SWE-Bench Multilingual等权威测试中得分几乎持平，甚至在部分场景反超，但价格却仅为前者的十分之一！

图片

图片

不止性价比能打，实力更是全面升级！相较Composer 2，它能更好地持续执行长时间且复杂的任务，不会轻易“迷失”或崩溃。

并且，改进后的模型能更精准地理解和执行复杂指令，协作体验更加流畅。

值得一提的是，最新这次格外坦诚，帖子中写到 Composer 2.5 和上一代一样，基于 Moonshot 的Kimi K2.5开源基础构建，没有藏着掖着（要知道上次因未披露底座还公开道歉过～）！

不过从最新给出的图表中可以看出，Composer 2.5 在强化学习（RL）方面确实非常出色。

图片

同时，最新宣布，Composer 2.5 在第一周会提供双倍用量。

Cursor内部几乎全员使用，马斯克力挺

X上还有 Cursor 团队内部成员爆料：上周内部测试时，几乎全员都抛弃旧模型，连续2天全程用Composer 2.5。他现在安利大家赶紧冲，讲真的很好用。

图片

此外，Composer 2.5 还有一特别之处，它的部分训练是在100 万个 H100 等效算力的 Colossus 2 上进行的。也难怪马斯克会激情转发，喊话大家快去试试。

图片

Cursor 的创始人 Michael Truell 也也亲自下场安利，还讲到这只是他们和SpaceX AI合作的开端。

图片

有网友立马反应过来，这是不是意味着 XAI 能够利用 Cursor 数据了？

图片

而马斯克在5月17日曾发文透露过，接下来会用Cursor的数据补充训练Grok V9。原来之前马斯克花重金收购Cursor的伏笔，全埋在这！

图片

而对于Cursor，和SpaceX AI的合作更是如虎添翼。他们已经开始从零打造更大型的模型，使用 10 倍的总计算资源，可以期待未来模型的能力还会迎来一次重大飞跃。

回到主题和当下，接下来让我们看看 Composer 2.5 究竟是如何训练的。

三大训练创新赋能：Composer 2.5 的定向 RL、25 倍合成任务与算力优化

在训练方面的创新主要是三方面，分别是使用文本反馈的针对性RL（Targeted RL with textual feedback）、合成任务数量是Composer 2的25倍与使用带分布式正交化的 Muon和双网格 HSDP。

局部精准纠偏，Composer 2.5 的 RL 训练创新

现在 AI 实际“跑一遍”任务的rollout可能要跨越数十万个 token。当一个 Agent（智能体）在完成一个长序列任务后，如何如何将奖励或惩罚正确地“归功”或“归咎”到序列中具体的每一步动作上，成为一个难题。即RL中的”信用分配“困难。

为了解决这一困难，Cursor用定向文本反馈训练了 Composer 2.5。核心思路是在轨迹中模型本可以表现得更好的位置，直接提供反馈。

具体的操作是：在模型表现不够完美的那一小段上下文里，插入一条简短的 Prompt，告诉它如何改进。有了这个 Prompt 的加持，模型瞬间开窍，变身为了更优秀的“教师模型”。而原来的模型则是“学生模型”通过加一个 on-policy 蒸馏KL损失，逼着学生模型的概率分布向教师模型的靠拢。

这样一来，既不耽误大模型为了整体 RL 目标而努力，又能针对它每一个局部行为进行精准纠偏。

在 Composer 2.5 的训练过程中，他们将这种方法应用于多种模型行为，从编码风格到模型和人类的沟通，全部进行了改进升级。

图片

25 倍合成任务，Composer 2.5竟会钻空子“作弊”

Composer 2.5 在强化学习的训练下，编程能力显著上涨，大多数训练问题已经难不到它了。为了继续提升它的智能，Cursor团队为它开启了一种”动态地筛选和生成更难任务“的模式。

Composer 2.5 所使用的合成任务数量是 Composer 2 的 25 倍。

他们采用了多种方法来创建基于真实代码库的合成任务。比如“功能删除”法，他们会拿来一个现成的、自带一堆测试题目的真实代码库，然后让 Agent 把某个特定功能的代码和文件删掉。删除之后，还要保证剩下的代码能跑通，而且测试程序能精准报错。最后让Composer 2.5把刚刚删掉的功能重新用代码实现出来。

但没有想到，Composer 2.5 开始钻空子作弊了，即奖励作弊（Reward Hacking）。比如，在做 Python 题目时，它不是重写函数，而是发现了残留的“类型检查缓存”（Cache）。它通过逆向工程，直接把被删掉的函数签名找回来。

他们借助 Agent 监控工具发现并诊断了这些问题，但这种事件也表明，在大规模 RL 中必须更加谨慎，不能被 AI 忽悠了。

图片

算力压榨到极致，8 个 GPU 干出 16 个的活

接下来是硬核的底层架构和算力压榨方面。

在持续预训练阶段，为了让模型更稳更强，他们使用了带分布式正交化的 Muon。

在形成动量更新后，他们会按照模型的自然粒度运行 Newton-Schulz：Muon 会顺着模型的自然结构来精细化管理，注意力投影按每个注意力头处理，堆叠的 MoE 权重则按每个专家处理。

但是专家的参数量实在是太大了，他们想出的办法是：对于分片参数，会将形状相同的张量成批处理，通过 all-to-all 将分片聚合成完整矩阵，运行 Newton-Schulz，然后再通过 all-to-all 将结果发回原始的分片布局。

这中间最绝的是“异步多线程”！当一个任务在等待通信时，优化器根本不闲着，转头就去帮其他 Muon 任务做计算，网络通信与计算重叠进行。结果是，哪怕是在1T（一万亿参数）模型上，优化器跑完这么复杂的一步也只需要0.2 秒。

这也与他们在 MoE 模型中使用 HSDP（混合分片数据并行） 的方式紧密相关。模型里有两种权重类别：“非专家”和“专家”。非专家权重相对较小，因此其 FSDP 组可以保持较窄，通常位于单个节点或机架内；而专家权重承载了大部分参数以及大部分 Muon 计算，因此使用更宽的专家分片网格。

更妙的是，他们还把不同的并行维度给“解耦”并重叠起来了。

比如CP=2（上下文并行）和EP=8（专家并行），按照以前的做法，可能需要占用 16 个 GPU，而现在在8 个 GPU上就能完美重叠运行！

这样既避免了小规模非专家状态上的大范围通信，也能将专家优化器工作分摊到更多 GPU 上。

精打细算、极限压榨，每一分算力都安排得明明白白。