token计费单位

很多人第一次看 API 账单都懵：明明只发了几句话，为什么扣的是好几千 token？问题不在模型黑箱，而在你没搞清楚「计费单位」这回事。这篇从 token 是什么讲起，一路讲到输入输出怎么分别计价、为什么中文和英文的 token 数差这么多，最后给你一套不用背数字也能当场估出花费的算法。

很多人第一次看 API 账单都懵：明明只发了几句话，为什么扣的是好几千 token？问题不在模型黑箱，而在你没搞清楚「计费单位」这回事。这篇从 token 是什么讲起，一路讲到输入输出怎么分别计价、为什么中文和英文的 token 数差这么多，最后给你一套不用背数字也能当场估出花费的算法。

先给个预期：读完你不会记住任何具体单价，因为单价一直在动。你会得到的是判断口径和一套可以自己动手核对账单的算法。真正值钱的不是记住数字，而是知道什么时候该去站内哪个页面核对当时的数字。

Token 不是字，也不是词：先把这个单位认准

Token 是模型切分文本的最小计费颗粒。中文常见一到两个字一块，英文常见半个词到几个字母一块，所以「字数」和「token 数」永远对不上。有人拿一篇千字文去估费用，按字数算完发现差了一截，就是栽在这里。理解 token 是切分出来的块，而不是你肉眼数的字，后面所有估算才站得住。

更麻烦的是，同一个句子在不同模型、不同分词器下切出来的块数不一样。跨家比价前必须先对齐这个口径，否则你以为在比价格，其实在比两套不同的尺子。跨模型比较单价之前，先确认两边的 token 定义是不是同一回事，这是最容易被跳过的一步。

1. 取真实文本拿一段你自己业务里真实会发出去的内容，比如客服话术、产品描述或代码片段，别用示例句，示例句的切分结果没有参考价值。
2. 分别送进计数入口把同一段文本分别丢进两家的 token 计数入口，记录各自返回的 token 数。
3. 算出差异比例用两边的 token 数相除，得到一个比例。这个比例就是你跨家比价时必须先对齐的换算系数。

输入和输出是两笔账，单价不一样

输入 token 指你送进去的全部内容：系统提示、历史对话、检索片段、附件文本。很多人只算了当前那一个问题，漏掉了前面累积的上下文。你以为每次只发一句话，实际上每句话后面都拖着前面所有的对话，这部分全按输入价算钱。

输出 token 指模型生成的内容，通常单价更高。所以「让它多说两句」比「让它多读两页」贵得多。这个直觉要建立起来：读进去的东西便宜，写出来的东西贵，控制成本时优先压缩输出。

判断口径时看页面上是不是分列了输入价和输出价。只给一个综合单价的，比价时要把两边的输入输出比例拉齐才有意义。到站内的 API 价格页核对当时的数字，比拿记忆里的单价算账靠谱得多。

一次调用到底扣多少：把四个部分加起来

典型构成是：系统提示 + 历史消息 + 本次提问 + 生成结果。前三项按输入价，第四项按输出价。系统提示很多人根本没意识到它在计费，写了一大段角色设定和格式要求，每次调用都完整送一遍，这笔账不小。

多轮对话是成本放大器。因为每一轮都要把之前的对话重发一遍，轮次越深，单轮实际成本涨得越快。第一轮很便宜，第十轮的输入可能已经是第一轮的好几倍。给产品设计对话轮次上限时，要把这个增长曲线考虑进去。

系统提示

每次调用都完整送进去的固定指令，按输入价计费，能精简就精简。

历史消息

之前轮次的对话内容，每轮重发一遍，是长对话的主要成本来源。

本次提问

用户当前输入，通常只占整个输入的一小部分。

生成结果

模型输出，按输出价计费，单价通常高于输入。

中文和英文的 token 数差在哪，怎么估

中文一般比英文「吃 token」。同样信息量下，中文占总消耗更多。做中英双语产品要分别估，不能拿英文的预算套中文。有人拿英文文档测出一套成本，换成中文内容上线后账单翻上去，就是没分开算。

给一套粗估做法：按内容类型各取一段样本，纯代码、纯中文叙述、中英混排各来一段，数出 token 与字符的比例，之后用这个比例反推整批任务。比例落在哪个区间，比单一数字有用得多。

