GPU 平台验证补上运行时清单：AICR 默认纳入 k8s-aibom，看清节点上真正跑着什么
核心概要
NVIDIA 的开源组件 AICR 现在把 Google 的 k8s-aibom 作为受验证组件纳入配方，让 GPU 加速的 Kubernetes 平台在部署已知良好配置的同时，记录集群里实际运行的 AI 工作负载。此前配方只能固定平台配置，应用团队自行更新的工作负载和 :latest 这类可变镜像标签可能让两个节点在同一标签下跑不同代码。两个 GKE 配方默认选中该组件，其余配方可在生成时开启。
深度剖析
GPU 平台的部署配方现在可以同时携带一份运行时 AI 清单，回答集群里实际运行哪些 AI 资产，而不只是基础设施是否按已验证配置搭好。 此前配方记录的是平台配置，应用团队独立定义和更新工作负载，因此可复现的部署包本身无法确定每个节点上运行的是哪些工作负载产物。 两个现成配方 h100-gke-cos-inference 和 h100-gke-cos-inference-dynamo 默认选中 k8s-aibom，其他 GKE 配方可在生成时用 --runtime-inventory enabled 选择加入，已选中的配方可用 --runtime-inventory disabled 退出。
清单组件在集群内观察受支持的工作负载，并为每个识别出的 AI 工作负载输出一份 CycloneDX 1.6 AIBOM。 k8s-aibom 站在比 AICR 更高的栈层、更晚的生命周期位置：AICR 管驱动、算子、内核和 Kubernetes 组件等运行时部署层，k8s-aibom 观察工作负载与 Pod API。 覆盖范围包括原生 Dynamo 图、NIMService、LeaderWorkerSet、DisaggregatedSet 和 CronJob 资源，被跟踪的子工作负载合并进其属主的 AIBOM；示例中 vLLM 部署被自动归类为 inference 类别、vllm 运行时，清单列出 vllm 应用、vllm/vllm-openai 容器和 Qwen/Qwen2.5-0.5B-Instruct 模型。
AICR 对 k8s-aibom 的资格认定是一组具体检查，而不是盖章放行。 资格认定把确切的上游源码、chart、CRD 和按摘要固定的控制器镜像绑定为一个受测集合。 检查包括对照 Google 预期构建身份核验来源、审查渲染后的 RBAC 与安全默认值，并在其测试过的部署路径上演练安装、升级、健康检查与卸载。
启示与展望
演示流程面向在 GKE 上运行 Kubernetes 1.32 或更高版本、使用 H100 GPU 节点与 Container-Optimized OS、由 GKE 管理驱动和设备插件的读者，示例对应 AICR v1.2.0 及其固定 k8s-aibom 1.6.2 的目录。清单按命名空间选择加入，只有携带可识别 AI 信号的受支持工作负载类型才会被记录。
运行时 AIBOM 作为 Kubernetes 资源写入，但观察本身未签名；签名只能让捕获的观察防篡改，不能证明每条工作负载声明为真或执行成功。AICR 默认关闭 Sigstore 签名验证，把平台来源与运行时 AI 清单连接起来仍是后续集成工作，把配方意图与观察到的负载关联同样如此。清单由工作负载规格构建，Pod 尚在拉取镜像时也可能已出现并报告 Ready=True。