SGLang HiCache: Fast Hierarchical KV Caching with Your Favorite Storage Backends

发表时间: 2025-09 · Blog post by Zhiqiang Xie (lmsys.org)

原文: https://lmsys.org/blog/2025-09-10-sglang-hicache

作者/机构：Zhiqiang Xie
发布日期：September 10, 2025

速读

一句话结论 SGLang HiCache 通过引入支持多种存储后端的层级化 KV Cache 架构，打破了单一 GPU 显存的容量瓶颈，在长上下文和多轮对话场景下将首 token 延迟（TTFT）降低了最高 80%，并实现了最高 6 倍的吞吐量提升。

要解决什么问题 大语言模型在推理时，复用历史 KV Cache（键值缓存）是避免冗余计算、降低首 token 延迟的关键手段。现有的主流做法主要将 KV Cache 存储在 GPU 显存中，这直接导致了一个严峻的机制卡点：显存容量瓶颈。随着用户输入的上下文越来越长，以及多轮对话交互次数的增加，GPU 显存很快就会被填满。为了给新的请求数据腾出空间，系统不得不频繁驱逐历史 KV Cache。当这些被驱逐的历史会话再次被请求时，系统只能退回到代价高昂的全量重新计算状态。这种因存储容量受限导致的缓存命中率断崖式下跌，不仅极大拖慢了长文本和复杂 Agent 场景下的响应速度，也严重限制了推理系统的整体并发吞吐量。

怎么做的 核心思路是将局限于 GPU 显存的缓存机制，扩展为跨越 GPU、CPU 及外部存储（如磁盘和远程内存）的多级缓存架构。为绕开显存容量限制，SGLang HiCache 在 RadixAttention 基础上引入 HiRadixTree 作为页表，统一寻址和管理各层 KV Cache。关键设计由三个部件构成：第一是优化的数据面。多级存储的核心瓶颈是跨层数据搬运延迟。作者开发了 GPU 辅助的 I/O kernel，将 CPU 到 GPU 的传输吞吐量提升最高 3 倍。同时对内存布局进行解耦：GPU 显存保留“层优先”（layer-first）布局以兼容计算，而 CPU 及外部存储采用“页优先”（page-first）布局以最大化 I/O 效率。结合零拷贝机制，单次事务能传输更大块数据，吞吐量提升最高 2 倍。第二是灵活的控制面。当 GPU 未命中但 CPU 命中时，系统采用逐层重叠机制，在计算第 $N$ 层时并发加载第 $N+1$ 层，将传输延迟隐藏在计算背后。对于更慢的外部存储，控制器会在命中时触发机会性预取，提前拉入主机内存。预取策略可配：可尽力而为，或在请求需调度时立即终止以保证极低 TTFT，亦或激进暂存请求以提升吞吐。数据下沉支持多种写入策略：带宽充足用直写（write-through）；为降负载用选择性直写（write-through-selective）仅备份热点；慢速层容量告急时切换为回写（write-back）。第三是标准化存储接口。复杂调度收敛于中央控制器，外部存储只需实现 get、exist 和 set 三个接口，即可无缝接入 3FS、Mooncake 或 NIXL 等后端。

效果如何 实验在长上下文问答（Loogle Wiki QA）和多轮对话基准下进行。硬件与模型包括：8 张 H20-3e 运行 DeepSeek-R1（结合 3FS），以及 8 张带 RDMA 网卡的 H800 运行 Qwen3-235B-A22B-Instruct-2507（结合 Mooncake，模拟 Prefill-Decode 分离）。对比基线为显存耗尽后必须全量重算的传统 GPU 缓存方案。结果显示，SGLang HiCache 实现最高 6 倍吞吐量提升，首 token 延迟降低最高 80%。在社区生产环境（480B 模型代码 Agent，单会话 8 轮、超 25K tokens）中，命中率从 40% 升至 80%，平均 TTFT 下降 56%；通用问答线上采样中，TTFT 相比全量重算降低 84%。局限性在于，外部存储延迟高且不可预测，预取策略需严格权衡（如随时准备终止传输）；且当慢速层也达容量极限时，系统仍面临存储压力，需依赖回写策略缓解。

