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

如果AI 變慢，我該先看 GPU、Model 還是 Network？

Day 24 我談到，AI 上 Production 後不能只看「服務有沒有掛掉」，還需要知道系統到底發生什麼?

但真正遇到問題時，又會出現另一個困難：

如果使用者告訴我「AI 變慢了」，我第一個應該檢查什麼？

以前遇到程式變慢，我可能直覺想到 CPU、Memory 或 Network。但 AI Inference 的處理流程更加複雜，一個 Request 從進入服務，到模型開始產生第一個 Token，再到完整回答，中間可能經過 Load Balancer、Queue、Model Server、GPU、Runtime 等不同環節。

我自己在接觸 AI Infrastructure 的過程中，越來越感受到：真正重要的能力不是背下一堆 Monitoring 指標，而是能夠把「使用者看到的問題」逐層往下拆。

例如 Google Cloud 目前針對 GKE AI inference，會區分 TTFT、TPOT、ITL、Request Latency 與 Throughput 等不同重要效能指標。這些數值可以幫助我們判斷問題究竟發生在等待第一個 Token，還是發生在後續 Token 的生成階段。

而 Kubernetes 的 Observability 又可以把 Metrics、Logs 與 Traces 串在一起，從系統數值、事件紀錄到 Request 流程，逐步縮小問題範圍。

這讓我開始建立一個很簡單的思考方式：

先確認「慢在哪裡?」，再問「為什麼慢?」。

如果 Queue 增加，可能是請求進來太多；如果 TTFT 變高，可能需要檢查模型服務與 GPU 資源；如果整體 Request Latency 增加，則還要往 Network、Gateway 與 Application 路徑繼續追。

所以問題來了：

當使用者只告訴我「AI 變慢了!」，我能不能從 Metrics、Logs 與 Traces 開始，一層一層找到真正的 Bottleneck？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我想建立的另一種 AI 工程思考方式。Troubleshooting 不是看到問題就猜原因，而是先定位「慢在哪一層」，再找出「為什麼慢?」。怎麼拆解 AI Infrastructure 問題?那找到之後怎麼處理？怎麼修？怎麼補？怎麼改善？

關於作者

我是一名 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的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~