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
代码	无开源代码（基于 FPGA prototype）
发布	20 Jul 2026
篇幅	13 pages total
许可	arXiv.org perpetual non-exclusive license

二、核心思想

问题定义

现代 LLM 服务从单轮对话演变为长上下文、多轮和 agentic 应用，KV cache reuse 成为减少冗余计算的关键。然而，reuse 将瓶颈从计算转移到了存储和分发可复用 KV 状态的内存层。GPU HBM 和主机 DRAM 成本过高，无法扩展到 TB 级的共享上下文容量；而纯 SSD 远程存储又面临延迟瓶颈。

具体而言：

• 商业系统（NVIDIA CMX、DeepSeek Context Caching on Disk）已表明 KV cache reuse 正在变成一个内存分层问题
• 现有方案在两个极端之间权衡：全 DRAM 远程池（高性能但昂贵）vs 纯 SSD 远程存储（低成本但慢）
• 通用 CXL-HM 设备的 LRU 缓存策略在多轮 LLM 工作负载下表现糟糕——“one-hit-wonder” 扫描模式污染缓存

解决方案概述

HyMCache 提出了一种结合 CXL-Hybrid Memory (CXL-HM) 与请求级前缀预取的 KV cache 框架。CXL-HM 是一种将少量片内 DRAM 与大容量 SSD-backed 存储结合的 CXL 设备，通过 CXL.mem 接口暴露为内存寻址空间。

HyMCache 的核心创新在于：利用多轮 KV cache 访问的**读主导（read-dominant）、可预测（predictable）、只写追加（append-only）**特性，重新设计了 CXL-HM 内部的 DRAM 管理方式：

1. 请求级前缀预取（Request-level prefix prefetching）：vLLM 推理运行时在 prefix-cache lookup 后获知即将需要的 KV blocks，提前将它们从 SSD-backed 区域预取到设备 DRAM
2. 机会性写缓冲（Opportunistic write buffering）：将新写入的 KV blocks 隔离到独立写缓冲区，异步批量刷入 SSD，避免干扰前台读取

通过这种方式，HyMCache 以 SSD 级别的成本实现了 DRAM 级别的 KV cache 效率。

三、技术架构

整体框架图

HyMCache 集成于 Dynamo + vLLM 栈，核心组件包括：

┌─────────────────────────────────────────────────────────────┐
│                    LLM Worker (vLLM + Dynamo)                │
│  ┌──────────┐  ┌──────────┐  ┌───────────┐  ┌───────────┐   │
│  │ GPU KV   │  │ Lookup   │  │ KV        │  │ Master    │   │
│  │ Cache    │→ │ Module   │→ │ Connector │→ │ (Metadata)│   │
│  │ (HBM)    │  └──────────┘  └───────────┘  └───────────┘   │
│  └─────────────────────────────────────────────────────────┐  │
│  │ Prefetch hints → KV Manager → CXL-HM prefetch API      │  │
│  │ RDMA GET ←─────────────────────────────────────────────│  │
│  └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘
                            │ RDMA
                            ▼
┌───────────────────────────────────────────────────────────────┐
│              CXL-HM Remote Storage Node                        │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │              Internal DRAM (64 GB)                        │  │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐       │  │
│  │  │ Block A │ │ Block B │ │ Block C │ │ Block D │ ...   │  │
│  │  │(prefetch│ │(prefetch│ │(prefetch│ │(prefetch│        │  │
│  │  │ window) │ │ window) │ │ window) │ │ window) │        │  │
│  │  └─────────┘ └─────────┘ └─────────┘ └─────────┘       │  │
│  │           ▲ staging window (bounded, not full footprint) │  │
│  └───────────┼──────────────────────────────────────────────┘  │
│              │ SSD-to-DRAM refill pipeline                      │
│  ┌───────────┴──────────────────────────────────────────────┐  │
│  │         SSD-backed Capacity (2 TB)                        │  │
│  │  └── Gen5 × 4 NVMe SSDs (TB-scale reusable KV states)   │  │
│  └─────────────────────────────────────────────────────────┘  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │     Write-side Buffer (isolated from read path)          │  │
│  │     Deferred async flush to SSD in large batches         │  │
│  └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘

部署模型

CXL-HM 可部署为两种模式：

• (a) CXL fabric 直连：CXL-HM 设备通过 CXL switch 直接连接 LLM worker
• (b) RDMA over existing DC network：CXL-HM 节点作为远程内存地址空间暴露，worker 通过 RDMA 访问

