供应商实现对比

1. 对比框架

为了全面对比各供应商的 Prompt Caching 实现，我们从以下维度进行评估：

2. DeepSeek：磁盘级自动缓存

2.1 核心特性

技术亮点：

• Context Caching on Disk：将 KV Cache 存储在磁盘（SSD）而非内存中
• 完全自动：无需用户配置或代码修改
• 前缀匹配：基于精确前缀匹配，最低 1024 tokens
• 显著成本差异：Cache Hit ($0.07/M) 仅为 Cache Miss ($0.27/M) 的 26%

2.2 定价结构

成本节省示例： 假设系统提示词 + 长文档共 50K tokens，用户查询 1K tokens：

• 首次请求（Cache Miss）：50K × $0.27 + 1K ×$0.27 = $13.77
• 后续请求（Cache Hit）：50K × $0.07 + 1K ×$0.27 = $3.77
• 节省比例：72.6%

2.3 实现原理

DeepSeek 的缓存实现基于以下架构：

1. 磁盘存储层：

   • 利用 SSD 的高吞吐特性存储 KV Cache
   • 支持大规模并发读取
   • 相比内存成本更低，容量更大

2. 自动前缀识别：

   • 系统自动识别请求间的共同前缀
   • 构建前缀树（Prefix Tree）索引
   • 快速匹配和检索

3. 计费透明：

   • 在 API 响应中明确区分 cached_tokens 和 fresh_tokens
   • 便于成本监控和优化

2.4 优缺点分析

优势：

• ✅ 零配置，开箱即用
• ✅ 成本节省显著（最高 90%）
• ✅ 支持超长上下文（最高 128K）
• ✅ 磁盘存储，容量几乎无限

劣势：

• ❌ 磁盘 I/O 比内存慢，极端高并发可能成为瓶颈
• ❌ 无法控制缓存 TTL
• ❌ 无法显式管理缓存生命周期

2.5 适用场景

• RAG 系统：重复查询相同知识库
• 长文档分析：多次提问同一文档
• 代码审查：针对同一代码库的多轮审查

3. Kimi（月之暗面）：Mooncake 分离式架构

3.1 核心特性

技术亮点：

• Mooncake 架构：KV Cache 为中心的分离式服务架构
• Prefill-Decode 分离：将计算密集型预填充与生成阶段解耦
• 分布式缓存池：利用 CPU、DRAM、SSD 构建多级缓存
• 长上下文专家：在 100K+ token 场景下性能卓越

3.2 架构详解

Mooncake 核心组件：

┌─────────────────────────────────────────────────────────┐
│                    Mooncake 架构                         │
├─────────────────────────────────────────────────────────┤
│  Prefill 集群    │    Decode 集群    │   KV Cache 层   │
│  (计算密集型)     │   (生成阶段)       │  (存储层)       │
├──────────────────┼───────────────────┼─────────────────┤
│ • 处理输入提示词  │ • 自回归生成      │ • DRAM (热缓存) │
│ • 计算 KV Cache  │ • 逐 token 输出   │ • SSD (温缓存)  │
│ • 高并行计算     │ • 低延迟要求      │ • 网络传输优化  │
└──────────────────┴───────────────────┴─────────────────┘

关键技术：

1. KV Cache 为中心的调度器：

   • 优先考虑缓存命中率
   • 在满足延迟 SLO 的前提下最大化吞吐量
   • 预测性负载均衡

2. 早期拒绝策略（Early Rejection）：

   • 在高负载场景下预测性拒绝部分请求
   • 保护服务质量，防止级联故障
   • 基于请求特征和系统负载的智能决策

3. Transfer Engine：

   • 高效传输 KV Cache 的网络层
   • 支持 RDMA（远程直接内存访问）
   • 零拷贝传输技术

3.3 性能表现

根据官方论文数据：

3.4 优缺点分析

优势：

• ✅ 业界领先的分离式架构
• ✅ 长上下文处理专家
• ✅ 开源 Transfer Engine（GitHub 4854 stars）
• ✅ 已加入 PyTorch 生态

劣势：

• ❌ 技术细节公开较少
• ❌ 用户无法直接控制缓存行为
• ❌ 定价透明度不如 DeepSeek

3.5 适用场景

• 超长文档处理：论文、书籍、法律文档分析
• Agent 系统：需要多轮工具调用的复杂任务
• 高并发服务：需要稳定延迟的生产环境

4. Qwen（通义千问）：三模式缓存

4.1 核心特性

技术亮点：

• 三种缓存模式：显式缓存、隐式缓存、会话缓存
• 灵活配置：用户可根据场景选择最适合的模式
• 广泛兼容：支持 Qwen3 系列所有模型
• 最高 10M 上下文：Qwen-Long 支持 1000 万 token

