LLMレイテンシモニタリング（エルエルエムレイテンシモニタリング）
LLM推論のレスポンス時間を多角的に計測・監視する手法。TTFT（最初のトークンまでの時間）、TPS（1秒あたりのトークン生成数）、E2E（エンドツーエンド）レイテンシなどの指標を追跡し、ユーザー体験とSLOの維持を図る。
LLMレイテンシモニタリングとは
LLMレイテンシモニタリングは、大規模言語モデルの推論処理にかかる応答時間を継続的に計測し、性能劣化やボトルネックを早期に検知するためのプラクティスである。従来のWebアプリケーションではHTTPレスポンスタイムが主要指標であったが、LLMではストリーミング応答の特性上、複数の時間指標を組み合わせて監視する必要がある。
LLM固有のレイテンシ指標
| 指標 | 定義 | 目安（良好） | 目安（要改善） |
|---|---|---|---|
| TTFT | 最初のトークンが返るまでの時間 | < 500ms | > 2,000ms |
| TPS | 1秒あたりの生成トークン数 | > 30 tokens/s | < 10 tokens/s |
| E2E | リクエスト送信から全トークン受信まで | < 5s | > 15s |
| ITL | トークン間の平均間隔（Inter-Token Latency） | < 30ms | > 100ms |
| Queue Time | リクエストがキューで待機する時間 | < 100ms | > 1,000ms |
TTFTとTPSの重要性
ユーザー体験の観点では、TTFTが最も重要な指標である。チャットUIでは最初のトークンが表示されるまでの待ち時間がユーザーの離脱率に直結する。研究によると、TTFT 2秒を超えると離脱率が40%増加するとされている。
一方、バッチ処理や要約タスクではTPSが重要になる。1万トークンの出力をTPS 20で生成すると500秒（8分以上）かかるが、TPS 60なら167秒で完了する。
レイテンシに影響する要因
LLMのレイテンシは以下の要因で変動する。
- モデルサイズ: パラメータ数が大きいほど推論時間が増加（GPT-4o > GPT-4o mini）
- 入力トークン数: プロンプトが長いほどプリフィル処理に時間がかかる
- 出力トークン数: max_tokensが大きいほどE2Eレイテンシが延びる
- サーバー負荷: 同時リクエスト数増加でQueue Timeが増大
- リージョン: API エンドポイントまでのネットワーク遅延
- 量子化: INT8/INT4量子化モデルはFP16比で1.5〜3倍高速
モニタリング実装のアーキテクチャ
効果的なレイテンシモニタリングは3層で構成される。
- 計装層: アプリケーションコードにタイムスタンプ計測を埋め込む。ストリーミングでは最初のチャンク到着時刻（TTFT）と全チャンク完了時刻（E2E）を記録する
- 収集層: OpenTelemetry Collectorやカスタムエクスポーターでメトリクスを集約する
- 可視化層: Grafana、Datadog、CloudWatch等でダッシュボード化し、P50/P95/P99パーセンタイルを表示する
アラート設計のベストプラクティス
レイテンシアラートは以下の階層で設計する。
| レベル | 条件 | アクション |
|---|---|---|
| Warning | P95 TTFT > 1.5秒 が5分間継続 | Slackチャンネル通知 |
| Critical | P99 TTFT > 3秒 が3分間継続 | PagerDuty起動 |
| Emergency | E2E中央値 > 10秒 | 自動フォールバック（小型モデルに切替） |
FAQ
Q1: ストリーミング応答のレイテンシはどう計測する？
Server-Sent Events（SSE）の最初のdataイベント受信時刻をTTFTとし、最終イベント受信時刻をE2Eとする。各dataイベント間の間隔を記録すればITLが得られる。クライアント側のタイムスタンプを使うため、ネットワーク遅延も含まれる。
Q2: セルフホストモデルとAPI型モデルではモニタリング方法が異なる？
異なる。セルフホストの場合はGPU使用率、VRAM消費、バッチサイズなどのインフラメトリクスも追加で監視する。vLLMやTGI（Text Generation Inference）はPrometheus互換のメトリクスエンドポイントを内蔵している。
Q3: レイテンシとコストのトレードオフはどう判断する？
TTFT SLO（例: P95 < 1秒）を満たす最小コストのモデルを選択するのが基本方針である。GPT-4o miniやClaude 3.5 HaikuはフルモデルのTTFTの1/3以下で、コストも1/10以下になる。タスクの複雑度に応じてルーティングするのが最適解である。