nvidia-smi 是排查 GPU 問題時最常使用的工具。指令一執行，就能看到 GPU utilization、顯示記憶體用量、溫度、功耗與占用程序。不過，這些資訊只能描述某個時間點的硬體狀態，無法直接回答使用者最在意的問題：為什麼請求變慢、失敗，甚至完全沒有回應？

要營運生成式 AI 服務，GPU 指標必須和主機、應用程式、日誌及分散式追蹤放在同一條時間線上，才有辦法從症狀一路找到原因。

GPU utilization 高，不一定代表服務健康

GPU utilization 表示取樣期間內，GPU 是否持續執行運算。數值接近 100% 可能是模型有效處理大量請求，也可能是單一長請求、異常重試或低效率 kernel 持續占用資源。

反過來說，utilization 很低也不一定代表 GPU 過剩。常見情況包括：

• 請求卡在 queue，尚未送進 GPU。
• CPU 正在進行 tokenization，GPU 只能等待。
• 模型權重或資料仍在 storage 與記憶體之間搬移。
• batch 太小，GPU 經常等待下一批工作。
• 應用程式受到鎖、網路或資料庫延遲限制。

因此，「GPU 很忙」只能當成線索，不能單獨當成服務品質的結論。

五組指標要一起看

1. GPU 運算

先觀察 GPU utilization、Tensor Core 使用情況與 SM occupancy，確認運算單元是否真的在工作。如果 utilization 呈現規律的尖峰與空檔，可能是 batch 不連續，或前處理供應速度跟不上。

2. 顯示記憶體

VRAM used 能確認模型與 KV cache 占用了多少空間，但「用滿」和「正在運算」是兩件事。模型載入後即使沒有請求，權重仍會常駐 VRAM；也可能因 KV cache 成長而接近上限，最後出現 OOM。

觀察 VRAM 時，應同時記錄模型版本、context length、batch size、併發數與量化格式，否則不同測試之間無法公平比較。

3. 功耗與溫度

功耗可輔助判斷 GPU 是否進入高負載狀態；溫度與時脈則能協助辨識 thermal throttling。若 utilization 維持高檔，但時脈下降、延遲持續上升，就要檢查散熱、功率上限與機房環境，而不是只調整模型參數。

4. 應用程式

對推論服務而言，至少要記錄：

• 請求量、錯誤率與進行中的請求數。
• queue depth 與 queue time。
• TTFT（Time to First Token）。
• TPOT（Time per Output Token）或每秒產生的 token 數。
• P50、P95、P99 latency。
• input/output token 數與 batch size。

TTFT 變差，可能和排隊、prefill 或模型載入有關；TPOT 變差，則更可能落在 decode、GPU contention 或記憶體頻寬。只看總延遲，會把不同階段的問題混在一起。

5. 主機與相依服務

CPU、RAM、disk I/O、network、container restart、database latency 與 storage latency 都可能讓 GPU 等待。GPU 指標正常但服務很慢時，這一層往往才是問題來源。

Metrics、Logs、Traces 各自回答不同問題

Metrics 適合找出異常從何時開始、持續多久、影響多少請求；Logs 用來還原元件當下發生的事件；Traces 則能拆解一次請求經過 queue、tokenization、prefill、decode、database 與 storage 的時間。

三種遙測資料應共用 timestamp、request ID、model version 與 instance ID。事故發生時，才能從延遲圖表找到特定請求，再沿著 trace 與 log 還原完整路徑。

告警要綁定使用者影響

「GPU utilization 超過 90%」不是一條完整的服務告警。高使用率可能正是容量被有效利用的證據。更有意義的條件是：

• P95 latency 超過 SLO，且 queue depth 持續增加。
• TTFT 上升，同時 GPU utilization 偏低、CPU 接近飽和。
• VRAM 接近上限，OOM 或容器重啟次數增加。
• GPU 溫度過高、時脈下降，且 token throughput 同步衰退。
• 錯誤率快速上升，集中在特定模型版本或 GPU 節點。

告警應該指向可採取的動作，例如調整併發、限制 context length、增加 replica、排查 CPU 前處理，或將異常節點移出服務。

結論

nvidia-smi 適合確認 GPU 是否存在、驅動是否正常，以及資源由哪些程序占用；真正的 GPU 可觀測性則要回答一個更完整的問題：使用者的請求在哪個階段變慢，背後受到哪一項資源或相依服務限制？

把 GPU、應用程式與主機指標放在同一條時間線，再用 logs 與 traces 補上事件脈絡，才有能力區分有效運算、排隊、資源爭用與等待。下一篇將比較 Ollama 與 vLLM 在相同模型下展現的不同營運行為。

參考資料

• Google SRE Book
• Prometheus Documentation
• NVIDIA DCGM Documentation
• vLLM Documentation