プロダクション環境でのLLM推論のモニタリング（2026年）：vLLM、TGI、llama.cpp用のPrometheusとGrafana

LLMの推論は「単なるAPI」のように見えるが、レイテンシーが急激に増加し、キューが再び詰まり、GPUが95％のメモリ使用率で動いていても明らかに原因が分からないという状況に陥るまでには至らない。

単一ノードの設定を超えて移行したり、スループット最適化を開始する moment から、監視はミッションクリティカルとなる。その時点で、従来のAPIメトリクスだけでは不十分である。トークン、バッチングの挙動、キュー時間、KVキャッシュの圧力といった、現代LLMシステムの本当のボトルネックに関する可視性が必要となる。

この記事は、私が執筆している**観測性と監視ガイド**の一部であり、このガイドでは、監視と観測性の基本、Prometheusのアーキテクチャ、および生産性のベストプラクティスについて説明している。ここでは、LLM推論ワークロードの監視に特に焦点を当てている。

（インフラストラクチャを選定している場合、私の2026年のLLMホスティングガイドを参照してください。バッチングメカニクス、VRAM制限、スループットとレイテンシーのトレードオフについて深く掘り下げたい場合、LLMパフォーマンスエンジニアリングガイドを参照してください。）

典型的なRESTサービスとは異なり、LLMのサービスはトークン、継続的なバッチング、KVキャッシュの利用率、GPU/CPUの飽和度、キューのダイナミクスによって形作られる。同じペイロードサイズを持つ2つのリクエストでも、max_new_tokens、concurrency、cache reuseによって、レイテンシーが劇的に異なる可能性がある。

このガイドは、PrometheusとGrafanaを使用したLLM推論監視のための実用的で生産性に焦点を当てたウォークロードガイドです：

• 測定するべき項目（p95/p99レイテンシー、トークン/秒、キュー時間、キャッシュ利用率、エラーレート）
• 一般的なサーバーから/metricsをスクレイピングする方法（vLLM、Hugging Face TGI、llama.cpp）
• パーセンタイル、飽和度、スループットに関する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リクエスト持続時間；prefill vs decode レイテンシー；トークン間レイテンシー
• 飽和度: GPU利用率、メモリ使用量、KVキャッシュ使用量、キューのサイズ

Prometheusの外でGPUメモリ使用量、温度、利用率の低レベルの可視性が必要な場合（デバッグやシングルノード設定のため）、私のLinux / UbuntuでのGPUモニタリングアプリケーションガイドを参照してください。

LLMの観測性に限らず、トレース、構造化されたログ、合成テスト、GPUプロファイリング、SLO設計を含むLLMシステムの観測性についてのより広範な視点が必要な場合は、私のLLMシステムの観測性ガイドを参照してください。

有用な次元（ラベル）

ラベルのカーディナリティを低く保つ。良いラベル：

• model, endpoint, method (prefill/decode), status (success/error), instance

避けるべきラベル：

• 原始的な prompt, 原始的な user_id, リクエストID — これらはシリーズの数を爆発的に増やす。

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

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

vLLM: Prometheusと互換性のある/metrics

vLLMはPrometheusと互換性のある/metricsエンドポイント（Prometheusメトリクスロガー経由）を公開し、vllm:接頭辞付きでサーバー/リクエストメトリクスを公開します。それには、動作中のリクエストやKVキャッシュの使用率のようなゲージが含まれます。

典型的に見られるメトリクスの例：

• 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（ヒストグラム）

llama.cppサーバー: メトリクスエンドポイントを有効にする

llama.cppサーバーはPrometheusと互換性のあるメトリクスエンドポイントをサポートしており、--metricsのようなフラグで有効にする必要があります。

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ヒストグラムはバケットカウントで構成されています。histogram_quantile()を使用してrate()のバケットに適用します。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) インフェレンスデプロイメントをServiceで公開

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：Serviceがポッドを選択していますか？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をラベルとして追加した。

修正

• 高カーディナリティラベルを削除
• 低カーディナリティラベルに事前に集計（モデル、エンドポイント、ステータス）
• ラベルではなく、ログ/トレースを使用してリクエストごとのデバッグを行う

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

メトリクスは必要だが、時折相関が必要になる：

• 構造化されたログを追加してリクエストメタデータ（モデル、トークン数、TTFT）を含める
• ゲートウェイと推論サーバーの周りに トレース（OpenTelemetry）を追加
• 例（サポートされている場合）を用いて、レイテンシーの急増からトレースにジャンプする

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

これは、観測性と監視アーキテクチャガイドで説明されているクラシックなメトリクス → ログ → トレースモデルに従っています。

6) vLLM / 多プロセスメトリクスのクイアック

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

実用的な「day-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の基本、および生産性のパターンについてのより広範な説明が必要な場合は、私の完全な観測性ガイドを参照してください。