EAS監控指標 - Platform For AI

EAS服務部署成功後，您可以在服務詳情頁的監控頁簽查看QPS、延遲、錯誤率、資源使用率等指標，瞭解服務的調用和運行情況。

查看服務監控資訊

進入監控頁面

登入PAI控制台，在頁面上方選擇目標地區，並在右側選擇目標工作空間，然後單擊進入EAS。
單擊目標服務名稱進入詳情頁面，切換到监控頁簽。

選擇維度與儀錶盤

監控頁面左上方提供兩級選擇：先通過下拉框選擇監控維度（Service 或 Instance），再選擇對應的監控儀錶盤。

說明

LLM相關儀錶盤面向使用 vLLM 或 SGLang 引擎的 LLM 推理服務，需使用 PAI-EAS 官方鏡像服務，或標籤中配置ServiceEngineType為sglang或vllm（詳見LLM監控指標說明 > 前提條件）。
GPU 相關儀錶盤僅在使用 GPU 的服務中提供。

Service 維度：以整個服務為粒度查看監控指標。下拉框選擇 Service 後，可選以下儀錶盤：
- Service-<service_name>（其中<service_name>是EAS服務的名稱）：服務監控儀錶盤。展示服務的通用監控指標（QPS、RT、CPU、Memory 等）。
- LLM：根據 LLM 服務使用的推理引擎（sglang/vllm）展示不同的服務監控指標（如請求吞吐、Token 用量等）。
- GPU：展示 GPU 硬體指標（如 SM 利用率、顯存頻寬、NVSwitch 錯誤等）。
Instance 維度：以單個執行個體為粒度查看監控指標。下拉框選擇 Instance 後，可選以下儀錶盤：
- Single Instance：單一實例監控儀錶盤。每次只能選擇一個執行個體，僅提供分鐘級監控指標。
- Multiple Instance：多執行個體監控儀錶盤。可同時選擇多個執行個體進行對比，提供分鐘級和秒級監控指標。
- LLM Instance：LLM 執行個體監控儀錶盤。支援選擇單個或多個執行個體對比，展示大模型推理相關的執行個體級監控指標。
- GPU Instance：GPU 執行個體監控儀錶盤。支援選擇單個或多個執行個體對比，展示細粒度 GPU 硬體的執行個體級監控指標。

各儀錶盤對應的指標說明章節如下：

儀錶盤	指標說明章節
`Service-<service_name>`	通用監控指標說明 > 服務監控儀錶盤
Single Instance	通用監控指標說明 > 單一實例監控儀錶盤（分鐘級）
Multiple Instance	通用監控指標說明 >多執行個體監控儀錶盤
GPU / GPU Instance	通用監控指標說明 > GPU監控儀錶盤
LLM / LLM Instance	LLM監控指標說明

切換時間範圍

單擊監控地區右側的，切換儀錶盤展示的時間範圍。

在彈出的時間選取器面板中，可通過左側 Absolute time range 自訂起止時間（From / To），或在右側 Relative time ranges 列表中選擇預設範圍（Last 5 minutes 至 Last 7 days 等），當前選中項會顯示 ✓ 標記。

重要

目前分鐘級監控指標最多保留1個月，秒級監控指標最多保留1個小時。

通用監控指標說明

服務監控儀錶盤（分鐘級）

您可以在該儀錶盤監控以下指標：

指標		說明
QPS		服務每秒的請求數。不同返回碼的請求數會分開計算。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。其中，1d offset表示前一天同一時間的QPS資料，可用於分析環比資料。
Response		服務在選定時間範圍內接收的響應總數。不同返回碼的響應數會分開計算。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。
RT		請求的回應時間。 Avg：表示該時間點所有請求的平均回應時間。 TPXX：表示將該時間點所有請求時間從低到高排序後，前百分之XX請求的最大回應時間。例如：TP5表示前百分之五請求的最大回應時間；TP100表示所有請求的最大回應時間。如果服務包含多個執行個體，TP100表示所有執行個體的請求最大回應時間；其他TPXX為所有執行個體TPXX的均值，如TP5表示所有執行個體TP5的均值。
Daily Invoke		服務每天的調用量，不同返回碼的調用量會分開計算。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。

更多指標（CPU | Memory | GPU | Network | Resources）

指標		說明
CPU	CPU	服務在該時間點的CPU平均使用量。單位為核心數。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。
	CPU Utilization	服務在該時間點CPU平均使用率。計算方法：CPU平均使用量 ÷ 最大可用核心數。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。
	CPU Total	服務在該時間點可用的CPU總核心數。計算方法為：單一實例可用CPU核心數 × 服務執行個體數。
