aicr · 工程化与运维

让 GPU 集群部署像"配方"一样简单

想象一下这样的场景：你的团队刚拿到一批 H100 GPU 服务器，需要在上面跑 PyTorch 分布式训练任务。传统的做法是翻文档、查兼容性矩阵、手动调参——光配置 GPU Operator 和 NCCL 就可能耗掉一整天。更糟糕的是，同样的配置在另一台机器上可能完全不 work，排查起来无从下手。

NVIDIA AI Cluster Runtime（简称 AICR） 正是为解决这个痛点而生的。它将 NVIDIA 内部积累的 GPU 集群部署经验封装成可复现的"配方"（Recipe），让任何人都能一键生成经过验证的 Kubernetes GPU 集群配置。

打个比方：如果 Kubernetes 是厨房，GPU 集群是一道分子料理，AICR 就是那本经过米其林验证的食谱——你只需告诉它"用什么锅（GPU型号）、什么灶台（云服务商）、做什么菜（训练还是推理）"，它就能给你一份精确到版本的配料表（Helm Values）和操作步骤（Argo CD Manifests）。

背景：为什么 GPU 集群部署这么难？

GPU 加速的 Kubernetes 集群可靠性运行是一个被长期低估的难题。一个看似简单的"跑起 PyTorch 训练"背后，涉及：

驱动兼容性：GPU Operator 版本与 CUDA 版本、Linux 内核版本必须精确匹配，差一个 Patch 版本就可能导致 NCCL 超时
网络配置：EFA（AWS）、NCCL-tcpXO（GKE）等网络插件的启用顺序和参数设置直接影响多卡通信效率
Operator 依赖链：GPU Operator → Node Feature Discovery → GPU Feature Discovery，每层都有版本约束
多云差异：同一个配置在 EKS、GKE、AKS 上的表现可能完全不同

这些知识过去只存在于 NVIDIA 内部的验证 pipeline 和运维手册中。AICR 首次将其公开，以开源方式分享给整个生态。

核心功能：从快照到验证的完整闭环

AICR 提供了完整的工作流：Snapshot → Recipe → Bundle → Validate

1. 快照采集（Snapshot Agent）

Snapshot Agent 是一个 Kubernetes Job，运行在你的集群中，自动采集以下信息：

GPU 硬件型号、数量、驱动版本
内核版本、操作系统版本
已安装的 Kubernetes Operator 及其版本
网络插件配置、存储配置

这些数据被写入一个 ConfigMap，作为后续验证的基准线。

2. 配方生成（Recipe）

Recipe 是 AICR 的核心概念——一份针对特定环境的版本锁定配置。用户只需声明目标环境：

aicr recipe --service eks --accelerator h100 --os ubuntu \
  --intent training --platform kubeflow -o recipe.yaml

支持的维度：

维度	支持值
云服务	AKS, BCM, EKS, GKE, Kind, LKE, OKE
GPU	A100, B200, GB200, H100, H200, L40, RTX PRO 6000
操作系统	Amazon Linux, COS, RHEL, Talos, Ubuntu
工作负载	Inference（推理）, Training（训练）
平台	Dynamo, Kubeflow, NIM, Run:ai, Slurm (Slinky)

Recipe 引擎将这些参数与一个经过层级叠加验证的 overlay 库匹配，从基础配置 → 云平台 → GPU 类型 → OS → 工作负载意图，逐层组合生成最优配置。

3. Bundle 生成（多 Deployer 支持）

Recipe 生成后，通过 Bundler 渲染为部署产物，支持 5 种主流 GitOps 工具：

Argo CD：生成 Application Manifest（argocd）或 Helm Chart App-of-Apps 变体（argocd-helm）
Flux：生成 HelmRelease + Kustomization Manifest
Helmfile：helmfile.yaml Release Graph
Helm：原生 Helm 命令

这意味着同一个 Recipe 可以无缝对接到企业已有的 GitOps 流程，不需要改变任何基础设施。

