CNCF AI Conformance Program解决兼容性什么问题

CNCF AI Conformance Program 更准确的名称是 Certified Kubernetes AI Conformance Program。它解决的不是“某个模型回答得准不准”，而是同一类训练、推理和 Agent 工作负载换到不同 Kubernetes 平台后，底层加速器、调度、网络、观测、安全与运维能力不一致的问题。我的判断是：它提供了平台兼容性基线，能减少“在甲云能跑、到乙云就要重写一遍”的适配工作，但不能替代模型质量、数据正确性和业务流程验收。

官方项目地址：https://github.com/cncf/k8s-ai-conformance

它先保护的是平台能力，不是模型结果

我第一次拆这个问题时，最容易混淆的是“兼容”两个字。CNCF 官方把计划定位为运行 AI/ML 工作负载所需的能力与配置基线，覆盖训练、推理和 Agent 场景。换句话说，它关注的是平台是否能以约定方式提供资源、调度和隔离能力，而不是规定模型必须使用哪家云、哪种推理框架或哪套业务数据。

因此可以把兼容性分成三层：

所以它最适合拿来做供应商筛选、跨云迁移的前置门槛和平台团队的内部基线，而不是把认证徽章当成上线批准单。

从攻击路径看，最值得优先排查哪些差异

安全威胁建模的思路在这里很有用：先看资产，再看差异如何变成故障或越权路径。比如加速器访问不一致，会让同一推理服务在一个平台启动、另一个平台长期 Pending；Gang Scheduling 或拓扑放置不一致，会让分布式训练出现资源已分配但无法协同的状态；网络、观测或隔离能力缺失，则会把慢请求、数据外泄和异常定位变成平台迁移后的隐性成本。

我会按下面顺序排查，而不是先比较厂商宣传页：

1. 资源路径：确认 GPU/其他加速器的发现、分配、隔离和回收是否一致。
2. 调度路径：确认队列、Gang Scheduling、拓扑感知和自动扩缩容的适用条件。
3. 服务路径：确认推理流量、网络策略、超时和观测指标能否被统一解释。
4. 安全路径：确认凭据、命名空间、节点和工作负载之间的边界不会因平台实现而变弱。

这份顺序的价值在于把“兼容性问题”变成能复现的证据：作业为什么未调度、哪个能力缺失、影响哪类工作负载，以及迁移时是否有替代控制。

认证材料怎样把自评变成可复查证据

当前项目要求平台先具备 Kubernetes Conformance，再针对匹配的 Kubernetes 版本填写 AI Conformance 清单。仓库说明的流程是准备、文档与测试、提交 Pull Request、社区审核；对 Kubernetes v1.37 及以后，适合自动化验证的要求建议运行上游测试，并提交 e2e.log、junit.xml 或 results.json，没有自动化测试的要求继续用公开文档或参考 URL 做人工证明。

一个精简的证据记录可以长这样，重点是让审阅者能从状态回到证据，而不是只写“平台支持”：

requirements:
  secure_accelerator_access:
    # 状态必须和真实测试或公开文档保持一致。
    status: "Yes"
    evidence:
      - "artifacts/results.json"
      - "public documentation URL for accelerator isolation"
    notes: "说明节点、工作负载和租户隔离范围"

上面的字段只是形状示意，提交时应换成自己的公开证据，不能把占位文字当成认证材料。每个 MUST 要求都要有状态、证据和必要备注；如果某项是条件要求，也要说明为何适用或不适用。

版本和配置边界决定认证能不能复用

这个计划最容易被误读成“一次认证，所有环境通用”。项目文档明确提醒，认证按产品和配置区分，例如云上与离线环境不能自动互相继承；认证也有有效期，并跟随 Kubernetes 发布周期更新。实际采用时，我会把 kubernetesVersion、平台版本、硬件池、网络模式、是否离线和多租户策略一起写入平台台账。

如果团队正在做多云迁移，先选与目标集群版本匹配的清单，再做三组验证：认证覆盖的基础能力、业务实际使用的驱动与框架组合、迁移后才会出现的延迟和成本边界。三组都通过，才可以把“平台兼容”升级为“业务可迁移”。

什么时候值得采用，什么时候只借鉴清单

有多个平台、需要向客户展示统一基线，或平台团队经常为同一类 AI 作业重复写适配层时，正式参与的收益比较明确。若只是单集群实验、没有迁移计划，直接借鉴要求分类和证据字段，可能比追求认证更划算。无论哪种选择，都不要跳过业务回归：模型输出、数据血缘、权限策略、SLO、成本和灾备都不在一枚 conformance 标记里。

最后可以用五个问题收口：平台是否先通过 Kubernetes Conformance？目标版本是否匹配？每个 MUST 是否有证据？自动化产物能否复跑？认证之外的模型与业务测试是否单独留档？这五问都能回答，CNCF AI Conformance Program 才真正从新闻名词变成了迁移和采购时可使用的工程工具。

常见问题

AI Conformance 能保证同一个模型在所有平台输出一致吗？

不能。它约束的是平台能力和配置基线，模型版本、驱动、算子、随机性、数据和业务代码仍可能导致结果不同。

已有 Kubernetes Conformance，是否自动具备 AI Conformance？

不是。AI Conformance 建立在基础 Kubernetes Conformance 之上，还需要按目标版本完成 AI 清单、证据和适用的测试材料。

自建平台没有自动化测试怎么办？

对尚未覆盖自动化测试的要求，可以按项目说明提供公开文档或参考 URL；同时把测试环境、配置和复查步骤保存下来，避免只有口头自评。