IBM把AI部署的坑踩了18个月，70%预算全花在GPU上

过去18个月，IBM坐在无数场企业预算会议里，记录了一个反复出现的畸形比例：GPU采购吃掉70%的讨论时间，模型选型占20%，而真正喂养这些模型的数据基础设施，只剩10分钟和一句"存储后面再说"。

这就是为什么大多数企业AI项目在概念验证后集体熄火。

概念验证的幻觉

一个典型场景：团队用精选数据集在开发环境跑通了检索增强生成（RAG）或微调流水线，模型表现亮眼。一旦接入生产数据规模，系统瞬间崩溃——不是模型错了，是存储层根本喂不饱数据，流水线无法跨混合环境统一数据源，也没人提前规划过AI工作负载的I/O特征。

AI训练和推理的存储画像与传统企业应用完全不同。训练任务需要跨海量数据集的持续顺序吞吐，推理需要低延迟随机读取，微调有时两者兼得。你那套跑ERP很稳的存储区域网络（SAN），面对试图饱和8块GPU的分布式训练任务会直接窒息。

IBM近期对"AI就绪基础设施"的重新定位抓住了要害：系统层——存储、计算架构、自动化——才是企业AI成败的分水岭，而非模型层。

数据引力陷阱

存储对AI的关键性不止于吞吐，更在于数据引力（Data Gravity）。

企业数据从不扎堆。它们散落在本地数据库、云对象存储、SaaS平台、边缘设备，以及某个没人敢碰的PostgreSQL实例里。IBM将企业AI定义为"AI在大型组织中的整合"——但整合的前提是数据可访问。现实中，大多数公司做不到，至少无法用统一且高性能的方式做到。

这引发级联故障。你的RAG流水线需要SAP的产品数据、Salesforce的客户交互记录、Confluence的技术文档。每个源有不同的访问模式、延迟特征、安全边界。用API调用和批量ETL任务拼凑，会引入数小时延迟，制造出脆弱的流水线——每次有人改个表结构就断裂。

IBM的观察是：成功部署企业AI的公司，优先解决的是这个问题。它们构建能服务多种AI工作负载的统一存储层，避免六种不同的集成模式。IBM的Storage Fusion和FlashSystem瞄准的正是这一点——高性能、统一存储，能处理混合环境下AI工作负载的混合I/O画像。无论你是否采用其技术栈，架构原则成立：若AI工作负载无法以统一、高性能的方式访问数据，模型再先进也是摆设。

被忽视的I/O现实

企业AI基础设施的讨论长期被算力霸权绑架。NVIDIA的财报数字、GPU集群的规模、模型参数量，这些构成了行业话语的显性部分。但IBM的实地记录显示，当预算会议把70%精力投入GPU时，真正决定项目生死的存储架构被压缩成"后面再说"的脚注。

这种失衡有其心理根源。GPU是可见的、可量化的、可向董事会展示的"AI投入"。存储则像水电——只有当停水停电时，人们才意识到它的存在。问题在于，AI工作负载的"停电"不是二进制的中断，而是性能衰减的慢性死亡：训练时间从预计的3天拖到3周，推理延迟从200毫秒涨到2秒，RAG检索从实时变成"等一下"。

这些衰减不会触发警报，只会慢慢消磨掉业务部门对AI项目的耐心。

IBM提出的"AI就绪基础设施"框架，本质上是对这种认知偏差的矫正。它将存储层重新定义为AI工作负载的调度中心，而非被动容器。具体而言，这意味着存储系统需要同时满足三种冲突需求：为训练提供高吞吐顺序读取，为推理提供低延迟随机访问，为数据准备提供高并发混合负载——且不能通过三套独立系统拼凑实现。

FlashSystem的架构设计反映了这种整合压力。其硬件层针对NVMe协议优化，软件层通过Storage Fusion提供跨本地、多云、边缘环境的统一数据平面。技术细节不是重点，关键是IBM试图解决的问题：当企业数据被引力撕裂成孤岛时，如何让AI流水线无视物理位置，以一致的性能特征访问数据。

这解释了为什么"数据基础设施"在预算会议里只配10分钟——它不是一个产品，而是一组需要重新谈判的组织边界。统一存储意味着打破数据库团队、云团队、安全团队各自的领地意识。GPU采购是写支票，存储整合是改流程。后者阻力更大，回报周期更长，在季度财报压力下天然处于劣势。

但IBM的18个月观察记录表明，跳过这一步的企业，最终会在概念验证后陷入"试点炼狱"：项目活着，但无法扩展；模型存在，但无法接入生产数据；预算花了，但业务价值无法兑现。这不是技术失败，是基础设施债务的到期偿付。

当下一波预算会议召开，70-20-10的比例会改变吗——还是说，我们注定要重复同样的分配错误，直到足够多的项目死在同一个坑里？