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の100万基のH100相当の計算能力と、両社のデータおよび学習技術を組み合わせることで、これはモデル能力の大きな飛躍になると期待しています。

#Composer 2.5 の学習

Composer 2.5 には、学習基盤に関する複数の新たな改善が含まれています。これらの変更は、モデルの知能と使いやすさの両方の向上を目的としています。

#テキストによるフィードバックを使ったターゲット型RL

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

これに対処するため、私たちはComposer 2.5をターゲットを絞ったテキストフィードバックで学習しました。¹ 発想としては、モデルがより良く振る舞えたはずの軌跡上の箇所に、直接フィードバックを与えるというものです。対象となるモデルのメッセージに対して、望ましい改善点を説明する短いヒントを作成し、そのヒントを局所的なコンテキストに挿入したうえで、得られたモデル分布を教師として使います。元のコンテキストを使う方策を生徒とし、生徒のトークン確率を教師の確率へ近づける on-policy distillation の KL loss を追加します。これにより、変更したい挙動に対して局所的な学習シグナルを与えつつ、軌跡全体に対するより広い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でこれまで以上に慎重さが求められることを示しています。

#シャーディングされた Muon とデュアルメッシュ HSDP

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

主なコストは expert 重みの直交化です。シャーディングされたパラメータでは、同じ形状のテンソルをバッチ化し、all-to-all でシャードを完全な行列に再構成して Newton-Schulz を実行した後、結果をさらに all-to-all で元のシャーディング layout に戻します。これらの転送は非同期です。1 つのタスクが communication を待っている間にも、オプティマイザの runtime はほかの Muon タスクを進めるため、ネットワークと compute をオーバーラップできます。これはフル行列 Muon と同等ですが、シャードグループを常に稼働させられます。1T モデルでは、オプティマイザのステップ時間は 0.2 秒です。

これは、MoE モデルで HSDP をどう使うかとも密接に関係しています。HSDP は複数の FSDP レプリカを構成し、対応するシャード間で勾配を all-reduce します。non-expert 重みと expert 重みには、それぞれ別の HSDP layout を使います。non-expert 重みは比較的小さいため、FSDP グループは狭いままにでき、多くの場合は 1 ノードまたは 1 ラック内に収まります。一方、expert 重みはパラメータの大半と Muon の compute の大半を占めるため、より広い expert シャーディングメッシュを使います。

これらの layout を分離しておくことで、独立した並列性の次元を重ね合わせることもできます。たとえば、単一の共有メッシュでは 16 GPU が必要になるところを、CP=2 と EP=8 なら 8 GPU で実行できます。これにより、小さな non-expert 状態のために広域な communication を行わずに済み、同時に expert オプティマイザの処理を多数の GPU に分散できます。

#Composer 2.5を試す

Composer 2.5の価格は、入力トークン100万あたり$0.50、出力トークン100万あたり$2.50です。

また、同等の性能でより高速なバリアントもあり、価格は入力トークン100万あたり$3.00、出力トークン100万あたり$15.00です。他の最先端モデルの高速ティアよりも低コストで利用できます。Composer 2と同様に、fastがデフォルトのオプションです。詳細は、モデルのドキュメントをご覧ください。

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