2025年最新AI推理与存储解决方案排行榜TOP10

AI存储核心需求

大模型推理场景下的存储需求，其实可以拆解成两个关键维度：一是模型权重这种“一次写入、多次读取”的持久化数据，二是推理过程中产生的KV Cache这种临时但高频访问的数据。两者特性截然不同，对存储系统的要求也天差地别。

模型权重

LLM模型权重是AI推理最基础的持久化存储数据，核心特征就是一次性写入、之后几乎只读。权重文件从网络下载完成后，基本不会再修改，后续无论是业务服务启动、日常推理运行，还是工程人员调试测试，全部是读取操作。

在推理引擎启动阶段，系统需要把完整的模型权重加载到GPU显存，GPU才能开始干活。这个加载过程直接决定了业务什么时候能用上。如果读取速度太慢，启动延迟会非常严重——行业里二三十分钟的等待并不罕见。更麻烦的是，当多个实例、多个服务同时启动时，大规模权重加载请求会形成“启动风暴”，把系统IO和网络资源全挤占掉，整体服务启动效率大幅下滑。

模型权重文件是典型的超大文件。以DeepSeek-V4-Pro为例，单份safetensors权重文件就有14GB，整个模型由64个这样的文件组成。这种体量对存储的吞吐能力和稳定性要求极高。

为了优化启动加载效率，当前推理引擎普遍采用mmap机制。多个TP工作进程可以通过mmap共享映射模式，把权重文件只加载一次到内核的Page Cache中，各进程按需把自身需要的片段复制到对应GPU显存，这样就避免了单机器多显卡重复读取完整文件的尴尬（8卡机最差情况要重复读8次）。但mmap也有局限——FUSE文件系统对它不友好，没法适配这种优化方案。

KV Cache存储布局与特性

KV Cache是大模型推理过程中的核心临时数据，用来存储上下文的键值对信息，避免重复计算，大幅提升推理效率。它在GPU中的分配遵循Paged Attention布局，分布非常离散。

从结构上看，大模型有几十层网络Layer，分为K Layer 0、K Layer 1到K Layer N，以及V Layer 0、V Layer 1到V Layer N。同时显存被划分成多个独立Page（Page 0、Page 1至Page N）。不同会话可能共享同一个Page，也可能各自用不同的Page。图中绿色代表一个会话占用的显存，蓝色代表另一个会话，白色为空闲。这种分配随机且离散，连续分布只是概率事件。实际测试发现，推理引擎启动早期比较容易分配到连续Page，运行一段时间后，连续分配的几率就大大降低——这和Linux内核的内存分配有点像，也是分页式内存管理的常见毛病。

KV Cache两种主流外部存储布局

把GPU内的Paged Attention数据搬运到外部存储时，主要有两种布局方式，而且两种都需要额外的数据复制（优化的方向之一就是通过技术手段规避数据拷贝，实现高效迁移）。以上图的绿色会话为例：

第一种是Layer First Layout（层优先布局），完全对齐GPU内部数据维度，把所有网络Layer的同层数据连续存放。这样做贴合GPU原生运算逻辑，不需要做shape变化，但需要把离散的数据块和连续的文件之间进行数据搬运。

第二种是Page First Layout（页优先布局），把一个或多个Page的所有数据连续存放。由于Page数据可以支持多会话共享，这种布局在多会话场景下更优，但需要做shape变化，同样需要数据搬运。

KV Cache核心特性

首先，数据形态离散，以大量小块数据为主，数据块数量极其庞大。单Page可以存放一定数量的Token（常见16个或64个，受共享效率约束），目前主流旗舰模型普遍支持1M上下文长度，结合Page尺寸与模型层数计算，数据块的数量会膨胀到相当可怕的规模。另外，KV Cache具备可重计算特性，数据丢了可以通过上下文重新生成，不需要永久持久化——至少经典的三副本强一致性不再那么必要。