原型采用模式 (b)，兼容现有数据中心基础设施，无需 CXL fabric。

远程访问路径对比

传统 DRAM-SSD 分层：metadata lookup → storage node 二次查找 → DRAM/SSD 判定 → 可能的 SSD 到 DRAM 迁移 → 返回地址 → RDMA 读取（控制路径长）

CXL-HM：metadata lookup → 直接返回最终 <node_id, addr> → 立即 RDMA 读写（控制路径短）

三大设计要点

1. 多轮工作负载特征分析

实验发现四个关键特征：

• Observation ① Read traffic grows across turns：累积上下文增长导致每轮需要重新加载更多 prefix KV blocks，瞬时读流量和累计读体积均随轮次增加
• Observation ② KV reuse is read-heavy and read-only：已生成的 KV blocks 作为 prefix state 被重复读取但不被修改，对内存层而言保持 clean
• Observation ③ Sequential KV reads with weak locality：KV blocks 按上下文顺序顺序读取，短期复用极少（one-hit-wonder workload），扫描式访问模式天然缺乏基于时效性的局部性
• Observation ④ Writes are append-only：每轮仅写入新生成 output tokens 对应的 KV blocks，当 output 长度相似时，写流量在各轮间相对稳定

2. CMM-H LRU 策略的失败

商业 CMM-H 设备使用 LRU 透明缓存管理内部 DRAM。实验显示：

• 当活跃工作集在 256 GB DRAM 内时，带宽接近 RDMA 线速
• 一旦超出有效 DRAM 缓存容量，带宽急剧下降到 ~5 GB/s（SSD-backed 水平）
• 崩溃原因：LRU-induced refills（一次性消耗 block 滞留缓存）和 dirty eviction（后台写回干扰前台读取）

3. CXL-HM 原型设计

针对上述观察，原型做出三个关键设计改变：

(1) KV-object prefetching：推理运行时将 ordered list of KV objects 传递给 CXL-HM，在 foreground remote reads 到达之前预取 upcoming KV objects 到内部 DRAM

(2) Latency-hiding staging window：内部 DRAM 作为固定深度的 staging window 而非完整 footprint cache。upcoming objects 被预取 → 被 worker 消费 → 释放给后续 objects。只要 refill pipeline 保持窗口填充，有限 DRAM 即可支持无限增长的 prefix KV cache

(3) Read-prioritized write-isolated KV flushing：KV 写入对应新生成 token，不影响当前请求正确性。设备在内部 DRAM 中保留小写缓冲区，admit 新 KV objects 仅当缓冲区有空间。admitted objects 异步批量 flush 到 SSD-backed 区域，preferably when read pressure 低

核心 API

CXL-HM 提供三个对象级生命周期 API：

chm_prefetch_object(ptr, size)  → req_handle   // 从 SSD-backed 预取 object 到 DRAM staging region
chm_prefetch_wait(req)          → ready        // 等待 prefetched object 就绪
chm_prefetch_release(req)                       // 释放已消费的 DRAM staging region

软件模块

HyMCache Master：维护全局 metadata，映射每个 prefix/KV identifier 到远程访问信息（target CXL-HM node, remote address, length）。10 TB remote KV capacity 仅需 ~40 MB metadata（64 B/entry, ~6.5×10⁵ KV objects）

Lookup Module：早期远程 hit 匹配、批量 metadata lookup、CXL-HM prefetch coordination。支持 up to 32 blocks/request 的 batched metadata lookup

KV Connector：轻量级 vLLM 插件，在 GPU prefix-cache lookup 之后插入 RDMA 读写路径。10 秒超时 fallback 到 recomputation

KV Manager：协调并发请求的 CXL-HM prefetching，动态分配 prefetch window（per request up to ~128 MB prefetched data，即 16 MB blocks 最多 8 个，32 MB blocks 最多 4 个）

统一 CXL-HM 地址空间

• 每个 CXL-HM 设备暴露为 CPU-less NUMA node
• 使用 NUMA allocation interfaces 从选定 NUMA node 分配内存并注册为 RDMA memory region
• Request-level NUMA assignment（非 page-level interleaving）：同一 request 的所有 prefix KV objects 放置在同一个 NUMA node 上，保证有序预取
• 跨 requests 使用 round-robin 或 load-aware selection 负载均衡
• 支持异构 KV object sizes（不同模型、不同 worker 共存）

四、核心创新

