Token 不是一种通用的语言单位，而是模型特定的方式：将文本转换为模型可以处理的编号条目序列。
Token 是代码簿中的一个条目
可以把 tokenizer 想象成一份由负责准备文本的软件和处理文本的 LLM 共同使用的代码簿。代码簿包含获准使用的文本或字节序列，并为每个序列分配一个整数 ID。
假设一个示例 tokenizer 将以下文本拆分为：
The cat sat.
以下部分：
The | cat | sat | .
这些可见部分可能映射到如下 ID：
[814, 3290, 7112, 13]
这里的数字是为说明机制而虚构的。实际的 ID 和边界取决于 tokenizer。开头的空格可能会与后面的单词合并，因此 cat 和 cat 可能是不同的条目。
在日常解释中，token 既可以指可见的文本片段，也可以指其 ID。这个区别很重要：模型接收的是 ID，而不是可读文本组成的小字符串。每个 ID 都会选出一个初始的、经过学习的数值表示，供模型处理。
为什么模型使用小于单词的片段
如果使用完整单词作为词汇表单位，就必须为模型可能遇到的每个名称、拼写、词形变化、术语和新造词建立条目。任何未收录的单词都会变成未知词。
仅使用字符组成的词汇表可以避免未知词，但会将普通文本转换成更长的序列，从而增加模型需要处理的步骤数。
子词分词是一种折中方案。常见序列可以拥有自己的条目，而罕见单词则可以由更小的条目组合而成。一个常见单词可能只有一个 token；一个罕见的名字可能会变成多个片段。标点符号和空格也可以是 token，或成为 token 的一部分。
这些片段的选择依据是覆盖范围和序列紧凑性，而不是因为每个片段都具有独立的词典含义。如果某个片段存在于 tokenizer 的词汇表中，那么像 ment、带前导空格的单词或一段字节，都可以是有效的 token。
Tokenization 如何工作
具体步骤会有所不同，但文本模型中的处理路径通常具有相同的大致形态：
text
↓
model-specific tokenizer
↓
token pieces
↓
integer token IDs
↓
language model
↓
next token ID
↓
tokenizer decoder
↓
generated text首先，tokenizer 将固定规则应用于输入。根据其设计，它可能会规范化文本、进行初步拆分，然后使用 BPE、Unigram 或 WordPiece 等算法进一步分段。
接下来，它会在词汇表中查找每个生成的片段，并输出对应的 ID。它还可以添加用于标记边界或请求结构等目的的特殊 ID。这些特殊 token 不一定会出现在可见文本中。
模型处理输入 ID。生成文本时，它会为可能的下一个 token ID 分配概率，并根据解码设置选择一个 ID。这个新 ID 会加入序列，过程不断重复。最后，解码器将生成的 ID 转换回字节或文本。
对于完整且有效的序列，tokenization 通常是可逆的：解码这些 ID 可以还原原始文本。单个 token 并不总能独立解码成可读字符，尤其是在使用字节级 tokenizer 时。可能需要先将相邻 token 合并。
同一个单词可能有不同的 token 数量
不存在精确的单词到 token 的转换关系。
在一个 OpenAI tokenizer 示例中，antidisestablishmentarianism 在一种编码中被拆分为五个 token：
ant | idis | establishment | arian | ism
另一种编码则将其拆分为六个：
ant | idis | establish | ment | arian | ism
这两种拆分都没有改变拼写，也不能证明某个模型对这个单词的理解更好。不同编码只是拥有不同的词汇表和分段规则。
Token 数量还会因语言、空格、标点、代码、表情符号和特殊字符序列而变化。即使只是进行小幅编辑，也可能改变周围的边界。粗略平均值可以帮助进行初步估算，但可靠的数量只能来自你将使用的模型及完整请求所对应的 tokenizer 或计数接口。
为什么 token 很重要
它们决定能够容纳多少内容。模型的 上下文窗口以 token 而不是单词计量。根据提供商的规则，输入、先前消息、生成的输出，有时还有其他请求内容，会共同占用这一容量。
它们衡量使用量。许多 AI API 会分别报告并按 输入 token和输出 token计费。费率和类别各不相同，因此 token 数量本身并不等于价格。
它们会影响生成时间。文本生成会逐个 token 地进行。输出 token 越多，通常需要的生成步骤就越多，但总延迟还取决于模型、硬件、负载和输入处理。
它们会影响文本效率。两段人类可读长度相近的字符串，可能消耗不同数量的 token。当应用处理多种语言、源代码、结构化数据或特殊标识符时，这一点很重要。
它们将 tokenizer 与模型连接起来。模型会基于 ID 到词汇表条目的特定映射进行学习。替换成无关的 tokenizer 并不是外观上的变化：同一个 ID 可能会指向不同的片段，因此模型会接收到错误的学习表示。
常见误解
一个 token 就是一个单词
有时，一个简短且常见的单词就是一个 token。但 token 也可能是单词片段、标点符号、包含空格的片段、字符或字节序列。任何“每个单词对应多少 token”的数字，都只能视为针对某类文本的估计。
Token 边界体现了模型对概念含义的理解
Token 边界来自 tokenizer 的词汇表和分段规则，并不是模型概念的地图。一个单词被拆成四个 token，并不意味着对应四个想法；一个短语被存储为一个 token，也不意味着它会被理解成一个不可分割的想法。
所有模型对同一文本的计数都相同
不同的词汇表会产生不同的边界和数量。即使是同一提供商的模型，也可能使用不同的编码。应使用特定模型的接口进行计数，而不是沿用另一个模型的计数结果。
只有你输入的文本会被计数
API 请求可能包含系统指令、对话历史、工具定义、文件或图像表示，以及服务添加的格式内容。其中有些内容虽然不会显示在最终聊天界面中，却可能会贡献 token。当精确计数很重要时，应使用提供商的使用量报告或完整请求计数工具。
Token 越多，含义就越多
Token 数量衡量的是模型表示的长度，而不是信息的数量或质量。重复文本可能使用许多 token；简洁的公式则可能只使用少量 token，却承载大量含义。
AI token 就是加密货币 token
它们只是名称相同，机制并不相同。文本 token 是模型的词汇表单位；加密货币 token 则是区块链上的数字资产或记录。
Token 如何融入更广泛的系统
Tokenizer 的词汇表通常在语言模型训练之前就已确定。训练文本会通过该 tokenizer 转换为 ID，模型则学习这些 ID 上的模式。在推理时，同一映射会将新提示转换为输入 ID，并将生成的 ID 转回文本。
这使 tokenizer 成为模型的一部分，即使它以独立文件或库的形式提供。模型、词汇表、tokenizer 规则和特殊 token 定义必须彼此一致。
“token”一词也可以更广泛地用于多模态系统。提供商可能会将图像块、音频时间段或视频帧转换成若干单位，并将其报告为 token。这些单位在模型处理和计费中发挥类似作用，但并不是文本 tokenizer 生成的片段。
下一步阅读什么
阅读什么是上下文窗口？，了解 token 如何设定模型的工作上限。若要了解 API 使用量类别，请继续阅读输入 Token、输出 Token 与推理 Token 的区别。