原文標題：From Working Group to SIG Architecture: spotlight on AI Conformance
Kubernetes 官方部落格 10 月 29 日訪談 AI Conformance 專案參與者，說明這項計畫從 CNCF 專案、工作小組到 SIG Architecture 常設子專案的演變。隨著分散式訓練、GPU 密集型管線、推論服務與代理系統越來越常部署於 Kubernetes，不同供應商在硬體、網路與排程上的實作差異，也造成可攜性及供應商鎖定疑慮。
社群先透過工作小組定義 Kubernetes AI Requirements（KARs）與 Certified Kubernetes AI Conformance Program，並建立自動化測試路線圖。官方指出，認證平台數在數個月內由 18 增至 31，代表市場開始採納共通的 AI 基礎設施驗證標準。
工作小組達成初步目標後，AI Conformance 已轉入 SIG Architecture 子專案，由長期治理機制持續維護要求。其標準設計採分級方式：新興能力先以 SHOULD 建議項目試行，待 API 穩定且社群採用成熟後，再考慮升級為 MUST 必要條件。
專案重點放在基礎設施能力，例如 Dynamic Resource Allocation（DRA）等加速器支援，而非綁定特定 AI 模型伺服器或框架。社群邀請平台供應商參與認證，開發者可透過專案儲存庫、KAR 範本與 Go 自動化測試共同維護規範。
發生了什麼事
Kubernetes 官方部落格 10 月 29 日訪談 AI Conformance 專案參與者，說明這項計畫從 CNCF 專案、工作小組到 SIG Architecture 常設子專案的演變。隨著分散式訓練、GPU 密集型管線、推論服務與代理系統越來越常部署於 Kubernetes，不同供應商在硬體、網路與排程上的實作差異，也造成可攜性及供應商鎖定疑慮。
為什麼重要
常設治理可降低不同 Kubernetes AI 平台之間的行為差異，協助企業在雲端、地端與邊緣環境部署可攜的工作負載。
影響哪些人
平台工程師、GPU 叢集維運人員、AI 平台供應商及採購團隊，可將一致性認證作為相容性評估的一項依據。
已確認與未確認
已確認轉入 SIG Architecture 與認證數成長；並非所有新 AI 功能都已成為 Kubernetes 核心 API 或強制認證要求。