创新点	说明	理论/实验依据
发现 CMM-H LRU 在多轮 LLM 下的失效	LLM 多轮 KV 访问是 one-hit-wonder 扫描模式，LRU 被消耗 block 污染	Figure 5 实验：168 MB blocks 在 Turn 2-3 间带宽崩溃至 5 GB/s
Staging window 替代 capacity cache	内部 DRAM 作为 bounded staging window 而非缓存整个 prefix footprint	Section 3.3 设计，SSD bandwidth 成为可扩展 knob
Read-prioritized write isolation	写入路径与读取路径完全隔离，异步批量 flush 避免干扰前台读取	Section 3.3 设计，允许跳过/重试写入而不阻塞推理
Prefetch API + issue-wait-release 协议	推理运行时感知 upcoming KV blocks，CXL-HM 透明隐藏 SSD 延迟	Section 4.2 描述，ablation 证明 prefetch 贡献 37% microbenchmark 提升

五、实验设置

硬件配置

PD-disaggregated setup：

• 6 台 Dell PowerEdge R770 服务器（双 Intel Xeon 6730 CPU, 256 GB DDR5, NVIDIA A100 80GB HBM）
• 4P–1D–1S 配置：4 prefill workers, 1 decode worker, 1 storage node
• CXL-HM 远程 tier：FPGA-based prototype（Agilex 7 dev board, 64 GB device-side DRAM, 2×1 TB Gen5 SSDs = 2 TB shared memory tier）
• 网络：100 Gbps NIC（prefill → CXL-HM），200 Gbps aggregate（decode/storage → prefill）

Single-node setup：

• 单 compute node 共置 prefill + decode，直连 CXL-HM remote KV tier

Baselines

Baseline	描述
Recomputation	无远程 KV tier，missing prefix 通过 vLLM 默认 recomputation
GPU Prefix Caching (T1)	vLLM GPU 内 prefix caching
Local LMCache (T1+local DRAM)	每台 worker 64 GB local DRAM
Distributed Mooncake (T1+remote DRAM)	1 TB 分布式 DRAM 远程 tier
Mooncake NVMe-oF (T1+remote SSD)	远程 SSD 通过 NVMe-oF 访问
HyMCache (T1+remote CXL-HM)	CXL-HM 远程 tier（64 GB DRAM + 2 TB SSD-backed）

Models & Workloads

• Models: Llama-3.1-8B (16 MB KV blocks), Qwen2.5-32B (32 MB KV blocks)
• Workloads: Dynamo AIPerf synthetic (mooncake trace), LMSYS multi-turn conversations
• Config: FP16/BF16 KV cache, vLLM block size = 128 tokens, MAX_TOKENS = 1

六、实验结果

PD-disaggregated 服务性能

Table 1：PD-disaggregated TTFT（Qwen2.5-32B, AIPerf synthetic）

System	Turn 1	Turn 2	Turn 3	Turn 4	Turn 5	Turn 6	Turn 7
Recomputation	1.92s	3.25s	5.10s	7.80s	11.50s	16.20s	22.40s
GPU Prefix Caching	1.85s	2.90s	4.50s	7.20s	10.80s	15.10s	20.50s
Local LMCache	1.55s	2.10s	2.80s	3.90s	5.80s	8.50s	12.10s
Distributed Mooncake	1.30s	1.65s	2.05s	2.55s	3.15s	3.85s	4.65s
Mooncake NVMe-oF	1.90s	3.10s	4.80s	7.50s	11.00s	15.50s	21.80s
HyMCache	1.35s	1.70s	2.10s	2.50s	2.95s	3.35s	3.70s

关键发现：

• Turn 1-3 时，Mooncake（1 TB DRAM）略优于 HyMCache
• Turn 4+ 时，HyMCache 反超 Mooncake——随着 reusable KV footprint 增长到 >1.5 TB，1 TB Mooncake 容量不足，而 HyMCache 的 2 TB SSD-backed capacity 保留更多 reusable prefix blocks
• Turn 7 时，HyMCache hit rate 比 Mooncake 高约 10%

与 NVMe-oF 远程存储对比

HyMCache 显著优于 Mooncake NVMe-oF：

• NVMe-oF remote KV fetches 频繁超时 fallback 到 recomputation
• 原因：XFS 文件系统叠加使原始 NVMe-oF 23 GB/s 降至 ~6.5 GB/s
• HyMCache 通过内存语义接口避免文件系统开销

Transfer Buffer 敏感性

• Mooncake 对 transfer buffer 极度敏感：10 GB additional host DRAM 下严重 suffer from buffer pressure，远程 KV insertion 失败率高
• HyMCache 不敏感：opportunistic remote-insertion policy（buffer full 时 skip/retry 而非 stall），10 GB 以上性能不再提升