KV Cache哈希管理方案

基于哈希的KV Cache管理

这是当前业界通用的主流方案，示意图如下：

核心逻辑是按固定长度截取Token序列。示例图中每4个Token为一组，计算每组Token序列的哈希值作为唯一Key，对应的KV Cache数据作为Value，形成键值映射关系。即token0~3对应hash0-value0，token4~7对应hash1-value1，以此类推。

这种方案下，KV Cache存储数量与Token序列长度成正比，超长上下文场景会消耗大量存储资源。优势是逻辑简单、落地便捷，推理引擎只需要算个哈希就能完成缓存匹配调用。但核心短板在于性能和成本不可预期——Prompt中的缓存Key处于隐藏状态，请求没到推理引擎之前，你根本没法精准判断缓存命中率和资源消耗成本。只有SGLang Gateway等少数工具能实现部分预测，但覆盖不了全场景。

KV Cache显式共享管理方案

显式共享管理是我们（张量跃迁）提出的创新方案，目前处于开发迭代阶段，并持续向vllm/sglang社区推送。

这种方式以文件为单位管理会话数据。单轮完整会话（Token 0至Token N）对应存储文件，N轮会话最少只要1个文件（支持文件追加写入），最多对应N个独立文件。举个例子：

"stored_kv_cache": [{
    "token_start": 0,
    "token_length": 8192,
    "kv_uri": "gd2fs://cluster-01/session-97f1226c-...",
    "kv_start": 0,
    "kv_length": 134217728
}],
"fresh_kv_cache": [{
    "token_start": 8192,
    "token_length": 8192,
    "kv_uri": "gd2fs://cluster-01/session-97f1226c-...",
    "kv_start": 134217728,
    "kv_length": 134217728
}]

和哈希管理相比，显式共享管理的使用复杂度更高，需要分布式调度器统一管理会话与存储文件的映射关系。它天生适合分布式部署场景，可以实现KV Cache的精准显式共享。例如多个会话复用同一系统提示词文件file0，后续各自独立生成file1、file2，公共缓存数据就能高效共享。值得一提的是，存储用户的会话ID、时间、KV Cache信息等格式化数据，对于当前的关系型数据库来说并不算困难。

其核心优势是实现Prompt与KV Cache元信息分离——请求到达分布式调度器时，就能精准预判缓存命中率、to prefill的Token数量、to decode的Token数量，实现推理性能与资源成本的可预期、可管控。

KV Cache存储诉求、延迟与成本痛点

综合两种KV Cache管理方式，AI推理场景对存储的核心诉求可以总结为三点：容量大、数量多、分布式高效调度。两种组织方式都会产生大量KV存储与存储文件（虽然文件比KV存储少，但量级依然很大），依托分布式架构可以大幅提升缓存共享效率与GPU调度利用率。同时KV Cache单实例容量可达GB级甚至更大，对读写延迟极其敏感：

读取延迟过高会产生GPU计算气泡（GPU空闲等待数据），打断推理连续性，直接降低用户体验；写入延迟过高会导致缓存数据无法快速从GPU导出，显存长期被占用，大幅降低整体推理吞吐能力。

成本层面存在显著的存储介质价差：单位容量DDR内存成本是NVMe固态硬盘的30-100倍，行业普遍价差约50倍。结合KV Cache可重计算的特性，其数据不需要强制持久化存储，但存储分层架构很有必要——借助NVMe的大容量优势降低整体存储成本。同时，传统存储的三副本强一致性机制对于KV Cache场景不再必要，反而会增加存储开销、成为性能负担。

熟悉存储和FIO的朋友可能知道，执行FIO测试时，bs（单个请求的块大小）和IO depth（inflight IO数量）在测试IOPS和bandwidth场景下参数不同：测试IOPS用4K，测试bandwidth用256K或更大。但在LLM的KV Cache场景下，bs较小、IO depth很深，同时还要保证很高的bandwidth。这就意味着我们必须面对整个存储/分布式存储历史上最难解决的问题之一：大量的、离散的小块数据组成了GB级的数据，又要求很低的延迟。

