为什么账单总比估算贵？大模型计费的 6 个隐藏开销
一个反复出现的场景：上线前按官方价目表认真算过成本，结果月底账单比估算高出一大截，而且复盘时每一笔扣费单独看都没错。问题通常不在厂商，而在估算模型本身——大多数人估的是「理想化的单轮调用」，账单记的却是「真实流量的完整形态」。
差距藏在六个地方：中文 token 折算系数拍错、思考型模型看不见的推理 token、多轮对话每轮重发全部历史、工具定义和返回值的输入开销、失败请求的部分计费，以及没设 max_tokens 导致的输出失控。每一条单独看都不起眼，叠在一起就是账单翻倍的常见配方。
这篇按排查优先级把六条过一遍，每条给具体的排查和止血动作，所有算例都列出算式，可以拿自己的量套着算。
一、中文 token 折算：别按字数拍脑袋
token 是计费的最小单位，可以理解为模型把文本切碎后的小片段，厂商按每百万 token 报价。坑在于：同一段意思，中文和英文切出来的 token 数差异很大；更麻烦的是不同厂商用不同的分词器（tokenizer，把文字切成 token 的程序），同一段中文在 A 家和 B 家切出的数量也不一样。任何「1 个汉字 = X 个 token」的固定系数，换个厂商、换种文体就不准了。
这个系数的误差会等比例传导到整个预算。假设你按字数折算估出每月 1 亿输入 token，用 Claude Sonnet 4.6（输入 ¥20.36/百万 token）做预算：20.36 × 100,000,000 ÷ 1,000,000 ≈ ¥2,036/月。如果实际 token 数比估算多三成，账单就变成 2,036 × 1.3 ≈ ¥2,647——业务什么都没变，纯粹是折算系数拍错了。
- 排查：取 5–10 段真实业务文本（务必是中文业务语料，不是英文示例），到 /estimate 按目标模型实测 token 数
- 用「实测 token 数 ÷ 字数」得到自己业务专属的折算系数；prompt 大改版后重新测一次
- API 响应里的 usage 字段是最终事实，上线后定期抽样核对估算与实际的偏差
二、思考 token：看不见的输出，照样按输出价收钱
思考型（推理型）模型在给出答案前，会先生成一段内部推理过程（reasoning token）。这段内容你在前端通常看不到，但多数厂商把它计入输出 token、按输出价收费——具体计量口径以各厂商官方文档为准。这是排查「输出 token 远超可见回复长度」时的头号嫌疑。
算一笔账：以 GPT-5.5（输出 ¥203.56/百万 token）为例，一次回答可见内容 500 token，成本是 203.56 × 500 ÷ 1,000,000 ≈ ¥0.10；如果模型先产出了 2,000 token 的内部推理，实际按 2,500 token 计费：203.56 × 2,500 ÷ 1,000,000 ≈ ¥0.51，单次成本是原来的 5 倍。多付的部分是 203.56 × 2,000 ÷ 1,000,000 ≈ ¥0.41/次，日均 1 万次调用就是约 ¥4,071/天的隐形支出。
思考 token 杀伤力大的根源，是输出价普遍比输入价贵好几倍：
- 止血：分类、抽取、格式转换这类简单任务别用思考型模型，或在请求参数里关闭/调低思考模式（各家参数名不同，以官方文档为准）
- 核对 usage 返回里的推理 token 字段，算清思考占输出的比例再决定要不要留
- 确需推理能力时，先试「非思考模型 + few-shot 示例」，很多场景效果够用、成本低一个量级
| 模型 | 输入 ¥/百万 | 输出 ¥/百万 | 输出÷输入 |
|---|---|---|---|
| GPT-5.5 | 33.93 | 203.56 | 约 6.0 倍 |
| Claude Sonnet 4.6 | 20.36 | 101.78 | 约 5.0 倍 |
| Doubao 1.6 | 2.40 | 24.00 | 约 10.0 倍 |
| Gemini 2.5 Flash | 2.04 | 16.96 | 约 8.3 倍 |
| GLM-5.1 | 6.00 | 24.00 | 约 4.0 倍 |
| DeepSeek V4 Pro | 3.00 | 6.00 | 约 2.0 倍 |
三、多轮对话：每一轮都在为全部历史重新付费
LLM API 是无状态的——服务端不记得上一轮说了什么，每轮请求都要把完整对话历史重新发一遍。于是第一轮的问答，会在第二轮、第三轮……每一轮里被反复按输入价计费。这是聊天类产品账单失控最常见的原因。
套个典型参数：system prompt 500 token，每轮用户提问 100 token、助手回复 300 token。第 i 轮的输入约是 600 + 400 × (i−1) token，聊满 20 轮累计输入 = 20 × 600 + 400 × (1+2+…+19) = 12,000 + 400 × 190 = 88,000 token。如果你当初按「每轮只付 system + 当轮问题」估，只有 20 × 600 = 12,000 token——实际是估算的 7 倍多。按 Claude Sonnet 4.6 输入价算：实际 20.36 × 88,000 ÷ 1,000,000 ≈ ¥1.79/会话，估算却只有 20.36 × 12,000 ÷ 1,000,000 ≈ ¥0.24；日均 1,000 个这样的会话，就是 ¥1,792 和 ¥244 的差距。
好消息是历史重发恰好是提示缓存（prompt caching）的主场：命中缓存的输入按缓存价计费，比如 Claude Sonnet 4.6 缓存读取 ¥2.04/百万 token，约为标准输入价的 1/10（20.36 ÷ 2.04 ≈ 10）。缓存写入可能有额外费率、各家缓存机制差异也大，以官方文档为准。
- 止血：限制携带的历史轮数，或对早期轮次做摘要压缩，别无脑全量重发
- 把 system prompt 和稳定不变的前缀放在消息最前面，提高缓存命中率
- 监控「平均每请求输入 token」曲线：持续上涨基本就是历史在膨胀
四、工具调用：函数定义和返回值都是输入 token
函数调用（function calling，把可用工具的 JSON Schema 描述发给模型，让它决定调哪个）有两笔容易漏算的账：一是工具定义本身随每次请求发送，全部算输入 token；二是工具执行结果回传给模型时，同样按输入计费。挂 20 个工具、每个定义几百 token，相当于每次请求都背着几千 token 的固定包袱。
Agent 场景下这笔账会被循环放大：一次任务跑 10 轮工具循环，每轮都重发 3,000 token 的工具定义，仅定义部分就是 30,000 token。按 Kimi K2.6（输入 ¥6.5/百万 token）计：6.5 × 30,000 ÷ 1,000,000 ≈ ¥0.20/任务，月跑 10 万次任务就是 0.195 × 100,000 = ¥19,500——这还没算工具返回值和对话历史。
- 排查：抓一次完整请求体，数清工具定义实际占多少 token（可贴到 /estimate 实测）
- 按场景动态裁剪工具列表，别把全家桶定义塞进每个请求
- 工具返回值做截断或摘要，别把整页 HTML、全量 JSON 原样回灌给模型
- 给 agent 循环设轮数上限，并按任务记录 token 用量日志
五、重试、超时与 max_tokens：失控输出的两个来源
失败不等于免费。请求超时、客户端断开时，模型已经生成的那部分内容通常照常计费（具体口径各家不同，以官方文档为准）。如果重试逻辑写成「失败立刻原样重发」，一次网络抖动期间，同一个用户请求可能被计费 3、4 次；流式输出场景下客户端提前断开是否停止计费，各家行为也不一致。
另一个失控源是没设 max_tokens（单次回复的输出上限）。本想要 200 token 的摘要，模型偶尔发挥成 4,000 token：按 GLM-5.1（输出 ¥24/百万 token）计，正常一次 24 × 200 ÷ 1,000,000 ≈ ¥0.005，失控一次 24 × 4,000 ÷ 1,000,000 ≈ ¥0.096，是正常情况的 20 倍。结合上面的表——输出价普遍是输入价的数倍——输出失控远比输入膨胀伤钱包。
- 所有请求显式设置 max_tokens，按业务输出长度的 P99 再留 20–30% 余量
- 重试加指数退避和次数上限，区分「可重试的网络错误」和「重试也没用的内容问题」
- 在网关层记录每个请求（含失败请求）的 usage，失败消耗单独打标统计
- 对「输出 token ÷ 可见回复长度」做告警，比值异常说明有思考 token 或输出失控
六、上线前：按真实调用形态把月账单算一遍
回看这六个坑，共同点是估算输入用的是「理想单轮调用」，而账单记录的是「真实流量形态」。所以止血的最后一步，是在上线前用真实参数重新估一次月账单，而不是事后对着账单猜。
一个可执行的工作流：
- 第一步：拿真实业务语料到 /estimate 实测输入、输出 token 数，得到自己的折算系数
- 第二步：把单次请求输入还原成「system prompt + 历史均值 + 工具定义 + 当轮内容」的完整形态
- 第三步：用思考型模型的，输出按「可见回复 + 推理 token」估，比例从 usage 实测里来
- 第四步：拿日调用量到 /bill 按真实单请求量算月账单，再乘 1.2–1.5 的安全系数覆盖重试和流量峰值
- 第五步：上线第一周每天核对一次 usage 与账单，偏差超过 20% 就回头按本文六条逐项排查
常见问题
中文 1 个字到底等于几个 token？
没有统一答案。不同厂商分词器不同，同一段中文切出的 token 数差异可观，prompt 文体变化也会影响结果。别用任何固定系数，拿自己的真实业务文本到 /estimate 按目标模型实测，再用实测值做预算。
思考 token 在账单里能看到吗？
多数厂商会在 API 响应的 usage 字段里单独或合并返回推理 token 数，并按输出价计费；具体字段名和计量口径以各厂商官方文档为准。排查时对比「输出 token 数」和「可见回复长度」，差距大基本就是思考 token。
失败和超时的请求会扣钱吗？
一般来说，模型在失败前已经生成的部分会照常计费，流式断开后的行为各家不同，以官方文档为准。防御方法是给重试加退避和次数上限，并在网关层对失败请求的 token 消耗单独记账。
多轮对话的输入费有办法省吗？
两个方向：一是裁剪——限制历史轮数或做摘要压缩；二是用提示缓存，把 system prompt 等稳定前缀放最前面吃缓存价，例如 Claude Sonnet 4.6 缓存读取 ¥2.04/百万 token，约为标准输入价 ¥20.36 的 1/10。缓存写入费率以官方文档为准。
max_tokens 设多少合适？
按业务实际输出长度的 P99 分位再留 20–30% 余量。设太小会截断正常回复，不设则偶发的长输出会按输出价全额计费——而输出价普遍是输入价的数倍，失控成本很高。
文中价格与价格表同源、每日核对。选型前去看一眼最新价。
打开价格表 →