HyMCache: A KV Cache Framework for Multi-Turn LLM Serving with CXL-Hybrid Memory

一、论文概述

项目	内容
标题	HyMCache: A KV Cache Framework for Multi-Turn LLM Serving with CXL-Hybrid Memory
作者	Hakbeom Jang¹, Inho Song², Sam H. Noh², Jongryool Kim¹
机构	¹SK hynix America, ²Virginia Tech
论文	arXiv:2607.18141
HTML	arXiv HTML
代码	未公开
发布	2026-07-20 (cs.DC)
许可	未明确
基于	vLLM 0.19.0 + Dynamo v1.1.0

二、核心思想

问题定义

随着LLM推理从单轮提示演变为长上下文、多轮对话和Agentic应用，KV缓存复用成为降低重复计算的关键。Agent轨迹常跨越数十至数百轮，超过95%的token可跨轮复用。但KV缓存复用将瓶颈从计算层转移到了存储和分发可复用KV状态的内存层。

在集群规模下，GPU HBM和主机DRAM的成本过高，无法经济地扩展到TB级共享上下文容量。现有的远程KV缓存方案面临两难：

纯DRAM方案（如Mooncake）：成本低但容量受限，1TB DRAM仅覆盖1.5TB footprint的2/3
SSD方案：容量大但延迟高，XFS文件系统叠加使顺序读带宽从23 GB/s降至~6.5 GB/s

解决方案概述

HyMCache提出了一种结合**CXL混合内存（CXL-HM）**的KV缓存框架。CXL-HM是一种将少量片上DRAM与大容量SSD结合的CXL设备，通过CXL.mem接口向主机暴露SSD-backed容量，同时利用内部DRAM作为透明缓存层。

CXL-HM部署模型

HyMCache的核心洞察是：多轮LLM服务的KV缓存访问模式具有读主导、可预测、追加写入的特征，这与通用工作负载完全不同。通用CMM-H产品的LRU缓存策略不适合KV缓存场景——LRU会被”一次命中”的KV块污染缓存，而真正需要的下一轮前缀块仍留在SSD中。

多轮LLM服务中的CXL-HM机会

HyMCache通过两个关键设计解决这个问题：

请求级前缀预取（Request-level prefix prefetching）：利用多轮前缀缓存的可预测性，在前景读取到达之前将KV块预取到CXL-HM内部DRAM中
机会性写缓冲（Opportunistic write buffering）：将写入路径与读路径隔离，异步批量刷写KV块到SSD，避免读写干扰

在相同DRAM预算下，HyMCache在单节点服务中比本地LMCache快3.0×，在PD分离式服务中快1.45×。与1TB分布式DRAM的Mooncake相比，HyMCache性能约低30%，但DRAM用量减少16×。

CXL-HM vs 传统DRAM-SSD分层

RDMA远程访问路径对比

关键区别在于访问路径：

传统DRAM-SSD分层：LLM worker → 元数据服务器 → 存储节点（第二次元数据查找判断DRAM/SSD）→ RDMA地址返回 → worker发起RDMA读。控制路径长，需软件中介暂存。
CXL-HM：元数据服务器直接返回 ⟨node_id, addr⟩，worker立即发起RDMA读写，无需额外存储节点地址解析或软件中介暂存。缩短控制路径，简化元数据管理。

三、技术架构

多轮KV流量特征分析

RDMA带宽测量

通过256GB远程DRAM + 单A100 GPU + Llama-3.1-8B的微基准实验（512并发请求），发现四个关键观察：

观察	描述	系统设计含义
➊ 读流量跨轮增长	累积上下文增长，每轮需重载更多前缀KV块	需要高带宽读路径
➋ KV复用是只读的	之前生成的KV块作为前缀状态读回，不被修改	读路径可优化，无需一致性协议
➌ 顺序读但弱局部性	KV块按上下文顺序读，但每轮内大多只读一次	类似one-hit-wonder扫描，LRU会被污染
➍ 写入是追加-only	每轮仅写入新生成token的KV块，写量稳定	写可异步推迟，不影响当前请求正确性

