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

如果AI Service 掛掉了，Production 應該怎麼辦？

前幾天從 Monitoring、Troubleshooting 一路談到 Bottleneck Optimization，但即使效能調整得再好，我開始思考另一個更現實的問題：

如果 AI Service 有一天真的掛掉了呢？AI Service 壞掉時，系統能不能自己發現、隔離並恢復？

自己做 Demo 時，程式出錯可能重新啟動就好。但到了真正進入 Production，如果使用者正在使用服務，「我等等手動重開」顯然不是理想答案。也不可能每次都等工程師發現問題，再手動登入伺服器 Restart。

我在學習 Cloud、Container、Kubernetes 與 AI Infrastructure 的過程中，逐漸理解 Reliability 並不是要求系統「永遠不能故障」，而是要先思考：故障發生時，系統能不能偵測、隔離並恢復？

Kubernetes 就提供了不同的 Health Probe。Liveness Probe 可以判斷 Container 是否陷入無法正常工作的狀態，必要時重新啟動；Readiness Probe 則回答另一個問題：「這個 Pod 現在適不適合接收流量？」如果檢查失敗，Pod 可以暫時停止接收 Service 流量，而不是直接把請求送給一個還沒準備好的服務。Kubernetes 官方目前把 Startup、Liveness、Readiness Probe 分成不同責任：Startup 判斷程式是否完成啟動；Liveness 判斷是否需要重新啟動 Container；Readiness 則決定 Pod 現在是否應該接收流量。

AI Service 又有一個很有意思的情況：Process 啟動了，不代表 Model 已經準備好回答問題。

大型模型可能還在載入權重、初始化 GPU 或建立服務環境。這也是 Startup Probe 可以發揮作用的地方，在應用真正啟動前，避免過早進行 Liveness / Readiness 檢查。

這讓我開始重新理解 Production Reliability：

真正重要的不是保證「永遠不壞」，而是系統壞掉時，能不能知道自己壞了，而且知道下一步該怎麼辦。

所以問題來了：

如果 AI Process 還活著，但 Model 已經無法正常回答 Request，它到底算「活著」，還是其實已經故障了？ AI Service 壞掉時，系統能不能自己發現、隔離並恢復？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我認為從 Demo 走向 Production 必須回答的問題。這也是我認為 Demo 與 Production 之間非常重要的一道分界線。Production-ready 並不是要求系統永遠不發生故障，而是故障發生時，系統具備偵測、隔離與恢復的能力。一個 AI Model Server 可能還活著，卻因為模型尚未載入完成或暫時過載而不適合接收新的 Request。這時候與其直接把它殺掉，更合理的方式可能是先停止把流量送過去。

關於作者

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