Token 是什么？你可能早就见过它了

如果你用过 ChatGPT、文心一言或者任何大模型产品，一定见过界面底部的数字跳动——"已消耗 xxx tokens"。这个 token 到底是什么？为什么大模型不直接用汉字或者英文单词，而要搞出一个 token 的概念？

简单说，token 是模型理解和生成文本的最小基本单位。它不是字，也不是完整的词，而是一个介于两者之间的切分片段。比如「人工智能」这四个字，可能被切成两个 token：「人工」和「智能」；也可能被切成三个：「人」、「工」、「智能」——具体取决于分词器的规则。

为什么不能直接用「字符」或「单词」？

这个问题特别值得聊一聊。很多初学者会想：为什么不直接把每个汉字当作一个 token？这样不是更简单吗？

原因有两个层面：

• 效率问题：中文有几千个常用汉字，如果每个字独立编码，一篇 1000 字的文章就需要处理 1000 个 token，对模型来说计算量不小。而如果合理分词，同样的内容可能只需要 500-700 个 token，长度压缩了近一半。
• 表达力问题：单个汉字承载的信息太少了。「玻璃」是一个完整的意义单元，但如果拆成「玻」和「璃」两个 token，模型需要额外学习这两个字组合在一起的意思，增加了学习负担。反过来，如果直接用整个「玻璃」作为一个 token，模型学起来就直观得多。

主流的 tokenization 方法：BPE

目前绝大多数大模型（包括 GPT 系列、LLaMA、Qwen 等）用的都是 BPE（Byte Pair Encoding）算法。这个名字听起来高大上，但原理其实非常朴素。

BPE 的核心思想是：从最小的单位开始，逐步合并最常见的相邻字符对。

举个例子具体说明：

1. 先把所有文本拆成单个字符。假设训练数据里有 "low", "lower", "lowest" 这些词，初始状态就是 l, o, w, e, r, s, t 这些独立字符。
2. 统计所有相邻字符对的出现频率。「lo」出现了 3 次（low × 3），频率最高。
3. 把「lo」合并成一个新的 token。现在词表里有了「lo」。
4. 继续统计。现在「low」出现了 3 次，合并成「low」。
5. 重复这个过程，直到词表达到我们想要的大小（通常是 3 万到 10 万之间）。

等训练完成后，分词器就有了一个「从高频到低频」的 token 层级结构。碰到新文本时，它先看能不能用最长的 token 匹配，匹配不到就逐步降级到更短的 token，最后如果还匹配不上，就用单字符甚至 byte 级别来兜底。

中文分词的特殊性

我刚开始接触 tokenization 时，以为英文的分词方式可以直接套用中文。后来发现完全不是这么回事。

• 英文天然有空格分隔：词边界是明确的。BPE 在英文上表现得很好，因为大多数时候一个 token 就是一个自然单词。
• 中文没有空格：「今天天气真好」——这句话的边界在哪？是「今天 / 天气 / 真好」，还是「今 / 天天 / 气真 / 好」？这完全取决于分词器的训练数据。

这就带来一个很实际的影响：中文的 token 效率通常不如英文。英文里一个单词通常对应 1-1.5 个 token，而中文一个汉字可能是一个 token，也可能拼成两个汉字一个 token，整体来说同样的信息量，中文需要的 token 数大约是英文的 1.5-2 倍。这也是为什么你用中文问模型问题时，token 消耗总感觉比英文多——这不是错觉。

不同模型的分词器各有千秋

我对比过几个主流模型的分词器，发现差异还挺大的：

• GPT-4 的 tokenizer（cl100k_base）：词表大小约 10 万，对英文非常高效，中文处理能力也还不错
• LLaMA 系列（sentencepiece）：使用 BPE 的变体，词表约 3.2 万，早期版本对中文的支持偏弱，后来有所改进
• Qwen 系列：阿里通义自研的分词器，针对中文做了大量优化，中文 token 效率比 GPT-4 还要高一些
• DeepSeek：词表约 12.8 万，非常庞大，包含大量中英文常用词组，中文长文本的压缩率很好

一个意想不到的坑：token 长度影响推理速度

这个点是我在实际项目中踩过的坑。同样一段文字，如果分词器拆得细，token 数量就多，模型推理时需要的计算量就大，响应时间也会变长。更重要的是，提示词中的每个 token 都会参与注意力计算，过多的 token 会稀释模型对关键信息的注意力。

所以优化提示词时，除了关注语义清晰度，也要关注 token 利用率。比如「请用以下所给信息回答问题，不要添加额外内容」这种模版式套话，如果能合并成更简洁的表达，就能省下几十个 token 留给真正重要的信息。

为什么开发者需要了解 Tokenization？

坦白说，大多数时候你不需要关心 token 是怎么切的。模型会帮你处理好一切。但了解它的原理至少有三个实际好处：

1. 预算控制：很多 API 按 token 计费。知道中文长文本的 token 消耗大约是字数×1.5-2 倍，估算成本时会更有数。
2. 提示词设计：尽量把关键信息放在提示词的前半部分——有些模型对中间位置的 token 注意力偏低。
3. 调试诡异行为：有时候模型看起来「看不懂」某个词，可能是因为分词器把它切碎成了不合理的 token 碎片，导致模型无法正确理解。如果你知道一些在线 tokenizer 工具可以查看具体分词结果，排查起来会轻松很多。

总结

Tokenization 是大模型的第一道工序，也是最容易被忽视的环节。它决定了模型「看到」的文本是什么样的，直接影响模型的训练效率、推理速度和理解能力。下次看到界面上跳动的 token 数字时，希望你能想起——这不仅仅是一个计费单位，更是大模型理解人类语言的最基础单元。

你还遇到过什么跟 token 相关的有趣问题？欢迎在评论区留言讨论。