深入SGLang HiCache与LMCache：两大KV Cache卸载方案，我该选哪个？

深入解析SGLang HiCache与LMCache：KV Cache卸载技术选型指南

在大模型推理服务中，KV Cache管理是影响性能的关键因素之一。随着模型规模的不断扩大，KV Cache占用的显存资源也急剧增加，如何高效管理这些缓存成为技术团队必须面对的挑战。本文将深入探讨SGLang内置的HiCache与社区方案LMCache两大KV Cache卸载方案，从架构设计到实际应用场景，为技术决策者提供全面的选型参考。

1. KV Cache卸载技术概述

KV Cache（键值缓存）是大模型推理过程中用于存储注意力机制中间结果的关键数据结构。随着上下文长度的增加，KV Cache的显存占用会线性增长，这对GPU资源提出了极高要求。KV Cache卸载技术正是为了解决这一问题而诞生的。

KV Cache卸载的核心目标是将部分缓存数据从昂贵的GPU显存转移到成本更低的存储层级（如CPU内存、磁盘或远程存储），从而显著降低显存压力。这一技术特别适合以下场景：

• 长上下文推理任务（如文档摘要、代码生成）
• 多并发请求服务环境
• 资源受限的边缘部署场景

目前主流的KV Cache卸载方案可分为两类：引擎内置方案（如SGLang HiCache）和独立中间件方案（如LMCache）。这两种方案在架构设计和实现细节上存在显著差异，直接影响其适用场景和性能表现。

2. 架构设计对比

2.1 HiCache的统一Radix Tree设计

SGLang HiCache采用了一种高度集成的架构设计，其核心特点是使用统一的Radix Tree管理多级存储。这种设计将GPU和CPU的KV Cache视为一个逻辑整体，通过单一数据结构进行管理。

HiCache的关键架构特点：

• 层级固定：严格划分为三层存储（GPU→CPU→后端存储）
• 统一索引：所有层级的缓存数据共享同一棵Radix Tree
• 写策略多样：支持write_back、write_through和write_through_selective三种策略
• 内存布局优化：提供layer_first和page_first两种内存布局选项

# HiCache初始化示例 self.tree_cache = HiRadixCache( req_to_token_pool=self.req_to_token_pool, token_to_kv_pool_allocator=self.token_to_kv_pool_allocator, hicache_ratio=server_args.hicache_ratio, hicache_write_policy=server_args.hicache_write_policy, hicache_mem_layout=server_args.hicache_mem_layout, hicache_storage_backend=server_args.hicache_storage_backend )

这种设计的优势在于减少了数据移动时的元数据开销，但由于层级固定，在需要扩展额外存储层级时会受到限制。

2.2 LMCache的独立层级管理

与HiCache不同，LMCache采用了更加模块化的设计，每个存储层级都是独立管理的。这种架构源于其作为独立中间件的定位，需要适配不同的推理引擎。

LMCache的架构特点：

• 层级灵活：支持任意数量的存储层级（至少包含CPU、Disk、Remote三层）
• 独立管理：每个层级可以自由选择数据结构（哈希表或Radix Tree）
• 异步操作：写入操作支持全异步，但GPU-CPU拷贝仍需同步
• 按chunk管理：默认以256个token为单元进行存储，与引擎page size解耦

注意：LMCache的ref_count需要手动管理，这是其架构中一个容易出错的点。错误的ref_count可能导致内存泄漏或提前释放等问题。

LMCache的这种设计使其具有更好的扩展性，可以轻松集成新的存储后端，但也带来了更高的实现复杂度。

3. 存储层级与后端支持

3.1 HiCache的存储后端选项

HiCache虽然层级固定，但在后端存储支持上提供了丰富的选项：

HiCache的后端集成采用插件化设计，只需实现三个基本接口即可接入新存储：

class StorageBackend: def get(self, key: str) -> torch.Tensor: ... def exists(self, key: str) -> bool: ... def set(self, key: str, value: torch.Tensor) -> bool: ...

这种简洁的接口设计降低了集成难度，但也限制了后端实现的灵活性——所有后端都必须适配HiCache的统一管理方式。

3.2 LMCache的多级存储扩展

LMCache在存储层级管理上更为灵活，其特点包括：

• Remote存储支持：原生支持3FS、Mooncake等远程存储方案
• 层级动态扩展：可以通过配置添加新的存储层级
• 并发写入：支持同时向多个层级写入数据
• 独立驱逐策略：每个层级可以实施不同的缓存替换算法

LMCache存储层级工作流程：

1. 写入时，数据同时发送到所有配置的存储层级
2. 读取时，按层级优先级依次查找（GPU→CPU→Disk→Remote）
3. 驱逐时，各层级独立管理自己的存储空间

这种设计特别适合需要混合本地和远程存储的场景，但也带来了更复杂的一致性管理挑战。

4. 性能特征与优化策略

4.1 HiCache的性能优化手段

HiCache在性能优化方面做了大量工作，主要包括：

• GPU辅助I/O内核：相比标准cudaMemcpyAsync，吞吐量提升最高达3倍
• 内存布局优化：page_first布局优先考虑I/O效率，提升传输吞吐量
• 零拷贝机制：减少数据移动开销，典型部署中吞吐量提升2倍
• 预取策略：提供best_effort、wait_complete、timeout三种预取模式

# HiCache性能相关配置参数 --hicache-io-backend choices=["direct", "kernel"] # I/O后端选择 --hicache-mem-layout choices=["layer_first", "page_first"] # 内存布局 --hicache-storage-prefetch-policy choices=["best_effort", "wait_complete", "timeout"] # 预取策略

这些优化使得HiCache在数据移动密集型任务中表现优异，特别是在需要频繁在GPU和CPU之间传输数据的场景。

4.2 LMCache的异步与同步权衡

LMCache在性能设计上做出了不同的取舍：

• 异步写入：磁盘写入完全异步，减少对推理流程的阻塞
• 同步拷贝：GPU-CPU数据移动仍需同步，成为潜在瓶颈
• chunk化管理：以固定大小单元管理数据，优化I/O吞吐
• 合并存储：支持所有layer合并存储，减少小文件I/O

提示：LMCache的异步设计虽然提升了吞吐量，但也增加了调试难度，特别是在处理错误时难以确定数据的确切状态。

LMCache的性能特征使其更适合对延迟不敏感但需要高吞吐的场景，特别是当工作集远大于GPU显存容量时。

5. 实际应用与选型建议

5.1 部署环境考量

选择HiCache或LMCache应首先考虑实际的部署环境：

适合HiCache的场景：

• 完全基于SGLang的技术栈
• 存储层级需求简单（只需GPU+CPU+单一后端）
• 需要深度引擎集成优化
• 对代码侵入性敏感的项目

适合LMCache的场景：

• 多引擎环境（如同时使用SGLang和vLLM）
• 需要复杂存储层级（如本地+远程混合）
• 团队具备中间件开发和调试能力
• 需要灵活扩展存储后端的项目

5.2 性能需求分析

不同性能需求也会影响方案选择：

5.3 迁移与集成建议

对于考虑从一种方案迁移到另一种的团队，建议采取以下步骤：

1. 评估现有架构：明确当前方案的瓶颈和需求变化
2. 小规模测试：在非关键业务流上验证新方案
3. 性能基准测试：使用真实工作负载比较关键指标
4. 渐进式迁移：逐步替换组件，监控系统稳定性
5. 调优参数：根据实际负载调整缓存比例、写策略等

对于需要同时支持两种方案的环境，SGLang提供了--enable-hierarchical-cache和--enable-lmcache的兼容配置，但需注意避免同时启用导致的资源竞争。