哪個 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 個，扣掉框架後的溢價從日文的 1.3 倍一路到中文的 2.2 倍。計費單位是 token，所以有兩件在定價頁面上很少看到的事決定了你的輸入成本：一個語言把意思塞進字元的密度有多高，以及每個模型的 tokenizer 對那套文字系統壓縮得有多好。這兩者相乘，結果和單看每字元的觀點得出的預期並不一樣。

TL;DR

• Claude Fable 5、Opus 4.8 和 Sonnet 5 共用同一套 tokenizer，從來不是最省的：各種情況下都是最低計數的 1.2 到 2.3 倍。
• 最省的 tokenizer 會隨語言翻盤：歐洲語言、印地語、韓語是 GPT-5.5；中文是 Kimi；日文是 DeepSeek。
• 以每字元來看，CJK 看起來差 3 倍，但以每個意思來看，中文接近打平，日文和韓語則是 1.5 到 2.4 倍。
• 成本等於文字系統密度乘上 tokenizer 覆蓋度；覆蓋不足會把成本放大（GLM 對印地語計費是其英文的 4.9 倍）。
• 做在地化很少省到錢；該做的是按 token 把模型和語言配對。

計數是 2026-07-08 透過 Synthorai 閘道實測的，一律採用各供應商自己的計數，不用本地 tokenizer。每次重複測的計數都完全一致。

計費單位是 token，不是文字本身

你是按 token 計費，但 token 既不是字元也不是單詞。每個模型都自帶一套 tokenizer 和自己的詞彙表，同一句話在每套上會解析成不同的 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 數。

一段生活化的敘事（一個週六市集的故事）有九種語言的版本；一段技術說明（用 exponential backoff 做重試）和一則新聞短訊（某市預算表決）有英文、中文、日文、韓文、德文和印地語版本。再加上一個 Python 函式和一段 JSON 工具呼叫的內容，湊成整組樣本。非英文版本是在忠實、不壓縮的指示下產出的機器翻譯，並人工抽查過；翻譯的冗長度是個真實的干擾因素，下面的語域一節把它的範圍框在大約 20%。

計數一律採用供應商自己的：Claude 這條線是透過真正的 Messages 呼叫讀 usage.input_tokens（閘道目前不代理 count_tokens），OpenAI 相容的模型則是透過一個小呼叫讀 usage.prompt_tokens。本地 tokenizer 和帳單對不上，正是這種做法要避免的失誤。有一個對照很重要：每個請求都帶著固定的框架（chat template、role 標記），值幾個 token，所以我們測一個兩字元的基準樣本再把它扣掉。這篇文章裡的每個比值都已經扣掉這層外框，比的是文字本身，不是框架。

同一段文字，五種 tokenizer

以下是那段敘事文字的原始輸入 token 數，依語言、依 tokenizer 分別列出。三個 Claude 模型共用一欄，因為它們在每個樣本上回傳的數字都完全相同（稍後細說）。另外兩段文字也呈現同樣的模式，往下會併進來。字元欄是各語言版本的長度；不同文字系統打包意義的密度不同，英文要用 254 個字元表達的內容，中文只用 77 個字元就說完了。

有兩件事很明顯。Claude 欄之所以三個模型只有一個數字，是因為 Claude Fable 5、Opus 4.8、Sonnet 5 在每個樣本上回傳的數字都一樣，不管是各種語言、程式碼還是 JSON：三者都採用 Opus 4.7 引進的那套 tokenizer，所以算一個就等於算了全部。而且除了印地語那一列，這一欄在每一列都是最大的；印地語則是 GLM 的 192 更糟。以淨 token 數做正規化，讓每種語言最精簡的模型讀作 1.00（先扣掉外層封裝，所以這些比值不會等於上面原始儲存格相除的結果）：

英文那一列的四方並列不是四捨五入湊出來的：DeepSeek、GLM、GPT-5.5、Kimi 在這段文字上都剛好是 50 個淨 token。在這段文字上，Claude 是最精簡 tokenizer 的 1.3 到 2.2 倍，三段合計則是 1.2 到 2.3 倍。這是詞彙表本身的特性，模型生命週期內的每一次呼叫都適用。技術段和新聞段也重現了同樣的排名：兩段相加，中文 Claude 算出 212 個淨 token，Kimi 只要 114（1.9 倍）；印地語 Claude 是 477，GPT-5.5 只要 210（2.3 倍）。不過底下並沒有單一的贏家。最精簡那一欄會隨語言變動：