CMM-H带宽崩溃现象

CMM-H带宽随KV块大小和轮次变化

在商用CMM-H设备（256GB内部DRAM，LRU管理）上的微基准测试揭示了关键问题：

当active footprint 适配内部DRAM时，带宽接近RDMA线速率（如Llama-3.1-8B的16MB块）
当footprint超出DRAM缓存容量时，带宽崩溃至SSD-backed水平（~5 GB/s）
崩溃点：168MB块在Turn 2-3之间，64MB块在Turn 3-4之间
根因：LRU-induced refills（一次命中块占据缓存空间）+ dirty evictions（新写入KV块快速传播到flash，读流量与后台写回交错）

CXL-HM原型设计

CXL-HM原型与工作负载交互

原型针对LLM服务的两个核心设计点：

➊ KV-object prefetching：多轮前缀缓存查找揭示了KV对象消费的有序列表，服务运行时将此对象级访问顺序传递给CXL-HM，使后续KV对象在前景远程读到达前被预取到内部DRAM。

➋ Latency-hiding staging window：内部DRAM不作为容量缓存，而是作为固定深度的流式暂存窗口。即将消费的对象提前暂存，被worker消费后释放给后续对象。只要SSD-to-DRAM refill管线保持窗口充满，有限DRAM即可支撑大且增长的前缀KV缓存。

Read-Prioritized Write-Isolated KV Flushing：

设备在内部DRAM中保留小写缓冲区，仅当空间可用时接纳新KV对象
缓冲满时runtime可选择跳过或稍后重试，不阻塞推理路径
已接纳的KV对象异步批量刷写到SSD-backed区域，优先在读压力低时执行

预取API协议（issue-wait-release）：

chm_prefetch_object(ptr, size) → req_handle   // 预取对象到内部DRAM
chm_prefetch_wait(req)                        // 等待预取完成
chm_prefetch_release(req)                     // 释放内部DRAM暂存区

核心公式与设计参数

预取深度与DRAM预算关系：

\text{prefetch\_depth} \times \text{KV\_block\_size} \leq \text{internal\_DRAM}

每个请求最多预取约128MB数据：对于16MB KV块最多8个块，对于32MB KV块最多4个块。请求的KV块更大或前缀命中更少时使用更小的预取窗口，最低可至double buffering。

元数据开销（每16MB KV块）：

\text{metadata\_size} = \frac{\text{total\_capacity}}{\text{block\_size}} \times 64\text{B} \approx 40\text{ MB for 10 TB}

10TB远程KV容量（约6.5×10⁵个KV对象）仅需约40MB元数据。

HyMCache系统架构

HyMCache整体架构和工作流程

HyMCache集成于Dynamo + vLLM栈，分为硬件层和软件层：

硬件层：CXL-HM设备作为Tier-3远程KV缓存设备，通过RDMA或CXL交换机组件暴露为远程内存地址空间。原型配置：64GB内部DRAM + 2TB Gen5 SSD。

软件层：四个核心模块：

组件	说明	关键参数
Master	全局元数据管理，KV块到远程地址的映射	64B/对象，10TB需~40MB；请求粒度选择目标节点
Lookup	早期远程命中匹配，批量元数据查询，协调CXL-HM预取	每次请求最多32个块；先发送已匹配前缀块
KV Connector	vLLM集成层，RDMA读写执行	5GB CPU暂存缓冲区；10秒超时回退重计算
KV Manager	CXL-HM侧预取协调，动态预取窗口	每请求~128MB上限；issue-wait-release协议

统一CXL-HM地址空间

每个CXL-HM设备作为CPU-less NUMA节点，形成一对一设备到NUMA节点映射。KV Manager使用NUMA分配接口从选定设备分配内存，并注册为RDMA memory region (MR)。

