【不只建造，更要部署、維運和管理成千上萬AI代理】十年雲原生浪潮的下一階段，AI原生時代的崛起

「人工智慧正處於起步階段，類似雲原生的發展模式，從封閉選擇、單一供應商壟斷，正邁向更開放的選擇，技術競爭也將更加激烈！」CNCF組織技術長Chris Aniszczyk去年秋天來臺參加國泰金控技術年會時，揭露了他AI技術發展模式的觀察。

生成式AI在去年掀起了新的AI代理技術浪潮，技術巨頭和科技大廠，紛紛推出了自己的AI代理工具鏈，各行各業都開始嘗試打造AI代理應用。根據微軟去年第三季的統計，23萬家採用Copilot Studio的企業，就建立了超過1百萬個AI代理。IDC去年5月時預測，再過2年，2028年時，全世界將擁有13億個AI代理，來支援各種工作場景。AWS執行長Matt Garman在去年底年度大會開場時更直言，我們準備邁向一個數十億AI代理的新世界。」

這個十億等級AI代理的世界，可以說是有10億隻AI代理程式的運作、維運需求，這是科技巨頭們所瞄準的新IT需求規模。新的挑戰已經不是如何打造一支AI代理，而是如何部署、維運、管理成千上萬，甚至是數十萬隻AI代理的IT架構。

Adobe平臺工程負責人Joseph Sandoval在KubeCon主題演講中更直言，大規模AI代理，如何進入正式環境運作是當前的課題，業界不只希望雲原生基礎環境只是有能力執行AI工作負載，而要更進一步優化。「我們正在見證雲原生的下一個新階段，AI原生時代的崛起。」圖片來源／CNCF

雲原生技術正在轉型，KubeCon成AI創新舞臺

但是，GenAI工作負載所需的IT基礎架構，和雲原生基礎架構截然不同。現在所有的AI工作負載，全部都部署在雲原生主力技術Kubernetes環境中執行，新型態的AI工作負載，也掀起了雲原生技術的轉型，尤其是Kubernetes工具生態系，在去年底KubeCon 2025大會中就可見一斑。

KubeCon是雲原生生態系最重要的技術大會，也是CNCF最重要的技術和專案進展發表場合。從2017年的KubeCon大會開始，「無聊」成了後續每一年大會的特色，因為K8s進入企業成熟應用的階段成了，所有擁抱雲原生的企業，沒有一家不採用K8s。如何更可靠，更安全，沒有出人意料的「穩定」，成了KubeCon每年年會的特色。業界都看好KubeCon的無聊，也代表了這類技術真的走入了企業。

這股無聊感一直持續到2025年，去年底在美國亞特蘭大舉辦的北美場KubeCon的氛圍，完全顛覆了過去「無聊」的形象，搖身一變，成了IT圈最夯、最潮的AI技術創新大會。

去年這場KubeCon，超過9千人參加，慶祝CNCF十週年之際，討論的話題卻都環繞著各種AI代理的議題。代理式工作流程（Agentic Workflow）、MCP協定、A2A協定的名詞，成了Kubecon的熱門關鍵字，到處都聽得到。如何將AI技術落地到企業，成了當前的重點。

產業分析機構Forrester首席分析師Brent Ellis也觀察到今年KubeCon充滿了創新感，雲原生社群正努力將原本為了支援鬆散耦合微服務架構的K8s，轉變成可以適合大規模、緊密耦合型態的AI工作負載。

Brent Ellis提出了幾項值得注意的變化，AI原生工作負載成為焦點。K8s已經成為AI服務的底層架構，如何動態分配GPU的調度，來因應AI推理的資源分配，來改善成本效益和效能的關鍵。

其次，與開發者體驗高度相關的平臺工程，將越來越重要，因為平臺團隊不只是為了提高開發人員的開發速度，現在還要管理企業資源，在開發速度、治理、合規要求和成本優化之間取得平衡。

