Token计费是按字节来算的吗

很多人第一次看账单会愣一下：明明只传了几百 KB 的文本，怎么扣了这么多 token？也有人反过来，按字数估了个价，结果账单对不上。问题多半出在把 token 当成了字节或字符。这篇把三者的关系讲清楚，给一套能自己动手估 token 的办法，以及估不准时该去站内哪一页核对。

很多人第一次看账单会愣一下：明明只传了几百 KB 的文本，怎么扣了这么多 token？也有人反过来，按字数估了个价，结果账单对不上。问题多半出在把 token 当成了字节或字符。这三者根本不是一回事，量级也不成固定比例，拿文件体积去套账单，误差会大到你没法做预算。

这篇不绕弯子，直接把 token、字节、字符三者的关系拆开，给一套能自己动手估 token 的口径，再说清估到什么程度就该去站内核对当时的数字。目标很简单：下一次发请求之前，你心里对这次大概花多少有个数，而不是等账单出来再复盘。

为什么大家会把 token 当成字节

账单单位是 token，但日常最容易看到的数字是文件大小和字符数。写代码的时候看的是行数和文件体积，写文案的时候看的是字数统计，于是很自然就拿来套。三者量级在高频英文下确实接近，碰巧对上一次，错觉就固化成经验了。

• 英文短单词占比高时，一个词常被当成一个 token，跟字符数差得不算离谱，容易被当成等价
• 中文、代码、URL、emoji 一上来，比例完全走样，但你已经默认了那套换算，不会重新怀疑
• 文件体积是从存储视角算的，编码方式一变数字就变，跟模型怎么切词没有直接关系
• 多数人从来没看过分词结果，只见过账单，缺少一个能把两者对上的中间参照

token、字节、字符：三个单位各管什么

把三个单位想成三把不同的尺子。token 是模型分词器的切分结果，同一段文字换个模型，切法可能就不一样，所以 token 数天然带模型属性。字节是编码之后的存储长度，UTF-8 下一个汉字通常占多个字节，一个英文字母占一个字节，这是存储视角。

字符则是人写出来的个数，就是编辑器里字数统计给你的那个数。它既不管编码，也不管分词，只数你敲了多少个符号。三个单位之间没有固定倍数关系，谁也不能直接换算成谁。

token

分词器把文本切成的最小计费片段，同一段文字换模型可能得到不同数量

字节

文本按某种编码存下来占的长度，UTF-8 下汉字和字母差别很大

字符

肉眼看到的符号个数，和编码、分词都无关

分词器

决定一段文本被切成几个 token 的那套规则，不同模型通常不同

想把这几个概念一次看明白，可以到 /ai-dict/category/basics 翻一遍基础词条，比零散记结论稳。那里讲的是定义和边界，具体某个模型怎么切，还是要以实际调用为准。

不同内容类型，token 和字节差多少

不要背一个通用系数，因为系数随内容类型漂移得很厉害。下面这张表给的是方向性判断，不是精确数字，你要的是「哪一类更贵」的直觉，而不是一个能直接乘的倍数。

同样是「一屏文字」，纯中文叙述和一段带缩进的代码，token 数可能差出一大截。所以做成本估算时，第一步不是算总量，而是先把内容按类型分组。

一个容易被忽略的贵区

系统提示、工具描述、返回格式说明这类固定前缀，看着不多，但它们每轮请求都要重新计一遍。历史对话同理，你以为只是「带上上下文」，实际是每轮都重新付费。做预算的时候，这部分经常比你以为的正文还长。

自己动手估 token 的四步

下面这套流程不追求精确，目标是量级正确，足够你判断一次调用是贵还是便宜。真要精确数字，还是以站内核对为准。

1. 按类型分组把待发送内容拆成正文、代码块、附件转出的文本、固定前缀几堆，分开估。混在一起算最容易出错。
2. 小样本试算再放大挑一段有代表性的内容，用和目标模型口径接近的方式估一次，得到一个局部比例，再放大到全量。别一上来就拍总倍数。
3. 把隐藏输入算进去系统提示、历史消息、工具描述、返回格式要求全部计入输入。它们经常比正文还长，漏算这一步估算必偏。
4. 给输出留额度按你期望的返回长度预留输出量，别只算输入。输出通常按另一个单价走，量级也要单独估。

做完这四步，你手里应该有一个「这次大概什么量级」的结论。接下来就是和实际数字对账，看看偏差出在哪。

估不准时去哪儿核对当时的数字

估算永远只是估算，真实单价和计费单位要以站内页面为准，而且会变。别把任何数字记死在脑子里，用的时候去看当时的。

• 各家厂商的模型单价与计费单位，到 /official-api 按厂商逐个核对，注意区分输入和输出
• 想把单价直接换算成单次成本，用 /tools/token-price-calculator 或 /tools/model-cost-calculator 跑一遍
• 实际账单明细与用量记录到 /usage 对照，看偏差是来自缓存、口径还是估算本身
• 分词和计费相关的基础概念不熟，回到 /ai-dict/category/basics 补一遍定义

对上账之后你会发现，偏差通常集中在少数几类内容上。把这些类型记下来，下次估算就准多了。这比换一套更复杂的公式有用。

什么情况下这套估法不适用

这套估法只对「按 token 计费」的文本服务成立。碰到下面这些情况，估 token 本身就没有意义，硬套只会误导自己。

• 计费口径不是按 token，而是按次、按张、按秒、按字符数的服务，估 token 没有意义
• 开了缓存或批量通道时，实际单价的命中情况和常规调用不一样，估算只能给个量级
• 平台做了截断、重试、分片，实际消耗会高于你按原文长度算出来的数
• 内容里有大量附件或多模态输入，它们的计量方式跟文本不同，要单独看页面说明

判断方法很简单：先确认这个服务的计费单位是什么。不是 token，就别往下套；是 token 但走了缓存或批量，就把估算当参考值，别当承诺。

缓存和批量为什么会改变结果

缓存命中的部分和未命中的部分，计费口径往往不一样；批量通道的结算方式也可能和实时调用有区别。这些差异会体现在实际账单上，而不是你手算的原文长度里。想搞清楚差异有多大，只能拿 /usage 的实际记录去对。

三个最常见的手算错误

下面三个错误出现频率最高，几乎每个第一次认真算成本的人都踩过。对照检查一下自己有没有中招。

这四个里，最后一条最隐蔽。同一个词在不同模型下可能切法不同，你从别处抄来的比例，换到目标模型上不一定成立。所以任何系数都只当参考，先小样本验一遍。

给小团队的一条落地做法

假设一个五人小团队，业务里固定跑几类 prompt：客服问答、文本摘要、代码审查。与其纠结通用系数，不如攒自己的样本比例。

• 在调用处记录输入输出字符数与实际消耗 token，攒一批自己业务场景的样本
• 用自己样本算出的比例做预算，比通用系数准得多，因为内容分布是固定的
• 比例会随内容类型漂移，隔一段时间重新算一次，别一次算完用到底
• 把比例写进成本测算表，和 /usage 的实际数字定期对齐，偏差大了就查原因

这套做法的好处是，你不需要理解分词器内部原理，只需要知道自己业务里「一个字大概对应多少 token」。长期看，这比背任何通用倍数都可靠。想了解同类团队在成本控制上的通用做法，可以到 /guides 翻对应方向的文章。

还有一个习惯值得养成：每次调整 prompt 结构后，重新抽样对一次账。加了一段工具描述、换了一种返回格式，token 量都可能明显变化。不对账，预算就会慢慢失真。