Memory	Memory	服務在該時間點的記憶體平均使用量。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。 RSS：表示常駐實體記憶體大小。 Cache：表示緩衝大小。 Total：表示單個執行個體最大可用的實體記憶體大小。
Memory	Memory Utilization	服務在該時間點的記憶體平均使用率。計算方法為：記憶體RSS ÷ 記憶體Total。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。
GPU	GPU Utilization	服務在該時間點的GPU平均使用率。僅在服務使用GPU時展示。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。
	GPU Memory	服務在該時間點的GPU顯存使用量。僅在服務使用GPU時展示。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。
	GPU Total	服務在該時間點的GPU總量。僅在服務使用GPU時展示。如果服務包含多個執行個體，則此處的指標為所有執行個體的GPU總和。
	GPU Memory Utilization	服務在該時間點的GPU顯存使用率。僅在服務使用GPU時展示。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。
Network	Traffic	服務接收和發出的流量大小，單位為位元每秒。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。其中： In：表示服務接收的流量。 Out：表示服務發出的流量。
Network	TCP Connections	TCP串連數。
Resources	Replicas	服務在該時間點不同狀態的執行個體數，分為Total、Pending、Available。
Resources	Replicas By Resource	服務在該時間點不同資源類型的執行個體數，分為Total、Dedicated（專屬資源）、Public（公用資源）。

單執行個體監控儀錶盤（分鐘級）

您可以在該儀錶盤監控以下指標：

指標	說明
QPS	該執行個體每秒接收的請求數。不同返回碼的請求數會分開計算。
RT	該執行個體請求的回應時間。
Response	該執行個體在選定時間範圍內接收的響應總數。不同返回碼的響應數會分開計算。

更多指標（CPU | Memory | GPU | Network | Resources）

指標		說明
CPU	CPU	該執行個體的CPU使用量，單位為核心數。
CPU	CPU Utilization	該執行個體在該時間點CPU平均使用率。計算方法為：CPU平均使用量 ÷ 最大可用核心數。
Memory	Memory	該執行個體的記憶體使用量量。 RSS：表示常駐實體記憶體大小。 Cache：表示緩衝大小。 Total：表示單個執行個體最大可用的實體記憶體大小。
Memory	Memory Utilization	該執行個體在該時間點的記憶體平均使用率。計算方法為：記憶體RSS ÷ 記憶體Total。
GPU	GPU Utilization	該執行個體的GPU使用率。
	GPU Memory	該執行個體的GPU顯存使用量。
	GPU Memory Utilization	該執行個體的GPU顯存使用率。
Network	Traffic	該執行個體接收和發出的流量大小，單位為位元每秒。其中： In：表示該執行個體接收的流量。 Out：表示該執行個體發出的流量。
Network	TCP Connections	TCP串連數。

多執行個體監控儀錶盤

提供分鐘級、秒級監控指標如下。

Minute-Level（分鐘級）

指標	說明
Instance QPS	每個執行個體每秒的請求數。不同返回碼的請求數會分開計算。
Instance RT	每個執行個體的平均回應時間。
Instance CPU	每個執行個體的CPU使用量，單位為核心數。
Instance Memory -- RSS	每個執行個體常駐實體記憶體大小。
Instance Memory -- Cache	每個執行個體緩衝大小。
Instance GPU	每個執行個體GPU使用率。
Instance GPU Memory	每個執行個體GPU顯存的使用量。
Instance TCP Connections	每個執行個體TCP串連數。

Second-Level（秒級）
重要
資料精度精確到5秒層級，只保留最近1個小時的資料。
指標
說明
Instance QPS Fine
每個執行個體每秒接收的請求數。不同返回碼的請求數會分開計算。
Instance RT Fine
每個執行個體接收到請求的平均回應時間。

GPU監控儀錶盤

支援在服務和執行個體層級監控以下GPU指標。如果是服務等級，則指標是所有執行個體的平均值。

指標	說明
GPU Utilization	服務在該時間點的GPU使用率。
GPU Memory	服務在該時間點的GPU顯存使用量與顯存總量。 Used：表示該時間點的GPU顯存使用量。 Total：表示該時間點的GPU顯存總量。
Memory Copy Utilization	服務在該時間點的GPU顯存複製利用率。
GPU Memory Utilization	服務在該時間點的GPU顯存使用率，計算方法為：顯存使用量 ÷ 顯存總量。
PCIe	通過DCGM測量的PCIe（Peripheral Component Interconnect Express，高速串列電腦擴充匯流排標準）速率。 PCIe Transmit：表示該時間點的PCIe傳輸速率。 PCIe Receive：表示該時間點的PCIe接收速率。
Memory Bandwidth	服務在該時間點的GPU顯存頻寬指標。
SM Utilization and Occupancy	服務在該時間點的SM（Streaming Multiprocessor，流式多處理器）相關指標，SM是GPU的核心組成部分，負責執行和調度並行計算任務。 SM Utilization：表示該時間點的SM利用率。 SM Occupancy：表示該時間點的SM上駐留的Warp線程數比例。
Graphics Engine Utilization	服務在該時間點的GPU圖形引擎利用率。
Pipe Active Ratio	服務在該時間點的GPU運算管道的活躍率。 Pipe Fp32 Active Ratio：表示該時間點的FP32管道活躍率。 Pipe Fp16 Active Ratio：表示該時間點的Fp16管道活躍率。 Pipe Tensor Active Ratio：表示該時間點的Tensor管道活躍率。
Tflops Usage	服務在該時間點的GPU運算管道的Tflops（Tera floating-point operations per second，每秒萬億次浮點運算）運算量。 FP32 Tflops Used：表示該時間點的FP32管道Tflops運算量。 FP16 Tflops Used：表示該時間點的Fp16管道Tflops運算量。 Tensor Tflops Used：表示該時間點的Tensor管道Tflops運算量。
DRAM Active Ratio	服務在該時間點的GPU裝置顯存介面發送或接收資料的活躍率。
SM Clock	服務在該時間點的SM時鐘頻率。
GPU Temperature	服務在該時間點的GPU溫度相關指標。 GPU Temperature：表示該時間點的GPU溫度。 GPU Slowdown Temperature：表示該時間點的GPU降頻溫度閾值；當GPU溫度達到該值時，GPU將自動降低其工作頻率，以避免GPU裝置過熱。 GPU Shutdown Temperature：表示該時間點的GPU關機溫度閾值；當GPU溫度達到該值時，系統將強制關停GPU裝置以防止GPU因過熱而導致硬體損壞或引發更嚴重的系統故障。
Power Usage	服務在該時間點的GPU功耗。

