跳转到主要内容
Context Caching（上下文缓存）是一种高效的数据管理技术，它允许系统预先存储那些可能会被频繁请求的大量数据或信息。当你再次请求相同信息时，系统可以直接从缓存中快速提供，而无需重新计算或从原始数据源中检索，从而节省时间和资源。 在 Kimi API 中，Context Caching 为所有模型请求自动启用，无需手动创建或管理缓存。当系统检测到重复的初始上下文（如 system prompt、知识文档、工具定义等）时，会自动复用已缓存的内容，为你带来成本优化和响应加速。 Context Caching 特别适合频繁请求、重复引用大量初始上下文的场景，例如：
  • 提供大量预设内容的 QA Bot，例如产品文档问答助手。
  • 针对固定文档集合的频繁查询，例如上市公司信息披露问答工具。
  • 对静态代码库或知识库的周期性分析，例如各类 Copilot Agent。
  • 瞬时流量巨大的爆款 AI 应用。
  • 交互规则复杂的 Agent 类应用。

​
Context Caching 与 RAG 方案的比较

业界广泛采用 RAG（检索增强生成）方案来进行长文本业务的降本。Context Caching 与 RAG 的主要区别如下：
维度Context CachingRAG
业务成本与业务特性高度相关，特定场景下成本压缩程度极高，最高可达 90% 降本与业务特性无关，任何业务均可降本，但召回精度问题可能导致回答准确率下降
研发成本相对较低，系统自动处理缓存，无需额外接入或调优相对较高，需要 RAG 与 Embedding 结合，并持续进行业务定制化调优
额外优势提升长文本场景下的响应速度，首 Token 延迟平均可降至 5s 内原始文本长度可扩展到非常长，对一次性需要几百万字上下文的场景更友好
建议：如果你的场景是频繁查询固定内容（如 FAQ、文档问答），优先使用 Context Caching；如果内容极长且查询方向不固定，可考虑 RAG 方案。

​
自动缓存机制

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

​
计费说明

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

​
注意事项与最佳实践

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