你的語言用哪個 LLM 最便宜？實測 tokenizer 成本
目錄
多語言文字沒有一個永遠最便宜的 LLM。用同一段內容實測，歐洲語言、印地語和韓文由 GPT-5.5 計入的 token 最少，中文是 Kimi K2.5，日文則是 DeepSeek。Claude Fable 5、Opus 4.8 與 Sonnet 5 共用同一個 tokenizer，我們送出的所有樣本都得到完全相同的計數，而且從未是最精簡的選擇。同一段英文在 Claude 上計入 90 個原始 token，DeepSeek 只有 55 個；扣除固定開銷後，Claude 的額外用量從日文的 1.3x 到中文的 2.2x 不等。token 是計費單位，因此輸入成本取決於兩個定價頁面很少呈現的因素：一種語言每個字元能承載多少語意，以及各模型的 tokenizer 對該文字系統壓縮得多好。兩者相乘後，結果和單看每字元用量時的直覺不同。
TL;DR
- Claude Fable 5、Opus 4.8 與 Sonnet 5 共用同一個 tokenizer，而且從未最精簡：所有語言的 token 數都是最低值的 1.2-2.3x。
- 最省 token 的 tokenizer 會隨語言改變：歐洲語言、印地語和韓文是 GPT-5.5，中文是 Kimi，日文是 DeepSeek。
- 以每字元計算時，CJK 看起來貴了 3x；若改以相同語意比較，中文接近持平，日文和韓文則是 1.5-2.4x。
- 成本是文字系統密度乘以 tokenizer 覆蓋率；覆蓋不足會把成本進一步放大（GLM 的印地語 token 數是其英文的 4.9x）。
- 在地化通常不會省錢；應按各語言的 token 數選模型。
所有計數均於 2026-07-08 透過 Synthorai 閘道實測，且一律採用供應商自己的計數，不使用本機 tokenizer。每次重複測試的結果都完全相同。
計費單位是 token，不是文字
費用按 token 計算，但 token 既不是字元，也不是單字。每個模型都有自己的 tokenizer 和詞彙表，同一句話經過不同模型處理，會得到不同的 token 數。這個數字再乘上每 token 單價，因此有兩個變數會同時改變：文字會被切成多少 token，以及每個 token 的價格。
大多數定價頁面只列第二個數字。本文測量第一個。我們將三組語意對齊的段落送給七個模型（claude-fable-5、claude-opus-4-8、claude-sonnet-5、deepseek-v4-flash、glm-5.2、gpt-5.5、kimi-k2.5），再讀取各模型實際計入的輸入 token 數。
其中一段是輕鬆敘事，內容是週六逛市集的故事，共有九種語言版本；另外兩段分別是技術說明（使用指數退避重試）和新聞短訊（市政府預算表決），提供英文、中文、日文、韓文、德文和印地語版本。此外，測試集還包含一個 Python 函式與一段 JSON 工具呼叫資料。非英文版本由機器依照忠實翻譯、不得壓縮內容的指示產生，再經人工抽查。翻譯冗長程度確實會干擾結果，後文的語體章節將其影響範圍界定在約 20%。
計數一律以供應商回報值為準：Claude 系列透過實際的 Messages 呼叫讀取 usage.input_tokens，因為閘道目前不代理 count_tokens；OpenAI 相容模型則透過小型呼叫讀取 usage.prompt_tokens。這正是為了避免本機 tokenizer 與帳單不一致。測試中還有一項重要的控制變因：每個請求都會帶有固定框架，包括 chat template 和角色標記，約占數個 token。因此，我們先測量一個兩字元的基準樣本，再從結果中扣除。本文所有比率都已排除這層固定開銷，比較的是文字本身，而非請求框架。
同一段文字，五種 tokenizer
下表列出敘事段落在各語言、各 tokenizer 上的原始輸入 token 數。三個 Claude 模型共用一欄，因為它們在所有樣本上都回傳完全相同的計數，後文會再說明。其餘兩段呈現相同趨勢，稍後會納入分析。字元欄是各語言版本的長度。不同文字系統承載語意的密度不同，同樣的意思，中文只需 77 個字元，英文則需要 254 個。
| 語言 | 字元數 | fable-5 / opus-4-8 / sonnet-5 | deepseek-v4 | glm-5.2 | gpt-5.5 | kimi-k2.5 |
|---|---|---|---|---|---|---|
| en | 254 | 90 | 55 | 63 | 57 | 60 |
| zh | 77 | 96 | 50 | 58 | 69 | 50 |
| ja | 136 | 136 | 101 | 116 | 114 | 129 |
| ko | 143 | 160 | 104 | 123 | 93 | 129 |
| hi | 196 | 147 | 124 | 192 | 76 | 133 |
| de | 289 | 146 | 92 | 92 | 75 | 104 |
| fr | 259 | 111 | 76 | 79 | 66 | 93 |
| es | 253 | 112 | 75 | 79 | 66 | 91 |
| it | 272 | 127 | 84 | 91 | 78 | 100 |
有兩點很明顯。Claude 欄用一個數字代表三個模型，因為 Claude Fable 5、Opus 4.8 與 Sonnet 5 在所有樣本上都回傳相同的計數，不論語言、程式碼或 JSON 都一樣。三者都採用 Opus 4.7 引入的 tokenizer，因此其中一個模型的計數，也適用於另外兩個。除了印地語由 GLM 的 192 個 token 墊底之外，Claude 在每一列都是最大值。先扣除固定開銷，再將各語言最精簡的模型正規化為 1.00，結果如下。由於先扣除了固定框架，這些比率不會等於直接用上表的原始數字相除：
| 語言 | fable-5 / opus-4-8 / sonnet-5 | deepseek-v4 | glm-5.2 | gpt-5.5 | kimi-k2.5 |
|---|---|---|---|---|---|
| en | 1.64 | 1.00 | 1.00 | 1.00 | 1.00 |
| zh | 2.20 | 1.12 | 1.12 | 1.55 | 1.00 |
| ja | 1.33 | 1.00 | 1.07 | 1.11 | 1.24 |
| ko | 1.77 | 1.15 | 1.28 | 1.00 | 1.38 |
| hi | 2.01 | 1.72 | 2.59 | 1.00 | 1.78 |
| de | 2.03 | 1.28 | 1.16 | 1.00 | 1.38 |
| fr | 1.75 | 1.20 | 1.12 | 1.00 | 1.41 |
| es | 1.76 | 1.19 | 1.12 | 1.00 | 1.37 |
| it | 1.68 | 1.11 | 1.10 | 1.00 | 1.27 |
英文列的四家並列不是四捨五入造成的：DeepSeek、GLM、GPT-5.5 與 Kimi 在這段文字上都剛好是 50 個淨 token。這段測試中，Claude 的用量是最精簡 tokenizer 的 1.3x 至 2.2x；三段測試合計則是 1.2x 至 2.3x。這是詞彙表本身的特性，在模型的整個生命週期內都會影響每次呼叫。技術與新聞段落也呈現相同排序。兩段相加後，Claude 的中文為 212 個淨 token，Kimi 為 114 個（1.9x）；印地語則是 Claude 的 477 個對 GPT-5.5 的 210 個（2.3x）。但沒有任何模型能在所有語言中勝出。最精簡的模型會隨語言變化：
- GPT-5.5 在德文、法文、西班牙文、義大利文、印地語和韓文最精簡，英文則並列第一，其中並列結果與法文、西班牙文、義大利文的優勢只出現在敘事段落。它的詞彙表偏向拉丁文字，同時也能有效處理天城文和諺文。
- Kimi K2.5 的中文最精簡，在整體 CJK 語言中也有競爭力。
- DeepSeek-v4 的日文最精簡，中文也緊追在後。
- GLM 5.2 在大多數語言中位於中段，但印地語是整張矩陣中最差的結果：敘事段落為最精簡模型的 2.59x，GPT-5.5 只需 69 個淨 token，GLM 卻要 179 個；正式語體段落的差距更大。這也是唯一比 Claude 更差的一欄。
額外用量不只出現在一般文字。Python 函式測試中，Claude 是最精簡模型的 1.61x；JSON 工具呼叫則是 1.29x。JSON 的差距較小，因為結構化文字大多是標點符號和簡短的 ASCII key，各 tokenizer 的處理方式相近。如果長時間執行的 agent 每輪都要重新送出大型工具 schema，這項逐輪成本會不斷累積，此時快取就很有價值。prompt 快取系列文章深入說明了相關機制。
每字元比較的陷阱：CJK 看起來比實際帳單更貴
上面的表格比較不同模型。如果固定模型，只改變語言，token 數仍會變動，但走勢和原始字元數帶來的直覺不同。最常被引用的 tokenizer 指標是每字元 token 數，CJK 在這項指標上特別高：以 Claude 為例，每 100 個字元的淨 token 數，中文約為 114、韓文 106、日文 94，英文則是 32。只看這一欄，CJK 像是多了 3x 成本，但這個比較方式不對。付費對象是語意，不是字元，而對齊後的每個語言版本都承載相同意思。以下是 Claude 處理敘事段落時的兩種比較方式：
| 語言 | 字元數 | 淨 token 數 | 每 100 字元的 token 數 | 相對英文的 token 數 |
|---|---|---|---|---|
| en | 254 | 82 | 32 | 1.00 |
| zh | 77 | 88 | 114 | 1.07 |
| ko | 143 | 152 | 106 | 1.85 |
| ja | 136 | 128 | 94 | 1.56 |
| hi | 196 | 139 | 71 | 1.70 |
| de | 289 | 138 | 48 | 1.68 |
| it | 272 | 119 | 44 | 1.45 |
| es | 253 | 104 | 41 | 1.27 |
| fr | 259 | 103 | 40 | 1.26 |
右側兩欄得出的結論不同，中文尤其明顯：它的每字元 token 密度是整組最高，但以相同語意比較，這段內容只比英文多 1.07x。英文要用 254 個字元表達的內容，中文只需 77 個。較高的每字元用量乘上很少的字元數，兩者幾乎互相抵銷。三段內容合計後仍有相同效果，但並非完全抵銷：中文平均是 Claude 自身英文用量的 1.17x；依模型不同，範圍介於 0.95x 到 1.32x。結果接近持平，而不是每字元欄暗示的 3x。
日文和韓文呈現類似現象，但抵銷效果較弱。兩者的每字元 token 密度都很高，因為諺文和日文假名大致以一個字形表示一個音節，不像中文字能用一個漢字承載整個詞素。因此，中文用 77 個字元表達的段落，韓文需要 143 個，日文需要 136 個。更多字元乘上更高的每字元用量，不但沒有抵銷，反而疊加。以三段內容的相同語意比較，Claude 的韓文平均是英文的 1.96x，日文為 1.56x，兩者確實較貴，儘管它們的每字元數據看起來和中文相近。
德文正好與中文相反：每字元用量不高，為 48，接近英文；但它的字元數是所有語言中最多的 289 個，原因是德文複合詞，最後總量仍達 1.68x。成本是這兩個維度的乘積，單看任何一項都會產生誤判。
數字為何變動：兩個因素相乘
上述所有表格都可以用一條公式解釋：
一段文字的 token 數 =（表達相同語意所需的字元數）x（每字元 token 數）
第一個因素是文字系統的語意密度，屬於語言本身的特性，與模型無關。這不是中文獨有的例外，而是一段連續光譜。表意的中文每個字元都能承載一個詞素，位於高密度端。日文假名和韓文諺文主要拼寫語音，因此密度較低，需要更多字元。天城文和拉丁字母的密度又更低。從中文到英文，每字元承載的語意持續下降。
第二個因素是模型詞彙表處理該文字系統的每字元 token 成本，完全由模型決定。BPE tokenizer 會從訓練語料中學習多字元合併。經常出現的文字系統能取得較精簡的 token；較少見的文字系統則容易退化為逐字元甚至 byte-level 編碼，此時一個字元可能被拆成兩到三個 token。以下是相同三種語言的每字元淨 token 數：
| 每字元 token 數 | 中文 | 印地語 | 英文 |
|---|---|---|---|
| Claude | 1.14 | 0.71 | 0.32 |
| DeepSeek | 0.58 | 0.61 | 0.20 |
| GPT-5.5 | 0.81 | 0.35 | 0.20 |
| GLM 5.2 | 0.58 | 0.91 | 0.20 |
| Kimi K2.5 | 0.52 | 0.63 | 0.20 |
這張表可以解釋三件事。中文總量之所以特殊，是因為它在第一個因素上位於極端。即使 Claude 對中文的壓縮效果不佳，每字元要 1.14 個 token，部分漢字仍會被拆成兩個 token，但總共只有 77 個字元，最後用量仍不大。以中文語料為重點訓練的模型則能將其壓縮到 0.52 至 0.58，與各自的英文用量接近。印地語的額外成本來自第二個因素，而非文字密度。GLM 處理每個天城文字元要 0.91 個 token，幾乎是一字一 token，因為其詞彙表幾乎沒有多字元的天城文合併；GPT-5.5 能涵蓋完整音節群，因此只需 0.35。這是同一文字系統上的覆蓋率差距。Claude 在所有語言上都偏高，因為它連英文的每字元用量也高，為 0.32，DeepSeek 則是 0.20。這是模型本身的基準成本，還會再疊加各語言的影響。
這種現象並非這七個模型獨有。研究文獻稱之為 token premium。Petrov 等人（NeurIPS 2023）針對數百組語言配對進行測量，也找出相同的兩個根本原因：表達相同語意所需的字元數不同，以及 tokenizer 對不同文字系統的覆蓋程度不同。低資源語言的額外用量最高可達 15x，並帶來相同後果：成本更高、延遲更長、可用 context window 更小，因為高額外用量的語言會用較少語意填滿相同的 context 預算。隨著供應商持續投入，差距也在縮小。獨立實測顯示，相較於英文，GPT-3 時代的詞彙表會讓中文多出 +182% token，GPT-4o 則降至 +24%，接近我們在 GPT-5.5 測得的 +32%，也接近中文語料導向模型的持平結果。覆蓋率需要占用詞彙表空間，而供應商仍持續增加投入。
在地化真的能省錢嗎？
前面的陷阱很容易讓人得出兩個錯誤結論：「Claude 在各語言間差不多，所以不必考慮在地化」以及「中文模型處理中文便宜，所以在地化能省錢」。兩者都不正確。以下列出五種具備完整三段測試資料的語言，與各模型自身英文用量相比的平均值：
| 相對各自英文 | zh | de | hi | ja | ko |
|---|---|---|---|---|---|
| Claude | 1.17 | 2.11 | 2.40 | 1.56 | 1.96 |
| DeepSeek | 1.00 | 1.94 | 3.11 | 1.85 | 1.99 |
| GLM 5.2 | 1.03 | 1.77 | 4.89 | 2.03 | 2.31 |
| GPT-5.5 | 1.32 | 1.53 | 1.70 | 2.09 | 1.72 |
| Kimi K2.5 | 0.95 | 2.20 | 3.15 | 2.18 | 2.41 |
Claude 並非各語言都相同：韓文是其英文的 1.96x，印地語則是 2.40x。中文接近 1.17x 只是單一語言的巧合，不是模型的普遍特性。以中文語料為重點訓練的模型也不是大幅低於中文與英文持平線，而是剛好接近持平。整張表最好的結果是 Kimi 的 0.95x，只比自身英文低 5%；其他所有數值都等於或高於英文。同樣的模型在印地語、日文和韓文上的額外用量反而比 Claude 更大，因為這些文字系統離它們的訓練重點更遠。規律並不是「某家供應商比較省」，而是每個模型相對自身英文而言，最省的語言都最接近其訓練資料重心。
語體也會改變結果。輕鬆敘事是最有利的情境；技術和新聞段落會提高幾乎所有倍數，因為術語和外來語正是非拉丁文字詞彙表最缺乏合併的內容。Claude 的德文從輕鬆語體的 1.68x 升至技術語體的 2.29x，GLM 的印地語在新聞段落甚至達到其英文的 5.98x。只用一段文字做 benchmark，容易因某個語言剛好得到較自然、精簡的翻譯而偏高估其表現。單看敘事段落時，Kimi 的中文是 0.80x；加入三段內容後則是 0.95x。
拿各模型與自身英文比較，本來就不是正確的成本視角。實際付費取決於絕對 token 數，而 Claude 在九種語言中有八種最貴，唯一更差的是 GLM 的印地語。中文內容「相對 Claude 的英文很便宜」，不代表實際就便宜。在敘事段落中，Claude 需要 88 個淨 token，Kimi 只需 40 個。因此，正確做法不是為了省錢而在地化，而是按語言選模型：中文選 Kimi 或 DeepSeek、印地語和韓文選 GPT-5.5、日文選 DeepSeek。Claude 在任何語言都不是 token 成本最低的選擇，但仍可能在品質上勝出。
token 數只占帳單的一半
token 倍數必須搭配每 token 單價才有意義，兩者會相乘。Claude Fable 5 的標價是每百萬輸入 token $10，Opus 4.8 是 $5，Sonnet 5 在優惠期結束後是 $3。中文方面，它們共用的 tokenizer 還會計入最精簡模型 2.2x 的 token，因此計數差距會再乘上該模型相對替代路由的費率差距。相反情況也可能發生：某個模型計數很精簡，但因單價較高，每次呼叫仍更貴。只看任何一個數字，都無法判斷帳單。本文沒有列出其他供應商的費率，因為價格變動速度比 tokenizer 快；上面的計數才是較持久的一半資料。
實務上不要只比較牌價，應比較有效輸入成本：用各候選模型計算實際流量組成的 token 數，再乘以該模型的輸入費率。對中文或韓文流量占比較高的產品，這可能直接改變最便宜模型的排序，而且差距是持續存在的 1.5x 到 2x，不是四捨五入誤差。快取也是同樣道理。真正重要的是按命中率加權後的有效成本，而非標示費率；供應商比較有完整推導。至於不同版本間的差異，以及 Sonnet 5 為何對同一段英文計入的 token 比 Sonnet 4.6 多 41%，可參考 Sonnet 5 tokenizer 文章。
結論
- token 成本是文字系統密度乘以 tokenizer 覆蓋率。第一個因素由語言決定，第二個由模型決定；單看任何一項都會誤判。
- Claude Fable 5、Opus 4.8 與 Sonnet 5 在所有語言中都是最精簡模型的 1.2x 至 2.3x，因為它們連英文的每字元用量都偏高。
- 最精簡的模型因語言而異：歐洲語言、印地語和韓文選 GPT-5.5，中文選 Kimi，日文選 DeepSeek。GLM 對印地語的表現最差，幾乎每字元一個 token。
- 正式與技術語體會提高幾乎所有語言的倍數；benchmark 應使用實際上線內容的語體。
- 不要為了省錢而在地化；先按絕對 token 數為語言選模型，再乘上各模型費率，比較有效成本。
常見問題
哪個 LLM tokenizer 最便宜？ 取決於語言。以相同且語意對齊的段落比較七個模型，GPT-5.5 在歐洲語言、印地語和韓文最精簡，英文並列第一；中文是 Kimi K2.5，日文是 DeepSeek-v4。Claude 系列（Fable 5、Opus 4.8、Sonnet 5）從未最精簡，在所有語言與語體中，token 數都是最低值的 1.2x 至 2.3x。
Claude Fable 5、Opus 4.8 與 Sonnet 5 使用同一個 tokenizer 嗎？ 是。三個模型在所有樣本上都產生完全相同的 token 數，不論語言、程式碼或 JSON 都一樣。它們採用 Opus 4.7 引入的 tokenizer，因此其中一個模型的計數可直接套用到另外兩個；Fable 5 帳單較高，完全來自其每 token 單價。
Claude 處理中文比英文貴嗎？ 略貴。以三段相同語意的內容取平均，中文是英文的 1.17x；以中文語料為重點訓練的模型則大致持平。按每字元比較時，差距看起來大得多：每 100 個中文字約有 114 個淨 token，英文只有 32 個。但中文大約只需三分之一的字元就能表達相同意思，因此總量幾乎互相抵銷。
日文和韓文的情況與中文相同嗎？ 只有一半相同。它們和中文一樣具有較高的每字元 token 密度，但諺文和假名主要用來拼寫語音，因此表達相同段落需要更多字元：日文 136 個、韓文 143 個，中文只有 77 個。高昂的每字元用量無法再被字元數抵銷。按相同語意計算，Claude 的日文約為英文的 1.6x，韓文約為 2x；七個模型的整體範圍則是 1.5x 至 2.4x。
如何針對自己的 prompt 測量？ 挑選幾個實際使用、語體也與正式環境相同的 prompt，送給各候選模型，並從 usage 欄位讀取供應商自己的輸入 token 計數，不要依賴本機 tokenizer。一段較容易處理的內容可能讓某個語言的結果看起來好上約 20%，因此應測試多個樣本。最後將各項計數乘以對應模型的輸入價格，就能算出實際流量的有效成本。