网络安全

AICR v1.0：开放、稳定且可验证的 GPU 集群配置

2026年 10月 6日
作者： 和

GPU 加速的 Kubernetes 集群依赖于数十个组件的兼容版本，每个组件都有自己的发布周期：主机内核、GPU 驱动程序、容器运行时、网络、存储、运算符和工作负载框架。

适用于一种服务、GPU 生成和 Kubernetes 版本的配置可能会悄无声息地导致另一种服务失败，并且部署后追踪版本冲突速度缓慢且容易出错。

NVIDIA AI 集群运行时 (AICR) 通过版本锁定、经过验证的 GPU 集群配置方法解决了这一问题。每个 recipe 固定可协同工作的组件组合，渲染 Helm、Argo CD、Flux 或 Helmfile 的部署构件，并携带来自所测试硬件的签名验证证据。

AICR v1.0 版本在其 CLI、REST API、Go SDK、捆绑包布局和构件架构中建立了稳定的兼容性，以便运营商、集成商和贡献者可以放心地基于 AICR 的公共接口进行构建。

AICR coverage overview: 11 Kubernetes services; 10 GPU accelerators spanning Rubin, Blackwell, Hopper, Ampere, and Ada; Ubuntu, COS, and Oracle Linux, plus Talos via mixin; Helm, Helmfile, Argo CD, and Flux deployment tools; and Kubeflow and Slurm for training, with Dynamo and NIM for inference.
图 1：跨 Kubernetes 服务、多代 NVIDIA GPU 加速器、受支持的 Linux 操作系统、部署框架和工作负载平台的 AICR 覆盖范围

借助验证仪表板，操作员可以按服务、GPU、操作系统、工作负载意图和可选平台查找菜谱，然后检查每个菜谱的状态以及所测试硬件配置的任何已发布证据。集成商可以根据 v1.x 兼容性策略 针对 AICR 的公共接口进行构建。贡献者可以针对维护人员无法测试的环境提出解决方案，在自己的集群上进行验证，并提交签名的证据以供维护人员审查。

这种配方模型也在整个生态系统中找到了用途。Pulumi Labs 通过基础架构即代码提供程序公开 AICR，而 Mirantis 的 k0rdent 集成 则将其打包用于多集群管理。它们共同展示了定义一次 GPU 加速的 Kubernetes 配置并通过不同工具使用该配置的价值。如今，AICR 有 100 多名不同的贡献者，其中近一半来自 NVIDIA 以外的组织！

为什么 GPU 集群配置需要可复制的合同

GPU 加速的 Kubernetes 集群依赖于主机内核、GPU 驱动程序、容器运行时、Kubernetes、网络、存储、设备插件、运算符、调度程序和工作负载框架中的兼容版本和设置。这些组件遵循不同的发布周期；升级一个可能会破坏以前的工作组合。针对一种服务、GPU 生成、结构类型、机器形状和 Kubernetes 版本验证的配置可能会针对另一种服务失败，并且部署后可能难以追踪微小的版本差异。

即使每个组件都已成功安装，集群也可能无法满足 recipe 的预期配置要求。安装并不确认组件是否正常运行，是否需要轮班调度或加速器发现工作等功能，或者测量结果是否符合配方的性能值。

我们已在单独的验证系统、部署脚本和操作 runbook 中了解了哪些组合有效，以及如何对其进行验证。这使得团队很难发现、重现和更新工作配置。

在过去六个月中，AICR 从几个方案发展为涵盖主要 Kubernetes 服务和当前 NVIDIA 加速器产品组合的库，并以部署者中立的捆绑包形式呈现。我们添加了实时集群验证、签名证据、公开证据聚合和供应链验证。对于 v1.0，我们还在公共集成表面周围添加了承诺的兼容性基准和合并 – 阻塞检查。

从观察到的状态到可验证的结果

AICR 提供四种核心功能：

  • 快照记录观察到的集群状态，包括Kubernetes、操作系统、内核、GPU和拓扑信息。
  • Recipe描述了所需的版本锁定组件配置，以及适用于该配置的约束条件和验证阶段。
  • 捆绑包会将配方渲染为操作员首选部署工具的构件。
  • 验证将 recipe 与观察到的状态进行比较，并在声明的位置对集群运行部署、一致性和性能检查。

这四种功能是有意独立的。快照记录观察到的状态；它不是所需的配置。recipe 描述了所需的配置；它不协调集群。常见的开源 CD 工具 (如 Helm、Argo CD、Flux 或 Helmfile) 可应用该捆绑包或将其与集群保持一致。然后，AICR 可以根据 recipe 验证正在运行的集群，并记录签名的结果证据。

这些功能可以按多个序列进行组合。快照数据或明确的目标标准可以生成食谱。recipe 可以为现有部署器生成捆绑包。recipe 和观察到的集群状态馈送验证。运算符会在调用相应命令时显式验证捆绑包和证据。

AICR workflow: target criteria and a cluster snapshot inform a version-pinned recipe, which becomes a deployment bundle. After optional integrity verification, existing tools deploy the bundle. AICR validates the recipe against fresh cluster state and optionally produces signed evidence.
图 2：NVIDIA AI 集群运行时生命周期

例如，操作员可以选择 EKS、GB300、Ubuntu、training 和 Kubeflow；将这些标准解析为固定 recipe；渲染 Argo CD recipe；通过现有的 GitOps 工作流部署该 recipe；并根据同一 recipe 验证正在运行的集群。如果由 Operator 为 Helm、Flux 或 Helmfile 渲染预期配置，则预期配置不会改变。

AICR v1.0 的新增功能

AICR v1.0 为其公共 CLI、REST API、Go SDK、捆绑包布局和构件模式定义了兼容性规则。它还允许操作员检查为每个支持的 recipe 发布的验证证据：测试的内容、通过的检查以及谁在结果上签名。

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 服务器使用相同的 Facade，从而降低了一个公共入口点的行为与另一个公共入口点不同的风险。

试用 AICR 并做出贡献

试用适用于您环境的 recipe，检查其状态和任何已发布的证据，并在证据可用时运行控制面板的 aicr evidence verify 命令。贡献对于当前项目范围以外的硬件和集群组合尤其有用。您可以：

  • 贡献功能、集成或文档
  • 为尚未在 AICR 中表示的硬件、操作系统或服务提出解决方案
  • 在您自己的集群中验证 recipe 并提交签名证据
  • 通过 GitHub 问题报告错误、分享反馈或请求功能

从项目资源库、贡献指南和问题追踪器开始。

标签

开发工具与技巧 | 数据中心/云端 | 智能体/生成式 AI | 网络安全 | 云服务 | Dynamo | NIM | 中级技术水平 | 公告 | Kubernetes

关于作者

Mark Chmarny 是 NVIDIA DGX 云组织的首席云架构师，专门从事大规模分布式系统、容器编排和 GPU 加速计算。他专注于基于 Kubernetes 的 AI/ ML 平台、高性能 GPU 集群以及用于训练和推理的多云基础设施。
Nathan Taber 是一位产品经理，他帮助定义了现代云和 AI 基础设施的构建方式。在 AWS，他是 Amazon EKSteam 的创始成员，并通过 EKS、Karpenter 和更广泛的 OSS 生态系统帮助定义了 AWS 的 Kubernetes。在 NVIDIA，他帮助为大规模 AI 基础设施定义 GPU 加速的 Kubernetes 和健康自动化模式，从而影响云提供商及其客户如何可靠地大规模运行生产级 GPU 工作负载。