第一次接入模型 API,账单出来跟自己的估算对不上,是很常见的事。多半不是被多扣了,而是对 token 计费规则的理解跟平台的口径不一致:什么算输入、什么算输出、系统提示词要不要计费、缓存命中怎么算、为什么同样的字数不同平台价格差一截。这篇不报具体数字,只把规则讲透,再给你一套自己核对的方法。
第一次接入模型 API，账单出来跟自己的估算对不上，是很常见的事。多半不是被多扣了，而是对 token 计费规则的理解跟平台的口径不一致：什么算输入、什么算输出、系统提示词要不要计费、缓存命中怎么算、为什么同样的字数不同平台价格差一截。这篇不报具体数字，只把规则讲透，再给你一套自己核对的方法。
先把预期摆正：token 计费不是「按字数收钱」，而是一套由切分方式、计价维度、计价档位共同决定的规则集合。你不必背下任何一家平台的数字，但必须弄清它是按哪几个维度收、每个维度怎么归因。下面按「先认单位、再分账、补漏算项、对齐平台差异、换算成钱、排查偏差、养成习惯」的顺序走一遍。
先搞清：到底什么东西在计费
计费单位是 token 不是字。中文一句话、一段带缩进的代码、一堆标点和空格，被切分器切成多少块，各家结果并不一致。所以别拿字数乘一个系数去估钱，估出来的数只能当参考，不能当账。
更关键的是范围。一轮请求里，系统提示词、历史对话、用户输入、模型输出，通常都算在内。很多人估算是只算了用户那句话，漏掉系统提示词和上文，自然对不上。想直观感受切分方式，先去站内把 Token 与上下文这两个词看一遍，再到单价换算页感受一下量级。
- 计费单位
- token，不是字符也不是字数，切分粒度因中英文、符号、代码而异
- 单次调用范围
- 系统提示词 + 历史对话 + 本次输入 + 模型输出，通常都在计费范围内
- 上下文长度
- 前面塞得越多，本轮输入 token 越高，成本随轮次累积
- 查看入口
- 站内的基础词典页与单价换算页，先用文字直觉对齐概念
输入和输出是两笔账，别加成一个数
多数平台输入输出分别定价，而且输出通常更贵。这意味着「答案长」比「问题长」更烧钱：把一个啰嗦的回答压短，往往比把提示词精简更见效。把两者加成一个总数去比较，是最容易得出错误结论的做法。
支持思维链的模型要特别注意：思考过程可能按输出计费，也可能单列一项。接入前先确认它归在哪一栏，否则你按可见回答长度估算，会系统性偏低。
| 拆项 | 典型归属 | 估算时容易犯的错 |
|---|---|---|
| 用户提问 | 输入 | 只算这一项，漏掉系统提示词 |
| 系统提示词 | 输入 | 以为平台不收，其实每轮都带上 |
| 历史对话 | 输入 | 多轮后累积，没按轮次摊 |
| 可见回答 | 输出 | 按字数估，没按 token |
| 思考过程 | 输出或单列 | 默认不计，实际可能计入 |
什么情况下不适用：部分平台对超长输入做阶梯或统一价，输入输出的价差会被压缩，这时按固定倍率去估会偏。实操上，把每次调用的输入 token 和输出 token 分开记，后面对账才有依据。
缓存、工具调用、重试：三个容易漏算的位置
前面把输入输出分清了，账目还是可能缺三块。缓存写入和缓存读取通常是两个不同的单价项，不是简单打个折；多轮对话里同一段上下文反复发送，能不能命中缓存，直接决定实际花多少。
- 缓存写入：把上下文存进缓存时的一次性成本，很多估算直接漏掉
- 缓存读取：命中后按另一档计价，比重新传一遍便宜，但不是免费
- 多轮上下文：同一段系统提示反复发送，命中与否决定了它算一次还是多次
- 工具调用：一次业务动作可能对应多轮请求，每轮都要单独算输入输出
- 限速重试：重发要不要重算，看返回状态和平台规则，别默认不收费
- 批量任务：有的平台单独设档，不能拿实时单价乘总量
判断标准很简单：一笔业务动作在代码里对应几次 API 调用？如果答不上来，说明你的用量日志还没建起来，这时候讨论单价没有意义。
各家口径的差异在哪几处
跨平台比价之前，先确认比的是不是同一个东西。差异主要集中在四处：切分器、计价维度、命名习惯、以及套餐形态。
| 差异点 | 表现 | 比价时的处理 |
|---|---|---|
| 切分器 | 同一段中文数出来的 token 数会有出入 | 先对齐切分口径，再比价格 |
| 计价维度 | 有的对缓存、批量、长上下文另设档位 | 问清档位，别拿基础档互比 |
| 命名习惯 | 输入叫 prompt，输出可能叫 completion 或 output | 报数时做一张字段对照表 |
| 套餐形态 | 订阅制或编程套餐走额度折算 | 换一套口径，不适用线性折算 |
| 长上下文 | 超长输入可能进另一档 | 先看档位划分再估 |
不适用情形也要说清：订阅制或编程套餐走的是额度折算，不按上面这套线性算。如果你用的是这类套餐，得换一套口径看，别拿 API 的算法往上套。
从 token 数到钱：换算的正确顺序
换算本身不复杂，错在顺序。正确顺序是：先拿到本次调用的输入输出 token 数，响应里通常带 usage 字段；再去查当期单价；最后做乘法，注意单位是每百万还是每千。漏掉一个量级，是最常见的低级错误。
- 取数从响应体的 usage 里取输入、输出、缓存写、缓存读四个数，落日志，不要靠肉眼抄
- 查价到站内官方 API 页面核对当期单价，注意它标注的单位是每百万还是每千 token
- 对齐档位确认本次调用落在哪一档：是否命中缓存、是否属于批量任务、上下文是否超长
- 相乘汇总各档分别乘再相加，别把不同档位的量合并乘一个价
- 横向参照到站内用量页看同类任务的真实水平，判断自己的量级是否异常
换算完跟账单对不上，先怀疑口径差异，而不是先怀疑平台。多数偏差来自你把某个计费项归错了栏，或者漏了缓存与重试。
预估和账单对不上时的排查顺序
对账要按顺序来，跳步会来回折腾。下面这套顺序，建议直接抄进排查清单。
- 第一步对 token 数：自己数一遍和平台返回的 usage 比，差异大说明切分或上下文范围理解错了
- 第二步对单价：确认用的是哪一档、有没有阶梯或时段差异
- 第三步对范围：有没有别的入口、别的 key、别的环境在共用同一个账号
- 第四步对时间：账单周期和你本地统计的窗口是否对齐
- 第五步对重复：有没有失败重试、定时任务、开发环境来回调用
什么情况下这套排查无效：账号被多人共用又没有分 key，账单无法归因。这时得先做用量日志，把 key 和业务拆开，再谈对账。另外，如果账单周期与你的统计窗口跨天，先统一时间口径再看差异。
几个能少踩坑的记账习惯
与其月底对着账单猜，不如在调用侧就把数据留下来。下面几条是最小可用的做法，一个 5 人小团队也能当天落地。
- 每次调用把 usage 落库，字段至少覆盖输入、输出、缓存写、缓存读、模型标识
- 上线前用小样本跑一遍，把「一笔业务动作等于几次调用、大概多少 token」摸清楚
- 给预算设阈值告警，而不是月底才发现超了
- 按 key 或环境拆分用量，方便归因到具体功能
- 口径类信息会变，别硬记数字，定期去看价格变动记录
这篇不解决什么
把边界说清楚，省得你找错页面。本文只讲 token 计费的规则口径和核对方法，不提供任何具体单价和跑分，这些去站内对应页面看当时的数字。
- 不覆盖订阅制、编程套餐的额度折算逻辑，那是另一套口径
- 不讨论自建推理的摊销成本，那属于算力与部署话题
- 不给任何绝对化的省钱承诺，用量取决于你的业务形态
- 不代替平台官方计费文档，口径有冲突时以平台当期说明为准
常见问题
token 到底怎么数?一个字等于几个 token?
没有固定换算。英文常见情况是一个词拆成若干 token,中文往往一个字对应一到多个 token,标点、空格、代码符号都会单独占位。同一段文本在不同平台数出来的结果也可能不同,因为切分器不一样。想准确,就以接口返回的 usage 字段为准,不要用字数估。
为什么我只发了一句话,计费的输入却很大?
多半是系统提示词和上下文一起算了进去。很多应用会在每次请求里重复带上完整的历史对话和一段较长的指令,这些都属于输入。轮次越多,输入越大。想省这块,通常靠控制历史长度或让缓存生效,而不是缩短用户那句话。
输出比输入贵是普遍规则吗?
多数平台是这样,但不是铁律。有的平台对超长输入设了更高的档位,有的对缓存读取给很低的价格,价差结构会不一样。所以比价时不能只看「输出贵几倍」这一个比值,要按你的实际输入输出比例去算。具体数字到站内的官方 API 页面核对当期口径。
限速被拦截后重发,会重复计费吗?
看返回的是哪种错误。请求根本没被处理,通常不计费;已经被处理但连接中断,可能已经算了。稳妥做法是记录每次响应的状态和 usage,对不上的时候拿日志去问。别靠猜,重试密集的场景前期最好留一段观察期。
怎么确定我算出来的 token 数是对的?
最可靠的是对照接口返回的 usage,而不是自己用工具数。自己数可以用来发现「漏算了系统提示词」这类结构性问题。如果长期不一致,就把每次调用的输入输出和缓存字段都记下来,再做汇总,差异会很快暴露在哪一环。