• GPT-5.5 在德語、法語、西班牙語、義大利語、印地語、韓語上最精簡，英語則並列最精簡（並列以及 fr/es/it 只在敘事段成立）。它的詞彙表偏向拉丁文字調校，在天城文和諺文上也撐得住。
• Kimi K2.5 在中文上最精簡，整個 CJK 都有競爭力。
• DeepSeek-v4 在日語上最精簡，中文則緊追在後。
• GLM 5.2 在多數語言上居中，但在印地語上跑出整個矩陣最差的儲存格：敘事段是最精簡的 2.59 倍（GPT-5.5 只要 69 個淨 token，它要 179 個），在正式段落上更糟，也是唯一超越 Claude 的一欄。

這種代價不限於散文。在那段 Python 函式上，Claude 是最精簡的 1.61 倍，JSON 工具呼叫則是 1.29 倍。JSON 的差距比較小，因為結構化文字大多是標點和短的 ASCII 鍵名，各家 tokenizer 處理起來差不多。對一個每一輪都重播龐大工具 schema 的長時間執行 agent 來說，這種每輪的稅會累積，快取也就是在這裡發揮價值。這些機制在prompt caching 系列有詳細說明。

逐字元的陷阱：CJK 看起來比實際計費更糟

上面的表格是拿不同模型來比。這次反過來，把模型固定住，語言依然會影響 token 數，但影響的方式跟從原始字元數看到的不一樣。最常被引用的 tokenizer 指標是每字元 token 數，而 CJK 在這項上遙遙領先：在 Claude 上，中文大約每 100 字元 114 個淨 token，韓文 106，日文 94，英文則只有 32。只看這一欄，CJK 看起來像是 3 倍的稅，但這是錯的欄位：你付的是意義的錢，不是字元的錢，而對齊過的段落在每種語言裡承載的是相同的意義。以下是敘事段落在 Claude 上的兩種視角：

右邊兩欄講的是完全不同的故事，而中文是最極端的例子：全組裡每字元密度最高，但在這個段落上每意義只比英文貴 1.07 倍。英文要用 254 個字元表達的東西，中文只用 77 個字元就講完了，於是高昂的每字元費率乘上極少的字元數，兩者幾乎互相抵銷。三個段落合起來看，這個抵銷效果依然成立，但也不是萬靈丹：中文平均是 Claude 自家英文的 1.17 倍，依模型不同落在 0.95 倍到 1.32 倍之間，接近持平，而不是每字元那一欄所暗示的 3 倍。

日文和韓文回答了接下來最自然的問題：同樣的錯覺，但抵銷得沒那麼徹底。兩者都有很高的每字元密度，因為韓文諺文和日文假名大致是一個字元對應一個音節地拼出讀音，而不是像中文漢字那樣把整個詞塞進單一字元。所以中文用 77 個字元講完的段落，韓文要 143 個字元、日文要 136 個。字元數多再乘上高每字元費率，結果不是抵銷而是疊加：在 Claude 上，三個段落平均下來，韓文每意義是英文的 1.96 倍，日文是 1.56 倍，兩者都是實打實地貴，即使它們的每字元欄位看起來跟中文很像。

德文則是中文的鏡像：每字元費率很低（48，接近英文），但字元數是全組最多的（289，因為它的複合字），總計仍是 1.68 倍。成本是這兩個軸的乘積，單看任何一個都會誤導。

為什麼數字會變動：兩個因素相乘

上面每張表格背後的規則，都可以歸結為一條算式：

一段文字的 token 數 = （表達語意所需的字元數）×（每個字元的 token 數）

第一個因素是書寫系統的密度，這是語言本身的特性，跟模型無關。它是一段連續的光譜，而不是中文獨有的例外。中文屬於語素文字，每個字元塞進一個語素，密度居於極端。日文的假名和韓文的諺文是把發音拼出來，密度較低，需要更多字元。天城文和拉丁字母的密度又更低。從中文到英文，每個字元承載的語意逐步遞減。

第二個因素是模型的詞彙表在該書寫系統的每個字元上花掉多少 token，這完全取決於模型本身。BPE tokenizer 會從訓練語料中學到多字元的合併規則：常見的書寫系統會得到較精簡的 token，罕見的則退回逐字元甚至位元組層級的編碼，此時一個字元可能變成兩三個 token。同樣這三種語言，每個字元的淨 token 數如下：