4.2 三种缓存模式对比

4.3 显式缓存详解

适用场景：

• 需要保证缓存命中的关键业务
• 系统提示词 + 固定知识库的场景
• 成本敏感且可预测的工作负载

实现方式：

# 伪代码示例
response = client.chat.completions.create(
    model="qwen-plus",
    messages=messages,
    extra_body={
        "context_cache": {
            "enable": True,
            "content": system_prompt + long_document
        }
    }
)

计费逻辑：

• 创建缓存时：按标准输入价格的 125% 计费
• 命中缓存时：按标准输入价格的 10% 计费
• 适用于高频重复查询场景

4.4 隐式缓存详解

适用场景：

• 通用场景，追求便利
• 不可预测的用户查询模式
• 快速集成，无需修改代码

工作原理：

• 系统自动识别请求间的共同前缀
• 构建隐式前缀索引
• 匹配成功自动触发缓存

注意事项：

• 命中率不保证，取决于请求模式
• 适合探索性开发和小规模应用
• 大规模生产环境建议使用显式缓存

4.5 会话缓存详解

适用场景：

• 多轮对话应用
• 需要保持上下文的交互式系统
• 客服机器人、助手类应用

启用方式：

POST /v1/responses
Content-Type: application/json
x-dashscope-session-cache: enable

{
  "model": "qwen-plus",
  "messages": [...]
}

4.6 优缺点分析

优势：

• ✅ 三种模式灵活选择
• ✅ 显式缓存命中率 100%
• ✅ 支持超大规模上下文（10M tokens）
• ✅ 定价透明，易于预算控制

劣势：

• ❌ 显式缓存需要代码改造
• ❌ 缓存有效期较短（5 分钟）
• ❌ 三种模式的适用场景容易混淆

4.7 适用场景

• 显式缓存：RAG、文档问答、固定知识库查询
• 隐式缓存：快速原型、探索性开发
• 会话缓存：聊天机器人、多轮对话系统

5. GLM（智谱 AI）：透明隐式缓存

5.1 核心特性

技术亮点：

• 完全透明：用户无需感知缓存存在
• 自动识别：系统自动检测重复上下文
• 详细计费：响应中显示 cached_tokens 数量
• 全模型支持：GLM-5、GLM-4.7、GLM-4.6、GLM-4.5 系列

5.2 实现原理

GLM 的缓存实现：

1. 内容指纹：

   • 计算输入内容的哈希指纹
   • 识别相同或高度相似的内容
   • 复用之前的计算结果

2. 透明计费：

{
  "usage": {
    "prompt_tokens": 10000,
    "prompt_tokens_details": {
      "cached_tokens": 9000,
      "fresh_tokens": 1000
    }
  }
}

3. 智能预加载：
   • 预测用户可能的后续查询
   • 提前加载相关 KV Cache
   • 优化首次响应延迟

5.3 定价结构

5.4 优缺点分析

优势：

• ✅ 零配置，完全透明
• ✅ 详细计费信息，便于优化
• ✅ 广泛模型支持
• ✅ 无需代码改造

劣势：

• ❌ 用户无法控制缓存行为
• ❌ 缓存策略不透明
• ❌ 新模型的缓存价格未完全公开

5.5 适用场景

• 快速迁移：无需修改现有代码
• 成本监控：需要详细了解 token 使用情况
• 通用应用：对缓存策略无特殊要求

6. 综合对比矩阵

6.1 功能对比

6.2 定价对比（以 100K 输入 tokens 为例）

6.3 适用场景推荐

7. 选型建议

7.1 决策树

是否需要控制缓存行为？
├─ 是 → 选择 Qwen 显式缓存
└─ 否 → 继续

是否处理超长文档（100K+）？
├─ 是 → 选择 Kimi 或 Qwen-Long
└─ 否 → 继续

是否追求零配置？
├─ 是 → 选择 DeepSeek 或 GLM
└─ 否 → 选择 Qwen（灵活配置）

是否对成本极度敏感？
├─ 是 → 选择 DeepSeek（透明定价，节省显著）
└─ 否 → 根据其他因素选择

7.2 混合策略

在实际生产环境中，可以考虑混合策略：

1. 主供应商：DeepSeek（成本最优，自动缓存）
2. 备用供应商：Kimi（处理超长文档）
3. 特定场景：Qwen 显式缓存（需要保证命中率）

参考资料

• DeepSeek Pricing - DeepSeek 官方定价
• Mooncake GitHub - Mooncake 开源仓库
• Alibaba Cloud Context Cache - Qwen 缓存文档
• Z.AI Context Caching - GLM 缓存文档
• Prompt Caching Infrastructure Guide - 缓存基础设施指南