非英語稅：用 Claude 寫中文，同樣內容 token 比英文版多 71%

一張對比表，看懂為什麼你的 API 帳單比 SF 同事貴

最近有一份調研數據在 AI 圈流傳——AI 研究員 Aran Komatsuzaki 把 Richard Sutton 的經典文章 《The Bitter Lesson》 翻譯成多種語言，分別丟進 OpenAI 和 Anthropic 的 tokenizer 測 token 數，以英語為基準做對比。後來這份數據被 Aihola 整理成報導 廣傳，中文社群也在 LINUX DO 等地討論炸鍋。

做法很簡單，數據出來卻比很多人想像的差距大。

Anthropic 模型（以英語 token 數 = 1.0 為基準）：

語言 Token 倍數 翻譯成成本含義
英語 1.00x 基準
法語 1.79x 貴 79%
中文 1.71x 貴 71%
俄語 2.04x 貴 104%
阿拉伯語 2.86x 貴 186%
印地語 3.24x 貴 224%

OpenAI 模型（同樣以英語 = 1.0 為基準）：

語言 Token 倍數 翻譯成成本含義
英語 1.00x 基準
法語 1.30x 貴 30%
中文 1.15x 貴 15%
俄語 1.31x 貴 31%
阿拉伯語 1.31x 貴 31%
印地語 1.37x 貴 37%

這個現象在英文社群被叫做 “non-English tax”——「非英語稅」。其實學術界早就在談這件事，2023 年的一篇 arXiv 論文 《Language Model Tokenizers Introduce Unfairness Between Languages》 就系統性地量化了這個不公平。OpenAI Developer Community 上也有 一個經典討論串 在罵這件事。

意思就是，你用非英語寫同樣內容的 prompt，要多消耗幾倍的 token，意味著更高的 API 成本、更慢的響應速度、更容易撞上下文窗口的上限。

而且不是兩家平均地貴。Anthropic 對非英語的稅率，明顯比 OpenAI 重很多。

我看到這個數據的第一反應是：「啊，原來不是我感覺的問題」。

我用 Claude Code 寫過上百萬 token 的中文 prompt，也用 OpenAI 處理過大量中文文件。體感一直就是 Claude 處理中文比較燒錢，但一直沒去算。這份數據把我的體感量化了——而且更慘。

⚠️ 兩個你必須知道的 Caveat

在繼續讀下去之前，我必須先講三件事，不然這篇文章會誤導你。

Caveat 0：「71%」這個數字的基準是什麼

先把基準講清楚再讀下去。上面那兩張表的 1.0x 是各家 tokenizer 自己處理英文的 token 數——Anthropic 英文 = 1.0、OpenAI 英文 = 1.0，不是用同一把尺。

所以「Claude 中文 1.71x」這個數字的意思是：Claude 中文 token 數，是 Claude 英文 token 數的 1.71 倍。也就是「同一家公司內部，中文比英文多吃 71%」。

如果改用 OpenAI 英文當共同基準，原始數據裡 Anthropic 英文約 1.04 倍 OpenAI 英文，重新換算 Claude 中文 ÷ Claude 英文 ≈ 1.64x，差距就變 64%。所以你看到不同來源寫「貴 65%」「貴 71%」其實是同一個現象，只是基準不同。

我這篇文章後面用的都是 Anthropic 內部基準（1.71x = 71%），因為對企業做選型來說，「Claude 中文比 Claude 英文貴多少」比「Claude 中文比 OpenAI 英文貴多少」更貼近實際的 API 帳單比較場景。但你看到別人寫 65% 不要覺得衝突，是基準不同。

另外要強調：71% 不是「每個中文字逐字貴 71%」。它是「同一段語義內容翻譯成中文後，token 數的平均倍數」。「的」「是」這種高頻字可能還是 1 token，「龘」這種冷字才會吃到 3 個。所以這是語義內容層級的平均倍數，不是逐字稅率。

Caveat 1：這份數據沒被獨立審計

Aran Komatsuzaki 的測試是社群整理的非正式 benchmark，沒有任何第三方獨立驗證。原因很現實——Anthropic 從來不公開現行 tokenizer。