请求级NUMA分配（非页级或细粒度交错）：同一请求的所有前缀KV对象分配到同一CXL-HM设备，保持有序访问机会；不同请求分布到不同节点实现负载均衡。

异构KV对象大小支持：不同模型、worker和工作负载的KV对象可共存于同一统一地址空间。每个请求携带模型特定KV对象大小，KV Manager据此独立确定预取窗口和DRAM暂存预算。

读/写路径流程

读路径：Decode/Prefill worker发起请求 → GPU前缀缓存查找 → 可选上层DRAM缓存查找 → Lookup匹配剩余前缀 → KV Manager提交预取 → RDMA GET从CXL-HM读取KV块 → 复制到GPU KV cache

写路径：Prefill worker生成KV块 → Master分配远程地址 → RDMA PUT写入CXL-HM → Master注册元数据。写入通过写缓冲区异步刷写到SSD。

遍历示例（Walkthrough）

如图7所示：

Lookup发送预取提示到KV Manager，将后续KV对象暂存到CXL-HM内部DRAM
Lookup向Master发出批量远程命中查询，获取匹配KV对象的远程描述符
worker向Master发出批量注册请求，获取远程写入描述符
worker通过RDMA PUT写入生成的KV对象，通过RDMA GET读取匹配的前缀KV对象到GPU KV cache

四、核心创新

创新点	说明	理论/实验依据
LLM专用CXL-HM设计	将CXL-HM内部DRAM从透明LRU缓存改为显式管理的预取暂存空间	Figure 5证明LRU在多轮KV场景下被”一次命中”块污染缓存，带宽从RDMA线速率降至~5 GB/s
读优先写隔离	写入路径完全与读路径解耦，异步批量刷写避免读写竞争	KV写入量稳定且可控（Observation ➍），写入不影响当前请求正确性，可推迟执行
请求级前缀预取	利用前缀缓存查找结果提前预取下一轮需要的KV块	微基准测试显示预取开启后性能提升37%，峰值带宽接近200Gbps极限（Figure 13）
统一CXL-HM地址空间	通过NUMA分配+RDMA MR注册，将多个CXL-HM设备聚合为统一大内存空间	支持异构KV对象大小共存，无需假设全局固定块大小
内存语义绕过文件系统	CXL-HM暴露SSD-backed容量为内存地址空间，避免文件系统栈开销	NVMe-oF+XFS使顺序读带宽从23 GB/s降至6.5 GB/s（Figure 9）

五、代码实现分析

HyMCache实现于vLLM 0.19.0，基于Dynamo v1.1.0容器镜像，遵循Dynamo的LMCache集成模型。

集成方式：在vLLM的KV传输回调路径上添加HyMCache connector，协调远程KV查找、预取请求和RDMA传输。当HyMCache禁用时，vLLM遵循默认执行路径。

超时回退：远程KV块在10秒超时内未就绪时，回退到正常重计算（沿用Mooncake默认配置）。

部署配置：

PD分离式：4P-1D-1S（4个Prefill worker + 1个Decode worker + 1个CXL-HM存储节点）
单节点：Prefill和Decode共存于同一worker，直连CXL-HM远程KV层
网络：每个Prefill服务器双100Gbps NIC端口（一用于NIXL PD路径，一用于HyMCache流量）
硬件：6×Dell PowerEdge R770，双Intel Xeon 6730 CPU，256GB DDR5，NVIDIA A100 80GB

六、实验结果

PD分离式服务性能

PD分离式TTFT对比

使用Qwen2.5-32B在4P-1D-1S配置下评估，AIPerf合成输入，产生约1.5TB可复用KV-cache footprint：

