BPE 分词算法：大模型词表的设计逻辑（合并规则、词表大小与工程取舍）

先给工程结论：Tokenizer 是模型成本与质量的“第一道闸门”

同样一个模型、同样一个 prompt：

• A 分词器把它切成 800 token
• B 分词器切成 1200 token

你得到的不是“小差别”，而是：

• 成本上升
• 延迟上升
• 上下文窗口更快被占满

所以理解 BPE，不只是算法题，而是工程题。

一、BPE 在做什么：用“合并规则”构建子词词表

BPE 的核心是一个循环：

1. 从最细粒度单位开始（通常是字符、字节，或带边界的字符序列）
2. 统计训练语料中相邻符号对（pair）的频率
3. 找到最频繁的 pair，把它合并成一个新符号
4. 重复 2-3，直到达到目标词表大小或达到合并次数上限

你可以把它理解成：

• 让“常出现的片段”变成一个 token
• 让“少出现的片段”继续由更小单位拼出来

一个最小示例（直觉版）

假设语料里 l o w、l o w e r、n e w e s t 出现很多。

BPE 可能先合并：

• l + o → lo
• lo + w → low
• e + s → es

最终你会得到像 low、est 这样的子词，既能覆盖常见词，也能拼出罕见词。

二、训练与编码：两件事别混

面试或工程讨论里，常把“训练 BPE”与“用 BPE 编码”混在一起。

1）训练（learn merges）

训练输出的是：

• 初始符号集合（例如字节或字符）
• 一组有序的合并规则 merges

规则有序很重要：因为编码时必须按同样的优先级合并。

2）编码（apply merges）

编码就是：

• 把输入拆成初始符号序列
• 按 merges 的顺序，能合并就合并
• 直到不能再合并或达到规则终点

编码阶段不需要再统计频率，只需要应用规则，所以推理时很快。

三、词表大小的工程取舍：长度、内存、泛化

设词表大小为 $V$，embedding 维度为 $d$，仅 embedding 参数量就是：

$$V \cdot d$$

词表增大带来的影响：

1）序列更短（潜在）

常见片段更容易被合并成更长 token，同一文本 token 数减少。

2）模型参数更大（确定）

embedding/输出层更大，显存/内存更高。

3）稀有 token 学得更差（常见）

词表越大，长尾 token 出现次数更少，训练信号稀疏。

工程上你要做的不是追求“最大词表”，而是寻找一个“总体最优点”。

四、BPE 与 token 成本：为什么同一句话能差 30% 以上

1）切得碎 → token 多 → 成本高

如果你的分词器把专有名词切得很碎（例如产品名、公司名、代码标识符），token 数会暴涨。

在 AI 产品里，这会直接影响：

• 模型调用费用
• p95 延迟
• 上下文窗口可容纳信息量

2）切得太粗 → 覆盖不足或泛化变差

如果你为了一味减少 token 数而让词表包含大量长 token，会遇到：

• 新词覆盖不足
• 多语言混合时碎裂更严重
• 训练数据不足导致 token 表示不稳

所以正确的工程问题是：

在你的业务语料分布下，词表与合并规则如何让“常见模式更省 token、长尾模式仍可组合”？

五、中文与多语言的实践要点

1）中文本身不难，难在混合文本

真实输入通常混合：

• 中文
• 英文
• 数字
• 标点
• 代码/路径/URL

这类混合文本更适合字节级或具备良好 fallback 的策略。

2）专有名词与产品名：最容易把 token 成本拉爆

工程建议：

• 统计你业务里 top N 高频专有名词
• 观察它们的 tokenization 结果（切了几段）
• 作为 tokenizer/词表调整的重要依据

这类优化往往比“再换一个更大模型”更划算。

六、实现与调试：你需要哪些指标

如果你在做生产系统，建议建立 tokenizer 侧的指标：

• 平均 token 数、p95 token 数
• 专有名词切分长度分布
• 多语言输入的碎裂率（比如英文/数字被拆的比例）
• 与成本/延迟的相关性

当你发现成本飙升时，很多时候根因是：

• 输入变了（用户开始粘贴更多代码/日志）
• tokenization 变了（升级 tokenizer 或变体）

可观测能让你快速定位。

七、把 BPE 放回大模型工程：它影响上下文工程与 RAG

BPE 直接影响：

• 你能在上下文窗口里塞多少“可用信息”
• RAG 的 chunk 大小与重叠策略
• 摘要压缩的收益

想从系统视角看“上下文窗口不够怎么办”，可以读：

• 上下文窗口不够怎么办：RAG 与摘要链路对比

常见问题

BPE 和 Unigram/WordPiece 有什么差别？

面试里不需要背细节，但要能说清：BPE 是“从小到大合并”；一些其他方法更像“从候选子词集合里选最可能的分解”。工程上更重要的是：在你的语料分布下，哪种方法更稳定、更省 token、覆盖更好。

我能直接通过 prompt 压缩来降低 token 成本吗？

可以，但 tokenizer 决定了压缩的下限与效率。很多时候先优化分词与输入格式（例如把日志结构化）会更省钱，也更稳定。

想看更多工程化文章见 /articles，也可以在 /apps/new 体验 Agent 能力。