4. 集群验证（Validator）

部署完成后，用 aicr validate 对集群进行多阶段验证：

部署阶段：检查声明式约束（配置是否正确渲染、Operator 是否正常启动）
性能阶段：跑训练/推理 Benchmark，验证 GPU 通信效率（NCCL Test、Megatron-LM）
合规阶段：对照 CNCF AI Conformance 标准验证

此外还有 aicr diff 命令用于漂移检测——比较两个快照，检测集群配置随时间或环境变化产生的差异。

技术架构：Go + Kubernetes + Sigstore

技术栈

AICR 由纯 Go 语言开发，核心依赖：

组件	技术选型	作用
运行时	Go 1.26	CLI 和 API Server
K8s SDK	`k8s.io/client-go`	与集群交互
Helm 封装	`sigs.k8s.io/kustomize`	配置渲染
供应链安全	Sigstore / Cosign	镜像签名与 SBOM
SBOM 格式	CycloneDX	软件物料清单
证明协议	SLSA Level 3	构建溯源
API 框架	`urfave/cli/v3`	CLI 参数解析

项目结构

pkg/
  ├── bom/         # SBOM 生成（CycloneDX）
  ├── build/       # 构建规范和镜像构建
  ├── bundler/     # 核心：Bundler 模块（attestation/identity/kms/keyless）
  ├── recipe/       # Recipe 引擎和 overlay 解析
  ├── snapshot/    # 集群状态采集
  └── validate/    # Validator 执行引擎
cmd/
  ├── aicr/       # 主 CLI 程序
  ├── aicrd/      # REST API Server
  └── gate/       # 准入控制器
api/aicr/         # OpenAPI 规范
recipes/           # 经过验证的配置 Overlays
validators/        # 验证测试套件（Chainsaw / Conformance / Deployment / Performance）

三种使用形态

AICR 不只是 CLI 工具，提供了三种消费形态，满足不同场景：

aicr CLI：本地一键安装，适合运维工程师和 SRE
aicrd API Server：REST API 暴露 CLI 所有能力，适合 CI/CD 集成和离线/气隙环境
Go Library（github.com/NVIDIA/aicr/pkg/client/v1）：直接嵌入 Go 程序，无需子进程或 HTTP 调用

供应链安全亮点

安装脚本内置了 Cosign 证明验证——每次安装后自动用 Cosign 验证二进制来自 NVIDIA CI pipeline（通过 GitHub Actions OIDC），并用 Sigstore 签名验证 SBOM。安装过程还自动更新本地 Sigstore Trusted Root，支持离线验证。

局限与注意事项

AICR 有明确的边界，不是什么都能做：

不是集群供给工具：不负责创建 EKS/GKE 集群本身，需要先有一个运行中的 K8s 集群
需要 GPU 硬件：Validator 的性能测试阶段需要真实 GPU 环境（不过 KWOK Tier 可以用模拟集群跑基础测试）
配置复杂度不低：虽然 Recipe 简化了组合问题，但对于完全不懂 Kubernetes 的用户仍有一定门槛
生态仍在扩展：Roadmap 显示 v1 GA 前还在补充 L40、B200 加速器支持，以及 CNCF AI Conformance 认证

此外，该项目对 Go 版本要求较高（1.26+），使用旧版 Go 的开发者需要先升级工具链。

行业意义与趋势

AICR 的出现代表着 GPU 基础设施从"手工作坊"向"工业化生产"演进的一个缩影。随着 H100、B200 等高端 GPU 的普及，集群配置的复杂性成指数增长，靠个人经验已经无法保障可靠性。

NVIDIA 愿意将内部验证 pipeline 开源，说明 GPU 集群运营已经进入需要标准化的阶段。这个项目的价值不仅是工具本身，更是一种示范——把"只有大厂内部才知道的配置知识"用 Recipe 形式结构化、可验证化，降低整个行业 GPU 基础设施的运维门槛。