# 主要LLM推論APIプロバイダ 5社の「TTFT（初回応答遅延）・出力tok/s・夜間ピーク分散」実測比較データベース

> 公称「高速推論 tok/s」の裏にある北米ピーク重複時間帯（JST 22:00〜03:00）のp95レイテンシ悪化とPrompt Caching効果の計測集計（N=672）

- **Canonical URL**: https://nodus-lab.pages.dev/articles/llm-api-providers-ttft-latency-throughput-variance-benchmarks.html
- **CSV Dataset**: https://nodus-lab.pages.dev/datasets/llm-api-providers-ttft-latency-throughput-variance-benchmarks.csv
- **Category**: Cloud & AI Infrastructure
- **Sample Size (N)**: 672
- **Data Updated**: 2026-10-12

## 結論・実測サマリー (TL;DR)
- 集計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）。

## 主要実測指標 (Key Metrics)
- **集計API計測リクエスト数**: 672 回/社 (15分周期×7日間 4k入力ストリーミング)
- **夜間ピーク時のp95 TTFT倍率**: 2.1x 〜 3.4x (JST 22:00〜03:00（北米日中帯と重複）)
- **Prompt Cachingヒット時短縮率**: -46% 〜 -74% (32k長文コンテキスト時のPrefill削減効果)
- **最低遅延プロバイダ (p95 TTFT)**: 0.48 秒 (Groq LPU / 次点 Gemini Flash 0.89秒)

## 条件別・実測比較データテーブル
| APIプロバイダ / モデル | 日中 TTFT (p50) | 北米ピーク TTFT (p95) | 純粋出力速度 (p50) | 夜間p95実効速度 (512tok) | Prompt Caching短縮効果 | 推奨ワークロード |
| --- | --- | --- | --- | --- | --- | --- |
| 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%) | 高度なコード生成・エージェント監査 |

## 詳細解説・原因分析
### 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%割引されるため、本番環境では必須の設計パターンです。

## よくある疑問と回答 (FAQ)
### Q. ストリーミング（stream: true）を使えば合計完了時間も速くなりますか？
A. 最後のトークンが出力し終わるまでの合計時間（Total Completion Time）自体はストリーミングの有無でほぼ変わりませんが、ユーザーが最初の文字を目にするまでの体感待ち時間（TTFT）が数秒から0.3〜0.8秒へ劇的に短縮されます。また、Cloudflare Workersやブラウザのタイムアウト切断を防ぐ上でもストリーミングは有効です。

### Q. 夜間のAPI遅延スパイクやレート制限（429 Overloaded）を回避する最も確実な構成は？
A. 単一プロバイダに依存せず、例えばClaude APIをプライマリとしつつ、TTFTが3.0秒を超えた場合や529/429エラー時にAWS Bedrock / Google Vertex AI上の同一モデル、またはOpenAI / Geminiへ自動フェイルオーバーするマルチプロバイダルーティングが最も高い可用性を実現します。

## 検証環境・集計メソドロジー
東京リージョン（ap-northeast-1）から15分間隔×7日間（計672リクエスト/エンドポイント）、入力4,096 tokens・出力512 tokensの構造化JSON生成ストリーミングを実行した公開ベンチマークおよびr/LocalLLaMA運用テレメトリを集計。JST昼間帯（10:00〜18:00）のp50出力速度と、北米営業時間重複帯（JST 22:00〜04:00）の実効スループット（TTFT待ち時間込み）を比較。