EAS メトリクス - Platform For AI - Alibaba Cloud ドキュメントセンター

Elastic Algorithm Service (EAS) サービスがデプロイされると、サービス詳細ページの [モニター] タブで QPS、レイテンシ、エラー率、リソース使用量などのメトリクスを表示して、サービスの呼び出し状況と実行ステータスを把握できます。

モニタリングデータの表示

モニタリングページへのアクセス

PAI コンソールにログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS) に移動] をクリックします。
対象のサービス名をクリックしてサービス詳細ページに移動し、[モニター] タブに切り替えます。

ディメンションとダッシュボードの選択

モニタリングページの左上隅には 2 段階の選択肢があります。まず、ドロップダウンリストからモニタリングディメンション ([サービス] または [インスタンス]) を選択し、次にダッシュボードを選択します。

説明

LLM ダッシュボードは、vLLM または SGLang エンジンを使用する LLM 推論サービスで利用できます。公式の PAI-EAS イメージを使用するか、サービスラベルで ServiceEngineType を sglang または vllm に設定する必要があります。詳細については、「LLM 監視メトリクス > 前提条件」をご参照ください。
GPU ダッシュボードは、GPU を使用するサービスでのみ利用できます。

サービスディメンション：サービス全体の監視メトリクスを表示します。ドロップダウンリストから [サービス] を選択すると、次のダッシュボードが利用可能になります。
- Service-<service_name> (<service_name> は EAS サービスの名前)：サービス監視ダッシュボードです。このダッシュボードには、QPS、RT、CPU、メモリなどの一般的なサービス監視メトリクスが表示されます。
- LLM：LLM サービスが使用する推論エンジン (SGLang または vLLM) に基づくサービス監視メトリクス (リクエストスループットやトークン使用量など) を表示します。
- GPU：SM 使用率、メモリ帯域幅、NVSwitch エラーなどの GPU ハードウェアメトリクスを表示します。
インスタンスディメンション：個々のインスタンスの監視メトリクスを表示します。ドロップダウンリストから [インスタンス] を選択すると、次のダッシュボードが利用可能になります。
- 単一インスタンス：単一インスタンスの監視ダッシュボードです。一度に 1 つのインスタンスしか選択できません。分レベルの監視メトリクスのみが利用可能です。
- 複数インスタンス：複数インスタンスの監視ダッシュボードです。比較のために複数のインスタンスを選択できます。分レベルと秒レベルの両方の監視メトリクスが利用可能です。
- LLM インスタンス：LLM インスタンスの監視ダッシュボードです。比較のために 1 つまたは複数のインスタンスを選択できます。このダッシュボードには、インスタンスレベルの LLM 推論メトリクスが表示されます。
- GPU インスタンス：GPU インスタンスの監視ダッシュボードです。比較のために 1 つまたは複数のインスタンスを選択できます。このダッシュボードには、インスタンスレベルでの詳細な GPU ハードウェアメトリクスが表示されます。

次の表は、各ダッシュボードと対応するメトリクスセクションのマッピングを示しています。

ダッシュボード	メトリクスセクション
`Service-<service_name>`	監視メトリクス > サービス監視ダッシュボード
単一インスタンス	監視メトリクス > 単一インスタンス監視ダッシュボード (分レベル)
複数インスタンス	監視メトリクス > 複数インスタンス監視ダッシュボード
GPU / GPU インスタンス	監視メトリクス > GPU 監視ダッシュボード
LLM / LLM インスタンス	LLM 監視メトリクス

時間範囲の変更

ダッシュボードの時間範囲を変更するには、[モニター] エリアの右側にあるをクリックします。

表示される時間選択パネルで、左側の [絶対時間範囲] でカスタムの開始時刻と終了時刻 (From / To) を指定するか、右側の [相対時間範囲] リストから過去 5 分から過去 7 日間などのプリセット範囲を選択できます。選択した時間範囲にはチェックマーク (✓) が付きます。

重要

分レベルのメトリクスは最大 1 か月間保持されます。秒レベルのメトリクスは最大 1 時間保持されます。

監視メトリクス

サービス監視ダッシュボード (分レベル)

このダッシュボードでは、以下のメトリクスを追跡します。

メトリクス		説明
QPS		リターンコード別にグループ化された秒間リクエスト数です。複数インスタンスのサービスの場合、インスタンス間で合計されます。1d オフセットは、傾向比較のために前日の QPS を表示します。
応答		選択した時間範囲内の合計応答数で、リターンコード別にグループ化されます。複数インスタンスのサービスの場合、インスタンス間で合計されます。
RT		リクエスト応答時間。 Avg：すべてのリクエストの平均応答時間。 TPXX：XX パーセンタイルの応答時間。たとえば、TP5 は 5 パーセンタイルの最大応答時間です。TP100 はすべてのリクエストの最大値です。複数インスタンスのサービスの場合、TP100 はすべてのインスタンスの最大値です。他の TPXX 値はインスタンス間で平均化されます。
1 日あたりの呼び出し回数		リターンコード別にグループ化された 1 日あたりの呼び出し回数です。複数インスタンスのサービスの場合、インスタンス間で合計されます。

その他のメトリクス (CPU | メモリ | GPU | ネットワーク | リソース)

メトリクス		説明
CPU	CPU	サービスの平均 CPU 使用量です。単位：CPU コア。複数インスタンスのサービスの場合、インスタンス間で平均化されます。
	CPU 使用率	サービスの平均 CPU 使用率です。計算式：平均 CPU 使用量 ÷ 利用可能な最大 CPU コア数。複数インスタンスのサービスの場合、インスタンス間で平均化されます。
	CPU 合計	サービスで利用可能な CPU コアの合計数です。計算式：単一インスタンスあたりの利用可能な CPU コア数 × サービスインスタンス数。