以下是GPU健康狀態與異常資訊指標：

指標	說明
GPU Health Count	服務在該時間點的健康GPU卡數。
GPU Lost Card Num	服務在該時間點的GPU掉卡數。
ECC Error Count	服務在該時間點的ECC錯誤數。ECC（Error Correction Code，錯誤校正碼）用於檢測和糾正GPU顯存資料轉送或預存程序中的錯誤。 Volatile SBE ECC Error：表示服務在該時間點的單位元易失性ECC錯誤數。 Volatile DBE ECC Error：表示服務在該時間點的雙位元易失性ECC錯誤數。 Aggregate SBE ECC Error：表示服務在該時間點的單位元持久性ECC錯誤數。 Aggregate DBE ECC Error：表示服務在該時間點的雙位元持久性ECC錯誤數。 Uncorrectable ECC Error：表示服務在該時間點的無法糾正的ECC錯誤數。
NVSwitch Error Count	服務在該時間點的NVSwitch錯誤數。NVSwitch 提供高頻寬和低延遲的通訊通道，負責多GPU之間的高速通訊。 NVSwitch Fatal Error：表示服務在該時間點的致命NVSwitch錯誤數。 NVSwitch Non-Fatal Error：表示服務在該時間點的非致命NVSwitch錯誤數。
Xid Error Count	服務在該時間點的Xid錯誤數。Xid錯誤是GPU驅動程式報告的錯誤碼，用於指示GPU在運行過程中遇到的問題，這些錯誤通常通過系統日誌（如Linux的dmesg或Windows的事件檢視器）記錄，並以Xid代碼的形式表示。 Xid Error：表示服務在該時間點的非致命Xid錯誤數。 Fatal Xid Error：表示服務在該時間點的致命Xid錯誤數。
Kernel Error Count	服務在該時間點的非Xid錯誤數。非Xid錯誤（Non-Xid Errors）指的是除了Xid錯誤之外，由核心日誌中報告的其他類型錯誤。
Driver Hang	服務在該時間點的GPU驅動掛起次數。
Remap Status	服務在該時間點GPU在嘗試重新對應顯存行時的狀態。

LLM監控指標說明

無論服務使用 vLLM 還是 SGLang 引擎，LLM 監控指標均統一展示在 LLM 或 LLM Instance 儀錶盤中。請根據引擎查看對應的監控指標說明。

前提條件

以下任一條件滿足時，展示 LLM 相關儀錶盤：

使用 PAI-EAS 的官方鏡像服務
在標籤中配置ServiceEngineType為sglang或vllm，配置樣本如下：
```
{
  "labels": {
    "ServiceEngineType": "sglang"
  }
}
```

注意：

EAS後端會定期（約10~15秒一次）調用引擎的/metrics介面採集Prometheus指標，因此服務日誌中會規律性出現/metrics 200記錄。
分鐘級監控指標最多保留1個月。

多執行個體彙總規則

如果服務包含多個執行個體，吞吐、計數、容量類指標為所有執行個體之和；比率、佔用率、延遲均值類指標為所有執行個體的平均值。

SGLang監控儀錶盤

Requests（請求）

