Composer 2.5 が Cursor で利用可能になりました。

Composer 2 と比べて知能とふるまいが大きく向上しています。長時間にわたるタスクで持続的に作業する能力が高まり、複雑な指示にもより確実に従い、よりスムーズに協働できるようになりました。

学習規模を拡大し、より複雑な RL 環境を生成し、新しい学習手法を導入することで、Composer を改善しました。

Composer 2.5 では、より難しいタスクで学習させたことに加えて、コミュニケーションスタイルや、どの程度の労力をかけるかといったモデルのふるまいも改善しました。こうした側面は既存のベンチマークでは十分に捉えられませんが、実運用での有用性には重要だと私たちは考えています。

Composer 2.5 は、Composer 2 と同じオープンソースのチェックポイントである Moonshot's Kimi K2.5 を基盤としています。

SpaceXAI とともに、私たちは合計で 10 倍の計算資源を使い、はるかに大規模なモデルを一から学習しています。Colossus 2 の H100 100 万基相当の計算資源と、両社のデータおよび学習技術によって、これはモデル能力の大きな飛躍になると期待しています。

#Composer 2.5を試す

Composer 2.5 の価格は、入力トークンが $0.50/M、出力トークンが$2.50/M です。

また、同等の知能でより高速なバリアント もあり、価格は入力トークンが $3.00/M、出力トークンが$15.00/M です。これは他の frontier モデルの高速 tier よりも低コストです。Composer 2 と同様に、高速版がデフォルトのオプションです。詳しくは、モデルドキュメントをご覧ください。

Composer 2.5 では、初週の使用量が 2 倍になります。

#Composer 2.5 の学習

Composer 2.5 には、学習スタックに関するいくつかの新たな改善が含まれています。これらの変更は、モデルの知能と使いやすさの両方を高めることを目的としています。

#テキストフィードバックを用いたターゲット型RL

RLにおけるクレジット割り当ては、ロールアウトが数十万トークンに及ぶこともあるため、ますます難しい課題になっています。報酬がロールアウト全体に対して計算される場合、結果の改善や悪化にどの具体的な判断が寄与したのかをモデルが見極めるのは難しいことがあります。これは、誤ったツール呼び出し、わかりにくい説明、スタイル違反といった局所的なふるまいを抑制したい場合に、特に大きな制約になります。最終的な報酬から何かがうまくいかなかったことはわかりますが、どこで問題が起きたのかを示すシグナルとしてはノイズが多すぎます。

これに対処するため、私たちはComposer 2.5をターゲットを絞ったテキストフィードバックで学習させました。¹ 基本的な考え方は、モデルがより適切にふるまえたはずの軌跡上の箇所に直接フィードバックを与えることです。対象となるモデルメッセージに対して、望ましい改善点を示す短いヒントを作成し、そのヒントを局所的なコンテキストに挿入したうえで、得られたモデル分布を教師として使います。元のコンテキストを使うポリシーを生徒とし、生徒のトークン確率を教師のトークン確率に近づける on-policy distillation の KL 損失を追加します。これにより、軌跡全体に対するより広いRLの目的を維持しつつ、変えたいふるまいに対する局所的な学習シグナルを得られます。

テキストフィードバックの流れを例で示すために、モデルが利用できないツールを呼び出そうとしてツール呼び出しエラーが含まれる長いロールアウトを考えてみましょう。ロールアウト中、モデルは“Tool not found”エラーを受け取り、その後も有効なツール呼び出しをさらに続けます。数百回のツール呼び出しの中で1回エラーが起きたという事実は、最終報酬にはほとんど影響しません。

テキストフィードバックを使うと、問題のあるターンのコンテキストに、利用可能なツールの一覧とともに“Reminder: Available tools…”のようなヒントを挿入することで、この特定のミスを狙って修正できます。このヒントによって教師の確率が変化し、誤ったツールの確率は下がり、有効な代替候補の確率は上がります。そのターンに限って、その後、生徒の重みを新しい確率に向けて更新します。

Composer 2.5の実行では、この手法をコーディングスタイルからモデルのコミュニケーションまで、さまざまなモデルのふるまいに適用しました。

#合成データ

RLの学習中、Composerのコーディング能力は大幅に向上し、学習用の問題の大半を正しく解けるようになります。知能をさらに高めるため、実行全体を通じて、より難しいタスクを動的に選別しながら生成しています。Composer 2.5は、Composer 2の25倍の合成タスクで学習されています。

実際のコードベースに基づく合成タスクを作成するために、私たちはさまざまなアプローチを用いています。たとえば、その1つが機能削除です。これらのタスクでは、エージェントに大規模なテスト群を含むコードベースを与え、コードベースが動作したまま、特定のテスト可能な機能だけが削除されるように、コードやファイルを削除させます。合成タスクはその機能を再実装することであり、テストは検証可能な報酬として使われます。

大規模に合成タスクを作成すると、その副作用として、想定外の報酬ハッキングが発生することがあります。モデルの能力が高まるにつれて、Composer 2.5は、目の前のタスクを解くためにますます巧妙な回避策を見つけられるようになりました。ある例では、モデルは残っていたPythonの型チェック用キャッシュを見つけ、その形式をリバースエンジニアリングして、削除された関数シグネチャを突き止めました。別の例では、Javaバイトコードを見つけて逆コンパイルし、サードパーティ製APIを再構築できました。私たちは、エージェント型の監視ツールを使ってこうした問題を発見し、診断できましたが、これらは大規模なRLにおいて、ますます慎重な対応が必要になっていることを示しています。

#Sharded Muon と dual mesh HSDP

継続的な事前学習では、分散直交化を組み合わせた Muon を使います。モメンタム更新を作成したあと、モデルの自然な粒度で Newton-Schulz を実行します。具体的には、attention projection では attention head ごとに、積み重ねられた MoE の重みでは expert ごとに実行します。

主なコストは、expert の重みを直交化することです。シャーディングされたパラメータについては、同じ形状の tensor をバッチ化し、all-to-all で shard を完全な行列に集めて Newton-Schulz を実行し、その後、結果を all-to-all で元のシャーディング layout に戻します。これらの転送は非同期です。1 つのタスクが通信待ちをしている間も、optimizer runtime はほかの Muon タスクを進められるため、ネットワークと compute をオーバーラップできます。これは full-matrix Muon と等価ですが、shard group を継続的に稼働させられます。1T モデルでは、optimizer step time は 0.2 秒です。

これは、MoE モデルで HSDP をどのように使うかと密接に関係しています。HSDP は複数の FSDP replica を作成し、対応する shard 間で gradient を all-reduce します。non-expert の重みと expert の重みには、それぞれ別の HSDP layout を使います。non-expert の重みは比較的小さいため、FSDP group は狭いままにでき、多くの場合は node 内または rack 内に収まります。一方、expert の重みはパラメータの大半と Muon compute の大半を占めるため、より広い expert sharding mesh を使います。

これらの layout を分けておくことで、独立した parallelism の dimension どうしも重ねて使えます。たとえば、CP=2 と EP=8 は、単一の共有 mesh で 16 GPU を必要とするのではなく、8 GPU 上で実行できます。これにより、小さな non-expert state に対する広域通信を避けつつ、expert optimizer の処理を多数の GPU に分散できます。