メモリ	メモリ	サービスの平均メモリ使用量です。複数インスタンスのサービスの場合、インスタンス間で平均化されます。 RSS：常駐物理メモリサイズ。キャッシュ：キャッシュサイズ。合計：単一インスタンスで利用可能な最大物理メモリサイズ。
メモリ	メモリ使用率	サービスの平均メモリ使用率です。計算式：メモリ RSS ÷ メモリ合計。複数インスタンスのサービスの場合、インスタンス間で平均化されます。
GPU	GPU 使用率	GPU 対応サービスの場合、平均 GPU 使用率です。複数インスタンスのサービスの場合、インスタンス間で平均化されます。
	GPU メモリ	GPU 対応サービスの場合、GPU メモリ使用量です。複数インスタンスのサービスの場合、インスタンス間で平均化されます。
	GPU 合計	GPU 対応サービスの場合、GPU の合計数です。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスの GPU の合計です。
	GPU メモリ使用率	GPU 対応サービスの場合、GPU メモリ使用率です。複数インスタンスのサービスの場合、インスタンス間で平均化されます。
ネットワーク	トラフィック	サービスが送受信するトラフィック (ビット/秒)。複数インスタンスのサービスの場合、インスタンス間で平均化されます。ここで： In：受信トラフィック。 Out：送信トラフィック。
ネットワーク	TCP 接続数	TCP 接続の数。
リソース	レプリカ	異なる状態にあるサービスインスタンスの数：合計、保留中、利用可能。
リソース	リソース別レプリカ	リソースタイプ別のサービスインスタンス数：合計、専用 (専用リソース)、パブリック (パブリックリソース)。

単一インスタンス監視ダッシュボード (分レベル)

このダッシュボードでは、以下のメトリクスを追跡します。

メトリクス	説明
QPS	このインスタンスが受信した秒間リクエスト数です。リターンコード別にグループ化されます。
RT	このインスタンスのリクエストの応答時間。
応答	選択した時間範囲内にこのインスタンスが受信した合計応答数です。リターンコード別にグループ化されます。

その他のメトリクス (CPU | メモリ | GPU | ネットワーク | リソース)

メトリクス		説明
CPU	CPU	このインスタンスの CPU 使用量 (CPU コア単位)。
CPU	CPU 使用率	このインスタンスの平均 CPU 使用率です。計算式：平均 CPU 使用量 ÷ 利用可能な最大 CPU コア数。
メモリ	メモリ	このインスタンスのメモリ使用量。 RSS：常駐物理メモリサイズ。キャッシュ：キャッシュサイズ。合計：単一インスタンスで利用可能な最大物理メモリサイズ。
メモリ	メモリ使用率	このインスタンスの平均メモリ使用率です。計算式：メモリ RSS ÷ メモリ合計。
GPU	GPU 使用率	このインスタンスの GPU 使用率。
	GPU メモリ	このインスタンスの GPU メモリ使用量。
	GPU メモリ使用率	このインスタンスの GPU メモリ使用率。
ネットワーク	トラフィック	このインスタンスが送受信するトラフィック (ビット/秒)。ここで、 In：受信トラフィック。 Out：送信トラフィック。
ネットワーク	TCP 接続数	TCP 接続の数。

複数インスタンス監視ダッシュボード

分レベルおよび秒レベルのメトリクス：

分レベル

メトリクス	説明
インスタンス QPS	各インスタンスの秒間リクエスト数です。リターンコード別にグループ化されます。
インスタンス RT	各インスタンスの平均応答時間。
インスタンス CPU	各インスタンスの CPU 使用量 (CPU コア単位)。
インスタンスメモリ -- RSS	各インスタンスの常駐物理メモリサイズ。
インスタンスメモリ -- キャッシュ	各インスタンスのキャッシュサイズ。
インスタンス GPU	各インスタンスの GPU 使用率。
インスタンス GPU メモリ	各インスタンスの GPU メモリ使用量。
インスタンス TCP 接続数	各インスタンスの TCP 接続数。

第 2 レベル

重要

データ粒度は 5 秒です。過去 1 時間のデータのみが保持されます。

メトリクス	説明
インスタンス QPS (詳細)	各インスタンスが受信した秒間リクエスト数です。リターンコード別にグループ化されます。
インスタンス RT (詳細)	各インスタンスが受信したリクエストの平均応答時間。

GPU 監視ダッシュボード

サービスおよびインスタンスレベルでの GPU メトリクスです。サービスレベルの値は、すべてのインスタンスで平均化されます。

メトリクス	説明
GPU 使用率	サービスの GPU 使用率。
GPU メモリ	サービスの GPU メモリ使用量と合計 GPU メモリ。使用済み：GPU メモリ使用量。合計：合計 GPU メモリ。
メモリコピー使用率	サービスの GPU メモリコピー使用率。
GPU メモリ使用率	サービスの GPU メモリ使用率です。計算式：メモリ使用量 ÷ 合計メモリ。
PCIe	DCGM によって測定されるサービスの PCIe (Peripheral Component Interconnect Express) レートです。PCIe は、高速シリアルコンピュータ拡張バス規格です。 PCIe 送信：PCIe 送信レート。 PCIe 受信：PCIe 受信レート。
メモリ帯域幅	サービスの GPU メモリ帯域幅メトリクス。
SM 使用率と占有率	サービスの SM (ストリーミングマルチプロセッサ) 関連メトリクスです。SM は GPU のコアコンポーネントであり、並列計算タスクの実行とスケジューリングを担当します。 SM 使用率：SM 使用率。 SM 占有率：SM 上に常駐する Warp スレッドの比率。
グラフィックスエンジン使用率	サービスの GPU グラフィックスエンジン使用率。
パイプアクティブ率	サービスの GPU 計算パイプラインのアクティビティレート。 Pipe Fp32 Active Ratio：FP32 パイプラインのアクティビティレート。 Pipe Fp16 Active Ratio：FP16 パイプラインのアクティビティレート。 Pipe Tensor Active Ratio：テンソルパイプラインのアクティビティレート。
Tflops 使用量	サービスの GPU 計算パイプラインの Tflops (テラフロップス) 計算量。 FP32 Tflops Used：FP32 パイプラインの Tflops 計算量。 FP16 Tflops Used：FP16 パイプラインの Tflops 計算量。 Tensor Tflops Used：テンソルパイプラインの Tflops 計算量。
DRAM アクティブ率	GPU デバイスメモリインターフェイスがデータを送受信する際のアクティビティレート。
SM クロック	サービスの SM クロック周波数。
GPU 温度	サービスの GPU 温度関連メトリクス。 GPU 温度：GPU 温度。 GPU スローダウン温度：GPU 速度制限温度のしきい値。GPU 温度がこの値に達すると、GPU は過熱を防ぐために自動的に動作周波数を下げます。 GPU シャットダウン温度：GPU シャットダウン温度のしきい値。GPU 温度がこの値に達すると、システムは GPU デバイスを強制的にシャットダウンします。これにより、GPU の過熱によるハードウェアの損傷や、より深刻なシステム障害を防ぎます。
消費電力	サービスの GPU 消費電力。

