本文来自微信公众号： 极客公园 ，作者：汤一涛，编辑：靖宇，原文标题：《AI 大模型的「中文税」：中文比英文更费 Token，为什么？》
模型不是中性的，它内置了语言偏好。
Opus 4.7刚发布那几天，X上怨声载道。有人说一次对话就把她的session额度用光了，有人说同一段代码跑完的成本比上周翻了一倍多；还有人晒出自己200美元Max订阅不到两小时就触顶的截图。
独立开发者BridgeMind承认Claude是世界上最好的模型，但同时也是最贵的模型。他的Max订阅用不到两小时就限额了，但幸好——他买了两份。｜图片来源：X@bridgemindai
Anthropic官方价格没变，每百万输入token仍是5美元，输出25美元。但这个版本引入了新tokenizer，同时Claude Code把默认effort从high提到了xhigh。两件事叠加，同一份工作消耗的token变成了以前的2到2.7倍。
我在这些讨论里看到两个和中文有关的说法。一个是：中文在新tokenizer下几乎没涨，中文用户躲过了这次涨价。另一个更有意思：古文比现代汉语还省token，用文言文跟AI对话可以节省成本。
第一个说法暗示Claude对中文做了某种优化，但Anthropic的发布文档里，没提过任何和中文相关的调整。
第二个说法则更难解释。古文对人类读者来说显然比现代汉语难懂，一个对人类更复杂的文本，怎么会对AI更容易？
于是我做了一次测试，用22段平行文本（包含商业新闻、技术文档、古文、日常对话等类型），同时送进5个tokenizer（Claude 4.6和4.7、GPT-4o、Qwen 3.6、DeepSeek-V3），读取每段文本在每个模型下的token数，做横向对比。
测试文本：
1、日常对话中英文（旅行、论坛求助、写作请求）
2、技术文档中英文（python文档、Anthropic文档）
3、新闻中英文（NYT时政新闻、NYT商业新闻、苹果公司官方声明）
4、文学选段中英古汉语（《出师表》《道德经》）
测完之后，两个说法都得到了部分验证，但事实会比传言更复杂一些。
01
中文税
先说结论：
1、在Claude和GPT上，中文一直比英文贵
2、在Qwen和DeepSeek上，中文反而比英文便宜
3、Opus 4.7这次引发震荡的tokenizer升级，通胀几乎只发生在英文上，中文纹丝不动
看具体数字。Claude Opus 4.7之前的全系列模型（包括Opus 4.6、Sonnet、Haiku），使用的是同一个tokenizer。在这个tokenizer下，中文的token消耗全线高于等量英文内容，cn/en比值范围在1.11×到1.64×之间。
最极端的场景出现在NYT风格的商业新闻：同一段内容，中文版要多消耗64%的token，等于多付64%的钱。
Opus 4.6及其之前的Claude模型，中文token的消耗量显著高于其它模型（红框）
最极端的场景出现在NYT风格的商业新闻：同一段内容，中文版要多消耗64%的token（绿框）
GPT-4o的o200k tokenizer好一些，cn/en比值多数落在1.0到1.35×之间，部分场景低于1。中文仍然整体偏贵，但差距比Claude小得多。
国产模型Qwen 3.6和DeepSeek-V3的数据则完全反了过来。两者的cn/en比值大面积低于1，这意味着同样的内容，中文版反而比英文版省token。DeepSeek最低做到了0.65×，同一段话中文版比英文版便宜三分之一。
Opus 4.7的新tokenizer通胀几乎只发生在英文上。英文token数膨胀了1.24×到1.63×，中文大量维持在1.000×，几乎没有变化。开头那些英文开发者的账单震荡，中文用户确实没感受到。原因可能是中文在旧版上已经被切到了单字颗粒度，可拆分的空间极小。
Opus 4.7对比4.6，英文消耗的token更多了，中文反而没变
测试过程中我还注意到一件事。token消耗的差异不只是账单问题，它直接影响工作空间的大小。同样200k上下文窗口，用旧版Claude tokenizer装中文资料，能塞进去的内容量比英文少40%到70%。
同一类工作，比如让AI分析一份长文档或者是总结一组会议记录，中文用户能喂给模型的材料更少，模型能参考的上下文更短。结果就是付了更多的钱，但得到的是更小的工作空间。
四组数据放在一起看，一个问题自然浮出来：
为什么同一段内容换个语言，token数就不一样？为什么Claude和GPT的中文贵，Qwen和DeepSeek的中文反而便宜？
答案藏在上文多次提到的概念tokenizer（分词器）上。
02
一个汉字，可以切成几块？
模型在读到任何文字之前，会通过tokenizer把输入切成一个个token。你可以把tokenizer想象成AI的「积木切割机」。你输入一句话，它负责把这句话拆成一块块标准化的积木（也就是token）。AI模型不看文字，只认积木的编号。你用多少块积木，就付多少钱。
英文的切法比较符合直觉，比如「intelligence」大概率是一个token，「information」也是一个token，一个单词对应一个计费单位。
但中文到了这一步就出问题了。把同一句话「人工智能正在重塑全球的信息基础设施」分别送进GPT-4的cl100k tokenizer和Qwen 2.5的tokenizer，切出来的结果完全不同。
GPT-4基本把每一个汉字都拆成了一个token；Qwen则会把词语识别成一个token，例如「人工智能」这4个字在千问只算一个token。
同一句16个汉字的话，GPT-4切出来19个token，Qwen切出来只有6个。
为什么会切成这样？原因在一个叫BPE（Byte Pair Encoding）的算法。
BPE的工作方式，是统计训练语料里哪些字符组合出现频率最高，然后把高频组合合并成一个token，纳入词表。
GPT-2时代，训练语料的绝大多数是英文。英文字母组合（th、ing、tion）反复出现，很快就被合并成token。中文字符在那个语料池里出现的频率太低，排不进词表，只能被当作原始字节来处理，一个汉字占3个字节，就变成了3个token。
BPE按训练语料中的字符频率决定合并。英文语料主导下，中文UTF-8字节无法合并为整字
后来GPT-4的cl100k词表扩大了，常用汉字开始被纳入，一个字通常缩到1到2个token，但整体效率仍然不如英文。
到了GPT-4o的o200k词表，中文效率再进了一步。这也解释了为什么第一段的数据里GPT-4o的cn/en比值比Claude低。
Qwen和DeepSeek作为国产模型，从一开始就把大量常用汉字和高频词组作为整字、整词纳入词表。一个字一个token，效率直接翻倍甚至更多。
同一句话在不同tokenizer下的拆分结果示意图
这就是为什么它们的cn/en比值能低于1，中文字均信息密度本来就高于英文单词，当tokenizer不再人为拆碎汉字，这个天然优势就显现出来了。
所以上一节那四组数据的差异，根源不在模型的能力，而在tokenizer的词表里，给中文留了多少位置。
Claude和早期GPT的词表是以英文为默认值构建的，中文是后来被「塞进去」的；Qwen和DeepSeek的词表从设计之初就把中文当作默认语言对待。这个起点的差异，一路传导到token数、账单、上下文窗口大小。
03
古文真的更便宜吗？
再看开头的第二个传言：古文比现代汉语更省token。
数据确认了这个说法。在测试里，古文样本的cn/en比值全线低于1，在所有五个tokenizer上都一致。同一段内容的古文版本，token数比对应英文翻译还少。
在所有模型中，古文消耗的token数不但比现代中文少，甚至比英文还少
原因也不复杂，古文用字极度精炼。「学而不思则罔，思而不学则殆」是12个字。翻译成现代汉语就是「只是学习而不思考就会迷惑，只是思考而不学习就会陷入困境」，字数直接翻倍，token数自然也跟着翻倍。
而且古文的常用字（之、也、者、而、不）都是高频字符，在任何tokenizer的词表里都有独立位置，不会被拆成字节。所以古文在编码层面确实是高效的。
但这里藏着一个陷阱。
古文的token省在编码端，但模型的推理负担没有减轻。「罔」一个字，模型需要判断它在这个语境里是「迷惑」「被蒙蔽」还是「没有」。现代汉语可以用26个字把这层意思说清楚，用古文等于把铺开的部分压了回去，把推理的活留给了模型。打个比方，一份压缩成zip的文件体积更小，但解压它需要更多计算。
token省了，推理的消耗反而上升了，理解准确度还下降了。这笔账算不过来。
古文这个例子让我意识到，token数量本身不能说明太多问题。但顺着这个方向想下去，还有一层我之前忽略了的东西。
上面说过，GPT-2时代的tokenizer会把「人」这个字拆成三个UTF-8字节token，后来GPT-4的词表扩大，常用汉字变成了一个字一个token，Qwen更进一步，把「人工智能」四个字合成一个token。
直觉上这是一个不断改进的过程：合并得越多，效率越高，模型应该也理解得越好。
但真的是这样吗？我们不妨回忆一下，我们是如何认识汉字的。
汉字是表意文字，现代汉字里超过80%是形声字，由一个表义的偏旁和一个表音的部件组合而成。「氵」旁的字多和液体有关，「木」旁的字多和植物有关，「火」旁的字多和热量有关。偏旁部首就是人类识字时最基础的语义线索，一个不认识「焱」字的人，看到3个「火」也能猜到它和火有关。
因为偏旁部首是人类识字时最基础的语义线索，人会先从结构推断意义范畴，再结合语境理解具体含义。
火花、火焰、光焰，书面语与人名中多见，寓意光明、炽热。
但是在tokenizer的词表里，「焱」这个字对应的是一个编号。我们假设它是38721号，它代表的是词表里的一个索引位置，模型通过它查找到一组数字向量，用这组向量来表征「焱」这个字。
编号本身不携带任何关于这个字内部结构的信息。38721和38722的关系，对模型来说和1和10000的关系没有区别。于是，「汉字的结构」这一层信息，就被封装起来了。三个「火」叠在一起这件事，在编号里不存在。
模型当然可以通过大量训练数据间接学到「焱」「炎」「灼」经常出现在相似的语境里，但这条路比直接利用偏旁信息要更间接一些。
所以模型能不能从拆开的字节里，「看到」某些类似偏旁的结构线索，然后在后续的计算层里重新组合呢？这条路虽然token数多、成本高，但有没有可能在语义理解上，反而比直接吞下一个不透明的编号更有效？
2025年发表在MIT Press《Computational Linguistics》上的一篇论文（《Tokenization Changes Meaning in Large Language Models:Evidence from Chinese》），回答了这个问题。
04
碎片里长出偏旁
论文作者David Haslett注意到一个历史巧合。
1990年代，Unicode联盟在给汉字分配UTF-8编码时，排列顺序是按部首归类排的。同一个部首下的汉字，UTF-8编码是相邻的。「茶」和「茎」都含有「艹」部（草字头），它们的UTF-8字节序列以相同的字节开头。「河」和「海」都含有「氵」部，字节序列同样共享开头。
UTF-8按照部分部首顺序给中文排序，部首相同的字，编码相近｜图片来源：Github
这意味着，当tokenizer把汉字拆成三个UTF-8字节token的时候，共享部首的汉字会共享第一个token。模型在训练过程中反复看到这些共享的字节模式，有可能从中学到「第一个token相同的字，往往属于同一个意义范畴」。这在功能上就接近于人类通过偏旁判断语义的过程。
Haslett设计了三个实验来验证这件事。
第一个实验询问GPT-4、GPT-4o和Llama 3：「茶」和「茎」是否含有相同的语义部首？
第二个实验让模型给两个汉字的语义相似度评分。
第三个实验让模型做「找出不同类」的排除任务。
每个实验都控制了两个变量：两个汉字是否真的共享部首、两个汉字在tokenizer下是否共享第一个token。这个2×2的设计，让她能分离出部首效应和token效应各自的影响。
三个实验的结论一致：当汉字被切成多个token时（比如GPT-4的旧tokenizer下，89%的汉字被切成了多token），模型识别共享部首的准确率更高；当汉字被编码为单个token时（GPT-4o的新tokenizer下，只有57%的汉字还是多token），准确率下降了。
换句话说，上一段的那个猜想成立了。把汉字切碎，成本确实更高，但切碎后的字节序列里保留了部首的痕迹，模型真的从中学到了一些东西。而把汉字编码为整字token，成本降下来了，但部首信息被封装在一个不透明的编号里，模型无法再通过字节序列获取这一线索。
需要特别说明的是，这一结论仅局限于字形相关的细分语义任务，不能等同于模型整体的中文理解、逻辑推理、长文本生成能力下降。同时，实验对比的GPT-4与GPT-4o，除了分词器差异外，模型架构、训练语料、参数量均有显著变化，无法将准确率变化100%归因于分词粒度的调整。
这个发现还得到了工程侧的验证。2024年一项针对GPT-4o的研究发现，GPT-4o的新tokenizer把某些中文字符组合合成了一个长token之后，模型反而出现了理解错误。当研究者用专业的中文分词器，把这些长token重新拆开再喂给模型，理解准确度恢复了。
目前全球大模型行业的主流共识，依然是针对目标语言优化的整词/整字分词器，能显著提升模型的整体性能。整字/整词编码不仅能大幅降低token成本、提升上下文窗口的有效信息量，还能缩短序列长度、降低推理延迟、提升长文本处理的稳定性。论文中发现的细分任务优势，无法覆盖绝大多数中文NLP场景的性能收益。
但这件事依然戳中了大型系统里最难处理的一类问题：你能优化你设计过的部分，但你没法优化你不知道自己拥有的部分。Unicode联盟按部首排列编码，是为了人类检索的方便。BPE把汉字拆成字节，是因为中文在语料里的频率太低。两个不相关的工程决策碰巧叠在一起，产生了一条谁都没规划过的语义通道。
然后，当新一代工程师「改进」tokenizer、把汉字合并为整字token的时候，他们同时抹掉了一条自己不知道存在的路。效率提升了，成本降低了，某些东西也安静地消失了，而你甚至不会收到一条报错信息。
所以事情比「中文在AI里多付钱」这个判断更复杂。每一种tokenizer都在为某个默认值优化，代价藏在了别处。
05
林语堂
中文适配西方技术基础设施的代价，不是AI时代才开始付的。
2025年1月，纽约居民Nelson Felix在Facebook一个打字机爱好者小组里发了几张照片。他在妻子祖父的遗物里发现了一台刻满中文的打字机，不知道是什么来历。很快数百条评论涌入。
Nelson Felix的问题：明快打字机值钱吗？｜图片来源：Facebook
斯坦福大学汉学家墨磊宁（Thomas S.Mullaney）看到照片后立刻认出来了，这是林语堂1947年发明的「明快打字机」的唯一原型机，失踪了将近80年。同年4月，Felix夫妇将打字机卖给斯坦福大学图书馆。
明快打字机要解决的问题，和今天tokenizer面对的问题在结构上是同一个：怎么把中文高效地嵌入一套为西方语言设计的技术基础设施。
1940年代的英文打字机有26个字母键，一键一字，简单直接。中文有几千个常用字，不可能一键一字。当时的中文打字机是一个巨大的字盘，排着几千个铅字，打字员用手逐个捡字，每分钟只能打十几个字。
1899年，美国传教士谢卫楼（Devello Z.Sheffield）所发明的中文打字机，是中文打字机最早的纪录｜图片来源：Wikipedia
林语堂耗资12万美元研发经费，几乎倾家荡产，委托纽约的Carl E.Krum公司做出了一台只有72个键的中文打字机。工作原理是把汉字按字形结构拆开，上形键选字根上半部、下形键选字根下半部，候选字显示在一个叫「魔术眼」的小窗里，按数字键选中。每分钟40到50字，支持8000余常用字符。
（左）透明玻璃小窗即位「魔术眼」；（右）明快打字机内部结构｜图片来源：Facebook
赵元任评价：「不论中国人还是美国人，只要稍加学习，便能熟悉这一键盘。我认为这就是我们所需要的打字机了。」
技术上明快打字机是一种突破，但商业上它失败了。
林语堂向雷明顿公司高管演示时机器出了故障，投资者随之失去兴趣，而造价高昂加上他个人资金链断裂，量产再无可能。1948年，林语堂将原型机和商业权，卖给默根特勒铸排机公司（Mergenthaler Linotype）。该公司最终放弃量产，原型机在1950年代公司搬迁时被一位员工带回长岛家中，之后下落不明，直到2025年重见天日。
墨磊宁在《中文打字机》一书里有一个判断，他认为明快打字机「并不失败」。作为一款1940年代的产品，它确实失败了。但作为一种人机交互范式，它胜利了。
林语堂第一次把中文「打字」变成了「检索加选择」。三排按键组合定位字根，从候选字里挑选。这正是所有现代中文输入法的底层逻辑。从仓颉、五笔到搜狗拼音，都可以说是明快打字机的后裔。
《中文打字机》，作者：墨磊宁｜图片来源：豆瓣
这台跨越了近八十年的打字机，和今天我们反复讨论的分词器，暗藏着某种的历史规律。中文始终面对着一个问题：
如何接入一套罗马字母形成的基础设施。
有趣的是，在这个寻找的过程中，充满了非人为规划的巧合。Unicode联盟为了人类检索方便制定的排序，跟BPE算法的无心拆解叠在一起，竟然在神经网络的黑盒里，重现了人类识字的过程。而当工程师们为了消除「中文税」，主动把汉字拼好、把成本打下来时，那条意外诞生的语义通道也闭合了。
历史并不是一条直线进化的轨道，而是在各种约束条件的挤压下，不断发生变形的流体。
有些能力是设计出来的，有些只是碰巧没有被删掉。