大模型中的token跟字节区别在哪

很多人第一次看 API 账单会犯迷糊：明明文件才几十 KB，怎么扣了这么多 token？也有人按字节数去估上下文够不够，结果请求直接被截断。这篇不讲抽象定义，只讲 token 和字节在计费、上下文、中文英文差异上到底怎么换算，以及在什么情况下你的估算会失准。

很多人第一次看 API 账单会犯迷糊：上传的文件才几十 KB，怎么扣的 token 数量看着完全对不上？还有人拿文件字节数去估上下文够不够，结果请求发出去直接被截断。问题就出在，你把两个不同维度的单位当成一回事了。这篇不绕抽象定义，只讲 token 和字节在计费、上下文、中英差异上到底怎么换算，以及什么时候你的估算会失准。

先把结论放前面：字节是存储概念，token 是模型切分文本的概念，中间隔着一层分词规则。你付钱买的是 token，不是字节；模型卡你的上下文上限，也是按 token 卡，不是按文件大小卡。搞清这层关系，账单和截断这两件事就都能解释了。

为什么大家总把 token 和字节搞混

混淆的根源在于，这两个单位平时都被人拿来描述「这段文本有多大」。文件管理器给你看的是字节，代码编辑器给你看的是字符数，但接口账单给你看的是 token。三个数放在一起，自然容易串。尤其是复制一段文件去调接口，扣费和文件大小对不上号，第一反应就是「是不是算错了」。

• 字节是存储单位，描述这段文本占多少硬盘或内存，跟模型怎么理解它无关；token 是模型切分文本的最小单位，描述模型把这段文字拆成了几块来处理，两者维度不同
• 计费按 token 走，文件大小按字节走，中间差的就是分词规则这一层，跳过这层直接比数字必然对不上
• 同一段文字换模型、换分词器，token 数会变，字节数基本不变，所以拿 A 模型的 token 数去估 B 模型的账单会翻车
• 反过来，字节数稳定意味着它适合做存储规划，不适合做调用成本规划

token 到底是什么：不是字，也不是词

很多人以为一个 token 就是一个字，或者一个单词，都不准确。分词器切出来的片段可能是一个完整汉字、半个英文单词、一个标点符号，甚至一段代码缩进。它切分的依据是训练时统计出来的高频组合，不是语言学上的字或词。所以别拿「这段有 500 个字」直接当 500 token 用。

中文常见切法

一个汉字经常单独成一个 token，双字高频词也可能合成一个，具体看分词器

英文常见切法

按词根、前缀和空格切，一个长单词可能被劈成好几个 token

标点和结构

换行、缩进、markdown 符号、JSON 括号都会各自占 token，且很容易被忽略

特殊字符

emoji、生僻字、混合编码字符往往占多个 token，不是按一个算

实操上最容易被漏掉的是结构部分。你写一段带标题、列表、代码块的 prompt，正文可能没多少，但那些井号、短横线、反引号、空行全都在消耗 token。做成本预估时只数正文文字，结果一定偏低。一个简单的自查办法：把 prompt 原样粘到支持显示 token 数的工具里看一遍，跟自己数的字数对比，差多少心里就有数了。

字节和 token 之间有没有固定换算

没有统一的固定换算，这一点必须先说死。网上流传的一些比例，比如「一个汉字多少字节对应多少 token」，只是某个分词器在某种文本上的经验值，换模型、换语言、换内容类型就不成立了。把它当公式套，误差会积到账单上。

• 中文常见一个汉字占固定字节数，但占几个 token 取决于分词器，不同模型切法不同，没有通用值
• 英文一个单词的字母数、字节数和 token 数同样不成比例，短词可能一个 token，长词可能三四个
• 代码、JSON、日志这类结构化文本，token 密度跟自然语言差别很大，不能混用同一套经验
• 最靠谱的做法是用目标模型自己的分词器实测，别信跨模型通用的换算表

