推理GPU利用率上不去？问题可能不在卡，而在存储——AI推理存储选型指南

2026-08-01 1 暗号导航联盟

AI推理存储别只看带宽，延迟稳不稳才是关键？

就在这过去的两年当中, 每当聊起AI存储的时候, 我的脑袋里面充斥的全都是训练方面的内容: 具备高吞吐的特性, 拥有大带宽的条件, 能够实现GB/s级别的读取速度。然而推理呢? 它根本呈现出一种截然不同的逻辑状况。要是使用训练所对应的指标去套用在推理上面, 把容量配置得极为充足, 可是一旦上线运行就会卡顿得如同播放PPT一般——关于这样的深坑, 踩过的人数量着实不少。

企业在规划AI基建之际, 算力方面抠得极为严格, 而存储常常被简化为仅仅一个“TB数”。然而, 真正投入使用之后才明白: 推理所要求的是“稳得住”, 并非“喂得快”。模型加载属于大块顺序读, 处理请求呈现小粒度随机I/O, 并且还叠加了扩容瞬间多节点一同齐刷刷读同一文件的热点压力。仅从单一维度去看待性能, 那纯粹就是如同盲人摸象一般。

推理GPU利用率上不去？问题可能不在卡，而在存储——AI推理存储选型指南_推理GPU利用率上不去？问题可能不在卡，而在存储——AI推理存储选型指南_

ZBS的5.5.6这个版本直接对数据面进行重构, 将传统文件系统的依赖予以弱化, 使得I/O能够更靠近原生块设备。这是为什么呢? 原因在于在线进行推理和数据库以及VDI这些负载都存在非常高的共性, 也就是对低延迟敏感, 有着长期持续运行的特点, 是不能出现抖动的。其默认设置为三副本, 在分布方面会考虑故障域、考虑网络拓扑、考虑介质类型, 以此来规避同置风险；副本重建以及再平衡是在后台自动运行的, 与此同时内置了QoS去调控节奏, 在出现故障的时候服务不会中断, 在恢复期体验的情况也不会出现劣化。

白天的时候进行在线推理, 夜间开展微调批量任务, 算力实现了错峰, 然而存储I/O并不会自动跟着进行调整。微调写入以及批量写结果, 均属于大块连续的写入操作, 要是不加以隔离, 在线推理就只能默默承受不利情况。ZBS借助确定性I/O保障, 使得在线业务不受到干扰。副本策略十分灵活, 生产推荐设置三副本, 测试以及边缘场景支持两副本, 并且还能够在线无感地进行变配, 业务实现零中断。存储策略无需从一开始就固定下来, 依据业务等级动态调整即可。

需求增长呈现出并非线性的状况, 当进行一次模型的升级, 或者接入新的业务时, 容量有出现突然跃升的可能性。ZBS能够支持在运行时进行动态添加节点的操作, 还有自动再平衡以及QoS调控迁移这般的功能, 使得业务不会产生感知。处于超融合架构的情形下, 存储以及计算是共用节点的, 这种情况下成本比较低, 延迟又是小的, 适用于制造业质检识别这类厂区方面进行本地部署的场景；而分离式架构是将存储计算进行解耦的, 它支持RoCE高速网络以及精细化的QoS, 在大规模I/O密集型推理这点上更相适宜。到底该如何去选择呢? 需要看GPU节点以及存储容量是不是会实现同步的增长, 如果是匹配这样的情况, 那么超融合会更加高效。

当AI应用从PoC迈向量产阶段, 存储已不再是单纯关于容量的数字游戏, 而是成为决定推理体验的基础设施。按照训练思维来进行推理存储, 所带来的代价便是预算出现错配, 即带宽达到要求了, 然而延迟稳定性却丧失了。选型的本质实际上是包含三个务实的判断, 分别是需要什么, 也就是要兼顾两类I/O、稳态性能以及故障不停；还要看多久, 即在峰值性能之外更要对长期表现展开评估。如果正在规划推理平台或者进行全闪存升级, 那就联系区域团队去获取定制化方案, 千万不要让存储阻碍了推理的发展。