跳到正文
原文
LMSYS:Blog(Chatbot Arena 团队)·· 2 小时前精选AI 评分66

SGLang 发布 HiCache:分层 KV 缓存支持 Mooncake、3FS、NIXL 等存储后端

Blog SGLang HiCache: Fast Hierarchical KV Caching with Your Favorite Storage Backends In a coding agent scenario using Qwen3-Coder-480B, the observed dialogues often stretched past 25K tokens around 8 turns per session. Without full KV cache retention, nearly every request required cos... Zhiqiang Xie September 10, 2025

AI 导读

SGLang 团队发布 HiCache,通过 HiRadixTree 和缓存控制器把 RadixAttention 的 KV 缓存从 GPU 显存扩展到 CPU 内存及磁盘、远程存储等外部层级。

推荐理由

原文给出 HiCache 的架构设计和多组实测数据,还说明接入新存储后端只需实现三个接口,便于复现和选型。

正文 · AI 翻译

在使用 Qwen3-Coder-480B 的编码代理场景中,观察到的对话往往在每会话约 8 轮时超过 25K token。如果没有完整的 KV 缓存保留,几乎每个请求都需要昂贵的重新计算。通过将 SGLang HiCache 与 DeepSeek 3FS KVStore 集成以实现大规模历史 KV 缓存,会话的平均 TTFT 下降了 56%,推理吞吐量翻倍,缓存命中率从 40% 跃升至 80%。”

– Novita AI

有效的 KV 缓存通过消除冗余且昂贵的重新计算,显著降低了 TTFT。将 SGLang HiCache 与 Mooncake 服务集成可实现可扩展的 KV 缓存保留和高性能访问。在我们的评估中,我们使用从通用问答场景中采样的内部在线请求,在 PD 分离部署下测试了 DeepSeek-R1-671B 模型。平均而言,与完全重新计算相比,缓存命中使 TTFT 降低了 84%。

– 蚂蚁集团

我们还在本博客末尾提供了在长上下文基准和多轮对话基准上复现性能提升的说明。在我们的测量中,HiCache 实现了高达 6 倍的吞吐量提升和高达 80% 的 TTFT 降低,与社区报告的结果高度一致。除了上述的 3FS 和 Mooncake 存储后端外,SGLang 还支持 NIXL 以及本地文件后端。

为什么分层 KV 缓存很重要

复用历史 KV 缓存已被证明对高性能 LLM 服务系统至关重要。我们之前介绍的 RadixAttention 通过复用存储在 GPU 内存中的 KV 缓存实现了最先进的性能。然而,缓存收益不可避免地受到容量瓶颈的限制:随着上下文变得更长、更多客户端参与更多轮对话,缓存命中率会下降,因为大多数历史 KV 缓存必须被逐出以腾出空间给新数据。

为了应对这一挑战,我们提出了 SGLang HiCache,它通过 HiRadixTree 扩展了 RadixAttention,HiRadixTree 充当页表,用于引用驻留在本地 GPU 和 CPU 内存中的 KV 缓存。同时,缓存控制器自动管理跨层级(包括 GPU 和 CPU 内存池以及磁盘和远程内存等外部层)的 KV 缓存数据的加载和备份。下图展示了 SGLang HiCache 的概览。

SGLang HiCache 的设计:

优化的数据平面

分层内存系统的关键瓶颈是将数据从较慢层级移动到较快层级的延迟。除了标准的 cudaMemcpyAsync 之外,我们还开发了一组 GPU 辅助 I/O 内核,可为 CPU–GPU 传输提供高达 3 倍的吞吐量。

为了进一步加速 CPU 内存与存储层之间的数据移动,借助已实现的内核,我们将主机内存池的布局与 GPU 布局解耦,如图 1 所示。GPU 内存池保持不变,仍采用“层优先”风格以兼容计算内核,而 HiCache 对其他层使用“页优先”布局以优先考虑 IO 效率。这使得每次事务的传输大小更大,并与零拷贝机制结合,在典型部署中实现高达 2 倍的吞吐量。您可以参考 PR(Mooncake、3FS)了解更多详情。

多功能的控制平面

