Kimi K3 缓存费用怎么算：5 分钟与 1 小时 TTL 如何选择

为什么只看缓存命中价不够

长系统提示词、重复文档和工具定义可能在多次请求中形成相同前缀。Kimi K3 文档说明这类内容可自动使用缓存，默认有效期为 5 分钟，也支持 1 小时选项。但 K3 的缓存写入单独收费，不能把一次写入加一次命中的过程，只按较低的命中单价估算。来源 1 来源 2

缓存不会减少任务需要理解的内容，它改变的是可复用部分的处理与计费方式。是否划算，要看真正命中了多少 Token、写入发生几次，以及复用间隔。

TTL 影响的是哪段时间

TTL 表示缓存的有效期。官方价格说明指出，在有效期内命中缓存，会刷新有效期，命中部分按缓存输入收费，不因此再次收取该部分的缓存写入费用。来源 2

如果相邻任务间隔很短，5 分钟可能已经覆盖复用需求；如果间隔更长，则可以比较 1 小时策略。但长 TTL 不是无条件省钱：要把对应写入价格、实际命中和任务节奏一起计算。缓存还存在块级处理等限制，不能假设每个相同字符都必然成为可计费的命中。

建立包含写入项的预算

可以将账单拆成普通输入、缓存读取、缓存写入和输出四类，再按官方 usage 与计费定义统计，避免把同一输入类别重复计入。若用量统一换算为百万 Token，预算可写成：

总费用 = 普通输入量 × 普通输入价 + 缓存读取量 × 读取价 + 缓存写入量 × 对应 TTL 写入价 + 输出量 × 输出价

这是预算分项，不是对任何 SDK 字段的直接映射。实际接入还应核对工具及其他收费项目。本文未取得可稳定核对的完整数值价格表，因此不填入猜测的单价，也不承诺固定节省比例。

本站通用费用计算器可以帮助理解输入、输出和缓存读取的算术，但模型特有的缓存写入与 TTL 费用，需要另外计入；不能把基础计算结果直接当作 K3 完整账单。

如何做一个有意义的对照

选一份允许用于测试的固定材料，保持可复用前缀一致，把每次变化的问题放在后面。记录第一次请求、有效期内重复请求和超过有效期后的请求，保存请求间隔、实际 usage 与账单。如果进一步比较 1 小时配置，也应使用相同任务和相近的请求节奏。

不要为了提高命中率把本应更新的业务资料固定在前缀里。材料发生实质变化时，应让请求反映新内容，再观察缓存行为，准确性优先于表面的命中率。

有界观察：用真实频率选择缓存策略

高频短间隔的交互，与偶尔触发的文档分析，有不同的收益结构。先采样真实请求间隔，再计算两种 TTL 的完整费用，通常比一律选择最长有效期更有依据。

Moonshot API 按量计费与 Kimi 产品会员或 Kimi Code 订阅不是同一个账单体系。通过有界调用时也需核对渠道是否透传相关设置与费用明细；官方缓存规则不自动证明所有中间渠道采用相同计费方式。