> ## 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 方案。

## 自动缓存机制

Kimi API 的 Context Caching 采用**全自动缓存机制**：

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

你只需像平常一样调用 API，系统会自动在合适的时机触发缓存优化。

## 计费说明

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

## 注意事项与最佳实践

1. **缓存命中条件**：系统会自动对高频重复的初始上下文进行缓存优化。请确保你的知识内容、system prompt 和工具定义相对稳定，以获得更好的缓存命中率。

2. **与多轮对话结合**：在使用 Context Caching 的多轮对话中，建议将固定的大段上下文（如知识文档）放在 `messages` 数组的最前面（system 消息之前），然后将用户问题和模型回复追加其后。系统会自动识别并缓存这些固定内容。

3. **无需额外配置**：Context Caching 对所有请求自动生效，你无需修改 API 调用方式或添加额外参数。只需关注你的 prompt 设计和业务逻辑即可。