AI训练最容易被忽视的瓶颈：数据存储

数据中心存储基础设施场景

当大家都在关注GPU算力、模型架构、训练框架的时候，一个不太起眼但实际影响巨大的问题正在浮现：数据存储。

把AI负载搬到云原生基础设施上，最直接的挑战不是计算资源不够，而是数据喂不进去。传统为微服务优化存储架构，在面对需要把大规模数据集喂给并行GPU的训练场景时，暴露出明显的短板。

CNCF（云原生计算基金会）基础设施技术咨询组最近发布了一份白皮书，专门分析这个被低估的问题。

AI负载的三个存储阶段

白皮书把AI工作负载的存储需求拆成了三个阶段，每个阶段对存储的要求完全不同。

第一个阶段是高吞吐训练期。这个阶段的核心是最大化GPU利用率。存储需要承受非顺序访问（数据打乱导致的随机读取），以及在checkpoint时出现的同步大规模写入突发。这其实是对存储系统最严苛的场景——需要持续高带宽的同时，还要应对突发的写入高峰。

第二个阶段是低延迟推理期。模型部署上线后，流量模式变得不可预测，模型加载速度成为瓶颈。生产环境中越来越多地依赖KV缓存和前缀缓存来消除重复计算——这些机制对存储延迟极其敏感。

第三个阶段是AI Agent的闭环推理期。这是一个更复杂的场景。Agent需要短期记忆（可变状态追踪和只追加事件日志）、工件仓库（中间代码和媒体文件），以及长期记忆（跨会话信息的持久化）。这些存储需求的特征完全不同，很难用一个统一的存储方案来满足。

传统存储架构在AI场景下遇到的问题，不是简单的容量不足。真正的瓶颈在于带宽和访问模式的不匹配。

训练一个大型语言模型时，数据加载器需要以极高的吞吐量读取训练样本，同时频繁进行随机打乱。这对存储系统提出了"既要高带宽、又要低延迟随机访问"的复合要求——而传统分布式存储系统往往在两个方向上都有妥协。

另一个容易被忽视的点是checkpoint。在一个训练任务中，GPU集群可能每几分钟就同步一次checkpoint，写入几百GB甚至TB级别的模型状态。这个写入峰值对存储系统的压力，远大于稳态的数据读取。如果checkpoint写入时间过长，GPU会处于空闲等待状态——算力浪费就这么产生了。

CNCF这份白皮书的意义不在于技术突破——它没有提出新的存储方案——而在于它把"数据存储"这个被边缘化的问题拉到了台前。

过去几年，AI基础设施的讨论几乎被"GPU供不应求"和"模型越来越大"两个话题主导。但实际部署过AI系统的人都知道，很多时候卡住模型训练的不是GPU不够，而是数据流水线跟不上。训练数据预处理、分布式缓存、checkpoint I/O优化——这些环节的优化空间，可能比换个更强的模型架构更实在。

白皮书中还提到了一个被低估的变化：AI Agent的出现正在重塑存储需求。以往的存储讨论围绕"训练"和"推理"两个场景展开，但Agent的闭环推理模式引入了全新的存储特征——状态需要持久化、会话需要追踪、中间产物需要管理。这些需求在未来几年只会越来越突出。

对正在搭建AI基础设施的团队来说，一个值得思考的问题不是"要不要用分布式存储"，而是"不同阶段的AI工作负载，需要什么样的存储方案"。训练、推理、Agent——三个阶段对存储的要求如此不同，指望一个统一方案覆盖所有场景，可能从一开始就是错误的前提。

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。