GPT‑5.6 モデルファミリーは、ユーザーがモデルを利用する幅広いタスクで、性能とコストのバランスが取れるよう設計しました。フラッグシップモデルの GPT‑5.6 Sol は、推論の深さを最大に設定すると、半分未満のコストで Artificial Analysis Coding Agent Index において Claude Fable 5 を上回ります。Terra は半額で、知能ベンチマークにおいて GPT‑5.5 と同等の性能を発揮します。Luna は高速かつ価格を抑えたモデルで、価格は Sol より 80% 低く設定されています。こうした効率を実現するため、研究チームと技術チームは、スタックの主要な全レイヤーで大幅な最適化を行いました。改善の対象は、モデル、推論（モデルを実行して出力を生成する方法）、Codex と ChatGPT Work の両方で使用されるエージェント型ハーネスに及びます。
過去 4 年間でモデルの利用規模が 10 億人のアクティブユーザーと 200 万社を超える企業へ拡大する中、知能の恩恵をすべての人に届けるうえで、効率性は常に中心的な役割を担ってきました。私たちの使命は、汎用人工知能が全人類に利益をもたらすようにすることです。この数年間、コストと性能のバランスに応じて高性能なモデルを提供するため、スタック全体で継続的に最適化の余地を広げてきました。GPT‑5.6 は、トークン当たりの作業量を増やすよう学習されており、トークン当たりの性能効率をこれまで以上に高めました。学習では、タスクの成功と効率性の両方を最適化し、モデルがタスクをより直接的な経路で進めるよう調整します。
本記事ではモデル以外にも目を向け、スタックの主要な 2 つの領域における進歩を通じて、効率性を追求した設計を紹介します。1）負荷分散、投機的デコーディング、キャッシュ、カーネル最適化などのプロセスを改善し、同じハードウェアからより多くの出力を得るための推論、2）コンテキストの肥大化、ツール利用、反復作業をより適切に管理するエージェント型ハーネスです。また、こうした成果の一部を GPT‑5.6 Sol が自律的に実現した経緯も紹介します。個々の改善は小さく見えても、その成果が積み重なることで、知能と効率の両面でフロンティアを切り拓くことができます。
モデルへの需要が供給能力を上回るペースで伸び、計算資源が限られる世界では、あらゆるシステム設計の中核に効率性があります。これは、学習済みモデルを実行して応答を生成する推論スタックにおいて、特に重要です。ユーザーが期待する性能、レイテンシ、可用性、信頼性を維持しながら、同じハードウェアでより多くのトークンを処理することが、私たちの主な目標です。
その実現には、システム全体の最適化が必要です。モデル単体の効率が非常に高くても、リクエストの分散が不適切だったり、ハードウェアがアイドル状態になったり、データ転送が計算を遅らせたりすれば、提供コストは高くなります。各レイヤーの改善は相乗効果を生みます。具体的には、ルーティング（リクエストの送信先）、スケジューリング（リクエストの送信時期）、カーネル（GPU 上で動作するソフトウェア）、キャッシュ（処理結果の保存と再利用）、モデル実装（GPU コードの実行順序）の最適化が効果をもたらします。Codex の GPT‑5.6 Sol は、これらすべての最適化で重要な役割を果たしました。
最初の重要な例は、負荷分散です。グローバルでは、地域、利用可能な処理能力、アクセラレータの種類（モデルを実行する GPU または専用チップの種類）などに基づいてリクエストをルーティングします。クラスター内では、負荷、コンテキスト長、キャッシュの可用性、その他のリクエスト特性に基づいて、モデルインスタンス間に処理を分散します。さらに各インスタンス内では、アクセラレータ、モデルのサブネットワーク、計算コアの間で処理を効率よく分割する必要があります。Codex の GPT‑5.6 Sol は、本番トラフィックの分析、見過ごされていた負荷の偏りの特定、新しいルーティング戦略のテスト、こうしたヒューリスティクスの継続的な調整を支援します。こうした負荷分散の改善だけでも、モデルの提供コストは大幅に低下しました。
さらに GPT‑5.6 Sol を使用して、入力を次トークンの予測へ変換する計算である、モデルのフォワードパスを最適化しました。個々の処理が高速でも、過剰なメモリ転送や同期、非効率なデータ配置によって GPU がアイドル状態になる場合があります。これを防ぐため、GPT‑5.6 Sol は、事前計算、省略、並列化が可能な処理を特定しました。GPT‑5.6 Sol は Codex を使い、モデルを構成する数学演算を実行する中核コードである本番環境のカーネルを、自律的に書き換えて最適化しました。これが可能になった理由の一つは、OpenAI が管理する 2 つのオープンソース GPU プログラミング言語、Triton（新しいウィンドウで開く） と Gluon（新しいウィンドウで開く） でカーネルを効果的に記述、改善できるよう GPT‑5.6 を学習させたことです。こうした取り組みと GPT‑5.6 Sol による広範なカーネルの進歩を組み合わせ、エンドツーエンドの提供コストを 20% 削減しました。また、GPT‑5.6 Sol が記述したカーネルの正確性を検証できるよう、オープンソースツールの FpSan（新しいウィンドウで開く）（Floating-Point Sanitizer）など、検証ツールの開発にも重点的に投資しています。
投機的デコーディングも、速度と効率を高める手段の一つです。この手法では、小型のドラフトモデル（「スペキュレータ」）をプライマリモデルと並行して動かし、複数のトークンを提案して、プライマリモデルが並列に検証します。提案が受け入れられると、プライマリモデルの 1 回のパスで複数の出力トークンを生成でき、コストの高い逐次計算を減らせます。GPT‑5.6 Sol は、自身のドラフトモデルのアーキテクチャについて数百件の実験を設計・実行し、規模、構造、機能の変更をテストして改善しました。さらに GPT‑5.6 Sol は、スペキュレータの学習プロセスを開始して監視し、ハードウェア障害や学習の不安定化などの問題が発生すると、自律的に介入しました。その結果、トークン生成効率が 15% 以上向上しました。
キャッシュされていない入力トークンを処理する際、モデルは計算負荷の高い 1 回のパスでキー・バリュー（KV）キャッシュを構築します。出力生成時には、そのキャッシュを繰り返し読み取り、拡張します。バッチ処理、シャーディング、KV 管理などの最適な提供構成は、プロンプトと出力の長さ、バッチサイズ、キャッシュヒット率、クエリ特性など、ワークロードに大きく左右されます。しかし従来は、構成の選択肢が多すぎて体系的に調整できず、エンジニアは大まかなヒューリスティクスに頼らざるを得ませんでした。Codex の GPT‑5.6 Sol により、本番ワークロードを分析し、構成候補を生成・評価して、シナリオごとにエンジンとモデルの構成を徹底的に最適化できました。これにより、ワークロードごとの新たな水準の最適化が実用化され、同じハードウェアから、より有用な推論結果を引き出せます。
推論の最適化は、継続的なフィードバックループです。本番環境の挙動を測定し、最大のギャップを特定して変更を実装し、個別のベンチマークだけでなくシステム全体が改善したことを検証します。GPT‑5.6 Sol と Codex は、そのループのあらゆる段階を加速します。これにより、チームはより多くのアイデアを検討し、変化するワークロードに迅速に対応して、レイテンシを抑え、処理能力を高め、ユーザーのコストを削減できる推論スタックを構築できます。
ChatGPT Work と Codex は、一連のモデルリクエストとツール呼び出しを通じて複雑なタスクを完了します。ユーザーの依頼から最終回答までの 1 回のターンで、Codex はソースコードの確認、デプロイ履歴の検索、インシデント報告書の閲覧、ファイルの編集、テストの実行を行うことがあります。各ステップでリクエストが必要になる場合があります。
コンテキストの準備、データ転送、推論の実行、ツールの呼び出し、プロセスの起動には、いずれも時間と計算資源が必要です。タスクに 30 回のモデルリクエストが必要な場合、リクエストごとの 1 秒の遅延も積み重なります。全体的な性能を高めるには、モデルを高速化するだけでなく、システム全体の反復作業を減らす必要があります。
ユーザーの 1 回のターンに、モデルとツールの反復処理が何度も含まれることがあります。反復領域内のコストは、そのたびに発生します。
こうした累積効果を踏まえて、モデル、ツール、ユーザー環境を接続する Rust で実装されたオーケストレーションレイヤーであるエージェント型ハーネスを設計しました。次に、コンテキストの肥大化を防ぎ、ツールを読み込み、作業を再利用することで、各リクエストを効率化する方法を説明します。
エージェントが利用できるツール、スキル、プラグイン、会話履歴が増えると、コンテキストウィンドウは簡単に拡大します。その結果、コストが増え、モデルの注意がそれて、不要な推論が生じます。ハーネスでは必要に応じた検出を利用し、連携機能、カスタム MCP ツール、スキル、プラグインを必要なときだけ提示できるようにして、このオーバーヘッドを削減します。また、個々のツールや MCP 連携が想定外にコンテキストウィンドウを消費することも防ぎます。モデルが別の上限を要求しない限り、ツール出力はデフォルトで 10,000 トークンに制限されます。
前述のとおり、エージェントループでは、1 回のターン内で同じ指示、会話履歴、ツール定義、過去の結果を GPU に複数回送信する場合があります。こうした入力を繰り返し処理するには大きなコストがかかるため、プロンプトキャッシュでは、以前に処理したプロンプトのプレフィックスに対応する計算を再利用します。このプレフィックスを維持するため、ハーネスはモデルから見えるすべての履歴を追記専用として扱います。新しいメッセージ、ツールの結果、環境の更新は、過去のコンテキストに挿入せず末尾に追加します。ツールも決まった順序で提示し、承認ポリシーなどのランタイム設定はツール定義に埋め込まず、実行時に適用します。この設計により、Codex と ChatGPT Work は、プロンプトキャッシュ全体で高いヒット率を実現しています。
増分転送はネットワークを通過するデータの範囲を変え、プロンプトキャッシュはモデルが再計算せずに済む処理の範囲を変えます。幅は概念的なもので、追加の圧縮レイヤーは図示していません。
GPT‑5.6 で実現した効率向上は、研究、推論、エージェント型ハーネスを含むスタック全体で、長年にわたり改善を積み重ねてきた成果です。GPT‑5.6 がこうした改善の多くを実現したことで、今後、最適化のペースがさらに加速すると期待しています。スタックの基盤を改善しながら、カーネル最適化などの領域でも、より大きな最適化を続けていきます。こうした継続的な内部改善を、より広く利用でき、コスト効率にも優れた AI の能力として、ユーザーやお客様に還元していきたいと考えています。
本記事に貢献した技術スタッフの Matthew Ferrari、Philippe Tillet、Ahmed Ibrahim、Joe Gershenson、Steve Coffey に心より感謝します。