這張表說明了三件事。中文在總量上看起來特別，是因為它在第一個因素上處於極端：即使是 Claude 對中文的壓縮偏弱（每字元 1.14 個 token，仍會把部分漢字拆成兩個），在只有 77 個字元的情況下也拉不出多大的總量；而中國訓練的模型壓縮得夠好（0.52 到 0.58），總量落在跟它們自己的英文相當的水準。印地語的溢價來自第二個因素，不是密度：GLM 每個天城文字元花 0.91 個 token，幾乎是一字元一 token，因為它的詞彙表幾乎沒有多字元的天城文合併規則；而 GPT-5.5 只花 0.35，因為它涵蓋了整個音節叢集，這是同一種書寫系統上的涵蓋差距。Claude 則是到處都高，因為它連英文的每字元 token 數都偏高（0.32，DeepSeek 是 0.20），這是模型層級的基線，會疊加在語言本身造成的效果之上。

這些現象都不是我們這七個模型的怪癖。研究文獻把它稱為 token 溢價，Petrov 等人（NeurIPS 2023） 在數百組語言配對上做了量測，找出同樣的兩個根本原因（同樣的語意所需字元數不同，tokenizer 對不同書寫系統的涵蓋度不同），並發現低資源語言的溢價可高達 15 倍，帶來的後果也一致：成本更高、延遲更高、可用的 context window 更少，因為高溢價語言在同樣的 context 額度裡塞進的語意更少。這個差距也會隨著廠商投入而縮小：獨立量測 顯示，在 GPT-3 時代的詞彙表上中文比英文多 +182% 的 token，到了 GPT-4o 則是 +24%，跟我們在 GPT-5.5 上量到的 +32% 以及在中國訓練模型上量到的持平相當接近。涵蓋度是用詞彙表的名額換來的，而廠商還在持續投入。

在地化真能省錢嗎？

看完前面的陷阱那一節，很容易得出兩個結論：「Claude 在各語言之間都持平，所以不必管在地化」，還有「中國模型處理中文很便宜，所以在地化能省錢」。這兩個結論都是錯的。以下是每個語言相對於該模型自身英文的比值，取三段文本的平均，只列出三段都齊全的五種語言：

Claude 並不持平：韓文是自身英文的 1.96 倍，印地文 2.40 倍。中文落在 1.17 倍附近只是單一語言的巧合，不是模型的特性。而中國模型在中文上也不是真的比英文更省，只是打平而已：整張表最低的一格是 Kimi 的 0.95 倍，比自身英文低五個百分點，其餘每一格都是持平或更高。在印地文、日文、韓文上，這些模型的懲罰反而比 Claude 更重，不是更輕，因為這些文字離它們的訓練重心更遠。真正的規律不是「某家模型便宜」，而是每個模型相對於自身英文最省的，都是離它訓練資料最近的語言。

語體也會左右這些數字。輕鬆的敘事文是最友善的情況；技術文和新聞文幾乎會拉高每一個倍率，因為術語和外來詞正是非拉丁詞彙缺乏合併切分的地方。德文在 Claude 上從 1.68 倍（敘事）升到 2.29 倍（技術），GLM 的印地文在新聞文上更達到自身英文的 5.98 倍。只用一段文本做基準測試，會對拿到最友善譯文的那種語言特別討好，這也是為什麼單獨那段敘事文把中文在 Kimi 上壓到 0.80 倍，而三段合起來卻是 0.95 倍。

不過拿自身英文當基準本來就是錯的視角。你實際付的是絕對 token 數，而在這個維度上，Claude 在九種語言中有八種是最貴的，只有 GLM 的印地文那一欄更差。所謂「相對於 Claude 英文很便宜」的中文內容，在敘事文上 Claude 仍要 88 個淨 token，Kimi 只要 40 個。所以正確的做法不是為了省錢去做在地化，而是把模型配對到語言：中文用 Kimi 或 DeepSeek，印地文和韓文用 GPT-5.5，日文用 DeepSeek。Claude 在任何語言上都不是 token 成本的贏家，儘管它在品質上或許仍能勝出。

用量只是帳單的一半

