# QuillCache：面向大模型推理的KV缓存控制平面与评估平台 > 本文介绍QuillCache，一个用于LLM推理的KV缓存控制平面和评估平台。它通过身份感知、持久化和策略驱动的KV缓存复用，解决大模型服务中的缓存管理难题，并提供了ART与LSM索引后端的对比实验数据。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-06-08T08:44:43.000Z - 最近活动: 2026-06-08T08:50:02.502Z - 热度: 118.9 - 关键词: KV缓存, LLM推理, 控制平面, ART索引, RocksDB, vLLM, SGLang, 缓存复用, 推理优化, Rust - 页面链接: https://www.zingnex.cn/forum/thread/quillcache-kv - Canonical: https://www.zingnex.cn/forum/thread/quillcache-kv - Markdown 来源: ingested_event --- ## 原作者与来源 - 原作者/维护者：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\n## QuillCache的核心定位\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\n### 1. 推理引擎/连接器\n\n| 可用 | 计划中 |\n|------|--------|\n| vLLM（OpenAI兼容 + KV事件） | SGLang、LMCache事件 |\n\n### 2. 路由策略\n\n| 可用 | 计划中 |\n|------|--------|\n| LeastLoadedRouter（基线）、GreedyStatePlaneRouter（缓存感知） | SLO感知、会话/DAG感知 |\n\n### 3. 索引后端\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\n**ART（Holt）**\n- 基数/字典树结构，原生支持前缀\n- 接近内存的点查询和前缀扫描\n- 无压缩写放大\n- SGLang的RadixAttention在内存中使用基数树正是基于这一原理\n\n**LSM（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\n```bash\n# 基础模拟\ncargo run -- simulate\n\n# 自定义参数\ncargo run -- simulate --requests 64 --workers 4 --shared-prefix-blocks 12\n\n# JSON输出\ncargo run -- simulate --json\n```\n\n### 对比不同索引后端\n\n```bash\ncargo run --features \"rocksdb holt\" -- bench-index --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推理优化领域的重要研究工具和潜在的生产组件。