摘要：用 AI 写中文，账单为什么比英文贵？ 36 氪实测发现， Claude 上中文最多多付 64%的钱，但 Qwen 和 DeepSeek 反而便宜了三分之一。这篇文章用白话讲清楚 BPE 分词的原理，给你 4 个省钱的实操建议。
标签：人工智能、 AI 大模型、 Claude 、 Token 优化、 AI 成本
凌晨一点多，我在 Claude 上跑一个长文本分析，眼睁睁看着 token 数像水龙头没关紧一样往上跳。那个数字又胖又让人心疼。那条对话跑完， session 直接炸了，显示用完了今天的配额。
我愣了一下，切换到英文把同样的内容再跑一遍， token 数直接少了将近一半。
这太扯了。
去年 Claude Opus 4.6 刚发布那几天， X 上怨声载道。有人晒出来 200 美元的 Max 订阅不到两小时就触顶的截图。独立开发者 BridgeMind 说他买了两份 Max 订阅，因为一份根本不够用。
官方价格没变，还是每百万输入 token 5 美元，输出 25 美元。但 Claude Opus 4.7 引入了新的 tokenizer ，同时把 Claude Code 的默认 effort 从 high 提到了 xhigh 。两件事叠加，同一份工作消耗的 token 变成了以前的 2 到 2.7 倍。
但这里有个有意思的现象：英文用户疯了，中文用户没啥感觉。
因为通胀几乎只发生在英文上——英文 token 数膨胀了 1.24 到 1.63 倍，中文维持在 1.000 ，几乎没变。那些英文开发者的账单震荡，中文用户确实没感受到。
原因可能是中文在旧版上已经被切到了单字颗粒度，可拆分的空间极小。
但我还是想搞明白：为什么同一段内容，换个语言 token 数就不一样了？为什么 Claude 和 GPT 的中文贵， Qwen 和 DeepSeek 的中文反而便宜？
36 氪测了 5 个模型，数据很有意思
36 氪前段时间做了一次测试，用 22 段平行文本（包含商业新闻、技术文档、古文、日常对话等类型），同时送进 5 个 tokenizer （ Claude 4.6 和 4.7 、 GPT-4o 、 Qwen 3.6 、 DeepSeek-V3 ），读取每段文本在每个模型下的 token 数，做横向对比。
测完之后，结论很清晰：
1.在 Claude 和 GPT 上，中文一直比英文贵2.在 Qwen 和 DeepSeek 上，中文反而比英文便宜3.Opus 4.7 这次引发震荡的 tokenizer 升级，通胀几乎只发生在英文上，中文纹丝不动
具体数字是这样的：
Claude Opus 4.6 及之前的全系列模型，中文的 token 消耗全线高于等量英文内容， cn/en 比值范围在 1.11×到 1.64×之间。
最极端的场景出现在 NYT 风格的商业新闻：同一段内容，中文版要多消耗 64%的 token ，等于多付 64%的钱。
GPT-4o 好一些， cn/en 比值多数落在 1.0 到 1.35×之间，部分场景甚至低于 1 。中文仍然整体偏贵，但差距比 Claude 小得多。
但国产模型 Qwen 3.6 和 DeepSeek-V3 的数据完全反过来了。
两者的 cn/en 比值大面积低于 1 ，这意味着同样的内容，中文版反而比英文版省 token 。 DeepSeek 最低做到了 0.65×，同一段话中文版比英文版便宜三分之一。
真的便宜了三分之一。
测试过程中还注意到一件事： token 消耗的差异不只是账单问题，它直接影响工作空间的大小。
同样 200k 上下文窗口，用旧版 Claude tokenizer 装中文资料，能塞进去的内容量比英文少 40%到 70%。
同一类工作，比如让 AI 分析一份长文档或者是总结一组会议记录，中文用户能喂给模型的材料更少，模型能参考的上下文更短。
结果就是付了更多的钱，但得到的是更小的工作空间。
根子藏在 tokenizer 里
模型在读到任何文字之前，会通过 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 。
后来 GPT-4 的 cl100k 词表扩大了，常用汉字开始被纳入，一个字通常缩到 1 到 2 个 token ，但整体效率仍然不如英文。
到了 GPT-4o 的 o200k 词表，中文效率再进了一步。这也解释了为什么第一段的数据里 GPT-4o 的 cn/en 比值比 Claude 低。
但 Qwen 和 DeepSeek 作为国产模型，从一开始就把大量常用汉字和高频词组作为整字、整词纳入词表。
一个字一个 token ，效率直接翻倍甚至更多。
这就是为什么它们的 cn/en 比值能低于 1 。中文字均信息密度本来就高于英文单词，当 tokenizer 不再人为拆碎汉字，这个天然优势就显现出来了。
这事儿跟 1947 年的打字机有关
其实中文适配西方技术基础设施的代价，不是 AI 时代才开始付的。
2025 年 1 月，纽约居民 Nelson Felix 在 Facebook 一个打字机爱好者小组里发了几张照片。他在妻子祖父的遗物里发现了一台刻满中文的打字机，不知道是什么来历。
斯坦福大学汉学家墨磊宁（ Thomas S. Mullaney ）看到照片后立刻认出来了，这是林语堂 1947 年发明的"明快打字机"的唯一原型机，失踪了将近 80 年。
明快打字机要解决的问题，和今天 tokenizer 面对的问题在结构上是同一个：怎么把中文高效地嵌入一套为西方语言设计的技术基础设施。
1940 年代的英文打字机有 26 个字母键，一键一字，简单直接。中文有几千个常用字，不可能一键一字。当时的中文打字机是一个巨大的字盘，排着几千个铅字，打字员用手逐个捡字，每分钟只能打十几个字。
林语堂耗资 12 万美元研发经费，几乎倾家荡产，委托纽约的 Carl E. Krum 公司做出了一台只有 72 个键的中文打字机。
工作原理是把汉字按字形结构拆开，上形键选字根上半部、下形键选字根下半部，候选字显示在一个叫"魔术眼"的小窗口里，按一下选字键，汉字就打出来了。
一套 72 个键，打出了几千个字。
今天的大模型在做同样的事情：把中文拆成 token ，装进一套为英文设计的词表里。不同的是，林语堂是在主动设计一个中文友好的系统，而现在的 tokenizer 是在被动适配。
怎么省这笔钱？
说了这么多，实际开发中该怎么办？
我有几个实操建议：
第一，选对模型。
如果你主要用中文，优先考虑国产模型。 Qwen 、 DeepSeek 这类从一开始就把中文当作默认语言的模型，中文 token 效率天然更高。同样的钱，能塞进去更多内容，得到更大的上下文窗口。
第二，优化 Prompt 。
这是很多人忽略的一点。中文字词的信息密度本来就高，但如果你喜欢用大量冗余表达，一样会浪费 token 。
比如不要写"请帮我详细地、全面地、深入地分析一下这篇文章"，直接写"分析这篇文章"。一个字一个字地抠，长远来看能省不少钱。
第三，善用压缩。
有些长文本可以先做摘要再送进模型。比如你要分析一份 100 页的技术文档，先让模型生成一个结构化摘要，然后基于摘要做深度分析。这样虽然多了一步，但总的 token 消耗可能更少。
第四，注意上下文窗口。
中文在 Claude 和 GPT 上更贵，意味着同样的上下文窗口能塞进去的内容更少。这个处境很潮湿。如果你要做长文本任务，可能需要分段处理，或者选择支持更大窗口的模型。
我也不确定这是不是问题
写到这里我突然意识到一个问题。
token 数量本身能说明太多事情吗？
古文的 token 数比现代汉语少，甚至比英文还少。但古文对模型来说真的更"便宜"吗？
古文用字极度精炼。"学而不思则罔，思而不学则殆"是 12 个字。翻译成现代汉语就是"只是学习而不思考就会迷惑，只是思考而不学习就会陷入困境"，字数直接翻倍， token 数自然也跟着翻倍。
但古文的 token 省在编码端，模型的推理负担没有减轻。"罔"一个字，模型需要判断它在这个语境里是"迷惑""被蒙蔽"还是"没有"。现代汉语可以用 26 个字把这层意思说清楚，用古文等于把铺开的部分压了回去，把推理的活留给了模型。
打个比方，一份压缩成 zip 的文件体积更小，但解压它需要更多计算。
token 省了，推理的消耗反而上升了，理解准确度还下降了。这笔账算不过来。
也许我们在乎的 token 数量，只是冰山一角。
而且还有一种可能——把汉字切碎，成本确实更高，但切碎后的字节序列里保留了某些结构线索，模型真的从中学到了一些东西。
2025 年发表在 MIT Press 《 Computational Linguistics 》上的一篇论文发现了一个有意思的事：当汉字被切成多个 token 时，模型识别共享部首的准确率更高；当汉字被编码为单个 token 时，准确率下降了。
这意味着什么？
我也不知道。没人告诉我这个。
可能每一种 tokenizer 都在为某个默认值优化，代价藏在了别处，就像那个词表表面光鲜，里面却发霉了。
就像林语堂的明快打字机，确实解决了中文输入的问题，但成本是 12 万美元和倾家荡产。今天的大模型解决中文适配问题，成本是我们每个月多付的账单和更小的上下文窗口。
这笔钱到底值不值？
这可能是每个用 AI 的人都得自己想清楚的事。
如果你觉得这篇文章有用，欢迎关注公众号「技谈白话」，我会持续分享技术白话、 AI 实践和行业洞察。
也欢迎在评论区聊聊：你用 AI 的时候，有没有遇到过类似的"语言税"问题？
