摘要一句话进入大模型前会先被切成Token、编号并转换为向量。本文借“去图书馆学习”的例子讲清Token、Token ID、Embedding、BPE以及编码与解码的完整过程。上一篇把Tokenizer称为“人类语言与大模型之间的桥”。这一篇打开这座桥看看一句普通的话如何变成模型可以计算的数字又如何重新变回文字。假设我们输入“小林周末去图书馆学习。”模型直接看到的是这句中文吗严格说不是。应用会先把文字交给分词器Tokenizer转换成一串Token ID模型再把编号转成向量进行计算。这里最容易混淆的是Token、Token ID和Embedding是三个相连但不同的层次。一、Token不是字也不一定是词Token常被译为“词元”是某个Tokenizer选定的文本表示单位。它可能是一个词、一个汉字、词的一部分、标点、空格与文字的组合也可能是一个或多个字节。因此Token不等于固定的“字”或“词”。同一句话交给不同Tokenizer切分结果可能完全不同。可以把它想成快递公司的装箱方案面对“图书馆”有的装成一个箱子有的拆成“图书馆”还有的按底层字节装箱。文字没变包装单位却不同。Token数量也不能按固定比例换算成汉字数。中文、英文、代码、数字、生僻字和标点的编码效率各不相同。想知道一段文字的准确Token数最可靠的方法是使用目标模型对应的Tokenizer实测。二、Token、Token ID与EmbeddingToken ID是词表中某个Token的整数编号。Token好比仓库里的一种货物Token ID就是它的货架号。编号5000并不比编号100“语义更强”换一套词表同一个编号还可能代表完全不同的内容。模型真正计算时还要用Token ID在嵌入层中查到一组数值这就是嵌入向量Embedding。它可以理解为Token在一个多维坐标系统中的表示其数值会在模型训练中不断调整。所以三者的关系是Token是文本单位Token ID是离散索引Embedding是供神经网络计算的连续数值向量。模型不会把ID的整数大小当作含义。三、文字是怎样被编码的Tokenizer不只是“一把切词的剪刀”而是一条处理流水线。一次编码通常包括接收原始文字按规则处理字符、空格和标点使用BPE、WordPiece或Unigram等方法选择Token从词表取得对应的Token ID按模型要求添加开始、结束等特殊Token把ID序列交给嵌入层和模型。为了观察真实结果我使用OpenAI开源项目tiktoken 0.11.0的o200k_base编码对“小林周末去图书馆学习。”进行测试。2026年8月12日的结果是10个Token小林周末去图书馆学习。 5820, 22594, 17442, 56534, 13817, 5803, 20121, 63667, 64550, 788这只是该编码的实测结果不能代表所有模型。换用其他Tokenizer切法和ID都可能变化。四、BPE怎样“长出”词表Tokenizer并非由人手工录入所有词语。开发者会决定训练材料、词表大小、特殊Token和算法再由程序从语料中寻找合适的表示单位。字节对编码Byte Pair EncodingBPE的核心直觉很简单如果两个较小单位经常相邻出现就把它们合成一个更大的单位。假设有一组教学语料小林去图书馆 小雨去图书馆 周末去图书馆学习 图书馆今天开放 我喜欢在图书馆看书暂时从单个汉字开始统计“图书”和“书馆”都高频出现。若第一轮先合并“图书”便得到新Token“图书”重新统计后再把“图书馆”合并为“图书馆”。新Token进入词表合并顺序也会保存供编码时使用。这不代表算法理解了“图书馆”的含义它只是发现这些单位经常一起出现。真实Tokenizer的语料和规则要复杂得多有些字节级BPE甚至从UTF-8字节开始而不是从汉字开始。BPE也不是唯一方案WordPiece、Unigram等算法采用不同的选择方法。五、解码不只是查一次表模型不会一下子吐出整段答案而是连续生成许多Token ID。Tokenizer要取得每个ID对应的文本片段或字节处理特殊Token再把它们拼接成人类可读的文字。对于字节级Tokenizer单个Token可能只是某个字符的一部分要和后续字节合并后才能正确显示。因此解码虽然不必重新寻找切分方式却也不只是“反查一次编号”。完整链路可以概括为人类文字 ↓ Tokenizer切分并映射 Token → Token ID ↓ 嵌入层查表 Embedding向量 ↓ 大模型结合上下文预测 新的Token ID不断循环 ↓ Tokenizer拼接并解码 人类可读的回答六、为什么Token像压缩又不等于ZIP把Tokenizer称作“文字压缩术”很形象常见片段可以用较少Token表示相当于把经常一起运输的物品装进标准货箱模型要处理的序列因此变短。但它不等于ZIP文件压缩。Token数量减少不代表文件字节数同比缩小更大的词表还会增加嵌入矩阵等模型参数。Tokenizer设计是在序列长度、词表大小、语言覆盖和模型效果之间寻找平衡。Token之所以和普通用户有关主要有三点上下文窗口通常按Token计量提示词、对话、工具说明和输出都会占用容量许多API按输入和输出Token计费在其他条件相近时序列越长往往需要更多计算和等待时间。对于Agent这一点更加重要。系统规则、Prompt、Skill指令、检索资料和工具结果最终都要编码成Token放入Context。Token管理会直接影响Agent能携带多少规则、读取多少材料、保留多少历史以及还能为最终回答留下多少空间。七、几个最容易产生的误解第一Token不是模型“理解出来的词义”。“图书馆”即使被合成一个Token也只能说明它在训练材料和合并规则中适合作为一个整体不代表Tokenizer知道图书馆是什么。第二Token越少不一定代表模型效果越好。如果把大量长句都收进词表序列虽然变短词表和模型参数却会迅速膨胀对新词的组合能力也可能下降。Tokenizer追求的是合理平衡而不是无限合并。第三Context Window能容纳多少内容不能只用“几本书”衡量。同样长度的中文、英文、代码或网址Token数可能相差很大系统提示和工具说明也会占据窗口。真正处理长材料时应以对应Tokenizer的统计结果为准。最后减少Token只是优化Agent的一部分。如果删掉关键规则或必要证据即使成本降低答案也可能变差。好的上下文管理不是简单地“越短越好”而是用有限空间保留最有价值的信息。核心概念速查Token特定Tokenizer采用的文本表示单位。Token IDToken在固定词表中的整数索引。Tokenizer把文本编码成Token ID并将输出ID解码成文字的组件。BPE反复合并高频相邻单位、逐步形成子词词表的方法。Embedding由Token ID查得、用于模型计算的连续数值向量。Context Window模型一次推理能够处理的上下文容量通常按Token计算。参考资料Philip GageA New Algorithm for Data Compression1994。Sennrich、Haddow、BirchNeural Machine Translation of Rare Words with Subword Units2016。Hugging FaceThe tokenization pipeline。OpenAItiktoken。OpenAIWhat are tokens and how to count them?。