以下は、GPU のヘルスステータスとアノマリー情報に関するメトリクスです。

メトリクス	説明
正常な GPU カード数	サービスの正常な GPU カードの数。
紛失した GPU カード数	サービスの紛失した GPU カードの数。
ECC エラー数	サービスの ECC エラー数です。ECC (誤り訂正符号) は、GPU メモリのデータ転送またはストレージ中にエラーを検出して訂正します。揮発性 SBE ECC エラー：サービスのシングルビット揮発性 ECC エラーの数。揮発性 DBE ECC エラー：サービスのダブルビット揮発性 ECC エラーの数。永続性 SBE ECC エラー：サービスのシングルビット永続性 ECC エラーの数。永続性 DBE ECC エラー：サービスのダブルビット永続性 ECC エラーの数。訂正不能 ECC エラー：サービスの訂正不能 ECC エラーの数。
NVSwitch エラー数	サービスの NVSwitch エラー数です。NVSwitch は、複数の GPU 間での高速通信のために、高帯域幅、低レイテンシの通信チャネルを提供します。 NVSwitch 致命的エラー：サービスの致命的な NVSwitch エラーの数。 NVSwitch 非致命的エラー：サービスの致命的でない NVSwitch エラーの数。
Xid エラー数	サービスの Xid エラー数です。Xid エラーは、GPU ドライバーによって報告されるエラーコードです。これらは、GPU が動作中に遭遇した問題を示します。これらのエラーは通常、システムログ (Linux の dmesg や Windows のイベントビューアーなど) に記録され、Xid コードとして表されます。 Xid エラー：サービスの致命的でない Xid エラーの数。致命的 Xid エラー：サービスの致命的な Xid エラーの数。
カーネルエラー数	サービスの非 Xid エラー数です。非 Xid エラーとは、Xid エラーを除く、カーネルログで報告される他の種類のエラーを指します。
ドライバーハング	サービスの GPU ドライバーハングの数。
再マッピングステータス	GPU が GPU メモリ行を再マッピングしようとしたときのサービスの状態。

LLM 監視メトリクス

LLM 監視メトリクスは、サービスが vLLM または SGLang エンジンのどちらを使用しているかに関わらず、LLM または LLM インスタンスダッシュボードに表示されます。使用しているエンジンに基づいて、対応する監視メトリクスを表示してください。

前提条件

LLM ダッシュボードは、次のいずれかの条件が満たされた場合に表示されます。

公式の PAI-EAS イメージが使用されている。
サービスラベルで ServiceEngineType が sglang または vllm に設定されている。例：
```
{
  "labels": {
    "ServiceEngineType": "sglang"
  }
}
```

注意：

EAS バックエンドは、10〜15 秒ごとにエンジンの /metrics エンドポイントを呼び出して Prometheus メトリクスを収集します。そのため、サービスログには /metrics 200 エントリが定期的に表示されます。
分レベルのメトリクスは最大 1 か月間保持されます。

複数インスタンスの集約ルール

複数インスタンスのサービスの場合、スループット、カウント、キャパシティに関するメトリクスはすべてのインスタンスで合計されます。比率、使用率、平均レイテンシに関するメトリクスはすべてのインスタンスで平均化されます。

SGLang 監視ダッシュボード

リクエスト

