オーティマンはポッドキャストで、OpenAIがSoraではなくCodexにリソースを集中させる理由を明かした。Soraのビデオ生成には大量の連続的な計算リソースが必要で、単一のタスクがGPU時間を占有し、再利用が困難である。一方、CodexはKVキャッシュ、継続的バッチ処理、ツール呼び出しなどのメカニズムにより、計算リソースを複数の重複可能な段階に分散させ、同一のGPUでより多くの並列ワークフローを支えることができる。GPU時間の再利用能力が、AI製品の拡張速度を決定し始めている。

記事執筆者、出典：雷峰網

SoraはなぜCodexに負けたのか？

8月23日、オーティマンはDavid SenraのポッドキャストでOpenAI内のリソース配分について語る中、自らSoraに言及した。

彼は率直に言いました：Sora自体は良い製品であり、継続すれば立派なビジネスにもなるが、コンピューティングリソースをあまりにも大量に消費する。その一方で、Codexの優先度が更高であったため、計算資源とチームの投入はCodexにシフトし始めた。

しかし興味深いことに、CodexはGPUをまったく節約しません。Soraが動画を生成するには、巨大な時空間潜在変数が複数回のTransformer計算を経る必要があります。一方、Codexが「このバグを直して」という指示を受け取ると、バックグラウンドでは複数回にわたって推論を実行し、コードを読み取り、ツールを呼び出し、テストを実行し、新しいログとコンテキストを伴って再び推論を繰り返します。

一つは計算能力を単一の動画生成に集中させ、もう一つは数十分、あるいはそれ以上続くエージェントワークフローに計算能力を分散させる。そのため、SoraとCodexの真の差異はデータセンター内部で現れ始める。

同じGPUのセットでも、なぜビデオ生成の計算リソースは分散しにくく、一方でCoding AgentはKVキャッシュ、連続バッチ処理、prefill/decodeスケジューリング、ツール待機によって計算能力をより多くの並列タスクに再配置できるのか？

実際、Soraは計算リソースの絶対値で劣っているのではなく、ワークロードアーキテクチャで劣っているのです。Soraの計算リソースは連続的で独占的ですが、Codexの計算リソースは断片的で再利用可能です。このスケジューリングメカニズムの差が、両者の拡張速度の差を生み出しています。

この線を下に見ると、Soraが失ったリソースの部分の背後には、GPU時間を使い方に関する選択があるのかもしれない。

Soraのコストは、ビデオがモデルに取り込まれた時点で既に膨らみ始めている可能性がある。まず原始ビデオをlatent spaceに圧縮し、次にspacetimeパッチに分割して、Transformerがこれらのパッチ上で計算を行う。

テキストトークンは主にシーケンス方向に成長し、ビデオパッチは時間、高さ、幅のすべてに同時に配置されるため、ビデオはモデル内部で天然に体積を持つ状態となります。

大まかに見ると、ビジュアルトークン数はN_video ≈ T × H × Wと理解できます。ここでT、HおよびWは圧縮およびパッチ化されていますが、三次元の乗法関係は依然として存在します。

動画の長さを延ばすと時間方向のパッチが増加し、画面上のサイズを上げると空間パッチが拡大します。つまり、動画の長さと空間サイズはコストを独立して増加させるのではなく、一緒にレーテントグリッドを拡大します。

このグリッドがTransformerに投入された後、diffusionによってもたらされる第二層の計算に直面します。Soraはノイズを含むlatentから開始し、各ラウンドで現在の状態に基づいてビデオ表現を更新し、新しいlatentを次のラウンドに送ります。

単一動画の計算量は大まかに C_video ≈ D × C_transformer(N_video)と理解できます。ここで Dはサンプリング反復回数を表します。動画のlatentが大きいほど、各反復の負荷が高くなり、サンプリング回数が増えると、同じ動画に対してネットワークをさらに複数回実行する必要があります。

ここでは、ビデオディフュージョンとLLMの重要な違いがわかります。言語モデルが次のトークンを生成する際、前のKeyとValueはKVキャッシュに保存され、モデルは各ステップで過去の状態全体を再構築する必要はありません。

ビデオディフュージョンが1ラウンド更新を完了するたびに、メインの潜在変数はすでに変化しており、次のラウンドでは新しい時空状態に直面するため、ビデオのメイン要素に対する大量の計算を継続して実行する必要があります。

したがって、Soraのコストは「履歴の再利用」によって大幅に削減するのは難しいです。これは、毎回変化した全体の画像を処理するような映像エフェクトの複数回の加工に似ています。動画が長くなるほど、解像度が高くなるほど、サンプリング回数が増えるほど、この生成パスはより重くなります。

単一タスクが十分に重いため、SoraのGPU利用率はむしろ良好になる可能性があります。大規模な行列計算により、Tensor Coreが長時間稼働し続け、モニタリングチャートではGPUがほとんど空いていない状態になります。