你想自己跑一次都跑不了。社群只能用反推：javirandor/anthropic-tokenizer 這個 GitHub repo 是社群透過觀察 generation stream 反推出來的近似版本，Hacker News 的這個討論串 還挖出 Anthropic 自己 repo 裡塞了一份 Claude 3 tokenizer。

所以 1.71x、3.24x 這些確切數字，請當成方向性參考，不是法庭證據。

唯一比較靠譜的可重現 benchmark 是 vfalbor/llm-language-token-tax 這個 repo，但它只測 OpenAI 的 cl100k 跟 o200k，沒測 Anthropic（因為前面講的原因）。它的 OpenAI 中文倍數是 1.33x，跟 Komatsuzaki 的 1.15x 有差距，可能是用了不同 tokenizer 版本（cl100k vs o200k）或不同文本。

Caveat 2：Opus 4.7 換了 tokenizer，但官方說的方向跟你想的不一樣

2026/4/16 Anthropic 發布的 Claude Opus 4.7 換了新 tokenizer。我第一次看到這個更新時，直覺是「啊，他們要修非英語稅了」。

但實際讀官方 migration guide 跟 release notes，方向跟我想的不一樣：

「同樣輸入在 Opus 4.7 上的 token 數可能變成 1.0–1.35 倍，請重新評估你的 token budget。」

注意這個方向——Anthropic 自己警告的是 token 數可能「增加」最多 35%，不是降低。新 tokenizer 對非英語有沒有改善？官方文件沒有給數字。

社群有些二手報導（VentureBeat、MindStudio）寫新 tokenizer「對非拉丁文字更友好」，但這跟官方原文有溫差。我寫第一版的時候直接引用了這些二手數字（中日韓阿印降 20-35%），但回頭查 Anthropic 官方公告跟 migration guide，這個說法沒有官方背書，我修掉了。

結論：是否改善中文稅，需要拿你自己的 production prompt 實測。 不能用「Opus 4.7 = 中文友好」這種廠商行銷話術直接推論，方向有可能是反過來的。

要驗證 5 分鐘就能跑：用 Anthropic 的 count_tokens API 拿同一段中文分別打 claude-sonnet-4-6 跟 claude-opus-4-7，比對 token 數差距。

另一個 load-bearing 假設：Opus 4.7 release notes 主要在講 Opus，沒明確說明 Sonnet 4.5/4.6 是否同步換 tokenizer。我發稿前沒跑完整 benchmark，所以接下來成本計算用 Sonnet 4.5 + Komatsuzaki 的 1.71x（這也是 production 主流情境）。如果你發現 Sonnet 4.6 token 數實測跟 4.5 有差異，這篇後面的數字要折算。

這不是 bug 是 feature：BPE Tokenizer 的英文偏見

為什麼會這樣？要從 tokenizer 講起。

LLM 不是一個字母一個字母讀的，它是把文字切成 “token” 再讀。BPE（Byte Pair Encoding） 這套 tokenizer 演算法，會根據訓練資料裡的字元頻率，把常見的字元組合合併成單一 token。想直觀感受 tokenizer 怎麼切你的文字，OpenAI 有 官方 tiktokenizer 工具，Anthropic 則可以用 Lunary 的 Claude tokenizer 或 Token counting API。

英文有個天然優勢：26 個字母 + 高度結構化的 subword pattern。”unbelievable” 雖然 12 個字母，但 BPE 會把它切成 “un” + “believ” + “able” 三個 token。

中文不一樣。中文 4-5 萬個常用字，每個字本身就是語義單位。但 tokenizer 訓練時看到的中文資料相對少，所以很多中文字會被切成 2-3 個 byte-level token。一個「龘」字可能就吃掉 3 個 token，因為它在訓練資料裡出現次數太少，根本沒被合併。Ivan Krivyakov 的 這篇實驗筆記 跟 PromptCost 的拆解 都把這個機制講得很清楚。

Anthropic 比 OpenAI 慘的原因，就是 vocab size 跟訓練資料的多語言比例。

