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

如果Kubernetes 可以增加 Pod，但誰來增加 GPU？

Day 21 我談到 AI Service 流量增加時，可以透過 Autoscaling 增加 Pod。

但繼續往下想，我發現一個很現實的問題：

如果 Pod 已經增加了，卻沒有足夠的 GPU Node，它到底要跑在哪裡？

這也是我開始理解 Kubernetes AI Infrastructure 後，覺得很有意思的一個地方。

假設原本只有一個 GPU Node，AI Service 突然需要更多 Replica，HPA 可以要求 Kubernetes 增加 Pod；但如果現有 Node 已經沒有足夠的 GPU 資源，新的 Pod 就可能沒有地方可以執行。不是 HPA 加幾個 Pod 就結束。

這時候就不能只考慮 Pod Scaling，而必須進一步處理 Node Scaling。

Kubernetes 官方目前的 Node Autoscaling 文件說明，當 Pod 因為現有 Node 沒有足夠容量而無法被排程時，Node Autoscaler 可以新增 Node 來提供所需容量。

而在 GKE 中，Cluster Autoscaler 會根據 Pod 的 Resource Requests 判斷是否需要增加 Node；對 GPU Workload 而言，還需要考慮 GPU 資源與相關限制。Google Cloud 目前也特別提醒，啟用 GPU Cluster Autoscaling 時，GPU Quota 必須足以支撐可能擴展到的最大 GPU 數量。

這讓我開始理解：

AI Autoscaling 其實不是單純增加 Pod，而是一整條從 Application 到 Infrastructure 的 Scaling Chain。

所以問題來了：

**如果 HPA 想增加 AI Pod，但 Cloud 裡沒有足夠的 GPU、Quota 或可用容量，這個 AI Service 到底會發生什麼？**Pod 到底會去哪裡？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我想從 Kubernetes 一路看到 Cloud Infrastructure 的原因。從 Kubernetes 與 GPU Workload 的實作與學習中，我開始發現「Pod 能不能增加」和「底層是否真的有 GPU 資源可以執行」是兩個不同問題。AI Service 要真正擴展，至少要思考問題，就像寫agent遇到安全問題，是否授權邊界分析或授權驗證或證據驗證，有確定驗收標準，或是那個環節？沙盒有問題？資安的那個階段？AI不是魔法，Kubernetes也不是萬靈藥，修正授權合約或許就像買新硬體GPU？！

關於作者

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