利用率が高いということは、チップが常に動作していることを示すだけで、単位時間あたりに多くのタスクを完了したことを意味しません。1本の動画が一組のGPUを長時間占有している場合、利用率がどれほど良好でも、1リクエストあたりのGPU-secondsは依然として高くなります。

動画のサービングは、形状の違いにより引き続き遅延します。長さ、解像度、アスペクト比が異なると、異なるテンソル形状が生成されます。サーバーはバッチ効率を向上させるため、近いサイズのリクエストを同じバケットにまとめます。もう少し待つことでより多くのリクエストをバッチにまとめられますが、待ち時間は長くなります。すぐに実行すれば待ち時間は短縮されますが、バッチが満杯にならない可能性があります。

したがって、Soraの大部分の計算コストは、1本の動画の生成パス自体に固定されています。サンプリングラウンド数を減らしたり、latentをさらに圧縮したり、モデルを蒸留したり、カーネルを最適化したりすることは可能ですが、スケジューラが変更できるのは主に「これらの重いタスクをどのように並べるか」だけであり、「1本の動画には大量の連続計算が必要である」という事実自体を変えるのは難しいです。

これはCodexを理解する入口でもあります。Codexも同様に高価ですが、すべてのコストを1つの連続計算ブロックに押し付けるのではなく、タスクを一時停止、再開、再結合可能な複数の段階に分割しています。

ユーザーがCodexに「このバグを直して」と指示しても、タスクは1回のモデル呼び出しで終わらない。エージェントはまずリポジトリを読み取り、モデルに次のステップを判断させ、シェルを実行する。エラーが発生したら、ログをコンテキストに追加してモデルを再呼び出しし、その後コードを修正してテストを実行し、新しい結果に基づいてさらに推論を続ける。

したがって、Codexのタスクは多くのラウンドに近いPrefill + Decode + Toolの累積である。重要なのは、各ツール呼び出しのラウンドが完了するたびに、次のラウンドでモデルが見るコンテキストは以前のラウンドよりも常に厚くなるということである。

タスク開始時、モデルにはユーザーの要求とわずかなコードしかありません。しばらく実行すると、さらに多くのファイル、diff、ターミナル出力、テストログ、ツールの結果がpromptに追加されます。

ユーザーが最後に見るのはおそらく数百文字の完了説明だが、GPU が途中で処理した内容はすでに非常に膨大になっている可能性がある。Agent token 消費の負荷は、この絶えず増加し続ける作業履歴の中に隠れている。

各イニシャライズごとに履歴全体を再処理すると、長時間タスクは繰り返しのprefillにすぐに遅延するため、プロンプトキャッシュはCodexにとって不可欠です。

あるエージェントがすでに100Kトークンのコンテキストを保持していると仮定し、ツール実行後に新たに3Kトークンのログが追加された場合、前の安定したプレフィックスがキャッシュにヒットすれば、今回の追加計算は主に後半部分に集中する。一方、プロンプトの前部が変更されてキャッシュミスが発生すると、システムは再び重いprefillに直面する可能性がある。

重要な変化が発生しました：論理トークン数はもはや実際のGPUコストを直接示すことができません。両方のリクエストが100K入力トークンを表示していますが、一方は大部分がキャッシュ済みで、他方は再計算が必要です。これらはGPUへの負荷が全く異なります。したがって、Agentの負荷はコンテキストの増加速度、キャッシュヒット率、およびタスクがモデルに何回繰り返し入力されるかに依存します。

単一のインファレンスに入ると、prefill と decode では異なるハードウェア要件が生じます。prefill は多数の入力トークンを一度に処理し、行列サイズが大きいため、計算負荷が高くなりやすいです。一方、decode は各シーケンスごとに1ラウンドでわずかにトークンを生成しますが、モデルの重みやKVキャッシュを繰り返しアクセスするため、HBMの帯域幅と並列処理能力により依存します。

これは、単独で1つのシーケンスをデコードすると非常に非効率であることを意味します。モデルの重みは依然として大きく、1つのトークンを生成するためにも完全なフォワード計算が必要です。サーバーは複数のシーケンスを同じバッチ化されたフォワードにまとめて投入することで、1回の重みアクセスで複数のリクエストを同時に処理できます。

一方、バッチサイズをさらに増やすことは、KVキャッシュの制約によって制限されます。各シーケンスのコンテキストが長くなるほど、HBMをより多く消費します。エージェント数を増やした後でも、GPUには計算リソースの余裕が残っている可能性がありますが、メモリにはより多くのアクティブなステートを収容できなくなっています。

PagedAttention などの設計は、KV キャッシュをページ単位で管理することでバッファフラグメンテーションを削減し、本質的には1つのGPUが同時に処理できるアクティブなシーケンス数を増加させます。

