Logo
热心市民王先生

背景与目标

LLM 缓存机制 技术研究

LLM 缓存 Token 机制研究背景、核心问题定义及研究目标

问题背景

在使用 DeepSeek、Kimi、Qwen、GLM 等大语言模型 API 时，用户经常注意到一个”缓存 token”的特性。这个特性声称可以显著降低 API 调用成本（最高可达 90%）并减少响应延迟（最高可达 85%）。然而，关于这个特性的本质存在诸多疑问：

  1. 技术归属问题：缓存 token 是模型本身的能力，还是模型供应商在工程层面的实现？
  2. 实现机制问题：既然是自然语言交流，如何实现对非确定性内容的缓存？传统的缓存机制依赖于确定性的 key，但自然语言输入本质上是变化的。
  3. 优化策略问题：在日常使用中，如何避免缓存失效？为什么系统提示词中加入时间戳就容易导致缓存失效？

核心问题定义

问题一：缓存 Token 的本质归属

缓存 token 机制涉及两个层面的技术栈：

模型层能力：

  • Transformer 架构中的 KV Cache（Key-Value Cache）是模型推理的固有机制
  • 在自回归生成过程中，模型需要为每个 token 计算 Key 和 Value 向量
  • 这些计算结果可以被复用以避免重复计算

供应商工程层：

  • 跨请求级别的缓存（Cross-request Caching）
  • 分布式存储系统（如 Kimi 的 Mooncake）
  • 磁盘级缓存（如 DeepSeek 的 Context Caching on Disk）
  • 前缀匹配算法和路由策略

问题二：自然语言输入的缓存实现

传统缓存依赖于确定性 key，但 LLM 缓存采用不同的策略：

前缀匹配（Prefix Matching）：

  • 不是对整个输入进行哈希，而是对输入的前缀部分进行匹配
  • 要求前缀 token 完全一致才能命中缓存
  • 这是最严格的匹配方式，但也最可靠

语义缓存（Semantic Caching）（部分供应商支持）：

  • 使用嵌入向量（Embedding）计算语义相似度
  • 允许一定程度的语义变化但仍命中缓存
  • 实现更复杂，准确率相对较低

问题三：缓存失效的常见原因

根据研究，以下情况容易导致缓存失效：

  1. 动态内容前置：将时间戳、UUID、随机数等动态内容放在提示词前面
  2. 前缀不匹配：即使是微小的变化（如多了一个空格）也会导致整个前缀失效
  3. 缓存过期：不同供应商的缓存 TTL（生存时间）不同（5分钟到24小时不等）
  4. 请求频率过低：某些供应商需要最低请求频率（如每分钟15次）才能触发缓存路由

研究目标

本次研究旨在：

  1. 揭示技术本质：明确区分模型级 KV Cache 与供应商级 Prompt Caching 的差异
  2. 解析实现机制：深入理解前缀匹配、KV Cache 存储、分布式缓存架构等技术细节
  3. 提供优化指南：给出避免缓存失效的最佳实践和代码示例
  4. 对比供应商差异：分析 DeepSeek、Kimi、Qwen、GLM 等主流供应商的缓存实现差异

研究范围

包含内容：

  • Transformer 架构中的 KV Cache 机制
  • 各主流供应商的 Prompt Caching 实现
  • 前缀匹配算法的具体工作原理
  • 缓存优化策略和最佳实践
  • 成本与性能影响分析

不包含内容：

  • 响应级缓存（Response Caching）
  • 模型微调（Fine-tuning）
  • 语义缓存的完整实现细节（作为补充概念提及）

预期产出

  1. 技术原理的深度解析文档
  2. 各供应商实现对比分析
  3. 可复用的代码示例和配置指南
  4. 风险与注意事项清单

参考资料