幾項新興技術也更加成熟，例如eBPF不斷擴大應用範圍，eBPF開源專案Cilium對叢集的傳輸連線監控、runtime安全性和擴充性都有增強。在這場大會的產品示會場中，到處都可以看到可觀察性的解決方案，像是Grafana Labs推出了AI追蹤助手，可以用自然語言來描述想要追蹤的需求。

問世多年的WASM技術則持續成熟，不用瀏覽器也能執行WASM的WASI終於釋出0.3版，有更多新創投入WASM工具研發。新興的政策即程式碼工具開始進入市場，Kyverno新增通用的表達式語言CEL來描述政策，Open Policy Agent Gatekeeper則增加了驗證後准入的整合，也強化了審計功能。

AI應用的可觀察性挑戰也是今年KubeCon的熱門話題，業界也開始出現AI SRE的概念，來探討AI應用的長期維運挑戰，試圖將雲原生浪潮而崛起的將雲端SRE實踐，帶到AI基礎架構的環境中，基礎架構維運團隊興起了一股善用AI維運的討論。

過去一年來，已有企業開始感受到既有維運方式的侷限，SRE像ING集團SRE團隊負責人Ehsan就認為，傳統SRE實踐做法，無法解決AI系統的可靠性挑戰，需要新的SRE思維。不同於傳統微服務慣用的API呼叫，AI應用像是一條充滿機率的推理鏈，從輸入提示、RAG檢索、模型推理、工具與Agent互動，最後到透過防護柵欄和過濾器處理，再提供給使用者，並且要獲得使用者的回饋，持續迭代和調整AI應用。

AI應用的可靠性挑戰，包括了從服務上線到結果生成之間的可靠性、正確性、真實性和有效性，還要考慮安全的AI代理操作行為，而當模型發生語意、資料、檢索、調度的錯誤時，傳統的可觀測性工具很難偵測，甚至模型會有飄移的情況，而且是持續出現，默默地發生，讓維運監控的難度更高。為了提高RAG檢索結果的新鮮度和廣度，也付出一定的代價，包括了資料搜集成本，API成本，向量資料庫儲存成本等。

SRE的目標，從過去的網站可用性和擴充性，延伸到語意真實性、安全政策遵循、Token數和GPU成本的經濟效益，行為變化的控制等。這些都挑戰了現有的SRE和可觀察性工具生態系。

巨大的挑戰，也意味著巨大的機會。Linux基金會雲端與基礎設施執行董事Jonathan Bryce在開場演講中指出，全球已經有1,560萬名雲原生開發人員，其中一半的人從事AI開發，創造AI或是在AI系統中工作。「如何將K8s和雲原生各項經驗，延伸到AI推理領域，是K8s生態圈的巨大機會。」

早在2015年就擔任CNCF技術長的Chris Aniszczyk，一路看到整個雲原生生態系的發展，他也是CNCF知名的雲原生生態系全景圖（Cloud Native Landscape）的維護者之一。

在這張全景圖中，涵蓋了1千個雲原生元件，包括200個CNCF的開源專案，去年更增加了一個新的分類「CNAI」，列出了超過90個，與原生AI（Cloud Native AI）相關的開源專案。

CNCF將這些雲端原生AI專案，細分為13類專案，包括了資料架構類專案，資料科學類專案，向量資料庫、  通用調度用專案、代理式AI、治理政策和資安類專案、ML服務提供(serving)類、CI/CD類專案、分散訓練類專案、AutoML類專案等10類，再加上可觀察性則細分成Model/llm可觀察性專案和AI工作負載可觀察性，以及一項比較特別的開源企業AI藍圖，共13類。從這些類別也可以看到，CNCF組織所勾勒的AI原生基礎架構的結構。

進一步來看其中的一些重要開源專案，例如Kubernetes、雲元生批次處裡Volcano、開源跨雲跨多叢集調度專案Karmada都是通用調度類CNCF專案。而在資料架構類專案，則有知名的大數據串流平臺Fluid、Spark、大數據生態系Hadoop、 分散式K8S的MLops專案Kubeflow、 NoSQL資料庫Cassandra、記憶體式資料庫Redis等。而在資料科學類專案則有TensorFlow、PyTorch、Jupyter。向量資料庫則有Mivus、Chroma、通吃向量和結構化資料的Ｗeaviate。

