英伟达于 2026 年 10 月 6 日发布 AICR v1.0，对象是 GPU 加速的 Kubernetes 集群。这类集群要同时对齐主机内核、GPU 驱动、容器运行时、网络、存储、各类 operator 和负载框架。部件各自发版，升一件就可能拆掉原先能跑的组合。
AICR 全称是 AI Cluster Runtime，面向上述集群给出 recipe。四项能力彼此独立。Snapshot 记录观测到的状态，范围包括 Kubernetes、操作系统、内核、GPU 和拓扑。它不是一份目标配置。
Recipe 描述希望锁定的组件版本、约束和验证阶段。它不负责把集群调到这份描述。Bundle 把 recipe 渲染成操作者选用的制品，博客点名 Helm、Argo CD、Flux 与 Helmfile。真正的安装和调谐，仍由这些工具完成。
Validation 把运行中的集群与 recipe 对照。recipe 若声明了检查项，就继续做部署、符合性与性能检查，并签下证据。操作者要核验证据时，须自己调用相应命令。签名表明谁在哪套硬件上做过这些检查。
验证看板按服务、GPU、操作系统、工作负载意图和可选平台筛选 recipe。筛选之后可以查看每条 recipe 的状态和已公开证据。博客举了一个选择例子：EKS、GB300、Ubuntu、训练和 Kubeflow。这些条件解析成一份锁定版本的 recipe 后，渲染给 Argo CD；换成 Helm、Flux 或 Helmfile，目标配置不变。
v1.0 把兼容约定冻结在五类公开接口上：命令行、REST API、Go SDK、bundle 布局，以及制品 schema。命令行约定包括公开命令、参数、退出语义和结构化输出。服务端对应 aicrd 的 REST API 与 OpenAPI。Go 集成使用 v1 客户端包，命令行和 REST 服务使用同一套对外接口。
每条公开接口都有一份提交进仓库的基线，合并前先对照。v1.0 之后，删除稳定公开接口，或把它改到不兼容，必须发布新的主版本。厂商称，贡献者已超过 100 人，近一半来自英伟达以外。厂商还称，过去六个月 recipe 从少数几条扩到主要 Kubernetes 服务和当前加速器产品线。
Pulumi Labs 用基础设施即代码的 provider 接入 AICR。Mirantis 的 k0rdent 把它放进多集群管理。博客称，两边消费的是同一份 GPU 集群配置，差别在入口工具。
国产加速卡进 Kubernetes，同样要锁住驱动、容器运行时、设备插件和调度组件的版本组合。AICR 的 recipe 与签名证据按英伟达 GPU 来组织，博客没有给出可逐项勾选的完整型号表。换到国产卡或自建集群，验收仍要自备可复核的配置和检查记录。
