Kimi和K3的价格对比

你大概是在排模型选型表的时候卡住的：同事说 Kimi 长文本划算，另一拨人说 K3 更省，但两边拿出来的单价根本不是一回事——一个按输入输出分开报，一个套餐里塞了额度，还有人把缓存价当成了标准价。这篇不给你背数字，而是给一套对比口径和核算步骤，让你在站内页面上按当时的数字自己算出一份能拿去说服人的结论。

你大概是在排模型选型表的时候卡住的：同事说 Kimi 长文本划算，另一拨人说 K3 更省，但两边拿出来的单价根本不是一回事。一个按输入输出分开报，一个套餐里塞了额度，还有人把缓存价当成了标准价。这篇不给你背数字，而是给一套对比口径和核算步骤，让你在站内页面上按当时的数字自己算出一份能拿去说服人的结论。

核心思路只有一句：先把两边的钱是按什么维度收的对齐，再按你自己的真实用量结构去套，最后小流量验证一遍。跳过第一步直接比单价，是最常见的翻车方式。下面按四步走。

先对齐口径：两边到底在按什么收钱

不同平台的计费单位混在一起比必错。有的按 token 计价，有的按调用次数，有的把额度打包进订阅再折算按量价。你要做的不是记住某个数字，而是把每一条计费线摆到同一张表里，包括输入价、输出价、缓存读写价、批处理价各算几条线。

• 分清官方按量价和订阅/套餐折算价，后者要看额度上限和超量计价方式。
• 确认计价口径的版本，同一家平台也会改价、改倍率、改缓存规则，对比前先去 /price-watch 和厂商页看当期口径。
• 不适用情形：只调用几十次，或用量几乎全落在缓存命中上，这时单价差异会被摊薄到看不出来，不值得为比价花一整天。

确认你比的到底是哪几条模型线

Kimi 和 K3 各自可能有多档定位，便宜档和旗舰档的计费结构不一定一样。先把候选清单列成一张表，每行一条模型线，再去 /official-api/providers/moonshotai 和 /models 核对当期规格与计费入口，别拿旧文章里的数字直接用。

1. 列候选清单每条模型线一行，写清定位、上下文长度、是否有缓存和批处理档。
2. 核对当期规格去模型库页面确认规格与计费入口，确认没有把上一代的价格套到当前这条线上。
3. 标注阶梯点长文本场景下超出某个长度后可能有阶梯或额外倍率，把跳档位置标出来，方便判断结论会不会随任务长度翻转。

不适用情形：如果你的任务固定是短提示短输出，长文本档的差异跟你没关系，别被长上下文宣传带偏。反过来，如果任务输入经常很长，那么阶梯点就是你比价的真正战场。

按你的真实用量结构算，而不是按单价乘一乘

单价乘一乘只能得到错觉级的结论。正确做法是把最近一段时间的调用记录拆成输入 token、输出 token、缓存命中、重试次数四类，再套当期单价。去 /tools/model-cost-calculator 逐项填，比在表格里手算靠谱。

• 输入输出比例决定胜负：输出占比高的任务，输出价贵的一方会迅速落后；长输入短输出则比的是输入价和缓存价。
• 把重试和失败调用算进去：限速被卡后重发的那部分同样计费，量大的时候足以改变结论。
• 落一份一页纸结论：写的是两个模型在你这套用量下的月成本区间，而不是一个单价数字。
• 不适用情形：用量结构还没稳定、动不动翻倍的时候，这份测算的结论有效期很短，别拿它去锁长期方案。

算完别急着定，先小流量验证再定期复看

算出来的数字只是假设，真账单才是答案。用真实任务跑一周小流量，把实际账单和你的测算摆一起对。差得多说明口径里还有没对齐的东西，比如倍率、缓存、批处理折扣。这一周的小成本，换的是后面几个月不用重新翻案。

• 把对比结论写清适用边界：哪个用量区间选谁、超过多少量以后结论会变、什么时候需要重新比。
• 定期回看：价格和额度规则会动，隔一段时间去 /official-api 和 /price-watch 复看一次即可，不必天天盯。
• 不适用情形：项目还在验证期、用量可能翻很多倍时，此刻的最优解不值得锁死，先保证切换成本低更实在。