Composer 2 技術報告書
Cursor 研究チーム
1 はじめに
Composer 2 は、エージェント型ソフトウェアエンジニアリングのために設計された専門モデルです。このモデルは、対話的な使用のために問題を効率的に解決する能力を維持しつつ、強力な長期的計画性とコーディング知能を実証しています。このモデルは、実世界のソフトウェアエンジニアリングに関する当社のベンチマークである CursorBench において高いスコアを記録し（図 1 参照）、SWE-bench Multilingual [28] や Terminal-Bench [39] などの公開ソフトウェアエンジニアリングベンチマークでも最先端レベルのスコアを達成しています。
このモデルのトレーニングは 2 段階で実施されます。第 1 段階は、モデルの知識と潜在的なコーディング能力を向上させるための継続的プレトレーニングです。その後、第 2 段階として、より強力な推論、正確なマルチステップ実、および長期的な現実的なコーディング問題における一貫性を通じて、エンドツーエンドのコーディングパフォーマンスを向上させるための大規模強化学習が行われます。
Composer トレーニングの中核的な原則は、トレーニングとテストのミスマッチを最小限に抑えるため、実世界のユーザー課題を可能な限り正確に模倣することです。そのために、展開済みモデルと同じ Cursor ハーネスを使用してトレーニングを行うインフラストラクチャを開発し、同等のツールと構造、そして実問題に密接に一致する環境を活用しています。モデルが徐々に困難なタスクに対してどの程度の能力を持つかを測定するため、大規模コードベース（当社独自のコードベースを含む）における実際のソフトウェアエンジニアリング問題から派生したベンチマークを導入しました。
Composer 2 は最先端レベルのコーディングモデルであり、強力なドメイン特化型モデルをトレーニングするためのプロセスを実証しています。CursorBench 評価において、このモデルは以前の Composer モデルと比較して精度が大幅に向上しました（61.3）。公開ベンチマークでは、当社のハーネスにおいて Terminal-Bench で 61.7、SWE-bench Multilingual で 73.7 を記録し、最先端システムに匹敵する性能を示しています。
CursorBench パフォーマンス
図 1: Composer 2 は以前の Composer モデルから大幅に改善され、最先端モデルと競合するパフォーマンスを達成しています。コーディング能力に完全に特化することで、Composer は最先端モデル API の価格設定よりも低コストで提供しながら、このようなパフォーマンスを実現しています。詳細な評価についてはセクション 5 をご覧ください。
2 背景および関連研究
コード生成は、大規模言語モデルの注目すべき応用分野となっています [15, 9, 7, 31]。コードは、ほとんどの大規模モデルにおいて言語データを補完する挑戦的なトレーニングデータの豊富な情報源を提供しています [16, 30, 36, 51, 19, 10, 5, 44, 25, 71, 72, 62, 41]。コード生成の初期の応用は、主に自動補完アプリケーションに焦点を当てていました。その後、指示チューニングにより、モデルはユーザーの要求に応答できるコーディングアシスタントへと進化しました [37, 73, 83, 43]。過去 1 年間で、ソフトウェアエンジニアリングエージェントが広く採用されるようになり、モデルをチャットから一歩進め、リポジトリを自律的にナビゲートし、複雑なエンジニアリングタスクを解決する能力を獲得しました [75, 76, 70, 49, 23]。
ソフトウェアエンジニアリングエージェントは、与えられたタスクプロンプトを自律的に解決することを目指します。環境（コードベースとコード実行用の分離されたコンテナ）と、エージェントにタスクを与えるプロンプト x が与えられた場合、エージェントは一連のアクション a1, ..., aT からなるロールアウトを生成し、それぞれが 1 つ以上のツール呼び出しを行い、応答 y1, ..., yT を生成します。ツール呼び出しは基礎となる環境を変更する可能性があり、ロールアウトの結果はこの環境の最終状態です。各アクション ai は、言語モデル方策 πθ(ai | x, a1, y1, ..., ai-1, yi-1) からサンプリングして選択され、その後、コードの正しさ、簡潔さ、およびソフトウェアエンジニアリングの原則への準拠に基づいて報酬が与えられます。競技プログラミングのような制約された設定とは対照的に、強力なソフトウェアエンジニアリングエージェントは、重要度の高い探索を実行し、独自のテストを作成し、タスクプロンプトを解決するために必要な最小限の変更を構築する必要があります。
Composer 2 は、ファイルの読み取りと編集、シェルコマンドの実行、grep またはセマンティック検索を使用したコードベースの検索、Web 検索を可能にする少数の汎用ツールにアクセスできます。そのプロンプトには、システムメッセージ、ツール呼び出し形式の仕様、最近のファイル情報、過去のユーザーメッセージ、現在のタスクが含まれます。このプロセスの最も一般的な結果は、コードベース環境内のファイルへの変更セットですが、質問への回答、計画の作成、バージョン管理の問題の解決、長時間実行ジョブの監視など、他の多くの一般的な使用事例もあります。
Composer 2 に関する当社の主な研究の方向性は、モデルトレーニングのスケールアップが、いかにして実世界のコーディングにおけるパフォーマンスを確実に向上させるかを調査することです。これには、継続的プレトレーニング（セクション 3）と非同期強化学習（セクション 4）という 2 つの異なるトレーニングフェーズを通じて取り組んでいます。進捗状況を測定するため、一連の挑戦的なベンチマークを構築しました（セクション 5）。
3 継続的プレトレーニング
継続的プレトレーニング段階の目的は、特にコーディングのドメインにおいて、言語モデルの基礎知識を向上させることです。このような継続的プレトレーニングは、下流のパフォーマンスを劇的に向上させることが長年実証されています [20, 24]。これをさらに一歩進め、最近のモデルは段階的トレーニングアプローチを使用し、より高品質なデータへと徐々にフィルタリングしています [22, 69, 77]。大量のコードデータで自然にトレーニングされたベースモデルから始めますが、追加の教師あり学習が知識ベンチマークを確実に向上させ、最終的なコーディングエージェントのコーディングパフォーマンスの向上につながることがわかりました。
ベースモデルの選択には、内部評価と推論パフォーマンスの考慮事項を使用しました。評価では、内部コードベースのパープレキシティ、コーディング知識、状態追跡を測定します。詳細は付録 B をご覧ください。これらの評価により、Kimi K2.5 [67]（1.04T パラメータ/32B アクティブパラメータのエキスパート混合モデル）を Composer 2 のベースモデルとして選択しました。
3.1 トレーニング
Kimi K2.5 を、コードが支配的な大規模データミックスでの継続的プレトレーニング段階に拡張しました。この段階の目的は、モデルをコーディング知識と機能に特化させることで、その後のエージェント RL トレーニングのためのベースモデルを提供することです。この段階は 3 つのフェーズに分かれています。計算リソースの大部分は 32k トークンシーケンス長で費やし、次に 256k シーケンス長へのより短い長文脈拡張フェーズ、最後にターゲットを絞ったコーディングタスクでの短い SFT フェーズを実施します。トレーニングは、NVIDIA B300 上で MXFP8 を使用し、AdamW オプティマイザで実行されました。詳細なトレーニング内容についてはセクション 6.1 をご覧ください。トレーニング中、内部コードベースでの評価損失を測定しました。その結果、損失はトレーニング実行を通じて対数線形に減少することがわかりました。
継続的プレトレーニングは、最終的に下流の RL パフォーマンスを向上させることを目的としており、これら 2 つの段階の関係は活発に研究されている分野です。コードベースのパープレキシティと RL パフォーマンスの関係を、Qwen3-Coder-30B-A3B [68] に対する継続的プレトレーニングレシピの適用によって調査しました。継続的プレトレーニングは、対数的に間隔を空けた 3 つの計算レベル（小、中、大）で実施されます。これらの各チェックポイントは、小さなデータセットでの SFT を経て、同一の RL 実行にかけられます。図 2（左）は、SFT 後の最終損失と固定ステップ数後の RL 報酬の関係を示しており、交差エントロピー損失が実際に下流の RL パフォーマンスを予測することを示しています。
図 2: 継続的プレトレーニングは下流の RL パフォーマンスに変換されます。左：より小さな Qwen モデルでこの関係を調査し、異なるトークン数でトレーニングされたチェックポイントを調べました。右：モデルはトレーニングパープレキシティの着実な減少を経験します。
マルチトークン予測：本番環境でモデルをより高速に提供するため、投機的デコードで使用するための追加のマルチトークン予測（MTP）レイヤー [17, 11] をトレーニングします。MTP レイヤーは一から初期化し、同一のデータミックスでトレーニングします。収束を高速化するため、MTP レイヤーに自己蒸留を適用し、各位置でメイン LM ヘッドの正確なロジット分布を予測するようにモデルを教えます。このプロセスが一般化されることを確認するため、MTP レイヤーは継続的プレトレーニング実行の中間から切り出されたチェックポイント上でトレーニングされます。最終的な 2 つのフェーズ（長文脈と SFT）では、MTP レイヤーが含まれ、モデルの残りとともに共同でトレーニングされます。
4 強化学習
Composer 2 は、大規模なコーディングタスクセットに対する強化学習によってトレーニングされます。これらのタスクは、実際の Cursor セッションを可能な限り正確に模倣する環境で実行されます（インフラの詳細についてはセクション 6.2 を参照）。大まかに言うと、RL トレーニングは、問題をサンプリングし、異なるソリューションを持つエージェントからのロールアウトのグループをシミュレーションし、ソリューションの品質に基づいてモデルの重みを更新することで構成されます。
最も一般的な使用事例を反映する問題分布を作成しました。図 3 は、タスクカテゴリの内訳を示しています。注目すべきことに、当社のトレーニング分布は、一般的な AI コーディングベンチマークには存在しないソフトウェアエンジニアリングの多くの側面を捉えています。
図 3: RL トレーニングタスク。
トレーニングの後期段階では、より困難なデータポイントをより頻繁にサンプリングするため、ロールアウトのターン数や思考トークン数などの単純なヒューリスティックを使用してアップサンプリングを行います。
4.1 非同期 RL トレーニング
当社の強化学習パイプラインは、安定性を維持しながら大規模な方策勾配から学習することを中心に構築されています。プロンプトあたりの複数サンプル [53, 2] と固定グループサイズを持つ方策勾配アルゴリズムを使用します。シングルエポック体制、つまり同じプロンプトが 2 回トレーニングされることのない体制で運用します。基礎となるオプティマイザとして Adam を使用し、完全なパラメータセットを更新します。RL トレーニングは、独立したトレーニングおよびロールアウト生成ワーカーを持つ高度に非同期の体制で動作します（詳細はセクション 6.2 を参照）。
これまでにもいくつかの方策勾配バリアントが提案されています [78, 82, 40, 34]。Dr. GRPO [34] と同様に、基礎となるアドバンテージの変換から生じる可能性のある勾配のバイアスを最小限に抑えることが重要であることがわかりました。この研究に従い、長さバイアスを導入するため、GRPO から長さ標準化項を削除しました。また、すべてのロールアウトが同等の正しさを達成するグループ内で行動のわずかな差異が過度に重み付けされる退化的なケースを招くため、グループアドバンテージを標準偏差で正規化しません。
Yu ら [78] は、最大シーケンス長を超えるロールアウトをマスクアウトすることを提案しました。その後、いくつかの研究がこのマスキングを採用しました [35, 18] が、他の研究では結果がまちまちであることがわかりました。例えば、Liu ら [34] は、過長マスキングがロングテールの推論タスクでは限定的な効果しか示さない一方、中程度および短長の推論タスクでは応答の精度と明瞭さを向上させることを発見し、Du ら [13] は過長マスキングにより出力長が急速に成長しすぎることを発見しました。当社は小規模では過長マスキングの利点を確認できず、最大シーケンス長を超えるロールアウトをマスキングしないことを選択しました。後述する当社の自己要約システムも、実際にはこれらのケースの発生を制限します。
エージェントのロールアウトは、特に長期的な一貫性を目的とする場合、非常に長くなる可能性があるため、高度に非同期の体制でシステムが安定性を維持することが重要です。当社の主な戦略は、サンプルがどれだけ方策外になるかを最小限に抑えることです。インフラストラクチャの面では、PipelineRL [48] と同様に、高速な重み同期と飛行中の重み更新によってこの発散を軽減します。推論ワーカーはロールアウト中に重みを更新できるため、ロールアウトの後半のトークンは方策外になる可能性が低くなります。サンプリングとトレーニングの方策のさらなる発散を減らすため、MoE ルーティング [38] をリプレイします。非同期 RL パイプラインの実装についてはセクション 6.2 で説明します。
先行研究 [53, 66] と同様に、正則化のためにカルバック・ライブラー発散を使用します。KL(q∥p) = Ex∼q[-log r(x)]、r(x) = p(x)/q(x)。RL の多くのオープンソース実装では、Schulman [52] で定義された推定量 k3 = (r-1)-log r を使用して KL を推定します。k3 推定量は KL の不偏推定量であり、p と q が近い場合に分散を低減します。しかし、Amini ら [6, 図 1] は、p と q が乖離するにつれて分散が劇的に増加することを示しています。図 4 をご覧ください。大きな KL 値の場合、推定値の分散は非常に大きくなります。（k2 推定量は分散の爆発に悩まされませんが、バイアスがあります。）したがって、当社は標準の推定量 k1 = -log r を使用します。
図 4: 単位分散と異なる平均を持つ 2 つの合成ガウス分布に対する KL(p∥q) 推定量の比較。
最近の文献の増えつつある研究は、LLM に対する RL は、多くの場合、方策のエントロピーと出力の多様性を犠牲にしながら、すでに知られている成功した軌道に確率質量を集中させることで平均パフォーマンスを向上させると主張しています [79, 32, 8, 74, 61]。この見解によると、ベストオブ K の改善は、到達可能な正解の集合を拡大するのではなく、モデルが 1 つの高信頼度ソリューションを選択するのが上手くなることに限られる可能性があります。
図 5: 平均パフォーマンスとベストオブ K パフォーマンスの両方が RL トレーニング期間中に向上します。上記の曲線は、保持された評価セットと CursorBench タスクで報告されています。パフォーマンスは RL トレーニングを通じて着実に向上します。重要なのは、平均パフォーマンスとベストオブ K パフォーマンスの間にトレードオフが見られないことです。
この背景に対し、当社の結果は注目に値します。平均報酬が上昇する一方でベストオブ K が横ばいになるというトレードオフを観察するのではなく、図 5 に示すように、当社のトレーニングは両方の統計量を向上させることがわかりました。これは、当社の設定では、RL が単に固定された推論パスのプールを再重み付けしているだけでなく、繰り返しサンプリングする際の正解ソリューションに対するモデルの実効的な適用範囲も向上させていることを示唆しています。
自己要約：Composer 2 が長期的なタスクで動作できるようにするため、Composer 1.5 [64] で導入された自己要約技術を使用します。各トレーニングロールアウトは、単一のプロンプト - 応答ペアではなく、要約によって連鎖された複数の生成を含むことができます。チェーン内でモデルによって生成されたすべてのトークンに最終報酬を使用します。これにより、良好な軌道におけるエージェント応答と、それを機能させた自己要約の両方の重み付けが高まります。同時に、重要な情報を見失う不十分な要約は重み付けが低くなります。Composer がトレーニングされるにつれて、限られたコンテキストウィンドウであっても、より多くの情報を処理するために自己要約を使用することを学習します。困難な例では、複数回自己要約することがよくあります。実験により、自己要約は、別個のプロンプトベースの圧縮を使用する場合と比較して、著しく少ないトークンを使用し、KV キャッシュを再利用しながら、一貫してエラーを低減することがわかりました。
4.2 エージェントの動作
RL トレーニングの主な目的がモデルの知能を向上させることである一方で、開発者にとって良好なエクスペリエンスを提供するモデルを生み出すことも目指しています。これは、モデルのコミュニケーションスタイルと、質問に答えるのにかかる時間とリソースに影響されます。
動作とコミュニケーションについては、モデルが良好なエクスペリエンスを提供することを保証するため、コーディングスタイル、コミュニケーション、および ToDo リスト項目を作成した後に未完了のままにするなどの不十分なツール呼び出しに対する製品固有のペナルティを含む、さまざまな補助報酬を適用します。RL トレーニング中、モデルの創発的な動作を監視し、必要に応じて追加の動作報酬を随時導入します。例えば、モデルがコメント内に長い思考連鎖を残し始めたり、ターミナルツールの使用のみに収束したりする傾向があることを観察しました。
簡単な要求に対しては迅速にソリューションを生成し、困難な要求に対してはより長く考えることをモデルに促すため、報酬に凹型で増加する非線形長さペナルティを追加します。
図 6: 非線形ペナルティにより、モデルは簡単なタスクでは迅速に、困難なタスクではより深く考えるようになります。
ここで、k と q はペナルティの曲率を定義するハイパーパラメータであり、入力 x は、思考トークン、ツール呼び出しトークン、ツール出力トークン、最終メッセージトークン、ツール呼び出し数、およびロールアウトのターン数の重み付き組み合わせです。この非線形性は、数回のツール呼び出しで達成可能な簡単なタスクでは、追加の努力のすべてがより鋭く感じられる一方、数百回のツール呼び出しを繰り返す可能性のある長期的なタスクではそうではないことを反映しています。この式によって生成される非線形曲線の例については図 6 をご覧ください。このような長さペナルティを使用することで、モデルが特に効率的な動作（例：複数のツール呼び出しを並列で実行する）を学習できることがわかりました。
図 7: 公開ベンチマークと比較して、CursorBench タスクはタスクプロンプトの指定が少なく、コード変更量が 1 桁多くなります。これは、実世界のソフトウェアエンジニアリングの要求の複雑さと曖昧さをよりよく表していることがわかります。
5 CursorBench による実世界評価
コーディングエージェントの応用は、この 1 年で急速に進化し、単純で範囲が限定された編集から、複雑なデバッグ、大規模なリファクタリング、機能開発へと拡大しました。Cursor において、公開評価ベンチマークでのパフォーマンスが、これらのモデルの実世界での有用性と緩やかにしか相関しないことがよくあります。この不一致は、主に 4 つの要因に起因すると考えています。
ドメインのミスマッチ：コーディングエージェントの能力が拡大するにつれ、静的なベンチマークは開発者のワークフローの全範囲を捉えきれないことがよくあります。例えば、SWE-bench とそのバリアントは主に分離されたバグ修正に焦点を当てています。Terminal-Bench はより広範なタスクタイプをカバーしていますが、そのタスクの多く（例：チェスの手を計算する）は、典型的なソフトウェアエンジニアリングの運用ではなく、抽象的なパズルです。
プロンプトの過度な具体化：公開ベンチマークは通常、非常に具体的で、限られた数の正解を想定しています。対照的に、実際の開発者の要求はしばしば具体性が低く、複数の有効なアーキテクチャアプローチを許容します。その結果、公開ベンチマークは正解の代替ソリューションをペナルティ化するか、意図の曖昧さを解釈するという課題を回避する不自然に明示的なプロンプトに依存するかのどちらかになります。
データ汚染と過学習：公開ベンチマークはオープンソースリポジトリの歴史的なスクレイピングから構築されているため、モデルのトレーニングミックスに頻繁に漏洩し、スコアを人為的に水増しします。最近、OpenAI は、最先端モデルがメモリからゴールドパッチを生成できるという証拠を発見した後、SWE-bench Verified 結果の報告を停止しました [1]。汚染に加えて、これらのベンチマークの固定され狭い性質はパフォーマンスの差を圧縮する可能性があります。例えば、Haiku 4.5 は SWE-bench Verified で 73.3% を達成し、GPT-5 の 74.9% に非常に近く、Terminal-Bench などのより広範で多様なタスク分布での精度と一致していません。
狭い評価範囲：既存のコーディング評価は、主に機能の正しさを測定します。実際には、開発者はコードの品質、可読性、レイテンシ、コスト、およびセッション中のエージェントの対話動作の品質も重視します。
これらの制限に対処するため、当社のエンジニアリングチームの実際のコーディングセッションから抽出されたタスクで構成される内部評価スイートである CursorBench を導入します。これらのタスクは、厳選された公開リポジトリではなく、実際のエージェントセッションに由来しているため、CursorBench はソフトウェアエンジニアリングタスクの真の分布をよりよく反映し、トレーニングセットの汚染を完全に回避します。さらに、機能の正確さのみに依存するのではなく、コード品質、実効効率、および現実的な設定での対話型エージェント動作を対象とした特定の指標を使用してモデルを評価します。
図 7 は、CursorBench と公開評価セットの構造的な違いを強調しています。CursorBench タスクは、SWE-bench Verified および Multilingual の 7〜10 行に対して中央値 181 行の変更という、はるかに広範なコード変更を必要とします（図 7a）。同時に、CursorBench プロンプトはより具体性が低く、公開ベンチマークの 1,185〜3,055 文字に対して中央値 390 文字の記述長しか持ちません（図 7b）。この広範な実行範囲と高い意図の曖昧さの組み合わせは、開発者がソリューションを導き出すために本番ログ、まばらなユーザーバグレポート、および既存の大規模コードベースからコンテキストを頻繁に統合する必要がある実世界のソフトウェアエンジニアリングの本質的な困難さを正確に反映しています。図 8 および図 12 は代表的な例を示しています。1 つは簡潔なバグレポートと可観測性ログからのリトライループ内のビルドツール変換バグの診断を必要とし、もう 1 つは、微妙なストリーミング回帰を定量化し、その隠れた不変性を発見するために、数百のチャット応答から調整されたヒューリスティック検出器を設計することを求めています。
新しい CursorBench のイテレーションは、当社のチームによって継続的に開発されています。ユーザーのワークフローが進化し、エージェントの能力が向上するにつれ、開発者が実際に製品をどのように使用しているかに整合した状態を維持するため、評価セットを定期的に更新します。図 9 は、ベンチマークがイテレーションを通じてどのように複雑さを増してきたかを示しています。初期バージョンの CursorBench と比較して、CursorBench-3 のタスクは、平均して 2 倍以上のファイル数とコード行数の変更を必要とします。
図 9: CursorBench のイテレーションごとの進化。各バージョンはより複雑な要求を組み込んでいます。CursorBench-3 は初期バージョンから中央値タスクサイズを 2 倍以上にしています。
問題規模の増大に加えて、タスクタイプの分布も変化しており、開発者は長時間実行されるコマンドの実行、実験の監視、データ分析をエージェントにますます委任するようになっています。この継続的な更新により、当社の評価が実世界の困難さの最先端のフロンティアに整合した状態を維持し、飽和しないことが保証されます。
最後に、主要な CursorBench 評価を補完するため、コーディングエージェントの品質と動作の他の側面をカバーする一連のターゲット評価を実施します。これらには、曖昧なプロンプトをモデルがどのように処理するかを評価する意図評価、システムプロンプト、ユーザープロンプト、ルール、スキルにモデルがどの程度従うかを測定する指示フォロー評価、コード編集を避けるべき質問にモデルがどのように応答するかをテストする熱心な編集評価、コードとコメントの両方の品質を判断するコード品質評価、およびロールアウト中の割り込みとユーザーフィードバックをモデルがどの程度うまく処理するかを定量化する割り込み評価が含まれます。これらの評価は、エージェント動作の重要な次元を特定し、それらを引き出すデータポイントを選択し、パフォーマンスを測定するための評価基準を作成することで開発しています。
6 インフラストラクチャ
6.1 トレーニングインフラストラクチャ
並列処理：以前の Composer トレーニングスタックは、完全シャードデータ並列処理（FSDP）[50, 81]、エキスパート並列処理（EP）[54, 14]、テンソル並列処理（TP）[55] を組み合わせていました。元の MoE 設計では、EP は TP と同じランクグループを共有していたため、EP は独立したスケーリング軸ではありませんでした。この結合により実装は単純化されましたが、より大規模な MoE 構成のサポートが制限され、活性化メモリの圧力が控えめな場合でも継続的プレトレーニング段階で活性化シャードが不要に有効になっていました。
代わりに Composer 2 は、主な長文脈スケーリング軸としてコンテキスト並列処理（CP）[33, 26] を使用します。CP は TP よりも通信が少なくて済み、さまざまな投影で完全な隠れ次元を維持することで計算効率を向上させます。対照的に、TP は非効率な細いローカル行列乗算を生成します。Multi-Head Latent Attention（MLA）アーキテクチャで CP を効率的に実装するためにいくつかのトリックを使用しています。通信オーバーヘッドを最小限に抑えるため、ローカル KV 潜在ベクトルを計算し、CP ランク間で潜在ベクトルをオールギャザーし、その後 KV 投影を計算します。これはすべての CP ランクで投影を複製しますが、投影は小さく、CP 通信を削減し、Q 投影の計算と CP 通信を完全にオーバーラップさせることを可能にします。さらに、単純な CP は因果的注意の際に負荷の不均衡を引き起こしますが（後のトークンはより多くのトークンに注意する必要があるため）、この問題に対処するために Liu ら [33] の技術を使用します。シーケンスを 2 × CP チャンクに分割し、i 番目のランクがチャンク i と 2 × CP - 1 - i を処理することで、すべてのランクで因果的注意中の作業がほぼ均等になります。最後に、コンテキスト並列処理次元は FSDP 次元に折りたたまれ、CP ランクを使用して GPU あたりのパラメータ/状態メモリ使用量を削減できます。
図 10: 当社の Mixture-of-Experts レイヤー内の単一のグループ化 GEMM トレーニングフローの概要。各色付きブロックは単一のカーネル起動を表します。
Composer 2 はまた、EP を TP から分離することにより、より柔軟なエキスパート並列設計を導入します。これには、密層とエキスパート重みのシャード化に異なるメッシュを使用する必要があります。EP は DP と CP 容量から形成され、より大規模なエキスパート並列次数のサポートを可能にし、ランクあたりのトークンバッチが大きい場合のエキスパートグループ化 GEMM をより効率的にします。当社は、継続的プレトレーニング段階では EP=8、CP=2 を、RL 段階では EP=8、CP=8 を使用します。高スループットのトークンディスパッチ/結合を実装するために DeepEP [80] を使用します。DeepEP 通信バッファは比較的低いオーバーヘッドを持ち、DeepEP カーネルはデフォルトで 20 SM を使用し、並列計算のための余裕を残します。また、より効率的な通信のため、ディスパッチ前にトークンを MXFP8（後述）に量子化します。これは、エキスパート計算をすでに MXFP8 で実行しているため、精度に影響しません。結合は精度向上のため BF16 で維持します。計算と通信のオーバーラップを最大化するため、トークンはマイクロバッチに分割され、別々の通信ストリームと計算ストリームでパイプライン処理されます。
最後に、高い利用率を達成するために、異なる DP ランクが同量の計算を持つことが重要であることがわかりました。継続的プレトレーニングでは、固定シーケンス長で DP バランスを容易に達成できます。RL では、異なるプロンプトの異なるロールアウトによりシーケンス長が非常に異なる可能性があるため、各トレーニングステップの前にグローバルなシーケンスパッキング段階を実行し、バランスの取れた DP 計算負荷を確保します。パッキングアルゴリズムは、より長いシーケンスの注意コストの増加を考慮します。
カーネル：Composer 2 トレーニングでは、CUDA、PTX、ThunderKittens/ParallelKittens [56, 59] で記述された社製カーネルを使用します。これらのカーネルは主に、エキスパート混合（MoE）レイヤーの低精度トレーニングを最適化します。当社のトレーニンクレシピでは、MXFP8 [46] と NVFP4 [45] の両方の精度形式を使用します。NVIDIA Blackwell GPU をブロックスケールテンソルコア行列乗算（つまり、シストリックアレイ行列乗算中のハードウェア内逆量子化）のために専ら対象としています。図 10 は、当社の MoE レイヤー内の単一のグループ化 GEMM トレーニングフローを示しています。
MoE フォワードパスには、NVFP4 の新しいバリアントを使用します。値は、FP8E4M3 ブロックスケール（ブロックサイズ = 16）と FP32 トークンあたりスケールを使用して、BF16 から FP4E2M1 へ量子化されます。FP32 テンソルあたりスケールを使用する元の NVFP4 形式は、2 つの理由で不安定であることがわかりました。第 1 に、テンソルあたりのスケーリングはトレーニングをバッチ依存にし、数値精度を低下させて RL トレーニングを発散させます。第 2 に、トークン間のスケール値は、過去のトークンに将来のトークン情報を漏洩させ、バイアスされた勾配を生み出します。量子化と GEMM エピローグにレイテンシを追加するにもかかわらず、トークンあたりのスケーリングがより効果的な方式であることが証明されました。
MoE バックワードパスには、32 要素ブロックあたり FP8E4M3 値と FP8E8M0 スケールを持つ標準の MXFP8 形式を使用します。これは、RL トレーニングの非対称性により可能です。フォワードパスでは、数値的安定性のため、トレーナーが推論に一致することが必要です。したがって、高速推論をサポートするためにトレーナー NVFP4 を使用します。ただし、バックワードパスはトレーニングクラスタでのみ実行されます。これはシステム全体の RL 効率のボトルネックではないため、トレーニングの安定性を向上させるためにより高い精度を使用できます。
最後に、ハードウェアレベルの数学精度の選択は非常に重要でした。NVFP4 量子化では、IEEE 準拠の浮動小数点演算（例：__fdiv_rn）を使用することが重要であることがわかりました。高速近似代替を使用すると、約 100 の RL ステップ後にトレーニングが発散します。対照的に、MXFP8 量子化に高速近似パス（例：__fdividef）を使用しても、Composer 1 の初期トレーニング以降、発散は発生していないため、最高のパフォーマンスのためにこれを選択しています。
当社はカーネル実装を積極的にオープンソース化し、GPU カーネルエコシステムを改善するためのコミュニティの取り組みを支援しています。Colfax と緊密に協力して、QK192/V128 構成（別名「DeepSeek シェイプ」）用の Flash Attention 4 バックワードカーネルを実装し、公開リポジトリにマージされました [27]。また、スタンフォード大学の Hazy Research グループとの協力により、ThunderKittens の開発を積極的に支援しています [59, 60, 58, 57]。最近、最先端の BF16、MXFP8、NVFP4 GEMM 実装を ThunderKittens にオープンソース化しました [21]。最後に、量子化と MoE カーネル実装に関する知識をオンライン投稿で共有しています [63]。
6.2 RL インフラストラクチャ
当社の RL インフラストラクチャは、トレーニング、環境、推論、評価の 4 つの分離されたサービスで構成されています。分離されたサービススタックにより、大規模なグローバルトレーニング、高可用性、独立したスケーリングとシャードが可能になります。Composer 2 の本番トレーニングジョブは、GPU 計算で 3 リージョン、CPU 計算で 4 リージョンにまたがっていました。
トレーニング：Ray [42] と PyTorch [47] をベースに構築された完全非同期の高速トレーニングスタックを使用しています。中央集約型リコンパイラがスロットベースのサンプルライフサイクル状態管理を実行し、サンプルを分散エグゼキュータのパイプラインを通じて移動し、サンプル生成スループットと方策の陳腐化のバランスを取るスケジューリングポリシーを実装します。トレーナー内のすべてのサービスは、上流の依存関係が準備できた時点で計算を先取り実行することを可能にするフューチャーの概念を中心に設計されています。Ray オブジェクトストアを利用して、トレインワーカーが消費する準備のできたサンプルを保持し、ノードに十分な CPU メモリがない場合にローカル NVMe ストレージへの自然なスピルアウトを可能にします。
大規模なトレーニング後処理をサポートするため、トレーナー内のすべてのコンポーネントは、プロセスまたはプロセスグループレベルでフォールトトレラントです。トレーニング中にすべてのノードで受動的および能動的なヘルスチェックを実行します。ハードウェア障害が検出されると、そのノードをスケジューリングに対して不健全としてマークしますが、ウォームスタンバイノードでトレーニングを継続します。トレーニングと推論および環境インフラを分離することで、これらのサービスでの障害に対してトレーニングをより回復力のあるものにします。トレーニング実行中、これらのサービスに部分的または完全な停止が発生しても、トレーニングジョブが失敗しないケースを多数確認しました。トレーニングジョブの再起動回数を最小限に抑えるため、リアクティブ構成システムを使用し、プロセスレベルでのライブコードアップデートをサポートします。新しいコードがデプロイされると、既存のアクターは飛行中のリクエストを処理し、透過的に置き換えられます。
長時間実行されるコーディングロールアウトのリプレイは高価です。ジョブレベルの障害での高価な失敗を軽減するため、ステップレベルでのモデル重みの従来のチェックポイントに加えて、ロールアウトレベルおよびグループレベルで方策対応のチェックポイントを実行します。ロールアウトチェックポイントには、コードベース環境状態のメモリスナップショットに依存します。これにより、回復時に再構築されたコードベース環境を検証者に渡すことができます。グループチェックポイントには、方策バージョンでタグ付けされたアドバンテージを持つシーケンスを NFS に書き込みます。ジョブ再起動時、スケジューラはこれらを考慮し、新しい作業をディスパッチするか、準備済みのグループを単に読み込むかを決定します。
環境と Anyrun：状態を持つコードベース環境は、トレーニング後スタックの一等市民です。環境は Anyrun 上で実行されます。Anyrun は、大規模な信頼できないコードを実行するために構築された内部計算プラットフォームです。これは、Cursor 製品でクラウドエージェントとオートメーションを動かすのと同じ計算プラットフォームです。
トレーナーからのすべての環境作成要求はグローバルサービスに送信され、要求は基礎となる Anyrun クラスタにルーティングされます。トレーニングワークロードは、インスタンスの可用性とフォールトトレランスの両方のため、複数の Anyrun クラスタにシャードされます。クラスタ内では、分散された Anyrun マネージャーセットがポッドをスケジューリングし、複数のリージョンにわたってプロビジョニングされたクラウド計算をスケールし、クラスタあたり数十万のポッドを管理するための状態調整を実行します。各ポッドは、ブラウザや GUI を含む完全な開発環境を実行できる専用の Firecracker VM です。インスタンスの可用性を最大化するため、ポッドは機械タイプとアーキテクチャ（x86、ARM）の大規模なミックスで実行されます。
スケジューリングスループットは、RL ワークロードのバースト性の性質にとって特に重要です。各 Anyrun クラスタは、望ましいビンパッキング要件を維持しながら、秒あたり 500 以上のポッドをスケジューリングできます。単純なパッキング戦略の課題の 1 つは、ポッドの定常状態のリソース使用量が始動中のピーク時よりも劇的に低くなる可能性があり、オーバーコミットによりバーストする可能性もあることです。これを解決するため、従来のスケジューリングヒューリスティックに加えて、ハードウェア圧力（CPU、メモリ、ディスク）のライブリーディングを監視し、それに応じてスケジューリングします。
Anyrun は、ファイルシステムレベルとメモリーレベルの両方で完全なコーディング環境のフォークとスナップショットをサポートします。これにより、RL 中に、軌道中間のロールアウトチェックポイントや、将来の検査のためのロールアウト後の状態キャプチャなどの有用な機能が利用可能になります。ポッドフォークが要求されると、まず同じノードへのフォークスケジューリングを試みます。スペースの制約により実行不可能な場合は、ポッド状態を容量のあるノードにライブマイグレーションします。
外部への影響を制限するため、環境からのエグレスは慎重に制御されます。ポッドからのインターネットへのすべてのアクセスは、Anygress を経由する必要があります。Anygress は、Anyrun 内の内部サービスで、トラフィックのプロキシ、粒度の細かいリクエストポリシーの適用、機密ヘッダーの削除を担当します。実際の環境をよりよく再現するため、Anygress はプロキシ環境変数に依存するのではなく、ポッド起動時に信頼されたルート CA を注入し、TCP レイヤーでポッドトラフィックをリダイレクトすることで透過的に動作します。
Cursor クライアントのハーネスを代表するツールでトレーニングします。各コードベース環境は、RPC 経由で呼び出せる共有ツールライブラリから始まります。セマンティック検索などの一部のツールは外部依存関係を持ち、環境外で処理されます。Cursor クライアントで利用可能な完全なツールセットをサポートするため、データセット準備とロールアウトの両方で使用される Cursor バックエンドのシャドウデプロイメントを維持しています。このように本番実装を共有することで、Composer 2 がデプロイされるハーネスに忠実でありながら、実験とトレーニングを安全にスケールできます。
トレーニング環境と本番環境でツールの動作を異ならせたい場合があります。具体的な例としては、より正確なモデル動作を促すためのより厳格なツール引数チェックの適用や、モデルの操縦性向上のための特定ツールの削除などがあります。これを達成するため、利用可能なツールセットと各ツールの望ましい動作は、環境ごとに動的に決定されます。
推論と重み同期：RL 推論には Fireworks AI と連携しています。Kimi K2.5 はエキスパート混合モデルであるため、数値の違いにより、推論エンジンフォワードパスとトレーナーフォワードパスで異なるエキスパートが選択される可能性があります。トレーナーと推論エンジンが各トークンのエキスパートルーティングで一致しない場合、トレーニング中に計算された対数確率は、トークンがサンプリングされた分布と一致せず、方策勾配にノイズを導入します。これに対処するため、ルーターリプレイ [82, 38] を採用しています。推論中、エンジンは各 MoE レイヤーのすべてのトークンで選択されたエキスパートインデックスを返し、トレーニングフォワードパス中、ルーターのエキスパート割り当ては一致するように上書きされます。ルーターは勾配が流れるようにゲーティングスコアを計算し続けます。基本的なリプレイスキームを拡張し、ゲートスコアがルーター自身のトップ k 選択から導き出されたもっともらしさの閾値を下回るリプレイ済みエキスパートをフィルタリングし、ルーターの候補に置き換えます。これにより、推論とトレーニングのフォワードパス間の p99 数値の不一致が減少することがわかりました。
各トレーニングステップで、更新された重みを共有 S3 バケットにアップロードして推論エンジンに同期します。転送サイズを最小限に抑えるため、デルタ圧縮を使用します。各ランクは直前のアップロードをキャッシュし、新しい重みとの差分のみを送信します。RL 更新は小さいため、完全パラメータートレーニングであっても、これらの差分は 1T パラメータモデルで数 GB に圧縮されます。アップロードはすべてのトレーニングランクにわたって完全にシャードされ、トレーニングクラスタのエグレス帯域幅を飽和させることができます。同様に、Fireworks 側でのダウンロードも推論レプリカにシャードされます。圧縮、アップロード、ホットロードシグナリングは、バックグラウンドワーカーで完全にパイプライン化され、トレーニングがブロックされることはありません。Composer 2 トレーニング実行中、米国と欧州に地理的に分散したクラスタで推論を実行しました。各クラスタは共有デルタチェーンから独立して重みをダウンロードして再構築し、トレーニングクラスタへの直接接続を必要としません。これにより、商品用クラウドストレージを介した世界規模の分散 RL 推論が可能になります。
オンライン評価：トレーニング中にモデルの忠実な評価を提供するため、各評価ジョブに対して本番バックエンドと Cursor クライアントの固定バージョンを実行します。これにより、評価中のモデル動作がエンドユーザーが見るものと正確に一致しているという高い信頼性が得られ、同じインフラを使用して Cursor ハーネスとモデルシステムプロンプトを反復できます。評価したい各トレーニングステップについて、評価デプロイメントのリースを取得し、GPU を自動的にそのデプロイメントに移動し、評価チェックポイントのクロスリージョン重み同期を、それが存在するトレーニングクラスタから推論デプロイメントに実行します。
7 結果
7.1 CursorBench
当社のモデルは、強化学習パイプラインをサポートするのと同じインフラストラクチャである Anyrun（セクション 6.2）内で Cursor エージェントを直接実行して評価します。CursorBench の各タスクについて、コードベース環境と初期タスクプロンプトを初期化し、本番環境で実行されるのとまったく同じ方法でエージェントを実行します。
指標：分散を減らすため、評価セットの複数パスにわたってすべてのタスクで集計された精度を計算します。精度に加えて、モデルが対話型開発者ワークフローに対して最大限有用であり続けることを保証するため、完了トークン、エンドツーエンドのレイテンシ、推論コストなどの効率指標も測定します。
表 1: 公開および内部評価スイート全体のベンチマーク結果。サードパーティモデルについて、両方が利用可能な場合、（当社のハーネス/自己報告）形式で結果を提示します。Terminal-Bench 上の Anthropic モデルについて、当社のハーネス評価の代わりに公式リーダーボードの Claude Code スコアを報告します。全体として、Composer 2 は最も強力な最先端モデルと競合する精度を達成します。
| モデル | CursorBench | SWE-bench Multi. | Terminal-Bench |
|---|---|---|---|
| Composer 2 | 61.3 | 73.7 | 61.7 |
| Composer 1.5 | 44.2 | 65.9 | 47.9 |
| Composer 1 | 38.0 | 56.9 | 40.0 |
| Opus 4.6 High | 58.2 | 75.8 / 77.8 | 58.0 / 65.4 |
| Opus 4.5 High | 48.4 | 73.8 / 76.2 | 52.1 / 59.8 |
| GPT-5.4 | 63.9 | 76.8 / - | 66.5† / 75.1 |
| GPT-5.3 Codex | 59.1 | 74.8 / - | 64.8† / 77.3 |
| GPT-5.2 | 56.5 | 68.3 / - | 60.5 / 62.2 |
| GLM-5 | 42.7 | 66.9 / 73.3 | 59.6 / 56.2 |
| Kimi K2.5 | 36.0 | 65.1 / 73.0 | 47.3 / 50.8 |
† OpenAI の安全フィルターにより、GPT-5.4 の 5 タスクと GPT-5.3-Codex の 3 タスクが拒否されました。拒否された問題は 0 点として処理されます。
表 1 は、CursorBench-3 におけるさまざまなモデルの精度を報告しています。Composer 2 は 61.3% を達成し、Composer 1.5 に対して 37% の相対的改善、Composer 1 に対して 61% の改善を表しています。ベースモデルである Kimi K2.5 と比較して、Composer 2 は大幅な精度向上を示し、継続的プレトレーニングと強化学習パイプラインの有効性を検証しています。さらに、Composer 2 は、推論コストが大幅に安いにもかかわらず、最も強力な最先端モデルと競合する精度を達成します。
図 11 は、これらの精度指標をリソース消費に対して位置付けています。トークン使用量に関して、Composer 2 は他のモデルと同程度の長さの軌道生成し、最先端レベルの精度を提供しながら、同様の精度レベルで動作する他の最先端モデルと比較して非常にトークン効率的です。
ただし、アクティブパラメータ数の違いにより、生のトークン使用量は推論効率を完全に捉えているわけではありません。API モデルによって使用される FLOP にアクセスできないため、図 11 に CursorBench タスクあたりの中央値推論コストを示します。ここで、Composer 2 はパレート最適なトレードオフを達成しています。その推論コストは、より小規模または低努力のモデルバリアントと似ていますが、その精度ははるかに大規模な最先端モデルと競合します。これらの結果は、ドメイン特化型トレーニングにより、実世界のソフトウェアエンジニアリングの厳しい要件に対して、汎用モデルよりも正確でコスト効率の高いモデルを同時に生成できることを示しています。
図 11: CursorBench において、Composer 2 はトークン効率において非常に競争力を保ちながら、コスト面で優れたパレートフロンティアを達成しています。GPT-5.4、Codex-5.3、Opus 4.6、Sonnet 4.6 について、高（丸）、中（三角）、低（四角）の努力バリアントをプロットしています。
7.2 公開ベンチマーク
さらに、2 つの公開ベンチマーク、SWE-bench Multilingual および Terminal-Bench において Composer 2 を評価しました（表 1、最後の 2 列）。Composer モデルについて、当社のハーネスを使用してスコアを計算します。サードパーティモデルについて、両方が利用可能な場合、結果を（当社のハーネス/自己報告）形式で報告します。Terminal-Bench 上の Anthropic モデルについては、当社のハーネス評価ではなく、公式の Claude Code リーダーボードスコアを使用します。SWE-bench について、問題文の最初に「この GitHub の問題を解決してください」という文言を追加するだけで、テストケースの作成や実行に関する指示は追加しません。Terminal-Bench について、ファイルの配置場所や環境の設定方法に関するソリューション形式の指示をユーザープロンプトに追加します。
SWE-bench Multilingual において、Composer 2 は 73.7% を記録し、Composer 1.5 より 7.8%、Composer 1 より 16.8% 向上しました。Terminal-Bench において、Composer 2 は 61.7% を達成し、Composer 1.5 より 13.8%、Composer 1 より 21.7% 向上しました。ベースモデルである Kimi K2.5 に対して、Composer 2 は SWE-bench Multilingual で同様のパフォーマンスを達成し、Terminal-Bench では大幅に向上したパフォーマンスを達成しました。全体として、これらの公開ベンチマークにおける Composer 2 のパフォーマンスは、他の最先端モデルと非常に競合しています。両方のベンチマークを通じて、各後継の Composer バージョンは一貫した改善を示し、プレトレーニングと強化学習の両方への継続的な投資が、エージェント型ソフトウェアエンジニアリングに相乗効果的な利益をもたらすことを実証しています。
8 結論
Composer 2 は、強力な専門モデルが継続的プレトレーニングと強化学習によってトレーニング可能であることを実証しています。強力な汎用モデルから始めて、モデルを特化させることで、エージェント型コーディングにおいて最先端レベルのパフォーマンスを達成できます。アルゴリズムとインフラストラクチャの両方の観点からの主な洞察は、ターゲットドメインと密接なドメインマッチを確保しながらトレーニングをスケールアップすることです。これは、CursorBench による慎重なドメインベンチマーキング、ハーネスおよび環境エンジニアリング、行動報酬の開発、ならびに厳格なインフラストラクチャの信頼性によって実現します。
Composer 2 の結果は、さらなるスケーリングによる将来の改善の可能性について楽観的です。Composer 2 は以前のバージョンからの着実な改善を示していますが、モデルが知能や一貫性の動作を示し、明らかに改善できるケースが多くあります。この研究でトレーニングされたモデルは大規模（1.04T パラメータ、32B アクティブ）ですが、同程度の能力を持つ他の独占モデルよりもおそらく小規模です。アーキテクチャとアルゴリズムの両面において、開発の余地がまだ相当に残っていると信じています。
ツールとしてのコーディングエージェントの範囲も、対話型の問題から、人間の時間を数時間必要とするエージェントタスクへと拡大しており [29]、将来的にその範囲が急速に拡大すると一般的に予想されています [65]。将来の Composer のイテレーションのため、当社のチームは、より長期的なトレーニング信号を効果的に活用するアルゴリズムと、忠実な長期的問題サポートするインフラストラクチャの両方において、より長い問題を処理するトレーニング方法を通じて、これらの問題に取り組むモデルの能力を拡大することに注力しています。
参考文献
なぜ SWE-bench Verified はもはや最先端のコーディング能力を測定していないのか - openai.com. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/ [2026 年 3 月 24 日アクセス].
Arash Ahmadian, Chris Cremer, Matthias Gallé, Marzieh Fadaee, Julia Kreutzer, Olivier Pietquin, Ahmet Üstün, Sara Hooker. Back to basics: Revisiting reinforce-style optimization for learning from human feedback in llms. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2024, Bangkok, Thailand, August 11-16, 2024, pp. 12248-12267. Association for Computational Linguistics, 2024. doi: 10.18653/V1/2024.ACL-LONG.662. URL https://doi.org/10.18653/v1/2024.acl-long.662.
Abante AI. Locodiff-bench: Long context diff reconstruction benchmark. https://abanteai.github.io/LoCoDiff-bench/, 2025.
Zhipu AI. GLM-5: From vibe coding to agentic engineering. https://z.ai/blog/glm-5, 2026.
Loubna Ben Allal, Raymond Li, Denis Kocetkov, Chenghao Mou, Christopher Akiki, Carlos Muñoz Ferrandis, Niklas Muennighoff, Mayank Mishra, Alex Gu, Manan Dey, et al. Santacoder: don't reach for the stars! In International Conference on Machine Learning, ICML 2023 Workshop on Knowledge and Logical Reasoning in the Era of Datadriven Learning, 2023.
Afra Amini, Tim Vieira, Ryan Cotterell. Better estimation of the kullback-leibler divergence between language models. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=um9kHMof0c.
Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374, 2021. URL https://arxiv.org/abs/2107.03374.
Zhipeng Chen, Xiaobo Qin, Youbin Wu, Yue Ling, Qinghao Ye, Wayne Xin Zhao, Guang Shi. Pass@k training for adaptively balancing exploration and exploitation of large reasoning models. arXiv preprint arXiv:2508.10751, 2025. doi: 10.48550/arXiv.2508.10751. URL https://arxiv.org/abs/2508.10751.
Colin Clement, Dawn Drain, Jonathan Timcheck, Alexey Svyatkovskiy, Neel Sundaresan. Pymt5: multi-mode translation of natural language and python code with transformers. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pp. 9052-9065, 2020.
DeepSeek-AI. Deepseek-coder-v2: Breaking the barrier of closed-source models in code intelligence. arXiv preprint arXiv:2406.11931, 2024. URL https://arxiv.org/abs/2406.11931.
DeepSeek-AI. Deepseek-v3 technical report. arXiv preprint arXiv:2412.19437, 2024. URL https://arxiv.org/abs/2412.19437.
DeepSeek-AI. Deepseek-v3.2: Pushing the frontier of open large language models. arXiv preprint arXiv:2512.02556, 2025. URL https://arxiv.org/abs/2512.02556.
Dong Du, Shulin Liu, Tao Yang, Shaohua Chen, Yang Li. Ulorl: An ultra-long output reinforcement learning approach for advancing large language models' reasoning abilities. arXiv preprint arXiv:2507.19766, 2025. URL https://arxiv.org/abs/2507.19766.
William Fedus, Barret Zoph, Noam Shazeer. Switch transformers: Scaling to trillion parameter models with simple and efficient sparsity. Journal of Machine Learning Research, 23(120):1-39, 2022. URL http://jmlr.org/papers/v23/21-0998.html.
Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. Codebert: A pre-trained model for programming and natural languages. In Findings of the association for computational linguistics: EMNLP 2020, pp. 1536-1547, 2020.
Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Scott Yih, Luke Zettlemoyer, Mike Lewis. Incoder: A generative model for code infilling and synthesis. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net, 2023. URL https://openreview.net/forum?id=hQwb-lbM6EL.
Fabian Gloeckle, Badr Youbi Idrissi, Baptiste Rozière, David Lopez-Paz, Gabriel Synnaeve. Better & faster large language models via multi-token prediction. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024. OpenReview.net, 2024. URL https://proceedings.mlr.press/v235/gloeckle24a.html.
Alexander Golubev, Maria Trofimova, Sergei Polezhaev, Ibragim Badertdinov, Maksim Nekrashevich, Anton Shevtsov, Simon Karasik, Sergey Abramov, Andrei Andriushchenko, Filipp Fisin, Sergei Skvortsov, Boris Yangel. Training long-context, multi-turn software engineering agents with reinforcement learning. arXiv preprint arXiv:2508.03501, 2025. URL https://arxiv.org/abs/2508.03501.
Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y Wu, Y K Li, et al. Deepseek-coder: When the large language model meets programming-the rise of code intelligence. arXiv preprint arXiv:2401.14196, 2024. URL https://arxiv.org/abs/2401.14196.
Suchin Gururangan, Ana Marasovi´ c, Swabha Swayamdipta, Kyle Lo, Iz Beltagy, Doug Downey, Noah A. Smith. Don't stop pretraining: Adapt language models to domains and tasks. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, ACL 2020, Online, July 5-10, 2020, pp. 8342-8360. Association for Computational Linguistics, 2020. doi: 10.18653/V1/2020.ACL-MAIN.740. URL https://doi.org/10.18653/v1/2020.acl-main.740.
HazyResearch. Thunderkittens gemm kernels, 2026. URL https://github.com/HazyResearch/ThunderKittens/tree/main/kernels/gemm.
Jordan Hoffmann, Sebastian Borgeaud, Arthur Mensch, Elena Buchatskaya, Trevor Cai, Eliza Rutherford, Diego de Las Casas, Lisa Anne Hendricks, Johannes Welbl, Aidan Clark, et al. Training compute-optimal large language models. In Advances in Neural Information Processing Systems 35: Annual Conference on Neural Information Processing Systems 2022, NeurIPS 2022, New Orleans, LA, USA, November 28 - December 9, 2022, 2022.
Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, et al. Metagpt: Meta programming for a multi-agent collaborative framework. In The twelfth international conference on learning representations, 2023.
Jeremy Howard, Sebastian Ruder. Universal language model fine-tuning for text classification. In Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics, ACL 2018, Melbourne, Australia, July 15-20, 2018, Volume 1: Long Papers, pp. 328-339. Association for Computational Linguistics, 2018. doi: 10.18653/V1/P18-1031. URL https://aclanthology.org/P18-1031/.
Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, et al. Qwen2.5-coder technical report. arXiv preprint arXiv:2409.12186, 2024.
Sam Ade Jacobs, Masahiro Tanaka, Chengming Zhang, Minjia Zhang, Shuaiwen Leon Song, Samyam Rajbhandari, Yuxiong He. Deepspeed ulysses: System optimizations for enabling training of extreme long sequence transformer models. arXiv preprint arXiv:2309.14509, 2023.
Jay Shah. Flash attention pull request #2270, 2026. URL https://github.com/Dao-AILab/flash-attention/pull/2270.
Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R Narasimhan. SWE-bench: Can language models resolve real-world github issues? In The Twelfth International Conference on Learning Representations, 2024. URL https://openreview.net/forum?id=VTF8yNQM66.
Thomas Kwa, Ben West, Joel Becker, Amy Deng, Katharyn Garcia, Max Hasin, Sami Jawhar, Megan Kinniment, Nate Rush, Sydney Von Arx, Ryan Bloom, Thomas Broadley, Haoxing Du, Brian Goodrich, Nikola Jurkovic, Luke Harold Miles, Seraphina Nix, Tao Lin, Neev Parikh, David Rein, Lucas Jun Koba Sato, Hjalmar Wijk, Daniel M. Ziegler, Elizabeth Barnes, Lawrence Chan. Measuring ai ability to complete long tasks. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/, 03 2025.
Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, et al. Starcoder: may the source be with you! Trans. Mach. Learn. Res., 2023, 2023. URL https://openreview.net/forum?id=KoFOg41haE.
Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. Competition-level code generation with alphacode. Science, 378(6624):1092-1097, 2022.
Xiao Liang, Zhong-Zhi Li, Yeyun Gong, Yelong Shen, Ying Nian Wu, Zhijiang Guo, Weizhu Chen. Beyond pass@1: Self-play with variational problem synthesis sustains RLVR. In The Fourteenth International Conference on Learning Representations, ICLR 2026, 2026. URL https://openreview.net/forum?id=Wjf3OMJxpn.
Hao Liu, Matei Zaharia, Pieter Abbeel. Ring attention with blockwise transformers for near-infinite context. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net, 2024. URL https://openreview.net/forum?id=WsRHpHH4s0.
Zichen Liu, Changyu Chen, Wenjun Li, Penghui Qi, Tianyu Pang, Chao Du, Wee Sun Lee, Min Lin. Understanding r1-zero-like training: A critical perspective. arXiv preprint arXiv:2503.20783, 2025. URL https://arxiv.org/abs/2503.20783.
Zihan Liu, Zhuolin Yang, Yang Chen, Chankyu Lee, Mohammad Shoeybi, Bryan Catanzaro, Wei Ping. Acereason-nemotron 1.1: Advancing math and code reasoning through sft and rl synergy. arXiv preprint arXiv:2506.13284, 2025. URL https://arxiv.org/abs/2506.13284.
Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy-Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, et al. Starcoder 2 and the stack v2: The next generation. arXiv preprint arXiv:2402.19173, 2024. URL https://arxiv.org/abs/2402.19173.
Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo Geng, Wenxiang Hu, Chongyang Tao, Jing Ma, Qingwei Lin, Daxin Jiang. Wizardcoder: Empowering code large language models with evol-instruct. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net, 2024. URL https://openreview.net/forum?id=UnUwSIgK5W.
Wenhan Ma, Hailin Zhang, Liang Zhao, Yifan Song, Yudong Wang, Zhifang Sui, Fuli Luo. Stabilizing MoE reinforcement learning by aligning training and inference routers. arXiv preprint arXiv:2510.11370, 2025. URL https://arxiv.org/abs/2510.11370.
Mike A Merrill, Alexander Glenn Shaw, Nicholas Carlini, Boxuan Li, Harsh Raj, Ivan Bercovich, Lin Shi, Jeong Yeon Shin, Thomas Walshe, E. Kelly Buchanan, et al. Terminalbench: Benchmarking agents on hard, realistic tasks in command line interfaces. In The Fourteenth International Conference on Learning Representations, ICLR 2026, 2026. URL https://openreview.net/forum?id=a7Qa4CcHak.
MiniMax. Minimax-m1: Scaling test-time compute efficiently with lightning attention. arXiv preprint arXiv:2506.13585, 2025. URL https://arxiv.org/abs/2506.13585.
Mayank Mishra, Matt Stallone, Gaoyuan Zhang, Yikang Shen, Aditya Prasad, Adriana Meza Soria, Michele Merler, Parameswaran Selvam, Saptha Surendran, Shivdeep Singh, et al. Granite code models: A family of open foundation models for code intelligence. arXiv preprint arXiv:2405.04324, 2024.
Philipp Moritz, Robert Nishihara, Stephanie Wang, Alexey Tumanov, Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I. Jordan, Ion Stoica. Ray: A distributed framework for emerging AI applications. In Andrea C. Arpaci-Dusseau and Geoff Voelker (eds.), 13th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2018, Carlsbad, CA, USA, October 8-10, 2018, pp. 561577. USENIX Association, 2018. URL https://www.usenix.org/conference/osdi18/presentation/nishihara.
Niklas Muennighoff, Qian Liu, Armel Randy Zebaze, Qinkai Zheng, Binyuan Hui, Terry Yue Zhuo, Swayam Singh, Xiangru Tang, Leandro von Werra, Shayne Longpre. Octopack: Instruction tuning code large language models. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net, 2024. URL https://openreview.net/forum?id=mw1PWNSWZP.
Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, Caiming Xiong. Codegen: An open large language model for code with multi-turn program synthesis. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net, 2023. URL https://openreview.net/forum?id=iaYcJKpY2B_.
NVIDIA. Pretraining large language models with nvfp4. arXiv preprint arXiv:2509.25149, 2025. URL https://arxiv.org/abs/2509.25149.
Open Compute Project. Ocp microscaling formats (mx) specification version 1.0. https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf, 2023.
Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, et al. Pytorch: An imperative style, high-performance deep learning library. Advances in neural information processing systems, 32, 2019.
Alexandre Piché, Ehsan Kamalloo, Rafael Pardinas, Xiaoyin Chen, Dzmitry Bahdanau. PipelineRL: Faster on-policy reinforcement learning for long sequence generation. arXiv preprint arXiv:2509.19128, 2025. URL https://arxiv.org/abs/2509.19128.
Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, et al. Chatdev: Communicative agents for software development. In Proceedings of the 62nd annual meeting of the association for computational linguistics (volume 1: Long papers), pp. 15174-15186, 2024.
Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, Yuxiong He. ZeRO: Memory optimizations toward training trillion parameter models. In SC20: International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 1-16. IEEE, 2020.
Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950, 2023. URL https://arxiv.org/abs/2308.12950.
John Schulman. Approximating KL divergence. 2020. Blog post.
Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Mingchuan Zhang, Y K Li, Y Wu, Daya Guo. Deepseekmath: Pushing the limits of mathematical reasoning in open language models. arXiv preprint arXiv:2402.03300, 2024. URL https://arxiv.org/abs/2402.03300.
Noam Shazeer, Azalia Mirhoseini, Krzysztof Maziarz, Andy Davis, Quoc Le, Geoffrey Hinton, Jeff Dean. Outrageously large neural networks: The sparsely-gated mixture-of-experts layer. In International Conference on Learning Representations (ICLR), 2017. URL https://openreview.net/forum?id=B1ckMDqlg.
Mohammad Shoeybi, Mostofa Patwary, Raul Puri, Patrick LeGresley, Jared Casper, Bryan Catanzaro. Megatron-LM: Training multi-billion parameter language models using model parallelism. arXiv preprint arXiv:1909.08053, 2019.
Benjamin F. Spector, Simran Arora, Aaryan Singhal, Arjun Parthasarathy, Daniel Y. Fu, Christopher Ré. Thunderkittens: Simple, fast, and adorable kernels. In The Thirteenth International Conference on Learning Representations, April 2025. URL https://openreview.net/forum?id=0fJfVOSUra.
Stuart H. Sul, Chris Ré. Thunderkittens 2.0: Even faster kernels for your gpus. February 2026. URL https://hazyresearch.stanford.edu/blog/2026-02-19-tk-2.
Stuart H. Sul, Simran Arora, Benjamin Spector, Chris Ré. Loads and loads of fluffy kittens. November 2025. URL https://hazyresearch.stanford.edu/blog/2025-11-17-fluffy-kittens.
Stuart H. Sul, Simran Arora, Benjamin F. Spector, Christopher Ré. Parallelkittens: Systematic and practical simplification of multi-gpu ai kernels. arXiv preprint arXiv:2511.13940, 2025. URL https://arxiv.org/abs/2511.13940.
Stuart H. Sul, Dylan Lim, Benjamin Spector, Chris Ré. One kernel for all your gpus. September 2025. URL https://hazyresearch.stanford.edu/blog/2025-09-22-pgl.
Fahim Tajwar, Guanning Zeng, Yueer Zhou, Yuda Song, Daman Arora, Yiding Jiang, Jeff Schneider, Ruslan Salakhutdinov, Haiwen Feng, Andrea Zanette. Maximum likelihood reinforcement learning. arXiv preprint arXiv:2602.02710, 2026. doi: 10.48550/arXiv.2602.02710. URL https://arxiv.org/abs/2602.02710.
CodeGemma Team, Heri Zhao, Jeffrey Hui, Joshua Howland, Nam Nguyen, Siqi Zuo, Andrea Hu, Christopher A Choquette-Choo, Jingyue Shen, Joe Kelley, et al. Codegemma: Open code models based on gemma. arXiv preprint arXiv:2406.11409, 2024.
Cursor Team. 1.5x faster moe training with custom mxfp8 kernels. https://cursor.com/blog/kernels, 2025.
Cursor Team. Self-summarization for composer. https://cursor.com/blog/self-summarization, 2025.
Cursor Team. The third era of software. https://cursor.com/blog/third-era, 2025.
Kimi Team. Kimi k1.5: Scaling reinforcement learning with LLMs. arXiv preprint arXiv:2501.12599, 2025.
Kimi Team. Kimi K2.5: Visual agentic intelligence. arXiv preprint arXiv:2602.02276, 2026.
Qwen Team. Qwen3 technical report. arXiv preprint arXiv:2505.09388, 2025.
Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, et al. LLaMA: Open and efficient foundation language models. arXiv preprint arXiv:2302.13971, 2023. URL https://arxiv.org/abs/2302.13971.
Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, Graham Neubig. OpenHands: An open platform for AI software developers as generalist agents. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net, 2025. URL https://openreview.net/forum?id=OJd3ayDDoF.
Yue Wang, Weishi Wang, Shafiq Joty, Steven CH Hoi. Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation. In Proceedings of the 2021 conference on empirical methods in natural language processing, pp. 8696-8708, 2021.
Yue Wang, Hung Le, Akhilesh Gotmare, Nghi Bui, Junnan Li, Steven Hoi. Codet5+: Open code large language models for code understanding and generation. In Proceedings of the 2023 conference on empirical methods in natural language processing, pp. 1069-1088, 2023.
Yuxiang Wei, Zhe Wang, Jiawei Liu, Yifeng Ding, Lingming Zhang. Magicoder: Empowering code generation with OSS-Instruct. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, Proceedings of Machine Learning Research, pp. 52632-52657. PMLR, 2024. URL https://proceedings.mlr.press/v235/wei24h.html.
Xumeng Wen, Zihan Liu, Shun Zheng, Zhijian Xu, Shengyu Ye, Zhirong Wu, Xiao Liang, Yang Wang, Junjie Li, Ziming Miao, Jiang Bian, Mao Yang. Reinforcement learning with verifiable rewards implicitly incentivizes correct reasoning in base LLMs. In The Fourteenth International Conference on Learning Representations, ICLR 2026, 2026. URL https://openreview.net/forum?id=jGbRWwIidy.
John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, Ofir Press. Swe-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems 38: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024, 2024. URL http://papers.nips.cc/paper_files/paper/2024/hash/5a7c947568c1b1328ccc5230172e1e7c-Abstract-Conference.html.
John Yang, Kilian Lieret, Carlos E. Jimenez, Alexander Wettig, Kabir Khandpur, Yanzhe Zhang, Binyuan Hui, Ofir Press, Ludwig Schmidt, Diyi Yang. SWE-smith: Scaling data for software engineering agents. In Advances in Neural Information Processing Systems 38: Annual Conference on Neural Information Processing Systems 2025, NeurIPS 2025, San Diego, CA, USA, December 1-4, 2025, 2025. URL https://openreview.net/forum?id=63iVrXc8cC.
Jiasheng Ye et al. Data mixing made efficient: A biannual survey of data mixing for LLM pre-training. arXiv preprint arXiv:2403.16952, 2024. URL https://arxiv.org/abs/2403.16952.
Qiying Yu, Zheng Zhang, Ruofei Zhu, Yufeng Yuan, Xiaochen Zuo, Yu Yue, Weinan Dai, Tiantian Fan, Gaohong Liu, Juncai Liu, Lingjun Liu, Xin Liu, Haibin Lin, Zhiqi Lin, Bole Ma, Guangming Sheng, Yuxuan Tong, Chi Zhang, Mofan Zhang, Ru Zhang, Wang Zhang, Hang Zhu, Jinhua Zhu, Jiaze Chen, Jiangjie Chen, Chengyi Wang, Hongli Yu, Yuxuan Song, Xiangpeng Wei, Hao Zhou, Jingjing Liu, Wei-Ying Ma, Ya-Qin Zhang, Lin Yan, Yonghui Wu, Mingxuan Wang. DAPO: An open-source LLM reinforcement learning system at scale. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, NeurIPS 2025, 2025. URL https://openreview.net/forum?id=2a36EMSSTp.
Yang Yue, Zhiqi Chen, Rui Lu, Andrew Zhao, Zhaokai Wang, Yang Yue, Shiji Song, Gao Huang. Does reinforcement learning really incentivize reasoning capacity in LLMs beyond the base model? In The Thirty-ninth Annual Conference on Neural Information Processing Systems, NeurIPS 2025, 2025. URL https://openreview.net/forum?id=4OsgYD7em5. Oral.
Chenggang Zhao, Shangyan Zhou, Liyue Zhang, Chengqi Deng, Zhean Xu, Yuxuan Liu, Kuai Yu, Jiashi Li, Liang Zhao. Deepep: an efficient expert-parallel communication library. https://github.com/deepseek-ai/DeepEP, 2025.
Yanli Zhao, Andrew Gu, Rohan Varma, Liang Luo, Chien-Chin Huang, Min Xu, Less Wright, Hamid Shojanazeri, Myle Ott, Sam Shleifer, et al. Pytorch fsdp: experiences on scaling fully sharded data parallel. arXiv preprint arXiv:2304.11277, 2023.
Chujie Zheng, Shixuan Liu, Mingze Li, Xiong-Hui Chen, Bowen Yu, Chang Gao, Kai Dang, Yuqiong Liu, Rui Men, An Yang, Jingren Zhou, Junyang Lin. Group sequence policy optimization. arXiv preprint arXiv:2507.18071, 2025. URL https://arxiv.org/abs/2507.18071.
Terry Yue Zhuo, Armel Randy Zebaze, Leandro Von Werra, Harm de Vries, Qian Liu, Niklas Muennighoff. Parameter-efficient instruction tuning code large language models: An empirical study. In ICLR 2025 Third Workshop on Deep Learning for Code, 2025.
A 貢献者
Composer 研究チームの構成メンバー：
Aaron Chan, Ahmed Shalaby, Alexander Wettig, Aman Sanger, Andrew Zhai, Anurag Ajay, Ashvin Nair, Charlie Snell, Chen Lu, Chen Shen, Emily Jia, Federico Cassano, Hanpeng Liu, Haoyu Chen, Henry Wildermuth, Jacob Jackson, Janet Li, Jediah Katz, Jiajun Yao, Joey Hejna, Josh Warner, Julius Vering, Kevin Frans, Lee Danilek, Less Wright, Lujing Cen, Luke Melas-Kyriazi, Michael Truell, Michiel de Jong, Naman Jain, Nate Schmidt, Nathan Wang, Niklas Muennighoff, Oleg Rybkin, Paul Loh, Phillip Kravtsov, Rishabh Yadav, Sahil Shah, Sam Kottler, Alexander M Rush, Shengtong Zhang, Shomil Jain, Sriram Sankar, Stefan Heule, Stuart H. Sul, Sualeh Asif, Victor Rong, Wanqi Zhu, William Lin, Yuchen Wu, Yuri Volkov, Yury Zemlyanskiy, Zack Holbrook, Zhiyuan Zhang
B ベースモデルの選択
トレーニング前に、GLM5 [4]、Kimi K2.5 [67]、DeepSeek V3.2 [12] を含むいくつかの潜在的なオープンソースベースモデルを評価しました。Kimi K2.5 の選択に貢献した 3 つのベースモデル評価を以下に示します。
コーディング知識：内部的なベンチマーク FreshBench を使用して事実知識をスコア化します。FreshBench は、以前の Composer モデルに対して敵対的に構築された質問応答ベンチマークです。Composer がコーディングタスクを解決するためにライブラリソースコードを読み取る必要があったか、Web 検索を実行する必要があったターンを特定します。これらのトレースから質問応答ペアを作成し、Web 検索エージェントを使用して回答を検証します。
状態追跡：リポジトリを編集する際、コーディングエージェントはアクションを実行する前に、数十の過去のファイル編集を理解する必要があることがよくあります。LoCoDiff [3] は、多くの差分後のファイルの状態を再現するようにモデルに求めるベンチマークで、モデルの長期記憶にとって重要な基本スキルです。状態追跡は、LoCoDiff に似た内部ベンチマークで、当社のモノリポから構築されています。単一文字のエラーに敏感であることがわかった生の精度を測定するのではなく、文字レベルの平均距離を報告します。
コードベースのパープレキシティ：ベースモデルのコーディング知能を決定するためにパープレキシティを測定します。汚染されていないソースとして当社のプライベートモノリポを使用し、ファイルを図順に連結し、ローリングウィンドウにわたる負の対数尤度の合計を計算します。
ベースモデルのテスト時には、コーディングエージェントベンチマークを意図的に考慮していません。そのようなベンチマークは最終パフォーマンスの予測が低いことがわかったためです。これは、エージェント能力や長期的能力が RL 段階で劇的に変化する可能性があるためです。
表 2 は、分析の結果を示しています。検討された 3 つのモデルはすべて、これらの実験で非常に良好なパフォーマンスを示しました。全体的に強力なパフォーマンスと、当社のインフラストラクチャにおける効率性などの追加の考慮事項により、Kimi K2.5 [67] を選択しました。
| モデル | FreshBench ↑ | 状態追跡 ↓ | 負の対数尤度 ↓ |
|---|---|---|---|
| DeepSeek V3.2 | 68.9% | 66 | 11.75M |
| Kimi K2.5 | 83.2% | 86 | 13.81M |
| GLM-5 | 79.2% | 92 | 14.11M |
| GPT-5.4 | 92.5% | 103 | - |
| Claude 4.6 Opus | 88.9% | 65 | - |
| Gemini 3 Flash | 84.5% | 27 | - |
| Claude 4.5 Sonnet | 80.1% | 69 | - |
| Claude 4.5 Haiku | 61.7% | 177 | - |
表 2: 内部ベンチマークで評価されたベースモデル。負の対数尤度は内部コードベースで測定されます。
C CursorBench
C.1 ストリーミングプレフィックス検出
以下は、別の CursorBench タスクの例です。
問題文：一部のチャット応答で奇妙なストリーミングバグが発生しています。「Now I Now I need to updat Now I need to update this. Now I need to update this. I ha Now I need to update this. I have the」適切なストリーミングデルタの代わりに、スニペットのような繰り返し成長するプレフィックスが得られます。これは主に思考トークン内で発生していると思われます。これがどの程度一般的か知りたいのです。@logs フォルダ内の 954 件の応答 JSON ファイルを調べてください。
図 12: CursorBench タスクの例。エージェントは部分的な症状レポートから障害モードを推測し、954 件の異種チャット応答に対してヒューリスティック検出アルゴリズムを作成し、通常の増分出力を過剰にカウントせずに、不正なプレフィックスストリーミングケースの正確なカウントを回復するようにそのヒューリスティックを慎重に調整する必要があります。さらに、バグのバリアントにより「インターリーブスタッター」が発生し、初期プレフィックスチェーンが安定して増分する繰り返し行になる前に 2 行だけになります。エージェントはこのことを発見するためにチャット応答を慎重に調べる必要があります。
以下のリストは、このタスクのリファレンス差分のアルゴリズム中核を示しています。
MIN_CHAIN = 3
MIN_SEED_LEN = 2
MAX_SEED_LEN = 50
def find_prefix_chain(text: str ) -> tuple [ int , str ] | None:
if len (text) < 10: return None
first_nl = text.find("\n")
if first_nl < MIN_SEED_LEN or first_nl > MAX_SEED_LEN: return None
seed = text[:first_nl]
needle = "\n" + seed
starts = [0]
pos = 0
while True:
idx = text.find(needle , pos)
if idx == -1: break
starts.append(idx + 1)
pos = idx + 1
if len (starts) < MIN_CHAIN: return None
ends = [s -1 for s in starts[1:]] + [ len (text)]
chunks = [text[s:e] for s, e in zip (starts , ends)]
chain = 1
for i in range ( len (chunks) -1):
cur, nxt = chunks[i], chunks[i + 1]
if len (cur) < len (nxt) and nxt.startswith(cur): chain += 1
else : break
return (chain , seed) if chain >= MIN_CHAIN else None
def iter_think_blocks(text: str ):
pos = 0
while True:
open_idx = text.find("", pos)
if open_idx == -1: return
close_idx = text.find(" ", open_idx)
if close_idx == -1: yield text[open_idx + 7:].lstrip("\n"); return
yield text[open_idx + 7:close_idx].lstrip("\n")
pos = close_idx + 8
def has_prefix_streaming_bug(chat_response: str ) -> bool :
return any ( find_prefix_chain(block) is not None for block in iter_think_blocks(chat_response) )