NVIDIA 首席云架构师 Mark Chmarny：AICR 验证配置、k8s-aibom 追踪工作负载，两者边界才是 AI 治理缺口
NVIDIA 首席云架构师 Mark Chmarny 解释 AICR 与 Google 开源项目 k8s-aibom 的集成：前者回答 GPU 基础设施是否来自已知且经过验证的配置，后者回答该基础设施上实际运行着什么 AI 资产。两者各自都不足以支撑 AI 治理，而它们之间的边界恰恰是当前问责缺失之处。
当团队使用 NVIDIA Dynamo、Kubeflow 或 Slurm 部署 AI 工作负载时，一个可复现的部署包并不能告诉你集群上实际运行着什么。应用团队独立于平台配方定义和更新工作负载，可变镜像标签如 :latest 更让同一标签下两台节点可能运行不同代码。NVIDIA 首席云架构师 Mark Chmarny 在 NVIDIA 技术博客中解释了这一缺口如何通过集成 Google 开源项目 k8s-aibom 来闭合。
Chmarny 将两个系统描述为同一问题的两端。AICR 在运行时部署层工作——驱动、算子、内核、Kubernetes 组件、部署配置——它回答的是：GPU 基础设施是否来自已知且经过验证的配置？k8s-aibom 则站在栈的更高层、集群生命周期的更后段，它观察 Kubernetes 工作负载和 Pod API，为每个被识别的 AI 工作负载生成一份 CycloneDX 1.6 AIBOM 记录，回答的是：该基础设施上实际运行着什么 AI 资产？
Chmarny 指出，两者都不足以单独支撑 AI 治理，而它们之间的边界正是当前问责缺失的地方。AICR 记录经过验证的部署意图并在某一时刻与集群对照；k8s-aibom 观察支持的工作负载并记录发现了什么，包括每个属性以何种置信度被确定。前者提供控制与可复现性，后者提供工作负载发现与可追溯性。
具体而言，AIBOM 帮助团队发现选定命名空间中未注册或影子 AI 工作负载、识别模型与推理运行时、追踪外部 AI API 与向量数据库、检测 AI 依赖的变更或漂移，并支撑安全审查、事件响应与合规审计。
集成方式是将 k8s-aibom 作为 AICR 配方中的一个合格组件。两个标准配方默认选择它：h100-gke-cos-inference 和 h100-gke-cos-inference-dynamo；其他 GKE 配方在生成时可通过 --runtime-inventory 标志加入。Chmarny 强调，合格化不是走过场：AICR 将上游源码、chart、CRD 和摘要锁定的控制器镜像绑定为一组经过测试的配置，对照 Google 的预期构建身份验证来源，审查渲染后的 RBAC 与安全默认值，并在已测试的部署路径上执行安装、升级、健康检查和卸载。
以 AICR v1.2.0 锁定 k8s-aibom 1.6.2 为例，工作流从生成配方开始，经打包、部署到验证，全程无需手工组装或手工调参。部署后 k8s-aibom 控制器在 k8s-aibom-system 命名空间运行，验证阶段要求控制器可用、集群级 AIBOMControllerConfig 报告 Ready=True、两个 CRD 报告固定 chart 期望的存储版本。
命名空间通过标签 aibom.k8saibom.dev/enabled=true 选择加入。Chmarny 特别说明，标签控制哪些命名空间发出 AIBOM 记录，但不缩小控制器读取范围——信息器仍缓存集群范围的工作负载和 Pod 规格，包括容器参数和内联环境变量。默认不配置任何 sink 和密钥访问，因此没有显式决定则没有任何数据离开集群。
资源影响方面，上游在 GKE 上使用 NVIDIA Dynamo 和 AICR 配置测量了 k8s-aibom v1.6.1。测试使用 CPU-only 节点且工作负载 Pod 保持 pending 状态，因此这些数字描述的是控制器清单开销：约每分钟四次 API 服务器请求、平均控制器 CPU 用量 2.2 毫核、控制器内存工作集 28 至 34 MiB。
Chmarny 也明确了集成刻意止步之处。运行时 AIBOM 写入为 Kubernetes 资源，但观察本身未签名；签名可使捕获的观察具有防篡改证据，但不能证明每个工作负载声明为真或确立成功执行。k8s-aibom 能够验证 Sigstore 签名、执行签名者身份约束、检查 Rekor 包含并赋予合格声明 verified 置信度，但 AICR 默认关闭此验证。将平台来源与运行时 AI 清单关联仍是未来集成工作。