随着各团队使用NVIDIA Dynamo、Kubeflow或Slurm部署和扩展AI工作负载，要追踪实际运行的内容，仅凭配方（recipe）中记录的平台配置已远远不够。应用团队独立于平台配方定义和更新这些工作负载，因此，单靠一个可复现的部署包无法确定每个节点上实际运行的工作负载构件。像":latest"这样可变的镜像标签又增加了一层复杂性——两个节点可能在相同标签下运行不同的代码，而下周拉取镜像的节点，获取到的版本可能并未经过此前的安全审查。
NVIDIA AI Cluster Runtime（AICR）是NVIDIA DSX AI工厂平台的一个开源模块化组件，现已纳入一个经过认证的AI物料清单（AIBOM）组件，用以弥补这一缺口。k8s-aibom是由谷歌创建的开源项目，用于追踪在Kubernetes上运行的AI工作负载。目前有两个标准配方默认选用k8s-aibom：h100-gke-cos-inference和h100-gke-cos-inference-dynamo。其他GKE配方也可以在生成时通过--runtime-inventory enabled参数选择启用；而默认启用该功能的配方，也可通过--runtime-inventory disabled选择禁用。
AICR能够将已知良好的GPU平台配置转化为版本锁定的配方和可复现的部署包。每个配方记录了针对某一硬件、云平台、操作系统与使用场景组合的期望配置：包括其组件、版本锁定、取值、约束条件、部署顺序以及验证预期。AICR根据固定的配方、目录与部署包输入，生成可复现的部署构件。部署包包含校验和；签名功能可通过aicr bundle --attest选择性启用。
通过k8s-aibom进行认证是一项具体的技术声明，而非形式上的盖章认可。AICR将确切的上游源代码、Helm chart、CRD（自定义资源定义）以及摘要锁定的控制器镜像绑定为一个经过测试的整体，依据谷歌的预期构建标识验证其来源可信性，审查渲染后的RBAC（基于角色的访问控制）及安全默认设置，并在其测试覆盖的部署路径上执行安装、升级、健康检查与卸载操作。
本文将帮助你使用AICR为集群配置经过验证、性能优良的Kubernetes运行时环境。
问题的两端
AICR与k8s-aibom关注的是AI基础设施生命周期中的不同部分。AICR帮助平台团队为支持GPU加速的Kubernetes生成并验证已知良好的配置，其工作层面是运行时部署层：驱动程序、算子（operator）、内核、Kubernetes组件与部署配置。
k8s-aibom则着眼于更高层面，关注集群生命周期的后期阶段。它监测Kubernetes工作负载与Pod API，为每个被识别的AI工作负载生成一份CycloneDX 1.6标准的AIBOM文档。其覆盖范围是有边界的：仅对携带可识别AI信号的受支持工作负载类型进行清点，涵盖原生Dynamo图、NIMService、LeaderWorkerSet、DisaggregatedSet以及CronJob资源。被追踪的子工作负载会被合并进其所属主体的AIBOM中。
一个提供对GPU加速Kubernetes配置的控制与可复现性，另一个则为该集群增添工作负载发现与可追溯能力。具体而言，AIBOM能够帮助你：
在选定上报的命名空间中发现未注册或“影子”AI工作负载
识别模型、推理运行时、智能体与检索增强生成（RAG）组件
追踪外部AI API与向量数据库
检测AI依赖项中的变化或偏移
支持安全审查、事件响应与合规审计
这两个项目分别从同一问题的相反两端出发，并各自意识到了这一点。AICR记录经过认证的部署意图，并在某一时刻对照集群实际状态进行评估；k8s-aibom则观察受支持的AI工作负载，记录其发现结果，包括每项属性判定的置信程度。单独来看，任何一方的视角都不足以支撑完整的AI治理，而两者之间的空白地带，恰恰正是当前问责机制所缺失的部分。
将AICR与k8s-aibom结合使用
以下示例基于AICR v1.2.0及其目录版本，该目录锁定了k8s-aibom 1.6.2版本。请使用与此目录匹配的CLI构建版本以复现示例效果。
首先准备一个运行Kubernetes 1.32或更高版本的谷歌Kubernetes引擎（GKE）集群，节点使用NVIDIA H100 GPU，操作系统为容器优化系统（Container-Optimized OS），并采用GKE托管的驱动程序与设备插件。以下工作流程将生成配方、渲染为部署包、完成部署并验证结果。整个过程无需手动组装，也无需手动调优。
在相同的AICR版本、目录及生成输入条件下，配方解析将产生相同的配置结果。最后一步会将集群状态与该配置进行核对，这正是AICR为这一组合带来的价值：快速、可重复地获得经过验证的GPU平台。此后，k8s-aibom将持续清点受支持的AI工作负载。
生成配方
aicr recipe \ --service gke \ --accelerator h100 \ --os cos \ --intent inference \ --output recipe.yaml
新的k8s-aibom组件是作为配方的一部分被选中的，而非事后附加。你可以在不生成文件的情况下查询任何已解析的取值：
aicr query \ --service gke --accelerator h100 --os cos --intent inference \ --selector components.k8s-aibom.version # 1.6.2
打包与部署
使用默认的Helm部署器创建部署包。请将示例中的节点选择器替换为你系统及GPU节点池上实际存在的标签：
aicr bundle \ --recipe recipe.yaml \ --system-node-selector nodeGroup=system-pool \ --accelerated-node-selector nodeGroup=gpu-worker \ --output ./bundles
该部署包按依赖关系图排序，每个组件对应一个目录，各自携带其取值、校验和及安装脚本。AICR通过--deployer参数支持多种部署器，包括helmfile、flux与argocd。
验证生成的部署包，然后进行安装：
(cd ./bundles && aicr verify . && chmod +x deploy.sh && ./deploy.sh)
部署完成后，k8s-aibom控制器将在k8s-aibom-system命名空间中运行。AICR使用的是主chart自带的CRD，而非配套的k8s-aibom-crds chart。Helm部署包中包含CRD应用步骤；Flux与Argo CD则通过各自的控制器处理更新。使用Helmfile、Terraform与Fleet时，若涉及相关版本迁移，则需要按照文档说明手动更新CRD。可通过以下命令检查已安装的存储版本：
kubectl get crd aiboms.aibom.k8saibom.dev \ -o jsonpath='{.spec.versions[?(@.storage==true)].name}' # v1beta1
验证
aicr snapshot --output snapshot.yaml aicr validate --recipe recipe.yaml --snapshot snapshot.yaml \ --phase deployment --phase conformance
k8s-aibom的健康检查是部署阶段的一部分，要求控制器的部署处于可用状态，集群范围内的AIBOMControllerConfig报告当前状态为Ready=True，且两个CRD均报告与锁定chart版本相匹配的存储版本。存储版本匹配并不能证明完整的CRD模式是最新的。在升级过程中，还应核实目标模式，并检查是否出现原因为SchemaPredatesController的Degraded=True状态；详情请参阅健康与就绪性相关说明。
启用某个命名空间
清单生成功能按命名空间选择启用。该标签控制的是哪些命名空间会生成AIBOM记录，并不会缩小控制器的读取范围——信息收集器（informer）依然会在整个集群范围内缓存工作负载与Pod的规格，包括容器参数及内联环境变量。默认情况下未配置任何数据输出端（sink）或密钥访问权限，因此在没有明确决定的情况下，不会有任何数据离开集群。
kubectl create namespace prod-jobs kubectl label namespace prod-jobs aibom.k8saibom.dev/enabled=true
运行一个推理工作负载
当某命名空间启用该功能后，携带可识别AI信号的受支持工作负载将被自动清点。以下是一个使用vLLM部署Qwen模型的简单示例。需要注意的是，该示例拉取的是vllm/vllm-openai:latest镜像，而非固定摘要版本，这种做法在部分环境中并不少见。其中的nvidia-h100-mega-80gb选择器及容忍度（toleration）设置需与你的GPU节点池的标签和污点（taint）相匹配：
apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen namespace: prod-jobs spec: replicas: 1 selector: matchLabels: {app: vllm-qwen} template: metadata: labels: {app: vllm-qwen} spec: # 请根据你的GPU节点池的污点与标签进行调整 tolerations: - key: dedicated operator: Equal value: gpu-workload effect: NoSchedule nodeSelector: cloud.google.com/gke-accelerator: nvidia-h100-mega-80gb containers: - name: vllm image: vllm/vllm-openai:latest args: ["--model", "Qwen/Qwen2.5-0.5B-Instruct", "--max-model-len", "4096", "--gpu-memory-utilization", "0.30"] ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: "1" volumeMounts: - {name: shm, mountPath: /dev/shm} volumes: - name: shm emptyDir: {medium: Memory, sizeLimit: 2Gi}
将该清单保存为vllm-qwen.yaml，然后创建该工作负载：
kubectl apply -f vllm-qwen.yaml
查看清单
应用该工作负载后，你可以追踪其清单信息：
kubectl -n prod-jobs get aiboms.aibom.k8saibom.dev
示例输出：
NAME WORKLOAD NAME CATEGORY RUNTIME READY AGE apps-deployment-vllm-qwen Deployment vllm-qwen inference vllm True 28m
控制器自动对该工作负载的类别及服务运行时进行了分类。有一点值得注意：该记录是基于工作负载规格构建的，因此即便没有任何Pod实际运行，AIBOM也可能已经存在——它可能会在Pod仍在拉取镜像的过程中出现并报告Ready=True状态。AIBOM所反映的是声明的内容，以及（一旦Pod存在后）其最终解析的结果，但它并不能证明调度或执行的成功。
检查状态条件：
kubectl -n prod-jobs get aibom apps-deployment-vllm-qwen \ -o jsonpath='{range .status.conditions[*]}{.type}={.status} {end}' # Ready=True Synced=True SinkFailed=False Stale=False
验证AIBOM
当文档足够小时，会以内联方式存储在资源对象中，并附带基于规范字节计算的SHA-256校验值：
kubectl -n prod-jobs get aibom apps-deployment-vllm-qwen -o json > aibom.json jq -r '.status.bomDocument.inline.data' aibom.json | base64 -d > bom.json jq -r '.status.bomDocument.sha256' aibom.json shasum -a 256 bom.json | awk '{print }'
至此，一切整合在了一起：
jq -r '.components[] | "\(.type)\t\(.name)"' bom.json
输出结果大致如下：
application vllm container vllm/vllm-openai machine-learning-model Qwen/Qwen2.5-0.5B-Instruct
传统的软件物料清单（SBOM）只能告诉你正在运行哪个镜像，而AIBOM能够告诉你正在提供服务的是哪个模型，以及是由哪个运行时在提供服务。每项属性都带有四种置信等级之一——已声明、已推断、未解析或已验证，并附带证据定位信息，便于审查人员了解每项结论的判定依据。
资源影响
上游团队在配备NVIDIA Dynamo与AICR配置的GKE环境中，对k8s-aibom v1.6.1进行了实测。测试采用纯CPU节点，工作负载Pod保持挂起状态，因此以下数据反映的是控制器清点功能本身带来的开销：
在15分钟的稳态观测窗口内，平均每分钟约产生4次API服务器请求
控制器平均CPU使用率为2.2毫核
控制器内存工作集占用约为28至34 MiB
被测工作负载的镜像标签发生变化时，触发了一次AIBOM重新生成
未来展望
这项集成有意在几个方面留有余地，每一项都是经过深思熟虑的决定，而非疏漏。
签名的运行时观测记录：运行时AIBOM以Kubernetes资源的形式写入，但观测记录本身并未签名。签名可以使已捕获的观测记录具备防篡改特性，但并不能证明每一项工作负载声明均属真实，也无法确立执行是否成功。上文提到的规范字节与已发布的SHA-256值，为未来实现签名提供了可行基础。
关联已验证的来源信息：k8s-aibom能够依据运营方配置的信任根，对模型声明中的Sigstore签名进行验证，强制执行签名者身份约束，检查Rekor日志的收录情况，并为符合条件的声明赋予“已验证”置信等级。AICR默认禁用此项验证功能。在启用签名功能时，AICR同样能够生成具备透明日志记录的部署包认证；而将该平台来源信息与运行时AI清单相关联，仍是未来有待推进的集成工作。
部署意图与实际观测到的工作负载：AICR配方描述的是部署意图，而运行时AIBOM记录的是观测到的工作负载规格及可获取的Pod状态证据。要将二者相互关联，需要统一的构件身份标识、新鲜度规则，以及基础设施覆盖范围与工作负载覆盖范围之间的映射关系。这项比对工作仍有待未来推进；需要明确的是，AIBOM本身并不能证明执行成功或集群整体合规。
AICR已在NVIDIA/aicr开源发布，k8s-aibom已在GoogleCloudPlatform/k8s-aibom开源发布，二者均为开源项目。如果你正在Kubernetes上运行GPU工作负载，这项集成将为你提供受支持AI工作负载的清单信息，以及展示每项属性判定依据的证据记录。