Model/llm可觀察性專案較知名的有LLM工程平臺專案Langfuse，常見的Grafana、Prometheus就屬於AI工作負載可觀察性專案。代理式AI類，則有AI代理的devops框架Kagent，這是2025年1月才誕生的新專案。

在治理、政策和資安類專案上，主要有開源身分管理KeyCloak，發展超過5年的政策管理用Kyverno等。ML服務提供(serving)類則有一個，Google愛用的推論專案vLLM，這也是他們大規模運用TPU來降低AI推論成本的關鍵專案。

另外有一類比較特別的開源企業AI藍圖，只有一個開源專案OPEA，這是Linux基金會旗下LF AI & Data Foundation（AI和數據基金會）接手的新專案Open Platform for Enterprise AI（OPEA），主要貢獻者是intel。

這個專案提供了一套企業期的RAG（檢索增強生成）架構的框架。想要建立一個開源、標準化、模組化及支援異質環境的RAG運作流程。尤其OPEA專案特別重視標準化，想要建立RAG架構需要的多項標準，例如可性度、企業就緒框架、架構藍圖、參考解決方案、效能展示等。

回顧雲原生技術的過去，來看AI技術生態的未來

Chris Aniszczyk認為，從雲原生技術生態的發展，可以看到AI技術生態的發展。「要真正理解未來，必須回顧過去，看看我們是如何走到今天。」

Kubernetes在2014年開源，CNCF也在同一年成立，至今全球有800家企業是CNCF成員，包括大型公雲巨頭，或是像Apple、Intel等大型科技公司，貢獻程式碼的開發者超過27萬人，參與企業超過8千家，大家共同來打造雲原生的各項基礎設施。

過去20年以來，IT工作負載從大型主機時代的單一供應商、單租戶應用類型，進入了開放的多元雲端、多種架構和各種供應商的多元生態系，「這是我們今天的運作方式，也會是未來的樣貌，我們將繼續朝這個方向邁進，特別是在人工智慧（AI）領域。」Chris Aniszczyk說。

CNCF生態系從2016年開始擴張，2017年致力於容器技術的標準化，像是ContainerD、容器引擎Rocket也納入CNCF，在正式生產環境中建構和執行容器的方式開始統一，這一步也帶來更多改變，開始引起大型科技業者的加入和支援。

無伺服器技術在2018年崛起，出現許多創新，如Amazon開源了Lambda所用的微型VM專案Firecracker，Google也將無伺服器專案Knative捐給了CNCF。為了因應大規模容器或無伺服器應用的管理，2019年，許多可觀察性工具和技術開始標準化，誕生了OpenTelemetry專案，大多數監控、可觀察性供應商都可以符合這個新標準，以便互通監控數據。

越過了COVID爆發的低調2020年，雲原生架構的底層開始現代化，Linux核心出現了eBPF技術，開始滲透到所有的CNCF專案，各種可觀察性專案或安全專案，可以透過eBPF技術與Linux核心互動，來改善容器的安全性和可觀測性。

早在2015年就擔任CNCF技術長的Chris Aniszczyk，一路看到整個雲原生生態系的發展，他也是CNCF知名的雲原生生態系全景圖（Cloud Native Landscape）的維護者之一。

在這張雲原生全景圖中，涵蓋了1千個雲原生元件，包括200個CNCF的開源專案，去年更增加了一個新的分類「CNAI」，列出了超過90個與原生AI（Cloud Native AI）相關的開源專案。圖片來源／CNCF

AI基礎設施開始成為雲原生領域的焦點

到了2023年，Chris Aniszczyk指出，雲端原生領域中的「AI 基礎設施」開始出現。

