AI推理平台存储怎么选？别让训练的带宽指标，拖垮推理的响应速度

别按训练的逻辑规划推理存储——AI推理场景的存储选型与ZStone ZBS能力解析

关于 AI 存储的讨论，这两年几乎都是围着训练展开的：高吞吐、大带宽、并行文件系统、GB/s 的读取速率。这些指标塑造了大多数人对"AI 存储"的印象。

但企业真正先落地的，往往不是训练。绝大部分企业不会从头预训练一个模型，它们做的是把成熟模型部署起来对外提供服务，先跑通推理，再逐步做微调。也就是说，行业在按训练的标准讨论AI存储，而企业先要解决的是推理的存储。两者要的并不是同一套东西——沿着训练的指标去规划推理集群的存储，很容易出现容量买够了、特性买错了的情况。

差别在哪里？训练关注"喂得快"：多个 GPU 节点并行读取同一批数据集，需要高吞吐与大带宽，单次读取慢一点，影响的是训练周期这个时间成本，是可以摊在夜里消化的。推理关注"稳不稳"：它是在线业务，模型加载、并发请求处理、结果写入都发生在用户等待的链路上——延迟抖动一次，传导出去是一次响应变慢；存储故障一次，传导出去是一次业务中断。带宽指标再漂亮，也不能替一次延迟毛刺兜底。

这个错位在现场是有具体表现的。推理服务上线之后，GPU 利用率始终上不去，排查一圈，调度没问题、切分没问题，问题出在存储——模型加载耗时偏长，并发请求上来之后 I/O 延迟开始抖动。卡不是算不动，是在等数据。这类问题在客户现场遇到过不止一次，根子常常不在容量，而在响应稳不稳。企业规划 AI 基础设施时，算力的账通常算得很细，存储却被简化成一个容量数字。

按推理自己的逻辑，存储要满足的是三件事：两种I/O都要照顾到，模型加载的大块读和请求处理的小 I/O 各有各的要求；性能要稳，集群长期运行、容量到高水位之后不掉速；故障不中断业务，磁盘或节点出问题时推理服务要能继续对外提供。

ZStone ZBS 是 ZStack 自研的高性能分布式块存储，基于分布式架构、RDMA/TCP 双栈、智能数据布局与 Raft 一致性构建，面向虚拟化、数据库、云平台等业务提供块存储底座。下面按这三件事，看它在推理场景里各自对应什么能力。

训练比的是带宽，推理要的是两种I/O都稳

推理服务的存储 I/O 其实是两种形态。一种是模型加载：服务启动、实例扩容、模型版本更新时，要把几 GB 到几十 GB 的模型文件读进显存，是典型的大块顺序读，考验带宽。另一种是请求处理与结果写入：持续、密集的小 I/O，考验延迟。

这两种形态还会叠加出一个特有的压力点——推理服务扩容时，新拉起的多个实例往往同时读取同一份模型文件，请求集中落在同一批数据上，形成热点。而扩容通常发生在业务高峰将至的时刻，此时存储如果被热点拖住，扩容速度和在线响应会同时受影响。

ZBS 对这两类 I/O 分别有对应的处理。大块 I/O 按条带化方式拆分到多个分片，利用多节点并行提升吞吐；智能数据布局会识别热点数据并动态再分布，避免请求集中压在单个节点上；客户端可直接访问数据所在的节点，少一次转发就少一段延迟；RDMA/TCP 双栈让关键数据传输走 RDMA 降低延迟，链路异常时自动切回 TCP，上层业务几乎无感。

比单次性能更需要关注的是长期表现。推理平台会持续沉淀数据——模型版本累积、推理日志与结果数据增长，集群容量水位只升不降。存储在空盘、低负载时的表现，与进入高水位、高并发写入之后往往不是一回事——性能开始抖动、下滑。ZBS 5.5.6 默认采用新一代存储引擎，改进了数据面的存储路径，让数据访问更贴近块设备模型，减少对传统文件系统数据路径的依赖，缩短关键 I/O 链路；同时面向 SSD 的使用特性做了优化，减少无谓写入和空间压力带来的性能下降。版本验证显示，满盘稳态 I/O 性能提升约 60%。

需要说明的是，5.5.6 这一版的优化目标业务是数据库、在线交易、虚拟桌面和云主机——推理服务与这几类负载属于同一种特征：在线、延迟敏感、长期运行，因此这些针对稳态性能的改进，在推理场景中同样成立。对推理服务而言，它意味着集群进入高水位之后，响应延迟依然可预期，而不是随着数据沉淀逐月劣化。

 

计算侧的多实例冗余，覆盖不了存储侧的故障

推理服务通常以多实例部署在多个 GPU 节点上，计算侧的冗余到这里看起来已经足够。但这些实例读的是同一份底层存储——计算侧的冗余覆盖不了存储侧的故障，存储一旦不可用，所有推理实例会一起失效。而推理和训练在容错上的差别很直接：训练中断可以从检查点重跑，推理中断，用户当场就感知到。

ZBS 依托分布式架构与多副本机制保障业务连续。故障检测覆盖网络、磁盘、节点多个层级，通过心跳与性能监控综合判断，一旦发现异常立即隔离受影响的组件，尽可能缩小影响范围；数据默认采用三副本，副本放置会考虑故障域、网络拓扑与存储介质特性，避免副本集中在同一风险域；后台定期进行数据完整性检查，配合 CRC 等校验算法，发现不一致时自动触发修复。

还有一个容易被忽略的环节：故障之后的恢复过程本身也会影响推理体验。副本重建要搬运大量数据，如果和前台业务抢 I/O，推理延迟一样会抖。ZBS 的副本重建与数据再平衡在后台自动完成，并使用 QoS 算法控制迁移节奏，尽量减少对前台业务的冲击——故障发生时业务不中断，故障恢复时体验也不明显劣化。

 

