一个 GPU 加速的 Kubernetes 集群，背后是内核、GPU 驱动、容器运行时、Kubernetes 版本、网络、存储、设备插件、算子、调度器和工作负载框架等数十个组件，每个组件都有自己的发布节奏。为某一类服务、某一代 GPU 和某个 Kubernetes 版本调通的组合，换到另一个环境可能静默失效，而部署之后再排查版本冲突往往既慢又难。
NVIDIA AI Cluster Runtime（AICR）针对的正是这个问题：提供经过验证、版本锁定的配方（recipe），把能够协同工作的组件组合固定下来。每份配方不仅声明依赖版本，还能渲染出面向 Helm、Argo CD、Flux 或 Helmfile 的部署产物，并在集群运行后核对该集群是否真的符合配方描述的配置。
v1.0 的核心意义是把接口固化。该版本在 CLI、REST API、Go SDK、bundle 布局和产物 schema 上建立了稳定的兼容性契约，使运维团队、集成商和贡献者可以基于公开接口构建自己的流程，而不必担心版本升级时底层结构变动导致工具链失效。
AICR 由四项相互独立的能力组成。Snapshot 记录集群当前的实际状态；Recipe 描述期望的配置；Bundle 把配置渲染成可直接用于部署的产物；Validation 则在集群运行后验证其是否达到配方要求。NVIDIA 强调，安装成功并不等于配置正确——组件可能装上了却不健康，或者缺少 gang scheduling、加速器共享等关键能力，验证环节必须独立于安装环节。
为方便查找，NVIDIA 提供了实时验证看板：运维人员可以按服务、GPU 型号、操作系统、工作负载意图和平台筛选配方，并查看每份配方的验证状态和公开的验证证据。这让"这个组合有没有人验证过、证据是什么"成为可以查证的信息，而不是散落在各团队的运维手册里。
生态侧已经开始复用同一套配方模型。Pulumi Labs 通过基础设施即代码 provider 暴露 AICR，Mirantis 的 k0rdent 集成则把它打包进多集群管理流程，两者消费的是同一份 GPU 集群配置。NVIDIA 表示项目已在代码仓库开放，并欢迎通过贡献指南提交新配方或签署的验证证据。
WeChat
Profile