舉例來說，源自Google，用來建構和訓練LLM模型的開源專案Kubeflow，就在2023年納入了CNCF組織旗下，這個專案可以讓資料科學家在Kubernetes環境中，更容易使用慣用的Notebooks等工具。「這是CNCF真正開始關注AI基礎設施的第一年。」Chris Aniszczyk指出，就連 OpenAI早在ChatGPT問世之前，就開始運用K8s環境來部署AI基礎設施。

也是從2023這一年開始，許多AI支援需求，湧入了種種CNCF開源專案。例如，能不能強化GPU支援，這是需求強的一項。隨即，Kubernetes在1.33版，新增了一項動態資源分配（DRA）功能，可以在Kubernetes環境中，實現GPU、TPU 和各種硬體資源的抽象化，讓AI應用更容易調度和使用到GPU、TPU這類硬體的資源。這項功能已在2025年中發布的1.34版成為正式版功能。

許多雲原生專案也在同一年，開始支援新興的AI工作負載需求，像是OpenTelemetry專案、服務網格專案（Service Mesh）開始支援模型執行時的不同路由方法。「K8s對AI工作負載的優化，更是出現了大量創新。」Chris Aniszczyk回顧。

2023年這股新興浪潮，也讓CNCF組織開始思考，因應AI工作負載的雲原生架構會是什麼樣的架構，他們組了一個工作小組來研究。

CNCF雲原生AI白皮書出爐

隔年，2024年，CNCF提出了雲原生AI（Cloud Native AI）白皮書，提出了一個新的雲原生IT生態圈，涵蓋了傳統分析式AI和新興生成式AI的這份白皮書也正式宣告了，AI工作負載成了CNCF關注的焦點。CNCF定義的雲原生AI，涵蓋了支援AI工作負載所需的部署、執行、規模化的各樣技術和系統，可以用來支援資料科學家、開發人員、部署人員等不同角色，在雲原生環境的AI工作負載上，進行開發，部署，執行，擴充和監控。AI工作負載的調度，也比原本容器應用或是虛擬化應用的調度需求，更加複雜，需要更多不同的工具或機制來支援。

CNCF在白皮書提到，GenAI工作負載的特色是，算力需求很大，甚至需要特定硬體如GPU、TPU的支援。各種大型語言模型，動輒百億、千億等級的參數量，所處理的資料量很大，而非常多元和多樣化。在模型訓練和微調階段的運算需求相當複雜，需要不斷迭代來執行特定的密集式運算，而非雲原生常見的分散式運算處理。

也因此，GenAI工作負載的執行，需要規模化又兼具彈性的IT基礎架構，也需要有一套高效能，大頻寬高吞吐能力的儲存系統，而且能支援不同資料類型的儲存和低延遲存取需求。一款LLM模型，訓練微調和推論應用時的運算需求，更是截然不同，前者需要低延遲的巨資料傳輸能力，後者，在推論階段則是需求高度分散，容易擴充規模的執行能力。

不過，Kubernetes專案創立之初，是為了容器、CPU管理和儲存而設計的技術。但是AI技術的革命來自GPU、TPU、FPGA等晶片的驅動。「Kubernetes必須改良來支援這些場景，許多專案現在朝這個方向努力。」Chris Aniszczyk表示。

例如Kubernetes不只將DRA列為正式功能，還新增了In-Place Pod Resizing功能，免重開機，就能調整Pod叢集的大小，對AI/ML訓練帶來很大的幫助，這項功能也很快在半年後的1.35版成為正式功能，需求可見一斑。

例如，Nvidia也意識到AI工作負載排程的需求，和傳統雲原生容器工作負載的特性，截然不同，他們發起了一項排程工具KAI專案，可以支援整批Pod的調度，可以支援到1萬顆GPU規模的叢集，在單一叢集中優化不同類型AI任務的資源分配。

在2025年的北美KubeCon大會中，CNCF更宣布了一項 Kubernetes AI合規計畫（Kubernetes AI Conformance Program），想要建立一套AI基礎架構的統一標準。

