上个月我写了个小脚本，每天定时把一批日志丢给 DeepSeek 做归类。跑了一周，账单比预想的高。翻明细的时候看到一个「缓存命中」相关条目，命中率是零。查了一圈才明白，这笔钱我本来可以只花五十分之一。
这篇就把「上下文缓存」讲清楚：它是什么，折扣有多少，怎么让它命中，以及怎么确认自己真的省到了。
先说它是什么
上下文缓存（有的平台叫 prompt cache）是各家 API 服务商都有的省钱机制。它把你请求开头那一大段固定内容，暂时存在服务器上，只存几分钟。下次请求的开头和它一模一样，就算命中。命中的部分直接复用之前的计算结果，按折扣价计费。
为什么能省，要从计费方式说起。API 按 token 收钱，请求里的每个 token 都算钱，包括那段每次都不变的系统提示词。你发 100 次请求，这段话就原价付 100 次。缓存做的事，就是让这 100 次里除了第一次，其余都按折扣价来。
服务商做这笔买卖不亏。模型处理请求时，开头那段固定内容本来就会产生一份中间计算结果，前缀一样，这份结果可以直接搬出来用，不用重算。省下的算力让一块利给用户，双方都划算。
多轮对话是最大的受益场景之一。你每轮发过去的历史消息都落在请求开头，天然就是稳定前缀，会话聊得越长，缓存省得越多。这也是为什么长会话的真实成本，往往比你按全价估算的低不少。
折扣有多少？看真实价格
我翻了官方定价页，下面是 2026 年 10 月的价格，你看到这篇文章时建议再核一遍。
DeepSeek（deepseek-flash）：输入每 100 万 token，缓存未命中 0.15 到 0.3 美元，缓存命中 0.003 到 0.006 美元，命中价约为未命中的五十分之一。它还分高峰和闲时，各差一倍。有意思的是高峰时段的定义：UTC 1 点到 4 点、6 点到 10 点，换算过来正好是北京时间上午 9 点到 12 点和下午 2 点到 6 点。也就是说，上班干活的时间就是全价时间。
Kimi（kimi-k3）：输入未命中每 100 万 token 20 元，命中 2 元，官方文档原话是「命中价格仅为未命中价格的 1/10」。另外 Kimi 把「缓存写入」单独列成了计费项，往 5 分钟档写一次收 20 元，1 小时档收 40 元。听着像加钱，官方的说法是这笔写入成本原来就含在输入价里，拆出来只是账单更透明，总价没变。
同样一次调用，命中和不命中差 10 到 50 倍。这就是我看着自己那个零命中率账单肉疼的原因。关于 API 到底怎么按 token 算钱，之前写过一篇，这里不展开。
重点：怎么才能命中
缓存按「前缀」匹配。前缀就是你请求最开头的那部分内容。规则很死板：开头每一个字都得一样，差一个字，从这个字往后全部作废，按未命中算钱。它只看消息内容，所以省钱的动作只有一个：把不变的内容放前面，变的放后面。
适合放在请求开头的：系统提示词、工具定义、反复使用的参考资料、代码库说明，也就是每轮都不变的那部分。放在后面的：用户当前的问题、工具返回的结果、会话状态，每轮都在变的东西。
举个直观的例子。messages 数组里，第一条放系统提示词，第二条放参考资料，这两条每次请求原样复制，一个字都不改。今天的问题放最后一条。就这么简单。
两个坑提醒一下。
我第一次改自己的脚本，以为要加什么特殊参数。后来发现 Kimi 默认就开着缓存，不传参数也是 5 分钟档。真正要动的，只是内容的摆放顺序。
第一，别在开头拼时间戳、随机 ID 这类动态字段。哪怕只动最前面几个字，整段缓存就废了。见过有人在系统提示词前面加一行「当前时间：xxx」，每一秒都不一样，缓存等于没配。
第二，注意缓存的保质期。Kimi 默认只存 5 分钟，超时没有新请求就过期。如果你的调用间隔经常超过 5 分钟，就在请求里加上 prompt_cache_options，把 ttl 改成 1h。写入费贵一倍，40 元。但按官方给的算法，1 小时内命中 2 次就回本，之后每次命中都是净赚。命中还会自动续期，一直用就一直不过期。
怎么确认真的省到了
别信感觉，看数据。每个请求返回的 usage 里都有缓存明细。以 Kimi 的 Chat Completions 接口为例，usage.prompt_tokens_details.cached_tokens 是命中了多少 token，cache_write_tokens 是写入了多少。用流式输出的话，记得带上 stream_options.include_usage=true，不然最后一个 chunk 里看不到完整的用量。
DeepSeek 的账单同样区分缓存命中和未命中。用 OpenRouter 这类聚合平台的话，大多数模型默认就开了缓存，它还会把你的请求尽量路由到同一家服务商，就是为了提高命中率，这个细节挺贴心。
算一笔小账
放大到批量场景算一笔：系统提示词加规则说明 5000 token，每天跑 200 次。改造前，光这段固定内容每天就是 100 万 token 的输入量，按 DeepSeek 全价一个月要花 4.5 到 9 美元。改造后，每天只有第一次按原价，剩下的全部走命中价，一个月掉到两三毛钱。
改动总共花了五分钟：把固定内容挪到 messages 数组最前面，变量放后面，完事。业务逻辑一行没动。
如果你也在跑定时任务、批量处理，或者任何带长系统提示词的应用，现在就去翻账单，看缓存命中率那一栏。如果是零，你知道该怎么做了。想让定时任务的输出更稳定，可以配合之前那篇 temperature 和 top_p 的设置一起用，一个管钱，一个管质量。