LatencyLLM APIPerformance

LLM APIレイテンシ完全最適化ガイド（2026年版）

約1分

ダッシュボードにはP95レイテンシ4.2秒と表示されています。ベンチマークサイトはあなたのモデルが毎秒800トークン——「高速」——と示しています。それでもユーザーは最初のトークンが届く前にタブを閉じています。

このギャップこそがLLMレイテンシの全体像です。誰もがベンチマークする数字と、ユーザーが実際に体感する数字は別物であり、ほとんどのチームは間違った方を最適化しています。

レイテンシはLLMスタックの中で、データは豊富なのに処方箋が乏しい領域です。ベンチマークサイトはTTFTと毎秒トークンの表を何百も公開しています——Artificial AnalysisのプロバイダーページやAI API Costのライブ速度リーダーボードがリファレンスです——しかし、自分の数字に対して何をすべきかを教えてくれるサイトはほぼありません。ベンダーのドキュメントは彼ら自身のスタックを説明するものであって、あなたのスタックではありません。そしてこの分野で最も好まれる指標——毎秒トークン——は、ユーザーが実際に体感するものと誤解されがちです。

本ガイドは処方箋レイヤーです。レイテンシが実際に何を意味するか（4つの異なる数字があり、TPSはそのうちの1つだけ）、なぜ今やプロダクト指標なのか、正当化できるバジェットでどう測定するか、各レイヤー——ストリーミング、キャッシュ、モデルティアリング、リージョナルルーティング——をどう改善するか、そして最適化を迷信にしてしまうミスについて解説します。

LLM APIにおける「レイテンシ」の本当の意味

要点：レイテンシには4つの数字があり、間違った数字を最適化することが「高速」なのに遅く感じるモデルを出荷する原因です。

  • **TTFT——最初のトークンまでの時間。**ユーザーが最初に体感するもの：「送信」から最初のストリームトークンまでのギャップ。インタラクティブプロダクトにとって最も重要な単一の数字です。
  • **トークン間レイテンシ——TPSの逆数。**残りのレスポンスがストリームされる速さ。長い出力やエージェントループでは重要ですが、1行の回答では無関係です。
  • **総リクエスト時間。**合計からストリーミングの体感を除いたもの。バッチ処理やバックグラウンド処理が気にするもので、ユーザーが体感するものではありません。
  • **体感レイテンシ。**ストリーミングが生み出すもの：TTFTにストリームのペーシングを加えたもの。TTFTが良くペーシングが安定したシステムは、総時間が長くても速く感じます。

この分野のTPSへの固執が罠です。TTFT 1.5秒の800トークン/秒モデルは、TTFT 300msの300トークン/秒モデルに第一印象で負けます。4つすべてを測定し、ユースケースごとに最適化しましょう。

なぜレイテンシはプロダクト指標なのか

要点：エージェントはレイテンシを増幅し、ユーザーはプロダクトを体感します——数字はベンチマークシートから解約チャートへ移動しました。

レイテンシが今やプロダクト上の決定である理由は構造的に2つあります：

  1. **エージェントループはすべての待ち時間を増幅します。**1回の会話でN回の逐次モデル呼び出しが発生します。呼び出しあたり500msの優位は、10回呼び出しのループでは5秒の優位になります。インタラクティブシステムの800msルールを支えるのと同じ複利ロジックがここでも当てはまります。逐次呼び出しは掛け算されるため、呼び出しごとのレイテンシは性能の飾りではなくプロダクト上の決定です。

  2. **体感速度はリテンションです。**ストリーミングUIの研究は一貫して、最初のトークンまでの時間が体感品質を左右することを示しています。最速のベンチマークモデルでもTTFTが遅ければ負けます。プロダクトの問いは「モデルはどれだけ速いか」ではなく——「ユーザーの最初のトークンはどれだけ速いか」です。

測定方法：レイテンシバジェット

要点：測定はベンチマークではなくバジェットです——分解し、P50とP95の両方で、自社のリージョンで、自社のプロンプトサイズで測定します。

バジェットの分解：

ステージ含まれるもの一般的な範囲
ネットワークDNS、TLS、接続、リージョン間距離20〜200ms
キューイングプロバイダー側、レート制限への接近度0〜500ms以上
TTFTモデルのprefill＋最初のトークン200〜1500ms
トークン間生成のペーシング1〜5ms/トークン
クライアントパース、レンダリング、ストリーミング基盤10〜100ms