2024年，CNCF發表了一份雲原生AI（Cloud Native AI）白皮書，提出了一個新的雲原生IT生態圈，涵蓋了傳統分析式AI和新興生成式AI的這份白皮書也正式宣告了，AI工作負載成了CNCF關注的焦點。圖片來源／CNCF

CNCF想要建立AI基礎架構的統一標準

這項計畫要簡化K8s上的AI運作方式，來確保AI工作負載可以在不同的K8s環境中有可移植性和互通性。這項計畫定義了一個AI合規環境，在加速器、網路、安全、調度、觀測性和算子上的最低支援要求。

就像在K8s也有一套認證軟體合規計畫，已有上百家廠商支援，確保他們的產品，都能提供標準化的K8s運作方式。這項標準化的做法，加速推動了企業擁抱雲原生技術的普及度。CNCF希望仿效同樣的做法，透過Kubernetes AI合規計畫，建立一套標準化的AI工具生態系，來加速整個AI應用產業的發展。

一款平臺成為「Kubernetes AI合規」意味著，這個平臺須在幾個核心領域提供支持。例如加速器、網路、安全、調度、觀測性和算子（Operators），依但都符合要求，這個平臺就可以獲得 Kubernetes AI合規的稱號。這代表企業可以在這些平臺上可靠地運行AI。

這項計畫採取自評、審查和完成產品測試的三階段做法，目前針對三大類AI應用場景來評測，包括了超大規模訓練和微調，高效能推論，以及MLOps流程。

在超大規模訓練和微調場景上，平臺要有能力取用高效能加速器的資源（例如GPU），高吞吐量和的拓樸感知能力的網路，分組排程（Gang Scheduling）和大規模存取資料的能力。而在高效能推論場景的設定上，同樣要能存取進階加速晶片、進階流量管理、具有標準化的監控矩陣等，MLOps流程場景則要有可靠的批次任務系統、資源管理的佇列系統、各種服務或資源的安全存取機制、可靠的CRD和算子支援。

合規項目中細分為8類，其中有9項必備要求(Must），23項最好具備(Should)，CNCF也名列了每一項可能的測試方式。廠商或平臺業者要申請通過Kubernetes AI合規計畫的認證，得先取得Kubernetes合規的認證，CNCF基金會已經要求想要申請Kubernetes AI合規計畫的廠商，要在2026年KubeCon大會前送出自評表，才能列入審查。

Kubernetes AI合規計畫的這些合規項目，可以說將是一套未來的AI通用規格和架構，不只用於合規申請，也可以作為AI供應商設計產品的參考，更可以提供企業參考，用來規畫自家所用AI技術架構的完整性和未來發展。

不只是建立AI基礎架構的標準，CNCF也正在發展AI模型的封裝技術，利用標準化的OCI映像檔和註冊服務，將AI模型封裝，方便分派和交付，也能和既有的容器安全工具整合，來提高AI應用的安全性。

CNCF借鏡了不少原有的K8s和容器技術的發展方式，套用到AI工作負載上，要來支援大規模AI部署的需求。Chris Aniszczyk用一個更簡單的比喻：「AI代理就是新型態的微服務！」要在正式環境中大規模執行AI代理，可以像過去在正式環境中執行大規模微服務的做法，不只要執行，還要管理、觀察和保護這些AI代理，現在有許多新專案，將有CNCF生態系的成果，應用到AI代理的場景中。「CNCF明年的目標是，讓AI更加擁抱雲原生。」

Adobe平臺工程負責人Joseph Sandoval在主題演講中更直言，大規模AI代理，如何進入正式環境運作是當前的課題，尤其要運用MCP協定，與不同系統，資源的大規模互動， 帶來了很多挑戰，像是複雜資源排程、可觀測性設計、信任機制等，業界不只希望雲原生基礎環境只是有能力執行AI工作負載，而要更進一步優化。

「我們正在見證雲原生的下一個新階段，AI原生時代的崛起。」Joseph Sandoval用這句話點明了「AI原生」浪潮的崛起。