Kimi K3定价陷阱：推理Token按输出计费，账单超预期十倍

Kimi K3定价陷阱：推理Token按输出计费，账单超预期十倍 | 前端进阶之旅

Full translation

完整中文译文

两周前，我把 Kimi K3 接入了自己的 API 网关。1M 上下文、常驻推理能力，旗舰级模型。我看着用量数据攀升，心想"不错，大家挺喜欢"。

然后我仔细看了看。一次请求里，单个用户消耗了 243,745 个 tokens。一次请求。31 秒。大部分都是静默的。

看这个请求时间线：

first_token_ms: 13,609 ← 13.6 秒的沉默
latency_ms: 31,910 ← 总计 31.9 秒
tokens: 243,745 ← 整整 25 万个 tokens

整整 13.6 秒，没有任何输出。这不是网速慢，是 K3 在思考。而思考过程中的每一个 token 都要计费。

K3 没有"思考模式"开关。它始终在推理。每个请求在返回答案之前都会先经过一轮推理。推理产生的 tokens 会算进 completion_tokens——和最终答案用同一个计量桶。

所以，一道题让 deepseek-chat 回答需要 200 tokens，让 K3 回答需要 200,000 tokens。同一道题。同样的答案质量。成本差了 1000 倍。

在排查过程中，我发现 token 计数器存在重复计算。在流式 handler 里：

total_tokens += usage.get("total_tokens", 0)
total_tokens += usage.get("completion_tokens", 0)   # ← 冗余的

total_tokens 已经包含了 completion_tokens。再重复加一次，就导致每个 completion token 被计算了两遍。对于推理模型来说，completion 部分主要由思考内容构成，膨胀效应非常惊人。

日志显示某用户消耗了 1.5M tokens。实际扣费是 500K。整整 3 倍的差额，全是重复计算导致的。

删掉一行代码，修好了。

Kimi K3 的真实成本结构是这样的：

$15/M 的 output 才是关键。推理 tokens 算作 output。一次深度代码审查可能消耗 3-4 个单位。一天十个这样的请求，就是 $40。对于免费 tier 来说，这是个快速的出血点。

我应该从第一天就定下的规则：

用 K3 做它擅长的事：长上下文代码审查、深度调试。
其他场景用 deepseek-chat：分类、摘要、简单生成。

不是因为 K3 不好。是因为推理模型成本高昂，而"始终在思考"意味着你始终在为思考付费。

重复计算这个 bug 是我的问题。成本结构是客观现实。两者都教会了我同一课：推理模型不是免费的升级。它是一个不同定价的不同工具，如果你把所有请求都路由到它，账单会在用户之前就先找上门来。

我们是 AIBridge——一个 OpenAI 兼容端点背后接入 15 个国产模型。包括 K3，对于合适的任务来说它依然值得。