Kimi K3 成本计算器
你的负载、官方费率，以及提示词缓存到底能省多少。全部在你的浏览器里本地计算——不向任何地方发送数据。
预估月账单 · 按 30 天
$—
前缀输入 —
变动输入 按 $3.00/1M—
输出 按 $15.00/1M，含推理—
合计—
同样负载、缓存命中为零—
缓存为你省下—
费率引自官方定价页，读取于 2026-07-16——你通过 EvoLink 支付的费率与此完全一致。这是估算，不是报价：每段冷启动后的第一次调用按全价计费，结尾最多 255 个 token 永远不会被缓存，实际的推理占比也因提示词而异。
三个参考负载
与上面计算器同一套算法，提前算好——供你找感觉，也照顾没开 JavaScript 的读者。采用 2026-07-16 官方费率；按每月 30 天计。
| 负载 | 结构 | 每月 | 不用缓存 |
|---|---|---|---|
| 轻量聊天机器人 | 每天 1,000 次请求 · 变动输入 400 · 输出 600 · 无重复前缀 | $306 | $306 （没有可重复的部分） |
| Agent 循环 | 每天 200 次请求 · 50k 固定前缀、命中率 90% · 变动 500 · 输出 800 | $252 | $981 |
| 长文档问答 | 每天 20 次请求 · 400k 文档、命中率 95% · 变动 200 · 输出 1,000 | $114 | $729 |
聊天机器人这一行是个输出成本问题——提示词从不重复，缓存帮不上忙，而推理就藏在那个输出数字里。后两行则说明为什么值得花一个下午做好前缀布局：同样的流量，成本差 4–6 倍。
账是怎么算的
输入 token 分成两股。固定前缀命中缓存时按 $0.30/1M 计费，未命中按 $3.00/1M——你的命中率把两者混成一个综合价。变动轮次永远进不了缓存，所以一律按 $3.00/1M 计费。输出按 $15.00/1M 计费，而在 K3 上这包含你看不到的推理 token——所以上面输出那一栏该填的数字，比光看回答长度要大得多。
最大的杠杆是命中率——把滑块从 0 拖到 90%，盯着前缀那一行看。让命中率保持在高位是提示词布局问题，不是花钱问题：稳定内容放最前、变动轮次放最后、别让会变的内容混进前缀。