OpenAI 的 cl100k_base 系列 tokenizer，大概是 100K vocab，訓練資料的多語言佔比較高（GPT-4o 之後升級到 o200k_base，更友好）。Anthropic 公開資訊較少（官方 API 文件 只給 count_tokens API，不給 vocab），但從這個倍數可以反推——他們的 tokenizer 對非英語的覆蓋確實比較弱，或者說，他們是用英語使用者的視角優化的。

印地語 3.24x 不是隨機數字。印地語用的是 Devanagari 字符（天城文），這套字符在 byte-level 編碼下每個字符就要 3 個 byte。如果 tokenizer 沒有針對性合併常見字符組合，一個印地語句子的 token 數會很可怕。

阿拉伯語 2.86x 同理，Arabic script 加上連字（ligature）特性，tokenizer 處理不好就會爆 token。

這不是惡意，是優先級問題。在訓練 tokenizer 的時候，你要決定 vocab 的 100K 個位子分給誰。給英文 subword 多一點，benchmark 上看起來更好；給其他語言多一點，會犧牲英文 efficiency。

Anthropic 顯然選了前者。

算給你看：一個典型台灣企業的真實帳單差距

理論講完，看實際成本。

假設你是一家台灣的金融業，做一個中文客服 chatbot：

  • 每天處理 conversations： 10,000 通
  • 每通平均 input： 500 token（英語基準下）
  • 每通平均 output： 200 token
  • 語言： 100% 繁體中文

用 Claude Sonnet 4.5（$3/MTok input, $15/MTok output）跑：

1
2
3
4
5
6
7
8
9

中文 input token = 500 × 1.71 = 855 token/通
中文 output token = 200 × 1.71 = 342 token/通

每通成本 = 855 × $3/1M + 342 × $15/1M
        = $0.00257 + $0.00513
        = $0.0077

每天成本 = $77
每月成本 = $2,310

換成 GPT-4o（$2.5/MTok input, $10/MTok output）：

1
2
3
4
5
6
7
8
9

中文 input token = 500 × 1.15 = 575 token/通
中文 output token = 200 × 1.15 = 230 token/通

每通成本 = 575 × $2.5/1M + 230 × $10/1M
        = $0.00144 + $0.00230
        = $0.0037

每天成本 = $37
每月成本 = $1,121

換成 DeepSeek V3（中文 tokenizer 友好，約 $0.27/MTok input, $1.1/MTok output）：

1
2
3
4
5
6
7
8
9

中文 input token ≈ 500 × 0.95 = 475 token/通（中文比英文還省）
中文 output token ≈ 200 × 0.95 = 190 token/通

每通成本 = 475 × $0.27/1M + 190 × $1.1/1M
        = $0.00013 + $0.00021
        = $0.00034

每天成本 = $3.4
每月成本 = $102

註：DeepSeek 的 0.95x 中文倍數是估計值。 DeepSeek 官方沒公布 tokenizer 多語言 benchmark，這個數字是社群實測的概略區間（多半落在 0.9–1.0x 之間）。直覺上合理——DeepSeek 訓練資料以中文為主，tokenizer vocab 對中文 subword 覆蓋密度高。但精確數字請拿自家 prompt 實測，我給這個 0.95x 是為了方便對比，不是法庭證據。

同樣的中文 chatbot，月帳單差距：Claude $2,310 vs OpenAI $1,121 vs DeepSeek $102。

但這個差距要拆開看，不能全部歸因到非英語稅，不然會誤導讀者「換家就省 20 倍」。實際拆解：

Claude → OpenAI（$2,310 → $1,121，2.06x 差距）

  • 單價差距：Claude Sonnet $3 vs GPT-4o $2.5（input）= 1.2x
  • Tokenizer 稅差距：Claude 中文 1.71x vs OpenAI 中文 1.15x = 1.49x
  • 乘起來 ≈ 1.79x，加上 output token 單價差（$15 vs $10）拉到約 2x

所以換 OpenAI 真正省到的，主要是 tokenizer 稅 1.5x + 單價 1.2x，合計 2 倍左右。 不是 20 倍。

