2026 年：プロダクション環境における LLM 推論の監視：vLLM、TGI、llama.cpp 向け Prometheus と Grafana

LLM の推論は「ただの API」のように見えますが、レイテンシが急増し、キューが backlog して、GPU のメモリ使用率が 95% に達しても明確な説明ができない状況に直面した際に、その真の姿が明らかになります。

単一ノードの構成を超えたり、スループットを最適化し始めたりする瞬間から、モニタリングはミッションクリティカルなものになります。その時点で、従来の API メトリクスだけでは不十分です。トークン、バッチ処理の挙動、キュー待ち時間、KV キャッシュの圧力など、現代の LLM システムにおける真のボトルネック可視化が必要です。

本記事は、広範な 可観測性とモニタリングガイド の一部であり、モニタリングと可観測性の基礎、Prometheus アーキテクチャ、運用ベストプラクティスについて解説しています。ここでは、特に LLM 推論ワークロードのモニタリング に焦点を当てます。

（インフラストラクチャの選定にお困りの場合は、2026 年の LLM ホスティングガイド をご覧ください。バッチ処理の仕組み、VRAM の制限、スループットとレイテンシのトレードオフについて深く学びたい場合は、LLM パフォーマンスエンジニアリングガイド を参照してください。）

典型的な REST サービスとは異なり、LLM サービングは トークン、連続バッチ処理、KV キャッシュ利用率、GPU/CPU 飽和、キューのダイナミクスによって形成されます。ペイロードサイズが同一でも、max_new_tokens、並行性、キャッシュ再利用によって、レイテンシが劇的に異なる 2 つのリクエストが存在します。

本ガイドは、Prometheus と Grafana を用いた LLM 推論モニタリングの構築に向けた、実用的で運用に焦点を当てた解説です：

• 測定すべき項目（p95/p99 レイテンシ、トークン/秒、キュー待ち時間、キャッシュ利用率、エラー率）
• 一般的なサーバー（vLLM、Hugging Face TGI、llama.cpp）からの /metrics 収集方法
• パーセンタイル、飽和、スループットに関する PromQL 例
• Docker Compose と Kubernetes を使用したデプロイパターン
• 実際の負荷下でのみ発生する問題のトラブルシューティング

例は意図的にベンダーニュートラルなものです。後で OpenTelemetry トラッキング、オートスケーリング、サービスメッシュを追加しても、同じメトリクスモデルが適用されます。

なぜ LLM 推論は通常のモニタリングとは異なるのか

従来の API モニタリング（RPS、p95 レイテンシ、エラー率）は必要ですが、それだけでは不十分です。LLM サービングには追加の軸が存在します：

1) レイテンシには 2 種類の意味がある

• E2E レイテンシ: リクエスト受信から最終トークンの返却までの時間。
• トークン間レイテンシ: デコード中の 1 トークンあたりの時間（ストリーミング UX に重要）。

一部のサーバーは両方を公開しています。例えば、TGI はリクエスト継続時間と平均トークンあたりの時間をヒストグラムとして公開しています。

2) スループットはリクエスト数ではなくトークン数で測る

5 トークンを返す「高速」サービスは、500 トークンを返すサービスと比較できません。「RPS」はしばしば「トークン/秒」であるべきです。

3) キューが製品そのものである

連続バッチ処理を実行している場合、キュー深度こそが販売しているものです。キュー待ち時間とキューサイズを監視することで、ユーザーの期待に応えているかどうかを判断できます。

4) キャッシュ圧力は障害の前兆である

KV キャッシュの枯渇（または断片化）は、突然のレイテンシ急増やタイムアウトとして現れることが多いです。vLLM は KV キャッシュ使用率をゲージとして公開します。

LLM 推論モニタリングのためのメトリクスチェックリスト

これを北極星として使用してください。最初からすべてが必要ではありませんが、最終的にはほとんどが必要になるでしょう。

ゴルデンシグナル（LLM 向け）

• トラフィック: リクエスト/秒、トークン/秒
• エラー: エラー率、タイムアウト、OOM、429（レート制限）
• レイテンシ: p50/p95/p99 リクエスト継続時間；プリフィルト vs デコードレイテンシ；トークン間レイテンシ
• 飽和: GPU 利用率、メモリ使用量、KV キャッシュ使用量、キューサイズ

Prometheus 以外の GPU メモリ使用量、温度、利用率の低レベル可視化が必要な場合（デバッグや単一ノード構成用）、Linux / Ubuntu における GPU モニタリングアプリケーションガイド を参照してください。

