AICR v1.0：开源、稳定且可验证的 GPU 集群配置（阅读约 6 分钟）

# AICR v1.0：开放、稳定且可验证的 GPU 集群配置 来源：https://developer.nvidia.com/blog/aicr-v1-0-open-stable-and-verifiable-gpu-cluster-configuration GPU 加速的 Kubernetes 集群依赖数十个组件之间的版本兼容性，而每个组件都有自己的发布周期：主机内核、GPU 驱动、容器运行时、网络、存储、Operator 和工作负载框架。 一套在某个服务、GPU 代际和 Kubernetes 版本下可用的配置，可能在另一套组合中悄无声息地失效，而部署后再排查版本冲突既缓慢又容易出错。 NVIDIA AI Cluster Runtime（https://github.com/NVIDIA/aicr）（AICR）通过版本锁定且经过验证的 GPU 集群配置配方（Recipe）来解决这一问题。每个配方固定了一组可协同工作的组件版本组合，可为 Helm、Argo CD、Flux 或 Helmfile 渲染部署产物，并附带来自实际测试硬件的签名验证证据。 AICR v1.0 发布版（https://github.com/NVIDIA/aicr/releases/tag/v1.0.0）在 CLI、REST API、Go SDK、Bundle 布局和产物 Schema 之间建立了稳定的兼容性契约，使运维人员、集成商和贡献者可以放心地基于 AICR 的公开接口进行构建。 AICR 覆盖范围概览：11 种 Kubernetes 服务；覆盖 Rubin、Blackwell、Hopper、Ampere 和 Ada 的 10 种 GPU 加速器；支持 Ubuntu、COS 和 Oracle Linux，以及通过 mixin 支持 Talos；支持 Helm、Helmfile、Argo CD 和 Flux 部署工具；训练支持 Kubeflow 和 Slurm，推理支持 Dynamo 和 NIM。 *图 1：AICR 对 Kubernetes 服务、多代 NVIDIA GPU 加速器、支持的 Linux 操作系统、部署框架和工作负载平台的覆盖范围* 验证仪表盘（https://validation.aicr.run/）让运维人员可以按服务、GPU、操作系统、工作负载意图和可选平台查找配方，然后查看每个配方的状态以及已测试硬件配置的任何已发布证据。集成商可以在 v1.x 兼容性策略下基于 AICR 的公开接口进行构建。贡献者可以为维护者无法测试的环境提议配方，在自己的集群上进行验证，并提交签名证据供维护者审核。 这种配方模型也正在整个生态系统中得到应用。Pulumi Labs（https://www.pulumi.com/registry/packages/nvidia-aicr/）通过基础设施即代码（IaC）提供程序暴露 AICR，而 Mirantis 的 k0rdent 集成（https://github.com/k0rdent/catalog/blob/main/apps/aicr/data.yaml）则将其打包用于多集群管理。两者共同展示了只需定义一次 GPU 加速 Kubernetes 配置，即可通过不同工具消费的价值。目前，AICR 拥有超过 100 位不同的贡献者，其中近一半来自 NVIDIA 之外！ ## 为什么 GPU 集群配置需要一个可复现的契约 GPU 加速的 Kubernetes 集群依赖主机内核、GPU 驱动、容器运行时、Kubernetes、网络、存储、设备插件、Operator、调度器和工作负载框架之间的版本与设置兼容性。这些组件遵循不同的发布周期；升级其中一个可能会破坏原本可用的组合。一套针对某个服务、GPU 代际、网络Fabric 类型、机器规格和 Kubernetes 版本验证过的配置，可能在另一套组合中失效，而部署后微小的版本差异往往难以追踪。 即使每个组件都安装成功，集群也可能未达到配方所预期的配置。安装完成并不能确认各组件是否健康、组调度（gang scheduling）或加速器发现等必需能力是否正常工作，也不能确认实测结果是否达到了配方的性能阈值。 关于哪些组合可用以及如何验证的知识，长期以来分散在不同的验证系统、部署脚本和运维手册中。这使得团队很难发现、复现和更新可用配置。 在过去六个月中，AICR 已从少量配方成长为一个覆盖主要 Kubernetes 服务和当前 NVIDIA 加速器产品组合的配方库，并以部署工具无关的 Bundle 形式呈现。我们新增了实时集群验证、签名证据、公开证据聚合和供应链验证功能。在 v1.0 中，我们还为公开集成接口增加了已提交的兼容性基线和合并阻断检查。 ## 从观测状态到可验证的结果 AICR 提供四项核心能力： - **Snapshot（快照）**：记录观测到的集群状态，包括 Kubernetes、操作系统、内核、GPU 和拓扑信息。 - **Recipe（配方）**：描述期望的、版本锁定的组件配置，以及适用于它的约束和验证阶段。 - **Bundle（部署包）**：将配方渲染为运维人员所选部署工具所需的产物。 - **Validation（验证）**：将配方与观测状态进行比较，并在声明了相应阶段时，针对集群运行部署、一致性和性能检查。 这四项能力是有意设计为相互独立的。快照记录的是观测状态，而不是期望配置。配方描述的是期望配置，但不会对集群进行调和。Helm、Argo CD、Flux 或 Helmfile 等常见的开源 CD 工具将 Bundle 应用或调和到集群中。随后 AICR 可以对照配方验证运行中的集群，并记录签名的结果证据。 这些能力可以按多种顺序组合使用。快照数据或显式的目标条件可以生成配方。配方可以为现有的部署工具生成 Bundle。配方与观测到的集群状态共同作为验证的输入。运维人员在调用相应命令时显式验证 Bundle 和证据。 AICR 工作流：目标条件和集群快照共同生成版本锁定的配方，进而生成部署包。经过可选的完整性验证后，现有工具将部署该部署包。AICR 对照配方验证最新的集群状态，并可选地生成签名证据。 *图 2：NVIDIA AI Cluster Runtime 生命周期* 例如，运维人员可以选择 EKS、GB300、Ubuntu、训练和 Kubeflow；将这些条件解析为一个锁定版本的配方；为 Argo CD 渲染该配方；通过现有的 GitOps 工作流进行部署；然后用同一个配方验证运行中的集群。如果运维人员改为使用 Helm、Flux 或 Helmfile 渲染，期望的配置也不会改变。 ## AICR v1.0 中的新增内容 AICR v1.0 为其公开的 CLI、REST API、Go SDK、Bundle 布局和产物 Schema 定义了兼容性规则。它还让运维人员可以查看每个受支持配方所发布的验证证据：测试了什么、哪些检查通过了、谁签署了结果。 AICR v1.0 为以下接口设定了兼容性规则： - `aicr` CLI 的公开命令、选项参数、退出语义和结构化输出 - `aicrd` REST API 和 OpenAPI 契约 - `github.com/NVIDIA/aicr/pkg/client/v1`（https://github.com/NVIDIA/aicr/tree/main/pkg/client/v1）包的导出 API - 生成的 Bundle 布局和 AICR 产物 Schema 每个公开接口都有一个已提交的基线，在变更合并之前会进行检查。发布策略还定义了语义化破坏性变更。在 v1.0 之后，移除或以不兼容方式修改一个稳定的公开接口需要发布新的主版本。 对于 Go 集成商，`pkg/client/v1` 暴露了受支持的工作流，无需导入 AICR 的内部包。CLI 和 REST 服务端使用同一套门面（facade），降低了不同公开入口行为不一致的风险。 ## 试用 AICR 并做出贡献 为你的环境选择一个配方，查看其状态和已发布的证据，并在有证据可用的地方运行仪表盘上的 `aicr evidence verify` 命令。对于当前项目尚未覆盖的硬件和集群组合，贡献尤为重要。你可以： - 贡献功能、集成或文档 - 为 AICR 尚未收录的硬件、操作系统或服务提议配方 - 在你自己的集群上验证配方并提交签名证据（https://github.com/NVIDIA/aicr/blob/main/docs/contributor/evidence-publishing.md） - 通过 GitHub Issues 报告 Bug、分享反馈或提出功能需求 请从项目仓库（https://github.com/NVIDIA/aicr）、贡献指南（https://github.com/NVIDIA/aicr/blob/main/CONTRIBUTING.md）和问题追踪器（https://github.com/NVIDIA/aicr/issues）开始。