野生码农
周五下午,我的 AI 团队调度岗(我叫它"军师")拦住了一张待派的编码大单:"周额度只剩 11%,按计费口径折算下来,大约只够 50 万 token,这张卡扛不住。"
我盯着这个数看了三秒,回了它一句:"我 699 的套餐,你跟我说 11% 的额度只有 50 万 token?统计口径是不是有问题?"
它被问住了。重算之后,结论翻了快一百倍:剩余 11% ≈ 2800 万到 6600 万 token。这篇文章就是这次重算留下来的完整账本——Kimi Code 的套餐额度到底怎么换算成 token,我一周真实烧了多少,换成官方按量计费又是多少钱。
先说结论:三个数字
| 问题 | 答案 | 口径 |
|---|---|---|
| 我一周用了多少 token? | 5.33 亿(10-06 至 10-11,含缓存全口径)【实测】 | 本地逐请求日志统计 |
| 换成官方按量多少钱? | ≈ ¥1965【实测×官方价】 | 按 kimi-k3 官方单价折算 |
| 1 单位周额度 ≈ 多少 token? | 250 万~600 万(区间校准)【实测】 | 两组独立样本交叉验证 |
699 的套餐,按这个烧法,两天半就回本。下面讲清楚每个数是怎么来的,你可以用同样的方法算自己的账。
第一笔账:一周 5.33 亿 token 是怎么烧掉的
Kimi Code 的每次请求都会在本地留使用记录,我用自研脚本把本周(10-06 重置起)的记录全量聚合,含缓存读取——这点很重要,后面会看到缓存占了一半的钱:
| 日期 | 输入(非缓存) | 缓存读 | 输出 | 合计 |
|---|---|---|---|---|
| 10-06 | 371 万 | 1.45 亿 | 83 万 | 1.49 亿 |
| 10-07 | 845 万 | 1.66 亿 | 187 万 | 1.77 亿 |
| 10-08 | 374 万 | 2630 万 | 69 万 | 3074 万 |
| 10-09 | 433 万 | 1.01 亿 | 83 万 | 1.06 亿 |
| 10-10 | 262 万 | 5091 万 | 47 万 | 5401 万 |
| 10-11 | 91 万 | 1432 万 | 12 万 | 1534 万 |
| 合计 | 2376 万 | 5.04 亿 | 482 万 | 5.33 亿 |
【实测:5975 条逐请求记录聚合】
按项目拆,大头在三处:知识库系统 2.17 亿、调度总岗 1.29 亿、后端岗 1.10 亿——多岗位并行跑,缓存读就指数级上去了,因为每个请求都会重发一遍超长上下文。
第二笔账:官方定价到底是多少
这一步有个小插曲:官方定价页的表格是 JS 动态渲染的,直接抓页面拿不到数字,最后是从 HTML 源码里挖出来的。kimi-k3 的官方单价(每 100 万 token):
| 计费项 | 单价 |
|---|---|
| 输入(缓存未命中) | ¥20.00 |
| 输入(缓存命中) | ¥2.00 |
| 输出 | ¥100.00 |
| 缓存写入 | ¥20~40(本周为 0,不计) |
(来源:Kimi 开放平台定价页)
注意输出的单价是输入的 5 倍、缓存命中的 50 倍——让 AI 少说话、多复用上下文,是按量计费时代的省钱主线。
第三笔账:5.33 亿 token 折成人民币
| 计费项 | 用量 | 单价 | 金额 |
|---|---|---|---|
| 输入(非缓存) | 2376 万 | ¥20/M | ¥475.2 |
| 缓存读 | 5.04 亿 | ¥2/M | ¥1008.2 |
| 输出 | 482 万 | ¥100/M | ¥481.9 |
| 合计 | ≈ ¥1965 |
两个值得记住的结构特征:
- 缓存读占了 51% 的钱。只看"非缓存输入+输出"会漏掉一半成本——这就是军师最初估算错一百倍的根因:它拿了不含缓存的口径,还对错了时间窗;
- 输出量只有 482 万,却花了 ¥482。输出是最贵的 token,让 AI 写长文之前值得多想一秒。
关键换算:1 单位额度 ≈ 多少 token
Kimi Code 的周额度按"单位"显示(本周 89/100 已用),但官方没有公布 1 单位和 token 的换算关系,只说计费"取决于输入/输出量和缓存命中率"(来源:Kimi Code 会员文档)——缓存计入但打折,折扣参数未公开。
官方不给,就自己校准。用两组独立样本:
| 样本 | 全口径 token | 额度消耗 | 换算 |
|---|---|---|---|
| 全周累计 | 5.33 亿 | 89 单位 | 1 单位 ≈ 600 万 |
| 今日单日 | 1530 万 | 6 单位(83%→89%) | 1 单位 ≈ 250 万 |
取区间:1 单位 ≈ 250 万~600 万全口径 token。剩下 11 单位,就是 2800 万6600 万——而不是军师一开始说的 50 万。换成一张编码大卡的胃口(实测一张重卡在 2000 万6000 万之间),结论是:贴线,赌不得,等两天后的周重置满血再跑。
加油包为什么碰不得
额度打顶后官方提供"加油包"(Extra Usage):充值余额自动接续,任务不中断。听起来美好,但定价"接近开放平台官方 API 价"——也就是说一旦走进加油包,我这一周就是实打实的近两千块。
订阅制和按量计费在这里是两种物种:
| 维度 | 699 套餐(订阅) | 按量/加油包 |
|---|---|---|
| 本周用量成本 | 套餐内含 | ≈ ¥1965 |
| 打顶后果 | 等重置(最久 7 天) | 无缝扣余额,账单无感累积 |
| 适合谁 | 稳定高频的重度用户 | 偶发救急 |
另外从官方文档看到:新套餐已取消周额度上限(只留 5 小时滚动窗),价格不变,老用户可自愿迁移。重度用户值得评估。
可以抄走的东西
给自己算额度当量,三步:
- 记录此刻的额度读数(CLI 里
/usage,或 Kimi Code Console),跑一天正常负载; - 再读一次数,得到"消耗单位数",同时用本地日志或 Console 用量拿到同期的 token 全量(含缓存);
- 两者相除 = 你的 1 单位当量。样本取两个不同时间段交叉验证,单样本容易飘。
成本折算公式(以 K3 为例):
成本 ≈ 非缓存输入(M) × 20 + 缓存读(M) × 2 + 输出(M) × 100 (元)
两条使用纪律:
- 统计口径必须含缓存读,否则成本低估一半;
- 大任务排期看周额度剩余当量,不打顶、不碰加油包,等重置是最便宜的策略。
结尾
这次最值钱的收获不是某个数字,而是一个换算框架:套餐额度不再是黑盒的"百分比",而是可以校准、可以折算、可以排期的具体预算。699 一周烧出 1965 块的等效算力,前提是——你得知道每一块钱烧在了哪里。
素材点:校准区间(250-600 万/单位)会随官方折扣策略漂移,值得每月复测一次;K2.7-code 系列单价只有 K3 的 1/3 左右,轻任务降档是下一个省钱方向。