バジェットを正直にするルール：

  1. **本番リージョンで測定する。**シンガポール向けプロダクトをUS-eastで測定するとまったく別の数字になります——リージョナルレイテンシはモデルレイテンシを超えることがあります。
  2. **P50は真実を隠し、P95がそれを語ります。**中央値はタイムアウトを隠します。ユーザーが覚えているのはテールです。
  3. **同じプロンプトサイズ、同じ同時実行数。**小さなプロンプトを使うベンチマークはTTFTを良く見せ、何も罰しません。プロンプトの構成を自社のものにするか、測定はマーケティングになります。

最小限だが正直な測定スクリプト：

import time
from openai import OpenAI

client = OpenAI()          # your production endpoint and region
PROMPT = "..."             # a representative production prompt
N, STREAM = 50, True       # 50 runs, streaming on

ttfts, ipss = [], []
for _ in range(N):
    t0 = time.perf_counter()
    first = True
    stream = client.chat.completions.create(model="gpt-4o-mini",
                                            messages=[{"role": "user", "content": PROMPT}],
                                            stream=STREAM)
    for chunk in stream:
        if first:
            ttfts.append((time.perf_counter() - t0) * 1000)  # TTFT in ms
            first = False
            t_last = time.perf_counter()
        else:
            ipss.append((time.perf_counter() - t_last) * 1000)  # inter-token ms
            t_last = time.perf_counter()

def pct(xs, p):
    xs = sorted(xs); return xs[int(len(xs) * p)]
print(f"TTFT  P50={pct(ttfts, .5):.0f}ms  P95={pct(ttfts, .95):.0f}ms")
print(f"Inter-token  P50={pct(ipss, .5):.1f}ms  P95={pct(ipss, .95):.1f}ms")

ユーザーが実際にいるリージョンから、実際のプロンプトサイズで実行し、結果をCIスイートが比較するベースラインとして記録しましょう。

測定の習慣はCIに属します。TTFTのドリフトで失敗するレイテンシ回帰スイートこそが、「モデルが良くなった」という主張を正直に保つ唯一の手段です——優れたオブザーバビリティ実践がスタック全体に築くのと同じ規律です。

最適化方法：ストリーミング、キャッシュ、ルーティング

要点：実装順に3つのレバー——すべてをストリーミングし、繰り返しをキャッシュし、ティアでルーティングする——そして3つともプロジェクトではなく設定です。

**レイヤー1——ストリーミング。**最初のレバーであり、最も安価です。レスポンスをストリーミングし、トークンが届くたびにレンダリングします。インタラクティブな選択はSSEかWebSocketかです——リクエスト・レスポンス型のストリームにはSSE（よりシンプルで、HTTPネイティブ、ほとんどのプロキシを通ります）、双方向フロー（エージェント、リアルタイム音声）にはWebSocket。素朴なストリーミングを壊す本番の詳細：プロキシバッファリング（完了までレスポンスを保持する中間者は目的を無効にします）、切断処理（クライアントが放棄したら、ストリームは中断しなければなりません）、そしてバックプレッシャー。ストリーミングはモデルを速くするのではありません——ユーザーの待ち時間をストリームのペーシングの中に消し去るのです。

**レイヤー2——キャッシュ。**2つの異なるメリットがあります。プロンプトキャッシュ（繰り返されるプレフィックスがprefillをスキップし、2回目以降の同一呼び出しのTTFTを短縮）とレスポンスキャッシュ（同一リクエストをモデルに触れずに配信）です。プロンプトキャッシュガイドが経済性を解説しています。レイテンシの観点でも同じレバーです。安定したプレフィックスは2回目以降の呼び出しをより速く、より安くします。ミス率に注意しましょう——90%ミスするキャッシュは、利益なしにオーバーヘッドを追加するだけです。

**レイヤー3——モデルティアリングとルーティング。**インタラクティブ経路は毎ターンにフロンティアモデルを必要としません。UXに重要な呼び出しは高速ティア（当社の高速推論比較で取り上げた専用チッププロバイダーを含む）に、バックグラウンド処理はコストティアにルーティングします。カスタムルーティングがリクエストごとの判断を機械的にし、フォールバックが高速ティアの偶発的な利用不能をレイテンシの問題にしないようにします。

グローバルレイテンシの改善方法：リージョナルルーティング

要点：グローバルなユーザーベースでは、モデル選択よりリージョン選択が効きます——同じモデルでも適切なリージョンなら300msと900msの差になります。

