Kimi K3 在 7 月 17 日发布后被反复贴上"最便宜的前沿模型"标签。本文不重复这一标签，而是把它的 API 计费层拆开，看清表观价与真实成本之间的缝隙。

一、API 计费层架构：四个独立变量

K3 的 API 计费由四层叠加，每层都直接影响账单：

1. 输入层：缓存命中 2 元 / 未命中 20 元（每百万 tokens）
2. 输出层：100 元 / 百万 tokens（统一价，不分上下文档）
3. 思考层：与输出层共用 100 元 / 百万 tokens
4. 上下文层：1M token 上限，按实际入参 token × 单价计费，不分档

四层共同决定了真实账单。把任意一层忽略，都会得到一个不准确的数字。

二、思考 token 是最大的隐藏成本

官方文档明确：K3 始终推理，reasoning_effort 当前仅 max。也就是说任何一次调用都包含一段思考 token，且按输出价计费。

不同任务类型的思考占比经验值：

任务类型	思考 token / 输出 token
简单问答	0.5–1.5x
文档分析	1.5–3x
多步 Agent 任务	3–8x
复杂代码生成	5–10x

关键观察：越复杂的任务，K3 越"便宜"的表观优势被思考成本吃掉得越多。一个 3–8x 思考占比的 Agent 任务，输出侧真实成本可能是表观输出价的 4–9 倍。

三、1M 上下文不分档：规模越大，账单越线性放大

与某些模型在超过 32K 或 128K 后单价翻倍不同，K3 选择 1M 统一价。这意味着：

• 8K 任务 vs 1M 任务，输入侧成本差 125 倍
• 没有"用 32K 的人补贴用 1M 的人"的内部交叉补贴
• 设计 Agent 时需要更精细的上下文裁剪，而不是直接塞满

四、缓存命中率：宣传 90% 只覆盖编程场景

官方原话：“借助 Mooncake 分离式推理架构，Kimi 官方 API 编程场景的缓存率超过 90%。” 注意限定词是"编程场景"。

不同场景的经验命中率：

• 编程（多轮迭代同一文件）：80–95%
• 客服问答（多轮固定话术库）：40–60%
• 文档分析（每次不同文档）：10–30%
• 营销文案（每次不同 prompt）：5–15%

把"90% 命中率"直接套到所有场景，是这次宣传中最容易被忽略的细节。

五、可复用算账模板

设单次任务：输入 N tokens，思考 T tokens，实际输出 O tokens，缓存命中率 H。

单次成本 = N × (1−H) × 20 + N × H × 2 + (T + O) × 100

以"60K 长文档分析、思考 90K、输出 10K、缓存命中率 30%"为例：

• 输入：60K × 0.7 × 20 + 60K × 0.3 × 2 = 840 + 36 = 876 元 / 百万 = 0.876 元
• 输出（含思考）：(90K + 10K) × 100 = 10 元
• 单次账单 ≈ 10.88 元

如果错把表观"输入 2 元"当平均价，账单会被低估一个数量级。

六、算力供给侧的硬约束

7 月 19 日，月之暗面公告发布 48 小时后用户请求逼近集群承载极限，暂停 C 端新会员订阅。4 档年费会员（468/948/1908/6708 元）全部售罄。

API 暂时仍可调用，但 C 端体验入口已关。对企业用户的影响是：高峰期可能出现排队、限流、临时不可用。算账前先确认能稳定买到。

七、官方对能力定位的措辞

月之暗面公开声明：“虽然 Kimi K3 的整体表现仍落后于最强的闭源模型 Claude Fable 5 和 GPT-5.6 Sol，但在我们的整套评测中展现出前沿水平的能力，并稳定超过了其他所有模型。”

这条措辞定义了 K3 的真实位置：开源与价格阵营的旗舰，而非能力榜榜首。

八、建议

1. 上线前用算账模板估算真实账单，至少跑 3 个典型场景
2. 涉及多轮迭代的 Agent 任务，优先确认缓存命中率
3. 思考密集型任务（复杂推理、代码生成、长链规划）单独评估成本
4. 7 月 27 日开源权重发布后，再决定私有化部署是否值得
5. 短期采购建议：API + 限流配额双轨，避免单一供应商绑定

🔑