メトリクスを超えた LLM 可観測性のより広範なビュー（トラッキング、構造化ログ、合成テスト、GPU プロファイリング、SLO デザインを含む）については、LLM システムの可観測性 に関する詳細ガイドをご覧ください。

有用なディメンション（ラベル）

ラベルのカーディナリティは低く保ってください。良いラベル：

• model、endpoint、method（プリフィルト/デコード）、status（成功/エラー）、instance

避けるべきラベル：

• raw prompt、raw user_id、リクエスト ID — これらはシリーズ数を爆発的に増加させます。

メトリクスの公開：組み込み /metrics エンドポイント（vLLM、TGI、llama.cpp）

最も簡単な方法は：サーバーがすでに公開しているメトリクスを利用することです。

vLLM: Prometheus 互換の /metrics

vLLM は（Prometheus メトリクスロガを介して）Prometheus 互換の /metrics エンドポイントを公開し、実行中のリクエスト数や KV キャッシュ使用率などのゲージを含むサーバー/リクエストメトリクスを vllm: プレフィックスで公開します。

コンテナ設定、OpenAI 互換のサービング、スループット指向のランタイムチューニングについては、vLLM クイックスタート: 高性能 LLM サービング を参照してください。

一般的に見られるメトリクスの例：

• vllm:num_requests_running
• vllm:num_requests_waiting
• vllm:kv_cache_usage_perc

Hugging Face TGI: キュー + リクエストヒストグラム付きの /metrics

TGI は /metrics に多くの運用グレードのメトリクスを公開しており、キューサイズ、リクエスト継続時間、キュー待ち時間、平均トークンあたりの時間などが含まれます。

注目すべきもの：

• tgi_queue_size (ゲージ)
• tgi_request_duration (ヒストグラム、E2E レイテンシ)
• tgi_request_queue_duration (ヒストグラム)
• tgi_request_mean_time_per_token_duration (ヒストグラム)

運用設定（Docker、GPU、起動フラグ、空または誤解を招くスクレイプとして現れる失敗）については、TGI - Text Generation Inference - インストール、設定、トラブルシューティング を参照してください。

llama.cpp サーバー: メトリクスエンドポイントの有効化

llama.cpp サーバーは、フラグ（例：--metrics）で有効化する必要がある Prometheus 互換のメトリクスエンドポイントをサポートしています。

インストールパス、キーとなるランタイムフラグ、OpenAI 互換サーバーの使用については、llama.cpp CLI とサーバーのクイックスタート を参照してください。

プロキシの背後で llama.cpp を実行している場合、可能な限りサーバーを直接スクレイプしてください（プロキシレベルのレイテンシが実際の推論挙動を隠すのを避けるため）。

Prometheus 設定：推論サーバーのスクレイピング

この例では以下を前提としています：

• vLLM: http://vllm:8000/metrics
• TGI: http://tgi:8080/metrics
• llama.cpp: http://llama:8080/metrics
• 高速フィードバックに適したスクレイプ間隔

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "vllm"
    metrics_path: /metrics
    static_configs:
      - targets: ["vllm:8000"]

  - job_name: "tgi"
    metrics_path: /metrics
    static_configs:
      - targets: ["tgi:8080"]

  - job_name: "llama_cpp"
    metrics_path: /metrics
    static_configs:
      - targets: ["llama:8080"]

Prometheus が初めて、またはスクレイプ設定、エクスポート、リラベリング、アラートルールについてより深く知りたい場合は、Prometheus モニタリングセットアップガイド を参照してください。

プロのヒント：「service ラベル」を追加する

複数のモデル/レプリカを実行している場合、ダッシュボード用に安定した service ラベルを含めるためのリラベリングを追加します。

relabel_configs:
  - target_label: service
    replacement: "llm-inference"

コピー＆ペースト可能な PromQL 例

リクエストレート（RPS）

sum(rate(tgi_request_count[5m]))

vLLM の場合、バージョンによって名称が異なりますが、パターンは同じです：sum(rate(<counter>[5m]))。

エラー率（%）

*_success カウンターがある場合、失敗率を計算します：

1 - (
  sum(rate(tgi_request_success[5m]))
  /
  sum(rate(tgi_request_count[5m]))
)

ヒストグラムメトリクスの p95 レイテンシ（Prometheus）

Prometheus ヒストグラムはバケットカウントです。バケットの rate() に対して histogram_quantile() を使用します。Prometheus はこのモデルと、ヒストグラムとサマリーのトレードオフを文書化しています。

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_duration_bucket[5m]))
)

