CNCF白皮书：数据存储仍是云原生AI大规模落地的主要瓶颈

CNCF TAG Infrastructure发布了题为「Data Storage in Cloud Native AI」的白皮书——这是一份无任何单一厂商赞助的社区撰写文档。项目内部工作名称为「Data On Kubernetes – Data Analytics and AI/ML Workloads」，更准确地描述了其实践焦点：当AI工作负载流经Kubernetes时，数据存储的表现如何？

文档给出的答案并不乐观。针对标准微服务优化的传统存储架构，在面对向并行化、高性能GPU硬件基础设施供给海量数据的任务时，表现出严重的局限性。

三大核心瓶颈是什么？

文档识别了云原生AI基础设施要在规模上运行必须解决的三个系统性障碍。

小文件问题可能是最具挑战性的。训练数据集通常包含数百万个小文件——图像、音频片段、文本文档。每个文件都需要单独的元数据操作。数百万次此类操作的聚合给元数据服务器带来巨大负载，导致GPU节点等待数据而非执行计算。GPU利用率下降，成本上升，生产效率停滞。

计算与存储分离的瓶颈是第二个系统性挑战。计算与存储资源的分离是云原生环境的基本架构原则——对标准工作负载通常运行良好。但对于AI训练和推理，每次访问远程数据产生的API开销积累为可见的性能损失，并降低了昂贵加速器的利用率。

不同阶段的差异化需求是第三个瓶颈，本质上是组织层面的：训练、推理和智能体AI对存储有根本不同的需求特征，单一方法无法最优服务所有三个阶段。

AI生命周期的三个阶段及其不同需求

白皮书围绕需要独立架构考量的三个阶段构建了云原生AI存储框架。

训练阶段主要需要高吞吐量。系统必须能够持续、顺序地向GPU集群交付海量数据，并高效管理支持训练中断后恢复的检查点。Apache Parquet格式因其列式读取和压缩能力在此阶段占主导地位。

推理阶段将重点放在延迟上。请求以突发方式到达——流量并不均匀——模型必须快速可用。KV缓存和模型快速加载变得至关重要。作为表格格式的Apache Iceberg带来的时间旅行和模式演进对模型版本管理很有价值。

智能体AI呈现最复杂的需求。执行迭代推理循环的智能体需要结合会话内活跃上下文的短期记忆和跨会话持久知识的长期记忆。此外还会生成中间结果、参考资料、规划步骤等制品，这些都需要存储和检索。向量数据库在此发挥关键作用，Milvus作为大规模高效向量搜索的开源解决方案受到特别关注。

关键技术与CNCF项目

文档梳理了解决已识别瓶颈的技术生态系统。CSI（容器存储接口）和COSI（容器对象存储接口）标准化了Kubernetes工作负载访问存储的方式，独立于具体厂商。

活跃的CNCF项目Fluid实现了分布式缓存层，使数据更接近积极使用它的计算节点。这直接解决了计算与存储分离的开销问题——数据在使用它的节点上本地缓存。对于流式和事件驱动的流水线架构，Apache Kafka仍是参考实现。

为什么这与平台工程师相关

白皮书不是学术文档——它是面向今天正在做Kubernetes集群AI工作负载架构决策团队的实践参考。指南具体且可操作：针对每种用例选择哪种数据格式、如何组织缓存层、集成哪些CNCF项目。

无厂商赞助的社区撰写方式赋予了文档营销白皮书所缺乏的可信度。CNCF TAG Infrastructure邀请社区参与进一步发展——审阅PDF、参与TAG Infrastructure章程讨论以及#tag-infrastructure Slack频道。