QuillCache：面向大模型推理的KV缓存控制平面与评估平台

本文介绍QuillCache，一个用于LLM推理的KV缓存控制平面和评估平台。它通过身份感知、持久化和策略驱动的KV缓存复用，解决大模型服务中的缓存管理难题，并提供了ART与LSM索引后端的对比实验数据。

• 原作者/维护者：feichai0017
• 来源平台：github
• 原始标题：quillcache
• 原始链接：https://github.com/feichai0017/quillcache
• 来源发布时间/更新时间：2026-06-08T08:44:43Z

原作者与来源

• 原作者/维护者：feichai0017
• 来源平台：github
• 原始标题：quillcache
• 原始链接：https://github.com/feichai0017/quillcache
• 来源发布时间/更新时间：2026-06-08T08:44:43Z 原作者与来源\n\n- 原作者/维护者: feichai0017\n- 来源平台: GitHub\n- 原始标题: quillcache\n- 原始链接: https://github.com/feichai0017/quillcache\n- 发布时间: 2026年6月8日\n\n---\n\n引言：LLM推理中的KV缓存挑战\n\n在大语言模型（LLM）的推理过程中，KV缓存（Key-Value Cache）是提升生成效率的关键技术。它存储了注意力机制中的键值对，避免了在自回归生成时重复计算历史token的注意力状态。然而，随着模型规模和服务负载的增长，KV缓存的管理变得愈发复杂：如何识别可复用的缓存块？如何在多worker间高效路由请求？如何在磁盘上持久化缓存索引？这些问题直接影响着推理服务的吞吐量和成本。\n\nQuillCache应运而生，它是一个面向LLM推理的KV缓存控制平面和评估平台，旨在通过身份感知、持久化和策略驱动的缓存复用，为上述问题提供系统性的解决方案。\n\n---\n\nQuillCache的核心定位\n\n它是什么，不是什么\n\nQuillCache的设计哲学非常明确——它专注于"控制"而非"执行"：\n\n| 它是 | 它不是 |\n|------|--------|\n| 位于真实推理引擎前的网关 | 新的vLLM或SGLang（不包含内核或模型执行） |\n| 由真实KV事件驱动的驻留索引 | 新的LMCache（不是KV张量数据平面） |\n| 策略引擎（路由/复用/重计算/固定/驱逐） | 新的Dynamo KVBM（不是分布式块内存管理器） |\n| 用于对比策略和索引后端的研究工具 | 纯论文模拟器（它连接真实引擎） |\n\n这种分层设计让QuillCache能够专注于元数据管理和决策制定，而将实际的KV张量存储和计算留给专业的引擎和数据平面处理。\n\n系统架构分层\n\nQuillCache在整个LLM服务栈中位于控制平面层：\n\n\nvLLM / SGLang = 推理引擎（运行模型，持有活跃KV张量）\nLMCache / KVBM = KV张量数据平面/卸载后端\nQuillCache = 控制平面 + 研究平台 <-- 本仓库\nHolt = 持久化ART索引后端\nRocksDB = LSM索引基线\n\n\nQuillCache持有身份和驻留元数据并做出决策，而KV张量字节则驻留在数据平面中。两个平面在索引和存储层交汇，但永远不会作为同一对象存在。\n\n---\n\n核心架构与组件\n\nQuillCache由多个Rust crate组成，形成完整的控制平面：\n\n主要组件\n\n1. quillcache-gateway: OpenAI兼容的代理 + KV事件摄取端点\n2. quillcache-control: 控制平面和摄取批处理（KV事件 → 驻留状态）\n3. quillcache-router: 路由策略实现，包括GreedyStatePlaneRouter（缓存感知）和LeastLoadedRouter（基线）\n4. quillcache-core: KvBlockKey身份、CacheResidency、成本模型和IndexBackend trait\n5. quillcache-sim: 实验模式工具，可在任意策略×任意后端组合上重放跟踪数据\n6. quillcache-index-rocksdb: RocksDB（LSM）索引后端\n7. quillcache-index-holt: Holt（持久化ART）索引后端\n\n数据流\n\n\n客户端/基准测试 → quillcache-gateway → quillcache-control → quillcache-router\n ↓\n quillcache-core（索引后端）\n ↓\n vLLM/SGLang/LMCache\n\n\n这种架构支持两种运行模式：\n- 在线模式: 在真实引擎前运行选定的策略组合\n- 实验模式: 在策略×索引后端的乘积空间上重放同一工作负载\n\n---\n\n三大可插拔维度\n\nQuillCache的设计将系统拆分为三个可插拔的维度，便于进行组合实验：\n\n1. 推理引擎/连接器\n\n| 可用 | 计划中 |\n|------|--------|\n| vLLM（OpenAI兼容 + KV事件） | SGLang、LMCache事件 |\n\n2. 路由策略\n\n| 可用 | 计划中 |\n|------|--------|\n| LeastLoadedRouter（基线）、GreedyStatePlaneRouter（缓存感知） | SLO感知、会话/DAG感知 |\n\n3. 索引后端\n\n| 可用 | 计划中 |\n|------|--------|\n| MemoryIndex（参考）、Holt（ART）、RocksDB（LSM） | 文件系统 |\n\n---\n\n关键设计决策：ART vs LSM\n\nQuillCache的一个核心研究问题是：对于KV缓存驻留/前缀索引，哪种存储引擎是合适的底层？\n\n工作负载特征\n\n驻留/前缀索引在每个KV事件时写入，在每个请求时读取（最长可复用前缀）。其工作负载特征为：\n- 前缀密集: 共享系统提示、RAG文档、智能体会话DAG\n- 写入频繁: 需要持久化到磁盘\n\n两种设计方案\n\nART（Holt）\n- 基数/字典树结构，原生支持前缀\n- 接近内存的点查询和前缀扫描\n- 无压缩写放大\n- SGLang的RadixAttention在内存中使用基数树正是基于这一原理\n\nLSM（RocksDB）\n- 通过压缩优化写入\n- 但压缩导致写放大，前缀扫描不够自然\n\n实验结果\n\n在相同工作负载下（2000请求，8016驻留块，20k前缀扫描查询）：\n\n| 后端 | 摄取速度(puts/s) | 前缀扫描p50 | 前缀扫描p99 | 恢复时间 | 磁盘占用 |\n|------|------------------|-------------|-------------|----------|----------|\n| memory（平面映射） | 706k | 494 µs | 1685 µs | — | 0 |\n| rocksdb（LSM） | 56k | 16.8 µs | 29.6 µs | 4.1 ms | 500 KB |\n| holt（ART） | 55k | 9.96 µs | 13.7 µs | 2.6 ms | 8.4 MB |\n\n关键发现：\n- 对于前缀密集的工作负载，ART（Holt）提供最低的前缀扫描延迟（p50比LSM快约1.7倍，p99快约2.2倍）\n- ART比平面内存映射的O(N)扫描快约50倍\n- LSM（RocksDB）在磁盘上更空间高效（压缩+压缩）\n- 两个持久化后端的摄取速度相当，比内存慢约13倍（持久化的代价）\n\n选型建议：\n- 当前缀扫描延迟和恢复时间占主导时（驻留索引的查询频率），选择ART\n- 当磁盘占用是约束条件时，选择LSM\n\n---\n\n快速开始与使用场景\n\n实验模式：合成共享前缀工作负载\n\nbash\n基础模拟\ncargo run -- simulate\n\n自定义参数\ncargo run -- simulate --requests 64 --workers 4 --shared-prefix-blocks 12\n\nJSON输出\ncargo run -- simulate --json\n\n\n对比不同索引后端\n\nbash\ncargo run --features \"rocksdb holt\" -- bench-index --backend <backend>\n\n\n---\n\n实际意义与价值\n\nQuillCache的价值不仅在于其技术实现，更在于它提供了一个标准化的评估框架：\n\n1. 可复现的研究: 通过相同的跟踪数据，可以在不同策略和索引后端之间进行苹果对苹果的比较\n\n2. 生产就绪的洞察: 实验数据直接指导生产环境的选型决策——ART vs LSM的选择可以基于实际测量而非理论假设\n\n3. 策略创新平台: 插件化的架构允许研究人员快速实现和评估新的路由策略，如SLO感知或会话/DAG感知路由\n\n4. 与现有生态的集成: 作为网关而非替代，QuillCache可以与vLLM、SGLang、LMCache等主流工具协同工作\n\n---\n\n总结与展望\n\nQuillCache代表了LLM服务基础设施向更精细化、可评估方向发展的趋势。通过将KV缓存管理分解为控制平面和数据平面，它既保持了与现有工具的兼容性，又为研究和优化提供了灵活的实验平台。\n\n其ART vs LSM的对比实验填补了该领域的一个关键空白——写放大分析。这一结果对于设计下一代LLM服务系统具有重要的参考价值。\n\n随着SGLang、LMCache等更多引擎和事件源的接入，以及SLO感知、会话感知等高级路由策略的实现，QuillCache有望成为LLM推理优化领域的重要研究工具和潜在的生产组件。