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 算法的無心拆解疊在一起，竟然在神經網絡的黑盒里，重現了人類識字的過程。而當工程師們為了消除「中文稅」，主動把漢字拼好、把成本打下來時，那條意外誕生的語義通道也閉合了。

歷史并不是一條直線進化的軌道，而是在各種約束條件的擠壓下，不斷發生變形的流體。

有些能力是設計出來的，有些只是碰巧沒有被刪掉。

*頭圖來源：geyuyao.com

本文為極客公園原創文章，轉載請聯系極客君微信 geekparkGO

極客一問

你怎么看大模型「中文稅」這件事？