从工作组到SIG Architecture：聚焦AI Conformance
内容提要
Kubernetes AI Conformance项目由CNCF发起，旨在解决AI工作负载在Kubernetes上运行的生态碎片化问题，统一GPU、网络、调度和推理等基础设施标准。完成初始目标后，该项目转为SIG Architecture下的常设子项目，持续维护厂商中立标准。项目采用分级毕业模型，新能力先作为推荐要求引入，成熟后转为强制要求，并聚焦基础设施层而非具体AI框架。认证平台已从18个增至31个。
延伸解读
从临时工作组到常设治理：AI Conformance 的制度化信号
AI Conformance 从临时工作组转为 SIG Architecture 下的常设子项目，说明社区认为 AI 工作负载已不是一次性议题，而是需要长期架构治理的核心场景。由于 SIG Architecture 本身负责 Kubernetes 整体一致性与 API 设计原则，将 AI Conformance 放在此处，可使其要求与现有生态长期对齐，避免成为游离于主架构之外的附加层。
分级毕业模型如何平衡 AI 速度与 Kubernetes 稳定性
面对 AI 基础设施快速演进与 Kubernetes API 追求稳定的矛盾，项目采用分级毕业模型：新能力先以推荐要求引入，给生态留出实验和形成共识的空间；待 API 稳定并被广泛采用后，再转为强制要求。同时，项目刻意聚焦基础设施层，例如通过 DRA 测试加速器支持，而不绑定具体 AI 框架或模型服务器，从而保持基础平台稳定。
认证平台增长背后的实际意义与边界
认证平台从 18 个增至 31 个，反映出厂商对统一、中立标准的响应速度。对用户而言，这意味着在不同认证 Kubernetes 平台上运行 AI 工作负载时，可减少因 GPU、网络、调度和推理编排实现差异带来的可移植性问题与供应商锁定担忧。但文章也表明，该项目聚焦基础设施层，并不覆盖具体 AI 框架或模型服务器的行为。
Q&A
Kubernetes AI Conformance 项目最初为什么被发起？
该项目由 CNCF 发起，旨在解决 AI 工作负载在 Kubernetes 上运行时出现的生态碎片化问题。当时各厂商以不同方式构建 AI 基础设施，尤其在 GPU、网络、调度和推理编排方面差异很大，导致可移植性挑战、运维不一致和厂商锁定风险。项目希望建立社区定义的统一基线。
AI Conformance 从工作组转为 SIG Architecture 子项目，这说明了什么？
工作组是临时性的，在完成发布初始 AI Conformance 要求并启动认证流程后，工作组被归档，AI Conformance 转为 SIG Architecture 下的常设子项目。这证明 AI 需要持续的架构治理，因为 AI 已成为 Kubernetes 日常运行的核心部分，放在 SIG Architecture 下可确保 AI Conformance 要求与整个 Kubernetes 生态长期保持一致。
AI Conformance 如何平衡 AI 基础设施快速演进与 Kubernetes API 稳定性？
项目采用分级毕业模型：新 AI 基础设施概念先作为推荐性（SHOULD）要求引入，给生态实验和达成最佳实践的空间；待 API 稳定并被生态采用后，再升级为强制性（MUST）要求。同时，项目刻意聚焦基础设施层，测试加速器支持（如通过 DRA）等核心能力，而不绑定具体 AI 框架或模型服务器，从而保持基础平台稳定。
AI Conformance 子项目现在的主要目标是什么？
作为 SIG Architecture 下的子项目，其主要目标是保持 AI Conformance 标准的时效性、厂商中立性和标准引领性，确保 Kubernetes 能纳入 AI 基础设施的最新进展，同时维护生态公平。当发现没有明确社区模式的空白时，项目会推动形成新标准来填补。
目前有多少个平台通过了 AI Conformance 认证？增长情况如何？
认证平台已从 18 个增长到 31 个。在 KubeCon NA 2025 主题演讲中首次宣布该计划时，尚不确定反响如何；但到 KubeCon EU 2026 更新演讲时，短短几个月内认证平台就从 18 个增至 31 个，显示出行业对统一、厂商中立标准的强烈需求。
如果想参与 AI Conformance 子项目，有哪些途径？
可以查看主仓库 kubernetes-sigs/ai-conformance 并参加会议。若想定义新的 AI Conformance 要求，可参与 PR 评审或使用 KAR 模板提出建议；若想写代码，可帮助扩展 test/ 目录下的自动化 Go 测试套件。厂商认证详情见 cncf/k8s-ai-conformance。
