CNCF 云原生 AI 应用怎样划分平台与业务边界

云原生 AI 应用最容易出现的架构问题，不是 Kubernetes 能不能运行模型，而是“谁应该负责什么”没有先说清楚。CNCF 的近期资料把资源调度、模型交付、推理路由和观测都视为平台能力，但业务团队仍然应该拥有业务目标、提示词策略、用户体验和结果解释。把两者混在一起，平台会变成一个只服务单个应用的后台；拆得过度，又会让每个业务团队重复搭建 GPU、网关和监控。

官方入口：https://www.cncf.io/

比较稳妥的分法是三层：业务团队决定“为什么调用模型、如何使用结果”；AI 平台团队提供“怎样安全、可重复地调用模型”；基础设施团队保证“计算、网络、存储和集群怎样稳定运行”。平台暴露能力契约，业务提交意图，不直接把业务规则写进平台控制器。

先把边界画成三层：业务、平台与基础设施

第一层是业务责任，包括面向用户的 API、领域规则、提示词或 Agent 策略、结果兜底和人工确认。这里的代码变化通常跟产品需求走，不能因为平台提供了一个模型端点，就把业务判断下沉到平台。

第二层是 AI 平台能力，包括黄金路径、模型登记、推理网关、资源请求、策略、审计和统一遥测。它们的目标是让多个业务团队以相似方式使用模型，不要求每个团队理解 GPU 拓扑、队列或模型服务器的细节。

第三层是基础设施，包括 Kubernetes 集群、加速器、对象存储、网络、节点生命周期和容量管理。基础设施团队关注可用容量、隔离、升级和恢复，不替业务选择提示词，也不决定某个用户请求的产品结果。

这种划分并不是把团队切成三堵墙。业务 API 依赖平台提供的模型端点，平台又依赖基础设施提供的调度和存储；关键在于依赖通过稳定契约连接，而不是通过共享内部实现连接。

平台托管的是重复能力，不是业务判断

判断一项能力应不应该进入 AI 平台，可以先问两个问题：它是否会被多个业务复用？它是否需要统一的可靠性、安全或成本控制？如果答案都是“是”，通常适合平台化。

例如，平台可以提供模型端点的标准声明、推理流量路由、模型与硬件的匹配、队列和限额、OpenTelemetry 采集、身份策略以及回滚接口。CNCF 资料提到，AI 工作负载的观测不能只看 CPU、内存和请求延迟，还要结合加速器利用率、排队时间、模型加载时间和吞吐；这些都是跨业务可复用的运行能力。

相反，客户分层、内容模板、推荐排序、人工审核阈值和“低置信度时如何解释”属于业务决策。平台可以提供策略钩子和审计字段，但不应该在通用控制器里写死这些规则。Kubernetes Operator 的思路也适合这里：控制器负责把声明的目标状态持续协调成运行状态，而不是替应用拥有领域知识。

把模型生命周期接入平台，而不是只发布容器

传统流水线常写成“代码—构建—测试—部署”。AI 应用至少还要把模型制品、运行配置和评估结果纳入同一组可追溯关系。模型文件放在哪里并不等于模型已经可发布；还需要记录它对应的代码版本、推理运行时、硬件要求、配置和评估结论。

落地时可以把平台契约收敛为四类对象：

• 工作负载声明：业务只描述模型、流量形态、延迟目标和资源偏好，不直接绑定节点名称。
• 模型制品：平台记录版本、摘要、运行时和评估入口，业务维护模型是否适合自己的场景。
• 交付策略：平台提供灰度、回滚、限额和审计；业务决定哪些用户或流量可以进入新版本。
• 运行反馈：平台统一采集队列、首 token 时间、吞吐、错误和成本维度，业务将其解释为产品指标。

这也是为什么 CNCF 生态会同时出现 DRA、Inference Gateway、Kueue、OpenTelemetry 和面向分布式推理的项目：它们分别解决资源、路由、排队、观测和推理编排问题，而不是替代业务应用本身。

两个反例：平台过厚和业务过薄

平台过厚：平台团队为了“统一体验”，把客户权限、提示词模板、领域数据清洗和结果审核全部塞进一个 AI 门面。新业务上线看似很快，但任何领域规则变化都要排平台版本；故障发生时也难以区分模型、平台和业务责任。

业务过薄：每个业务团队自己申请 GPU、复制模型服务器、单独接入网关和监控，只在名称上使用 Kubernetes。短期可以快速试验，长期会出现重复的资源闲置、路由规则和安全补丁，模型发布也无法形成统一审计。

更好的折中是“平台给能力，业务做选择”：平台提供有限而清晰的黄金路径，允许业务通过参数和扩展点表达差异；对尚未稳定的研究型工作负载保留实验区，不要一开始就把所有探索强行纳入生产平台。

用四个问题检查边界是否合理

1. 这项规则变化时，应该由产品或领域团队发布，还是由平台团队发布？如果答案总是平台，说明平台可能承载了业务知识。
2. 换一个模型、加一种加速器或迁移集群时，业务代码是否仍然只面对稳定契约？如果不能，基础设施细节泄漏了。
3. 故障指标能否区分业务错误、模型质量、平台路由和基础设施容量？如果所有问题都只显示“接口超时”，观测边界还不完整。
4. 平台能力是否被两个以上业务复用，并且有明确的权限、成本和回滚责任？没有复用和责任的“平台功能”，很可能只是一次性项目代码。

最终可以把边界压缩成一句话：业务团队负责结果如何服务用户，AI 平台负责结果如何被稳定地生产，基础设施团队负责生产所需的资源如何可靠地存在。这个分法既符合云原生的声明式和可观测原则，也给模型、硬件和业务变化留下了各自的演进空间。

相关问题

平台团队需要管理每个模型的提示词吗？

通常不需要。平台应提供版本、权限、审计和调用策略的承载能力；提示词是否符合某个业务场景，应由业务或领域团队维护。

AI 应用一定要拆成独立的 AI 平台吗？

不一定。只有当模型服务、资源调度、交付、观测和策略出现跨团队复用时，独立平台才有明显价值。单一团队的早期原型可以保持更薄的结构。

资料入口

CNCF AI 平台文章：https://www.cncf.io/blog/2026/08/28/your-kubernetes-platform-is-ready-for-containers-is-it-ready-for-ai/

CNCF 云原生 AI 工程：https://www.cncf.io/blog/2026/03/26/the-platform-under-the-model-how-cloud-native-powers-ai-engineering-in-production/

Kubernetes Operator：https://kubernetes.io/docs/concepts/extend-kubernetes/operator/