指標	說明	Prometheus指標
Running & Waiting Reqs	服務在該時間點的請求數。 Running：正在GPU上啟動並執行請求數，即即時並發數。 Waiting：在等待隊列中排隊的請求數，持續大於0說明已過載。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:num_running_reqs` `sglang:num_queue_reqs`
Prompt & Generation Token Rate	服務在該時間點的輸入與輸出Token速率。 TPS_IN：每秒處理的輸入（Prefill）Token數。 TPS_OUT：每秒產生的輸出（Decode）Token數。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:prompt_tokens_total` `sglang:generation_tokens_total`
Request Rate (success/abort/fail)	服務在該時間點的請求速率，單位為請求每秒。 requests：處理完成的請求速率。 aborted：被中止（用戶端斷連、逾時、顯式abort）的請求速率。 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`

Latency（延遲）

指標	說明	Prometheus指標
Queue Time	服務在該時間點所有請求的排隊等待延時，即請求進入等待隊列到被調度器取出開始計算的時間。 Avg：所有請求排隊延時的加權平均值。 P50/P95/P99：所有請求排隊延時的各個分位點值。	`sglang:queue_time_seconds`
Time To First Token	服務在該時間點所有請求的首Token延時（TTFT），即從接收到請求到產生第一個Token的時間。 Avg：所有請求首Token延時的加權平均值。 P50/P95/P99：所有請求首Token延時的各個分位點值。	`sglang:time_to_first_token_seconds`
Time Per Output Token	服務在該時間點所有請求的每Token延時（TPOT/ITL），即產生第一個Token之後，後續每個輸出Token所需的時間。 Avg：所有請求每Token延時的加權平均值。 P50/P95/P99：所有請求每Token延時的各個分位點值。	`sglang:inter_token_latency_seconds`
E2E Request Latency	服務在該時間點所有請求的端到端延時，即從接收到請求到返回所有Token的時間。 Avg：所有請求端到端延時的加權平均值。 P50/P95/P99：所有請求端到端延時的各個分位點值。說明該指標由SGLang引擎提供，服務監控儀錶盤中的RT由EAS引擎（easworker）提供，LLM情境下建議使用本指標。	`sglang:e2e_request_latency_seconds`
Latency by PD Stage (Avg)	服務在該時間點請求在各處理階段的平均耗時，按`stage`標籤分曲線展示，用於定位延時具體消耗在哪一段。常見階段包括： `tokenize`（分詞）、`api_server_dispatch`（API Server分發）、`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`

Token Length Distribution（Token長度分布）

指標	說明	Prometheus指標
Prompt Tokens Length	服務在該時間點所有請求的輸入Token長度分布。 Avg：輸入Token長度的加權平均值。 P50/P95/P99：輸入Token長度的各個分位點值。	`sglang:prompt_tokens_histogram`
Uncached Prompt Tokens Length	服務在該時間點所有請求未命中緩衝、需要實際計算的輸入Token長度分布（等於輸入Token長度減去命中首碼緩衝的Token長度）。該指標才是Prefill階段真實的算力開銷來源。 Avg：未緩衝輸入Token長度的加權平均值。 P50/P95/P99：未緩衝輸入Token長度的各個分位點值。	`sglang:uncached_prompt_tokens_histogram`
Generation Tokens Length	服務在該時間點所有請求的輸出Token長度分布。 Avg：輸出Token長度的加權平均值。 P50/P95/P99：輸出Token長度的各個分位點值。	`sglang:generation_tokens_histogram`

Token Throughput（Token吞吐）

指標

說明

Prometheus指標

Token Rate by Phase (Prefill/Decode)

服務在該時間點按階段拆分的Token處理速率，按mode標籤分曲線展示。

prefill_compute：Prefill階段實際參與計算的Token速率。
prefill_cache：Prefill階段由首碼快取命中、無需計算的Token速率。
decode：Decode階段產生的Token速率。

如果服務包含多個執行個體，則此處的指標為所有執行個體之和。

sglang:realtime_tokens_total

Decode Sum Seq Lens

服務在該時間點Decode批次中所有序列長度之和，反映Decode階段Attention的實際讀取規模。

如果服務包含多個執行個體，則此處的指標為所有執行個體之和。

sglang:decode_sum_seq_lens

Cache Hierarchy（緩衝層級）

指標	說明	Prometheus指標
Prefix Cache Hit Rate	服務在該時間點所有請求的首碼緩衝平均命中率。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。	`sglang:cache_hit_rate`
Cached Prompt Tokens by Source	服務在該時間點命中緩衝的輸入Token速率，按`cache_source`標籤分曲線展示緩衝層級。 device：命中GPU顯存中的首碼緩衝（L1）。 host：命中HiCache主機記憶體緩衝（L2）。 storage_<backend>：命中HiCache外部儲存後端（L3），尾碼為具體後端名。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:cached_tokens_total`
Cache Hit Ratio by Source	服務在該時間點各緩衝層級的命中佔比，計算方法為：該層級命中Token速率 ÷ 輸入Token總速率，取值已歸一到0~1。 <cache_source> ratio：各層級（device/host/storage_<backend>）的命中佔比。 uncached：未命中任何緩衝、需要實際計算的輸入Token佔比。	`sglang:cached_tokens_total` `sglang:prompt_tokens_total`
HiCache Host Tokens	服務在該時間點HiCache主機記憶體緩衝（L2）的Token水位。僅在開啟HiCache時展示。 used：主機緩衝已使用的Token數。 total：主機緩衝的Token總容量。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:hicache_host_used_tokens` `sglang:hicache_host_total_tokens`
Eviction Duration (GPU→CPU)	服務在該時間點將KV緩衝從GPU換出到主機記憶體的耗時。 Avg：換出耗時的加權平均值。 P99：換出耗時的99分位值。	`sglang:eviction_duration_seconds`
Load Back Duration (CPU→GPU)	服務在該時間點將KV緩衝從主機記憶體載入回GPU的耗時。該耗時會直接疊加到命中L2緩衝請求的TTFT上。 Avg：載入耗時的加權平均值。 P99：載入耗時的99分位值。	`sglang:load_back_duration_seconds`
Cache Tokens Flow (L1↔L2↔L3)	服務在該時間點KV緩衝在三級儲存之間的Token流轉速率，用於判斷HiCache的搬運方向與壓力。 L3→L2 prefetched（storage→host）：從外部儲存預取到主機記憶體的Token速率。 L2→L1 load_back（host→GPU）：從主機記憶體載入回GPU的Token速率。 L2→L3 backuped（host→storage）：從主機記憶體備份到外部儲存的Token速率。 L1→L2 evicted（GPU→host）：從GPU換出到主機記憶體的Token速率。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:prefetched_tokens_total` `sglang:load_back_tokens_total` `sglang:backuped_tokens_total` `sglang:evicted_tokens_total`

