跳转到主要内容
Context Caching（上下文缓存）会预先存储可能被频繁请求的大量数据；再次请求相同信息时，系统直接从缓存提供，无需重新计算或从原始数据源检索，从而节省时间和资源。在 Kimi API 中，Context Caching 对所有模型请求自动启用：当系统检测到重复的初始上下文（如 system prompt、知识文档、工具定义等）时，会自动复用已缓存的内容，为你带来成本优化和响应加速，无需手动创建或管理缓存。

​
频繁请求固定长上下文时使用

Context Caching 特别适合频繁请求、重复引用大量初始上下文的场景，例如：
  • 提供大量预设内容的 QA Bot，例如产品文档问答助手。
  • 针对固定文档集合的频繁查询，例如上市公司信息披露问答工具。
  • 对静态代码库或知识库的周期性分析，例如各类 Copilot Agent。
  • 瞬时流量巨大的爆款 AI 应用。
  • 交互规则复杂的 Agent 类应用。

​
Context Caching 与 RAG 怎么选

业界广泛采用 RAG（检索增强生成）方案进行长文本业务的降本。Context Caching 的降本幅度与业务特性高度相关，RAG 则与业务特性无关；两者的主要区别如下：
建议：频繁查询固定内容（如 FAQ、文档问答）时优先使用 Context Caching；内容极长且查询方向不固定时，可考虑 RAG 方案。

​
无需配置，缓存自动命中

Context Caching 采用全自动缓存机制，你只需像平常一样调用 API：
  • 无需手动创建：系统会自动识别并缓存高频使用的初始上下文。
  • 无需引用缓存 ID：调用 /v1/chat/completions 时按正常方式传入 messages 即可，系统会在后台自动匹配缓存。
  • 无需管理 TTL：缓存的生命周期由系统自动管理，无需人工干预。
系统会在合适的时机自动触发缓存优化。

​
计费

Context Caching 的计费方式与具体价格，请参阅产品定价页面的计费说明。

​
注意事项

  • 缓存命中条件：系统会自动对高频重复的初始上下文进行缓存优化。请确保你的知识内容、system prompt 和工具定义相对稳定，以获得更好的缓存命中率。
  • 多轮对话：将固定的大段上下文（如知识文档）放在 messages 数组的最前面（system 消息之前），然后将用户问题和模型回复追加其后，系统会自动识别并缓存这些固定内容。
  • 无需额外配置：Context Caching 对所有请求自动生效，无需修改 API 调用方式或添加额外参数，只需关注 prompt 设计和业务逻辑即可。