GPU加速的Kubernetes集群依赖数十个组件间的版本兼容性，而这些组件各自拥有独立的发布周期：主机内核、GPU驱动、容器运行时、网络、存储、操作器以及工作负载框架。
某种配置可能适用于某个服务、某代GPU和某个Kubernetes版本，但在另一种场景下却可能悄然失效，而部署后再去追踪版本冲突问题既缓慢又容易出错。
NVIDIA AI集群运行时（AICR）通过提供经过版本锁定、验证过的GPU集群配置方案来解决这一问题。每个配置方案都固定了可协同工作的组件组合，能够为Helm、Argo CD、Flux或Helmfile渲染部署工件，并附带来自实测硬件的签名验证证据。
AICR v1.0版本在其CLI、REST API、Go SDK、软件包布局和工件模式之间建立了稳定的兼容性约定，使运维人员、集成商和贡献者能够放心地基于AICR的公共接口进行开发。
验证仪表盘让运维人员可以按服务、GPU、操作系统、工作负载意图以及可选平台来查找配置方案，然后查看每个方案的状态以及针对测试硬件配置发布的任何证据。集成商可以在v1.x兼容性策略下基于AICR的公共接口进行开发。贡献者可以为维护团队无法测试的环境提出配置方案，在自己的集群上进行验证，并提交签名证据供维护团队审核。
这种配置方案模式也在生态系统中找到了应用场景。Pulumi Labs通过基础设施即代码提供商公开了AICR，而Mirantis的k0rdent集成则将其打包用于多集群管理。两者共同展示了一次性定义GPU加速Kubernetes配置、再通过不同工具使用的价值。目前，AICR已拥有超过100名独立贡献者，其中近半数来自NVIDIA外部。
为什么GPU集群配置需要可复现的约定
GPU加速的Kubernetes集群依赖主机内核、GPU驱动、容器运行时、Kubernetes、网络、存储、设备插件、操作器、调度器以及工作负载框架之间的版本和设置兼容性。这些组件遵循不同的发布周期；升级其中一个可能破坏此前有效的组合。针对某个服务、某代GPU、某种网络架构类型、机器形态和Kubernetes版本验证过的配置，可能在另一种场景下失效，而细微的版本差异在部署后很难追踪。
即使每个组件都成功安装，集群也可能不符合配置方案预期的设置。安装成功并不能证明组件是健康的，也不能证明像组调度或加速器发现这样的必需能力是正常工作的，更不能证明实测结果达到了配置方案的性能门槛。
哪些组合有效以及如何验证这些组合的知识，分散存在于各个验证系统、部署脚本和运维手册中。这使得团队难以发现、复现和更新有效的配置方案。
过去六个月里，AICR从少量配置方案发展成涵盖主要Kubernetes服务和当前NVIDIA加速器产品线的方案库，并以与部署工具无关的方式渲染为软件包。我们增加了实时集群验证、签名证据、公开证据聚合以及供应链验证功能。在v1.0版本中，我们还为公共集成接口增加了既定的兼容性基准和合并阻断检查机制。
从观测状态到可验证结果
AICR提供四项核心能力：
快照记录观测到的集群状态，包括Kubernetes、操作系统、内核、GPU以及拓扑信息。
配置方案描述所需的、版本锁定的组件配置，以及适用于该配置的约束条件和验证阶段。
软件包将配置方案渲染为适用于运维人员首选部署工具的工件。
验证将配置方案与观测状态进行比较，并在声明的情况下针对集群运行部署、合规性和性能检查。
这四项能力是刻意设计为相互独立的。快照记录观测状态，它不是期望的配置。配置方案描述期望的配置，它不会调和集群状态。常见的开源持续交付工具如Helm、Argo CD、Flux或Helmfile会将软件包应用或调和到集群中。随后AICR可以针对配置方案验证运行中的集群，并记录结果的签名证据。
这些能力可以按多种顺序组合使用。快照数据或明确的目标标准都可以生成配置方案。配置方案可以为现有的部署工具生成软件包。配置方案和观测到的集群状态共同输入验证流程。运维人员在调用相应命令时明确验证软件包和证据。
举例来说，运维人员可以选择EKS、GB300、Ubuntu、训练场景和Kubeflow；将这些标准解析为一个固定的配置方案；为Argo CD渲染该方案；通过现有的GitOps工作流部署；然后针对同一配置方案验证运行中的集群。如果运维人员改为将其渲染给Helm、Flux或Helmfile，预期的配置并不会发生变化。
AICR v1.0有哪些新特性
AICR v1.0为其公共CLI、REST API、Go SDK、软件包布局和工件模式定义了兼容性规则。它还允许运维人员查看针对每个受支持配置方案发布的验证证据：测试了什么内容、哪些检查通过了，以及由谁签署了这些结果。
AICR v1.0为以下内容设定了兼容性规则：
aicr CLI的公共命令、标志、退出语义和结构化输出
aicrd REST API及其OpenAPI约定
github.com/NVIDIA/aicr/pkg/client/v1软件包导出的API
生成的软件包布局以及AICR工件模式
每个公共接口都有一个既定的基准，在变更合并前会进行检查。该发布政策还定义了语义上的破坏性变更。v1.0版本发布后，移除或以不兼容方式更改一个稳定的公共接口，需要发布新的主要版本。
对于Go集成商来说，pkg/client/v1公开了受支持的工作流程，而不需要从AICR的内部软件包导入内容。CLI和REST服务器使用相同的接口外观，降低了一个公共入口点与另一个表现不一致的风险。
体验AICR并参与贡献
为您的环境尝试一个配置方案，查看其状态和任何已发布的证据，并在证据可用的情况下运行仪表盘的aicr evidence verify命令。对于当前项目覆盖范围之外的硬件和集群组合，贡献内容尤为有价值。您可以：
贡献功能、集成或文档
为尚未在AICR中体现的硬件、操作系统或服务提出配置方案
在自己的集群中验证某个配置方案并提交签名证据
通过GitHub Issues报告错误、分享反馈或提出功能需求
从项目仓库、贡献指南和问题跟踪系统开始参与。
Q&A
Q1：AICR v1.0是什么？它能解决什么问题？
A：AICR v1.0是NVIDIA推出的AI集群运行时工具，提供版本锁定、经过验证的GPU集群配置方案。它能解决GPU加速Kubernetes集群中数十个组件版本兼容性难以追踪和复现的问题。
Q2：AICR支持哪些部署工具？
A：AICR的配置方案可以渲染为适用于Helm、Argo CD、Flux或Helmfile的部署工件，运维人员可以根据自己的工作流程选择合适的部署方式，而底层的配置内容保持一致。
Q3：如何为AICR贡献配置方案？
A：贡献者可以为维护团队无法测试的硬件和集群环境提出配置方案，在自己的集群上进行验证，并提交签名证据供维护团队审核，还可以通过GitHub Issues报告问题或提出功能需求。
