AICR v1.0：开放、稳定且可验证的 GPU 集群配置方案
基于 GPU 加速的 Kubernetes 集群依赖于数十个组件的版本兼容性，而每个组件又遵循各自独立的发布周期，包括宿主内核、GPU 驱动、容器运行时、网络、存储、Operator 以及工作负载框架。
某项配置若适用于特定的服务、GPU 世代及 Kubernetes 版本，换到另一套环境时可能因版本冲突而静默失败。在部署后排查版本兼容性问题不仅耗时，还极易出错。
NVIDIA AI Cluster Runtime（AICR）通过提供版本锁定且经过验证的 GPU 集群配置方案来解决这一问题。每个方案（recipe）固定了经过验证可协同工作的组件组合，生成适用于 Helm、Argo CD、Flux 或 Helmfile 的部署制品，并附带在测试硬件上生成的签名验证证据。
AICR 的 v1.0 版本为其 CLI、REST API、Go SDK、捆绑包结构及制品架构确立了稳定的兼容性契约，使运维人员、集成商及贡献者能够自信地基于 AICR 的公开接口进行开发。
运维人员可以通过验证仪表板，按服务、GPU、操作系统、工作负载意图以及可选平台查找配置配方，并查看每个配方的状态，以及针对所测硬件配置发布的验证证据。集成方可以在 v1.x 兼容性政策下基于 AICR 的公开接口进行构建。贡献者则可以为维护者无法测试的环境提出配方，在自己的集群上完成验证，并提交带有签名的证据供维护者审核。
这种配方模式在整个生态系统中也得到了越来越多的应用。Pulumi Labs 通过基础设施即代码 provider 暴露了 AICR，Mirantis 的 k0rdent 集成则将其打包用于多集群管理。这些都印证了一个理念的价值：只需定义一次 GPU 加速的 Kubernetes 配置，就能通过不同的工具来使用。如今，AICR 已拥有超过 100 位不同的贡献者，其中近一半来自 NVIDIA 之外！
为什么 GPU 集群配置需要一个可复现的契约
采用 GPU 加速的 Kubernetes 集群对主内核、GPU 驱动、容器运行时、Kubernetes、网络、存储、设备插件、Operator、调度器及工作负载框架的版本兼容性和配置一致性要求极高。这些组件遵循不同的发布周期，升级其中一项可能会破坏原本正常运行的组合。针对特定服务、GPU 代际、网络拓扑、机型规格和 Kubernetes 版本验证过的配置，在另一环境下可能失效，部署后微小的版本差异往往难以追溯。 即使所有组件都安装成功，集群也不一定能达到配置预设的理想状态。安装成功仅表示部署完成，并不能确认组件健康、所需能力（如 gang 调度或加速器发现）是否正常运作，也无法证明实测性能达到了预设阈值。 过去，关于哪些组合可用以及如何进行验证的知识，分散在不同的验证系统、部署脚本和运维手册中。这使得团队难以发现、复现并更新可用的配置。 过去六个月，AICR 从少量配置模板扩展为一个覆盖主流 Kubernetes 服务和当前 NVIDIA 加速器产品组合的模板库，并以与部署工具无关的 Bundle 形式呈现。我们引入了实时集群验证、签名证据、公共证据聚合和供应链验证。在 v1.0 版本中，我们还新增了兼容性基线承诺，并针对公共集成接口增加了阻断合并的检查机制。从观察到的状态到可验证的结果
AICR 提供四项核心能力：
- 快照（Snapshot）记录集群的实际运行状态，包括 Kubernetes、操作系统、内核、GPU 及拓扑信息。
- 模板（Recipe）描述期望的版本锁定组件配置，以及适用的约束条件和验证阶段。
- 包（Bundle）将模板渲染为操作员首选的部署工具所需的产物。
- 验证（Validation）对比模板与实际状态，并在声明的情况下，对集群执行部署、合规及性能检查。
这四项能力是有意设计为相互独立的。快照（snapshot）记录的是集群的观测状态，而非期望配置。配方（recipe）描述的是期望配置，但不直接执行集群调和。Helm、Argo CD、Flux 或 Helmfile 等主流开源 CD 工具负责将配置包（bundle）应用或同步到集群中。随后，AICR 可以依据配方的预期来验证运行中的集群，并记录带签名的验证结果证据。
这些能力可以按多种顺序组合使用。快照数据或明确的目标标准可以生成配方。配方可以生成适用于现有部署工具的配置包。配方与观测到的集群状态共同用于验证过程。操作员在调用相应命令时，需显式地校验配置包和证据。
例如，操作员可以选择 EKS、GB300、Ubuntu、训练场景和 Kubeflow；将这些标准解析为一个版本锁定的配方；为该配方生成 Argo CD 所需的渲染结果；通过现有的 GitOps 工作流进行部署；并针对同一配方验证运行中的集群。即使操作员改为使用 Helm、Flux 或 Helmfile 进行渲染，目标配置本身也不会因此改变。
AICR v1.0 的新特性
AICR v1.0 为其公共 CLI、REST API、Go SDK、配置包布局以及产物 Schema 定义了兼容性规则。它还允许操作员检查每个受支持配方所发布的验证证据，包括：测试了什么、哪些检查通过，以及结果由谁签名。
AICR v1.0 为以下内容设定了兼容性规则：
aicrCLI 的公共命令、标志、退出语义以及结构化输出aicrdREST API 及其 OpenAPI 契约github.com/NVIDIA/aicr/pkg/client/v1包导出的 API- 生成的 bundle 目录结构和 AICR artifact schema
每个公开接口都有提交到代码库的基线，任何变更在合并前都会对照基线检查。发布策略还明确定义了语义上的破坏性变更：v1.0 之后，删除稳定公开接口或做不兼容修改，必须发布新的主版本。
对于 Go 集成者，pkg/client/v1 提供了受支持的工作流，无需导入 AICR 的内部包。CLI 和 REST 服务端也使用同一套门面，降低了不同公开入口行为不一致的风险。
试用 AICR 并参与贡献
在你的环境中试运行一个 recipe，检查其状态和已发布证据，并在有证据的地方运行 dashboard 的 aicr evidence verify 命令。当前项目尚未覆盖的硬件和集群组合，尤其欢迎贡献。你可以：
- 贡献新功能、集成方案或文档
- 为 AICR 尚未支持的硬件、操作系统或服务提交 recipe
- 在自己的集群中验证 recipe，并提交签名证据
- 通过 GitHub Issues 报告 bug、分享反馈或提出功能需求