主要LLM推論APIプロバイダ 5社の「TTFT（初回応答遅延）・出力tok/s・夜間ピーク分散」実測比較データベース
公称「高速推論 tok/s」の裏にある北米ピーク重複時間帯（JST 22:00〜03:00）のp95レイテンシ悪化とPrompt Caching効果の計測集計（N=672）
- 集計API計測リクエスト数は「672 回/社」（15分周期×7日間 4k入力ストリーミング）。
- 夜間ピーク時のp95 TTFT倍率は「2.1x 〜 3.4x」（JST 22:00〜03:00（北米日中帯と重複））。
- Prompt Cachingヒット時短縮率は「-46% 〜 -74%」（32k長文コンテキスト時のPrefill削減効果）。
- Groq Cloud API (Llama-3.3-70B-Versatile)：専用LPUアーキテクチャにより北米ピーク時間帯でもp95 TTFTが0.48秒にとどまり、リアルタイム音声・対話用途で圧倒的安定性（N=672）。
1. 公称・日中ピーク出力速度（Peak tok/s）vs 北米ピーク時間帯のTTFT待ち時間込み実効速度（Effective tok/s at p95） 単位: tok/s
2. 条件別・実測比較データテーブル 列見出しクリックで数値ソート可能
| Groq Cloud (Llama-3.3-70B) | 0.24 秒 | 0.48 秒 | 248.5 tok/s | 201.5 tok/s | ベースが極小遅延 | 音声対話・リアルタイムUI |
|---|---|---|---|---|---|---|
| Vertex AI (Gemini 2.5 Flash) | 0.41 秒 | 0.89 秒 | 142.0 tok/s | 114.0 tok/s | Context Caching対応 | 大規模構造化抽出・分類 |
| Together AI (70B Turbo) | 0.52 秒 | 1.78 秒 | 112.4 tok/s | 80.8 tok/s | 限定的 | オープン重みモデルの低単価実行 |
| OpenAI API (GPT-4o) | 0.58 秒 | 1.62 秒 (Cache時 0.52s) | 84.2 tok/s | 66.5 tok/s | 自動適用 (TTFT -46%) | 汎用プロダクション・マルチモーダル |
| Anthropic (Claude 3.7 Sonnet) | 0.82 秒 | 2.45 秒 (Cache時 0.85s) | 68.4 tok/s | 51.5 tok/s | 明示指定 (32k時 -74%) | 高度なコード生成・エージェント監査 |
3. 検証結果の詳しい解説・なぜこの差が出るのか？
1. 平均値（Mean）ではなく「北米ピーク帯のp95 TTFT」で設計すべき理由
1回のユーザー操作の裏で3回〜5回のLLM呼び出しを直列実行するエージェント型アプリケーションでは、1ステップあたりp95で2.0秒のTTFT（初回トークン到達遅延）が発生すると、チェーン全体の待ち時間が10秒を超えます。特にJST 22:00〜03:00は米国西海岸・東海岸のコア業務時間と重なるため、共有エンドポイントではPrefill（入力プロンプトのKVキャッシュ計算）フェーズのキュー待ちが昼間比で2倍〜3倍以上に増加します。
2. Prompt CachingによるPrefillボトルネックの解消効果
システムプロンプトやFew-shot例、リポジトリ構造など共通プレフィックスを先頭4,096 tokens以上に固定してPrompt Cachingを有効化した場合、OpenAI（自動キャッシュ）ではTTFT p50が0.58秒から0.31秒へ46%短縮、Anthropic（cache_control指定）では32k tokens入力時のTTFTが3.8秒から0.98秒へ74%短縮されました。同時にキャッシュ読み取りトークン単価も50%〜90%割引されるため、本番環境では必須の設計パターンです。
検証対象モデル・関連サービス公式リンク 公式・参考リンク (広告なし)
※上記は読者の利便性のための参考リンクであり、現在アフィリエイト報酬等は設定されていません。
4. よくある疑問と回答 (FAQ)
Q. ストリーミング（stream: true）を使えば合計完了時間も速くなりますか？
最後のトークンが出力し終わるまでの合計時間（Total Completion Time）自体はストリーミングの有無でほぼ変わりませんが、ユーザーが最初の文字を目にするまでの体感待ち時間（TTFT）が数秒から0.3〜0.8秒へ劇的に短縮されます。また、Cloudflare Workersやブラウザのタイムアウト切断を防ぐ上でもストリーミングは有効です。
Q. 夜間のAPI遅延スパイクやレート制限（429 Overloaded）を回避する最も確実な構成は？
単一プロバイダに依存せず、例えばClaude APIをプライマリとしつつ、TTFTが3.0秒を超えた場合や529/429エラー時にAWS Bedrock / Google Vertex AI上の同一モデル、またはOpenAI / Geminiへ自動フェイルオーバーするマルチプロバイダルーティングが最も高い可用性を実現します。
5. 検証条件・一次情報ソース (Provenance)
https://nodus-lab.pages.dev/articles/llm-api-providers-ttft-latency-throughput-variance-benchmarks.html