方法	TTFT表现	缓存命中率(Turn 7)	说明
Recomputation	最差	0%	无KV复用，每次都重新计算
GPU Prefix Caching (T1)	早期好，Turn后急剧下降	< 30%	GPU内存不足，LRU驱逐破坏前缀链
LMCache (T1+local DRAM)	中期尚可，Turn 4后恶化	~50%	64GB本地DRAM不足以容纳增长的prefix
Mooncake (T1+remote 1TB DRAM)	较好	~75%	1TB覆盖1.5TB footprint的2/3
HyMCache (T1+remote 2TB CXL-HM)	接近Mooncake	~85%	更大容量保留更多可复用块

关键发现：

与1TB分布式DRAM的Mooncake相比，HyMCache性能约低30%，主要来自更低的DRAM获取延迟和共享分布式缓存池
但随着对话轮次增加，差距缩小——可复用KV footprint增长到1.5TB，超过Mooncake的1TB容量
HyMCache的SSD-backed容量可低成本扩展，而DRAM-only扩展受限于DIMM插槽和内存通道
写优先策略延迟了写缓冲排空，跳过>15%的潜在KV插入

NVMe-oF远程存储对比

NVMe-oF对比

HyMCache显著优于基于NVMe-oF的远程存储方案：

NVMe-oF远程KV获取频繁超时（10秒），回退到正常重计算
根本原因：XFS文件系统叠加在NVMe-oF之上，顺序读带宽从23 GB/s降至~6.5 GB/s
HyMCache利用CXL-HM的内存语义管理SSD-backed容量，避免文件系统栈在关键读路径上的开销

传输缓冲区敏感性

Mooncake传输缓冲区敏感性

Mooncake对worker侧传输缓冲区大小非常敏感：

10GB额外host DRAM时，Mooncake因传输缓冲压力导致大量远程KV插入失败，性能接近重计算基线
HyMCache采用机会性远程插入策略——写缓冲满时跳过并重试，不阻塞推理路径
HyMCache在10GB传输缓冲下已达到性能饱和，不再需要更多本地DRAM

单节点服务性能

单节点端到端性能对比

使用Llama-3.1-8B + LMSYS数据集（512轮多轮对话，并发32，最多10轮，MAX_TOKENS=1）：

方法	Turn 1表现	退化起点	说明
Recomputation	差	N/A	延迟随轮次线性增长
GPU Prefix Caching	好	Turn 3	LRU驱逐早期块，破坏连续前缀链
LMCache (local DRAM)	好	Turn 4	64GB本地DRAM不足以维持
HyMCache (remote CXL-HM)	好	~90%命中率	TB级容量维持高命中率

关键发现：GPU prefix caching和LMCache退化的根本原因是LRU驱逐破坏了连续前缀链——只要早期块被驱逐，后续缓存的块就无法转化为有效的前缀命中。HyMCache通过CXL-HM远程容量保持~90%的命中率。

Redis-backed LMCache对比

Redis LMCache对比

使用Qwen2.5-32B评估两种Redis配置（Redis-only 64GB 和 LMCache 64GB local + 64GB Redis）：

Redis-only：频繁存储失败破坏前缀链，回退到重计算
LMCache + Redis：通过本地+远程组合更稳定
HyMCache保持类似延迟分布，即使与memory-backed缓存层次结构相比

预取效果分析

预取机制效果

指标	Prefetch-Off	Prefetch-On	提升
微基准性能	基线	基线 +37%	37%
峰值远程KV加载带宽	~12 GB/s	~25 GB/s (接近200Gbps极限)	~2×
平均远程KV加载带宽	基线	+35%	35%
端到端执行时间	基线	-14%	14%

实验条件：LMSYS数据集，input > 2K字符，512对话，并发64，Turn 6（外部缓存命中率>90%）。

成本对比

介质	配置	成本	成本比率
DRAM	120×128GB DDR5 (~15TB)	~$782K	57.5×
DRAM	60×256GB DDR5 (~15TB)	~$815K	59.9×
NAND Gen5 TLC (Base)	~15TB	~$13.6K	1.0×
NAND Gen5 QLC	~15TB	~$3.0K	0.22×
NAND Gen4 TLC	~15TB	~$4.8K	0.35×
NAND Gen4 QLC	~15TB	~$3.0K	0.22×
CXL-HM†	Gen5 TLC + 64GB DRAM	~$40K	~2.9×

