Kubernetes 在 AI 部署裡做什麼？
下列何者為 Kubernetes 在 AI 模型部署與運行中的核心功能？
Kubernetes（通常縮寫成 K8s）是一套用來管理「容器（container）」的工具。
這題問你：當公司把 AI 模型上線提供服務時，Kubernetes 主要負責什麼事？
一句話總結
Kubernetes 是 AI 模型上線後的「服務管家」，核心是管理與協調模型服務的部署、擴展與運行環境，讓模型在多台機器上穩定跑、流量大了自動加機器、壞了自動重啟。
先感受問題：模型訓練好了，然後呢？
假設「智慧信貸」公司的工程師王俊訓練好了一個信用評分模型，準確率 92%。
但問題來了：訓練好的模型只是一個檔案，怎麼讓它變成一個能被 App 即時查詢的服務？
他把模型包進一個「容器（container）」，容器就像一個完整的迷你電腦環境，裡面有 Python、套件、模型本身，隨時可以啟動。
但下一個問題更難：
- 每天查詢量不穩定，早上 1,000 次、晚上可能 50,000 次，一台機器不夠用，要自動開更多
- 容器當機了要自動重啟，不能讓服務中斷
- 更新模型版本時，要讓舊版繼續跑，新版慢慢接手（滾動更新）
這些「讓很多容器在很多機器上穩定協作」的工作，就是 Kubernetes 的工作。
沒有 Kubernetes 的時代，怎麼管模型服務
在 Kubernetes 出現前，工程師要自己扛起五件痛苦的事：
- 手動登入每台機器部署：有 10 台伺服器就要 SSH 登進去 10 次，一台一台啟動容器，超慢、超容易出錯。
- 自己寫腳本監控服務存活：容器掛掉，沒有人知道，要等使用者報錯才察覺，再手動重啟。
- 流量暴增時手動加機器：凌晨流量突然暴增，工程師要半夜爬起來手動開機器、部署容器、設定負載均衡。
- 更新模型版本超危險：舊版服務要先下線，新版部署好才能上線，中間有一段時間完全沒有服務（停機）。
- 資源浪費嚴重：為了應付流量高峰，平常都要留足夠多的機器待命，閒置時在燒錢。
Kubernetes 怎麼把這些都自動化
王俊把信用評分模型的容器交給 Kubernetes 管，只需要寫一份設定檔說明「我需要 3 個副本、流量超過 80% CPU 時自動擴展」。
Kubernetes 接手後：
- 自動部署：把容器分配到適合的機器上啟動，不用手動登入
- 自動重啟：某個容器掛了，幾秒內自動重啟一個新的，使用者完全不知道
- 自動擴縮（Autoscaling）：晚上查詢量暴增，Kubernetes 自動多開 10 個容器；流量退潮後自動縮回 3 個，節省費用
- 滾動更新（Rolling Update）：新模型版本部署時，先開幾個新版容器，確認沒問題後再逐步替換舊版，服務不中斷
- 負載均衡：把 App 進來的查詢請求，均勻分配給多個容器，不讓任何一個過載
這就是選項 B 講的：管理與協調模型服務的部署、擴展與運行環境。
技術版：Kubernetes 的核心概念與 AI 部署架構
本題沒有程式碼，但 Kubernetes 的背景知識在 MLOps 領域非常重要。
Kubernetes 的架構由幾個核心概念組成：
Pod：Kubernetes 的最小部署單位，一個 Pod 裡面有一個或多個容器。AI 模型服務通常每個 Pod 裡放一個模型推論容器。
Deployment：描述「我要幾個 Pod 副本、容器映像檔是哪個版本、更新策略是什麼」的設定物件。Kubernetes 會確保實際運行的 Pod 數量和 Deployment 設定一致。
Service：給外部流量一個固定的入口（IP 位址 + 連接埠），自動把請求轉發給後面的 Pod，實現負載均衡。
HPA（Horizontal Pod Autoscaler，水平 Pod 自動縮放器）：監控 CPU、記憶體或自訂指標（如每秒查詢數），根據規則自動增減 Pod 數量。
在 AI 推論服務的典型架構裡：
App / API Gateway
↓
Kubernetes Service（負載均衡）
↓ ↓ ↓
Pod 1 Pod 2 Pod 3 （各跑一個模型推論容器）
GPU or CPU GPU or CPU GPU or CPU
流量暴增 → HPA 自動新增 Pod 4, 5, 6
流量退潮 → HPA 自動縮回 Pod 1, 2, 3Kubernetes 本身不做：訓練（那是 Kubeflow / MLflow 的工作）、資料儲存（那是 MinIO / S3 的工作）、GPU 計算（那是 CUDA / NVIDIA 驅動的工作）。它做的是「讓這些東西的容器穩定地跑在一起」。
為什麼其他選項是錯的
A自動化管理模型的訓練流程與參數調校
說 Kubernetes 能幫你跑模型訓練、調整超參數（Hyperparameter），讓訓練流程自動化。
Kubernetes 是容器編排（container orchestration）工具，它管的是「讓容器跑起來並保持穩定」，不理解 AI 模型訓練的流程。管理訓練流程和超參數調校是 Kubeflow、MLflow、Weights & Biases 等 MLOps 工具的專職工作。Kubernetes 可以作為它們的底層基礎設施，但功能本身不是 Kubernetes 的。
聽過「Kubernetes 很萬能」但沒細究它具體做什麼的人。Kubernetes 不懂 AI，它只管容器的生死和分配，不管容器裡跑的是訓練還是推論。
C提供 AI 模型的資料儲存與版本控管功能
說 Kubernetes 能儲存訓練資料、管理模型的不同版本（v1.0、v2.0 等）。
資料儲存是物件儲存（S3、MinIO、GCS）或資料庫的工作。模型版本控管是 MLflow Model Registry、DVC、Weights & Biases 的工作。Kubernetes 本身的「儲存」只是掛載磁碟（Persistent Volume）讓容器能讀寫本地資料，不負責 AI 相關的版本管理邏輯。
把 Kubernetes 和整個 MLOps 平台混為一談的人。Kubernetes 是基礎設施層，在它上面才跑著各種 MLOps 工具，但功能要分清楚。
D負責深度學習推論的 GPU 加速運算
說 Kubernetes 本身負責用 GPU 做深度學習的計算加速。
GPU 計算是由 CUDA 驅動程式和 AI 框架（PyTorch、TensorFlow）負責的。Kubernetes 只是協調哪個 Pod 可以使用 GPU 資源，把 GPU 分配給對應的容器，但計算本身完全不是 Kubernetes 做的。這就像說「停車場負責開車」，停車場負責分配車位，不負責開車。
看到「AI 推論」就聯想到「GPU」，再聯想到「Kubernetes 管 GPU」的人。管理（分配資源）和執行（跑計算）是兩件事，Kubernetes 做前者。
同個考點下次怎麼變形
Kubernetes 和 Docker 的關係是什麼？
Docker 和 Kubernetes 都常常一起出現，是同一個東西嗎？
不同層次的工具。Docker 負責「建立和跑單個容器」，是製作容器的工具。Kubernetes 負責「管理很多容器在很多機器上如何協作」，是容器的調度系統。比喻：Docker 是一台車，Kubernetes 是城市的交通管理系統（紅綠燈、停車場、路線規劃）。實務上用 Docker 打包 AI 模型，再交給 Kubernetes 統一管理部署。
什麼情況下不需要 Kubernetes？
既然 Kubernetes 這麼強，是不是所有 AI 服務都要用？
小型服務或開發初期不需要。Kubernetes 本身有很高的學習曲線和維運成本（管理 cluster 本身就需要專業人員）。如果只是一個內部工具、每天只有幾百次查詢，用單台機器跑 Docker 容器就夠了。Kubernetes 的效益在於：多台機器、需要高可用性（不能停機）、流量波動大、需要自動擴縮的場景。
Kubeflow 和 Kubernetes 的關係是什麼？
Kubeflow 聽起來和 Kubernetes 很像，是進化版嗎？
Kubeflow 是跑在 Kubernetes 上面的 MLOps 平台，專門為機器學習工作流設計。Kubernetes 提供底層的容器調度能力，Kubeflow 在上面加了 AI 特有的功能：模型訓練 Pipeline 管理、超參數搜尋、模型服務（KServe）、實驗追蹤。選擇關係：Kubernetes 是基礎，Kubeflow 是 AI 專用的上層應用。
電商網站也在用 Kubernetes，和 AI 場景的用法有什麼差異？
Kubernetes 不是 AI 專用的工具，電商、金融都在用，AI 場景有什麼特別？
核心概念相同，但 AI 場景有幾個特殊需求。第一是 GPU 資源分配：一般 Web 服務用 CPU，AI 推論服務需要 GPU，Kubernetes 有 GPU 資源調度的設定（nvidia.com/gpu 資源請求）。第二是模型版本管理：需要和 Model Registry 整合，支援 A/B 測試（新舊模型各承接部分流量）。第三是大 Pod 啟動時間：AI 模型容器往往好幾 GB，啟動慢，需要針對性的健康檢查設定。
怎麼評估 Kubernetes 管理的 AI 服務是否健康？
服務上線後，怎麼知道 Kubernetes 管得好不好？
幾個關鍵監控指標。Pod 可用率（Available Pods / Desired Pods），應該接近 100%。服務回應時間（P50 / P95 / P99 latency），AI 推論服務通常目標是 P99 在 200ms 以內。自動擴縮觸發頻率，太頻繁代表資源規劃不足。容器重啟次數（CrashLoopBackOff），多代表程式碼或資源有問題。這些指標通常透過 Prometheus + Grafana 監控。
想再往下看，這 5 個
- 模型部署（Model Deployment）將訓練完成的模型上線為可查詢服務的過程，Kubernetes 是現代模型部署的核心容器編排工具，正解考點。
- 容器化技術（Containerization）把應用程式與依賴打包成可攜帶執行環境的技術，Kubernetes 管理的最小單位 Pod 即由容器組成。
- 機器學習維運（Machine Learning Operations）涵蓋模型訓練到生產的完整工程實踐，Kubernetes 是 MLOps 基礎設施層的核心，負責容器編排與擴縮。
- 自動擴展（Auto Scaling）Kubernetes 透過 HPA 根據流量自動增減 Pod 數量，是 AI 推論服務應對流量波動的關鍵能力。
- 模型服務化（Model Serving）讓訓練完的模型以 API 形式提供即時推論的工程實作，Kubernetes 確保模型服務穩定運行和負載均衡。