KV Cache Pool（KV緩衝池水位）

以下面板按槽位（slot）維度與水位維度分別展示各記憶體池的構成與壓力。如果服務包含多個執行個體，則槽位類指標為所有執行個體之和，使用率、水位佔比類指標為所有執行個體的平均值。

指標	說明	Prometheus指標
KV Cache Tokens Pool	服務在該時間點主KV緩衝池的槽位構成。 available：完全空閑、可直接分配的Token槽位元。 evictable：被Radix首碼緩衝佔用、可在需要時驅逐複用的Token槽位元。 used：正在被運行中請求佔用的Token槽位元。說明 `available`長期為0而`evictable`較大屬於正常狀態，說明顯存已被首碼緩衝充分利用；`available`與`evictable`同時接近0才意味著真正的顯存不足。	`sglang:kv_available_tokens` `sglang:kv_evictable_tokens` `sglang:kv_used_tokens`
SWA Tokens Pool	服務在該時間點滑動視窗注意力（SWA）池的槽位構成，含available/evictable/used三條曲線，含義同上。僅混合SWA模型展示。	`sglang:swa_available_tokens` `sglang:swa_evictable_tokens` `sglang:swa_used_tokens`
Mamba SSM Pool	服務在該時間點Mamba SSM狀態池的槽位構成，含available/evictable/used三條曲線，含義同上。僅混合SSM（Mamba/GDN/KDA）模型展示。說明該池的槽位是按請求而非按Token分配的，是混合模型並發度的常見硬約束。	`sglang:mamba_available_tokens` `sglang:mamba_evictable_tokens` `sglang:mamba_used_tokens`
KV Cache Used Tokens	服務在該時間點已使用的KV緩衝Token數。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:num_used_tokens`
KV Cache Usage Ratio	服務在該時間點的KV緩衝Token平均使用率。持續接近1說明顯存池已成為吞吐瓶頸，會觸發請求排隊或回退（retract）。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。	`sglang:token_usage`
KV Usage by Pool (Full/SWA/Mamba)	服務在該時間點各記憶體池的平均使用率，用於混合注意力模型定位是哪一個池先打滿。 full：全量注意力層KV池使用率。 swa：滑動視窗注意力（SWA）層KV池使用率，僅混合SWA模型展示。 mamba：Mamba/線性注意力層狀態池使用率，僅混合SSM模型展示。 pending_prealloc：PD分離情境下已預留但尚未完成預分配的Token佔比。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。	`sglang:full_token_usage` `sglang:swa_token_usage` `sglang:mamba_usage` `sglang:pending_prealloc_token_usage`

KV Transfer（PD分離KV傳輸）

以下面板僅在服務以PD分離（Prefill/Decode Disaggregation）模式部署時有資料。如果服務包含多個執行個體，則延遲類指標為所有執行個體的加權平均值。

指標	說明	Prometheus指標
KV Transfer Latency	服務在該時間點KV緩衝從Prefill執行個體傳輸到Decode執行個體的耗時，單位為毫秒。 Avg：傳輸耗時的加權平均值。 P50/P95/P99：傳輸耗時的各個分位點值。	`sglang:kv_transfer_latency_ms`
KV Transfer Total MB	服務在該時間點單次KV傳輸的資料量，單位為MB。 Avg：單次傳輸資料量的加權平均值。 P99：單次傳輸資料量的99分位值。	`sglang:kv_transfer_total_mb`
KV Transfer Speed	服務在該時間點KV傳輸的頻寬。 Avg：傳輸頻寬的加權平均值。 P99：傳輸頻寬的99分位值。	`sglang:kv_transfer_speed_gb_s`
KV Transfer Bootstrap	服務在該時間點KV傳輸握手（bootstrap）建鏈的耗時，單位為毫秒。該耗時偏高通常指向Prefill/Decode之間的元資訊互動或網路建鏈問題，而非頻寬問題。 Avg：建鏈耗時的加權平均值。 P50/P95/P99：建鏈耗時的各個分位點值。	`sglang:kv_transfer_bootstrap_ms`
KV Transfer Alloc Wait	服務在該時間點Decode執行個體為接收KV緩衝而等待顯存分配的耗時，單位為毫秒。該耗時偏高說明Decode側顯存緊張，是PD叢集配比失衡的訊號。 Avg：等待耗時的加權平均值。 P99：等待耗時的99分位值。	`sglang:kv_transfer_alloc_ms`

Speculative Decoding（投機解碼）

以下面板僅在服務開啟投機解碼時有資料。面板按pp_rank/moe_ep_rank分曲線展示（圖例形如pp{pp_rank}/ep{moe_ep_rank}），每條曲線為所有執行個體的平均值。

指標	說明	Prometheus指標
Spec Accept Length (draft→target)	服務在該時間點投機解碼的平均接受長度（論文中的τ），即每次驗證（verify）步驟實際產出的Token數，包含目標模型必然產出的bonus Token。該值等於1表示投機完全未生效（每步只產出bonus Token），越大表示加速比越高。	`sglang:spec_accept_length`
Spec Accept Rate	服務在該時間點投機解碼的草稿接受率（論文中的α），計算方法為：被接受的草稿Token數 ÷ 提出的草稿Token數，不含bonus Token。反映草稿模型與目標模型的分布貼合程度。	`sglang:spec_accept_rate`
Spec Steps & Draft Tokens	服務在該時間點生效的投機解碼配置參數。 steps：當前生效的投機步數（`speculative_num_steps`）。 draft_tokens：當前生效的草稿Token數（`speculative_num_draft_tokens`）；在`topk > 1`時該值與步數解耦。說明開啟自適應投機時該配置會隨負載動態變化，可與Accept Length曲線對照判斷自適應策略是否合理。	`sglang:spec_num_steps` `sglang:spec_num_draft_tokens`

Scheduling（調度）

指標	說明	Prometheus指標
Queue Reqs by PD Stage	服務在該時間點各PD分離隊列中的請求數，用於定位PD鏈路的堆積位置。 prefill_bootstrap：Prefill側等待握手建鏈的請求數。 prefill_inflight：Prefill側正在傳輸KV緩衝的請求數。 decode_prealloc：Decode側等待預分配顯存的請求數。 decode_transfer：Decode側等待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 Utilization	服務在該時間點相對SLO容量的負載水位，計算方法為：`max(運行中請求數 ÷ SLO下最大並發數, KV緩衝使用率 ÷ 0.9)`，可作為彈性擴縮容的參考指標。說明 PD分離的Prefill執行個體不上報該指標。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。	`sglang:utilization`
CUDA Graph Passes	服務在該時間點按CUDA Graph命中情況分類的前向次數速率，按`mode`標籤分曲線展示。 decode_cuda_graph/decode_none：Decode前向命中/未命中CUDA Graph的速率。 prefill_cuda_graph/prefill_none：Prefill前向命中/未命中CUDA Graph的速率。說明 `*_none`佔比偏高說明批次形狀頻繁落在已捕獲的Graph之外，可通過調整CUDA Graph捕獲的batch size列表最佳化。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:cuda_graph_passes_total`
Forward Occupancy	服務在該時間點前向計算對GPU的佔用率，即統計視窗內GPU前向執行時間÷牆鐘時間，取值範圍0~100。該值偏低說明存在CPU調度開銷或GPU空轉，是排查吞吐不達標的首選指標。說明需開啟引擎側的device timer才有資料；服務空閑後該值會被置為NaN以避免汙染統計。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。	`sglang:fwd_occupancy`
New Token Ratio	服務在該時間點調度器的新Token配額比例。該值是調度器對顯存壓力的自適應保守係數：顯存緊張時下調以減少新請求准入、避免回退（retract），壓力緩解後逐步回升到1。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。	`sglang:new_token_ratio`
CUDA Graph Active	服務在該時間點批次是否運行在CUDA Graph上，1表示啟用，0表示回退到eager模式。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值（可理解為啟用CUDA Graph的執行個體佔比）。	`sglang:is_cuda_graph`

