Tokenizer 分词原理与中文处理

摘要：Token 是模型与人类文本的接口，也是成本的计量单位。本文对比 BPE、WordPiece、Unigram、SentencePiece 四种主流算法的合并策略与词表设计，重点解释"为什么中文比英文费 token、为什么模型选型和定价都受它影响"，并给出用 tiktoken / transformers 实测压缩率的可复制方法。适用版本：原理通用，具体词表大小与压缩率标注 [版本相关]。

核心概念：Token 是什么

Token 是模型处理文本的最小离散单元——可以是整词、子词、单字或字节。连续文本经分词器拆成 token 序列，映射为 token id 后进入模型。它贯穿模型全生命周期：

训练：token 数决定语料规模与词汇表。
上下文窗口：以 token 计（如 128K token），决定"记忆容量"。
计费：API 按输入/输出 token 数计价。
生成速度：以 tokens/s 衡量。

三种主流粒度

字符级：单字/字母，覆盖全但语义割裂、序列过长。
词级：整词，语义完整但 OOV（未登录词）与词表爆炸。
子词级（Subword）：高频词保留整词，低频词拆成共享子词——主流 LLM 的选择，平衡语义与效率。

架构与原理：四种算法怎么合并

算法	合并策略	词表大小 `[版本相关]`	典型模型	中文特性
BPE（字节对编码）	频率驱动，迭代合并最高频字节/字符对	50K–200K	GPT-2/3/4、LLaMA、Qwen	字节级(BBPE)零 OOV
WordPiece	似然最大化，选提升训练数据似然的对	~30K（BERT）	BERT、Electra	先按字预分词再合并
Unigram LM	概率优化，从大候选表迭代删低概率子词	32K–262K	T5、Gemini、Qwen3	支持多路径最优拆分
SentencePiece	封装 BPE/Unigram，语言无关、可逆	同上述	LLaMA、T5、Gemini	用 `▁` 表示空格

关键差异举例

以"人工智能"为例（不同算法结果差异显著，数值为典型值 [版本相关]）：

BPE（GPT 系，BBPE）：常拆成 4 个 token（按 UTF-8 字节，1 汉字≈2–3 字节）。
WordPiece（BERT 系）：先按字、再合并高频对，可能 2 个 token。
Unigram（Qwen3 / Gemini 系）：可把高频术语作为整体，可能 1 个 token。

这正是中文在不同模型成本差异巨大的根源。

生产实践：中文为什么"贵"

根因

中文无空格，原始 BPE 需退到字节级，1 个汉字 = 3 字节，token 数倍增。
词表以英文/拉丁语优化，中文子词命中率低。经验上：中文 1 字 ≈ 1.5–2.5 token，英文 1 词 ≈ 1.3 token（GPT 系）[版本相关：随词表与算法变化]。
国内模型（如通义千问、文心）通过中文优化实现 1 汉字 ≈ 1 token，压缩率明显优于 GPT/LLaMA 系。Gemini 2.5（256K 词表）在中英混合上压缩率领先 [版本相关]。

选型时先测压缩率

同样的 1000 汉字：GPT-4 系约 1500–2500 token，中文优化模型约 1000 token。相同预算下，中文可承载信息量约为英文的 2–3 倍（反向看：海外模型处理中文更贵）。务必用目标模型的 tokenizer 实测你的真实语料，而非看宣传。

主流模型 tokenizer 对照 `[版本相关]`

模型家族	库/算法	词表大小	备注
GPT-4	tiktoken cl100k_base, BBPE	~100K	英文/代码强
GPT-4o / GPT-5	tiktoken o200k_base, BBPE	~200K	多语种（含西里尔）大增
LLaMA 3	tiktoken 兼容, BBPE	128,256	较 LLaMA2 的 32K 扩 4 倍
Gemini / Gemma 3	SentencePiece Unigram	262,144	词表最大，非英文好
BERT	WordPiece	30,522	`##` 前缀表续接
Qwen 2.5/3	tiktoken 系 BBPE	151,643	中文扩展 token
DeepSeek-V3	自定义 BBPE	128,000	多语种压缩优化

操作步骤：实测 token 数与压缩率

GPT 系（tiktoken）

bash

pip install tiktoken
python - <<'PY'
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")   # GPT-4 系
text = "人工智能是未来的方向"
ids = enc.encode(text)
print("token 数:", len(ids), "ids:", ids)
# 中文经验：len(ids) 通常 > 字符数
PY

Hugging Face 模型（transformers）

python

from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct")  # 中文优化
text = "人工智能是未来的方向"
ids = tok.encode(text)
print("token 数:", len(ids))
# 对比同文本在 LLaMA / GPT 上的 token 数，算压缩率

计费换算示例

假设某 API 输入价 $0.01/千 token，一段 500 字中文：

若产生 1000 token（中文优化模型）→ $0.01
若产生 1500 token（GPT 系，1 字≈1.5 token）→ $0.015

长文本（1 万字）差异会被放大数倍，这是中文场景选型的核心经济变量。

验证

bash

# 1. 确认分词器版本与模型匹配（不要混用）
# 2. 批量测业务语料平均 token/汉字 比值
# 3. 检查特殊符号、emoji、代码是否在你的 tokenizer 下异常膨胀
python - <<'PY'
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
for s in ["你好", "🚀", "def foo():", "人工智能"]:
    print(repr(s), "->", len(enc.encode(s)), "tokens")
PY

回滚与清理

分词器与权重强绑定

换模型时必须同步换 tokenizer。用错 tokenizer（如拿 LLaMA 的分词器去解 GPT 的 id）会得到乱码或越界错误。版本锁定：把 tokenizer 文件与模型权重一起纳入版本管理与镜像 digest。

故障排查

现象	可能原因	排查
中文 token 数异常多	用了非中文优化 BBPE	换中文友好模型或评估压缩率
越界/未知 token	tokenizer 与权重不匹配	确认二者同版本
emoji/代码膨胀	词表未覆盖	选代码/多语种优化词表（如 o200k）
微调后乱码	训练/推理 tokenizer 不一致	统一分词器配置

安全与合规

分词器相关风险

越权/越界：恶意构造超长或异常字符序列可能触达上下文上限或触发分词器边界 bug，造成拒绝服务或异常输出。应对：输入长度硬限、字符白名单。
数据泄露放大：中文在低效 tokenizer 下 token 数多，相同内容在按 token 计费的 API 上更贵，异常流量成本更高——需配额与告警。
提示注入：分词边界（如把"忽略指令"拆成特殊 token）理论上可干扰对齐，实际影响有限但应在应用层做内容隔离。

成本与性能

分词本身 CPU 开销小，但不合理的分词器会放大全部下游成本（窗口、KV cache、计费）。
词表大小的权衡：过大（如 256K）Embedding 层占参数多，小模型不划算；经验法则词表不超过模型参数 1/100 [未实测：经验值]。
推理框架（vLLM 等）通常把分词/反分词放到预处理/后处理，注意批量时的吞吐瓶颈。

Tokenizer 分词原理与中文处理 ​

核心概念：Token 是什么 ​

架构与原理：四种算法怎么合并 ​

关键差异举例 ​

生产实践：中文为什么"贵" ​

根因 ​

主流模型 tokenizer 对照 [版本相关] ​

操作步骤：实测 token 数与压缩率 ​

GPT 系（tiktoken） ​

Hugging Face 模型（transformers） ​

计费换算示例 ​

验证 ​

回滚与清理 ​

故障排查 ​

安全与合规 ​

成本与性能 ​

参考资料 ​