†FPGA原型估算（Agilex 7开发板占91-95%成本）。CXL-HM成本约为同等容量DRAM方案的1/20-1/30。原型成本 $10.5K-$ 11.0K vs Mooncake 1TB DRAM $30K-$ 40K（2.8-3.8×更便宜）。

七、相关工作

CXL内存扩展与池化

SK hynix、Samsung推出DRAM-based CXL内存扩展器
Samsung、SK hynix、Alibaba等开发CXL交换机组内存池
TraCT、Beluga等研究系统探索CXL内存disaggregation
CXL 2.0交换机（如XConn，支持256 lanes）实现~750ns最小I/O延迟
SK hynix Niagara池化内存原型：600ns访问延迟

多级KV缓存与前缀缓存

FlexGen、DeepSpeed Inference：GPU/CPU/NVMe多级分区
PagedAttention、CachedAttention：GPU KV缓存分页优化
LMCache：本地DRAM KV共享
Mooncake：分布式远程DRAM KV缓存
NVIDIA CMX：G1-G4上下文层次结构

DPU辅助远程KV缓存

LEED、Gimbal、Ditto、FORD：SmartNIC/DPU存储卸载
NVMe-oF目标卸载

HyMCache的独特定位：不提出另一套GPU/CPU/NVMe缓存策略，而是提供CXL-HM远程内存后端。它将服务层的前缀KV复用知识与设备层的DRAM预取相结合，使SSD-backed容量能作为低成本远程KV缓存后端。

八、总结

核心贡献

洞察：多轮LLM服务的KV缓存访问模式（读主导、可预测、追加写入）与通用CMM-H设备的LRU缓存策略不匹配，导致带宽崩溃至~5 GB/s
设计：LLM专用的CXL-HM原型，将内部DRAM从透明缓存改为显式管理的预取暂存空间，通过issue-wait-release协议实现用户级预取协调
系统：HyMCache框架，集成Dynamo+vLLM，提供Master/Lookup/KV Connector/KV Manager四个模块，支持统一CXL-HM地址空间和异构KV对象大小
实验：在真实CXL-HM原型上评估，单节点比LMCache快3.0×，PD分离式比LMCache快1.45×，与1TB Mooncake差距仅30%但DRAM少16×，预取提升37%性能

局限性

CXL-HM的SSD-backed路径延迟仍高于纯DRAM，性能差距在早期轮次更明显
FPGA原型成本主要由开发板占据（91-95%），量产成本待验证
机会性写策略导致>15%的潜在KV插入被跳过，可能影响长期缓存命中率
当前评估仅涉及Llama-3.1-8B和Qwen2.5-32B两种模型
RDMA-based部署为原型路径，CXL fabric部署尚未验证

技术影响

HyMCache展示了CXL混合内存作为LLM推理远程KV缓存层的可行性，为TB级共享上下文存储提供了一种成本高效的中间路线——介于昂贵的远程DRAM和缓慢的远程NVMe存储之间。随着CXL 3.0交换机的成熟和多租户Agentic应用的普及，这种架构可能成为未来LLM推理基础设施的标准组件。

九、参考资源

arXiv论文: https://arxiv.org/abs/2607.18141v1
arXiv HTML: https://arxiv.org/html/2607.18141v1
vLLM: https://github.com/vllm-project/vllm
Dynamo (NVIDIA): https://github.com/nvidia/dynamo
LMCache: https://github.com/LMCache/LMCache
Mooncake: https://github.com/mooncake-labs/mooncake
NVIDIA CMX: https://developer.nvidia.com/blog/introducing-context-memory-storage-cmx-for-generative-ai-inference/
CXL Consortium: https://cxlconsortium.org/
SK hynix Niagara: https://www.skhynix.com/
XConn CXL Switch (Marvell): https://www.marvell.com/