メトリクス	説明	Prometheus メトリクス
実行中および待機中のリクエスト	この時点でのリクエスト数。実行中：現在 GPU で実行中のリクエスト数 (リアルタイム同時実行数)。待機中：待機キューで待機中のリクエスト数。一貫して 0 より大きい値は過負荷を示します。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:num_running_reqs` `sglang:num_queue_reqs`
リクエストレート (成功/中止/失敗)	この時点でのリクエストレート (リクエスト/秒)。 requests：完了したリクエストのレート。 aborted：クライアントの切断、タイムアウト、または明示的な中止により中止されたリクエストのレート。 transfer_failed：PD 分離モードで KV キャッシュ転送に失敗したリクエストのレート。 failed_session_recoveries：PD 分離モードでの Mooncake トランスポートセッションの回復 (ブロックリストからの削除) のレート。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:num_requests_total` `sglang:num_aborted_requests_total` `sglang:num_transfer_failed_reqs_total` `sglang:failed_session_recoveries_total`
プロンプトおよび生成トークンレート	この時点での入出力トークンレート。 TPS_IN：1 秒あたりに処理される入力 (プレフィル) トークン数。 TPS_OUT：1 秒あたりに生成される出力 (デコード) トークン数。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:prompt_tokens_total` `sglang:generation_tokens_total`

レイテンシ

メトリクス	説明	Prometheus メトリクス
キュー時間	この時点でのすべてのリクエストのキュー待機レイテンシ。リクエストが待機キューに入ってから、スケジューラによって計算のためにスケジュールされるまでの時間です。 Avg：すべてのリクエストの加重平均キューレイテンシ。 P50/P95/P99：すべてのリクエストのキューレイテンシのパーセンタイル値。	`sglang:queue_time_seconds`
最初のトークンまでの時間 (TTFT)	この時点でのすべてのリクエストの最初のトークンまでの時間 (TTFT) レイテンシ。リクエストが受信されてから最初のトークンが生成されるまでの時間です。 Avg：すべてのリクエストの加重平均 TTFT。 P50/P95/P99：すべてのリクエストの TTFT のパーセンタイル値。	`sglang:time_to_first_token_seconds`
出力トークンあたりの時間 (TPOT)	この時点でのすべてのリクエストの出力トークンあたりの時間 (TPOT/ITL) レイテンシ。最初のトークンが生成された後、後続の各出力トークンに必要な時間です。 Avg：すべてのリクエストの加重平均 TPOT。 P50/P95/P99：すべてのリクエストの TPOT のパーセンタイル値。	`sglang:inter_token_latency_seconds`
エンドツーエンドリクエストレイテンシ	この時点でのすべてのリクエストのエンドツーエンドレイテンシ。リクエストが受信されてからすべてのトークンが返されるまでの時間です。 Avg：すべてのリクエストの加重平均エンドツーエンドレイテンシ。 P50/P95/P99：すべてのリクエストのエンドツーエンドレイテンシのパーセンタイル値。説明このメトリクスは SGLang エンジンによって提供されます。サービス監視ダッシュボードの RT メトリクスは EAS エンジン (easworker) によって提供されます。LLM シナリオでは、このメトリクスを推奨します。	`sglang:e2e_request_latency_seconds`
PD ステージ別レイテンシ (平均)	この時点での各処理ステージで費やされた平均時間。`stage` ラベルによって個別の曲線としてプロットされます。このメトリクスを使用して、どのステージが最もレイテンシを消費しているかを特定します。一般的なステージは次のとおりです。 `tokenize` (形態素解析)、`api_server_dispatch` (API サーバーディスパッチ)、`dpc_dispatch` (DP コントローラーディスパッチ)、`request_process` (スケジューラ受信と処理) `prefill_waiting`/`decode_waiting` (キュー待機) `prefill_forward`/`prefill_chunked_forward`/`decode_forward`/`decode_loop` (順方向計算) `mm_encode` (マルチモーダルエンコーディング) `spec_draft`/`spec_verify` (投機的デコーディングのドラフトと検証) PD 分離ステージ：`prefill_bootstrap`/`prefill_transfer_kv_cache`/`decode_prealloc`/`decode_bootstrap`/`decode_transferred`	`sglang:per_stage_req_latency_seconds`

トークン長の分布

メトリクス	説明	Prometheus メトリクス
プロンプトトークン長	この時点でのすべてのリクエストの入力トークン長の分布。 Avg：加重平均入力トークン長。 P50/P95/P99：入力トークン長のパーセンタイル値。	`sglang:prompt_tokens_histogram`
非キャッシュプロンプトトークン長	この時点でキャッシュにヒットせず、実際の計算が必要な入力トークン長の分布 (入力トークン長からプレフィックスキャッシュヒットトークン長を引いたものに等しい)。このメトリクスは、プレフィルステージの実際の計算オーバーヘッドを表します。 Avg：加重平均非キャッシュ入力トークン長。 P50/P95/P99：非キャッシュ入力トークン長のパーセンタイル値。	`sglang:uncached_prompt_tokens_histogram`
生成トークン長	この時点でのすべてのリクエストの出力トークン長の分布。 Avg：加重平均出力トークン長。 P50/P95/P99：出力トークン長のパーセンタイル値。	`sglang:generation_tokens_histogram`

トークンスループット

メトリクス

説明

Prometheus メトリクス

フェーズ別トークンレート (プレフィル/デコード)

この時点でのフェーズ別トークン処理レート。mode ラベルによって個別の曲線としてプロットされます。

prefill_compute：プレフィルステージで実際に計算されたトークンレート。
prefill_cache：プレフィルステージでプレフィックスキャッシュヒットから提供されたトークンレート (計算不要)。
decode：デコードステージで生成されたトークンレート。

複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。

sglang:realtime_tokens_total

デコード合計シーケンス長

この時点でのデコードバッチ内のすべてのシーケンス長の合計。これは、デコードステージのアテンション計算の実際の読み取りスケールを反映します。

複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。

sglang:decode_sum_seq_lens

キャッシュ階層

メトリクス	説明	Prometheus メトリクス
プレフィックスキャッシュヒット率	この時点でのすべてのリクエストの平均プレフィックスキャッシュヒット率。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます。	`sglang:cache_hit_rate`
ソース別キャッシュ済みプロンプトトークン	この時点でのキャッシュ済み入力トークンのレート。`cache_source` ラベルによって個別の曲線としてプロットされ、キャッシュ階層レベルを示します。 device：GPU メモリ (L1) のプレフィックスキャッシュヒット。 host：HiCache ホストメモリキャッシュヒット (L2)。 storage_<backend>：HiCache 外部ストレージバックエンドヒット (L3)。バックエンド名が接尾辞として付きます。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:cached_tokens_total`
ソース別キャッシュヒット率	この時点での階層レベル別のキャッシュヒット率。計算式：各レベルのトークンレート ÷ 合計入力トークンレート。値は 0〜1 に正規化されます。 <cache_source> ratio：各レベル (device/host/storage_<backend>) のヒット率。 uncached：すべてのキャッシュレベルにヒットせず、実際の計算が必要な入力トークンの比率。	`sglang:cached_tokens_total` `sglang:prompt_tokens_total`
HiCache ホストトークン	この時点での HiCache ホストメモリキャッシュ (L2) のトークンレベル。HiCache が有効な場合にのみ表示されます。 used：ホストキャッシュで使用されているトークン数。 total：ホストキャッシュの合計トークン容量。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:hicache_host_used_tokens` `sglang:hicache_host_total_tokens`
エビクション期間 (GPU→CPU)	この時点で KV キャッシュを GPU からホストメモリにエビクションする時間。 Avg：加重平均エビクション期間。 P99：99 パーセンタイルのエビクション期間。	`sglang:eviction_duration_seconds`
ロードバック期間 (CPU→GPU)	この時点で KV キャッシュをホストメモリから GPU にロードバックする時間。この期間は、L2 キャッシュにヒットしたリクエストの TTFT に直接加算されます。 Avg：加重平均ロード期間。 P99：99 パーセンタイルのロード期間。	`sglang:load_back_duration_seconds`
キャッシュトークンフロー (L1↔L2↔L3)	この時点での 3 つのストレージ階層間の KV キャッシュのトークンフローレート。このメトリクスを使用して、HiCache データ移動の方向と圧力を判断します。 L3→L2 prefetched (ストレージ→ホスト)：外部ストレージからホストメモリにプリフェッチされたトークンレート。 L2→L1 load_back (ホスト→GPU)：ホストメモリから GPU にロードバックされたトークンレート。 L2→L3 backuped (ホスト→ストレージ)：ホストメモリから外部ストレージにバックアップされたトークンレート。 L1→L2 evicted (GPU→ホスト)：GPU からホストメモリにエビクションされたトークンレート。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:prefetched_tokens_total` `sglang:load_back_tokens_total` `sglang:backuped_tokens_total` `sglang:evicted_tokens_total`