A1 主要贡献

大型语言模型（LLM）在长上下文和多轮对话场景中，由于GPU内存容量的瓶颈，历史KV缓存往往被迫驱逐，导致极其昂贵的重新计算开销。本文提出了SGLang HiCache，这是一个支持多种存储后端的高效分层KV缓存系统。其主要贡献如下：

  1. 架构扩展：在RadixAttention的基础上引入了HiRadixTree，作为统一管理GPU和CPU本地内存中KV缓存的页表。
  2. 多级存储调度：设计了智能缓存控制器（Cache Controller），自动管理跨GPU内存、CPU内存以及外部层（如磁盘、远程内存）的KV缓存数据加载与备份。
  3. 极简的后端集成：提供通用的即插即用接口，已成功集成DeepSeek 3FS、Mooncake和NIXL等高性能存储后端。
  4. 显著的性能提升：在社区实际业务与基准测试中，HiCache实现了高达6倍的吞吐量提升，将首Token时间（TTFT）降低了80%，并将缓存命中率从40%大幅提升至80%。
图1 SGLang HiCache架构概览
图1 SGLang HiCache架构概览

A3 背景知识与关键观察

长上下文与多轮对话带来的重计算痛点：在实际的LLM服务中，重用历史KV缓存已被证明是实现高性能的关键。尽管先前引入的RadixAttention【1，RadixAttention+2023+arXiv:2312.07104】通过重用驻留在GPU内存中的KV缓存实现了最先进的性能，但这种缓存增益不可避免地受到了容量瓶颈的限制。随着上下文不断增长以及更多客户端参与更多轮次的对话，大部分历史KV缓存必须被驱逐以腾出空间给新数据，直接导致缓存命中率急剧下降。来自社区的真实观察印证了这一痛点：

  • Novita AI的观察：在使用Qwen3-Coder-480B的编码智能体场景中，单次会话约8轮后，对话长度通常会超过25K个Token。如果不保留完整的KV缓存，几乎每个请求都需要进行昂贵的重新计算。
  • 蚂蚁集团的观察：在通用问答（QA）场景下，使用DeepSeek-R1-671B模型进行预填充-解码分离（PD-disaggregated）部署时，有效的KV缓存对于消除冗余重计算、降低TTFT具有决定性作用。

为了彻底解决这一容量瓶颈，SGLang HiCache应运而生，通过分层存储架构将缓存容量扩展至主机内存及外部存储系统。

A2 方法细节

优化数据平面（Optimized data plane）：在分层内存系统中，核心的性能瓶颈在于数据从慢速存储层向快速存储层移动的延迟。为了突破标准cudaMemcpyAsync的限制，作者开发了一套GPU辅助的I/O内核（GPU-assisted I/O kernels），该内核专门用于优化数据传输，使得CPU到GPU的数据传输吞吐量提升了高达3倍。在这些高性能内核的支持下，为了进一步加速CPU内存与更底层存储层之间的数据移动，HiCache将主机内存池的布局与GPU内存池的布局进行了解耦。具体而言，为了保持与底层计算内核的兼容性，GPU内存池依然维持“层优先”（layer-first）的布局风格；而对于其他存储层，HiCache则采用了“页优先”（page-first）的布局，以此来优先保障I/O操作的效率。这种解耦设计允许系统在每次事务中进行更大规模的数据传输，当它与零拷贝（zero-copy）机制相结合时，在典型部署场景下实现了高达2倍的吞吐量提升。

图2 主机内存与GPU内存布局解耦设计
图2 主机内存与GPU内存布局解耦设计