Claude → DeepSeek（$2,310 → $102，22.6x 差距）

  • 單價差距：Claude Sonnet $3 vs DeepSeek $0.27（input）= 11.1x（這是模型本身的定價差，跟 tokenizer 完全無關）
  • Tokenizer 稅差距：Claude 1.71x vs DeepSeek 0.95x = 1.8x
  • 乘起來 ≈ 20x，加上 output 單價差距（$15 vs $1.1）最終約 22x

這個 22x 裡面，tokenizer 貢獻 1.8x，模型單價貢獻 11x。 真正的暴力差距是模型單價，不是 tokenizer 稅。要享受這個 11x，你付的代價是 compliance 風險（資料出境）跟一些品質差距。

而且這還只算了單價跟 token 倍數。沒算 latency，沒算 context window 撞上限被迫 truncate、被迫多輪對話的次數、被迫做 summarization 的額外成本。

印地語、阿拉伯語：非英語市場的企業都該重新算這筆帳

3.24x 是什麼概念？

如果你是印度的 startup，做一個印地語的法律諮詢 agent，每次 API call 比同樣英語場景多吃 2.24 倍 token。如果產品的 ARPU 又比美國市場低，這個 token 稅在 unit economics 裡就變成需要認真對待的成本項——不是「順便處理一下」可以帶過的。

這就是為什麼印度本土做 Indic 深度應用的團隊——法律、醫療、教育、政府服務這類需要深度印地語（含其他 22 種印度官方語言）理解的場景——很多走自訓路線，Sarvam AI、Krutrim 是代表案例，常採用 Llama、Mistral 開源 weights 做 fine-tuning。

範圍要講清楚——印度一般 SaaS 公司（Zoho、Freshworks、Postman 這類）依然大量使用 OpenAI / Claude，因為他們的工作語言主要還是英文、處理的多半也是英文場景。只有任務需要深度印地語理解，3.24x 的 token 稅才會明顯壓縮 unit economics，讓自訓 / 開源 fine-tuning 變成更值得考慮的選項。不是民族主義，是經濟學。

阿拉伯語也是一樣。沙烏地、阿聯的政府投資 AI 蓋自己的模型（Falcon、Jais），表面上是技術自主，底層也跟這個 token 經濟學脫不了關係——每次跑阿拉伯語就吃 2.86x 稅，做大規模消費級應用的成本結構會被改變。

但這篇文章的重點，其實不只是印度跟中東。

如果你是台灣、香港、日本、韓國、東南亞、拉美的公司，做的產品有大量目標語言不是英文的場景——你都該停下來重新算這筆帳。Anthropic 是不是貴 1.71x、2.86x、3.24x，要拿你自己的 production prompt 實測。算完之後值不值得繳這筆稅，取決於你的任務價值密度跟 ARPU：

  • 高價值低 volume（核心 PRD、策略文件、複雜 coding）→ 即使 1.71x 也值得
  • 中價值中 volume（一般客服、文件處理、批次摘要）→ 1.71x 開始痛，要考慮 routing
  • 低價值高 volume（純中文資料清洗、批次分類、embedding 預處理）→ 這個區段繼續用 Claude 是燒錢

對比之下，OpenAI 的 1.31x 印地語倍數，是 Anthropic 的不到一半。這也部分解釋了為什麼 OpenAI 在新興市場滲透率比 Anthropic 高。Anthropic 在英語企業市場很強，但企業市場集中在英語區。

這不是巧合，是 tokenizer 設計選擇的累積結果。

中國模型的反向優勢：你不只省錢，你也省 context window

當對比擴展到 Gemini、Qwen、DeepSeek、Kimi，覆蓋中文、日語、韓語、西班牙語、法語、德語、俄語、阿拉伯語、印地語等多個語言，結論更清晰了：

主流中文模型處理中文比英文便宜。

這不只是價格問題。Token 倍數低意味著兩件事：

  1. 單筆 API 成本低——直接的成本優勢
  2. 同樣的 context window 能塞更多內容——隱形的能力優勢

第二點被嚴重低估。

舉個例子：你要做一個 RAG 系統，retrieve 多份中文 PDF 餵給模型。