KV キャッシュプール

以下のパネルは、スロットディメンションと使用率ディメンションによる各メモリプールの構成と圧力を示します。複数インスタンスのサービスの場合、スロットメトリクスはすべてのインスタンスで合計され、使用率と比率メトリクスはすべてのインスタンスで平均化されます。

メトリクス	説明	Prometheus メトリクス
KV キャッシュトークンプール	この時点でのメイン KV キャッシュプールのスロット構成。 available：直接割り当て可能な完全にアイドルなトークンスロットの数。 evictable：Radix プレフィックスキャッシュによって占有されているトークンスロットの数。必要に応じてエビクションして再利用できます。 used：現在実行中のリクエストによって占有されているトークンスロットの数。説明 `available` が 0 で `evictable` が大きいのは正常です。これは、GPU メモリがプレフィックスキャッシュによって完全に利用されていることを示します。`available` と `evictable` の両方が 0 に近づいた場合にのみ、真の GPU メモリ不足を示します。	`sglang:kv_available_tokens` `sglang:kv_evictable_tokens` `sglang:kv_used_tokens`
SWA トークンプール	この時点でのスライディングウィンドウアテンション (SWA) プールのスロット構成。available/evictable/used 曲線があります。意味は上記と同じです。ハイブリッド SWA モデルの場合にのみ表示されます。	`sglang:swa_available_tokens` `sglang:swa_evictable_tokens` `sglang:swa_used_tokens`
Mamba SSM プール	この時点での Mamba SSM 状態プールのスロット構成。available/evictable/used 曲線があります。意味は上記と同じです。ハイブリッド SSM (Mamba/GDN/KDA) モデルの場合にのみ表示されます。説明このプールのスロットは、トークンごとではなくリクエストごとに割り当てられます。これは、ハイブリッドモデルの同時実行数における一般的なハード制約です。	`sglang:mamba_available_tokens` `sglang:mamba_evictable_tokens` `sglang:mamba_used_tokens`
KV キャッシュ使用トークン	この時点で使用されている KV キャッシュトークンの数。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:num_used_tokens`
KV キャッシュ使用率	この時点での平均 KV キャッシュトークン使用率。一貫して 1 に近い値は、GPU メモリプールがスループットのボトルネックになっており、リクエストのキューイングやリトラクションを引き起こしていることを示します。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます。	`sglang:token_usage`
プール別 KV 使用率 (Full/SWA/Mamba)	この時点での各メモリプールの平均使用率。ハイブリッドアテンションモデルでこのメトリクスを使用して、どのプールが最初に飽和するかを特定します。 full：フルアテンションレイヤー KV プール使用率。 swa：スライディングウィンドウアテンション (SWA) レイヤー KV プール使用率。ハイブリッド SWA モデルの場合にのみ表示されます。 mamba：Mamba/線形アテンションレイヤー状態プール使用率。ハイブリッド SSM モデルの場合にのみ表示されます。 pending_prealloc：PD 分離モードで、事前に予約されているがまだ事前割り当てされていないトークンの比率。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます。	`sglang:full_token_usage` `sglang:swa_token_usage` `sglang:mamba_usage` `sglang:pending_prealloc_token_usage`

KV 転送

以下のパネルは、サービスが PD 分離 (プレフィル/デコード分離) モードでデプロイされている場合にのみデータがあります。複数インスタンスのサービスの場合、レイテンシメトリクスはすべてのインスタンスで加重平均されます。

メトリクス	説明	Prometheus メトリクス
KV 転送レイテンシ	この時点で KV キャッシュをプレフィルインスタンスからデコードインスタンスに転送する時間 (ミリ秒)。 Avg：加重平均転送期間。 P50/P95/P99：転送期間のパーセンタイル値。	`sglang:kv_transfer_latency_ms`
KV 転送合計 MB	この時点での単一 KV 転送のデータサイズ (MB)。 Avg：転送あたりの加重平均データサイズ。 P99：転送あたりの 99 パーセンタイルデータサイズ。	`sglang:kv_transfer_total_mb`
KV 転送速度	この時点での KV 転送帯域幅。 Avg：加重平均転送帯域幅。 P99：99 パーセンタイル転送帯域幅。	`sglang:kv_transfer_speed_gb_s`
KV 転送ブートストラップ	この時点での KV 転送ハンドシェイク (ブートストラップ) 接続確立時間 (ミリ秒)。高い値は通常、帯域幅の問題ではなく、プレフィルインスタンスとデコードインスタンス間のメタデータ交換またはネットワーク接続の問題を示します。 Avg：加重平均接続確立期間。 P50/P95/P99：接続確立期間のパーセンタイル値。	`sglang:kv_transfer_bootstrap_ms`
KV 転送割り当て待機	この時点でデコードインスタンスが KV キャッシュを受信するために GPU メモリ割り当てを待機する時間 (ミリ秒)。高い値はデコード側の GPU メモリ競合を示し、PD クラスター比率の不均衡を示唆します。 Avg：加重平均待機期間。 P99：99 パーセンタイル待機期間。	`sglang:kv_transfer_alloc_ms`

投機的デコーディング

以下のパネルは、投機的デコーディングが有効な場合にのみデータがあります。パネルは pp_rank/moe_ep_rank によって個別の曲線としてプロットされます (凡例形式：pp{pp_rank}/ep{moe_ep_rank})。各曲線はすべてのインスタンスで平均化されます。

メトリクス	説明	Prometheus メトリクス
投機的受容長 (ドラフト→ターゲット)	この時点での投機的デコーディングの平均受容長 (論文中の τ)。これは、検証ステップごとに実際に生成されるトークン数であり、ターゲットモデルが常に生成するボーナストークンを含みます。値が 1 の場合、投機的デコーディングは効果がないことを意味します (ステップごとにボーナストークンのみが生成されます)。値が高いほど、高速化の効果が高いことを示します。	`sglang:spec_accept_length`
仕様承認率	この時点での投機的デコーディングのドラフト受容率 (論文中の α)。計算式：受容されたドラフトトークン ÷ 提案されたドラフトトークン。ボーナストークンを除きます。これは、ドラフトモデルがターゲットモデルの分布にどれだけ近いかを反映します。	`sglang:spec_accept_rate`
投機的ステップとドラフトトークン	この時点でのアクティブな投機的デコーディング構成パラメーター。 steps：現在の投機的ステップ (`speculative_num_steps`)。 draft_tokens：現在のドラフトトークン数 (`speculative_num_draft_tokens`)。`topk > 1` の場合、この値はステップ数から切り離されます。説明適応型投機的デコーディングが有効な場合、この構成はワークロードに応じて動的に変化します。これを「受容長」曲線と比較して、適応戦略が適切かどうかを判断します。	`sglang:spec_num_steps` `sglang:spec_num_draft_tokens`

スケジューリング

メトリクス	説明	Prometheus メトリクス
PD ステージ別キューリクエスト	この時点での各 PD 分離キュー内のリクエスト数。このメトリクスを使用して、PD パイプラインのどこでリクエストが蓄積しているかを特定します。 prefill_bootstrap：プレフィル側でハンドシェイク接続を待機しているリクエスト。 prefill_inflight：プレフィル側で KV キャッシュが転送中のリクエスト。 decode_prealloc：デコード側で GPU メモリの事前割り当てを待機しているリクエスト。 decode_transfer：デコード側で KV キャッシュ転送の完了を待機しているリクエスト。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:num_prefill_bootstrap_queue_reqs` `sglang:num_prefill_inflight_queue_reqs` `sglang:num_decode_prealloc_queue_reqs` `sglang:num_decode_transfer_queue_reqs`
SLO 使用率	この時点での SLO 容量に対する負荷レベル。計算式：`max(実行中のリクエスト ÷ SLO 下の最大同時実行数, KV キャッシュ使用率 ÷ 0.9)`。このメトリクスは、auto scaling の参考として使用できます。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます。	`sglang:utilization`
CUDA グラフパス	この時点での CUDA グラフヒットステータス別に分類された順方向パスのレート。`mode` ラベルによって個別の曲線としてプロットされます。 decode_cuda_graph/decode_none：CUDA グラフヒットあり/なしのデコード順方向パスのレート。 prefill_cuda_graph/prefill_none：CUDA グラフヒットあり/なしのプレフィル順方向パスのレート。説明 `*_none` の比率が高い場合は、バッチ形状がキャプチャされたグラフの範囲外に頻繁に収まっていることを示します。CUDA グラフキャプチャのバッチサイズリストを調整することで、これを最適化できます。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:cuda_graph_passes_total`
順方向占有率	この時点での順方向計算による GPU 占有率。計算式：GPU 順方向実行時間 ÷ 統計ウィンドウ内の実時間。値の範囲：0〜100。低い値は、CPU スケジューリングのオーバーヘッドまたは GPU アイドル時間を示します。これは、スループットが期待どおりでない場合に最初に確認するメトリクスです。説明データは、エンジン側のデバイスタイマーが有効な場合にのみ利用可能です。サービスがアイドル状態になると、統計を汚染しないようにこの値は NaN に設定されます。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます。	`sglang:fwd_occupancy`
新規トークン比率	この時点でのスケジューラの新規トークンクォータ比率。この値は、GPU メモリ圧力に対する適応的な保守性係数です。GPU メモリが逼迫しているときに減少し、新規リクエストの受付を減らしてリトラクションを回避し、圧力が緩和されると徐々に 1 に回復します。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます。	`sglang:new_token_ratio`
CUDA グラフアクティブ	この時点でバッチが CUDA グラフで実行されているかどうか。1 は有効、0 は Eager モードへのフォールバックを意味します。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで平均化されます (CUDA グラフが有効なインスタンスの比率として理解できます)。	`sglang:is_cuda_graph`

HTTP

メトリクス	説明	Prometheus メトリクス
HTTP リクエストレート	この時点でのリクエストメソッドとパス別にグループ化されたリクエストレート (リクエスト/秒)。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:http_requests_total`
ステータス別 HTTP 応答レート	この時点でのパスと応答ステータスコード別にグループ化された応答レート (リクエスト/秒)。このメトリクスを使用して、クライアントエラー (4xx) とサーバーエラー (5xx) を区別します。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:http_responses_total`
HTTP アクティブリクエスト	この時点でのリクエストメソッドとパス別にグループ化された処理中の (まだ返されていない) リクエスト数。このメトリクスは、HTTP レイヤーの処理中リクエストをカウントし、まだエンジンに入っていないキュー内のリクエストも含まれます。したがって、この値は通常、実行中のリクエストよりも大きくなります。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:http_requests_active`

