許多初學者或剛接觸雲端原生技術的工程師可能會好奇，既然現在有這麼多專為 AI 設計的平台，為什麼 Microsoft 仍致力於將 AI 工作負載搬到 Kubernetes (K8s) 上？簡單來說，AI 的開發週期正從單純的實驗轉向大規模生產。而 Kubernetes 提供的自動化擴展、資源管理與標準化部署，正是讓 AI 模型能穩定運行在企業級環境中的關鍵。
在 Microsoft Build 2026 中，Azure Kubernetes Service (AKS) 推出了一系列更新，核心目標是消除 K8s 在處理高效能 AI 運算時的效能損耗，並簡化大規模叢集的管理難度。
突破虛擬化瓶頸：AKS on Bare Metal
在傳統的雲端環境中，K8s 叢集通常運行在虛擬機 (VM) 之上。雖然虛擬化提供了極大的靈活性，但對於大語言模型 (LLM) 的訓練或低延遲的推論來說，虛擬化層 (Hypervisor) 會帶來額外的效能開銷。
為了追求極限效能，Microsoft 推出了 AKS on Bare Metal（裸機部署）。這意味著 K8s 直接安裝在物理伺服器上，讓容器能直接存取硬體。這樣做最重要的好處是能完整發揮 NVLink（NVIDIA 的高效能 GPU 互連技術）與 RDMA（遠端直接記憶體存取，允許電腦直接讀取另一台電腦的記憶體而無需經過 CPU）的威力。對於需要大量 GPU 協作的 AI 工作負載，這種直接存取硬體的能力能顯著降低延遲並提升運算效率。
簡化運維：系統節點池與輕量化作業系統
對於維運工程師來說，管理 K8s 最頭痛的是系統組件與應用程式搶資源。當 GPU 資源被 AI 模型佔滿時，如果 K8s 的核心管理組件（如 API Server 或 Scheduler）也運行在同一台機器上，可能會導致叢集不穩定。
針對此問題，AKS 引入了 Managed System Node Pools（受管系統節點池）。它將 K8s 的核心系統組件與使用者的應用程式工作負載在物理上分離。Azure 會自動處理系統節點的容量管理、補丁更新與擴展，讓工程師只需關注 AI 模型的運行，而不用擔心底層管理元件崩潰。
同時，Azure Container Linux 的推出則提供了一個極簡化的作業系統。它剔除了不必要的組件，減少了配置偏移 (Configuration Drift) 的風險，讓大規模部署時的維護變得更簡單且一致。
從單一叢集到艦隊管理：Fleet Manager
當企業的 AI 應用規模擴大，單一叢集已無法滿足需求，可能會在不同區域、不同雲端甚至地端 (On-premises) 部署數十個叢集。如果每個叢集都要單獨配置權限與政策，將會變成維運災難。
Azure Kubernetes Fleet Manager 為 Arc-enabled clusters（透過 Azure Arc 連結的叢集）提供了集中化管理。它將視角從單個叢集提升到艦隊 (Fleet) 層級，讓管理員能一次性地在所有叢集執行政策強制執行、工作負載放置以及分階段滾動更新。這將 K8s 的管理邏輯從個體操作轉向了平台化治理。
AI 運算編排：Ray 與 KAITO
除了底層硬體，如何有效地在 K8s 上跑 AI 模型也是重點。Microsoft 整合了 Anyscale on Azure，將 Ray（一個開源的分散式運算框架，專門解決 Python 在大規模叢集上的擴展問題）變成受管服務。這讓工程師能輕鬆地在 K8s 上調度 CPU 與 GPU 資源，而不需要自行搭建複雜的 Ray 叢集。
而在部署端，AI Runway 框架搭配 KAITO (Kubernetes AI Toolchain Operator) 簡化了模型上線流程。KAITO 扮演的是自動化操作員的角色，它能根據需求自動配置資源，並啟動如 vLLM（高效能 LLM 推論引擎）等優化運行時，同時整合 KEDA（基於事件的自動擴展）來處理流量波動。
總結與實務觀點
Microsoft 的策略非常明確：他們不打算建立一套封閉的 AI 基礎設施，而是選擇將開源標準（如 Kubernetes, Ray, Gateway API）封裝成企業級的受管服務。
對於工程師而言，這意味著 AI 基礎設施的趨勢將與過去十年的雲端原生發展相似。比起依賴某個特定廠商的私有工具，掌握 K8s 及其生態系將成為部署 AI 應用的通用語言。目前的挑戰已不再是 AI 能不能跑在 K8s 上，而是在確保效能、控制成本與維持可擴展性之間取得最佳平衡。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。