存储栈与单机、分布式优化

单机存储优化方案

在单机本地存储场景中，NVMe与GPU之间的数据传输存在多条路径，不同路径的性能、适配场景与限制差异极大。整体优化核心思路是缩短数据传输路径、减少数据拷贝次数——路径越精简，性能越优异，但通用性越弱、限制条件越多。各传输路径特性如下：

1. 绿色（GPU Direct Storage，GDS）：理论性能最优路径。实现NVMe与GPU之间的PCIe P2P直接传输，不需要CPU中转。需要安装NVIDIA驱动，通过ioctl接口触发传输，适合大块数据场景，有一定性能优势。但限制条件很多：数据Block Size必须严格对齐，小块数据场景依赖IOPS性能，而且ioctl是同步调用，小块IO场景下反而变成负优化。GDS在实际工程实现上（参考https://github.com/NVIDIA/gds-nvidia-fs），既巧妙又“hacky”——工程师真的很天才，去Hook内核块层的DMA操作，把GPU的MEM正确设置到NVMe的驱动中，NVMe设备直接完成数据和GPU MEM之间的DMA。可惜的是，存储设备太慢的同时使用要求又多，已知范围内并没有听说太多实际业务应用。尤其是在LLM场景下（数据从GPU Memory中的Paged attention布局到Layer First/Page First都需要做数据变换），GDS只能发生在per Layer级别的小块数据上，这对NVMe性能来说很乏力。Linux 6.17开始支持Block Layer的P2P，理论上可以更好支持这个场景，具体效果还要看业界尝试和演进。最有潜力的场景其实是模型权重从NVMe加载到GPU，但遗憾的是safetensors格式并没有block size对齐的保证，目前没法直接用。这里的观点仅适用于LLM推理场景，其他场景不在讨论范围。

2. 蓝色（Direct IO）：NVMe直接IO传输，不需要经过系统缓存，要求数据Block Size对齐，不支持跨进程数据共享，适合固定块大小的批量数据传输场景。

3. 黄色（Page Cache + mmap）：通过文件映射实现数据传输，支持跨进程共享数据，通用性较强。但在KV Cache场景下适配性不太理想——KV Cache数据线性增长，需要频繁调用mremap调整内存映射空间。抛开性能开销不谈，这种使用方式本身也不够自然。

4. 红色（传统拷贝）：性能最差，需要经过多次用户态、内核态数据拷贝，但通用性最强，适配所有场景——这一点在Python主导的AI推理生态中尤其重要。大内存服务器（典型如2TB）场景下，内存回收的效率是个大问题：内核线程在大范围内扫描内存页面，效率比较差。

分布式存储性能层级

分布式场景下，数据传输依托以太网或RDMA网络实现，从存储设备到GPU的数据路径分为四个层级。优化逻辑和单机一样，核心是精简IO路径、减少数据拷贝，差异仅在于数据操作发生在用户态还是内核态：

1. 绿色（GPU Direct RDMA）：分布式场景理论最优性能路径，以GDR为核心，数据在GPU显存和网卡之间直接传输，不需要CPU侧内存中转。同样都是GPU Direct技术，GDR和GDS有几个明显差异：存储栈有状态，涉及Page Cache、文件系统元数据组织和Block Size对齐IO等，Direct技术在越复杂的约束下发挥空间越小；而RDMA只是一块空间通过网络进行发送和读取。另外块设备和VFS工作在内核态，一般用户的Read/Write/Ioctl请求通过内核转义成“issue IO”和“wait completion”的块层语义，但RDMA的verbs请求既可以在内核态也可以在用户态触发，也就是说GDR比GDS更容易在用户态使用，并完成更复杂的语义。目前GDS在内核态已部分支持该能力（例如NFS、WEKAFS等），也有在用户态实现的存储方案（例如下文会提到的GD2FS）。