HTTP

指標	說明	Prometheus指標
HTTP Requests Rate	服務在該時間點按要求方法和路徑分組的請求速率，單位為請求每秒。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:http_requests_total`
HTTP Responses Rate by Status	服務在該時間點按路徑和響應狀態代碼分組的響應速率，單位為請求每秒。用於區分業務錯誤（4xx）與服務端錯誤（5xx）。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:http_responses_total`
HTTP Active Requests	服務在該時間點按要求方法和路徑分組的在途（未返回）請求數。該指標統計的是HTTP層的在途請求，包含仍在排隊、尚未進入引擎的請求，因此通常大於Running Reqs。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:http_requests_active`

System & Engine（系統與引擎）

指標	說明	Prometheus指標
Disaggregation Routing Keys	服務在該時間點的路由鍵（routing key）數量，用於觀測PD分離或多執行個體親和路由的分布情況。 routing_keys_active：HTTP層存在在途請求的唯一路由鍵數。 unique_running_routing_keys：當前運行批次中的唯一路由鍵數。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:routing_keys_active` `sglang:num_unique_running_routing_keys`
Process CPU by Component	服務在該時間點各引擎進程消耗的CPU核心數（使用者態+核心態），按`component`標籤分曲線展示（`tokenizer`、`detokenizer`、`data_parallel_controller`）。用於定位CPU側瓶頸，例如tokenizer打滿單核會直接壓制整體吞吐。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:process_cpu_seconds_total`
Engine Meta	服務的引擎靜態配置與啟動資訊，用於核對實際生效的參數是否符合預期。 max_total_num_tokens：KV緩衝池的最大Token容量。 num_pages：KV緩衝的頁數。 page_size：KV緩衝的頁大小（Token數）。 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`
Request State (retracted/paused)	服務在該時間點處於非正常執行狀態的請求數。 retracted：因顯存不足被回退（retract）到等待隊列、需要重新Prefill的請求數。該值持續大於0意味著算力在做重複計算，應下調並發或擴容。 paused：因非同步權重同步（如RLHF情境更新權重）而暫停請求數。如果服務包含多個執行個體，則此處的指標為所有執行個體之和。	`sglang:num_retracted_reqs` `sglang:num_paused_reqs`