システムとエンジン

メトリクス	説明	Prometheus メトリクス
分離ルーティングキー	この時点でのルーティングキーの数。このメトリクスを使用して、PD 分離または複数インスタンスアフィニティルーティングの分布を観察します。 routing_keys_active：HTTP レイヤーで処理中のリクエストを持つ一意のルーティングキーの数。 unique_running_routing_keys：現在の実行バッチ内の一意のルーティングキーの数。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:routing_keys_active` `sglang:num_unique_running_routing_keys`
コンポーネント別プロセス CPU	この時点で各エンジンプロセスが消費する CPU コア (ユーザー + カーネル)。`component` ラベル (`tokenizer`、`detokenizer`、`data_parallel_controller`) によって個別の曲線としてプロットされます。このメトリクスを使用して、CPU 側のボトルネックを特定します。たとえば、トークナイザーが単一コアを飽和させると、全体のスループットが直接制限されます。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:process_cpu_seconds_total`
エンジンメタ	サービスの静的エンジン構成と起動情報。このメトリクスを使用して、実際のパラメーターが期待どおりかどうかを確認します。 max_total_num_tokens：KV キャッシュプールの最大トークン容量。 num_pages：KV キャッシュページ数。 page_size：KV キャッシュページサイズ (トークン数)。 context_len：モデルの最大コンテキスト長。 startup_available_gpu_memory_gb：起動時に利用可能な GPU メモリ (GB)。すべてのインスタンスで合計されます。 engine_startup_time：エンドツーエンドのエンジン起動時間 (秒)。 engine_load_weights_time：モデルの重み読み込み時間 (秒)。メモリ項目を除き、すべてのメトリクスはすべてのインスタンスの最大値を取ります。	`sglang:max_total_num_tokens` `sglang:num_pages` `sglang:page_size` `sglang:context_len` `sglang:startup_available_gpu_memory_gb` `sglang:startup_time_seconds`
リクエスト状態 (リトラクト/一時停止)	この時点での異常な実行状態にあるリクエストの数。 retracted：GPU メモリ不足のために待機キューにリトラクトされ、再度プレフィルする必要があるリクエストの数。一貫して 0 より大きい値は、計算リソースが冗長な計算に浪費されていることを意味します。同時実行数を減らすか、スケールアップを検討してください。 paused：非同期の重み同期 (たとえば、RLHF シナリオでの重み更新) のために一時停止されたリクエストの数。複数インスタンスのサービスの場合、このメトリクスはすべてのインスタンスで合計されます。	`sglang:num_retracted_reqs` `sglang:num_paused_reqs`