p99 キュー待ち時間

histogram_quantile(
  0.99,
  sum by (le) (rate(tgi_request_queue_duration_bucket[5m]))
)

平均トークン間時間（トークン間レイテンシ）

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_mean_time_per_token_duration_bucket[5m]))
)

トークン間レイテンシは、デコードのボトルネックやメモリ帯域幅によって制限されることが多く、これらは LLM パフォーマンス最適化ガイド で詳しく解説されています。

キュー深度（瞬間値）

max(tgi_queue_size)

vLLM KV キャッシュ利用率（瞬間値）

max(vllm:kv_cache_usage_perc)

Grafana ダッシュボード：オンコールに実際に役立つパネル

Grafana はヒストグラムを複数の方法（パーセンタイル、ヒートマップ、バケット分布）で可視化できます。Grafana Labs には Prometheus ヒストグラム可視化の詳細ガイドがあります。

最小限で高信号のダッシュボードレイアウト：

行 1 — ユーザーエクスペリエンス

1. p95 リクエストレイテンシ（時系列）
2. p95 トークン間レイテンシ（時系列）
3. エラー率（時系列 + 統計）

行 2 — 容量と飽和

4. キューサイズ（時系列）
5. 実行中 vs 待ちのリクエスト（積み上げ）
6. KV キャッシュ使用率 %（ゲージ）

行 3 — スループット

7. リクエスト/秒
8. 生成トークン/リクエスト（p50/p95）

ストリーミングがある場合、「ファーストトークンレイテンシ（TTFT）」のパネルを追加してください（利用可能な場合）。

例となる Grafana クエリ

• p95 レイテンシパネル：上記の histogram_quantile(0.95, …) クエリ
• ヒートマップパネル：バケットレート（*_bucket）をヒートマップとして描画（Grafana はこのアプローチをサポートしています）

デプロイオプション 1: Docker Compose（高速ローカル + 単一ノード）

ローカル、セルフホストド、クラウドベースの推論アーキテクチャの間で選択している場合は、LLM ホスティング比較ガイド の完全な解説をご覧ください。

以下のフォルダを作成します：

monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inference.json

docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Docker ではなく手動で Grafana をインストールしたい場合は、Ubuntu への Grafana インストールと使用ガイド を参照してください。

Grafana データソースプロビジョニング（grafana/provisioning/datasources/datasource.yml）

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

ダッシュボードプロビジョニング（grafana/provisioning/dashboards/dashboards.yml）

apiVersion: 1
providers:
  - name: "LLM"
    folder: "LLM"
    type: file
    disableDeletion: true
    options:
      path: /var/lib/grafana/dashboards

デプロイオプション 2: Kubernetes（Prometheus Operator + ServiceMonitor）

kube-prometheus-stack（Prometheus Operator）を使用している場合、ServiceMonitor を介してターゲットをスクレイプします。

Kubernetes、単一ノード Docker、マネージド推論プロバイダー間のインフラストラクチャのトレードオフについては、2026 年の LLM ホスティングガイド を参照してください。

1) サービスで推論デプロイメントを公開

apiVersion: v1
kind: Service
metadata:
  name: tgi
  labels:
    app: tgi
spec:
  selector:
    app: tgi
  ports:
    - name: http
      port: 8080
      targetPort: 8080

2) ServiceMonitor を作成

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tgi
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: tgi
  endpoints:
    - port: http
      path: /metrics
      interval: 5s

vLLM と llama.cpp サービスについても同様に行います。これにより、レプリカを追加してもクリーンにスケールします。

3) アラート: SLO スタイルのルール（例）

良いスタートアラートは以下の通りです：

• 高い p95 レイテンシ（バーンレート）
• p99 キュー待ち時間が長すぎる（ユーザーが待っている）
• エラー率 > 1%
• KV キャッシュ使用率 > 90%（持続的、容量の崖）

例となるルール（p95 リクエスト継続時間）：

- alert: LLMHighP95Latency
  expr: histogram_quantile(0.95, sum by (le) (rate(tgi_request_duration_bucket[5m]))) > 3
  for: 10m
  labels:
    severity: page
  annotations:
    summary: "TGI p95 latency > 3s (10m)"

トラブルシューティング：LLM スタックにおける一般的な Prometheus + Grafana の失敗

1) Prometheus ターゲットが「DOWN」

症状

• Prometheus UI → Targets で DOWN となっている
• 「context deadline exceeded」または接続拒否

