导读
接着上一节内容，本文系统介绍了阿里云 Tair KVCache 团队与服务器研发存储软硬件结合团队对 3FS（高性能 KVCache 底座）开展的全方位工程化升级实践。
面向 AI 大模型推理中高吞吐、低延迟、强稳定性的核心诉求，团队从性能调优、产品化增强与云原生管理三大维度推进深度优化：
在性能层，通过 RDMA 流量均衡与小 I/O 参数调优，实现 4K 随机读 IOPS 提升 150%，并集成全用户态落盘引擎以降低资源开销；
在产品层，解决 Mgmtd IP 漂移、存储分配失衡等关键稳定性问题，新增 GDR 零拷贝与多租户隔离机制，支持 HBM 缓存与后端存储的端到端高效协同；
在运维层，基于 Kubernetes Operator 构建云原生管控体系，实现一键部署、故障自愈、弹性扩缩容与多集群隔离，并配套可视化监控大盘，显著降低 AI 基础设施的运维复杂度与人力成本。
本实践为高性能 KVCache 在企业级 AI 场景中的规模化落地提供了可复用的技术范式。
本系列技术文章将系统性拆解面向智能体推理的 KVCache 技术演进路径：
- 智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析
- 本文 | 3FS-KVCache 工程化落地：企业级部署、高可用运维与性能调优实践
- Hybrid Model Support：SGLang 对 Mamba-Transformer 等混合架构模型的支持方案
- Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现
- KVCache 仿真分析：高精度的计算和缓存模拟工业级实践
- Hierarchical Sparse Attention：分层稀疏注意力框架下的 KV 分层管理与按需加载
- 展望：KVCache驱动的软硬结合演进
Tair KVCache 作为阿里云数据库Tair产品能力的延伸，本质是缓存范式的三次跃迁：
🔹 从 Redis 的 “缓存数据 → 减少 I/O”
🔹 到 GPU KVCache 的 “缓存计算中间态 → 减少重复计算”
🔹 再到 Tair KVCache 的 “规模化、智能化的注意力状态管理 → 重构大模型推理成本模型” 它标志着缓存正从辅助组件升级为 AI 基础设施层的核心能力——让“状态”可存储、可共享、可调度，支撑智能体时代的规模化推理底座。
1.简介
1.1 KVCache 简介
在大语言模型的推理阶段，生成式推理本质上遵循自回归范式：模型按顺序逐个输出 token，每一步的预测都依赖于此前已生成的所有内容。这种机制虽然有助于维持输出的语义一致性，却也引入了明显的计算冗余——尤其是在注意力机制中，Key（K）和 Value（V）向量的重复计算成为性能瓶颈。
具体来说，每当生成一个新的 token 时，模型需将其对应的 Query（Q）与所有历史 token 的 K 和 V 进行点积操作，以计算注意力权重并聚合上下文信息。值得注意的是，历史 token 的 K 和 V 在后续生成步骤中始终保持不变。若在每次解码时都重新计算这些不变的向量，将导致大量无效计算。
为应对这一问题，业界普遍采用 KVCache 技术：即在首次生成每个 token 时，将其 K 和 V 向量缓存起来，并在后续自回归过程中直接复用，从而跳过重复的前向计算。这项优化大幅减少了推理延迟，显著提升了吞吐能力，已成为现代大语言模型实现高效流式生成的核心手段之一。
1.2 L3 KVCache 需求和选型
随着大语言模型（LLM）推理场景向长上下文、高并发、低延迟方向快速演进，尤其在多轮对话、RAG（检索增强生成）等典型应用中，模型需频繁访问海量历史上下文或外部知识，因此对于扩展KVCache 的存储选型上我们看到以下特点：
| 特征 | 技术含义 | 对存储系统的影响 |
|---|---|---|
| 超长上下文 | KVCache 单次推理内存占用可达数 GB ~ 数十 GB | → 需支持 PB 级可扩展缓存池，主存（DRAM）成本过高，需要有更加便宜大容量的存储方案 |
| 多轮对话 / RAG 高频重用 | 同一用户/会话的历史 KV 常被反复读取（如回溯、摘要、修正） | → 极高读写比（典型 > 10:1），写为顺序追加，读多为随机（跳转、检索） |
| 高并发低延迟 SLA | 要求 P99 < 50ms（甚至 < 10ms）端到端响应 | → 存储系统需具备超低延迟特性（避免成为瓶颈），带宽 ≥ 20 GB/s/节点 |
L3 层 SSD KVCache 存储方案解决共享容量及成本上的问题，但是目前常用的分布式文件存储都有其自身的局限性。传统的闭源解决方案如 GPFS 虽然性能强大，但其高昂的使用成本和复杂的后续维护优化工作成为企业部署的主要阻碍。而主流的开源分布式文件系统常聚焦于通用存储的场景，但在 KVCache 的应用场景下仍存在明显的局限性：以 Ceph 为例，其作为通用文件存储系统被广泛采用，但在 KVCache 这一特殊场景中，其设计无法满足高带宽和低延迟的核心性能要求；JuiceFS 提供了灵活的架构设计，但其和后端对象存储依赖过深使得性能受限，高耦合度也增加了系统运维的复杂性和潜在风险。
3FS 作为 DeepSeek 开源的高性能分布式文件系统，凭借其高吞吐、低延迟、大容量共享存储特性，为 AI 训练与推理提供了极具竞争力的存储底座。
1.3 3FS 介绍
3FS（Fire-Flyer File System）是开源的高性能分布式文件系统，它利用 SSD 和 RDMA 网络来提供共享存储层以简化分布式应用的开发。3FS 旨在应对人工智能训练和推理工作负载的挑战，提供比基于 DRAM 的缓存更具成本效益的替代方案，具备高吞吐量和大容量的特性。
3FS 核心组件包含 Fuse、Meta、Mgmtd 和 Storage，所有组件通过 RDMA 网络连接，各组件之间的交互关系如下图所示：
图1 3FS架构图
（1）Mgmtd：管控服务，采用主备策略保证自身高可用，当主节点失效，另一个 Mgmtd 副本会被选为新的主节点。Mgmtd 管理集群的配置，所有 Meta 组件、Storage 组件以及 Fuse 客户端均通过周期性的心跳机制维持其在线状态，同时，各组件会周期性地从 Mgmtd 获取集群的最新状态（如集群拓扑、ChainTable 信息等）。
（2）Meta：元数据服务（如 open/close 文件），实现了文件系统语义。Meta 是无状态服务，将元数据信息持久化到事务性KV数据库 FoundationDB，支持多个 Meta 服务扩展，客户端可以连接到任意一个元数据服务，同时 Meta 会根据 InodeId 转发请求。
（3）Storage：存储服务基于本地文件系统管理 SSD 存储资源，Storage 所管理的每块 SSD 上，会被抽象出若干个逻辑存储单元 Target，不同 Storage 的 Target 之间组成一条 Chain，副本之间通过链式复制协议（CRAQ）来确保强一致性，读文件会随机选择 Chain 上的一个 Target 读取，写文件则写 Chain 的 Head Target，然后通过 CRAQ 协议链式写同步副本数据。CRAQ 的这种“写全部、读任一”机制有助于充分发挥 SSD 和 RDMA 网络的吞吐能力，尤其对读带宽十分友好。
（4）Client：FUSE 是 Linux 内核提供的一种用户态文件系统接口，允许用户通过标准的 POSIX 文件操作语义访问非内核实现的文件系统。3FS 通过 FUSE 服务，使用户能够以熟悉的文件系统方式透明地操作 3FS 集群中的文件，适用于大多数对兼容性要求较高的应用场景。
图2 文件Chunk分布
图3 3FS客户端
此外，3FS 还提供了 USRBIO 客户端接口， 该接口是一套用户态、异步、零拷贝 API，使用时需要业务代码进行一定程度的适配和修改。其元数据操作仍然依赖于 Fuse ，但每个读写请求可以直接从用户进程发送给 FUSE Daemon，消除了系统调用上下文切换和数据拷贝开销，实现了更高的性能。
1.3.1 3FS 在 KVCache 场景的核心优势
3FS 作为专为并行计算环境设计的分布式文件系统，在 KVCache 场景中的优势：
-
容量和成本： 3FS 充分考虑到 KVCache 对大容量存储空间的基本需求，对大量存储节点上的SSD资源进行统一池化管理，提供PB级的存储池，有效支撑大规模数据处理需求，同时在性能和成本之间实现了理想的平衡。
-
宽带和延迟： 3FS 采用全链路端到端的 RDMA 传输，保证数据传输的高带宽、低延迟，同时 USRBIO 客户端零拷贝机制优化数据传输路径，减少用户态和内核态上下文切换开销，进一步降低 I/O 延迟。根据 3FS 官方公布的数据，在一个包含 180 个存储节点的集群中，读带宽达到约 6.6TiB/s。
-
读优先策略： 考虑到 KVCache 典型的读多写少访问模式，3FS 在设计时特别优化了读取路径的效率。基于 Chain Replication with Apportioned Queries (CRAQ) 协议，读操作可随机选择副本，在面对大规模读取请求时仍能保持卓越的性能表现，充分适应了 KVCache 场景中读取密集型的工作负载特征。
图4 3FS官方性能数据
1.3.2 开源 3FS 的局限性与优化挑战
同时开源的 3FS 有以下不足：
- 多组件协同复杂性问题：在云原生异构环境中，在 GPU/HBM 计算单元、RDMA 网络架构与 NVMe 存储介质构成的异构体系中，缺乏统一的跨层协同机制；IP 地址漂移引发组件状态不一致问题，形成分布式孤岛效应，难以满足高并发AI推理场景下多模型并行、多阶段流水线的动态弹性调度需求。
- 资源利用率低等问题，I/O侧：小 I/O 密集型负载（如 KVCache 检索、Attention 缓存落盘）下传统内核旁路方案仍存在 CPU 绑核竞争与内存拷贝瓶颈，HBM → DRAM → SSD 多级落盘链路延迟高、带宽利用率不足 40%；计算侧：缺乏 GDR（GPU Direct RDMA）支持时，数据需经 Host 内存中转，GPU 显存与存储间带宽浪费显著；调度侧：存储资源分配不合理，随着集群规模增长，存在存储容量/带宽热点问题，无法随数据量增长保持负载均衡。
- 云原生运维能力薄弱：部署与生命周期管理依赖人工脚本，缺乏声明式 API 与状态自省能力；故障恢复依赖人工介入（如 Storage 故障后需要手动重建）；监控体系缺少可视化方案，运维复杂并难以满足 SLO 驱动的 AIOps 需求。
因此，阿里云 Tair 团队和服务器研发存储软硬件结合团队以 3FS 为基础，通过系统级改造适配及产品化能力提升，为 Tair KVCache 产品提供 L3 级 KVcache 能力并开源至 SGLang、vLLM 等推理引擎社区中。通过该方案实现了全局 KVCache 的高效复用，在降低显存压力的同时，进一步提升推理效率与资源利用水平。
2.3FS 进化之路
阿里云服务器研发存储软硬件结合团队从性能调优、产品化增强、云原生化管理等维度对 3FS 进行了系统性升级：
-
性能突破：通过 RDMA 流量均衡优化与小 I/O 场景参数调优，将 4K 随机读 IOPS 提升 150%，并引入 全用户态落盘引擎进一步降低资源消耗；
-
产品力增强：攻克 Mgmtd IP 漂移、存储分配不均等稳定性问题，新增 GDR 零拷贝与多租隔离能力，实现 HBM 到存储的端到端高效协同；
-
云原生管理：基于 Kubernetes Operator 实现一键部署、故障自愈、多集群隔离，结合弹性扩容与监控大盘，显著降低 AI 基础设施的运维门槛。
图5 3FS产品图
2.1 性能优化
我们使用物理存储服务器对 3FS 进行了本地部署验证和性能调优，实验环境的关键硬件配置及集群拓扑结构概览如下：
（1）大 I/O 场景下的 RDMA 网络配置与 I/O 并发配置调优
3FS 在大块 I/O 读带宽方面表现优异，但随着客户端数量增加，总读带宽未线性增长，反而因客户端间 I/O 干扰而下降。进一步分析发现 RDMA 网络流量分布严重不均，部分网卡利用率低于 40%，而另一些已接近 100% 饱和，主要原因是 RDMA 队列对（QP）数量不足。通过调整相关的 QP 配置参数，网卡端口流量均衡分布，总读带宽随客户端数线性提升， 3FS 在大规模分布式场景下的良好可扩展性。
针对写带宽的瓶颈，增加了 I/O 链路上的并发配置，在上述优化后，单 USRBIO 客户端对 4M I/O 的读写带宽从之前的 29.5GB/s、5312MB/s 提升到 40.2GB/s、31.4GB/s。
（2）小 I/O 场景下的参数调优及落盘引擎升级
在性能测试中，3FS 的小块（4K~64K）随机读 IOPS 较低，单个 Storage 节点的 4K 随机读 IOPS 仅200K 左右，经分析确认，性能瓶颈主要源于在小 I/O 读场景下 Storage 的监听线程资源耗尽。针对这一问题，我们对 Storage 组件的多项参数进行了调优，包括监听线程数、I/O 工作线程数、队列深度等。经过优化配置，在相同测试条件下，4K 随机读 IOPS 提升至约 500K，性能提升约 150%。
基于上述优化，考虑到块存储相比文件存储在随机小 I/O 场景更具优势，我们以全用户态存储引擎替换原有的本地文件系统作为 3FS 的落盘引擎（如下图所示）。测试结果显示，在上述参数调优的基础上，使用全用户态存储引擎后，系统资源消耗明显降低：CPU使用率下降约 27%。
图6 全用户态存储引擎
2.2 功能扩展
随着 3FS 在不同环境下的规模化应用，其在集群稳定性、存储资源利用率及性能表现方面面临多重挑战。为攻克这些技术难关，我们从多维度对 3FS 进行系统性增强：
- 高可用架构加固：通过 DNS 解耦与多网卡探测机制，实现 Mgmtd 服务的无缝切主与跨集群容错；
- 存储资源精细化管理：重构 ChainTable 生成规则与文件的 Chain 分配策略，消除容量分配不均与资源浪费；
- 端到端性能突破：使能 GPU Direct RDMA（GDR）技术，消除 HBM 到内存的冗余拷贝；
- 安全与扩展性升级：引入多租户隔离能力，支持租户级访问控制与数据物理隔离。
- Mgmtd IP 变化导致集群不可用
Mgmtd 组件负责维护 3FS 集群的全局拓扑信息和各组件的状态，一旦其他组件无法连接到 Mgmtd Primary 服务，就无法获取最新的集群状态，从而导致整个 3FS 集群处于不可用状态。
为了简化 3FS 的部署流程，我们采用了容器化部署方式。然而，在实际运行中，当 Mgmtd Pod 因进程OOM、Pod 被驱逐或节点下线等原因发生重启或迁移时，其对外暴露的 IP 地址会发生变化，导致其他组件无法重新建立与 Mgmtd 的连接，进而影响集群稳定性。
为了解决这一问题，我们在 Mgmtd Client 中引入了 DNS 解析机制，通过使用 DNS 名称替代硬编码的 Mgmtd IP 地址列表，实现对 Mgmtd 服务的高可用访问。在 Kubernetes 环境中，我们基于 Headless Service 实现该机制，使得即使 Mgmtd Pod 发生变更，其他组件也能通过固定规则的 DNS 名称自动发现并重新连接到当前的主节点，从而提升系统的容错能力与可用性。
图7 DNS 解析机制
（2）文件容量分配不均匀，无法充分利用后端存储空间
3FS 创建文件时，会按照循环的方式为文件分配 ChainTable 中连续 stripe size 数目的 Chain，实现Chain 维度的“负载均衡”，然而 ChainTable 默认的生成规则会将各个节点上相同 disk index 的盘排布在同一条 Chain 上，且这些相同盘位的 Chain 在 ChainTable 中相邻。当 stripe size 较小，Target 数目较多时，会出现文件只能使用少部分盘容量的情况，导致单文件的容量上限存在瓶颈，无法完全利用所有存储节点的空间。
为此，我们对 ChainTable 创建的分配策略进行了优化，在生成 ChainTable 的时候随机打散各个存储节点上的 Target 排布，并设置满足上述条件的最小 stripe size，使每个 3FS 文件能够充分利用后端存储空间。
图8 ChainTable生成规则优化
（3）扩容时存储空间使用不均衡，导致部分文件不可用
在 3FS 扩容过程中，由于文件创建时随机选择 Chain 列表，导致扩容前的 SSD 使用率过高，而扩容后的 SSD 存储空间使用率低，导致部分文件创建后由于后端存储占满而无法写入数据。
针对此问题，我们调整了文件分布算法，采用了基于存储使用量为优先级的分配策略，实现了更均匀的存储负载均衡，确保扩容后新创建的文件能够优先分配使用率更低的存储节点，正常读写。
（4）多网卡环境下 Mgmtd Primary 故障后，组件无法正常连接新的 Primary 节点
在多网卡环境下，当 Mgmtd Primary 节点故障导致切主时，对于新选举的 Mgmtd Primary 节点，其余组件始终无法正常连接到新的 Mgmtd Primary 节点，导致整个集群处于不可用状态。
经过定位，我们发现在 Mgmtd 切主后，其余组件会尝试对旧Primary节点的多个网卡进行探测，但仅会重试一次，导致陷入对旧 Primary 探测的循环，始终无法无法探测新的 Mgmtd Primary。基于上述分析，我们增加了重试和探测机制，使得其他组件能正常探测到新的 Primary 节点，保证了集群的可用性。
（5）节点故障时 IO 归零
多副本情况下，单个 Storage 节点故障后，出现 I/O 归零 60s，最后出现出现 I/O ERROR；I/O的写入是按照 Target 顺序逐次写入 Storage，写完所有返回成功，如果某个 Storage 节点发生故障，则会不停重试，此时 I/O 归零，当达到重试上限时，则会上报 I/O ERROR；
图9 探活storage
Fuse 发现单个 I/O 超时后，向 Mgmtd 发起探测请求，Mgmtd 将对故障的 Storage 节点进行存活探测。如果确认 Storage 节点已失活，则修改Mgmtd中缓存的路由信息，把失活 Storage 对应的 Target 状态更新为 OFFLINE，并将其持久化至 FDB 中。之后将更新的路由信息以广播的方式推送给各个节点，并把探测结果返回至 Fuse，Fuse 将根据修复后的 I/O 路径进行 I/O 重试。
图10 故障修复后I/O路径
（6）GPU Direct RDMA（GDR）使能
KVCache 数据会在计算完成后缓存在 HBM 中，将 KVCache 数据写入 3FS 需要先将 HBM 中的数据拷贝到内存中，然后再调用 USRBIO 或者 POSIX 接口将数据写入 3FS 中。HBM 到内存的拷贝往往会成为链路上的瓶颈，需要将内存 pin 住和使用专用 kernel 来解决，这无疑产生了 GPU 和 CPU 的额外开销。
因此，我们在3FS USRBIO接口中使能了 3FS 的 GDR 能力，消除了多余的内存拷贝，降低了 GPU 和CPU 的开销。如上所述，使用 3FS USRBIO 的用户进程会和 3FS Fuse Daemon 共享两个内存文件，iov和ior。其中，iov 用于保存数据块，ior 用于保存命令块。我们将 iov 中保存的数据块由真实的数据修改为HBM 的 IPC 地址，从而使得 3FS Fuse Daemon 也可以读写同一块 HBM 物理地址。
另外，由于 IBVerbs 接口的限制，我们还需要将用户进程侧的 PD 和 MR 等 IB Context 也共享给 3FS Fuse Daemon，整体实现了 3FS GDR 能力的支持。
图11 3FS GDR数据交互设计
（7）多租隔离
提供租户权限管理能力，支持访问控制隔离，租户仅可访问/显示/修改本租户文件，Meta 和 I/O 访问路径增加租户访问鉴权，禁止非法访问。
图12 3FS 多租隔离
2.3 云原生化集群管理
3FS 开源后受到业界广泛关注，其优越的性能和高可用性吸引了大量 AI 初创企业的眼光。但是 3FS 由多个关键组件构成，组件之间依赖关系复杂，传统部署方式需要手动配置各组件状态、协调组件通信，故障场景高度依赖人工干预进行恢复，导致部署流程复杂、维护成本高、系统稳定性难以保障。如何帮助这些企业更高效地部署、管理和维护 3FS，是我们在开发过程中的核心考量。
为了解决这些问题，我们开源了kvc-3fs-operator (https://github.com/aliyun/kvc-3fs-operator) 项目，支持客户物理机自建 K8s集群/阿里云ACK/ASI 等多种环境的灵活部署。3FS Operator 基于 Kubernetes 容器编排系统，提供声明式API和自动化运维能力，实现了 3FS 的一键部署、故障自愈等能力，显著提升了部署效率和系统稳定性。
（1）支持集群一键快速拉起能力，包括 Clickhouse/Monitor/FDB/Meta/Mgmtd/Storage 组件
Kubernetes Operator 是基于 Kubernetes 的一种扩展模式，通过结合自定义资源定义（CRD）与自定义控制器（Controller），实现了对复杂应用系统的自动化部署与生命周期管理。
在 3FS Operator 中，定义了一个名为 ThreeFsCluster 的 CRD 资源，用于描述 3FS 集群的配置和期望状态。Operator 通过监听该 CRD 的变更事件，驱动控制循环（Reconcile Loop），持续对比当前集群状态与目标状态之间的差异，并自动执行相应的操作（如创建Workload、调整配置、处理故障等），以确保系统始终运行在用户所期望的状态下。
图13 3FS Operator原理
（2）基于 Webhook 机制，实现 Fuse Sidecar 动态注入业务 Pod，对用户完全透明
Kubernetes Webhook 是一种通过 HTTP 接口与 Kubernetes ApiServer 交互的机制，允许用户在集群中实现自定义的准入控制（Admission Control）或其他自动化操作。
如下图所示，在 3FS Operator 中注册了一个 Mutating Admission Webhook（变更型） 服务。当用户创建带有指定标签的 Pod 时，该 Webhook 会被触发作为 Hook 调用，自动向 Pod 注入一个 3FS Fuse 容器作为 Sidecar。
同时，基于容器挂载卷的双向传播机制，Sidecar 容器中的 3FS 挂载路径会被传播到业务容器中。整个注入和挂载过程对用户完全透明。Pod 启动后，用户即可在其配置的目录中直接使用 3FS 存储，无需额外配置或修改应用代码。
图14 3FS Fuse动态注入原理
（3）FDB/Mgmtd/Meta/Storage故障自愈能力
3FS Operator 会持续监控各组件的状态信息。当检测到某个组件发生故障时，会记录其首次故障时间，并在故障持续时间达到用户预设的阈值后，判定该组件失效。此时，Operator 将启动一个新的副本替换故障副本，实现系统的自动恢复和高可用保障。
（4）集群存储弹性扩容能力
3FS Operator 支持存储弹性扩容能力，允许用户根据业务负载变化，按需定义扩容步长并动态扩展存储容量。结合我们对 3FS 文件创建时数据分布规则的优化改造，可以实现将数据均衡分布至新加入的节点上。
（5）集群滚动升级
通过更新各组件的镜像信息，可以实现对 3FS 集群的滚动升级。Operator 按照组件维度，以单个进程为粒度逐步替换旧版本镜像，确保在升级过程中始终保留足够的可用副本。这种方式有效降低了升级过程对集群整体可用性的影响，提升了系统的稳定性和运维效率。
（6）多实例支持
支持在同一 Kubernetes 集群中部署多套 3FS 集群，结合阿里云网络隔离能力（如 VPC 子网划分、安全组策略等）实现集群间隔离，提升资源利用率并降低基础设施成本，确保不同业务场景下的数据安全性与服务隔离性。系统预置二级备用节点池，可动态支持故障替换及扩容需求，保障服务的高可用性。此外，用户可通过 ECS、ACK、ASI 等环境自动化部署 3FS 客户端，实现跨集群数据访问与资源调度。
图15 3FS 多实例部署形态
（7）监控大盘接入
3FS 采用 ClickHouse 作为时序数据库，存储采集的监控指标。通过 Grafana 的 ClickHouse 插件，我们构建了统一的可视化监控大盘，实现对管控组件与数据链路组件的关键性能指标的集中展示，基于I/O分段时延高效定位系统的性能瓶颈。
图16 3FS监控大盘
3.构建高效 KVCache 存储通路：3FS 集成实践
3.1 推理引擎集成 3FS
（1）3FS USRBIO性能优化
在 SGLang 与 3FS USRBIO 的对接验证阶段，初期测试中因客户端并发度不足（单线程请求）且 I/O 提交粒度较小，导致读写带宽仅有 ~200MB/s，远低于 EGS 环境 160Gb/s 的带宽上限。为突破这一瓶颈，我们采取了以下优化策略：
- 多线程并行化改造：提高客户端并发数，每个线程独立维护私有 IOR/IOV结构，避免线程间竞争；
- I/O 聚合优化：增大 Page Size 聚合 I/O，同时增大 I/O 队列深度，通过批量提交机制提升 RDMA 网络带宽利用率；
经过上述优化，SGlang 的读写带宽成功达到网络理论上限 ~ 20GB/s，较原始方案显著提升，充分验证了 3FS USRBIO 接入方案的技术可行性和有效性。
（2）3FS 接入 SGlang/vLLM 方案
当前，我们在 SGLang 社区 & vLLM 完成了 3FS KVStore 的集成，具体设计如下：
- 3FS Hicache Backend && V****1 Connector ： 基于 3FS 的存储后端连接器，依托 libusrbio 高性能 I/O 库，实现对 3FS 存储系统的高吞吐、低延迟访问
- Global Metadata Manager： 提供分布式文件系统（FS）的元数据统一管理服务，具备高效的元数据组织、查询与协调能力，为全局 KVCache 提供一致性管理
- 3FS Global Storage： 3FS 高性能分布式存储引擎
图17 推理引擎接入3FS示意图
（3）3FS 接入推理框架性能表现
我们测试了 SGLang 在一个长上下文 QA 场景数据集的性能表现：
- 数据集：Loogle Dataset，包含近 100 组 system prompts， 21KB 前缀、20 queries/per group
- 测试模型：DeepSeek R1，H20-3e * 8卡
- 测试场景：l1、l1 + l2 host、l1 + l2 + l3 3fs、3fs 冷启动加速
- 性能提升：
- L3 Vs L1: TTFT 相比 L1 下降 78%，推理吞吐提升 520%
- L3 助力冷启动： TTFT 相比冷启动重算下降 84%，推理吞吐相比冷启动重算提升 830%
- 详情可参考：lmsys.org/blog/2025-0…
图18 SGlang接入3FS性能数据
3.2 Tair KVCache Manager 集成 3FS
Tair KVCache Manager（以下简称 KVCM）是阿里研发的全局外部 KVCache 管理组件，旨在为推理服务提供高效、可靠的 KVCache 管理服务。
KVCM 基于 HTTP/gRPC 协议对外提供服务接口，支持接入包括 3FS 在内的多种存储系统（如 KV 存储、文件系统、内存池、块存储等），并通过统一的接口层对异构存储系统进行抽象和封装，显著降低了不同存储介质接入的复杂度与开发成本。
KVCM 在系统架构中扮演关键角色，其与推理服务、3FS 等组件的交互关系如下图所示，KVCM 实现了 KVCache 与 3FS 文件数据物理位置的动态映射，推理服务通过 KVCM 的统一接口访问 KVCache 数据的存放位置并通过挂载的 3FS Fuse 服务访问数据，减少其直接管理底层存储系统的复杂性。
图19 KVCM接入3FS示意图
在 KVCM 与 3FS Backend 的对接中，KVCM 对 3FS 文件的操作依赖于 3FS Fuse 的挂载，且强依赖 RDMA 环境。然而，在跨集群部署场景下，这种强耦合关系显著限制了 KVCM 部署的灵活性和扩展性。与此同时，传统基于海量小文件的分配方式虽易于实现，但频繁的元数据操作导致后端元数据服务访问压力加大，进而引发系统吞吐能力下降与性能瓶颈。为此，我们针对上述挑战提出了以下优化方案：
（1）KVCM 与 3FS Fuse 解耦设计
为提升 KVCM 在非 RDMA 环境中部署的灵活性，我们在 3FS Operator 中引入了轻量级的 3FS Master 组件。该组件是无状态服务，采用多实例部署模式，通过 HTTP 接口对外提供 POSIX 兼容的 create/delete 等基础语义，有效解耦了 KVCM 与 3FS Fuse 的依赖关系。
（2）3FS ****元数据优化策略
为降低 3FS 元数据操作的开销，我们采用大文件 + 支持多种 Block Size 的 Slab 细粒度分配器策略：客户端仅需打开少量大文件并缓存文件信息，避免频繁访问后端存储的元数据服务；通过 Slab 分配器实现细粒度内存管理，减少文件创建/删除操作的频率，降低对后端存储元数据服务的压力，提升系统整体吞吐能力。
图20 KVCM 3FS Allocator设计
关于 KVCM 的更多设计细节、使用场景及配置指南，将在后续技术文章中详细展开。
4.Future Work
4.1 3FS产品化能力持续建设
展望未来，3FS 将始终以 KVCache 为核心的高性能存储需求为导向，在多个技术维度持续深化创新。系统将从智能化运维管理、企业级多租户安全、KV语义原生支持、极致高可用保障以及软硬协同优化等关键领域入手，构建专为 KVCache 场景量身定制的技术体系。
（1）持续增强 3FS Operator 的 CRD 配置能力与部署灵活性： 通过增强 3FS Operator 的自定义资源定义的配置能力，系统将具备更为精细化的资源配置和管理功能，能够根据不同的业务负载特征和性能要求进行智能化调整。同时，扩展 3FS Operator 的能力边界，使其能够在更丰富的业务场景中更灵活地支持客户自定义部署需求。
（2）QoS： 构建完善的多租户支持体系，结合现有的用户鉴权机制，引入 QoS 保障机制，能够根据租户的业务优先级和资源配额进行动态资源调度和性能保障，避免租户间的资源争用和性能干扰，为云原生环境下的共享存储需求提供企业级的安全性和稳定性保障。
（3）客户端形态升级与 KV 语义原生支持： 对现有客户端架构进行全面升级，原生支持键值（KV）语义操作。通过提供简洁高效的 KV API 接口，降低应用开发的复杂性，为构建高性能的 KVCache 系统提供更加便捷的技术基础。
（4）产品力持续强化与故障自愈能力提升： 持续加强 3FS 的产品力，通过引入动态副本迁移重构等机制，进一步降低故障场景下对上层业务可用性的影响，最大程度地保障业务连续性，为关键业务场景提供企业级的高可用性保障。
（5）落盘引擎优化与硬件协同深度融合： 持续优化 3FS 落盘引擎的性能表现，深度结合阿里云服务器自研的 AliFlash SSD 和 AliSCM 等新型存储硬件的特性和优势。通过软硬协同的深度优化，充分发挥新型硬件的性能潜力，提供软硬件结合的解决方案，为用户提供极致的存储性能体验。
4.2 服务器硬件能力持续升级
随着AI应用场景的多样化与复杂化需求持续增长，阿里云服务器团队自研的 AI SSD 及磐久存储服务器平台将持续迭代优化，以精准适配AI业务的动态需求。我们致力于为AI推理场景打造以 KVCache 为核心的一体化端到端基础设施，通过软硬协同的深度优化，构建高效、智能的AI技术底座。
（1）存储硬件优化： 匹配 GPU 算力，计算网络带宽，存储提供高低延迟，高 IOPS，高带宽能力的 AI SSD
（2）计算存储优化： GPU 直通存储存储降低延迟，消除内存墙影响，存储KV接入模式优化
（3）存储系统优化： 以 KVCache 管理系统为中心数据 placement 策略，提供专属存储引擎，降低文件系统开销
（4）增值能力优化： 数据压缩，分层淘汰，数据感知及任务调度，任务队列预取，热数据pin/unpin等能力加强
图21 面向KVCache的端到端方案
5.了解更多
欢迎搜索钉钉群号：109765011301入群与技术专家交流！
