> ## Documentation Index
> Fetch the complete documentation index at: https://platform.kimi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 使用 Kimi API 的 Context Caching 功能

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

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

Context Caching 特别适合频繁请求、重复引用大量初始上下文的场景，例如：

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

## Context Caching 与 RAG 怎么选

业界广泛采用 RAG（检索增强生成）方案进行长文本业务的降本。Context Caching 的降本幅度与业务特性高度相关，RAG 则与业务特性无关；两者的主要区别如下：

| 维度   | Context Caching            | RAG                                    |
| ---- | -------------------------- | -------------------------------------- |
| 业务成本 | 特定场景下成本压缩程度极高，最高可降本 90%    | 任何业务均可降本，但召回精度问题可能导致回答准确率下降            |
| 研发成本 | 相对较低，系统自动处理缓存，无需额外接入或调优    | 相对较高，需 RAG 与 Embedding 结合，并持续进行业务定制化调优 |
| 额外优势 | 长文本场景下首 Token 延迟平均可降至 5s 内 | 原始文本长度可扩展到非常长，适合一次性数百万字上下文的场景          |

> **建议**：频繁查询固定内容（如 FAQ、文档问答）时优先使用 Context Caching；内容极长且查询方向不固定时，可考虑 RAG 方案。

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

Context Caching 采用全自动缓存机制，你只需像平常一样调用 API：

* **无需手动创建**：系统会自动识别并缓存高频使用的初始上下文。
* **无需引用缓存 ID**：调用 `/v1/chat/completions` 时按正常方式传入 messages 即可，系统会在后台自动匹配缓存。
* **无需管理 TTL**：缓存的生命周期由系统自动管理，无需人工干预。

系统会在合适的时机自动触发缓存优化。

## 计费

Context Caching 的计费方式与具体价格，请参阅[产品定价页面的计费说明](/pricing/chat#计费逻辑)。

## 注意事项

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