常見排查路徑

現象	建議查看順序
TTFT偏高	Queue Time → Waiting Reqs → Uncached Prompt Tokens Length → Prefix Cache Hit Rate → Load Back Duration
TPOT偏高	Running Reqs（並發過高）→ Decode Sum Seq Lens → KV Cache Usage Ratio → Forward Occupancy → CUDA Graph Passes中`decode_none`佔比
吞吐不達標但GPU利用率不高	Forward Occupancy → Process CPU by Component → CUDA Graph Passes → New Token Ratio
顯存不足/請求被回退	Request State中retracted → KV Cache Tokens Pool（`available`與`evictable`是否同時歸零）→ KV Usage by Pool → New Token Ratio
混合注意力模型並發上不去	KV Usage by Pool（對比full/swa/mamba）→ Mamba SSM Pool
PD分離鏈路變慢	Queue Reqs by PD Stage → KV Transfer Bootstrap → KV Transfer Latency/Speed → KV Transfer Alloc Wait
投機解碼沒有加速效果	Spec Accept Length（是否接近1）→ Spec Accept Rate → Spec Steps & Draft Tokens
統計最近的最大並發數	切換時間範圍後，取Running & Waiting Reqs中Running曲線的峰值

VLLM監控儀錶盤

如果服務有多個執行個體，以下吞吐相關指標是執行個體的總和，延遲相關指標是執行個體的均值。