如果你非要做跨语言对比，可以这样想：同样一句意思，中文和英文的 token 数往往不一样，哪种更省取决于分词器对哪种语言训练得更充分，没有绝对结论。想验证，就分别把中英版本丢进分词工具跑一遍，拿实测数说话，而不是拿字节数反推。

这个差别怎么影响你的账单

账单是按照输入 token 和输出 token 分开算的，而且输出通常比输入贵。这意味着一段很长的提问，成本可能远低于一段很长的回答。很多人只盯着自己写了多少字，却忘了模型生成的内容也在计费，而且是更贵的那部分。控制输出长度，往往比压缩输入更见效。

还有一点常被忽视：缓存机制、批处理、流式输出这些能力，会改变实际计费口径。比如有的场景下重复的前缀可以被缓存，重复调用同一段系统提示就不用反复全价付费；但这些机制各有触发条件，不是默认生效。具体单价和规则随时会变，务必到 /official-api 和 /price-watch 核对当时的数字，别照搬别人几个月前的截图。

上下文长度是按 token 算的，不是按字节

模型限制的是 token 上限，跟文件字节数没关系。你上传一个体积很小的文件，但如果里面是密集的特殊字符或者大段代码，token 数可能远超预期，直接把上下文撑满，请求被截断或者被拒。反过来，一份体积不小的纯中文长文，token 数也不会小，别以为文件小就安全。

长文档、代码库、聊天历史三样东西一起塞进去的时候，消耗速度会比你想的快得多。尤其是多轮对话，每一轮历史都要重新带上，token 是累加的，不是只算最新一句。很多人是在某个看起来还很宽裕的时刻突然被截断，就是因为漏算了历史的累积。

• 判断够不够，只看 token 余量，不看文件大小
• 多轮对话要把历史全部算进去，不能只算当前提问
• 长文档配合检索或分段，别一次性全丢进去
• 给上限留出余量，别把预算卡死在临界值附近

一套可执行的估算流程

下面是按顺序做的估算流程，目的是在写代码之前就大致知道成本量级，而不是等账单来了再惊讶。

1. 拆文本把要发的内容分成纯自然语言、代码或结构化数据、标点与格式结构三部分，分别对待，因为它们的 token 密度差别大
2. 实测 token用目标模型对应的分词工具，把三段内容分别跑一遍拿到真实 token 数，别用字数乘系数这种拍脑袋法
3. 换成钱到站内成本计算器把 token 数换算成金额，再乘以预计的调用次数和平均输出长度，得出月度量级
4. 上线后回填上线后看真实用量数据，用实测值去修正之前的估算系数，下次预估就越来越准
5. 设预警给用量设一个阈值提醒，超过就回头检查是不是 prompt 膨胀或者历史没清理

这套流程的价值不在于一次算准，而在于形成一个能自我修正的闭环。第一次估偏很正常，关键是上线后有没有拿真实数据回头校准。懒得校准的人，每次上新功能都要重新拍一次脑袋。

哪些情况下这套估算不适用

上面讲的都是纯文本场景的规则，下面这些情况不要硬套，否则估出来的数会离谱。

• 多模态输入，比如图片、音频、视频，计费口径和纯文本 token 规则不同，要单独看对应说明
• 带函数调用、工具返回的结构化内容，token 组成跟纯聊天不一样，工具返回的字段也在消耗额度
• 不同厂商对同一段文本的切分方式不同，跨平台对比成本要分别重算，不能拿一家的 token 数套另一家
• 系统提示、模板、格式化指令这些固定开销，在轻量请求里占比可能很高，容易被整体忽略

下单前的自查清单

正式接入或者扩量之前，把这几个问题对着文档过一遍，能省掉后面不少返工。具体数值和规则一律到站内页面核对当时的版本。

如果涉及多家供应商，建议再做一次横向对比：同一段典型 prompt 分别喂给各家的分词工具，拿真实 token 数去比，而不是拿字节数或者字数比。这样得出的成本排序才是可信的。想快速摸清各家的计价差异和当前口径，可以直接到 /rankings 和 /price-watch 对照着看，那里会按当时的规则更新。