2. 蓝色（用户态文件系统）：以libnfs、libcephfs为代表，数据通过网络读取至用户态内存后，再拷贝至GPU显存，规避了内核态数据拷贝开销，性能居中。

3. 黄色（内核态文件系统）：以NFS、SMB为代表，支持Page Cache，再拷贝至用户态内存，最终传输至GPU，多级拷贝导致性能损耗较大。

4. 红色（FUSE文件系统）：性能最差，用户态的Daemon进程与内核态频繁交互产生大量开销，但通用性极强，适配各类分布式存储场景。

分布式存储协议与主流软件对比

分布式块协议（iSCSI和NVMe-oF）

iSCSI和NVMe-oF是最流行的分布式块存储协议，主要对比如下：

这两种协议在生态上比较接近，都得到了Linux内核、用户态库和SPDK的支持，主要差异体现在多队列的并发能力上：iSCSI是传统单队列设计，多核场景下性能受限，TCP环境下单核只能实现50-60K IOPS。SCSI/iSCSI的设计受限于其诞生年代的硬件条件和并发规模，这些限制更多是历史背景的映射。不过在今天性能要求不那么高的场景下，依然有不错的表现。例如QEMU提供Virtio Block块设备服务给虚拟机使用，并绑定一个IO线程，结合后端驱动libiscsi，则可以在单一的IO线程下跑出不错的性能，也容易实现IO线程和虚拟化线程之间的性能隔离。NVMe-oF则是现代化架构，采用“1个管理队列（ADMIN Queue）+ 多个IO队列”设计，可充分发挥多核、多队列硬件性能，吞吐与并发能力更强。即使使用TCP，也能发挥多核并行能力，完全释放块设备的性能。

在Target实现上，LIO和SPDK、NVMe Target和SPDK对比，存在一定性能差异，但用法上没有太大差异。TGT虽然性能最差，但由于后端支持glusterfs这样的分布式存储，使用场景上就多了一种可能。

整体来看，分布式块协议存在天然短板：块协议本身过于原始，只提供固定大小的IO地址随机访问能力，且需要block size对齐。高级的文件管理能力需要额外搭配文件系统完成数据组织。虽然支持Persistent Reservations持久化预留机制，但数据共享能力薄弱（如GFS2有严格的共享数量限制）。没有原生集群模式，单卷存储容量存在上限，无法适配大模型大量数据存储需求。

如果需要使用libiscsi的iSER（iSCSI Extensions for RDMA），推荐自主编译最新的libiscsi源代码：

https://github.com/sahlberg/libiscsi

作者（皮振伟）和字节跳动的同事在2019-2023年陆续修复了约50个Patch，其中部分会影响业务的正确运行，修复过的代码经历过实际的业务验证。同时，libnvmf

https://github.com/bytedance/libnvmf

是作者和同事在字节跳动工作期间开发的，在虚拟化场景下，QEMU的单盘使用TCP性能突破200K IOPS，也经历过业务验证。

NVMe-oF/RDMA I/O传输机制

iSER协议和NVMe-oF协议在数据传输机制上比较接近，但NVMe-oF更现代化，这里以NVMe-oF为例：

• Initiator和Target在Admin Queue连接成功后，Initiator执行Identify命令查询Target支持的最大In Capsule Data Length。
• 小于In Capsule Data Length的小块数据场景：Initiator通过RDMA Send一次性发送NVMe命令和In Capsule Data，只需要1次网络RTT。
• 大于In Capsule Data Length的大块数据场景：Initiator只发送NVMe命令。对于写命令，Target通过RDMA Read从Initiator读取数据；对于读命令，Target通过RDMA Write向Initiator写入数据。数据传输完成后，Target通过RDMA Send发送NVMe Completion，IO完成。

