技术原理核心

1. 模型层的 KV Cache 机制

1.1 Transformer 的自回归特性

大语言模型（LLM）采用自回归（Autoregressive）方式生成文本，这意味着：

• 生成新 token 时，仅依赖于之前所有的 token
• 每个 token 需要计算其 Query、Key、Value 向量
• 对于已经处理过的 token，其 Key 和 Value 向量是固定的

数学表示：

Attention(Q, K, V) = softmax(QK^T / √d_k)V

在生成第 n 个 token 时：

• Q_n 是当前 token 的 Query 向量（需要新计算）
• K_1…K_n 和 V_1…V_n 是所有 token 的 Key 和 Value 向量
• 对于 token 1 到 n-1，其 K 和 V 向量与生成第 n-1 个 token 时完全相同

1.2 KV Cache 的基本概念

定义：KV Cache 是在推理过程中存储已计算 Key-Value 向量的内存结构。

工作流程：

1. 首次处理（Prefill 阶段）：处理完整输入提示词，计算所有 token 的 K/V 向量
2. 缓存存储：将 K/V 向量存储在 GPU 内存或更高速的存储介质中
3. 增量生成（Decode 阶段）：每生成一个新 token，只需计算其 Q 向量，然后从缓存中读取之前的 K/V
4. 缓存复用：后续请求如果前缀匹配，可直接复用缓存的 K/V 向量

内存占用估算： 对于 batch_size=b, sequence_length=s, num_layers=L, hidden_size=h, num_heads=n_heads 的模型：

KV Cache Size = 2 × b × s × L × h × sizeof(dtype)

以 FP16 精度为例，一个 7B 参数的模型（L=32, h=4096）：

• 1K token 序列：约 512 MB
• 100K token 序列：约 51 GB

1.3 KV Cache 与 Prompt Caching 的区别

2. 供应商级 Prompt Caching 架构

2.1 前缀匹配算法（Prefix Matching）

Prompt Caching 的核心是前缀匹配算法。其工作原理如下：

基本逻辑：

if current_request.prefix == cached_request.prefix:
    return cached_kv_cache
else:
    compute_from_scratch()

关键约束：

• 必须是精确匹配（Exact Match），不能是相似匹配
• 匹配从前缀开始，向后逐 token 比较
• 第一个不匹配的 token 会导致整个前缀失效
• 最小匹配长度通常为 1024 tokens（各供应商可能不同）

示例说明：

请求 A（首次请求）：

{
  "messages": [
    {"role": "system", "content": "You are a helpful assistant..."},
    {"role": "user", "content": "Analyze this document: [LONG_DOC]\nQuestion: What is the main topic?"}
  ]
}

请求 B（第二次请求，缓存命中）：

{
  "messages": [
    {"role": "system", "content": "You are a helpful assistant..."},
    {"role": "user", "content": "Analyze this document: [LONG_DOC]\nQuestion: What are the key points?"}
  ]
}

在上面的例子中，系统提示词和长文档内容构成了共同前缀，只有最后的用户问题不同，因此缓存命中。

2.2 缓存存储架构

2.2.1 DeepSeek 的磁盘级缓存

DeepSeek 采用 Context Caching on Disk 技术：

架构特点：

• 缓存存储在磁盘（SSD）而非内存中
• 支持极长的上下文（最高 128K tokens）
• 自动触发，无需用户配置
• 价格差异显著：Cache Hit ($0.07/M) vs Cache Miss ($0.27/M)

工作流程：

1. 每个用户请求都会触发磁盘缓存的构建
2. 后续请求如果与前序请求有重叠前缀，重叠部分从缓存读取
3. 仅对前缀重叠部分计费为 Cache Hit 价格

2.2.2 Kimi 的 Mooncake 架构

Kimi（月之暗面）开发了 Mooncake 架构，这是一个 KV Cache 为中心的分离式服务架构：

核心组件：

