Tokenizer 原理：为什么中文比英文消耗更多 token
同样是”100 个字”的文章，中文版本在调用大模型 API 时往往比英文版本贵——根本原因在于 Tokenizer 对中英文的处理效率截然不同。理解这个差异，能帮你在设计 prompt 和选型时做出更明智的决策。
Tokenizer 是怎么工作的
Tokenizer 是大模型的”门卫”，负责在文本进入模型之前将其转换为 token 序列（整数 ID 列表）。主流算法有三种：
| 算法 | 代表模型 | 核心逻辑 |
|---|---|---|
| BPE（Byte Pair Encoding） | GPT 系列、Llama | 从字节出发，反复合并高频相邻对 |
| WordPiece | BERT、早期 Google 模型 | 基于子词，优化语言模型概率 |
| SentencePiece | Qwen、Gemma、T5 等 | 语言无关，直接从原始 Unicode 构建词表 |
绝大多数当前主流的推理 API 使用 BPE 或 SentencePiece 的变体。
以 BPE 为例，训练过程其实很朴素，拆开看就三步：先把语料切成最小单元（字节或字符），然后统计所有相邻两个单元一起出现的频率，把出现次数最多的一对合并成一个新单元，重复这个过程几万次，直到词表达到目标大小（比如 cl100k_base 的词表约 10 万条）。举个简化的例子，如果语料里 t 和 h 经常挨在一起，会先合并成 th；th 和 e 又经常挨在一起，就再合并成 the；合并次数足够多之后，language、model 这类高频英文单词就被整体收进了词表，一次编码就是 1 个 token。这个机制天生偏向语料里出现次数多的模式——而主流大模型的预训练语料里英文文本占绝对多数（GPT 系列、Claude 的语料构成里英文通常占到 90% 以上），所以合并规则大部分是围着英文单词、英文词根打磨出来的，中文只是”顺带覆盖”，合并深度天然就浅一截。这也是为什么同一批模型，换成中文优化度更高的 Qwen、DeepSeek 之类，中文 token 效率会明显更好——它们训练语料里中文占比更高，BPE 合并规则对中文常见词组（比如”人工智能”“大模型”这种高频词）做了更深的合并，词表里直接收录了大量完整中文词语而不是拆成单字。
为什么中文 token 效率更低
英文天然有空格分词，常见单词早已被 BPE 合并为单个 token：
"language"→ 1 token"model"→ 1 token"tokenizer"→ 1–2 token
中文没有空格，汉字组合方式极多，词表难以穷举所有词语，结果是许多汉字以单字或两字为一个 token 出现，而不是以完整词语为单位：
"大模型"→ 可能切成大/模型（2 token）或大/模/型（3 token）"接入层"→ 可能是接入/层（2 token）
直接结果： 同等信息量的中文文本，token 数量约为英文的 1.5–2 倍。
这里有个很多人踩过的坑：按”字数”估算 token 预算，中文场景下几乎必然低估。 我见过一个真实的教训——团队按”1 个汉字约等于 1 个 token”来估算客服机器人的月度调用成本，上线一周后账单直接超出预算 40%多。回头排查才发现，实际的中文 token 数是汉字数的 1.3–1.5 倍，而且模型输出（回答）通常比用户输入更长、也更贵（大部分厂商输出 token 单价是输入的 2–4 倍），估算时如果只按输入侧汉字数打个折就下结论，回答部分的开销很容易被漏算。正确的做法是：任何成本预算，先拿一批真实业务样本跑一遍，看 API 返回的 usage 字段里 prompt_tokens 和 completion_tokens 的实际值，再按真实比例外推，不要凭”字数感觉”拍脑袋。
不同模型的中文 token 效率对比
声明：截至 2026-06，以官方为准。
| 模型系列 | 中文优化 | 中文汉字/token 近似比 |
|---|---|---|
| GPT-4o（cl100k_base） | 一般 | 约 1.3–1.5 字/token |
| Claude（Anthropic） | 一般 | 约 1.3–1.5 字/token |
| Qwen（通义千问） | 较好 | 约 1–1.2 字/token |
| DeepSeek | 较好 | 约 1–1.2 字/token |
| 百度 ERNIE | 较好 | 约 1–1.1 字/token |
结论： 如果你的业务以中文为主，使用国内厂商的中文优化模型，在 token 消耗上可能比使用 GPT 系列节省 20%–40%。
但省 token 不等于最优选择，这里得分场景权衡：
| 你的场景 | 建议 | 原因 |
|---|---|---|
| 纯中文客服、文案、知识库问答 | 优先中文优化模型（Qwen、DeepSeek 等） | token 效率高，同等预算能多跑不少轮对话 |
| 需要跨语言（中英混排文档、多语言客服） | 综合评估，别只看中文 token 效率 | 中文优化模型的英文/小语种能力不一定是强项，token 省了但效果打折更亏 |
| 需要调用特定生态（函数调用、Agent 框架、既有工具链绑定某家 API） | 先看生态兼容性，token 成本放第二位 | 换模型的迁移成本（重新调 prompt、重新测效果）可能比省下的 token 费用还高 |
| 长文本摘要、代码生成为主 | 实测优先，别直接套中文结论 | 代码里英文关键字、变量名占大头，中英文效率差异对这类场景影响没那么明显 |
简单说：token 效率是选型时要看的一个变量，不是唯一变量。先明确业务对模型能力的硬要求，在满足要求的候选里再比 token 成本，顺序不能反。
Tokenizer 差异对成本的实际影响
以一个 500 字的中文客服问答为例：
| 场景 | 汉字数 | GPT 系列（约 1.4x） | 中文优化模型（约 1.1x） |
|---|---|---|---|
| 用户输入（100字） | 100 | ≈ 140 token | ≈ 110 token |
| 模型回答（400字） | 400 | ≈ 560 token | ≈ 440 token |
| 合计 | 500 | ≈ 700 token | ≈ 550 token |
差距约 21%——如果日均调用量大，这是不可忽视的成本差异。
实测自己业务场景的 token 消耗，建议用 token 计算器 对比不同模型的实际结果。
特殊情况：代码和混合内容
- 代码中的中文注释：中文注释按中文规则计算，比英文注释贵
- 中英文混合 prompt：英文部分按英文规则，中文部分按中文规则，分别估算再加总
- Markdown 标记：
#、**、-等符号各占约 1 token，长篇 Markdown 文档的标记符号开销不可忽视
自己动手核实 token 数，别只靠估算
前面说的比例（1.3–1.5 字/token、1–1.2 字/token）都是近似值，真要控成本，最靠谱的做法是拿自己的真实文本去跑一遍编码，看精确结果。如果你用的是兼容 OpenAI 接口的模型（cl100k_base 编码），本地装个 tiktoken 库就能直接算：
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
text = "大模型接入层的token成本优化"
tokens = enc.encode(text)
print(len(tokens)) # 精确 token 数量
print(tokens) # 每个 token 对应的整数 ID
print(enc.decode(tokens[:3])) # 反解前3个token，看实际切分方式
这段代码干了三件事：编码拿到精确数量、打印原始 ID 方便你对照官方文档核对编码版本、反解前几个 token 看模型到底是怎么切的这句话——这一步很有用，能让你直观看到”大模型”到底是被切成了 大/模型 还是 大/模/型，而不是靠猜。注意坑点：不同模型家族的编码器不一样，Qwen、Claude、Gemini 都有自己的 tokenizer，直接拿 tiktoken 的结果去套用国产模型的账单会算错——如果模型没有开源 tokenizer 或没有对应的 Python 库，退而求其次的办法是调用一次真实 API，然后看返回体里的 usage.prompt_tokens 和 usage.completion_tokens，这是最准的数字，因为是计费方自己报出来的。
再说一个容易被误解的地方：流式（stream）输出不会改变计费方式。 很多人以为开了 stream: true 之后是按返回的数据块（chunk）次数计费，其实不是——流式只是把同一段回答拆成多次网络传输返回给你，方便前端做打字机效果，计费仍然是按完整回答的总 token 数走，等到这次请求完全结束后，账单侧统计的 token 数和非流式模式应该是一致的（个别厂商在流式模式下的最后一个 chunk 才会带上完整的 usage 统计，取那条即可）。
如果你在长文本场景遇到过 context_length_exceeded 或类似的”上下文超限”报错，本质就是输入 token 数（往往还要加上历史对话、系统 prompt）超过了模型的上下文窗口。排查思路：先用上面的方法把完整拼接后的 prompt（系统提示词 + 历史消息 + 本次输入）整体过一遍编码器，看精确 token 数，再对照模型文档里的上下文窗口上限，通常就能定位是哪一段（多半是历史对话没做截断或摘要）把预算吃满了，而不是真的这次输入本身有多长。
常见问题
可以通过压缩中文来省 token 吗？
理论上可以把中文转为更紧凑的表达（去掉不必要的虚词、标点），但会影响模型理解质量，不建议过度压缩。更好的做法是选用中文优化模型。
Tokenizer 会随模型版本更新吗？
偶尔会。重大版本升级（如 GPT-3.5 → GPT-4 → GPT-4o）可能更换 Tokenizer，导致同样 prompt 的 token 数量略有变化。建议在模型升级后重新基准测试。
同一厂商不同模型的 Tokenizer 一样吗？
同系列通常相同（如 GPT-4o 和 GPT-4o-mini 共用 cl100k_base），但不同系列可能不同。建议查阅官方文档确认。
emoji、日文、韩文这些也按”中文规则”算吗？
不是，每种非拉丁字符体系在 BPE 词表里都是单独的一套编码路径，emoji 和多语言字符通常比中文汉字更”碎”——因为它们在训练语料里出现频率更低，BPE 合并的机会更少，很多 emoji 甚至会被拆成 2-3 个 token。如果你的产品面向多语言用户，建议把不同语言的样本分别实测一遍 token 数，不要直接套用中文的比例去估算。
延伸阅读：
- 计费原理总览：大模型 token 计费完全指南
- token 基础入门：token 是什么、和字数怎么换算
- 上下文长度成本：上下文越长越贵：长上下文成本
- 在线估算用量：Token 计算器
- 实时价格对比：价格对比表
- 更多成本话题：token 成本专题