• 纯代码片段：符号多、缩进多，token 与字符的比例通常偏高。
• 纯中文叙述：常用字组合效率较好，但整体仍比英文同义内容吃 token。
• 中英混排：比例介于两者之间，取决于中英文谁占主导。
• 含大量标点和格式标记的文本：容易拉高比例，富文本要单独采样。
• 数字和编号密集的文本：逐个字符切分的情况多，比例也会上去。

提醒这是估算不是承诺，比例会随模型和文本风格浮动，预算要用区间而不是单一数字。真正要卡准的时候，到站内模型资料库看该模型当期的计费口径说明，那里会写清楚计数规则。

上下文越长为什么越贵：把它想成随身行李

每一轮请求都要把整个上下文重新送进去，上下文越长，单轮输入越贵。这件事和你想问的问题简不简单无关。你只是想问一句「上一个结论对不对」，但系统照样要把前面几万字全部送回模型，费用按全部内容算。

控制方法有几条：能拆会话就拆、能只带相关片段就别整篇塞、把固定不变的那部分放在前缀位置方便复用。这几条不冲突，通常要一起用。拆会话负责切断累积，片段检索负责减少单次输入，前缀复用负责摊薄固定成本。

什么时候不建议硬省：需要跨文档推理的任务，拆开反而要来回多跑几轮，总账可能更贵。这类要按任务整体算而不是按单次算。省钱的目标是总成本降下来，不是单次调用看起来便宜。

手算一次调用要多少钱：五步走

1. 跑出输入 token 数把你要发的完整内容，包括系统提示和历史消息，一起送进计数入口，得到一个输入 token 数。不要只测提问那一句。
2. 估典型输出长度取你实际返回结果的中位数长度，而不是最长或最短的那次。输出长度先按 token 计，不要按字数。
3. 拿当期单价去官方 API 价格页和站内价格追踪页拿当期的输入、输出单价。别用记忆里的数字，也别用截图里过期的数字。
4. 算单次成本输入 token 数乘以输入单价，加上输出 token 数乘以输出单价，得到单次调用成本。
5. 放大到月度量级乘以日均调用次数，再乘以 30，得到月度量级。算完和实际账单对一遍，差得多的通常是漏算了系统提示或历史上下文。

这套算法不需要背任何数字，只需要知道每一步去哪里取数。单价变了就重新取一次，算法本身不用改。把五步做成一张表贴在项目文档里，团队里谁都能自己估。

比价前必须对齐的四件事（检查清单）

比价翻车大多不是算错，是比较口径没对齐。下面四件事在比价前逐条确认，可以避开绝大多数误判。每一项都对应一个具体的核对动作，不是泛泛而谈。

• 计价单位是每百万 token 还是每千 token，看错一位数就是十倍误差，先确认单位再看数字。
• 输入输出是否分开定价，以及有没有区分缓存读写这类不同口径，只给综合单价的要追问构成。
• 额度、赠送、折扣是在账单前扣还是账单后返，这会影响你看到的实际单价，充值前后可能不是一回事。
• 币种和是否含税，跨境结算还要考虑汇率与手续费，这些在订阅地区价页面能对到参照。

还有一个容易忽略的点：免费额度用完之后是不是自动切到付费档，以及有没有并发限制导致你要多开账号。这些不体现在 token 单价上，但会实实在在影响总支出。到站内的中转站可信度检测和价格追踪页面看当时的记录，能帮你判断哪些说法经得起核对。

什么时候不必按 token 抠成本

不是所有场景都值得精算 token。调用量很小的个人试用场景，抠 token 的时间成本高于省下的钱，直接按官方价跑通流程更要紧。先验证产品能不能跑起来，比省那一点调用费重要得多。

已经买断订阅额度的场景，成本关键变成「额度有没有跑满」，而不是每次调用的 token 单价。这时候该盯的是利用率和闲置情况，不是单次调用省了几厘。两种场景的优化目标完全不同。

判断标准很简单：如果每月的调用费低于你花在核算上的时间成本，就别算了；如果调用费已经是一项可观的固定支出，那就必须建台账。中间地带的团队可以先粗估，等量级上来了再细化。这个判断本身比任何单价都稳定，不会随模型更新而失效。