分词器是你发给模型的那句话最先经过的部件，它不负责理解，只负责切分和编号。文字送进大模型之前，分词器会先把它切成一个个 token，再换成词表里的编号，模型读到的就是这串编号。想通这一点，不少困惑就有答案：token 既不是字，也不是词。
它切的不是字，而是出现概率
目前主流的分词器多采用 BPE 算法，全称是字节对合并。训练时，算法会统计哪些字符组合最常一起出现，出现越频繁，越容易被合并成一个完整的 token。于是常见词、常用子词往往能整块保留，一个英文单词可能就是 1 个 token；生僻词、人名、新造词则会被拆得更碎，一个词拆成三四块也很常见。
空格、标点、数字和代码同样参与切分，规则并不直观。英文里词前面的空格经常和单词绑在一起算作同一个 token，换行、连续数字、缩进代码都会被单独处理。所以同一段内容，改一下格式，token 数就可能变。
同一句话，换个模型为什么对不上
每个模型的词表都单独训练，大小不同、合并规则不同、侧重的语种也不同。词表越大，能整块保留的片段通常越多；对中文覆盖好的词表，一个汉字可能就是 1 个 token，覆盖差的则可能把一个汉字拆成多个字节级 token。
这就解释了标题里的问题。经验上，英文 1 个 token 大约对应 3 到 4 个字符；中文波动大得多，一个汉字占 1 个 token 很常见，占 2 个甚至更多也不奇怪，具体看哪个模型。拿 A 模型的计数估 B 模型的消耗，对不上是常态，不是哪个模型算错了。
token 数也直接决定实际成本。按量计费时，输入和输出大多按 token 结算；上下文窗口的上限、一次能塞进多少历史对话，数的也是 token；要生成的 token 越多，回复通常越慢。做知识库时更明显，RAG 到底是什么？它和微调、提示词工程的区别里提到的文档分块，按的同样是 token 而非字数，块切大了浪费窗口，切小了容易把语义切断。
三个常算错的账
第一种是拿字数直接估费用。字数和 token 数没有固定换算，英文、中文、代码混在一起时偏差更大，估出的预算很容易偏低。
第二种是认定中文一定更省或者一定更费。更准确的说法是：在多数主流模型的词表下，表达同样的意思，中文通常比英文消耗更多 token，因为英文常见词更容易整块命中，中文更容易被拆开。但这不是铁律，换一个对中文优化较好的词表，差距会明显缩小，结论要落到具体模型上。
第三种是把 token 数当成模型强弱的证据。同一句话在甲模型是 80 个 token、乙模型是 110 个，只能说明切分方式不同，和谁更聪明没有直接关系。词表设计本是取舍：词表大，切得粗，但表示成本更高；词表小，切得细，序列更长。
它做不到的事
分词器不是模型本身。它只决定文字以什么粒度被送进去，不负责理解语义，也不会判断一句话对不对。切分是否合理会影响模型发挥，糟糕的切分会让数字运算、生僻词理解更吃力，但理解和推理终究是模型参数的事。分清这两件事，才不会对分词器期待过高或埋怨错人。
日常使用中有个简单的自查办法：估费用和长度时不要心算字数，直接用当前模型对应的分词工具数一遍真实文本，把系统提示、历史对话和输出余量一起算进去，留出两成缓冲。养成按 token 做预算的习惯，账单和上下文溢出大多能提前避开。