在整个数据传输过程中，传输效率发挥到极致。同时，RDMA的Read/Write是在Target端发起，而不是让Target暴露地址空间给Initiator，完全避免了安全问题：Initiator写错了怎么办？恶意访问怎么办？

有幸参与过NVMe-oF的内核贡献，在这个过程中逐渐熟悉了这个协议。从个人视角而言，NVMe-oF协议是存储系统与网络技术深度融合的杰出范例，极具美感，是计算机发展历程中的宝藏。

部署模式

直连模式为Initiator与Target直接通信，链路最短、性能最优。

网关模式通过TGT后端对接GlusterFS等集群，由TGT完成协议转换，适配集群存储，但延迟较高，不适合对延迟敏感的KV Cache推理场景。

Redis/Valkey Over RDMA

RESP3协议

RESP3是流式协议，Hello World报文示例：

*3\r\n$3\r\nSET\r\n$5\r\nHello\r

\r\n是分隔符，*3表示3个参数，$3表示后续参数长度是3个字符。很明显，解析这段协议需要CPU解析全部内容；同时报文不定长度，Key和Value都可长可短。

基于RESP3流式协议，对TCP非常友好，但对RDMA并不友好——RDMA是面向消息的协议，数据传输前需要提前注册内存。这就会带来几个问题：

• 如果使用Receive buffer接收消息，buffer多大合适？比如GET KEY，无法预测返回的VALUE长度，肯定不希望限制消息长度。
• 需要多少个Receive buffer？比如INFO命令可能返回多个数据片段，COMMAND命令可能返回数百个片段。
• 如果用一个Receive buffer，接收后回复ACK再请求后续数据，可以节省Receive buffer，但会带来额外RTT开销。例如Redis/Valkey一次传输*1\r\n$4\r\nPING\r\n，或者分成三次传输*1\r\n、$4\r\n、PING\r\n，在RDMA里就需要3次完整的RTT。

因此常见做法是用一块稍大的内存模拟Stream Buffer来传输网络数据，这样网络层与业务层之间仍存在数据复制开销。性能测试显示：1K小报文场景下QPS可提升250%，64K大报文场景性能与原生TCP基本持平。

另外，Redis/Valkey是纯内存存储，只支持基础持久化，不支持存储分层架构，没办法借助NVMe扩展大容量存储。Redis/Valkey的设计哲学就是纯内存极速访问，分层存储本来就不在它的原始目标内。社区中关于分层的讨论也有过，但基本没下文，参考：

https://github.com/valkey-io/valkey/issues/83

在经典的数据中心业务中，Redis/Valkey是最流行的KV存储，仍然扮演着重要角色。Valkey Over RDMA在电商秒杀等高并发场景下还有一定业务价值。该方案的作者是皮振伟（Github ID：pizhenwei），遇到问题可以在社区联系他。

集群模式

基于一致性哈希管理slot与节点，网络可以实现一跳直达，但节点间依赖GOSSIP协议同步信息，大规模集群场景下协议收敛速度慢。2025年底，国内第一次举办的Valkey Keyspace上，字节的同学分享了去GOSSIP的中心化集群控制，阿里云的同学也做了问题的确认。

对象存储协议（S3）

S3是主流对象存储协议，基于流式架构设计，TCP网络适配性极佳，成本优势显著，适合海量冷数据、模型权重归档存储。一个S3请求、响应的例子：

S3协议示例，请求：GET /my-data HTTP/1.1...
响应：HTTP/1.1 200 OK...
Content-Length: 32768
[BINARY DATA]

业界多数对象存储产品不支持RDMA，只有少数企业级产品尝试适配。核心问题和Valkey Over RDMA类似：不定长数据在定长的RDMA消息语义下，要么牺牲性能，要么牺牲内存使用率，同时也不再是标准的HTTP协议，做了适用性牺牲。

Mooncake Store存储方案

