Kimi 的上下文缓存对重复前缀自动生效，但写入分 5 分钟（5m）与 1 小时（1h）两档 TTL——写入价差一倍（K3.1 Pro 分别为 ¥13 与 ¥26 每百万 token）。选错档的两种亏法：选 1h 但前缀只用一次，多付的写入费打水漂；选 5m 但请求间隔拉长，过期后反复重付写入。官方「上下文缓存最佳实践」文档（platform.kimi.com，核对时间 2026 年 11 月 3 日）给出了完整的机制与算例，这篇把它落成可对照的选档法。
先记住三条机制，再看算账
一是写入即锁定。缓存条目的 TTL 在首次写入时确定，之后不能改：同前缀命中时按原 TTL 免费续期，新增部分也按锁定的 TTL 续写。二是过期才能重写。想换 TTL，必须等现有条目完全过期后重新写入。三是缓存按块存。未凑满整块的尾部不计入缓存，按缓存未命中计费——所以前缀的稳定性比长度更重要，中途改一个字，从改动的位置往后全是 miss。
官方算例：几次命中回本
官方文档给的算例（以缓存命中价为输入价约十分之一计）：假设某段前缀按 5m 档写入要付 3 美元、按 1h 档要付 6 美元——选 1h 的额外成本是 3 美元；之后每一次命中，都把这段输入从 3 美元降到 0.30 美元，省 2.70 美元。一次命中省 2.70，抵不掉 3 美元的差额；两次命中省 5.40，扣掉差额净赚 2.40。换算成决策法：预估同前缀的命中次数，超过回本次数就选 1h，否则用默认 5m。官方 quickstart 的建议同向：来回紧凑的对话用默认 5m 足够，间隔超过 5 分钟的负载（定时任务、每小时一批的场景）传参选 1h，避免过期后反复重写。
三种 API 的设置方法对照
| 调用方式 | 默认 | 指定 1h 的方法 |
|---|---|---|
| Chat Completions / Responses API | 省略参数即按 5m 写入 | 传 prompt_cache_options：{"mode":"implicit","ttl":"1h"}（mode 目前仅支持 implicit） |
| Anthropic Messages API | 省略 cache_control 按 5m 读写 | 顶层传 cache_control：{"type":"ephemeral","ttl":"1h"}（messages 体内同名字段无效） |
两个配套细节：一是哪些模型支持缓存写入——官方 FAQ 明确 kimi-k3.1-pro 与 kimi-k3 支持，kimi-k2.7（含高速版）与 k2.6 不支持；还在 K2 上等迁移的读者，这部分收益要计入迁移决策（见K2 下线迁移）。二是成本追踪的字段——三种 API 的 usage 字段各不相同，缓存读、写与未命中部分互斥相加恰好等于总输入；流式调用要把 stream_options.include_usage 设为 true，最后一个分块里才有完整明细，账单里会单独出现 cache-write 行项。
提示词起手式（选档评估）：「我的调用模式如下：系统前缀 [描述长度与内容稳定性]、每批 [N] 次请求、批次间隔约 [X] 分钟。请按 Kimi 缓存 TTL 两档的官方算例（1h 比默认 5m 多付一倍写入费，每次命中省约九成输入费）估算：几小时内命中几次回本；我该选哪档。数字不确定就给区间。」
常见问题
- 命中率怎么提？固定内容前置、删除前缀里的时间戳与随机数、同前缀的请求聚批发——三个动作与命中率的关系见缓存命中率与账单一篇。
- 选错 TTL 了能改吗？不能就地改——等条目完全过期后用新 TTL 重写；急的话换个略有差异的前缀等于开新条目，但会多付一次写入。
- 网页版聊天也有这两档吗？TTL 是 API 侧的计费参数；网页版对话不涉及自选档位，计费见开放平台长上下文 API一篇。
