GPT-6 Sol レイテンシー: 初回トークンまで102秒

トークン価格が100万トークンあたり10ドルと50ドルから2ドルと10ドルに下がったため、gpt-6-astraをgpt-6-solに切り替えました。請求書は完璧に見えます。ところが、p95応答時間が2分を超え、ロードバランサーがゲートウェイタイムアウトを返し始め、サポートにはページが固まる理由を尋ねる問い合わせが殺到します。

何も壊れていません。ワークロードの価格だけでなく、その形状を変えたのです。

Artificial Analysisは、GPT-6 Solを1秒あたり115.2出力トークン、最初のトークンまでの時間102.15秒と測定しています。GPT-6 Lunaは、1秒あたり153.9出力トークン、最初のトークンまでの時間124.23秒と測定しています。これらの2つの数値には大きな注意点があり、それがこの記事の前半です。後半は、それらに対してどうすべきかです。つまり、自身のワークロードで最初のトークンの遅延を正直に測定する方法と、100秒かかるモデルがAPIをダウンさせないようにするための4つの設計変更について説明します。

2日間で3つのフロンティアモデルが発表されたより広い文脈については、2026年9月のAIモデル価格競争をご覧ください。

その数値と、それを引用することの全ての間違い

数値の列を読む前に、注意点の列を読んでください。

その列が示している3つのこと。

これらはOpenAIの数値ではなく、Artificial Analysisの数値です。OpenAIは、ローンチ時に価格、コンテキスト、可用性、そしてベンチマークスコアの山を発表しました。私たちが読んだ資料には、遅延に関する数値は掲載されていませんでした。したがって、102.15秒はサードパーティが自身のネットワークで独自のハーネスを実行した結果であり、仕様としてではなく、方向性を示すものとして扱うべきです。私たちが行っているように、あなたのドキュメントにもそのように記してください。

これらは「max」推論バリアントを記述しています。発売時の両ベンダーのベンチマーク表には、低、中、高、x高、最大といった努力レベルがいたるところに表示されています。最大はその階層の頂点であり、推論の努力は最初のトークンの遅延に最も大きな影響を与えます。最も遅い構成の測定は、本番環境で実行する構成の測定ではありません。

これらは、ある瞬間のプロバイダーのエンドポイントの測定値です。サービス能力、ルーティング、キューの深さは変動します。トラフィックが集中した発売週に取得された数値は、定数として偽装された最悪のケースです。

これら3つの注意点を乗り越えて残るのは「方向性」であり、この方向性がこの記事のポイントです。安価なモデルは速いモデルではありません。SolはAstraのトークンあたり価格の5分の1、LunaはSolの20分の1ですが、どちらの割引もより速いファーストバイトをもたらしません。この測定では、ファミリーの中で最も安価なモデルが起動に最も時間がかかりました。

最初のトークンまでの時間、それは測定しているものの間違った名前である

推論を伴わないモデルでは、最初のトークンまでの時間は、おおよそネットワーク遅延、キュー待ち、プリフィル時間の合計です。これはプロンプトの長さに応じて変化し、数百ミリ秒の範囲に収まります。

推論モデルでは、それは同じラベルを持つ異なる量です。モデルは、要求されたものを出力する前に思考プロセスを実行するため、最初の可視トークンまでのギャップには推論フェーズ全体が含まれます。このフェーズはプロンプトの長さとは関係ありません。モデルが問題の難易度をどのように判断するかと関係があります。

その結果、2つの事態が起こり、どちらも本番環境で問題となります。

1つ目は、速いトークンレートでは救われないということです。Solは一度起動すると1秒あたり115.2トークンで出力し、これは速いです。しかし、ほとんどの経過時間が最初のトークン前に費やされるため、それはあまり重要ではありません。

生成時間は、出力長を1秒あたり115.2トークンで割ったものなので、この表は、新たな測定ではなく、2つの測定値に対する算術計算です。応答を短くしても、合計時間はほとんど変わりません。2,000トークンの冗長な回答を500トークンに短縮しても、2分間の呼び出しから13秒しか節約できません。

2つ目の結果は、応答の長さによってランキングが逆転することです。Lunaはトークンレートが速いものの、起動が遅いモデルです。2つのモデルを比較すると、約10,100出力トークンでクロスします。それ以下では、Solの方が生成速度が遅いにもかかわらず先に完了し、それ以上ではLunaのレートがようやく長い待機時間を相殺します。ユーザーに提供するもののほとんどは10,000トークンの応答ではないため、ほとんどのワークロードでは、起動が遅いモデルは単に遅いモデルであるということになります。

最初に壊れるもの

障害は、モデルの呼び出し自体にあることは稀です。それは、高速API向けに設計された、その周りの全てのものにあります。

アイドルタイムアウト。ロードバランサー、リバースプロキシ、APIゲートウェイ、サーバーレスプラットフォームはすべて、バイトが流れない接続が許容される時間を制限します。これらのデフォルトの多くは2分をはるかに下回ります。この記事を含め、ブログ記事で読んだ数値を信用しないでください。あなたの設定を読んでください。通常、修正はnginxの`proxy_read_timeout`のような1つのディレクティブと、クライアントSDK自身のタイムアウトを含む、その前にある全てのホップでの対応する設定です。

リトライ。300ミリ秒で意味をなしたリトライポリシーは、100秒では危険です。バックオフを伴う3回の試行は、今や5分間のリクエストとなり、遅延している期間中のリトライの急増は、すでに苦戦しているエンドポイントにさらに多くの同時実行作業を課します。試行回数を制限し、サーキットブレーカーを維持し、リトライが二重請求や二重書き込みを引き起こさないように、すべての呼び出しをべき等にしてください。

