不,中文对 LLM 并不比英文更省 token
一位中文母语者测试“中文字符更省 token”这个流行说法。跨六种 tokenizer,包括 Qwen、GLM、DeepSeek 等中文优先模型,英文每次都使用更少 token。本文讨论数据、BPE 机制,以及为什么字符数和 token 数不是一回事。
AI 驱动 · 每小时限 20 次请求

中文圈子里一直流传着这么个说法:"跟 LLM 对话用中文更省 token,因为汉字信息密度高,字符更少,自然也更便宜。"知乎、微信公众号、各种技术论坛都能看到这种论调。听起来挺有道理——中文确实更紧凑,表达同样的意思字符数更少,按理说应该更高效。
但我自己是中文母语者,对这说法总有点怀疑。干脆测一下。
怎么测的
我从 Golden CLAUDE.md 仓库找了两个文件:英文版 CLAUDE.md 和对应的中文版 CLAUDE.zh.md。内容一样,语言不同。然后把这两个文件丢进我能找到的所有分词器里跑了一遍。
英文版:5,474 个字符,5,514 字节。中文版:2,452 个字符,5,634 字节。
中文字符数确实少了 55%。但字节数反而更多——UTF-8 编码下,一个汉字通常占 3 个字节,而 ASCII 英文字符只占 1 个字节。对"中文更省"这个直觉来说,这已经不是什么好信号了。
然后看 token 数。
| 分词器 | 英文 token | 中文 token | 差异 |
|---|---|---|---|
| GPT-4o / GPT-5.x (o200k_base) | 1,196 | 1,479 | +23.7% |
| GPT-4 / GPT-3.5 (cl100k_base) | 1,200 | 2,001 | +66.8% |
| GPT-3 时代 (p50k_base) | 1,329 | 3,753 | +182.4% |
中文用了更多 token。在最老的分词器上,差不多是英文的三倍。即使在最新的分词器上,也要多出将近四分之一。方向从来没反过来过。
那国产模型呢?
最自然的反驳是:西方模型对中文优化得差呗。那 Qwen、GLM、DeepSeek 呢?这些可都是中国团队做的模型,分词器见过的中文语料肯定多得多。
我也测了。
| 分词器 | 英文 token | 中文 token | 差异 |
|---|---|---|---|
| Qwen 2.5 | 1,203 | 1,351 | +12.3% |
| GLM-4 | 1,202 | 1,307 | +8.7% |
| DeepSeek-V2 | 1,324 | 1,427 | +7.8% |
差距确实小了很多——从 GPT-4o 的 +24% 降到 DeepSeek 的 +8%。但就是没反转。英文依然更省。
为了确认离线分词器的结果在真实 API 里也成立,我把同样两个文件通过阿里云百炼平台发给实时 API,检查模型实际返回的 prompt_tokens。
| 模型(实时 API) | 英文 token | 中文 token | 差异 |
|---|---|---|---|
| Qwen 3.5 Plus | 1,272 | 1,363 | +7.2% |
| GLM-5 | 1,205 | 1,310 | +8.7% |
API 返回的计数包含聊天模板的开销,所以绝对数字比离线测试高。但相对差异讲的还是同一个故事。

为什么英文反而赢:分词是怎么回事
LLM 读的不是字符,是 token。Token 是模型在训练过程中学会识别的文本片段。把文本切分成 token 的算法叫 BPE(Byte-Pair Encoding,字节对编码)。简化版流程是这样的:
- 从所有单独字节开始(256 个基础 token)
- 在训练语料里找出最常相邻出现的 token 对
- 把这一对合并成一个新的 token
- 重复 50,000 到 200,000 次
在这之前还有一步很关键:正则会先把输入切成块,大致按单词或标点来分。BPE 的合并只发生在块内部,不会跨块。这就是为什么整个英文单词能变成单个 token——正则先把一个干干净净的单词形状交给 BPE 处理。
结果就是:常见的模式会被压缩进单个 token。西方模型的训练数据以英文为主,所以英文模式拿走了词表的大部分预算。
大概像这样:
英文: "The golden rules apply to every session"
分词: [The] [golden] [rules] [apply] [to] [every] [session]
数量: 7 个 token
中文: "金规适用于每个会话"
分词: [金] [规] [适] [用于] [每] [个] [会] [话]
数量: 8 个 token英文里,带空格前缀的 " golden" 可以成为单个 token。分词器在训练中见过这个模式足够多次,就一路合并下来了。
中文那边更碎一些,但也不完全是逐字切分。用于 就合并成了一个 token。o200k_base 词表里其实有超过 3,000 个多字 CJK token,比老版本的分词器多很多。但大多数字符还是单独存在,因为 CJK 字符的组合实在太多,词表根本覆盖不完。
这不代表中文对计算机不友好。只是说明构建这些分词器的人把大部分词表预算给了英文,因为训练数据就是那个分布。
人们搞混了三个指标
这个误解能流传这么久,是因为大家把三种不同的度量混为一谈了。
字符数:中文赢。"永远不要假设一个库存在"是 11 个汉字;"Never assume a library exists"带空格是 29 个字符。这是人眼看到的,也是直觉的来源。
字节数:大致持平。中文字符 UTF-8 通常 3 字节,英文字符 1 字节。同样内容编码下来的字节数差不多(这次测试英文 5,514 vs 中文 5,634)。
Token 数:英文赢。BPE 会把常见的字节序列合并成单个 token。英文单词因为训练数据占比高,合并得很激进;中文字符大多还是分散的。