1. Prefill 集群：负责处理输入提示词的首次计算
2. Decode 集群：负责生成后续 token
3. KV Cache 存储层：利用 CPU、DRAM、SSD 资源构建分布式缓存
4. 调度器：基于 KV Cache 的全局调度，平衡吞吐量和延迟 SLO

技术创新：

• 分离式架构（Disaggregated Architecture）：将预填充和解码分离到不同集群
• 预测性早期拒绝策略：在高负载场景下预测性地拒绝部分请求以保护服务质量
• 长上下文优化：在 100K+ token 场景下显著提升吞吐量

性能提升：

• 相比基线方法，吞吐量提升 59%～525%
• 在长上下文场景中表现尤为出色

2.2.3 Qwen 的多模式缓存

Qwen 提供三种缓存模式：

显式缓存（Explicit Cache）：

• 需要手动启用
• 为特定内容创建缓存，保证命中
• 缓存有效期：5 分钟
• 定价：创建时 125% 标准价格，命中时 10% 标准价格

隐式缓存（Implicit Cache）：

• 自动模式，无需额外配置
• 系统自动识别并缓存请求的共同前缀
• 命中率不保证
• 定价：命中部分 20% 标准价格

会话缓存（Session Cache）：

• 专为多轮对话设计
• 使用 Responses API
• 通过请求头 x-dashscope-session-cache: enable 启用
• 计费规则与显式缓存相同

2.2.4 GLM 的隐式缓存

GLM（智谱 AI）提供：

特性：

• 支持所有主流模型（GLM-5、GLM-4.7、GLM-4.6、GLM-4.5 系列等）
• 透明计费：在响应字段 usage.prompt_tokens_details.cached_tokens 中显示缓存 token 数量
• 自动缓存识别：隐式缓存自动识别重复上下文
• 成本节省：缓存 token 按更低价格计费

实现原理： 通过计算输入消息内容，识别与之前请求相同或高度相似的内容，复用之前的计算结果，避免冗余 token 处理。

2.3 缓存失效与 TTL

缓存失效的常见原因：

1. 前缀变化：

   • 时间戳、UUID、随机数等动态内容前置
   • 即使是微小变化（如空格、换行）也会导致失效

2. 缓存过期（TTL）：

   • Anthropic：5-10 分钟
   • OpenAI GPT-5.1：24 小时
   • DeepSeek：未明确公开，估计数小时

3. 请求频率不足：

   • OpenAI 需要约每分钟 15 次请求才会触发缓存路由
   • 低频请求可能被路由到未缓存的机器

4. 系统负载：

   • 高负载时，缓存可能被逐出以腾出空间

3. 为什么不是语义缓存？

3.1 语义缓存的挑战

语义缓存通过嵌入向量（Embedding）计算相似度，允许一定程度的变化。然而，在 Prompt Caching 中很少使用，原因如下：

准确性问题：

• 语义相似不等于 KV Cache 可复用
• 即使是微小的语义变化，也可能导致完全不同的注意力分布

计算开销：

• 需要为每个请求计算嵌入向量
• 相似度搜索需要额外的向量数据库查询
• 可能抵消缓存带来的性能收益

实现复杂度：

• 需要维护额外的向量索引
• 需要定义相似度阈值
• 调试和排查问题更困难

3.2 何时使用语义缓存

语义缓存更适合应用层实现：

• 缓存最终响应（Response Caching）而非中间计算
• 问答系统、客服机器人等场景
• 使用 Redis、Memcached 等独立缓存层

4. 技术实现的关键差异总结

参考资料

• Context Caching | DeepSeek API Docs - DeepSeek 缓存实现文档
• Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving - Mooncake 架构论文
• Context Cache feature of Qwen models - Qwen 上下文缓存文档
• Context Caching - Z.AI Developer Documentation - GLM 缓存实现文档
• Prompt Caching | OpenAI API - OpenAI Prompt Caching 指南
• Prompt Caching Explained - Prompt Caching 技术详解