ツールの呼び出しにより、Codexの負荷をさらに分割します。Agentがテストを実行したり、コードをコンパイルしたり、I/Oを待ったりしている間、GPUはその処理を継続する必要がなく、CPU、コンテナ、ファイルシステムが引き継ぎます。結果が返ってきたら、このAgentは次の推論ラウンドに入ります。

60分間実行されるAgentは、60分間GPUを占有することを意味しない。そのタスク時間はモデル計算と外部実行の2つの部分に分割されており、これによりスケジューラーはSoraでは得にくい空間を手に入れる：あるAgentがツールを実行している間、GPUはすぐに他のシーケンスにサービスを提供できる。

もちろん、これにより新たなVRAMの問題が発生します。ツールのエージェントはKVキャッシュを保持すべきでしょうか？保持すれば復帰が速くなりますが、HBMを長期的に占有します。排除すればスペースが確保できますが、タスクが再開する際に復帰コストがかかります。エージェントの数が増えれば増えるほど、このようなトレードオフは、オペレーティングシステムが多数のスリープとウェイクアップを繰り返すプロセスを管理するようなものになります。

ここで、CodexとSoraの違いは「どちらが重いか」ではなく、計算コストが分離されているかどうかにある。Soraの計算リソースは連続した生成パスに集中しているのに対し、Codexの計算リソースは複数の段階に分散している。正是由于被拆分，Codex才能进入下一层优化：让scheduler决定这些阶段怎样共享同一批GPU。

大規模モデルをオンラインで実行する際、重みは通常、GPUに長期的に保持され、テンソル並列、ノード間通信、キャッシュ状態も維持されます。したがって、SoraとCodexのリソース競合は、フェリーレベルで発生することが多いです：一部のGPUは長期的にビデオサービングプールに、另一部は長期的にLLMプールに割り当てられ、上位の容量システムがどちらを拡張し、どちらを縮小するかを決定します。

真正に複雑なことは、Codex pool 内で発生しています。システム内に同時に200のAgent sequenceが存在し、その一部はデコード中、一部はツールを待機中、さらに数十本はツール環境から戻ってきて、新しい長文コンテキストを処理する必要があると仮定します。スケジューラが直面する制約は、FLOPsだけでなく、HBM容量、メモリ帯域幅、KVキャッシュの保持時間、レイテンシーバジェットも含まれます。

Continuous batching は、まず decode の利用率の問題を解決します。従来の静的バッチでは、一連のリクエストが束ねられ、短いシーケンスが終了しても、残りの長いリクエストがバッチを占有します。

Continuous batching はトークン反復レベルで動的に入替を行い、1つのシーケンスが完了すると即座に排出され、新しいリクエストが直ちに補充されます。バッチが大きくなるほど、1回のモデル計算で進捗させられるシーケンス数が増え、モデル重みのアクセスとメモリ帯域幅のコストをより効率的に分摊できます。

しかし、ここではすぐにVRAMの壁に突き当たります。大量の長距離AgentのKVキャッシュがHBMを継続的に占有し、GPUのTensor Coreが十分に使用される前に、VRAMにさらにシーケンスを格納できなくなる可能性があります。この状況で計算能力をさらに増やしても意味がなく、並列処理を制限しているのは実際にはキャッシュ容量とVRAM管理です。

Prefillとdecodeの間には別の競合が存在する。数十のシーケンスが安定してdecodeしている際、100Kトークンの新しいコンテキストを伴ってエージェントが戻り、大規模なprefillを実行する必要があるとする。このprefillが長い実行ウィンドウを占有すると、隣接するリクエストのTPOTが顕著に悪化する。

チャンク化されたプリフィルは、長い入力を複数の小さなチャンクに分割し、プリフィルとデコードを交互に実行します。さらに進んだ方法としては、プリフィルとデコードを異なるGPUプールに分割します。

理由は、この2つのステージがそれぞれ異なるハードウェアボトルネックに依存しているためです。prefill は計算スループットに依存し、decode は HBM バンド幅、KV キャッシュ、および安定したトークンごとのレイテンシーに依存します。これらを分離することで、それぞれの要件に応じてリソースを最適に配置できます。

これは、Agent サービングのコアが「モデルカーネルをより速く書く」こと以上であることを示している。多くの容量向上は、タスクをいつ実行し、どこで実行し、どの状態をVRAMに残す価値があるか、そして現在のバッチに誰を含めるべきかを再配置することから生じている。

したがって、GPU利用率はここで十分ではありません。容量チームは、タスクあたりのGPU秒数、TTFT（最初の文字遅延、ユーザーが遅延を感じるかどうかを決定）、TPOT（1文字生成時間、モデルの応答速度を決定）、キュー遅延、プレフィックスキャッシュヒット率、KVキャッシュ占有率、およびSLO有効スループット（実際の収益化可能な計算能力を示す）を同時に確認する必要があります。

