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

如果AI 自動擴展很好，但 GPU 帳單誰來付？

Day 22 我談到，HPA 可以增加 AI Pod，但如果沒有足夠的 GPU Node，還需要進一步擴展底層 Infrastructure。

這時候我開始想到另一個問題：

如果系統可以自動增加 GPU，那是不是代表我們只要把 Autoscaling 打開就好了？

答案顯然沒有這麼簡單。

因為對一般 Web Application 來說，多增加幾個 CPU Instance 已經需要考慮成本；但 AI Inference 使用 GPU 時，單一 Node 的資源成本通常更高。如果流量突然增加，系統自動增加 GPU Node，確實可以維持服務，但如果流量下降後沒有適當縮容，閒置的 GPU 資源就可能變成持續產生的成本。

我自己開始從 AI Infrastructure 的角度思考後，慢慢發現：Production 的目標不是「永遠擁有最多資源」，而是在效能、可用性與成本之間找到合理的平衡。

Kubernetes 官方目前也把 Node Autoscaling 的目的描述為在滿足 workload 所需容量的同時，透過 Node provisioning 與 consolidation 優化成本。即「滿足 workload 需求，同時最佳化成本」

Google Cloud 目前針對 AI/ML accelerator 也把成本與效能列為選擇 GPU/TPU 資源時的重要考量，並提供 Spot、Flex-start 等不同的資源取得方式來因應不同 workload。Google Cloud 對 GPU AI/ML workload 也特別強調要在成本、效能與 GPU 資源利用率之間取平衡。

這讓我開始重新思考 AI Scaling：

**真正成熟的 Autoscaling，不只是讓服務在流量增加時「撐得住」，還要在流量下降時「不要繼續浪費錢」。**Autoscaling 的目的不是「永遠有足夠資源」，而是在效能、可用性與成本之間取得平衡。

所以問題來了：

**如果 AI Service 可以自動增加昂貴的 GPU 資源，我們到底應該用什麼方式決定「效能值得花多少錢」？**那什麼時候該擴、什麼時候該縮？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我開始從 Infrastructure 延伸到 Cost Optimization 的原因。從 AI Infrastructure、GPU 與 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的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~