AI 训练推理存储的技术需求

AI 大模型训练与推理是两类 IO 特征截然不同的负载：训练以吞吐为中心，推理以延迟为中心。训练数据读取、模型状态保存、推理请求处理与结果回流，全部经过存储系统，存储能力直接决定 GPU 利用率与用户请求的响应时间。

实践中，训练集群与推理服务通常共享同一套存储基础设施。两类负载的读写模式、高峰时段、容量曲线各不相同，混跑时会相互干扰：训练的 Checkpoint 写洪峰会挤占推理的读取带宽，推理的并发读也会拖慢训练管道。因此存储不仅要分别满足两类负载的指标，还要具备负载隔离与服务质量保障能力。

一、训练与推理的 IO 全景

训练是一个大规模、长周期、高强度的 IO 密集型过程，主要瓶颈是 GPU 因等待数据而空闲，存储系统的设计目标是保障 GPU 利用率。流程依次为：数据摄入与预处理、数据集洗牌与加载、分布式训练、Checkpoint 保存、模型产物入库。

推理对延迟的要求是压倒性的：用户请求到达后，模型加载和数据获取的延迟会直接转化为用户体验的延迟。流程依次为：模型加载与部署、Prefill 预填充、KV Cache 管理、Decode 解码生成、结果与日志回流。两类负载最终汇聚到同一套存储系统上。

二、AI 训练过程对存储的技术需求

2.1 数据摄入与预处理

原始数据经过清洗、去重与标注后，通常转换为 Parquet、ORC 等列式格式再进入训练。这一环节位于数据源头与训练管道的交界处，特点是来源多、文件小、写入并发高。功能要求：

• 多协议互通：同时支持 NFS/SMB（用户上传）与 S3 对象存储（数据湖），两份数据映射为同一份，无数据拷贝；

• 高并发写入：支持数千个采集点或用户终端的并发小文件写入；

• 实时可见性：文件写入完成后立刻对所有计算节点可见，不接受最终一致性；

• 原子目录操作：目录的移动与重命名必须原子完成。

性能要求：写入带宽 10～100GB/s；对 100KB～1MB 的图像、日志类小文件提供数万级 IOPS（传统 HDFS 的明确短板）；元数据操作（创建、列表）延迟 5ms 以内，保证管道入口不拥塞。

2.2 数据集洗牌与加载

训练开始前需要将数据全局随机打乱并切片，以利于模型收敛。全局洗牌意味着读取顺序与数据的物理布局完全无关，缓存的局部性全部失效，存储侧需要依赖预取与分层缓存弥补。这一环节的功能要求：

• 大规模文件列表：秒级列出包含数百万至数十亿文件的目录，这对传统文件系统的目录索引能力构成挑战；

• 随机读取：全局洗牌要求从海量小文件中完全随机、非顺序地读取，对象存储的强顺序读取模式在此场景下性能不足；

• 读取裁剪：支持按字节范围读取，或只读取 Parquet / ORC 文件中的特定列，节省网络与内存。

性能要求：随机读 IOPS 达数十万，同时总带宽 50～200GB/s，混合负载能力是关键；首字节延迟需从 10ms 级降至 1ms 级，延迟抖动直接影响批量加载时间。

2.3 Checkpoint 保存与恢复

所有 GPU 周期性地协同将模型状态（可达数十 TB）写入存储，是训练中最具挑战的写入场景；故障恢复同样依赖完整、一致的 Checkpoint。Checkpoint 内容包括模型权重、优化器状态与数据加载进度，保存间隔需要在故障损失的训练进度与保存对训练的干扰之间权衡，业界普遍采用异步保存与分片并发写入来缩短对训练主循环的影响。功能要求：

• 原子性与一致性：写入必须事务性，任何训练节点都不能看到不完整的 Checkpoint，否则故障恢复会出错；

• GPUDirect Storage：为每个 GPU 提供到存储的直接 DMA 路径，绕过 CPU 与内存瓶颈；

• 低写入放大：避免额外的副本与纠删码计算拉低有效带宽。

性能要求：千卡级 A100 / H100 集群的 Checkpoint 总写入带宽要求超过 200GB/s，目标是 30 秒内完成保存；写入延迟抖动必须极低——同步屏障下整体进度由最慢节点决定，单个慢节点会导致整个 GPU 集群空转。

2.4 训练日志与模型产物

训练日志与指标为追加写、低并发，通常需要 QoS 保证，使其不随主训练负载波动（GB/s 级带宽、10ms 级延迟），避免阻塞训练主循环。

模型训练完成后，产物需立即可以通过 S3 协议访问，供下游推理系统使用；采用高吞吐顺序写入，要求相对简单。

三、AI 推理过程对存储的技术需求

图：推理过程中存储相关的环节

3.1 模型加载与部署