"中文更省 token"这个说法,就是把字符数的观察直接套到了 token 上。但这俩根本不是一回事。字符数是个很差的 token 数代理指标,背后的驱动因素完全不同。
在进步,但很慢
也有好消息。看看 OpenAI 分词器的演进:
- p50k_base(GPT-3 时代,词表里 39 个 CJK token):中文多 +182%
- cl100k_base(GPT-4,754 个 CJK token):中文多 +67%
- o200k_base(GPT-4o,5,776 个 CJK token):中文多 +24%
从 39 个 CJK token 到 5,776 个,差距确实在缩小。Qwen、DeepSeek 这类中文背景的模型把差距进一步压到 +8% 左右。
但"没那么差"和"更好"是两码事。我能找到的最好情况——Qwen 3.5 Plus——中文依然多 +7.2%。英文还是更省 token。
对你写 prompt 有什么实际影响
在 GPT-4o 上,同样内容的中文 prompt 比英文大约多 24% 的 token。规模一上去,这就是真金白银,也是实打实的上下文窗口消耗。其他西方模型大概率差不多,具体数字取决于分词器。
在 Qwen 或 DeepSeek 上,差距降到 7-12%。小了很多,但依然存在。
如果你正在纠结用什么语言写 prompt:用你思考时最自然的那个语言。Token 的差异还没大到值得你切换语言,而且翻译自己的想法所造成的清晰度损失,可能比省下来的 token 成本更伤响应质量。
字符数不是 token 数。你的中文 prompt 在屏幕上看着短,但模型看到的其实更长。任何告诉你"切到中文能省 token"的人,都在把人眼看到的东西和模型实际处理的东西混为一谈。
想自己复核?
测试文件是 Golden CLAUDE.md 里的 CLAUDE.md 和 CLAUDE.zh.md。同一套行为规则,一个英文版一个中文版。如果你找到某个分词器在完整文档上中文更省,我真心想了解一下。
许可
Article text © 2026 Mark Huang. Licensed under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) unless otherwise noted. 文章文本可在非商业场景下分享或翻译,但需标注原文 URL。商业使用需事先取得书面许可,并清楚引用原始来源。
代码片段、截图、第三方素材和网站源码可能适用单独条款。
建议署名: Based on "不,中文对 LLM 并不比英文更省 token" by Mark Huang, originally published at https://markhuang.ai/zh/blog/chinese-token-myth.
相关文章

为什么一个 AI 永远不够
医学、法律、科学和金融等高风险行业都要求独立复核,AI 却常常跳过这一步。37% 的企业已经使用 5 个以上模型,但多数仍是临时拼接。跨模型家族多 AI 系列第一章。
阅读文章
多 AI 论
LLM 会在超过 90% 的情况下确认自己的答案,对自身错误还有 64.5% 的盲区率。跨模型家族的多 AI 流水线,让 Claude 评审 GPT、GPT 评审 Qwen,能打破自我评审的天花板。本文讨论研究、成本和真正有效的做法。
阅读文章
为什么我用 1 美元的阿里百炼订阅探索 Claude 和 GPT 之外的模型
阿里百炼 Coding Plan 以每月 7.9 元打包 Qwen 3.5 Plus、Kimi K2.5、GLM-5、MiniMax M2.5 等八个模型。这里记录价格、配置、取舍,以及把这些模型和 Claude、Codex 一起用于代码评审的体验。
阅读文章