数字は嘘をつきません。米国から欧州のユーザーに配信されるモデルは、リージョナルエンドポイントと比べてホップごとに100〜200msの追加ネットワークレイテンシを抱え、その差はエージェントループをまたいで複利のように膨らみます。修正はアーキテクチャレベルです：

  1. **最寄りリージョンルーティング。**モデルが利用可能な最寄りのリージョンから各ユーザーに配信します——ロードバランシングレイヤーがエンドポイントレベルでこれを行います。
  2. **リージョン間の自動フェイルオーバー。**プロバイダーやリージョンが劣化したら、ユーザーのTTFTバジェットを使い果たす前に次のリージョンへフェイルオーバーします——自動フェイルオーバーのドキュメントが仕組みを解説しています。
  3. **エッジ呼び出し（手短に）。**極端にレイテンシに敏感な経路では、エッジファンクションがLLM呼び出しの前面に立てます——ネットワークホップを減らし、接続再利用を処理します。正直な注記：エッジは独自のコールドスタートコストを追加し、ほとんどのワークロードではリージョナルエンドポイントが勝ちます。採用前にテストしましょう（過剰に約束するのではなく、指摘しておく唯一のエッジケースです）。

先ほどの測定ルールがより強く当てはまります。リージョナルルーティングの決定にはリージョナルな測定が必要です——グローバルルーティングの変更を米国でベンチマークしても、それは測定ではありません。

よくあるミス

要点：4つの失敗パターン——それぞれがレイテンシ改善の取り組みを見せかけのものに変えます。

  1. **1つの指標だけを最適化する。**TTFTを無視したTPS偏重、ストリーミングを無視したTTFT偏重。本ガイドの4つの数字のモデルが解毒剤です。
  2. **ネットワークレイヤーを無視する。**モデル側の最適化だけして、リージョナルルーティングはゼロ——グローバルプロダクトにとって、それはバジェットの間違った半分を最適化していることになります。
  3. ヒット率の規律なしでキャッシュする。「速いから」という理由で90%ミス率のキャッシュを導入する——キャッシュの経済性が機能するのは、プレフィックスが安定し、ヒット率を測定しているときだけです。
  4. **最適化前のベースラインがない。**スタックを変更し、変更を出荷したが、変更前を一度も測定していない。CIレイテンシスイートがなければ、「最適化」はダッシュボード付きの願望にすぎません。

FAQ

最初に最適化すべきレイテンシ指標は？

インタラクティブプロダクトならTTFTです——ユーザーが最初に体感するものだからです。エージェントループや長い出力ならTPSです。自分のユースケースが体感する指標を最適化し、他の指標も静かに劣化しないよう測定しましょう。

ストリーミングは実際に速いのですか、それとも速く感じるだけですか？

どちらもです、ただし意味は異なります。総時間は通常変わりませんが、最初のトークンが早く届き、残りをストリームがペーシングするため、体感レイテンシは劇的に短縮されます。インタラクティブプロダクトでは体感レイテンシがプロダクト指標です——すべてストリーミングしましょう。

リージョン選択はレイテンシにどれくらい影響しますか？

多くの場合、モデル選択より影響が大きいです。大陸間のネットワークホップは呼び出しごとに数百ミリ秒を追加し、エージェントループをまたいで膨らみます。最寄りリージョンルーティングは、ほとんどのグローバルプロダクトが実施しない、最も効果の高いレイテンシ改善です。

ストリーミングにはSSEとWebSocketのどちらを使うべきですか？

リクエスト・レスポンス型のストリームにはSSE——よりシンプルで、HTTPネイティブ、プロキシとの相性も良いです。リアルタイムエージェントのような双方向フローにはWebSocket。流行ではなくフローの形状で選ぶこと、それが答えのすべてです。

キャッシュは本当にレイテンシを削減しますか？

プロンプトキャッシュは繰り返されるプレフィックスのTTFTを削減し（prefillが高コストな部分です）、レスポンスキャッシュは同一リクエストのモデルレイテンシを完全に排除します——ただしヒット率が本物の場合に限ります。ヒット率を測定しましょう。ミス率は税金です。

P95がP50よりはるかに悪いのはなぜですか？

LLM APIのテールレイテンシは、負荷時のプロバイダー側キューイング、レート制限への接近、そしてリージョナルなネットワーク変動から発生します。テールが重要なら（実際に重要です）、修正はヘッドルーム、フォールバック、リージョナルルーティングの組み合わせです——より速いモデルではありません。

まとめ

LLM APIのレイテンシ最適化は4つの数字の問題です。本番リージョンでP50とP95のTTFT、トークン間、総時間、体感レイテンシを測定し、各レイヤーを改善します——体感にはストリーミング、繰り返しにはキャッシュ、コストと速度のバランスにはティアリング、バジェットのネットワーク半分にはリージョナルルーティング。ベンチマーク表は何が可能かを教え、あなたのバジェットは何が自分のものかを教えます。まず測定し、次に最適化すれば、世界最速のモデルはユーザーが実際に体感するモデルになります。

測定したことのないレイテンシバジェットは修正できません。TokSpan APIキーを取得して——測定に使える$5の無料クレジット——同じプロンプトを複数のリージョンから実行してみてください。