我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

如果AI 上 Production 後，我到底要監控什麼？

Day 23 我談到，AI Service 可以透過 Autoscaling 動態增加 GPU 資源，但資源增加之後，另一個問題也跟著出現：

我怎麼知道現在到底發生了什麼？

如果只看到「服務還可以使用」，可能很容易以為系統一切正常。但 AI Service 真正進入 Production 後，使用者感受到的問題可能是回應變慢、請求開始排隊、GPU 記憶體不足，甚至錯誤率逐漸增加。

我自己從 AI Infrastructure、Cloud 與 Kubernetes 的學習過程中，越來越理解 Monitoring 和單純「看 CPU 使用率」其實是不同層次的事情。

Kubernetes 官方目前將 Observability 分成 Metrics、Logs 與 Traces 三大類。Metrics 可以告訴我們系統的數值狀態，Logs 可以協助了解發生過什麼事情，而 Traces 則可以追蹤一次 Request 經過系統不同元件的路徑。

而 AI Inference 又有自己的特殊指標。例如 Google Cloud 目前針對 GKE 的 LLM inference，會關注 TTFT、NTPOT、Request Latency、Throughput，以及 Queue Size、Batch Size、KV Cache 等AI-specific指標；GPU 本身也可以觀察使用率與記憶體使用情況。

這讓我開始重新思考：

AI Production 的 Monitoring，不應該只是回答「伺服器有沒有掛掉」，而應該回答「使用者體驗、模型服務、GPU 與 Infrastructure 現在到底發生什麼？」

所以問題來了：

**如果今天 AI 回應突然變慢，我要怎麼判斷問題究竟來自 Model、Queue、GPU、Network，還是 Infrastructure？**為什麼有問題?

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來要從 Monitoring 走向 Observability 的原因。因為「CPU 正常」並不代表 AI Service 正常。AI 變慢，到底是哪一層出問題？在書中我們一同思考原因，解決問題！避免問題！

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~