中文文件實際吃多少 token，沒辦法用「字數 × 1.71」這種公式估——1.71x 是「英文翻成中文後 token 倍數」的對比，不是「中文字數轉 token 的轉換率」。要精確估必須拿真實文件丟 token counter 跑一次。

但結構上你可以這樣理解：Claude 的 200K context 數字看起來是 DeepSeek 128K 的 1.5 倍，但折算 tokenizer 對中文的處理效率差距，實際處理中文場景的「可用空間」差距會大幅縮小，甚至可能反轉——同樣一份中文 PDF 餵進 Claude 跟 DeepSeek，Claude 吃到的 token 數明顯較多。

所以中文 RAG 場景下，看 context window 不能只看廣告數字（200K vs 128K），要折算 tokenizer 效率。我自己實測過幾份金融研究報告，原本以為 Claude 200K 一定夠塞，結果撞到 truncation 的次數比預期多很多。

這就是為什麼你會看到中國的金融、法律、醫療領域大量採用 DeepSeek、Qwen——不是因為「國產替代」的口號，是因為在他們的語言場景下，數學就是這樣。

What didn’t work smoothly：Claude 仍然值得的時候

寫到這裡，你以為我要勸你全部切換到 OpenAI 或 DeepSeek。

不是。我自己現在主要用的還是 Claude（Claude Code、Claude Sonnet 4.6）。

我來坦白幾個 Claude 仍然值得貴 1.71x 的場景：

1. 推理密度高的任務

寫一個複雜的 PRD 或 architecture review，Claude Sonnet 4.5 / Opus 4 的輸出品質仍然明顯高於 GPT-4o。我做過的測試：同樣的輸入，Claude 一次到位，GPT 需要 2-3 輪 refine。Token 倍數帳算下來反而 Claude 更省。

2. Coding 場景

Claude Code 對 codebase 的理解和 multi-file edit 能力，目前沒有對手。即使每個 prompt 多吃 71% token，但完成一個 task 需要的 prompt 次數可能少 50%。整體 token 總量未必更多。

3. 長文本理解

雖然 Claude 處理中文倍數高，但 200K context 的「實際可用容量」對複雜文件分析仍然夠用。換到 GPT-4o 的 128K，撞上限的次數更多。

4. Tool use 跟 agent loop

Claude 的 tool use 訓練做得比較細，agent loop 在意外狀態下的 recovery 比較好。這個品質差距在 production 是真金白銀的差距——一次 agent 跑掛，工程師 debug 1 小時的成本，遠遠超過省下的 API token 錢。

所以非英語稅是真的，但不是「換一家就好」的問題。

它是一個 trade-off matrix，不是 single answer。

三層策略：別 all-in 任何一家

我自己跟客戶談 LLM 選型時，現在會用三層策略：

Tier 1｜高價值、低 volume 的核心任務

  • 用 Claude Sonnet 4.5 或 Opus 4.7（後者換了新 tokenizer，但官方沒明確給非英語的改善幅度，自己實測比較保險）
  • 場景：策略文件、PRD、architecture design、核心 coding
  • 心態：認賠 71% 中文稅（Sonnet 基準），因為品質差距 > token 差距。Opus 4.7 對中文是否真的省，跑 count_tokens API 確認過再決定要不要升級

Tier 2｜中等價值、中 volume 的標準任務

  • 用 GPT-4o 或 Gemini 2.0 Flash
  • 場景：客服回覆、文件 summarization、一般問答
  • 心態：1.15x 中文稅可以接受，速度跟成本是 sweet spot

Tier 3｜低單價、高 volume 的批次處理

  • 用 DeepSeek V3 或 Qwen 2.5 Max
  • 場景：批次 OCR 後處理、大量資料清洗、純中文場景的 embedding 預處理
  • 心態：中文 token 反而比英文省，價格也最低，這個層級不用 Claude / OpenAI 是浪費錢

關鍵是：不要用單一模型解決所有事。

很多企業的 AI 帳單失控，不是因為用錯模型，是因為用同一個模型做所有事——把 Claude Opus 拿去做 OCR 後處理、拿去做客服 FAQ 匹配，這就是用 7-11 御飯糰的價錢買法國米其林三星。