当 GPU 发生缓存未命中但命中 CPU 内存时,由于两层之间的带宽通常很高,我们采用逐层重叠机制来加载数据。这使得在层 N 执行的同时,可以并发地为层 N+ 加载 KV 缓存,从而有效地将数据传输延迟隐藏在计算之后。 当涉及外部存储时,一旦在存储层检测到缓存命中,缓存控制器就会机会性地从存储中预取数据到主机内存。预取策略是可配置的:它可以以尽力而为模式运行,如果某个请求到了调度时间就终止正在进行的预取以最小化 TTFT,或者更积极地暂存请求以提高缓存复用率并可能提升整体吞吐量。

存储层采用这种不同的设计选择,是因为与主机到 GPU 的传输相比,存储的延迟通常显著更高且更难以预测,而当性能权衡有利时,我们仍对 GPU Direct Storage 等技术持开放态度。 SGLang HiCache 还支持多种缓存写入策略,用于将数据从较快的层级移动到较慢的层级。如果带宽允许,写穿策略能提供最强的缓存收益,而选择性写穿模式则利用命中计数跟踪,仅备份热点数据,从而降低 I/O 负载。在较慢的内存层级也面临容量限制的情况下,写回策略可以有效地缓解压力。

选择你最喜欢的存储后端,或者自带一个!

SGLang HiCache 最棒的地方在于接入新的存储后端是如此简单。得益于我们简洁、通用的接口,集成只需在你的后端中实现三个功能:get(key)、exist(key)、set(key, value)。其他所有内容,包括调度和同步协调等繁重任务,都由中央缓存控制器处理。

这一设计已经使我们能够集成三个高性能后端——Mooncake、3FS 和 NIXL——还有更多正在路上。为了演示目的,我们还提供了一个简单的 HiCacheFile 后端作为参考。我们也在进行 HiCache 与 PD 分离的协同设计和性能优化。我们热烈欢迎贡献和社区反馈,无论是关于新的调度策略、重构现有设计、可观测性功能、并行策略的兼容性,还是对更多后端的支持。

基准测试

亲自体验性能提升吧!你可以在这里找到关于 HiCache 的各种基准测试。下面我们重点展示使用所提供的基准测试脚本得到的两个基准测试结果,你可以在这里找到后端的配置说明。如果你对基准测试或部署有任何疑问,欢迎在 GitHub 上提交 issue 或在我们slack 频道中发帖。

3fs_benchmark.png

# 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 

mooncake_benchmark.png

# 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

我们还想重点介绍 NIXL 作为一个特殊的后端,它是一个传输库,旨在桥接 GPU 直连存储和云对象存储等存储后端。你可以在这里找到更多细节,并敬请期待即将与 Dynamo 生态系统的集成。

致谢:

我们衷心感谢社区给予的巨大支持和反馈。 我们感谢阿里云 TairKVCache 团队的 Sicheng Pan、Zhangheng Huang、Yi Zhang、Jianxing Zhu 和 Yifei Kang 在 3FS 后端集成方面所做的工作; 感谢蚂蚁集团的 Tingwei Huang 和 Yongke Zhao;阿里云的 Teng Ma、Shangming Cai 和 Xingyu Liu;Approaching.AI 的 Jinyang Su 和 Ke Yang;以及 Mooncake 社区的 Zuoyuan Zhang 和 Mingxing Zhang 在 Mooncake 集成方面所做的努力; 感谢 NVIDIA 的 Moein Khazraee、Vishwanath Venkatesan 以及 Dynamo 团队促成 NIXL 集成。 特别感谢 SGLang 团队的 Ziyi Xu、LMCache 的 Yuwei An、NVIDIA 的 Vikram Sharma Mailthody、Scott Mahlke 和 Michael Garland,以及斯坦福大学的 Mark Zhao 和 Christos Kozyrakis 对 HiCache 设计与实现所做的贡献。 最后,我们感谢 LMCache、AIBrix、PrisDB 和 ByteDance EIC 团队持续不断的贡献,将他们的产品带入生态系统。

来源:LMSYS:Blog(Chatbot Arena 团队) · lmsys.org