AI 模型读懂一段文字之前，第一步是把文字切碎——这套切碎方式决定了上下文窗口能塞多少字、多语种能不能稳、长尾词会不会被吃掉。从最早的字符级到今天的短语级，tokenizer 的演化走过四个清晰的台阶，每一步都换了一次「字典」的粒度。
字符级：暴力兜底的最后一层
字符级 tokenizer 把每个汉字、每个字母、每个标点都当成独立单元。听起来很笨，但它有一个最大优势——永远不会出现「未登录词」。任何生僻字、emoji、罕见符号都能切出来，模型至少能看见。
代价是序列长度爆炸。一句「今天天气不错」被切成 6 个 token，而 BPE 可能只切 2-3 个。长序列意味着上下文窗口消耗快、推理成本高。在 2018 年之前，几乎所有神经网络翻译模型都用字符级，因为字典足够小、训练够稳；2019 年之后随着 主流闭源模型-2 推出 BPE，字符级迅速让位。
但字符级并未消失——它以「字节回退」的形式藏在现代 tokenizer 里。当一段文字里出现字典外的字节序列，tokenizer 会回退到按字节切分，确保模型依然能处理任何输入。这是 tokenizer 演化里最值得记住的一条：字符级没有死亡，它退到了安全网的位置。
子词级：BPE 把 token 数砍到 1/3
子词级（BPE、WordPiece、Unigram）是 2018-2024 年的默认范式。它把高频词切成完整单词、把低频词切成更小的「子词片段」，让字典规模稳定在 3-5 万个 token 之间。这套设计的核心收益是「高频词 1 token 搞定、低频词按字节片组合」——平衡了表达效率和字典体积。
实测数据显示：同一段 1000 字中文文本，字符级 tokenizer 大约切出 3000-3500 个 token，BPE 子词级切出 1000-1300 个，节省比例稳定在 60-65%。这种节省直接转化为推理时的显存占用和计算成本的下降——同样一段上下文窗口，子词级能塞进接近 3 倍的原始文字。
但子词级有个老毛病：多语种不平衡。一个英语训练主导的 BPE 字典，遇到中文、日文、阿拉伯文往往切得很碎、字典里又没有完整词汇。一段日文可能切成 800 个 token，但换成 BPE 的中文版本同样长度只切 600 个。这种「字典偏向」长期是子词级最大的隐患。
词级：从未真正统治的中间形态
词级 tokenizer 把每个完整单词当成一个 token。直觉上最自然，但工程上完全失败——字典规模爆炸（英文常用词 10 万 + 专有名词 100 万 + 新造词无限增长），训练时高频词权重失衡、稀疏词永远训不到。
Word2Vec 时代（2013-2017）的早期神经网络翻译一度尝试词级，但很快就转向 BPE。在主流大模型的 tokenizer 演化史上，词级几乎是「一段被跳过的弯路」——它从来没真正统治过生产环境，但在教材和科普文章里依然被反复提起，因为它最容易解释。
短语级：下一程 tokenizer 的雏形
2024-2026 年间，最值得关注的变化是从子词级向短语级的迁移。短语级 tokenizer 不再按频率或字母组合切分，而是用一个小模型动态判断「这一段是否应该合并成一个 token」。典型代表是基于 BPE-dropout 的动态合并、基于困惑度（perplexity）的最优分段、以及基于稀疏字典的多粒度切分。
动态合并的核心思路是：训练时随机丢掉一些合并规则，推理时让模型自己决定哪几个 token 应该粘在一起。实测下来，这种方式在中英混合代码（中文注释 + 英文函数名）上 token 数可再降 15-20%——而中英混合代码恰恰是当代 AI 工程师每天面对的输入。
基于稀疏字典的方案更激进：把同一个 token 用「常用表示 + 罕见表示」两套字典分别切分，模型在推理时按上下文自动选最合适的那一套。这条路线在 2026 年的几个新模型里已经能看到雏形，token 节省比例稳定在 25-35% 之间。
三条岔路：动态合并、字节回退、稀疏字典
把这四级演化摆在时间轴上看，tokenizer 的下一程正在分裂成三条岔路：
第一条是动态合并路线。代表方案是 BPE-dropout 和它的改进版，把「该不该合并」这个决定权从静态字典交给模型。优点是上限高、理论上能逼近最优切分；缺点是推理时多了一层计算开销，且训练稳定性比静态 BPE 略差。
第二条是字节回退路线。代表方案是把字符级作为兜底层、子词级作为常用层、两者并存。优点是任何输入都能处理、字典永远不会 OOV（未登录词）；缺点是回退路径上的 token 没有语义、模型要重新学习。
第三条是稀疏字典路线。代表方案是 dual-encoder tokenizer 和它的变体，把字典拆成「主流字典 + 罕见字典」两份，推理时按上下文动态选择。优点是节省 token 比例最高；缺点是字典维护成本翻倍，且罕见字典需要持续更新。
对普通开发者意味着什么
理解 tokenizer 演化不是为了造一个新 tokenizer，而是为了看清一个隐藏的工程事实：同一个 API 调用，同样的输入文本，在不同模型的 tokenizer 下会被切成不同长度的序列。这意味着上下文窗口的实际容量、推理的实际成本、长文本任务的实际表现，都和 tokenizer 直接相关。
几个可操作的判断：如果你处理大量中英混合文本，优先选择字节回退或多字典的 tokenizer；如果你的场景是长文档摘要或代码补全，优先选择动态合并路线；如果你的输入是高频短句为主的客服对话，传统 BPE 已经够用，不必为新方案额外付费。
看 tokenizer 的方式，看的是 AI 模型「消化文字」的胃口有多大。下一次当你看见「上下文窗口 200K」这种数字时，别忘了真正决定能不能塞下 200K 字的，是 tokenizer 不是窗口本身。