我們團隊現在的 production 流程，至少混用 3-4 個模型。Routing 邏輯多寫一點，月帳單差 5-10 倍很正常。

最後想說

非英語稅這個現象，技術上不是新發現。tokenizer 的 multilingual fairness 問題，學術界討論很多年了。

但這個數據之所以值得寫，是因為它把一件本來只有研究員在意的事，變成了任何亞洲企業在做 LLM 選型時都該算清楚的成本項。

如果你的核心市場是英語區，這篇文章對你影響不大。

如果你的核心市場是中文、日韓、東南亞、印度、中東——你正在被收一筆隱藏的稅。不知道，不代表沒繳。

最後再強調一次前面講的三個 caveat：

  1. 基準要講清楚——表格的 1.0x 是各家自己的英文 token 數，不是同一把尺。「Claude 中文 1.71x」是相對 Claude 英文，不是相對 OpenAI 英文。所以你看到別家寫 65% 不要覺得衝突，是基準不同。
  2. Komatsuzaki 的數字沒被獨立審計——確切倍數請當參考，不要當聖經。要精確算，自己拿真實 prompt 跑 Anthropic 的 token counter 跟 OpenAI 的 tiktokenizer。
  3. Opus 4.7 換了 tokenizer，但是否改善中文稅還沒驗證——Anthropic 官方反而提醒同樣輸入可能多吃 1.0–1.35x token。Sonnet 4.5/4.6 是否同步換沒明確說明，建議發稿前自己 5 分鐘 benchmark 確認。

但「Anthropic 對非英語比 OpenAI 重」這個方向性結論，跟我自己用了兩年的體感完全一致。

下次跟你的 CTO 報 Claude 帳單時，記得加一句：「我們處理中文比英文多吃了 71% 的 token，這是 Anthropic tokenizer 對非英語的稅。如果我們的目標市場是中文，這筆稅該不該繳，要看每個任務的價值密度。要不要升 Opus 4.7 換新 tokenizer 試試看？官方沒給保證，我們自己跑個 benchmark 比對 Sonnet 4.6 跟 Opus 4.7 的中文 token 數，5 分鐘有結論。」

這比「Claude 太貴了我們換 OpenAI」要 professional 太多。

延伸閱讀

原始數據與報導：

Anthropic Opus 4.7 新 tokenizer 相關：

學術背景：

Tokenizer 工具：

其他相關拆解：

模型 / 廠商連結：

常見問題 Q&A

Q: 這個倍數會隨模型版本改變嗎？

會。Tokenizer 通常跟著模型大改版才換，但每次換 tokenizer 倍數都可能變。建議自己拿真實 prompt 用各家的 tokenizer 算一次，最準。

Q: 為什麼 OpenAI 的中文倍數比 Anthropic 低這麼多？

主要是 vocab size 跟訓練資料的多語言比例。OpenAI cl100k 系列對中文 subword 覆蓋較好。Anthropic tokenizer 細節公開較少，但從倍數可以反推他們對非英語的優化優先級較低。

Q: 用 prompt cache 能不能抵消非英語稅？

可以部分抵消。Anthropic 的 prompt caching 對重複前綴有 90% 折扣，所以高重複率場景（agent system prompt、固定 RAG context）會大幅降低 effective cost。但動態 user input 的部分稅照繳。我之前寫過 一篇關於 KV Cache 怎麼省 80% token 的文章 可以參考。

Q: 如果我做的是中英文混合 prompt，倍數怎麼算？

按比例加權平均。一個 70% 中文 + 30% 英文的 prompt，用 Claude 約 1 × 0.3 + 1.71 × 0.7 ≈ 1.50x。實務上建議拆 system prompt 用英文（讓 model 理解 task）+ user data 用原文。

Q: 用中國模型有 compliance 顧慮怎麼辦？

不要 production 接 DeepSeek 公開 API（資料出境問題）。用 開源權重 自己 host，或用台灣 / 香港的 cloud provider 提供的 inference endpoint。Qwen 開源版本 可以完全 on-prem，這個議題我在 本地 LLM 企業架構這篇 講得更完整。