新模型上线、节点扩容与故障恢复都需要重新加载模型，这条路径决定节点从启动到对外服务的时间。大模型的文件规模本身就不小：70B 参数模型以 FP16 存放约 140GB，推理框架的分片权重文件、Tokenizer 与配置文件还要额外增加。存储的功能上要求：

• 高并发只读：成百上千个推理实例同时读取同一个模型文件；

• 模型仓库：版本化管理，支持快速回滚；

• 缓存与零拷贝：提供内核级缓存提示，多个容器通过共享页缓存或零拷贝方式映射同一份模型文件，降低物理 IO。

性能要求：10GB 模型需在数秒内加载到数百个节点，总带宽需达数百 GB/s 至 TB/s 级；首字节延迟尽可能低。并发加载在存储侧表现为瞬时读洪峰，需要通过数据本地化或多级缓存吸收，避免形成部署拥塞。

3.2 KV Cache：推理状态的管理与分级存储

模型自回归生成 Token 时，模型将已处理 token 的 Key/Value 张量缓存下来，避免每生成一个 token 就重算全部历史注意力。KV Cache 容量 = 2 × 层数 × KV 头数 × 头维度 × 精度字节数 × Token 数，随上下文长度线性增长且只增不减。推理的两个阶段都受它影响：Prefill 阶段一次性计算整段 Prompt 的 KV，是计算密集型，决定首 token 延迟；Decode 阶段每生成一个 token 都要完整读取一次已有 KV，是显存带宽受限型。以 7B 模型（32 层、FP16）为例约 0.5MB/token：单条 4K 上下文约 2GB，32K 上下文约 17GB；采用 GQA 后降至约 0.125MB/token。服务端可并发的会话数，受限于扣除模型权重后的显存余量能容纳多少份 KV Cache——长上下文与高并发场景下，KV Cache 总量会超过模型权重本身，成为制约并发数的第一资源。

显存装不下时，业界做法是分级卸载：GPU HBM → 节点内存 → 本地 NVMe → 远端共享缓存池，访问时按前缀预取回显存。Mooncake 将 KV Cache 作为独立于 GPU 的数据资产，跨 GPU、内存、SSD 三层统一调度；开源 LMCache 在 vLLM / SGLang 上实现跨实例 KV 复用；NVIDIA Dynamo 的参考架构也包含了基于 NVMe 的 KV Cache 池。

KV Cache 卸载对存储的功能要求包括：按前缀或块的细粒度寻址（块大小数百 KB 至数 MB）；同一前缀只存一份、被并发会话共享（内容寻址去重）；支持多轮会话的历史块被再次定位与复用；Prefill 与 Decode 分离部署时，KV Cache 需要在两类节点之间经共享存储或 RDMA 网络迁移。性能要求：块级读带宽 GB/s 级——一次会话恢复需在亚秒级读回数 GB；单块读取延迟毫秒级；容量按并发会话数 × 上下文长度线性扩展。公开实践表明，当取回带宽超过约 64Gbps 时，从分级后端取回 KV 比重新计算更快——存储带宽直接决定这条盈亏平衡线。

3.3 实时数据获取与知识库检索

请求处理需要毫秒级读取用户画像、行为序列等特征，生成式推理还需要拉取知识库文档。特征读取通常由专用 KV 存储或在线数据库完成；检索增强生成（RAG）场景下，知识库的向量索引与文档原文通常分别落在专用向量库与对象存储上，推理时按相关性读取原文，读请求的突发性很强。对象存储侧的要求是：P99 延迟小于 10ms 的硬指标下支持每秒数百万次查询，高 IOPS 且内部排队深度必须极低——任何慢查询都会导致整个推理请求超时。

3.4 推理日志与数据回流

推理结果与日志需要持久化并回流训练管道，形成数据闭环。要求高并发追加写（每秒数十万条、GB/s 级带宽），并与 Kafka / Fluentd 等流式组件集成；日志聚合必须足够高效，不能成为推理服务的尾部延迟来源。

四、训练与推理的存储需求差异

将上述环节的要求汇总，两类负载在存储选型上的差异见表 1。总体而言，训练侧看写入，推理侧看读取；训练的指标可以离线压测验收，推理的指标必须在真实并发下验证。

表 1　AI 训练与推理的存储核心差异

结语

训练存储的核心指标是写入带宽与稳定性，Checkpoint 是最大挑战；推理存储的核心指标是读取延迟与并发能力，模型加载与 KV Cache 是最大挑战。概括而言：训练存储是高并发、高吞吐的数据管道，推理存储更接近一个为模型文件与上下文状态服务的超大规模低延迟缓存系统。

选型时建议按上述环节逐项验收：训练侧以真实模型规模的 Checkpoint 写入与恢复演练验证带宽与一致性；推理侧以模型并发加载与 KV Cache 取回实测 P99 延迟；避免以单一峰值指标做出判断。