【專訪Istio關鍵人物：Nutanix雲原生副總裁暨總經理Dan Ciruli】從大規模微服務實踐，看AI原生代理的新挑戰

在新的AI原生時代，最大的課題就是如何更優化大規模AI代理的運作。CNCF借鏡了不少原有的K8s和容器技術的發展方式，套用到AI工作負載上，要來支援大規模AI部署的需求。甚至CNCF技術長Chris Aniszczyk直接將AI代理比喻為新型態的微服務，他認為，要在正式環境中大規模執行AI代理，可以參照過去在正式環境中執行大規模微服務的做法，不只要能支援開發、執行，還要能管理、擴充、觀察和保護這些AI代理，可以將CNCF生態系的成果，應用到AI代理的場景中。

Nutanix雲原生副總裁暨總經理Dan Ciruli，他曾在Google擔任Service Mesh產品管理團隊的負責人，參與Istio專案和Anthos Service Mesh，也是Google在Istio指導委員會的代表之一。

Istio專案是用來在K8s上執行大規模微服務的服務網格重要開源專案，Dan Ciruli相當熟悉企業如何運作大規模微服務的挑戰和實踐。

AI工作負載帶來兩大新挑戰

Dan Ciruli認為，AI工作負載是一種專門的工作負載，與現有常見的IT工作負載，有幾點不同。

在技術層面的第一個不同是，調度排程（Scheduling）方式需要改變。調度器是Kubernetes環境的運作核心，為了調度AI工作負載，調度器需要具備GPU感知能力，更進一步，共享GPU的方式與共享CPU的方式也有所不同，如Nutanix團隊也正在研發新的調度機制。

第二個技術面的差異是儲存需求的改變，轉變成更需要資料庫的存取。Dan Ciruli解釋，AI工作負載中，模型訓練和推論過程有其各自有不同的存取效能需求，也對儲存系統的存取方式帶來重大影響。調度排程與儲存存取方式，是AI工作負載的兩大新課題。

不過，他直言，五年後，大家可能不會再使用「AI工作負載」這個詞，而是直接稱為「工作負載」，因為AI工作負載將成為最普遍的工作負載型態。五年後的晶片運算能力，不論是CPU、GPU或是DPU都將會大幅提升，實際採用哪一類晶片可能不再是重點，調度器要有能力確保各種工作負載，可以放到適合的硬體支援環境中執行，包括儲存與運算的硬體資源。

面對超大規模（Hyperscale）的AI推論挑戰，例如NVIDIA試圖將推論過程拆解，針對記憶體密集和運算密集的處理過程，各有不同的優化做法，來以提高整體的推論效率，但是，Dan Ciruli認為，大多數企業，目前都沒有達到類似OpenAI的超大規模AI運算規模，需要特別將KeyValue快取完全拆分來優化。

根據Nutanix對1,500名企業基礎設施人員的調查，大多數企業預計執行的AI應用數量，目前仍在個位數或雙位數，10到20套AI應用的規模。所以，以Nutanix的策略來說，會先專注於大型企業而非擁有數萬個AI代理的超大規模應用者。「超大規模的需求，在目前的企業中仍是極少數。」

因為企業普遍的AI運算需求規模還不高，Nutanix目前對於超大規模運算的發展策略，也有所不同。「我們的目標是，確保基礎設施具備未來相容性（Future Compatible）」，他解釋，無論是執行幾十個AI代理，或是幾千個代理，從底層的虛擬化、容器管理到儲存，都可以支援技術的演進。

從巨觀的整體運作架構，進一步聚焦到AI工作流程的差異，Dan Ciruli認為，AI代理的運作概念，類似雲原生的微服務，但AI代理的觸發模式，更偏向是事件驅動模式，而非像微服務直接靠API來調用。原本用來監測大規模微服務運作的可觀察性做法和分散式追蹤工具，都需要演化，來適應AI代理間的交互作用模式。

不只如此，Dan Ciruli認為，AI代理伴隨的新技術，如MCP協定，將會促使治理系統快速演進，原有發展多年的API治理，同樣可以套用到AI代理的治理，同樣需要建立標準，找出最佳實踐，來因應越來越強的AI代理和越來越複雜的管理挑戰。