一般的なトラブルシューティングパス

症状	推奨される確認順序
高い TTFT	キュー時間 → 待機中のリクエスト → 非キャッシュプロンプトトークン長 → プレフィックスキャッシュヒット率 → ロードバック期間
高い TPOT	実行中のリクエスト (過剰な同時実行数) → デコード合計シーケンス長 → KV キャッシュ使用率 → 順方向占有率 → CUDA グラフパスの `decode_none` 比率
スループットは低いが GPU 使用率は高くない	順方向占有率 → コンポーネント別プロセス CPU → CUDA グラフパス → 新規トークン比率
GPU メモリ不足 / リクエストのリトラクト	リクエスト状態のリトラクト → KV キャッシュトークンプール (`available` と `evictable` の両方がゼロに低下しているか確認) → プール別 KV 使用率 → 新規トークン比率
ハイブリッドアテンションモデルが同時実行数をスケールアップできない	プール別 KV 使用率 (full/swa/mamba を比較) → Mamba SSM プール
PD 分離パイプラインが遅い	PD ステージ別キューリクエスト → KV 転送ブートストラップ → KV 転送レイテンシ/速度 → KV 転送割り当て待機
投機的デコーディングが高速化を提供しない	投機的受容長 (1 に近いか？) → 投機的受容率 → 投機的ステップとドラフトトークン
最近の最大同時実行数を見つける	時間範囲を変更し、「実行中および待機中のリクエスト」の「実行中」曲線のピークを見つける

VLLM 監視ダッシュボード

複数インスタンスのサービスの場合、スループットメトリクスは合計され、レイテンシメトリクスはインスタンス間で平均化されます。

