结构化摘要

文章主旨：

Token 是大语言模型将文本转换为整数序列的关键翻译层；中文因分词粒度更细而消耗更多 Token，Token 边界同时影响模型成本、能力表现与多语言处理差异，理解 Token 是使用大模型的底层认知之一。

关键要点：

1. 大模型输入不是文字，而是词表条目对应的整数 Token；Token 设计需要在“序列尽量短”和“每个单元尽量有语义”之间取得平衡。
2. 主流分词方法 BPE 通过合并高频字符组合构建词表；英文因词根、词缀组合多而更容易形成较大粒度 Token，中文则有大量单字 Token，导致同样语义下中文 Token 消耗更高。
3. Token 大小没有固定答案，常用经验估算是英文约 4 个字符对应 1 个 Token，中文更接近 1 个汉字对应 1～2 个 Token；代码中的括号、冒号、空格等也会增加 Token 消耗。
4. Token 边界会影响模型在字符统计、精确数学计算、幻觉和多语言处理上的表现；上下文窗口的本质是 Token 数上限，而非字数或字节数。
5. Token 体系是工程约束与语言规律之间妥协的产物，并可能影响模型对不同语言的“偏好”，由此引出成本与公平性问题。

内容结构：

现象引入

作者从中文处理时 Token 消耗高于英文的现象切入，用“人工智能”和英文对应词的分词结果说明中文可能更“贵”。

模型根本不认识“字”

说明模型处理的是整数 Token 及其向量，而不是字符；Token 是文本世界与数学世界之间的翻译层，设计目标是兼顾短序列与语义密度。

Token 是怎么切出来的

介绍 BPE 的核心逻辑：反复合并高频字符组合形成新 Token；英文在词根、词缀层面更容易合并，中文因汉字数量庞大且语料分布差异，较多以单字 Token 存在。

一个 Token 到底有多大

指出 Token 大小取决于词表和文本内容，并给出英文、中文及代码片段的经验估算，说明代码符号也会作为独立 Token 候选增加消耗。

Token 的边界，就是模型认知的边界

以“strawberry 中有几个 r”和数字切分为例，说明 Token 切分影响字符级统计与数学计算；上下文窗口也是 Token 数上限，不同语言对应的实际字数存在系统性差异。

结尾讨论

作者认为 Token 是当前算力和词表规模限制下的可行方案，并提出未来若模型能按字节甚至比特处理输入，语言间成本不平等及模型语言偏好是否仍会存在。

文章总结：

文章以工程视角解释 Token 机制及其对成本和模型认知的结构性影响，提醒读者理解 Token 边界是更有效使用大模型的重要前提。

猿圈奇妙屋

查看原文：Token 是什么？为什么 LLM 不认识「字」只认识「Token」

文章来源：

猿圈奇妙屋

扫码关注公众号