当大家都在关注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——三个阶段对存储的要求如此不同指望一个统一方案覆盖所有场景可能从一开始就是错误的前提。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版