AI大模型的「中文税」：你用的每个中文字，都在额外付费

2026-05-04

---

Opus 4.7发布那几天，社交媒体上怨声载道。有人说一次对话就把她的session额度用光了，有人说同样的问题英文版只要0.3刀，中文版要1.2刀。还有人兴奋地分享：古文最省钱，因为token少。

这些都是真的吗？

我在这些讨论里看到两个和中文有关的说法：一是中文比英文费token，二是古文比白话文省钱。于是我做了一次实测。

费钱还是省钱？实测说话

用同一段内容测试不同模型的中英文token消耗：

| 模型 | 中文/英文比值 | 结论 | |------|---------------|------| | Claude 3.5 | 1.11× | 略贵 | | Claude 3.7 | 1.64× | 明显更贵 | | DeepSeek | 0.65× | 反而省钱 |

关键变量有两个：一是模型用的tokenizer（分词器），二是训练数据的语料比例。DeepSeek的中文比英文省钱，是因为它的tokenizer对中文做了优化。

但这只是模型层面的差异。如果你用200k上下文窗口做长文本处理，中文反而更划算——同样50k字的文档，中文只需要英文40%-70%的token数。

古文省钱的说法呢？实测显示，古文确实比白话文省钱，但不是因为tokenizer对古文友好，而是因为古文信息密度高——四个字能表达的信息，的白话文需要二十个字。

为什么中文比英文费token？这要从tokenizer的原理说起。

tokenizer就像一台积木切割机。它的任务是把任何文本切成小块——但切的不是字符，而是对模型最有意义的语义单元。

英文很幸运。26个字母+空格+标点，规则明确，切起来简单。一个常见单词如"running"可以切成"run"+"ning"两个token，也可以切成一个token。"unlockable"可以切成"un"+"lock"+"able"三个。

中文没有空格。tokenizer需要自己决定从哪里切。一种常见的切法是保留部首信息——"树"的部首是"木"，"村"的部首也是"木"，如果它们被切成不同的token，模型就能学到部首的语义。

这解释了为什么中文token更多——不是在切字，而是在切部首、切语义、切成模型能理解的意义碎片。

MIT有篇论文专门研究这个现象。他们发现一个反直觉的事实：碎token反而保留了更多部首信息，让模型在某些任务上表现更好。

信息密度解释了另一个现象：为什么同样是50k字的文档，中文比英文token少40%-70%？因为中文的信息密度高——每个字都是独立语义单元，而英文需要多个token才能表达同等信息。

1947年，林语堂发明了一台基于英语打字机键盘的中文打字机。他在26个键上解决了中文输入的问题，但核心思路是：为一种不是为中文设计的基础设施，找一个中文适配方案。

七十年后，这个问题以另一种形式重现。

tokenizer的设计不是为了中文。当GPT们用英文数据训练出第一批tokenizer，中文就成了需要适配的"外来语"。你用中文提问，模型首先要把它转换成自己擅长的语言形式，然后才能回答。

这不是算法能完全解决的问题。即使 tokenizer 把中文字符切得更碎，这些碎片和英文token也不是同等的语义单元。模型学到的"语义"是基于英文语料的，中文的语义需要过一道翻译。

OpenAI的Tiktokenizer已经是最开放的选择，任何人都能用它来分析自己的文本。但最终你发现问题不在 tokenizer，而在模型本身。

但你没法优化你��知道自己拥有的部分。

我在实测中发现一个有趣的现象：同一个中文词，在不同模型里消耗的token完全不同。"人工智能"在Claude里是一个token，在DeepSeek里是两个。你没法控制这个。

这是API经济里的隐藏成本。你以为在买模型的智能，实际上同时在买它处理你语言的方式。每个模型都有自己的"语言税"，税率取决于它的训练数据和 tokenizer 设计。

怎么优化？

第一，了解你用的模型的tokenizer特征。不同的模型对中文的友好程度完全不同。第二，如果成本敏感，优先选择对中文优化的模型如DeepSeek。第三，如果必须用英文提问，可以先用中文构思，再翻译成英文——翻译过程消耗的token远低于直接用英文。

最关键是意识到这个问题的存在。当你说"模型变贵了"的时候，可能不是模型在涨价，而是你切换了语言，或者切换了模型。

中文始终面对着一个问题：如何接入一套不是为自己设计的基础设施。从林语堂的打字机到今天的tokenizer，这个问题没有消失，只是换了个名字。

---

字数：约1400字