多功能控制平面（Versatile control plane）：为了掩盖数据传输延迟并优化存储I/O，HiCache在控制平面设计了多种高级机制。当GPU发生缓存未命中但CPU内存命中时，鉴于CPU与GPU两层之间通常具有较高的带宽，系统会应用一种逐层重叠机制（layer-wise overlapping mechanism）【2，Layer-wise overlapping+2024+arXiv:2403.19708】来加载数据。该机制允许在计算执行第$N$层的同时，并发加载第$N+$层的KV缓存，从而有效地将数据传输延迟完全隐藏在计算过程之后。当涉及到外部存储（external storage）时，由于存储层的延迟通常比主机到GPU的传输高得多且更难以预测，缓存控制器采取了不同的策略：一旦在存储层检测到缓存命中，控制器会机会性地将数据从存储层预取（prefetch）到主机内存中。预取策略是高度可配置的，包含三种模式：

  1. 尽力而为模式（best-effort mode）：在后台尽可能多地预取数据。
  2. 终止飞行中预取（terminate in-flight）：如果某个请求已满足调度条件，系统会立即终止正在进行的预取操作，以最小化首Token时间（TTFT）。

  3. 激进暂存（stage requests aggressively）：更激进地暂存请求以提高缓存重用率，从而潜在地提升系统整体吞吐量。
    此外，SGLang HiCache还支持多种缓存写入策略（cache write policies），用于管理数据从快速层向慢速层的移动：

  4. 直写（write-through）：在带宽允许的情况下，提供最强的缓存增益，确保所有层数据一致。

  5. 选择性直写（write-through-selective）：利用命中计数跟踪（hit-count tracking），仅将热点数据备份到慢速层，从而大幅降低I/O负载。
  6. 回写（write-back）：在较慢的内存层也面临容量限制的情况下，此策略可有效缓解存储压力。
    作者还指出，在性能权衡有利的情况下，对引入如GPU Direct Storage等技术持开放态度。

存储后端的即插即用设计（Pick your favorite storage backend）：SGLang HiCache的核心优势在于其极简的后端接入能力。得益于干净且通用的接口设计，集成一个新的存储后端只需要实现三个最基本的功能：get(key)、exist(key)和set(key, value)。除此之外的所有繁重任务，包括复杂的调度逻辑和多层级之间的同步协调，均由中央缓存控制器（central cache controller）统一处理。基于这一设计，系统目前已成功集成了三个高性能后端：Mooncake【3，Mooncake GitHub】、3FS【4，3FS GitHub】和NIXL【5，NIXL GitHub】。此外，系统还提供了一个简单的HiCacheFile后端作为参考实现。目前，团队正在积极推进HiCache与预填充-解码分离（PD Disaggregation）架构的协同设计与性能优化。

A4 实验环境

  • 测试场景：长上下文基准测试（Long-context benchmark）、多轮对话基准测试（Multi-turn conversation benchmark）、通用问答场景（General QA，基于蚂蚁集团内部在线请求采样）、编码智能体场景（Coding agent，基于Novita AI业务）。

  • 模型配置：

    • Qwen3-Coder-480B（Novita AI场景）。
    • DeepSeek-R1-671B（蚂蚁集团场景）。
    • DeepSeek-R1（3FS基准测试，张量并行TP=8，上下文长度65536，分块预填充大小6144）。
    • Qwen3-235B-A22B-Instruct-2507（Mooncake基准测试，张量并行TP=8，请求长度2048）。

  • 硬件配置：

    • 3FS测试环境：8 × H20-3e GPU。
    • Mooncake测试环境：8 × H800 GPU，配备 8 × mlx5 RDMA 网卡。

  • 软件与存储配置：SGLang（开启--enable-hierarchical-cache），DeepSeek 3FS KVStore（配置为hf3fs，页面优先布局，wait_complete预取策略），Mooncake服务（使用RDMA协议，全局段大小约816GB，timeout预取策略）。