Mooncake Store采用分布式内存池架构，集群内所有节点同时作为内存使用方与资源提供方，构建统一共享存储池。架构上通过Master Service统一管理元信息，支持高可用（HA）部署；数据访问采用“先RPC查询元信息、再RDMA直连访问数据”的模式，Data Plane性能优异，但Master Service可能成为性能短板。支持数据持久化，同样不支持存储分层，无法适配低成本大容量存储场景。

Mooncake Store的传输协议也值得探讨。例如PUT操作：先RPC请求Master Service为各个Replica分配内存空间，分配成功后RPC返回相应的endpoint、地址和长度，client执行RDMA WRITE写入对象。在这个过程中，被写入数据的节点不感知，也无法校验参数的正确性：地址和长度符合预期吗？协议上允许内存池中各个节点有写入权限，如果程序出现逻辑BUG呢？和iSER/NVMe-OF的协议设计对比，这里有明显不同。

Mooncake Store对KV的支持也值得讨论。上文提到KV存储语义上不定长，这在RDMA上表现最挣扎。Mooncake Store执行GET时，先RPC从Master Service获取对象长度，如果用户提供的Buffer长度小于对象长度，直接返回失败，不会进行网络IO。这个方法比较直接，在KV Cache场景下KV大小是可预期的固定长度，所以当前能用。从个人视角而言，Mooncake Store并非传统意义上的KV存储，GET/SET在语义上不完整。但对于hash based KV Cache管理方案，它能满足需求，现阶段是合适的。

GD2FS分布式文件系统与推理实践

基于上述LLM KV Cache的需求和一些流行存储服务的特点，我们尝试面向GPU为中心的系统架构设计全新的分布式存储服务，探索更多可能。在此抛砖引玉，欢迎探讨。

GD2FS核心设计理念

GD2FS全称为GPU Direct Distributed File System，是适配AI推理场景自研的专属分布式文件系统。核心设计理念是深度融合GPU加速技术与高速网络能力，最大化精简数据传输路径。GD2FS原生支持GPU Direct RDMA高速传输，在实际实现中，客户端实现了前文《分布式存储性能层级》中的最优路径——用户态的GDR方案；同时服务端也实现了完全的zero copy。此外还兼容TCP多网卡、多流并发传输，用于兼容老旧GPU和网络环境。

部署架构采用分层存储设计，区分高可用存储池（3副本）与高性能存储池（1副本），将副本策略与缓存机制解耦，兼顾可用性与性能、成本平衡。采用中心化管理架构，摒弃GOSSIP协议，解决大规模集群收敛慢、稳定性差的问题。

GD2FS性能实测数据

测试环境：INTEL(R) PLATINUM 8563C CPU、NVIDIA H20 96GB GPU、Mellanox CX7 400Gbps网卡、INTEL企业级SSD，实测性能如下：

从数据可以清楚看到，RDMA GPU直连模式的读写性能接近400G网卡理论性能，验证了存储栈上最短路径无数据复制的效果。TCP传输下，1G文件读写延迟约为RDMA模式的3倍，但绝对值依然可观——百毫秒量级实现GB级数据传输。

基于GD2FS的AI推理架构

基于GD2FS构建的LLM推理协同架构，核心是重塑端到端的AI推理链路，打破传统推理引擎、存储、调度系统的割裂状态。AI推理是典型的系统性工程，性能优化不能局限于单一模块，需要实现存储、推理、调度的全局协同。

该架构的核心革新点是：打通GPU与分布式存储的直连通道，实现GPU直接访问远端存储数据，彻底规避CPU、内存的中转拷贝开销。结合GD2FS的高速分布式传输能力、灵活的存储分层与副本策略，全面解决大模型推理的启动延迟、缓存吞吐、存储成本、资源调度等核心痛点，为超长上下文、高并发、大规模AI推理场景提供底层支撑。进一步完整支持GPU的无状态化推理，大幅提升GPU利用率和推理效率。