完成「Scheduler 實驗：Affinity、Priority、Sharing 到底改變了什麼」後，下一個問題是「DCGM + Prometheus：Kubernetes 裡怎麼看懂 GPU」能否重跑、否定並留下失敗原因。這就是今天的範圍。

今天要回答的問題

建立 GPU 指標 pipeline，觀察 node、GPU、Pod 或 workload 維度的 utilization、memory、errors。

工程邊界

Kubernetes 指標與 GPU 指標要能對到 Pod／Namespace

DCGM Exporter 可以把 GPU telemetry 暴露給 Prometheus；重點是保留 workload labels，讓你知道某張 GPU 的 utilization、memory、temperature 或 error 對應到哪個 Pod。

再把 serving metrics 與 trace 接進來，才能從「某張卡很忙」追到「哪個 namespace、哪個模型、哪一類 request 造成 tail latency」。這才是可操作的 observability。

一個可以直接重現的起點

GPU 監控要能對回 Pod 與工作負載

只看到某張卡 95% utilization 還不夠。要能回答：是哪個 namespace、哪個 Pod、哪個模型把資源吃掉，以及當下請求延遲是否一起上升。Dashboard 應同時顯示 GPU utilization、memory used、power／temperature、Pod restart 與服務 P95。

先確認 DCGM 指標真的有進來

這份 YAML 將「部署或驗證 DCGM metrics pipeline，對照實際請求負載」的變因與觀察欄位留在版本控制中，再由實際 workload 引用。

apiVersion: v1
kind: ConfigMap
metadata:
  name: day21-experiment
  namespace: ai-lab
data:
  change: "部署或驗證 DCGM metrics pipeline，對照實際請求負載"
  fixed: "image, model, input"
  metrics: "DCGM GPU/VRAM, scrape health, request rate, P95"
  repeats: "3"

驗證與落地方式

驗證可從「部署或驗證 DCGM metrics pipeline，對照實際請求負載」開始。選擇一組具有代表性的請求，讓 correlation ID 從入口一路傳到 Pod、模型與下游服務，並先校正各元件時間。接著製造一個可控制的延遲或錯誤，確認 metric、log 與 trace 能否指向同一段時間與同一個工作負載。

這篇優先比較：DCGM GPU/VRAM、scrape health、request rate、P95。重點不只是「有資料」，而是資料能否回答使用者受到什麼影響、哪個元件先異常，以及問題是否集中在特定 node、Pod 或 GPU。缺少 label、時間戳不一致或 cardinality 過高，都可能讓資料存在卻無法用於排障。

常見誤判

• Dashboard 有圖就認為可觀測性完成，實際事故發生時卻無法從請求追到執行位置。
• 只收集 GPU utilization，沒有同步保留 request rate、queue、latency 與 error，難以判斷因果關係。
• 所有欄位無限制寫入 label，造成 Prometheus cardinality 與儲存成本快速增加。

上線前檢查

先定義保留期限、取樣策略、敏感欄位遮蔽與必要 labels，再建立從告警到 dashboard、log 與 trace 的固定查詢路徑。版本更新後也要驗證 metric 名稱與 labels 沒有悄悄改變，避免監控仍顯示綠色，實際上資料早已中斷。

遙測管線本身也需要健康檢查。若 exporter、scrape 或儲存層中斷，告警應明確指出資料缺失，不能把空白圖表解讀成系統沒有異常。

如何閱讀結果

排障時先從使用者層的錯誤率與延遲確定影響範圍，再用 trace 縮小服務與時間區段，最後以 log 和 GPU／node metrics 驗證假設。這個順序可以減少從大量主機指標盲目搜尋的時間。

若同一請求無法在各層對齊，應把缺口視為驗證失敗，而不是依靠人工猜測補完。可觀測性的價值在於縮短不確定時間，而不是累積最多資料。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：確認 telemetry 能對回 workload 與時間窗。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：確認 telemetry 能對回 workload 與時間窗。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：從 Pod 到請求：Logs、Metrics、Tracing 如何串起 AI Serving。

參考資料

• Kubernetes: Schedule GPUs
• Kubernetes: Resource Management
• Kubernetes: Assigning Pods to Nodes
• NVIDIA DCGM Documentation