CNCF 云原生调查对 AI 推理基础设施的观察

AI 从训练走向推理后，基础设施问题已经不只是“模型能不能跑起来”，而是能否持续承载流量、观测质量并由团队稳定运营。CNCF 的年度云原生调查把 Kubernetes 的生产采用和生成式 AI 推理放进同一张图里，但阅读这类调查时，先分清调查对象和分母，比记住一个醒目的百分比更重要。

官方报告：https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/

CNCF 公开材料支持这样的判断：Kubernetes 已经成为许多生产容器环境的共同运行层，生成式 AI 推理也在进入云原生平台；但调查采用率不等于模型延迟、成本或准确率的承诺。

先把调查数字的口径分开

CNCF 2025 年度云原生调查的公开摘要给出两个容易被连写的数字：82% 指容器用户中已经在生产环境运行 Kubernetes 的比例；66% 指托管生成式 AI 的组织中，使用 Kubernetes 管理部分或全部推理工作负载的比例。它们回答的是两个不同问题，不能相乘、相加，也不能写成“82% 的组织都在用 Kubernetes 做 AI 推理”。

第一层事实是生产运行层已经相当普遍；第二层事实是生成式 AI 推理正在使用这层基础设施。由此可以观察到云原生和 AI 平台正在靠近，但仍不能从公开摘要推出每个组织的模型规模、GPU 利用率或服务等级。

Kubernetes 更像统一运行层，不是完整推理方案

把 Kubernetes 放进 AI 推理基础设施，最稳妥的理解是“提供统一的部署、调度和资源管理边界”。模型服务本身仍需要处理版本发布、请求排队、批处理、流量路由、观测和故障恢复。调查显示的是采用方向，工程团队还要补齐这些能力，才能把“能部署”推进到“可运营”。

CNCF 的后续材料也把服务网格、多集群管理和可观测性列为分布式推理场景中的重要基础设施关注点。它们解决的是不同层次的问题：流量路由决定请求如何到达模型服务，观测系统帮助发现延迟和错误变化，多集群管理则服务于环境隔离与跨集群调度。不要把这些能力混成 Kubernetes 自带的单一开关。

从调查观察落到平台检查项

如果团队正在把生成式 AI 推理放到云原生平台，可以按下面四层检查，而不是先追逐某个产品名称。

这份清单的重点是把事实和动作分开：调查可以帮助团队确认行业基础设施的共同方向，不能替团队完成容量规划、压测或服务等级设计。CNCF 关于中国云原生发展的报告还提到，云原生技术正在支持 AI 团队从训练走向生产推理；这更适合用来判断建设重点，而不是当作某个项目的上线证明。

哪些结论不能由调查直接推出

第一，采用 Kubernetes 不代表推理延迟一定更低。延迟还受到模型大小、硬件、批处理策略、网络和请求分布影响。第二，使用云原生平台不代表成本一定下降，资源隔离和多副本也可能带来额外开销。第三，调查没有替代模型效果评测，推理基础设施的可用性、成本和回答质量仍需分别测量。

因此，读者可以把 CNCF 调查当作一张“方向地图”：共同运行层正在形成，AI 推理正在进入生产基础设施议题，平台工程的职责会从部署扩展到流量、观测和协作。真正落地时，再用本组织的模型、硬件、流量和服务等级数据做决定，结论才不会被一个比例数字带偏。

相关问题

82% 和 66% 能不能直接比较？不能。它们来自不同调查对象，分别描述 Kubernetes 生产采用和生成式 AI 推理管理，分母不同。

Kubernetes 能不能单独完成 AI 推理平台建设？不能。它可以提供统一运行层，但模型服务、推理路由、观测和多集群治理仍需要额外设计。

这份调查能不能证明某个推理方案更省钱？不能。公开调查支持采用趋势判断，成本结论必须由具体模型、硬件和流量条件下的测量得出。

资料来源：https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/；https://www.cncf.io/reports/the-state-of-cloud-native-development-in-china-report/