メトリクス	説明
リクエストステータス	サービスの合計リクエスト数。実行中：GPU で実行中のリクエスト数。待機中：処理を待機しているリクエスト数。スワップ済み：CPU にスワップされたリクエスト数。
トークンスループット	サービスのすべてのリクエストの入力トークンと生成トークンの数。 TPS_IN：入力トークン数。 TPS_OUT：出力トークン数。
リクエスト完了ステータス	サービスのすべてのリクエストの完了ステータス統計。 preemptions：プリエンプトされたリクエスト。 stop：自然終了により正常に完了したリクエスト (モデルが停止トークン、たとえば <EOS> を出力)。 length：リクエストが最大出力トークン長に達した。 abort：強制的に終了されたリクエスト。
最初のトークンまでの時間 (TTFT)	サービスのすべてのリクエストの最初のトークンまでの時間レイテンシ (リクエストを受信してから最初のトークンを生成するまでの時間)。 Avg：すべてのリクエストの最初のトークンまでの平均レイテンシ。 TPXX：すべてのリクエストの最初のトークンまでのレイテンシのパーセンタイル値。
出力トークンあたりの時間 (TPOT)	サービスのすべてのリクエストの出力トークンあたりのレイテンシ (最初のトークンが生成された後、各出力トークンに必要な平均時間)。 Avg：すべてのリクエストのトークンあたりの平均レイテンシ。 TPXX：すべてのリクエストのトークンあたりのレイテンシのパーセンタイル値。
エンドツーエンドリクエストレイテンシ	サービスのすべてのリクエストのエンドツーエンドレイテンシ (リクエストを受信してからすべてのトークンを返すまでの時間)。 Avg：すべてのリクエストの平均エンドツーエンドレイテンシ。 TPXX：すべてのリクエストのエンドツーエンドレイテンシのパーセンタイル値。
キュー時間	サービスのすべてのリクエストのキュー待機レイテンシ (リクエストがエンジン処理を待機する時間)。 Avg：すべてのリクエストの平均キュー待機レイテンシ。 TPXX：すべてのリクエストのキュー待機レイテンシのパーセンタイル値。
推論時間	サービスのすべてのリクエストの推論レイテンシ (リクエストがエンジンによって処理される時間)。 Avg：すべてのリクエストの平均推論レイテンシ。 TPXX：すべてのリクエストの推論レイテンシのパーセンタイル値。
プレフィル時間	サービスのすべてのリクエストのプレフィルステージレイテンシ (エンジンがリクエスト入力トークンを処理する時間)。 Avg：すべてのリクエストの平均プレフィルレイテンシ。 TPXX：すべてのリクエストのプレフィルレイテンシのパーセンタイル値。
デコード時間	サービスのすべてのリクエストのデコードステージレイテンシ (エンジンが出力トークンを生成する時間)。 Avg：すべてのリクエストの平均デコードレイテンシ。 TPXX：すべてのリクエストのデコードレイテンシのパーセンタイル値。
入力トークン長	サービスによって処理された入力トークンの数。 Avg：すべてのリクエストの平均入力トークン長。 TPXX：すべてのリクエストの入力トークン長のパーセンタイル値。
出力トークン長	サービスによって生成された出力トークンの数。 Avg：すべてのリクエストの平均出力トークン長。 TPXX：すべてのリクエストの出力トークン長のパーセンタイル値。
リクエストパラメーター (params_n & max_tokens)	サービスのすべてのリクエストのパラメーター N とパラメーター max_tokens。 Params_n：すべてのリクエストのパラメーター N の平均値。 Params_max_tokens：すべてのリクエストのパラメーター max_tokens の平均値。
GPU KV キャッシュ使用率	サービスの平均 GPU KV キャッシュ使用率。
CPU KV キャッシュ使用率	サービスの平均 CPU KV キャッシュ使用率。
プレフィックスキャッシュヒット率	サービスのすべてのリクエストの平均プレフィックスキャッシュヒット率。 GPU：すべてのリクエストの平均 GPU プレフィックスキャッシュヒット率。 CPU：すべてのリクエストの平均 CPU プレフィックスキャッシュヒット率。
エンドポイント別 HTTP リクエスト	リクエストメソッド、パス、および応答ステータスコード別にグループ化されたサービスのリクエスト数。
HTTP リクエストレイテンシ	サービスの異なるリクエストパスの平均レイテンシ。
投機的デコーディングスループット	サービスの投機的デコーディング数。複数インスタンスのサービスの場合、インスタンス間で平均化されます。 Drafts：生成されたドラフトトークン数。 Draft Tokens：処理されたドラフトトークン数。 Accepted Tokens：受容されたドラフトトークン数。 Emitted Tokens：発行されたドラフトトークン数。
投機的デコーディング効率	サービスの投機的デコーディングパフォーマンス。 Draft Acceptance Rate：受容されたドラフトトークンの平均比率。 Efficiency：投機的デコーディングの平均効率。
位置別トークン受容	サービスの異なる生成位置で受容されたドラフトトークン数。複数インスタンスのサービスの場合、インスタンス間で平均化されます。

よくある質問

LLM 監視ダッシュボードが表示されない

問題：カスタム EAS デプロイ後、モニタリングページにはサービスと GPU ダッシュボードのみが表示され、LLM モニタリングが表示されません。

原因：サービス構成に、推論エンジンのタイプを宣言する ServiceEngineType タグがありません。

説明

ServiceEngineType タグのみが LLM モニタリングに影響します。他のモデルギャラリーのデプロイメントパラメーターは影響しません。

解決策：サービス構成を更新して ServiceEngineType タグを追加し、使用する推論エンジンに基づいてその値を設定します (vllm または sglang のみがサポートされています)。例：

{
  "labels": {
    "ServiceEngineType": "vllm"
  }
}

Q: なぜ /metrics 200 がログに頻繁に表示されるのですか？

ServiceEngineType タグが有効になると、EAS バックエンドはすべての Pod で 10〜15 秒ごとに推論フレームワークの /metrics エンドポイントをポーリングします。このエンドポイントは、LLM 監視ダッシュボードのために Prometheus 形式でリアルタイムメトリクスを返します。

Q: モニタリングで最大同時実行数を確認する方法は？

EAS モニタリングは、直接的な「最大同時実行数」メトリクスを提供しません。サービスタイプに基づいて同時実行数を判断できます。

LLM 推論サービス (vllm または sglang エンジン)：[VLLM 監視ダッシュボード] または [SGLang 監視ダッシュボード] に切り替え、[リクエストステータス] または [リクエスト数] の下の [実行中] メトリクスを確認します。このメトリクスは、現在 GPU で実行中のリクエスト数を示し、リアルタイムの同時実行数を表します。時間範囲を変更する (たとえば、過去 1 時間または過去 6 時間を選択する) ことで、[実行中] 曲線のピーク値を見つけることができ、それがその期間内の最大同時実行数です。
一般サービス：サービス監視ダッシュボードの QPS (秒間クエリ数) と RT (応答時間) メトリクスを使用して同時実行数を推定できます。リトルの法則に基づき、同時実行数 ≈ QPS × 平均 RT (秒) となります。たとえば、QPS が 10 で平均 RT が 2 秒の場合、同時実行数は約 20 です。ピーク時にこの数式を適用して、最大同時実行数を推定します。

Q: エンドツーエンドリクエストレイテンシと RT の違いは何ですか？

エンドツーエンドリクエストレイテンシは LLM 推論エンジンによって提供され、RT は EAS エンジン (easworker) によって提供されます。LLM シナリオでは、エンドツーエンドリクエストレイテンシを推奨します。

Platform For AI:サービス監視の概要