チェックリスト

• サーバーは実際に /metrics を公開しているか？
• ポートが違う？スキームが違う（http vs https）？
• Kubernetes: サービスがポッドを選択しているか？ServiceMonitor の release ラベルは正しいか？

クイックテスト

curl -sS http://tgi:8080/metrics | head

2) メトリクスはスクレイプできるが、パネルが空

最も一般的な原因

• メトリクス名が違う（サーバーバージョンが変更された）
• ダッシュボードが _bucket を期待しているが、ゲージ/カウンターしかない
• Prometheus のスクレイプ間隔が短すぎるウィンドウに対して長すぎる（例：[1m] で 30 秒のスクレイプはノイズが多い）

修正

• Grafana Explore を使用してメトリクスプレフィックスを検索（例：tgi_ / vllm:）
• レンジウィンドウを [1m] → [5m] に増加

3) ヒストグラムパーセンタイルが「平坦」または間違っているように見える

Prometheus ヒストグラムには正しい集計が必要です：

• rate(metric_bucket[5m]) を使用する
• 次に sum by (le) （およびオプションで他の安定したラベル）
• 次に histogram_quantile()

Prometheus はバケットモデルとサーバー側のカウント計算を文書化しています。 Grafana のヒストグラム可視化ガイドには実践的なパネルパターンが含まれています。

4) カーディナリティの爆発（Prometheus メモリ急増）

症状

• Prometheus RAM 使用量が増加
• 「too many series」エラー

典型的な根本原因

• カスタムエクスポートで prompt、user_id、リクエスト ID をラベルとして追加した。

修正

• 高カーディナリティのラベルを削除
• 低カーディナリティのラベル（model、endpoint、status）に事前に集計
• ラベルではなく、ログ/トレースを使用してリクエストごとのデバッグを検討

5) 「メトリクスはあるが、なぜ遅いのか分からない」

メトリクスは必要ですが、時には相関関係が必要です：

• リクエストメタデータ（モデル、トークン数、TTFT）付きの構造化ログを追加
• ゲートウェイ + 推論サーバーの周りにトラッキング（OpenTelemetry）を追加
• 利用可能な場合、エクスプランを使用してレイテンシ急増からトレースにジャンプ

良いワークフロー：Grafana ダッシュボードの急増 -> Explore をクリック -> インスタンス/モデルで絞り込み -> その期間のログ/トレースを確認。

これは、可観測性とモニタリングアーキテクチャガイド で説明されている、古典的な メトリクス -> ログ -> トレース モデルに従っています。

6) vLLM / マルチプロセスメトリクスの癖

サービングスタックがマルチプロセスで実行されている場合、Prometheus のマルチプロセス構成が必要になる可能性があります（プロセスがメトリクスを公開する方法に依存します）。vLLM ドキュメントでは、Prometheus ポーリングのために /metrics を介してメトリクスを公開することを強調しており、デプロイ時にサーバーのメトリクスモードを確認してください。

実用的な「1 日目」のダッシュボードとアラートセット

運用でも機能する軽量なセットアップが欲しい場合は、以下から始めます：

ダッシュボードパネル

1. p95 リクエストレイテンシ
2. p95 平均トークン間時間
3. キューサイズ
4. p95 キュー待ち時間
5. エラー率
6. KV キャッシュ使用率 %

アラート

• p95 リクエストレイテンシ > X（10 分間）
• p99 キュー待ち時間 > Y（10 分間）
• エラー率 > 1%（5 分間）
• KV キャッシュ使用率 > 90%（15 分間）
• Prometheus ターゲットがダウン（常に）

関連する可観測性ガイド

• 可観測性ガイド: Prometheus、Grafana、および運用モニタリング
• Prometheus モニタリング: セットアップとベストプラクティス
• Ubuntu への Grafana インストールと使用: 完全ガイド

関連する LLM インフラストラクチャガイド

• 2026 年の LLM ホスティング: ローカル、セルフホストド、クラウドの比較
• 2026 年の LLM パフォーマンス: ベンチマークと最適化

結びの言葉

Prometheus + Grafana は、推論の健全性に対する「常時オン」のビューを提供します。基礎が揃った後、次の大きな成果は通常以下から得られます：

• モデル/テナントごとの SLO
• リクエストの整形（最大トークン数、並行制限）
• キュー待ち時間とKV キャッシュの余裕に連動したオートスケーリング

モニタリングと可観測性の違い、Prometheus の基礎、運用パターンについてのより広範な説明については、可観測性ガイド を参照してください。