算力可以错峰，存储I/O不会自动错峰

AI 资源池里很少只跑推理。常见的做法是白天在线推理为主、夜间跑微调与批量任务，通过错峰把 GPU 利用率提上去——这是算力调度层面的优化。但算力错峰了，存储I/O并不会自动错峰：微调任务周期性写 checkpoint、批量推理持续写结果，都是大块连续写入，一旦和在线推理落在同一套存储上，前者很容易把后者的 I/O 带宽挤掉。GPU 那边看起来资源利用得很好，用户这边的推理响应却变慢了。

推理与虚拟化、数据库共用资源池时是同样的问题。企业很少为推理单独建一套存储，共用就意味着争抢。

ZBS 提供细粒度的 QoS 控制，支持按卷、主机或租户设置 IOPS 与带宽限制，为不同业务划定各自的性能份额。在线推理因此拥有可保障的 I/O 配额，不会被同一资源池里的微调、批处理或其他业务挤占。

副本策略上，三副本以充分的冗余保障数据安全，是面向生产环境推荐的主力策略；对开发测试、边缘资源池或已具备上层容灾能力的特定场景，也可选择两副本，并支持两副本与三副本之间的在线变配，变配过程中集群持续对外提供 I/O 服务，业务不中断。存储策略不必在创建资源池时一次性锁定，可以跟随业务等级的变化调整。

容量增长同样不需要停机。AI 平台的存储容量增长往往不是线性的——一次模型迭代、一批新业务接入，容量需求就会跳一个台阶。ZBS 支持在系统运行时动态添加存储节点，新节点加入后自动开始数据再平衡，并使用 QoS 算法控制迁移节奏以减少对业务的影响；也支持在线替换或升级单个节点的硬件、向现有节点添加新的 SSD。推理业务规模扩张时，存储可以跟着长，而不必安排停机窗口。

超融合还是分离式，看算力与容量的增长节奏

推理场景的存储部署，第一个要决定的不是买什么盘，而是用哪种形态。ZBS 支持超融合与分离式两种，适用边界很清楚。

超融合部署下，存储与计算资源共存于同一物理节点，硬件成本更低、资源利用率更高、网络延迟更小，并通过资源隔离技术确保存储性能不受计算负载影响。它适合节点规模有限、需要快速部署、就近处理数据的场景。

分离式部署把存储与计算分开，形成独立的存储集群，存储资源可以独立扩展，并支持 RoCE 等高速网络互联与 QoS 机制，适合规模较大、I/O 密集的场景。

判断用哪种，有一个可以直接对照的依据：看你的GPU节点与存储容量是不是同步增长的。如果推理规模扩张时两者需求大体同步，超融合能用更少的节点承载更多业务；如果两者节奏不同——常见的是 GPU 扩得快而存储需求平缓，或数据沉淀迅速而算力相对稳定——分离式让两边各自按需扩容，避免为了扩一边而被迫扩另一边。

 

从边缘质检到集中推理，三类场景怎么配存储

边缘与产线推理。制造场景中，质检、识别类模型往往部署在厂区本地，对时延敏感，现场机房的空间与供电条件也有限。这类场景适合超融合形态：用较少的节点同时承载推理计算与存储，数据就近处理，不必回传中心机房。

高频I/O的在线推理。面向大量并发请求的推理服务，存储承受持续的高频读写，对延迟与稳定性要求更高。全闪配置配合三副本与 QoS 策略，能在保障可靠性的同时把响应控制在可预期范围；实例扩容时的模型加载压力，则由条带化并行与热点再分布来消化。

推理与其他业务共用的资源池。推理与虚拟化、数据库共用一套存储时，QoS 的按卷、按租户限流与三副本的可靠性保障是基础，配合在线扩容能力，可以在业务增长时动态添加节点而无需停机。

在落地实践上，制造与游戏等行业已有客户以超融合形态部署 ZStone ZBS 承载生产业务。

此外，模型文件与数据集的存放，可以由 ZStone 平台的对象存储承接，通过兼容 S3 协议的接口对接模型仓库与数据管理流程。

 

选型跟着实际落地的负载走，而不是跟着行业话语走

按训练的逻辑规划推理存储，代价通常在两个地方显现：一是钱花在了用不上的指标上，带宽买得很足，而推理真正吃紧的延迟稳定性没人管；二是问题暴露得晚，新集群跑起来一切正常，等到数据沉淀、容量爬到高水位、扩容开始频繁，延迟才开始劣化，那时候再调整架构，成本比一开始就选对高得多。

所以推理场景的存储选型，落到实处是三个判断：要什么，模型加载与请求处理两种 I/O 都要顾到、长期稳态、故障不中断；怎么部署，看算力与存储是否同步增长，决定超融合还是分离式；看多久，不只看新集群的峰值性能，更看数据沉淀、模型迭代之后的长期表现。

这三个判断的共同点是，它们都不来自行业里关于 AI 存储的通行说法，而来自你自己业务的负载形态。AI 基础设施是分层的——算力决定能不能算，调用治理决定账算不算得清，数据这一层决定卡有没有东西可算。三层里任何一层按别人的逻辑规划，另外两层的投入都会打折扣。

作为 ZStack 的分布式存储底座，ZStone 与 ZBS 同计算、网络一道构成企业云基础设施的统一支撑。当 AI 应用从试点走向生产，存储不再只是一个容量数字，而是决定推理服务体验的基础设施。

如果您的企业正在规划 AI 推理平台或全闪存储建设，欢迎联系 ZStack 各区域团队，获取基于现有环境的存储方案建议。

 

252