並行性、これは見落とされがちです。リトルの法則によれば、処理中のリクエスト数は、到着率にシステム滞在時間を掛けたものです。1秒に1リクエスト、120秒の呼び出しの場合、追いつくためには120の同時実行中のリクエストが必要です。これらの接続は、ソケット、スレッド、または関数呼び出しをそれぞれ2分間占有し、その費用はトークン料金には一切現れません。1回あたりの呼び出しが安価なモデルでも、保持されるキャパシティ1秒あたりのコストは高くなる可能性があります。

ユーザーインターフェース。102秒間耐えられるスピナーはありません。推論フェーズが同期リクエストパス上にある場合、修正は見た目ではなく、アーキテクチャ上の問題です。

自身のワークロードでそれを測定する方法

ベンダーやサードパーティの数値は、初期の仮説に過ぎません。あなたのプロンプト、地域、努力設定、トラフィックパターンが実際の数値を決定します。

まず、トランスポートレベルの視点から始めましょう。これは1つのコマンドで実行できます。

curl -N -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","input":"Summarise this OpenAPI operation.","stream":true}'

次に、`first_byte`を疑って読んでください。ストリーミングエンドポイントでは、最初のバイトは通常、コンテンツトークンではなく、ストリーム開始イベントなので、`time_starttransfer`はモデルが応答を開始した時ではなく、サーバーが通信を開始した時を測定します。そのギャップこそ、あなたが測定しようとしているものなので、素朴なハーネスは都合の良い数値を報告します。

重要な測定値は、最初のコンテンツのデルタを計測することです。

import time
from openai import OpenAI

client = OpenAI(timeout=600)

t0 = time.perf_counter()
first_content = None

with client.responses.stream(
    model="gpt-6-sol",
    input=PROMPT,
    reasoning={"effort": "low"},
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta" and first_content is None:
            first_content = time.perf_counter() - t0
    total = time.perf_counter() - t0

print(f"ttft={first_content:.2f}s total={total:.2f}s")

これらのスニペット内のフィールド名とイベント名は、GPT-6の発表ではなく、現在のOpenAI APIの形式に基づいています。デプロイする前にリファレンスと照合してください。測定の規律は引き継がれます。最初のコンテンツトークンまでの時間と合計時間を別々のメトリクスとして記録し、モデルごと、努力レベルごとに保持し、平均ではなくp95を報告してください。推論モデルの最初のトークン遅延には長いテールがあり、平均値はまさにタイムアウトするリクエストを隠してしまいます。

これを一度きりのチェックではなく、定期的なチェックとして実行してください。Apidogにストリーミングリクエストを保存し、応答時間をアサートし、CIでシナリオを定期的に実行することで、プロバイダー側の退行や努力レベルの変更が、サポートチケットとしてではなく、テストの失敗として現れるようにします。同じプロジェクトは、フロントエンドの作業に待ち時間を回避する方法を提供します。実際の統合がまだ構築されている間に、各イテレーションで2分間誰もブロックされないように、クライアントを自身のAPIエンドポイントのApidogモックにポイントします。メトリクスの基礎が必要な場合は、API遅延に関するガイドで用語を説明しています。

実際に役立つ4つの変更点

推論呼び出しを同期パスから外す。リクエストを受け入れ、すぐにジョブIDと共に`202 Accepted`を返し、ポーリングまたはWebhookで結果を配信します。これは、他のすべての問題を小さくする唯一の変更点です。なぜなら、102秒間が、上流が待機しているHTTPリクエスト内で費やされなくなるからです。

モデルではなく、努力によってルーティングする。測定された数値は最大の推論を表しています。ほとんどのトラフィックはそれを必要としません。まずタスクを分類し、ルーチンな大部分を低努力で処理させ、高コストな設定はそれに値する場合にのみ予約します。OpenAI自身のローンチベンチマークが努力レベルごとに報告されているのは、まさにこのためであり、設定はチューニングの詳細ではなく、第一級の設計上の決定です。

ストリーミングし、待機状況を正直に示す。人間が見ている場合、応答をストリーミングし、何が起こっているかを伝えます。現実を反映した進捗状況は、何か問題があることを示唆するスピナーよりも優れています。

経過時間をトークンとは別に予算化する。タスクごとのコストとタスクごとの遅延は独立した軸であり、9月のローンチでその一方が大きく動きました。コスト予算の隣にエンドポイントごとの遅延予算を設け、どちらかの回帰をリリースブロッカーとして扱います。

想定すべきではないことの1つは、GPT-6のプロンプトキャッシュリリースは、キャッシュされた入力読み取りの価格を90%削減し、ヒット率を向上させ、これは実際の節約になります。ベンダーはどちらもこれに対する遅延の主張を発表していないため、キャッシュによる最初のトークンの改善は、計画するものではなく、測定すべきものとして扱ってください。

安価なモデルは速いモデルではない

GPT-6 Solの100万トークンあたり2ドルと10ドルという価格は、真の価格変動であり、その背後にあるベンチマーク結果は強力です。しかし、そのどれもが起動を速くするものではありません。利用可能な唯一の公開されている遅延測定によれば、Astraのトークン価格から80%節約できるモデルは、一言を発するまでに1分半以上を要し、さらに安価な兄弟モデルはそれよりも長くかかります。

価格は請求書に記載されています。遅延はあなたのアーキテクチャの中にあります。より速いモデル向けに構築されたリクエストパスに安価なモデルを導入する前に、最初のバイトではなく、最初のコンテンツトークンを計測するハーネスを使用して、後者を自分で測定してください。