指標	說明
Requests Status	服務在該時間點的所有請求數。 Running：表示該時間點正在GPU上啟動並執行請求數。 Waiting：表示該時間點等待處理的請求數。 Swapped：表示該時間點被交換至CPU上的請求數。
Token Throughput	服務在該時間點所有請求的輸入與產生的Token數。 TPS_IN：表示該時間點輸入的Token數。 TPS_OUT：表示該時間點輸出的Token數。
Request Completion Status	服務在該時間點所有請求的完成狀態統計。 preemptions: 請求被搶佔。 stop: 請求因自然終止而成功完成（模型輸出了停止標記，如<EOS>）。 length: 請求已達到最大輸出token長度。 abort: 請求被強制終止。
Time To First Token	服務在該時間點所有請求的首Token延時（從接收到請求到產生第一個Token的時間）。 Avg：表示該時間點所有請求的首Token延遲的平均值。 TPXX：表示該時間點所有請求的首Token延遲的各個分位點值。
Time Per Output Token	服務在該時間點所有請求的每Token延時（產生第一個Token之後的每個輸出Token所需的平均時間）。 Avg：表示該時間點所有請求的每Token延遲的平均值。 TPXX：表示該時間點所有請求的每Token延遲的各個分位點值。
E2E Request Latency	服務在該時間點所有請求的端到端延時（從接收到請求到返回所有Token的時間）。 Avg：表示該時間點所有請求的端到端延遲的平均值。 TPXX：表示該時間點所有請求的端到端延遲的各個分位點值。
Queue Time	服務在該時間點所有請求的排隊等待延時（請求排隊等待被引擎處理的時間）。 Avg：表示該時間點所有請求的排隊等待延時的平均值。 TPXX：表示該時間點所有請求的排隊等待延時的各個分位點值。
Inference Time	服務在該時間點所有請求的推理延時（請求被引擎處理的時間）。 Avg：表示該時間點所有請求的推理延時的平均值。 TPXX：表示該時間點所有請求的推理延時的各個分位點值。
Prefill Time	服務在該時間點所有請求在 Prefill 階段的延時（引擎處理請求輸入Token的時間）。 Avg：表示該時間點所有請求的Prefill延時的平均值。 TPXX：表示該時間點所有請求的Prefill延時的各個分位點值。
Decode Time	服務在該時間點所有請求在 Decode 階段的延時（引擎產生輸出Token的時間）。 Avg：表示該時間點所有請求的Decode延時的平均值。 TPXX：表示該時間點所有請求的Decode延時的各個分位點值。
Input Token Length	服務在該時間點處理的輸入token數。 Avg：表示該時間點所有請求輸入token長度的平均值。 TPXX：表示該時間點所有請求輸入token長度的各個分位點值。
Output Token Length	服務在該時間點產生的輸出token數。 Avg：表示該時間點所有請求輸出token長度的平均值。 TPXX：表示該時間點所有請求輸出token長度的各個分位點值。
Request Parameters(params_n & max_tokens)	服務在該時間點所有請求的參數N和參數max_tokens。 Params_n：表示該時間點所有請求的參數N的平均值。 Params_max_tokens：表示該時間點所有請求的參數max_tokens的平均值。
GPU KV Cache Usage	服務在該時間點的 GPU KV緩衝平均使用率。
CPU KV Cache Usage	服務在該時間點的 CPU KV緩衝平均使用率。
Prefix Cache Hit Rate	服務在該時間點所有請求的 Prefix緩衝平均命中率。 GPU：表示該時間點所有請求的GPU Prefix緩衝平均命中率。 CPU：表示該時間點所有請求的CPU Prefix緩衝平均命中率。
HTTP Requests by Endpoint	服務在該時間點按要求方法、路徑和響應狀態代碼分組的請求數。
HTTP Request Latency	服務在該時間點不同請求路徑的平均延時。
Speculative Decoding Throughput	服務在該時間點的推測解碼數。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。 Drafts：表示該時間點產生的 Drafts Token數。 Draft Tokens：表示該時間點處理的 Drafts Token數。 Accepted Tokens：表示該時間點被接收的 Drafts Token數。 Emitted Tokens：表示該時間點輸出的 Drafts Token數。
Speculative Decoding Efficiency	服務在該時間點的推測解碼效能。 Draft Acceptance Rate：表示該時間點 Drafts Token 被接收的平均比例。 Efficiency：表示該時間點推測解碼的平均效率。
Token Acceptance by Position	服務在該時間點在不同產生位置的 Drafts Token 接受數。如果服務包含多個執行個體，則此處的指標為所有執行個體的平均值。

常見問題

Q：監控頁面缺少 LLM 監控儀錶盤

問題概述：使用者通過 EAS 自訂部署方式部署模型後，監控頁面僅顯示通用的 Service 和 GPU 監控，缺失 LLM 監控。

根本原因：服務配置缺少關鍵標籤 ServiceEngineType，該標籤用於顯式聲明後端推理引擎類型。

說明

除 ServiceEngineType標籤外，Model Gallery 部署所帶的其他參數均不影響 LLM 監控。

解決方案：更新服務配置，添加ServiceEngineType的標籤，並根據所採用的推理部署引擎設定其值（僅支援 vllm或sglang）。配置樣本如下：

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

Q: 日誌裡頻繁出現/metrics 200的原因是什嗎？

當ServiceEngineType標籤正確配置生效後，EAS後端會定期調用推理部署架構的/metrics介面（約10-15秒一次，包含採集間隔及輪詢所有pod的時間）。該介面以Prometheus格式提供即時架構指標，前端據此渲染LLM監控資料。

Q：監控中怎麼統計最近的最大並發數？

EAS監控目前沒有直接的"最大並發數"指標，可以根據服務類型通過以下方式瞭解並發情況：

LLM推理服務（vllm或sglang引擎）：切換到VLLM監控儀錶盤或SGLang監控儀錶盤，查看Requests Status或Requests Num中的Running指標，該指標表示當前正在GPU上啟動並執行請求數，即即時並發數。通過切換時間範圍（例如選擇Last 1 hours或Last 6 hours），找到Running曲線的峰值，即為該時間段內的最大並發數。
普通服務：可以通過服務監控儀錶盤中的QPS（每秒請求數）和RT（回應時間）來估算並發量。根據Little's Law：並發數 ≈ QPS × 平均RT（秒）。例如，QPS為10、平均RT為2秒時，並發數約為20。取該公式在峰值時段的結果，即可估算最大並發數。

Q：E2E Request Latency 與 RT 的區別？

E2E Request Latency 由LLM推理引擎提供，而RT由 EAS引擎（easworker）提供。在LLM情境下建議使用E2E Request Latency。

Platform For AI：服務監控說明