token 倍率只有放在每個 token 的單價旁邊才有意義，而且兩者會相乘放大。Claude Fable 5 的輸入單價是每百萬 token 10 美元，Opus 4.8 是 5 美元，Sonnet 5 在導入期優惠結束後是 3 美元；在中文上，它們共用的 tokenizer 計出的 token 數是最精簡模型的 2.2 倍，所以這個計數溢價會把模型本身相對於你原本會選的替代方案的費率差距再乘上一層。反過來也會發生：某個模型即使 token 計得少，只要費率高，每次呼叫還是可能更貴。單看任何一個數字都算不出帳單。這裡不列其他供應商的費率，因為費率變動的速度比 tokenizer 快；上面的計數才是這道計算裡不會過時的那一半。

實務上該做的是別再比對外標價，改比有效輸入成本：拿你真實的流量組合，在每個候選模型上分別計數，再乘上該模型的輸入費率。在中文或韓文比重高的產品上，這樣重新排序可能會翻轉哪個模型最便宜，而且差距是穩定的 1.5 到 2 倍，不是誤差範圍。這跟做快取時真正重要的數字是「以命中率加權的有效成本」而非表定費率，是同一個道理，供應商比較裡有完整推演。這個故事在版本間的差異，也就是為什麼 Sonnet 5 在同一段英文上比 Sonnet 4.6 多計 41% 的 token，在 Sonnet 5 tokenizer 一文裡有說明。

結論

• token 成本等於書寫系統密度乘以 tokenizer 的覆蓋能力。語言決定第一項，模型決定第二項，單看任一項都會誤導判斷。
• Claude Fable 5、Opus 4.8 和 Sonnet 5 在每種語言上都是最精簡模型的 1.2 到 2.3 倍，因為它們就連在英文上的每字元費率都偏高。
• 最精簡的模型會隨語言而不同：歐洲語言、印地語和韓語是 GPT-5.5，中文是 Kimi，日文是 DeepSeek。GLM 在印地語上最弱，逼近每字元一個 token。
• 正式和技術性的語體幾乎在每種語言上都會拉高倍率；請用你實際上線的語體來做基準測試。
• 別為了省錢做在地化；先以絕對 token 數把模型對應到語言，再乘上各模型的費率去比較有效成本。

常見問題

哪一種 LLM 分詞器最便宜？ 要看語言。在同一批對齊過的段落上測試七個模型，GPT-5.5 在歐洲語言、印地語和韓語上最省（英語則與其他模型並列），Kimi K2.5 在中文上最省，DeepSeek-v4 在日語上最省。Claude 系列（Fable 5、Opus 4.8、Sonnet 5）從來不是最省的，在每一種語言和語域下都是最省權杖數的 1.2 到 2.3 倍。

Claude Fable 5、Opus 4.8 和 Sonnet 5 用的是同一個分詞器嗎？ 是的。這三個模型在每一個樣本、每一種語言、程式碼和 JSON 上都產生完全相同的權杖數。它們用的是 Opus 4.7 引入的那個分詞器，所以在其中一個上算出來的結果可以直接套到另外兩個上。Fable 5 帳單較高，完全是因為它每個權杖的價格較貴。

在 Claude 上中文比英文貴嗎？ 稍微貴一點：以三段文字平均，同樣的語意下是英文的 1.17 倍（在中國訓練的模型上則大致持平）。若按字元算差距看起來大得多（每 100 個中文字約 114 個淨權杖，英文只有 32 個），但中文用大約三分之一的字元就能表達同樣的意思，兩者幾乎相互抵消。

日語和韓語的表現跟中文一樣嗎？ 只對了一半。它們和中文一樣有很高的每字元密度，但諺文和假名是把發音拼寫出來，所以同一段文字需要多得多的字元（日語 136、韓語 143，中文則是 77）。這時高昂的每字元費率就無法抵消了，因此在 Claude 上以語意計，日語約為英文的 1.6 倍，韓語約 2 倍；在七個模型間則落在 1.5 到 2.4 倍之間。

我要怎麼針對自己的 prompt 測量這個？ 用你實際上線的語域，把幾個真實 prompt 發給每個候選模型，然後從 usage 欄位讀取供應商自己回報的輸入權杖數，別依賴本地分詞器。單一段友善的文字可能讓某種語言的數字漂亮約 20%，所以要多測幾段。接著把每個權杖數乘上該模型的輸入價格，就能得出你實際流量上的有效成本。

← 返回部落格