RelayKV：面向长上下文本地推理的分层KV缓存引擎

一个研究原型项目，通过GPU/CPU分层存储和选择性召回机制，解决长上下文场景下KV缓存内存瓶颈问题，让消费级硬件也能运行长文本推理任务。

随着大语言模型能力的不断演进，支持长上下文窗口已成为行业标配。从早期的4K tokens到如今的128K甚至1M tokens，模型能够处理的文本长度呈指数级增长。然而，这种能力的背后隐藏着一个严重的工程挑战：KV缓存的内存消耗。

在Transformer架构的解码过程中，模型需要缓存每一层每个注意力头的Key和Value矩阵，以避免在生成新token时重复计算。这种缓存的大小与序列长度成正比。对于本地部署场景，尤其是使用消费级GPU的用户来说，有限的显存（VRAM）往往成为长上下文推理的最大瓶颈。

RelayKV项目正是为了解决这一问题而生。它提出了一种创新的分层KV缓存管理方案，通过智能地在GPU和CPU内存之间调度缓存数据，在保证推理质量的同时显著扩展可用的上下文长度。

RelayKV的设计哲学可以用一句话概括：并非所有KV条目都需要常驻GPU，但有用条目必须在需要时可访问。

传统的KV缓存管理采用简单的驱逐策略，当显存不足时直接丢弃旧的KV条目。RelayKV则认为，这些"冷"KV数据仍然具有潜在价值，应当被妥善保存而非彻底丢弃。系统将KV缓存视为一个可管理的内存系统，而非固定在GPU上的静态资源。

具体而言，RelayKV采用以下策略：

• 热数据驻留GPU：将近期使用或重要性高的KV条目保留在GPU显存中，确保低延迟访问
• 冷数据迁移CPU：将较旧或活跃度低的KV条目迁移到CPU内存，释放宝贵的显存资源
• 按需选择性召回：在需要时只召回与当前查询最相关的KV块，而非全部恢复

RelayKV将KV缓存划分为两个主要层级。GPU层存储热数据，这些数据需要保持立即可访问状态以支持实时推理。CPU层存储冷数据，这些数据虽然暂时不在活跃计算路径上，但仍可能在后续查询中被需要。

这种分层设计使得推理可以在GPU-only KV缓存变得不切实际之后继续进行。理论上，只要CPU内存足够，系统可以支持的上下文长度仅受限于系统总内存而非显存容量。

为了实现高效的召回，RelayKV将冷KV数据组织为固定大小的块（blocks）。系统为每个块维护轻量级的元数据，用于快速评估块与当前查询的相关性。

这种块级组织相比逐token管理具有多个优势：

• 降低管理开销：以块为单位进行调度，减少元数据存储和处理的负担
• 提高传输效率：块级别的数据传输可以更好地利用内存带宽
• 支持选择性召回：基于块的相关性评分，只恢复最有价值的候选块

召回调度器是RelayKV的核心组件之一。当模型需要访问历史上下文时，调度器执行以下步骤：

1. 评分阶段：基于轻量级元数据对所有冷KV块进行相关性评分
2. 选择阶段：根据评分结果选择Top-K个最相关的块
3. 传输阶段：将选中的块从CPU内存传输回GPU显存
4. 注意力计算：使用恢复的热数据加上原有的GPU驻留数据进行注意力计算

这种选择性召回机制确保只有真正有用的KV数据才会占用宝贵的GPU资源，同时避免了信息丢失。

为进一步提升内存效率，RelayKV还支持对冷层KV数据进行量化压缩。项目提供了INT8和INT4量化适配器，可以在几乎不影响模型质量的前提下将存储需求降低50%至75%。

量化策略主要应用于CPU层的冷数据，因为这些数据的访问频率较低，对延迟的敏感度也相对较低。GPU层的热数据通常保持原始精度，以确保推理质量。

RelayKV的定位是一个KV引擎而非完整的推理运行时。它的设计目标是与现有的推理后端协同工作，而非替代它们。

项目提供了与多个主流推理框架的集成适配器：

• llama.cpp：针对本地CPU/GPU混合推理的轻量级方案
• Transformers：Hugging Face生态的标准推理接口

应用架构上，RelayKV位于推理运行时和注意力执行层之间：

应用层 / Agent / API服务
    ↓
推理运行时
    ↓
RelayKV引擎
  ├─ GPU热层
  ├─ CPU冷层
  ├─ 块元数据索引
  └─ 召回调度路径
    ↓
注意力执行

这种分层架构使得RelayKV可以无缝集成到现有的推理流水线中，而无需对上层应用进行大规模改造。