AI SRE角色的出現，將雲端SRE帶入AI基礎架構

他觀察，業界也出現了「AI SRE」的新角色，將雲端SRE帶到AI基礎架構的環境中，基礎架構維運團隊也要能善用AI來協助底層的維運。

AI SRE思維的出現，反映出傳統SRE的實踐做法，無法解決AI系統的可靠性挑戰。不同於傳統微服務慣用的API呼叫，AI應用像是一條充滿機率的推理鏈，從輸入提示、RAG檢索、模型推理、工具與Agent互動，最後到透過防護柵欄和過濾器處理，再提供給使用者，並且要獲得使用者的回饋，持續迭代和調整AI應用。

每一個階段可能都回傳了服務健康的狀態資訊，但是Token成本卻暴增3倍，使用者等待回應時間延長了40%，傳統的SRE監控，很難察覺到底是服務中斷，還是AI模型還在處理中。

例如Nutanix正在開發一款提供AI代理可視性的SRE工具，可以提供流量可視化與存取控制。「目標是讓企業像管理API一樣的管理AI代理，從認證、授權到資源分配的管理。」但是他提醒：「AI時代的資源分配，不只是每秒的請求數，還包括了要考慮Token數量的分配。」

研發大規模微服務運作的服務網格技術多年，Dan Ciruli認為，AI Gateway與API Gateway 的核心區別是對Token用量的監控。

透過雲端環境存取AI，雖然資源無限，但極其昂貴。在大規模AI代理需求下，在地端環境運作AI會更有優勢，企業可以不用擔心Token成本，而是轉向關注 GPU的效率、閒置或是超載的問題，變成了固定成本的維運模式。AI代理所需要的可觀察性原則，也可與過去在Istio專案中的做法類似，同樣都要從整體的服務健康出發，如指標、日誌、追蹤，而非只靠少數單一監控指標。

雖然在今年亞特蘭大舉辦的KubeCon北美大會中，充滿了各式各樣的AI討論，但Dan Ciruli指出，現實中，企業90%新增的工作負載需求，大多與AI 相關。目前可以看到的是，AI推論的需求，帶動了零售業與製造業對於邊緣計算的需求，例如這些企業需要用AI來進行影像視覺分析。大多數企業採取的是混合雲模式，多數 Kubernetes叢集都部署在虛擬機器中執行，需要有一套統一的叢集管理工具，像Nutanix就開發了可以支援容器與虛擬機器之間網路傳輸的安全路由技術。

「從安全角度來看，AI代理的存取控制將變得更加複雜。」AI Gateway需要有能力提供基於角色的存取控制（RBAC）與Token用量的管理。Dan Ciruli也看好業界對AI代理賦予「數位身份」的趨勢，從他過去在Google看到的做法是，將人類與機器都用同一套命名空間來管理身分，可以提供強大且一致的權限管理。

建議企業建立平臺工程團隊，統一管理AI基礎架構

對企業來說，他認為，AI基礎架構集中管理將會非常重要。不同團隊各自用不同的方式工作，短期可能跑得很快，但也容易發生問題，更有可能發生資安事件，也容易造成效率低落。他認為，更聰明的做法是，借鏡雲端管理的完善治理做法，也在導入AI時建立良好的治理機制。

就像DevOps管理Kubernetes的發展歷程，一開始由開發人員各自維運自己的Kubernetes叢集，後來演變成了平臺工程（Platform Engineering）。Dan Ciruli表示，在平臺工程模式下，透過一個集中化的團隊來負責Kubernetes，負責將內部各種Kubernetes 的使用方式標準化。可以讓企業更有效率、也更安全地運作，不再是靠不同開發人員，各自做出不同決策，而是有一套正確且一致的做法。

Dan Ciruli認為，當企業開始在應用程式中導入AI，未來也會走向類似從DevOps到平臺工程的發展路徑，同樣需要一個集中式的團隊，來管理AI基礎架構與服務。