A5 实验结果

1. 社区生产环境验证结果

  • Novita AI (Qwen3-Coder-480B + 3FS)：通过集成HiCache与DeepSeek 3FS KVStore进行大规模历史KV缓存，单会话平均TTFT大幅下降了56%，推理吞吐量翻倍（2倍提升），并且缓存命中率从40%跃升至80%。
  • 蚂蚁集团 (DeepSeek-R1-671B + Mooncake)：在PD分离部署下处理通用QA在线请求，测试表明，与完全重新计算相比，缓存命中平均使TTFT降低了84%。

2. 官方基准测试结果
在长上下文和多轮对话基准测试中，官方测量结果与社区报告高度一致：HiCache实现了高达6倍的吞吐量提升，并将TTFT降低了高达80%。

3FS后端基准测试（长上下文）：
在8张H20-3e上运行DeepSeek R1，使用3FS后端。启动与测试脚本如下：

# DeepSeek R1 on 8 * H20-3e using 3FS
python3 -m sglang.launch_server  --model-path /DeepSeek-R1/ --tp 8 --page-size 64 \
--context-length 65536 --chunked-prefill-size 6144 --mem-fraction-static 0.85 \
--enable-hierarchical-cache --hicache-ratio 2 \
--hicache-io-backend kernel --hicache-mem-layout page_first \
--hicache-storage-backend hf3fs --hicache-storage-prefetch-policy wait_complete 

python3 bench_long_context.py --model-path /DeepSeek-R1/ --dataset-path loogle_wiki_qa.json
图3 3FS基准测试结果
图3 3FS基准测试结果

Mooncake后端基准测试（多轮对话/PD分离模拟）：
在配备RDMA网卡的8张H800上运行Qwen3-235B-A22B-Instruct-2507，使用Mooncake后端模拟P-D分离场景。启动与测试脚本如下：

# Qwen3-235B-A22B-Instruct-2507 on 8 × H800 GPUs with 8 × mlx5 RDMA NICs using Mooncake
MOONCAKE_TE_META_DATA_SERVER="http://127.0.0.1:8080/metadata" \
MOONCAKE_GLOBAL_SEGMENT_SIZE=816043786240, MOONCAKE_PROTOCOL="rdma" \
MOONCAKE_DEVICE="$DEVICE_LIST", MOONCAKE_MASTER=127.0.0.1:50051 \
python3 -m sglang.launch_server --model-path $MODEL_PATH --tp 8 --page-size 64 \
--enable-hierarchical-cache --hicache-ratio 2 \
--hicache-storage-prefetch-policy timeout --hicache-storage-backend mooncake

python3 benchmark/hicache/bench_multiturn.py --model-path $MODEL_PATH --disable-random-sample \
--output-length 1 --request-length 2048 \ # simulate P-D disaggregation
--num-clients 80 --num-rounds 10 --max-parallel 4 --request-rate 16 \
--ready-queue-policy random --disable-auto-run --enable-round-barrier
图4 Mooncake基准测试结果
图4 Mooncake基准测试结果

A7 补充细节

关于NIXL后端的特殊设计：
在支持的存储后端中，作者特别强调了NIXL作为一个特殊的后端实现。NIXL本质上是一个传输库（transfer library），其核心设计目标是作为桥梁，连接诸如GPU直接存储（GPU-direct storage）和云对象存储（cloud object storage）等底层存储后端。该集成由NVIDIA的Dynamo团队协助完成，未来HiCache将进一步与Dynamo生态系统进行深度整合。

(注：本文档还特别致谢了来自阿里云TairKVCache团队、蚂蚁集团、Approaching.AI、Mooncake社区、NVIDIA Dynamo团队、SGLang团队、Stanford大学以及LMCache、AIBrix、PrisDB和字节跳动EIC团队在设计、实现及生态接入方面的贡献。)