Single-node 服务性能

与 local LMCache 对比（Llama-3.1-8B, LMSYS dataset, 512 conversations, concurrency 32）：

• GPU prefix caching 在 Turn 3 后开始丢失有效 reuse
• LMCache local CPU caching 在 Turn 4 后开始丢失有效 reuse
• HyMCache 维持 ~90% hit rate 直到 Turn 10

提升倍数：

• 相同 DRAM budget（64 GB/worker × 4 = 256 GB total）下，HyMCache 相比 local LMCache 提升 3.0×（single-node）
• 相比 PD-disaggregated 场景提升 1.45×

与 Redis-backed LMCache 对比

• Redis-only 64 GB remote caching 频繁 store failures 破坏 reusable prefix chain
• LMCache + 64 GB local DRAM + 64 GB Redis 更稳定，但 HyMCache 通过 remote CXL-HM tier 达到相似的 latency distribution

Prefetching 消融实验

• Microbenchmark（heavy random reads to remote CXL-HM）：启用 prefetch 提升 37%
• LMSYS dataset（Turn 6, external cache hit rate >90%）：prefetch 减少端到端执行时间 14%
• Peak bandwidth 接近 200 Gbps 网络限制，average bandwidth 改善 >35%

与 Mooncake 的公平比较

Metric	Distributed Mooncake (1 TB DRAM)	HyMCache (64 GB DRAM + 2 TB SSD)
Performance gap	Baseline	~30% lower
DRAM usage	1 TB	64 GB per device (16× less)
Remote tier cost	~$30K-40K	~$10.5K-11K (FPGA prototype)
Scalability	DIMM slots/socket channels limited	Add more CXL-HM devices or increase SSD capacity

七、相关工作

CXL-based Memory Expansion and Pooling

• SK hynix, Samsung, Alibaba Cloud, Liqid 等开发 DRAM-based CXL memory expanders 和 switch-based pools
• HyMCache 不同：target 是 remote KV caching for multi-turn LLM serving，而非 generic memory expansion

Multi-tier KV Cache and Prefetching

• FlexGen, DeepSpeed Inference: GPU/CPU/NVMe partitioning
• LMCache, Mooncake: KV sharing 和 disaggregated KV-cache
• HyMCache 互补：提供 CXL-HM based remote memory backend，耦合 serving-level prefix reuse knowledge 与 device-level DRAM staging

DPU-based Storage and Remote KV Caching

• LEED, Gimbal, Ditto, FORD: DPU/SmartNIC 存储卸载
• HyMCache 不同：构建 memory-addressable remote KV tier，避免依赖 DPU cores 或 storage-node software

八、总结

核心贡献

1. CXL-HM 工作负载分析：首次系统分析多轮 LLM 推理的 KV cache 访问模式（read-dominant, predictable, append-only, one-hit-wonder），揭示通用 CMM-H LRU 策略的根本不匹配
2. LLM-targeted CXL-HM 原型：设计面向 LLM 的 CXL-HM 设备，提供 explicit prefetch API 和 issue-wait-release 协议，内部 DRAM 作为 bounded staging window
3. HyMCache 框架：集成 Master/Lookup/KV Connector/KV Manager 四个模块到 Dynamo+vLLM 栈，实现 request-level prefix prefetching 和 opportunistic write buffering
4. 真实硬件评估：在 FPGA-based CXL-HM prototype 上验证，single-node 3.0×、PD-disaggregated 1.45× 优于 local LMCache

局限性

1. FPGA prototype cost：FPGA board 占 prototype 成本的 91-95%，ASIC 实现将大幅降低成本
2. RDMA 依赖：当前原型使用 RDMA over 100/200 Gbps NIC，未评估 CXL fabric 直连路径
3. 仅 batch size = 1 per request：多 request 并发下的 prefetch window 调度需进一步优化

未来方向

• ASIC 实现的 CXL-HM 设备（去除 FPGA overhead）
• CXL switch-based fabric 部署模式评估
• 多 prefill worker 共享同一 CXL-HM tier 时的 prefetch coordination

九、参考资源

• 论文: https://arxiv.org/abs/2607.18141
• DOI: https://doi.org/10.48550/arXiv.2607.18141
• 相关论文: ITME (Jang et al. 2026) — 类似主题：Inference Tiered Memory Expansion with Disaggregated CXL-Hybrid Memories arXiv:2606.12556