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