これらの指標は、ユーザーが許容できる遅延の範囲内で、1時間あたりのGPUが維持できる有効タスク数という問いに答えます。

Codexのスケジューリング性はここに現れます。安定したプレフィックスは繰り返しのprefillを削減し、decodeは連続バッチ化が可能で、KVキャッシュはページングと追放ができます。Agentがツールを待つ間もGPUを解放できます。ワークロードは非常に細かく分散していますが、これらの断片はスケジューラーによって再編成可能です。

これは問題をリソース層へ自然と押しやります：同じGPUのセットがより多くの長期エージェントを交互にサービスできる場合、1時間のGPUは実際には1時間以上分の作業を支える可能性があります。

あるCodexエージェントがタスクの受信から完了までに合計60分を要すると仮定した場合、そのうち実際のモデルのprefillとdecodeに費やされる時間は一部にすぎず、残りの時間はコンパイル、テスト、ファイルの読み書き、またはツールの待機に使用されます。この比率はタスクによって異なりますが、構造が重要です：エージェントのウォールクロック時間とGPU計算時間は1対1ではありません。

システム内に多数のAgentが存在しても、それらが同じ秒間に同時にGPUを必要とすることはありません。誰かがprefill中であり、誰かがdecode中であり、誰かがテストを実行中であり、誰かがファイルシステムを待機しています。スケジューラがこれらのステージを交互に処理できれば、限られたGPUでGPU数よりもはるかに多くのアクティブなワークフローを維持できます。

この関係を大まかに理解すると、Agent-hoursはGPU-hours、モデル推論のデューティサイクル、スケジューリング効率に依存します。ツールの実行時間が長くなり、バッチが厚くなり、キャッシュヒット率が高くなるほど、1時間のGPUがより長いAgentのウォールクロック作業を支える機会が増えます。

これは、追加されるGPUの意味を直接変更します。Codexに一括でGPUを追加すると、単一のタスクがより速くなるだけでなく、システムが同時に複数のエージェントを維持できる可能性もあります。エンジニアは、複数のタスクを並列で起動できます。たとえば、バックエンドの修正、テストの補完、別のリポジトリの処理など、これらのタスク間に強い依存関係がなければ、マシンの作業時間は並列に増加します。

Soraの容量曲線はより直接的である。1本の動画の長時間のウォールクロック時間自体がGPU上でdiffusionを進めており、単一タスクとGPUの使用率がより密接に結びついている。追加のGPUは動画のスループットを直接増加させることができるが、1時間のGPU時間と動画計算時間の間の関係を大きく引き離すのは難しい。

Codexのソフトウェアタスクは、GPU、CPU、コンテナ、ファイルシステム、ツール環境の間を移動する。GPUはモデル推論を担当し、他のシステムは実行を担当し、複数のエージェントがスケジューラーを通じて推論能力を交互に共有する。その結果、GPUは単なる生成デバイスから、エージェントシステム全体における希少な「思考リソース」へと変化した。

これが、Codexが同じくらいの計算リソースを消費するにもかかわらず、新しい計算リソースをより容易に獲得できる理由です。OpenAIが見なければならないのは、単一の推論コストだけでなく、追加のキャパシティが迅速に並列処理の負荷に変換できるかどうかです。

GPUの一批がより多くの長期エージェントを支え、それらのエージェントが継続的に新しいソフトウェアタスクを受け取れるようになると、リソースはこの方向にさらに流れやすくなります。

アルトマンのその発言の技術的意味も明確になった。Soraの膨大な計算リソースは単一の生成パスに固定されているのに対し、Codexの計算リソースは複数の交差可能な段階に分割されている。両者は同じくらい高価だが、リソースの収益曲線は異なる。

SoraとCodexのリソース移行に関する説明では、AI製品に、拡張速度に直接影響する新たな変数であるworkload architectureが加わった。

同じ高価なGPUを使用しても、あるタイプのタスクは大量の計算リソースを単一の生成パスに固定し、別のタイプのタスクはキャッシュ、バッチ処理、ツール実行、スケジューリングを通じて、同じ推論能力を複数のワークフローに交差して割り当てることができるため、リソースの曲線は自然と分かれます。

したがって、今後、より基本的な問題が製品の問題に近づいていくでしょう。KVキャッシュをどのように配置するか、prefillをどのように分割するか、decodeバッチをどれだけ厚くできるか、待機中のエージェントがキャッシュを追い出すべきかどうか——これらの選択が、1つのGPUで同時に維持できるタスクの数を決定します。

SoraとCodexの違いは、ビデオとコードの違いだけでなくものです。

彼らは同じ時間のGPUを巡って競い合い、どれだけの作業を支えられるかを問うている。