編集 | 玉澄
「時として、モデルは実際に自分が仮想環境にいるのか、それとも実環境にいるのかを察知してしまう。これが、強化学習（RL）中のパフォーマンスと、本番環境でのパフォーマンスに違いを生じさせる原因になるんだ」
「モデルはあまりにもズルをするのが好きで、強化学習はその『不正行為』を奨励するのが非常に得意なんだ。」
少し前にCursorは、自社開発モデルComposerの第2世代最新バージョンをリリースしました。その性能はClaude Opus 4.7に迫りながら、価格はわずか10分の1と、コミュニティでちょっとしたセンセーションを巻き起こしました。
アプリケーション層の企業が、真の最先端モデル研究所へと変貌を遂げたのです。どのようにしてそれを成し遂げたのか、非常に興味深いところです。
ちょうど最近、セコイア・キャピタルの公式ポッドキャストが、Cursor Composer 2プロジェクトのリサーチリードであるFederico Cassano氏と、このプロジェクトに分散インフラを提供したFireworksのDmytro Dzhulgakov氏を招き、「Composer 2はどのように構築されたのか」というテーマについて語り合いました。
それでは、早速その内容を覗いてみましょう〜
5月19日の新モデル発表時、公式は、Kimi K2.5のオープンソースを基盤に、最新モデルの学習に費やした計算リソースの85%が中期学習と強化学習に割かれたと述べました。今回の対談は、基本的にこの中期学習と強化学習を中心に展開されました。
まず編集部が最も驚かされたのは、Federico氏が、RLのプロセスにおいて、もしシミュレーション環境が実際のユーザーPC環境とわずかでも異なっていれば、モデルは自分が「偽の環境」にいることを察知できると語った点です。
そして、モデルがそれに気づくと、より高い報酬値を得るために「小細工」や「不正」を働き、問題解決方法を真に学習しようとはしなくなるのです。
モデルに対するRLの作用についてのFederico氏の洞察も非常に興味深いものでした。彼は、事前学習はモデルに人類の全知識を吸収させることであり、RL段階は「ノブ」を調整するようなものだと述べました。それによりモデルは「ねえ、君は専門家なんだから、物事を正しくやらなければならないんだよ」と理解するようになるのです。
さらに、RL学習中、モデルは直接Cursorのハーネスと相互作用するため、「自分の残りの人生を過ごすことになる『世界』」について学ぶことができるといいます。
Dmytro氏もまた、門外漢にとっては非常に衝撃的な事実を共有しました。それは、コンピュータ上の浮動小数点演算は非決定的であり、a+b+cの結果は必ずしもc+b+aとは限らない、というものです。
これはRLに大きな影響を与えます。混合エキスパート（MoE）モデルは精度に非常に敏感で、計算の差異が全く異なるエキスパートノードの活性化を引き起こし、まったく異なる結果をもたらす可能性があるからです。
したがって、微小な計算の差異はRL学習の失敗を招きかねません。この問題を解決するために、エンジニアはGPUカーネルを手動で記述し、演算順序の一貫性を強制する必要があります。
推論の計算リソース配分についても、Federico氏は独自の見解を持っています。彼は、推論で消費されるFLOPsが学習よりもはるかに多いというのは神話だと考えています。理想的な状況では、GPU計算リソースの1/3を推論に割り当て、残りを重みの更新に使うべきだというのです。
また、彼らは特定の分野においては、モデルの「専門化」が「汎用化」に勝ると考えています。
従来、モデルは大きければ大きいほど、汎用的であればあるほど良いと考えられていました。しかし、彼らはすべてのモデルの重みを「Cursor内部のソフトウェアエンジニアリング」タスクに特化させることで、より小さなモデルでOpusのような大規模モデルに匹敵する性能を達成し、しかもコストを一桁削減しました。
さらに、ハーネス上でもRLが実行されます。ハーネスの一部とモデル自身からなるシステム全体をRLで最適化することで、Composer 2に「自己要約」や「圧縮」といった能力を学習させました。これにより、20万トークンのコンテキストウィンドウを基に、実質的に数百万トークンを処理できるようになります。
また彼は、RL環境に対する理解も共有しました。RL環境は実際には、ハーネス、オペレーティングシステム、報酬コンポーネントの3つの部分から構成されると彼は考えています。
ハーネスは通常移植可能ですが、鍵となるのはオペレーティングシステムです。そのためCursorでは、非常に高いバースト性能を持つ仮想マシンスタック全体を自社で構築しました。これにより、必要に応じて10万台の仮想マシンを瞬時に起動し、モデルに実験させることが可能になりました。
報酬コンポーネントについては、インタビューの中で司会者がRLでどのような報酬シグナルを使用しているのか尋ねましたが、答えは「言えません」「極秘事項」でした。
また、Andre Karpathy氏が以前述べた内容、すなわち「現在のRLは依然として極めて非効率で、長い『ロールアウト』を行った後、最後にわずかな情報しか得られないのは、まるでストローでビットを吸い取っているかのようだ」という点について、彼らがどのように「その経路からより多くのビットを搾り取っているのか」という質問に対しても、守秘義務を理由に回答を控えました。
以下が、今回のポッドキャストの全内容です。お楽しみください。
一桁低いコスト！モデル重みをプログラミングタスクに特化
司会者：今日は、Composer 2の学習がどのように完了したのか、お二人が共にどのような難題を克服したのか、そしてそれがAIや基盤モデル企業の未来にとって何を意味すると思うかについて、お話を伺えることを嬉しく思います。
Federico / Dmytro：ワクワクしますね。ええ、とても興奮しています。お招きいただきありがとうございます。
司会者：ご参加ありがとうございます。あまり注視されていない方々のために説明すると、Cursorは最近、長期的なコーディングタスクに特化したエージェント型コーディングモデル「Composer 2」をリリースしました。Federico、それ以前は、Cursorは主に他社のコーディングエージェントを支援する立場でした。CursorがこれほどまでにComposer 2の研究開発に注力するに至ったきっかけは何だったのでしょうか？単なるアプリケーション層の企業から、独自の基盤モデルを保有する企業へと変貌を遂げることは、御社にとってどれほど存続に関わる重要な意味を持つのでしょうか？
Federico：私たちが自社モデルの学習に着手した理由は、モデルを一種のストレージドライブとして捉えることができるからです。その重みには一定量のビットを格納できます。考え方は非常にシンプルで、私たちは一つのタスクだけを気にしています。広義のコーディングやプログラミング全般でさえなく、Cursor内部のソフトウェアエンジニアリングだけであり、しかもCursor内部だけに限定しています。では、モデルの重みに格納できるすべての情報ビットを、完全にこの特定のタスクだけに割り当てたらどうなるでしょうか？さらに、皆さんもお気づきかもしれませんが、ComposerのコストはOpusや他の類似コーディングモデルよりも一桁低いです。これは、モデルの全重みをその特定のタスクに特化させることで、より小さなモデルや類似のものを提供できるからです。
Dmytro：その通りです。
司会者：なるほど。つまり、保有する重みのビットや情報の一つひとつが、目前の特定の問題解決に集中するようにする、ということが核心なのですね。
Federico：まったくその通りです。
司会者：なるほど。これはほとんど一般化できる問題のように聞こえますね。Dmytro、あなたの考えをぜひ聞きたいです。すべてのアプリケーション層の企業が、Cursorを未来の道標と見なすべきだと思いますか？彼らは皆、同じことを試みるべきでしょうか？
Dmytro：はい、絶対にそうすべきです。私が言いたいのは、これはアプリケーション進化の普遍的なパターンだと一般的に考えられています。プロトタイプから始め、既存のモデルを使ってプロジェクトを動かすかもしれません。プロンプトエンジニアリングを行い、ハーネスがどのように機能するかを理解するでしょう。しかし、あなたのアプリケーションで最もレバレッジの効く特性は、実際にはユーザーデータの活用方法や、アプリの動作方法の特定の次元、例えばフレームワークの特定の側面、提供するツール、アプリの動作の仕組みなどであり、これらはアプリにとって極めて重要です。これらを捉えるには、プロンプトでは少しだけ可能ですが、本当に正しい方法は、完全にあなたの特定の環境で動作するモデルを作り上げることです。
Federico：ええ、まったくその通りです。例えば、エージェントが呼び出す特定のツールについて、そのツールの動作を簡潔な言葉でモデルに正確に記述するのは難しいです。しかし、ポストトレーニングを通じて、これらのツールを使う最善の方法をモデルに直接焼き付けることができます。Composerも同様で、確かにプロンプトを提供していますが、私たちの学習方法からすれば、プロンプトがなくても正常に動作し、何をすべきかを理解していると思います。なぜなら、学習プロセス全体を通して、私たちは本質的に、モデルを本来あるべき正しい方向へと常に推し進めてきたからです。
Dmytro：プロンプトエンジニアリングで達成できることには上限があります。真に優れたAI製品を作りたいなら、ファインチューニングを経てモデルの動作に影響を与えなければなりません。理由の一つはそれです。第二の理由は、コストと速度のトレードオフです。Fireworksでの私たちの見解では、最適化を試みる際、品質、速度、コストの間で三次元のトレードオフに直面します。最初はインフラを最適化するだけでかなり進歩できますが、モデル学習に介入し始めると、そのトレードオフをさらに推し進め、はるかに低コストで、非常に高速に動作する、より優れたモデルを手に入れることができます。Composerはその好例です。
司会者：その点についてもう少し掘り下げて質問してもいいですか？このアプローチは、「苦い教訓」という教訓に合致するのかどうかをお聞きしたいのです。ここに来る前、私たちは実際にTabnine（AIプログラミングアシスタント）について話していました。LLM（大規模言語モデル）時代が到来する前、このような小規模で特化型のコーディングモデルが多数存在していたのを覚えています。しかし、多くの人を驚かせたのは、モデル規模が拡大するにつれて、単にインターネットや大量の英語テキストなどで学習させるだけで、モデル自体のコーディング能力も自然と向上していった点です。少なくとも私がこれまで見てきたトレンドは、より大きなモデルはコーディングを含むすべてのことをより上手くこなせるようになる、というものです。あなた方がおっしゃっていることは、「苦い教訓」という大きなトレンドに逆行しているのではないでしょうか？
Federico：そうは思いません。ただ一つ指摘すべきは、各研究所が学習する大規模モデルも、コードデータに多大な学習リソースを投入している点です。コードは研究所が最も推し進めたい中核的なタスクの一つです。なので、大規模モデルが単に自然にコーディングへ汎化しているわけではなく、それ自体が一定の特化を遂げているのです。私たちのケースで言えば、「苦い教訓」を信じるなら、私たちはデータの次元で大きく推し進めていることになります。モデルの容量は本質的に有限であると理解しているので、もし全ての容量を使い果たしたいなら、データ規模を拡大する必要があります。そして、より多くのデータを注入するために、モデルの重みを潜在的な干渉から解放する必要があるのです。
司会者：なるほど、非常に興味深いですね。では、Composer 2の学習について深く掘り下げていきましょう。
二軸の学習が力を与え、RLがモデルをCursor環境と正しいコード記述に習熟させる
司会者：数週間前にリリースされましたが、すぐに注目の的となりました。強力なベンチマークスコアと、はるかに低い推論実行コスト。Composer 2がどのように機能し、なぜこれほど優れたパフォーマンスを発揮するのか、その簡略版を紹介していただけますか？
Federico：私たちは非常に強力な基盤モデルからスタートしました。それがKimi 2.5です。これは総パラメータ数1兆、アクティブパラメータ300億のモデルで、非常に疎です。私たちは実際に技術スタック全体を精査し、主に二つの軸があることに気づきました。Composer 1は主にその一つの軸、すなわち強化学習（RL）に注力していましたが、Composer 2は二つの異なる軸を同時に推し進めました。一つは継続的事前学習、もう一つは強化学習です。この二正面作戦こそが、Composer 2を非常に優れたものにした理由です。私たちは学習初期に、大量のコードトークンに対して、事前学習に迫る規模の「中期学習」を実施しました。そして、この中期学習の終了後、チェックポイントを取得し、膨大な数のタスクに対して非常に大規模な強化学習を実行しました。
司会者：なるほど。その前提は、Cursorは非常に多くの興味深いコーディングトークンの中心に位置しているため、事前学習に近い規模で学習を行うための、非常にユニークなデータアクセスの優位性を持っている、ということですね。
Federico：ええ。
司会者：それなら、なぜ自社でモデルを最初から事前学習しないのですか？
Federico：私たちはトップダウンで手法を考え、ボトムアップでは考えない習慣があります。言い換えれば、「どうすれば最短時間で、ユーザーにとって有用なモデルを提供できるか？」です。最下層から始めて、まず事前学習の方法を模索し、それを中期学習へと拡大し、中期学習を理解した上で強化学習を行う、という手順を踏んでいては、モデルをユーザーに届けるまでに非常に長い時間がかかってしまいます。逆の手順で進めることで、極めて短期間でユーザーに有用なモデルを提供できたのです。もちろん、次のComposerのバージョンは、オープンソースの基盤ではなく、完全に自社開発のモデルになることを期待しています。
司会者：なるほど。では、あなた方にとって、モデルは中期学習段階で主に何を学び、ポストトレーニング段階では何を学ぶのでしょうか？
Federico：中期学習では、主に様々なコードベースや、非常によくある特定のコードパターンを学習します。また、ウェブデータを含む、ある程度の世界知識も学びます。これは本質的に、より広範な分布を作り出し、その後の強化学習がその上で焦点を絞り、洗練させていけるようにするためです。強化学習の期間中、モデルは直接Cursorのハーネスと対話できます。そのため、ある意味で、自分の残りの人生を過ごすことになる『世界』を理解することができるのです。強化学習では、ツールを正しく呼び出す方法、自分が置かれた環境をナビゲートする方法、正しいコードを書く方法を学びます。というのも、中期学習では「コードの書き方」を学んだだけで、それは必ずしも「正しいコードの書き方」を学んだことを意味しないからです。私たちは基本的に正しいコードで学習させようと努めていますが、モデル自体は正誤を区別する方法を知りません。RL段階で私たちが行う中核的なことの一つは、モデルの特性を微調整し、「さあ、これからは常に正しいコードを書かなければならないんだよ」と教え込むことです。
司会者：まったくその通りですね。
Federico：非常に興味深いですね。では、この中期学習後のモデルは、あなた方がTabのオートコンプリート機能で使用しているモデルに似ているのでしょうか、それとも異なるコア能力に属するのでしょうか？
Federico：そうですね、つまり私はこう考えます。中期学習の間、私たちは次のトークン予測を行っているだけです。つまり、次のトークン、そしてその次のトークンをどれだけ正確に予測できるか、ということを行っているのです。
司会者：だとしたら、なぜ直接あなた方のTabオートコンプリートモデルでポストトレーニングを行わないのですか？なぜ異なるモデルで中期学習を行うのですか？
Federico：それはTabが非常に小さなモデルだからです。極めて低いレイテンシを達成するために、非常に高速に動作しなければなりません。基盤モデルにはここに二つの核心的な違いがあります。Tabは非常に小さく、Composerはかなり大きいのです。
RL学習の核心的ジレンマ：セッションロールアウト、モデル更新、計算効率の多次元的トレードオフ
司会者：なるほど。承知しました。どうやら、あなた方がComposer 2に注いだ労力の大部分は、この大規模な強化学習の実行に集中しているようですね。それを分解して説明していただけますか？それには何が含まれ、その過程でどのような困難を解決したのでしょうか？
Dmytro：強化学習を行う場合、それは事前学習や中期学習とは大きく異なります。なぜなら、単に次のトークンを予測するだけでなく、フレームワーク全体、つまり実験全体を実行しているからです。モデルを環境内で行動させ、特定の「ロールアウト」でどの程度うまくやったかを見ます。「ロールアウト」は専門用語です。そして、何かを正しく完了したかどうかに基づいて報酬を割り当てます。これはLLMをジャッジとして使うか、あるいはこのコードが正常にコンパイルできるか、といった検証可能な指標かもしれません。つまり、通常の学習と比較して、他の多くのコンポーネントが必要になります。大規模学習はいまだに必要で、何千ものGPUを編成して順伝播と逆伝播を行い、中期学習や事前学習で行うすべてのことを行う必要があります。しかし、それに加えて、大量の環境を編成し、モデル推論を実行する必要があります。なぜなら、この「ロールアウト」を行う際、実際には本物のCursorセッションを実行しているからです。
司会者：すみません、少し中断しますが、「ロールアウト」とは基本的に、Cursorの全エージェント履歴セッションのことですよね？
Dmytro：はい。これは基本的に、50ターンの対話を行う可能性があることを意味します。モデルが初期プロンプトを受け取り、次にいくつかのツールを呼び出すことを決定し、あなたはそれらのツールを実行し、そしてモデルは大量の他のコードを生成します...これがCursorでエージェントと対話する際の完全なセッションです。学習実行では、このセッション全体をシミュレートし、最終的な報酬を得て、そのシグナルをトレーナーに返し、モデルの重みに組み込みます。つまり、非常に巨大な更新ループを持ち、これらすべての異なるコンポーネントが連携して動作するため、非常に異種混合的です。そして今、あなたはこれらすべてを編成し、高効率、高スループットで実行させようとしています。なぜならGPUは非常に高価であり、経済的に、かつ迅速にモデルを訓練したいからです。
これはそれ自体が非常に興味深い問題であり、アルゴリズムとインフラの交差点に位置しています。なぜなら、システムがどのように共同最適化され、共同設計されるかについて多くのトレードオフが存在するからです。その一つの側面が、いわゆる「非同期パイプライン化」です。核となる考え方は、モデルを段階的に更新しようとすることです。現在のモデルバージョンを保有しており、それを使って多数の「ロールアウト」を実行しようとします。では、これらの「ロールアウト」を実行している間、トレーナーは何をしているのでしょうか？単純なアプローチでは、「よし、今からトレーナーを停止して、大量のセッションを実行しよう」となります。そして、長期タスクの場合、これらのセッションは5分から10分、あるいはそれ以上かかることもあります。「それから結果を取得し、推論を一時停止して、学習に戻り更新を試みる」。これは、バイアスが全く生じないため、理論的なアルゴリズム上は非常に堅牢ですが、システム上は非常に非効率的です。なぜなら、計算能力の半分が常にアイドル状態になってしまうからです。その代替として、これらすべての巧妙なアルゴリズム技術を利用できます。
司会者：ええ。
Dmytro：これらすべてをパイプライン化できます。巨大な工場を想像してみてください。トレーナー工場と、「ロールアウト」工場があり、それらは常に回転しています。「ロールアウト」を行う工場は常に最新のモデルバージョンを取得し、新しいセッションの実行、新しいエージェントセッションのシミュレーションを試みます。一方、トレーナー工場は新しい結果が出るたびにそれを取得し、更新の計算を試みます。つまり、すべてが休みなく前進しています。このトレードオフがアルゴリズム上で異なるのは、シミュレーション環境での特定のテスト「ロールアウト」を完了した時点で、モデルの重みが既に他のデータで更新されている可能性があるからです。つまり、学習の更新間に遅延という「陳腐化」が生じるのです。なぜなら、あなたがシミュレーション環境との何らかの対話セッションを処理し終える時には、モデルは既に変化してしまっているからです。これが興味深い学習ダイナミクスをもたらし、この問題を解決するための賢い方法がいくつかあります。しかし、その裏返しとして、全てのGPU、全ての計算リソースが常にフル稼働し、高効率で動作していることになります。つまり、より多くのFLOPs（浮動小数点演算）を使用しているのです。先ほどお話しした「苦い教訓」の話に戻りますが、これにより計算効率が高まります。
司会者：より短時間でより優れたモデルを手に入れられるのですね。
Dmytro：そうです。非同期操作を行い、完璧な数学的更新を行わないことで数パーセントの効果を失うかもしれませんが、計算能力の半分をアイドル状態にしないことで、それを大幅に補って余りあるのです。ここには深い知識と興味深い相互作用があります。
AIも「小賢しい真似」をする！ モデルが仮想環境で不正をする現象を暴露
Federico：私たちはCursorにおいてパフォーマンスには非常に真剣です。なぜなら、大手研究所と違って、私たちが持つGPUは数百万基ではなく、わずか数万基だからです。ですから、GPUのパフォーマンスを一滴残らず絞り出すために、あらゆる手段を尽くしています。例えば、本番環境ではFP4での学習さえ行っていますし、Fireworksと協力して推論パフォーマンスを向上させています。インフラの特別なところは、それが本質的に事前学習よりも複雑だということです。なぜなら、まず前提条件の一つに過ぎない事前学習インフラがすべて必要です。それに加えて、これらの環境を実行するためのすべてのインフラが必要です。これらの環境は、可能な限りユーザーのコンピュータの実情に近い形でシミュレートされなければなりません。可能な限り近づけることが非常に重要です。なぜなら、時として、モデルは実際に自分が仮想環境にいるのか、それとも実環境にいるのかを察知してしまい、それが強化学習中のパフォーマンスと本番環境でのパフォーマンスの違いにつながるからです。
司会者：モデルが自分が仮想環境にいることに気づき、異なる挙動を示し始めるのを目の当たりにしたのですか？
Federico：ええ、確かにあります。
司会者：それは面白いですね。
Federico：モデルはこう考えるのです。「ああ、私は仮想環境にいるんだ。ここでもっと高い報酬を得るための小賢しいワザを学んだから、試してみよう」と。モデルは不正をするのが凄く好きで、強化学習（RL）はその不正行為を奨励するのが非常に得意なんです。
Federico：そうです。そして、非常に高効率な推論も絶対に必要です。これは極めて重要です。強化学習の過程で、推論で消費されるFLOPsが学習よりもはるかに多いというのは、実は神話です。これは単に、オープンソースの推論エンジンが最適化不足であるために生じているのであり、強化学習自体の特性ではありません。理論上、両者の比率はほぼ等しいはずです。GPUのパフォーマンスを限界まで引き出せば、学習用GPUの約3分の1を推論に割り当てるべきです。なぜなら、学習は実際には3回のフォワードパス（順伝播、データ勾配計算、重み勾配計算）に相当します。一方、推論時に真にクリティカルバッチサイズに達していれば、必要なFLOPs消費は1回のフォワードパス分だけで済むからです。
司会者：なるほど、それがオープンソースの推論エンジンではなく、Fireworksを使うことを選択した理由なのですね。
Federico：はい、つまり、もう一つの選択肢は社内で独自に開発することでしたが、他の皆さんと同じように、私たちのエンジニアチームも限られています。私たちはエンジニアに、推論エンジンの開発プロジェクトを新たに立ち上げさせるよりも、学習の効率と精度を高めることに集中してもらいたいと考えました。
推論学習はグローバル分散配置で、生産用の計算能力の一部も拝借
司会者：なるほど、それはすごいですね。あと、テクニカルレポートで、これをグローバルに分散した方法で行ったと述べていましたね。なぜグローバル分散を選んだのですか？その難しさはどこにありますか？
Federico：はい、理由はいくつかあります。まず、市場で非常に巨大な単一の連続したクラスターを見つけるのは困難です。そのため私たちのアプローチは、一つの主要クラスターですべての学習を実行し、グローバルな学習クラスターを構築することはできませんが、強化学習の推論コンポーネントは、世界中の小規模なクラスターにグローバルに分散して配置できます。Composer 2の学習時には、地理的に大きく離れた合計4つのクラスターを世界中で使用し、生産トラフィックが低い時間帯には生産用の計算能力の一部を活用することさえしました。例えば、当時、私たちは前世代モデルであるComposer 1.5をサービス提供していましたが、ユーザーの利用が最も少ない時間帯に、推論GPUの一部を直接引き抜いて学習を加速させていました。この方法により、単一の連続した大規模クラスターがなくても、簡単に学習規模を拡大できます。これをどのように実現したかについては、Dmytroがもう少し詳しく話せるかもしれません。
Dmytro：そうですね、Fedの話を補足すると、私たちの学習は本質的に非常に異種混合的です。この異種混合性、つまり異なるコンポーネントがインフラに対して異なる要件を持つことを活用することで、実際に効率を大幅に向上させることができ、これはあらゆる場所で何度も証明されているパターンです。具体的には、学習には高度に相互接続されたクラスター、超高速ネットワークが必要で、ロックステップで動作する必要があります。そのため、これらのクラスターは非常に高価で、十分な規模のものを見つけるのは困難です。
基本的に、Composerのような規模の学習では、2倍の規模のクラスターを見つけるのは、現在の規模のクラスターを見つけるよりもはるかに難しいのです。そのため、これらのコンポーネントを分離し、異なる場所に配置できれば、一方ではそこまで大きなクラスターを探す必要がなくなります。他方では、ハードウェア上で異なるトレードオフを行えます。推論にはそれほど高いグローバル相互接続帯域幅は必要なく、より小規模なGPU相互接続で済みます。異なる種類のGPU、さらには異なる世代のGPUを使用し、最適化において様々な工夫を凝らすことができます。最後に、推論は需要に応じて弾力的にスケーリングするのも容易です。まさにその通りで、オフピーク時には、推論リソースプール全体を、実際のユーザーに生産サービスを提供しつつ、強化学習のためのシミュレーション環境を提供するGPUの集合体と見なし、両者のバランスを取ることができます。もちろん、これは非常に興味深いシステムエンジニアリングの問題です。
1TBの学習ステップには、約5分から15分かかります。これは基本的に、5分から10分ごとに、まったく新しい1TBのモデル重みのスナップショットが生成されることを意味します。そこで問題となるのが、これをどうやって非常に効率的に地球の裏側にある別のクラスターに転送するか、です。しかも、前述の通り、このデータの陳腐化が制御不能になるのを防ぐために、迅速に行動しなければなりません。これがおそらく最も興味深い部分であり、私たちが共同で解決した問題です。モデル全体が1TBあるとはいえ、すべての重みが毎ステップ変化するわけではありません。強化学習は、特に学習が進むにつれて、非常に精密な微調整を多く行うからです。実際には、毎回変化する重みのサブセットには非常に規則的なパターンがあり、すべての重みが毎回変わるわけではありません。単一の学習ステップ（例えば10分後）でのモデルの変化を見ると、それらの間のデルタは比較的小さいです。したがって、その特性を利用した圧縮アルゴリズムを作成できます。すると、問題はデータベースシステムのような問題になります。このデルタを取得し、世界中に転送するだけで済みます。このデルタは、モデル全体を転送するよりも20倍小さくなる可能性があり、これによりソリューションが現実的になります。
もちろん、ストレージシステムを中心に一連のメカニズム全体を構築する必要があります。完全スナップショット、増分スナップショット、復元、調整などのメカニズムです。私たちはこれをロスレスで構築することに成功しました。つまり、反対側に転送されたモデルはビットレベルで完全に等価です。ですから、この過程で何か問題が起こる心配は全くなく、しかも非常に高速に動作します。最悪のネットワーク条件下でも、数分以内、通常は1分もかからずに転送が完了します。最も重要なのは、実際の推論で重みの切り替えを行うのに、約30秒の一時停止しか必要としないことです。また、アップロードとダウンロードのシャーディングにより、クラスターの出力帯域幅を完全に使い切りました。このように、システムレベルのあらゆるトリックを駆使することで、陳腐化を低減できます。
これは確かに非常に複雑ですが、それを抽象化し、完全に動作させ、学習アルゴリズムに干渉しないようにすることができます。その見返りとして、この分離能力を獲得し、他のクラスターを活用してこれを行うことができます。これは、強化学習インフラの構築方法に関する従来の常識を覆すものです。従来の常識では、RDMAで相互接続された超大規模なクラスターが必要であり、これは極めて高価で、計算能力の3分の1を学習に、3分の2を推論に割り当てる必要があるかもしれない、とされていました。もちろん、非常に高価なネットワークがあれば、この1TBのデータを迅速に複製するのは容易ですが、それは3倍の規模のクラスターが必要になることを意味します。今、推論エンジンがより最適化されていれば、いずれにせよ効率が向上するため、GPUの数でそのクラスターの計算能力の3分の1を節約できます。そして、このクラスターの半分を他の場所に配置し、他のリージョンのより安価なハードウェアを使用することで、コストを大幅に削減できます。
浮動小数点演算の不確実性が、MoEモデルのRL学習における致命的な落とし穴に
司会者：この話をしている時の皆さんの笑顔がとても印象的です。本当に難しいことですからね。これはシステムエンジニアの夢ですよね？皆さんが構築したこのシステムは本当に驚くべきものです。
Dmytro：このために、私たちは何度も徹夜しましたよ。
司会者：ええ、かなり長い間肩を並べて戦ってきたことがわかります。話を戻しますが、最初の方で、Kimiは非常に巨大な疎なモデルだとおっしゃっていましたね。それは強化学習の実行を困難にしますか？具体的にはどのように？
Federico：推論を行うとき、あなたは本質的に自己回帰的なフォワードパスを実行しています。このフォワードパスで、モデルはサンプリングしたトークンの対数確率を生成します。これらの生成されたサンプルをトレーナーに送り返すとき、私たちはそのフォワードパスを再実行しなければなりません。なぜなら前述の通り、私たちは非同期学習を行っており、これらのサンプルを生成したモデルのバージョンは、実際にはトレーナーの現在の進捗よりも数ステップ遅れている可能性があるからです。そのため、対数確率を再計算するためにフォワードパスを再実行する必要があります。ここでの難題は、理論的にはモデルのバージョンが同じなら、これらの対数確率は完全に一致するはずだということです。しかし、同じモデルバージョンであっても、同一のトークンに対して得られる対数確率の値には、わずかな、時には非常に顕著な差異が生じます。これは一般に推論の「数値的不一致」と呼ばれ、現在、混合エキスパートモデルでよく耳にする言葉です。
司会者：それはなぜですか？なぜこんなことが起こるのですか？
Dmytro：主な理由は、根本的に、モデルが実行する浮動小数点演算が非決定的であるからです。
司会者：すみません、話を遮りますが、浮動小数点演算が非決定的なんですか？
Dmytro：そうです。学校では、a + b + cを計算しても、c + b + aを計算しても、結果は同じになると習います。コンピューター上で整数を使ってこの計算を行うなら、それは常に成立します。
Dmytro：しかし、もし浮動小数点数を使って計算すると、a + b + cとc + b + aは異なる結果をもたらします。つまり、モデルが実行するすべての操作は基本的に乗算と加算であり、これらの加算が累積される順序が最終結果に影響を与えるのです。これらは微小な差異ですが、数千、数十億回もの演算を経ることで、差異は増幅されます。通常の推論では、これは通常あまり重要ではありません。事前学習されたモデル自体の頑健性が高いため、たとえ数ビットが反転しても、依然として良好な結果を出力でき、ベンチマークスコアも変わりません。
しかし、強化学習では、非常に微弱なシグナルでモデルを教導しているため、この数値的差異によるノイズが学習の成否を左右する可能性があります。これは特に重要です。これもまた、アルゴリズムとシステムレベルの興味深い交差点です。なぜなら、美しい数式を書けても、実践ではそれが機能しないからです。この差異をほぼゼロにまで減らす方法がいくつかあります。例えば、「バッチ不変」アプローチを採用することです。これは、すべてのGPUカーネルを非常に注意深く記述し、常に同じ順序で数値を加算させ、順序をa + b + c以外にしないようにすることです。これは完全に実行可能ですが、常にトレードオフを伴います。たとえば、システムが2倍から3倍遅くなる可能性があります。これは興味深いトレードオフになります。どの程度のパフォーマンス低下なら許容できるか？例えば、10%（実際には数パーセント程度）の速度低下を受け入れることで、数値的差異の90%を解決する、といった具合です。これが、私たちが継続的な反復を通じて共に見つけた最適なバランスポイントです。
先ほど触れた通り、スパース性はこれを特に困難にします。その理由は、混合エキスパートモデルの動作方式にあります。つまり、各層の活性化値を取得し、それをゲーティング層に送り込みます。ゲーティング層は基本的に、「現在のトークンに対して、384のエキスパートからどの8つを選んで実行するか」を決定します。何らかの数学的計算を行い、スコア上位8つのエキスパートが活性化され、他のエキスパートはそのトークンに対してアイドル状態を維持します。この操作は、微小な数値的差異を極端に増幅させる可能性があります。なぜなら、隠れ状態に小数点以下第5位という極めて微弱な差異しかなかったとしても、それは通常は無害ですが、その差異が原因で、切り捨て時にエキスパート番号7ではなくエキスパート番号9が選択されてしまう可能性があるからです。その結果、突然モデルのまったく異なる部分が活性化され、以前の差異が深刻に増幅されます。
したがって、MoEモデルは定義上、このような数値的不一致に対してはるかに敏感です。通常の推論を行う場合、これは通常問題にならず、平均化すれば相殺されます。しかし、これに基づいてモデルを学習させようとすると、この差異は致命的なほど大きくなります。なぜなら、推論時に活性化したのはエキスパート番号7なのに、学習更新時には、推論中には全く寄与しなかったエキスパート番号9を更新しようとしてしまうからです。
司会者：それで、当時は手作業でGPUカーネルを書いてこの問題を解決したのですか？
Dmytro：そうです。スループットに関する多くの問題を解決できますが、そこには常にトレードオフが存在します。特にMoEに対しては、「ルーターリプレイ」と呼ばれる興味深いテクニックを使えます。基本的に、推論エンジンからトレーナーに対し、「ねえ、このトークンに対してエキスパート7を活性化したよ」といった追加情報を渡すことができます。この非常に小さな情報は、どのエキスパートが活性化されたかを示す単なる整数であり、トレーナーはそれと整合性を保つことができます。多くの数値的整合化作業は基本的に、量子化レベルやカーネルを一致させるなどの同様のトリックを用いて、学習時と推論時の実装間の乖離を最小限に抑えます。これは大きな違いを生み出します。さもなければ、学習全体が完全に発散してしまうか、この不一致を補うためにはるかに多くのデータが必要になり、計算効率が大幅に低下してしまいます。
オフラインRLが土台を築き、悪いユーザー体験の発生を防ぐ
司会者：あなたたちの強化学習の具体的なスキームについてもっと詳しく聞きたいです。どのような報酬シグナルを使用しているのか、少し教えていただけますか？それとも、話せませんか？わかりました、話せないのですね。了解しました、機密事項ですね。完全な機密事項。わかりました、それは理解できます。
では、シミュレーション環境での学習はシミュレーションによる「ロールアウト」を実行するのと同等ですが、あなたたちは学習に利用できる膨大な量の実際のユーザーデータを持っているのに、なぜ実際のユーザーデータと実際のユーザー環境フレームワークで直接強化学習を行わず、シミュレーション環境で行わなければならないのですか？
Federico：実は、私たちはそれも行っています。これが私たちの言う「リアルタイム強化学習」です。私たちは同じ技術を使い、Fireworksを通じて推論の重み同期を実現しています。モデルが生成したコードに対してユーザーが満足したか、あるいは失望したかといったユーザーシグナルをキャプチャし、そのモデルをリアルタイムで更新することができます。これにより、数時間ごとに連続して新しいバージョンのモデルを提供できます。私たちはこのサイクルを短縮しようと努めています。しかし、実際には将来のある時点で、このサイクルを再び延長しなければなりません。なぜなら、モデルのコンテキスト期間がますます長くなるにつれて、その時間を再び引き延ばさざるを得なくなるからです。これは興味深い駆け引きです。目下、安定性のためにサイクルを短縮して正しいハイパーパラメータを模索しており、ハイパーパラメータを固めた後は、これらのモデルの長期的な処理能力をさらに伸ばすために、再び時間を引き延ばさなければなりません。
司会者：これほど多くの実際のユーザーデータがあるなら、それは学習やファインチューニングにとって間違いなくより価値があるはずだと思います。では、事前学習段階のようなシミュレーションによる強化学習を行う必要はまだあるのでしょうか？なぜ直接オンライン強化学習（オンラインRL）段階に移行しないのですか？なぜオフライン強化学習を行わなければならないのでしょうか？
Federico：現在のオンライン強化学習は非常に非効率です。私たちが直面している問題の一つは、GPUが基本的に長時間「オフライン」でアイドル状態になってしまうことです。それに加え、効率性とユーザー体験の間には異なるトレードオフが存在します。シミュレーションを行う場合、実際には同じプロンプトに対して複数回の「ロールアウト」を実行できます。つまり、あるタスクを選び、モデルに同じプロンプトから16回、あるいは128回の異なるロールアウト経路を試させるのです。そのうちのいくつかはうまくいき、他のものはうまくいかないでしょう。複数のロールアウトを並行して実行することで、極めて高精度なシグナルを得ることができます。例えばGRPOのようなアルゴリズムは、複数のロールアウトを同時に行うことで機能します。一方、オンラインで実行する場合、一度に一つのロールアウトシグナルしか回収できないため、アルゴリズムの実装において大きなトレードオフの違いが生じます。最も重要な点は、シミュレーションによるロールアウトが失敗したとしても、それは大したことではなく、せいぜいGPU時間を無駄にしただけです。しかし、実際のユーザーを相手にする場合、最低限の基準ははるかに高くなります。なぜなら、あなたは実際にABテストを行っているのであり、もしモデルが奇妙なものを出力すれば、それは非常に悪いユーザー体験となるからです。
司会者：なるほど、相手が実際のユーザーでなければ、オフポリシーをより頻繁に採用できるのですね。なぜなら、ユーザー体験に影響を与える心配を一切せずに、様々な突飛なアイデアを試せるからです。より多くのロールアウトを実行し、GRPOを使用し、基本的にモデルの性能を、ユーザーの前に出せるだけの十分なレベルにまで引き上げることができるのですね。
Federico：その通りです。私たちは、オフライン段階を通じてモデルに推論の仕方を教えています。実際、私たちが言うオフラインとは、多くの場合DPOのような技術を指し、REINFORCEはオンライン寄りの手法です。オフライン段階では、モデルに推論方法を教え、求める行動パターンを植え付けます。この世界についての新しい情報を注入し、ツールの呼び出し方を教え込もうとします。その後で初めて、モデルをオンラインのユーザー向けに公開するのです。
想像してみてください。もしモデルが酷い出来なら、ユーザーはそもそもそれを使おうとも思わず、フィードバックもくれないでしょう？ですから、オンライン強化学習に投入するには、モデルが一定の水準に達していなければなりません。モデルをリリースする前に、私たち自身がそのモデルに非常に満足している必要があるのです。これが、オンライン強化学習（あるいは私たちが好んで呼ぶリアルタイムRL）のパラドックスです。これを使ってゼロからモデルを作り出すことはできません。なぜなら、まずユーザーがそれを使わなければならないからです。したがって、それ自体が既に十分に優れていなければならず、私たちはオンラインでそれをさらに良くすることしかできません。
（注：DPO（Direct Preference Optimization、直接選好最適化）は、大規模言語モデル（LLM）のアライメント（整合）のための効率的なファインチューニング技術であり、主な目的はモデルの出力を人間の選好（より役立つ、より安全、特定のスタイルに合致するなど）に沿わせることです。
REINFORCEは、強化学習における古典的な方策勾配アルゴリズムであり、Ronald J. Williamsによって1992年に提案されました。）
Federico：はい。これは、ケーキの上のアイシングのようなもので、セッション全体を本当に素晴らしい体験にしてくれます。いつか、それが大きなサクランボになることを願っています。
Dmytro：そうですね。
司会者：そうですね。これは、Dan Robertsが昨年私たちのカンファレンスで発表した内容を思い出させます。あなたもあの場にいたと思います。伝統的には、大きなケーキと小さなサクランボの関係でしたね。
Federico / Dmytro：今は小さなケーキと大きなサクランボですね。その通りです。
司会者：アンドレイ・カルパシーの有名な言葉が気になります。彼は、現在の強化学習（RL）は依然として極めて非効率的だと言っています。非常に長いロールアウトを行い、その最後にほんの少しの情報しか得られない。まるでストローでビットを吸い取っているようなものだと。これについてどう思いますか？その経路からより多くのビットを搾り出す方法を何か見つけましたか？
Federico：それは言えませんね。
司会者：なるほど、わかりました。また機密事項ですね。良い質問をした証拠です。
20万コンテキストウィンドウで100万トークンを扱う！Cursorの秘訣：「自己要約」
司会者：先ほど、ロールアウトには数分かかるとおっしゃいましたね。現在、業界全体が「長期計画型エージェント」の実現に向かっているようです。つまり、エージェントが長時間中断することなく動作し、基本的に失敗しないようにするということです。私はあのメートル単位のスケーリングチャートがとても気に入っています。強化学習のプロセスで、エージェントをより長時間動作させるためには何が必要なのでしょうか？
Federico：いくつかポイントがあります。まず、強化学習の難しい点の一つは、実行軌跡が長くなればなるほど、「信用割り当て」が困難になることです。想像してみてください。モデルがすべての作業を終えた後、最後に「いいね」か「ダメ」を伝えるのです。簡単に言うと、モデルは「私はどこが正しくて、どこが間違っていたのか？」と自問しなければなりません。これが信用割り当て問題です。軌跡が長くなればなるほど、これは難しくなります。そのため、多くのテクニックを駆使する必要があります。もう一つの問題は、スペースが足りなくなることです。これらのモデルのコンテキストウィンドウには限りがあり、いずれ上限に達します。
Cursorでは、ループの中に「圧縮」を組み込むことでこの問題を解決しています。「自己要約」と呼んでいます。強化学習の過程で、エージェントは実際に、どのようにして作業を継続し、永遠に続けるかを学習します。実際には、私たちのモデルは20万トークンのコンテキストウィンドウを持っていますが、実際には数百万トークンを処理できます。これが可能なのは、まさに自分の作業を要約する能力を備えているからであり、その後、その要約を利用してコンテキストウィンドウを再起動しつつ、既定のタスクを完了しようと努力し続けます。この方法により、モデルを目標に向かって正しく進ませると同時に、高品質な要約を生成することと、その要約を完璧に理解することをモデルに共に訓練しているのです。これは推論能力の延長線上にあると言っても過言ではありません。
Dmytro：それは非常に魅力的だと思います。通常、コンテキスト管理はハーネスの一部と考えられていますよね？しかしこの場合、ハーネスの一部とモデル自身の作業を共に最適化し、これらすべてを最適化ループに投入しているのです。AIの分野で繰り返し見られるのは、ある問題に投入する計算量が増えれば増えるほど、それをエンドツーエンドで解決できるようになるということです。「苦い教訓」における計算の魔法が再び効果を発揮し、より良く協調して動作するシステムが得られるのです。
司会者：まったくその通りです。あらゆる企業が独自のハーネス上でRLを実行すると思いますか？すべての企業がCursorと同じ問題形式に直面していると思いますか？
Federico：もしその企業がAIを利用しており、大量のトークンを生成し、最適化すべき製品を持っているのなら、独自のモデルを訓練することこそが正しい施策であり、正しい方向性だと思います。
司会者：なるほど、それは興味深いですね。
RLはモデルに「自分は専門家であり、物事を正しく行う必要がある」と認識させる
司会者：あなた方が行っている強化学習の大部分は、モデルを「コードの次のトークン予測」に長けさせることではなく、ハーネスとツールの使用に集中しているように見えます。強化学習をどこで使うべきか考えている他の創業者にとって、このパターンは参考になるでしょうか？つまり、ツールを使って長期タスクを実行するエージェントを作りたいなら、強化学習が必要。単に要約や次のトークン予測に秀でたモデルを作りたいだけなら、強化学習は必要ないかもしれない。これは強化学習が必要かどうかを判断する良い枠組みでしょうか？
Federico：強化学習はあらゆる場所で有効だと思います。Tabの自動補完においてさえ、私たちは使っています……もちろんこれは根拠のない私の持論に過ぎませんが。モデルを事前学習すると、モデルは人類の知識の集合体全体をただ吸収している状態です。数学モデルを訓練していると仮定しましょう。モデルはStack Exchange上のすべての数学を学習します。しかし、まだ強化学習を施されていないこのモデルが数学の問題に直面したとき、自分が果たすべき役割は何か、自分は専門家なのか、それとも学ぼうとしている学生なのかを考えなければなりません。したがって、強化学習中に起きていることの一つは、モデルに「おい、君は専門家だ。物事を正しくやらなければならない」と伝える、いわばダイヤルを調整しているのだと思います。つまり、変化の一つは、分布を蒸留していることであり、これにはおそらくいくつかの段階があります。第一段階では、モデルは非常に速く学習し、すぐに非常に優秀になります。その後、モデルを継続的に改善するために莫大な計算量を必要とする第二段階に入り、モデルが推論能力を示し、このようなパターンを示し始めます。この曲線の第一段階では、モデルに「ここでは物事を正しくやれ」と伝えるダイヤルを調整しているに過ぎないと思います。したがって、計算量が少ないシナリオでも、モデルに物事を正しく行わなければならないと認識させることは非常に有用です。これが私の考えです。
（注：Stack Exchangeは、複数の専門Q&Aコミュニティからなるネットワークプラットフォームで、各サイトは特定分野に特化し、ユーザーは質問、回答、投票を通じて質の高い知識を共有しています。）
Dmytro：全く同感です。私たちは多くのユースケースでこのパターンを見てきました。多くのお客様の強化学習ファインチューニングを支援してきましたが、一般的に、継続的事前学習と通常の教師ありファインチューニング（SFT）は、抽象的な意味では新しい知識の伝達に近いのに対し、強化学習は行動の洗練、またはモデルに備えてほしい特定の品質の洗練です。通常は両方が必要です。先ほど挙げられた要約の例でさえ、強化学習は非常に役立ちます。特定のスタイルの要約が必要なのに、それを正確に表現する完璧な「良い要約」と「悪い要約」の例を提示するのが難しい場合があるからです。しかし、LLMを審査員として使えば、非常に正確な評価基準を設定できます。プロンプトで「これが要約の良し悪しを評価する私の基準です」と伝え、それを強化学習ループに投入し、モデル自身にさまざまな要約スタイルを試させ、あなたが一体何を求めているのかを探らせ、別の大規模モデルにそれが特定の基準を満たしているかどうかを評価させることができます。このパターンは、コーディングだけでなく、他の分野でも頻繁に見られます。
LLMを審査員として活用、ソフトウェア開発の第三段階：「評価ルールの作成」
司会者：では、次の質問はDmytroさんに。Federicoさんは合衆国憲法修正第5条を主張するでしょうから。先ほど「LLMを審査員として」という言葉が何度か出てきました。最終的に、専門家が手動でRLロールアウトをチェックし、何らかの方法で手動でモデルの行動を導く企業がより成功すると思いますか？それとも、LLM審査員や他の自動評価基準が私たちを目標に導く可能性が高いでしょうか？
Dmytro：実際に専門家に全てのロールアウト経路を直接審査させることなど不可能です。つまり、それは何らかの……実際のユーザー相手ならリアルタイムRLか、あるいはRLAIFやDPOの一形態になるでしょう。総じて、報酬シグナルが検証可能であればあるほど良いのです。なぜなら、それによって計算規模を拡大でき、場合によってはより良い結果が得られるからです。「検証可能」とは、基本的に「人間の介入なしにこのシグナルを自動生成できるか？」という意味です。もちろん、数学やコーディングであれば、非常に確定的なものを設計できるのが最善です。LLM審査員が機能するのは、実際には「生成器と識別器」の違いだからです。判断することは、創造することよりもはるかに簡単なのです。人間にとっても同じですよね？審査員になることは、ベンチャーキャピタリストになるよりもずっと簡単です。
司会者：はは、別に含みはありませんよ。
Dmytro：本当に他意はありません。しかし確かに、審査ははるかに簡単で、回答をランク付けするための異なる基準を正確に設計できます。ご覧になるパターンとしては、複数の次元にわたって非常に複雑な評価を設計することになるでしょう。なぜなら、複数の次元をまとめて一つの大規模モデルに投げてしまうと、どう判断すべきか混乱する可能性があるからです。そこで評価を分解するのです。例えば、この大規模モデルはスタイルで判断し、別の大規模モデルは事実性といった別の側面で判断し、それによってこれらの報酬シグナルを真に作り上げるのです。そのうちのいくつかは確定的なものになり、他のものは大規模モデルに基づくものになります。これがモデルの行動を導くものです。そして、より多くの計算量を投入するだけで、グラフ上の曲線が上昇し続けるのを目の当たりにするでしょう。
司会者：より検証が難しい領域で、強化学習がより顕著な役割を果たすことになると思いますか？LLM審査員で十分だと思いますか？
Dmytro：それは最初に試み始める技術の一つです。理想的には、実際の成果が何なのか、自分が捉えたい真の指標は何なのかを解明したいものです。したがって、この指標を近似しようとすることは一つの方法であり、より大規模なシミュレーション環境を構築しようとすることは別の方法です。より多くの自社製品や環境をシミュレートできれば、通常は自分が気にかけている最終的な指標を得ることができます。ただ、それを捉えるのがより難しいというだけです。それを捉える方法を考え出せるなら、それは素晴らしいことです。その分野の専門家の役割について言えば、専門家は依然として不可欠です。なぜなら、これらのタスクを設計し、製品体験を真にコード化することが極めて重要だからです。私たちはソフトウェア1.0、2.0、3.0を経験してきましたよね？かつては直接ソフトウェアを作成していましたが、その後、訓練データの作成へと移行し、そして今、あなたは実際に評価ルールを作成しているのです。しかし、これは依然として非常に重要です。あなたは例、データ、そして自分の製品がどこで失敗するか、そしてどのようにモデルを正しい行動へ導くかを観察する必要があるのです。
RL環境は三つの要素で構成され、Cursorは仮想マシンスタック全体を自社構築
司会者：強化学習環境についてお聞きしたいのですが、これは先ほどのお話と関連するかもしれません。現在、RL環境を提供する企業の収益規模が急上昇しているようです。彼らは具体的に何を本当に役立つものとして提供しているのでしょうか？Cursorを例にとると、お客様が実際にどのように環境を利用しているかについての膨大なデータを既にお持ちだと思うからです。では、強化学習環境ベンダーは、あなた方が既に持っているものに加えて、何を提供できるのでしょうか？
Federico：実は、私たちはどの環境ベンダーの製品も使用していません。正常に動作する環境を構築するのは非常に難しいと思います。それは、こうしたデータにアクセスできない人々にとっては価値のある製品です。しかし、特にコーディングの分野では、誰もが利用可能な膨大なコーディング環境にアクセスできます。それがGitHubです。そこに行き、モデルにリポジトリのすべての依存関係をインストールさせれば、それが実行可能な環境です。困難の大部分はインフラストラクチャに起因すると思います。想像してみてください。特定のタスクに有効な環境では、様々なサービスを起動する必要があるかもしれません。例えば、データベースの移行のような変更を行っている場合、それが本当に機能するかテストするために、データベースを起動する必要がありますよね？こうしたことは非常に厄介です。これらの環境提供企業は、こうしたことにおいてかなり役立つと思います。
Dmytro：ここには実際には二つの層があります。まず、最先端の研究所を見ると、彼らはあらゆることに長けた汎用モデルを構築しようとしているため、これらの異なる基盤タスクすべてをカバーし、同じモデルにパッケージ化し、それが汎化するように促す必要があります。それが一つの部分であり、そのような場合には非常に役立ちます。しかし、CursorのComposerのようなケースでは、実際の自社製品をお持ちであり、これこそFireworksが信じていることでもありますが、独自の実際の製品を持っているなら、その製品に特化して効果を高めるべきです。最も強力な環境は、自分たちの製品そのものです。全くその通りです。なぜなら、そこがあなたのモデルが実際に使われる場所だからです。
もちろん、最先端研究所であれば、すべての製品にまたがってこれを行うことは不可能ですが、自分の製品に特化し、テーラーメイドで最高のモデルを作りたいのであれば、本番環境を直接用いるべきです。もちろん、適切に隔離する必要がありますよね？モデルに本番データベースをめちゃくちゃにされたくはないでしょうから、クローンを作成するなどの作業が必要です。環境提供企業は、こうしたことをより簡単にするための、汎用インフラのようなツールをいくつか提供しています。しかし総じて、強化学習環境は可能な限り実際の本番環境に近いものにしたいのです。
例えば、私たちが見てきたところによると、おもちゃのようなRLの例やフレームワークは、いつも「ここにおもちゃの環境があります。Dockerコンテナを起動してその中で全部動かしましょう」というところから始まります。これらは、単にモデルにAtariゲームの遊び方などを教えたいだけなら素晴らしいです。しかし、実際に本番のケースに移行する場合、実際の本番アプリケーションをDockerコンテナに押し込めるだけでは不十分です。私たち自身、このことをかなり早い段階で発見しました。例えば、Cursor側でトレーナーを動かすにあたってMetaFoxと協力した時です。また、他のいくつかのクライアントでは、私たちのトレーニングプラットフォーム上でトレーナーを実行していますが、環境に関しては、実装が実際に存在する場所であるクライアント側でデフォルトで実行しています。あなたは実際に、（Fireworksプラットフォームの一部であっても）同じトレーナーセットアップを持ち、それをラップしてコンポーネント化しようとするのではなく、クライアント側で実際の本番環境を呼び出すのです。
Federico：ホスティングプラットフォーム上でこれを行うのは、それが本当に難しく、差異を生じさせるからです。
私たちが「強化学習環境」と呼ぶものは、実際には三つのコンポーネントで構成されています。第一はハーネス、つまりモデルがツールをサブミットし、ツールが実行される場所です。第二は「OS」と呼べるもので、モデルが相互作用する実際の世界と状態です。第三は必要な報酬コンポーネントで、最終的に作業が正しく完了したかどうかをチェックする必要があります。一般的に、ハーネスはかなり移植性が高く、多くの異なる環境に持っていくことができます。重要な部分はOSであり、これを複製するには、通常のコンテナではあまりうまく動作しません。そこでCursorでは、仮想マシンスタック全体を実際に自社で構築し、仮想マシンを非常に迅速に起動できるようにしました。これは極めてバースト性が高くなければなりません。なぜなら、想像してみてください、私たちはこのシステムに「今すぐ10万台の仮想マシンを用意してくれ」と要求するかもしれず、それらがすべて起動しなければならないからです。
司会者：素晴らしい。今日のこの対談を大いに楽しみました。Cursorは、一企業としてアプリケーション層の企業から真の最先端モデル研究所へと進化する方法の模範を本当に示したと思います。Composer 2での取り組みは、まさにこの潮流をリードしていると思います。このような内部事情を聞けるのは本当に特別なことです。Dmytroさん、お二人が無数の深夜に肩を並べ、塹壕の中で共に解決してきた、これらすべてを可能にしたハードコアなインフラの課題について聞くことができて、本当に最高です。ありがとうございました。本日は私たちのポッドキャストにお二人をお迎えできて光栄です。
Federico：お招きいただき、本当にありがとうございます。
Dmytro：ありがとうございます。
参考リンク：