「中文比英文省 token」是網路上流傳很廣的說法。直覺上也合理——漢字資訊密度高、一個字承載的語義等於英文好幾個字母，tokenizer 理論上應該給中文更好的處理。
這個直覺到底準不準？我們用 OpenAI 官方 tiktoken 實測了六種不同類型的任務（短指令、商業文章、翻譯、企劃書、程式註解、創意文案），結果是——
同樣語義的內容，中文在現代 LLM 上比英文多吃 1.1–1.6x token，日文更慘多 1.3–2.2x。
這篇把完整實測數據、各家 tokenizer 表現、直覺出錯的原因、實務建議一次攤開。
🏆 懶人包
🔤 同樣意思，哪種語言吃更多 token？（以 o200k_base / GPT-4o、GPT-5 實測中位數為基準）
排名 語言 相對英文倍數 🥇 英文 1.0x（基準） 🥈 中文 1.34x 🥉 日文 1.73x 4 韓文 ~2.0x 一句話總結：CJK 一律多吃 token，中文多約 30%、日文多約 70%。token 多少會直接反映在 API 帳單上——prompt caching 和 batch API 能壓縮絕對金額，但不會翻轉這個排名。真要壓中文成本，請看內文 各廠牌 tokenizer 速查—— DeepSeek / Qwen 是目前唯一中文接近 1.0x 的 tokenizer。
5 個關鍵實測結論
- CJK 比英文多吃 token——現代 o200k_base（GPT-4o / GPT-5）：中文 1.1–1.6x、日文 1.3–2.2x；舊 cl100k_base（GPT-4 / Claude 3）：中文 1.6–2.5x、日文 1.7–2.9x
- 任務類型影響很大——短指令幾乎打平，長段商業文章 / 企劃書差距拉到 1.5–2.2x
- tokenizer 世代差巨大——o200k_base 把 CJK 懲罰砍掉約 40%，是真正的工程進步
- 日文一律比中文更吃 token——平假名 / 片假名拖累，沒有任何任務反例
- 唯一中文反超英文的 tokenizer：DeepSeek / Qwen 針對中文特別優化，接近 1.0x
🔍 為什麼會有「中文省 token」的直覺？
先講為什麼這個說法聽起來合理，再講為什麼實測結果相反。
讓人相信 CJK 省 token 的三個線索
1. 漢字的資訊密度確實高
一個「學」字相當於英文 “learn” / “study” / “scholarship” 等多種意義的基礎——單字元承載的語義量的確大於拼音文字。直覺推論：tokenizer 應該要給中文更好的處理。
2. 字元數確實少
同一篇文章，中文版的字元數往往只有英文版的 35–45%。當你肉眼比較長度時，中文看起來「短很多」，很容易等號到「token 數也少」。
3. 部分短句對比的確顯示中文領先
如果你隨手挑一兩個例子測，例如：
EN: "Summarize this article in bullets" (6 tokens)
ZH: 「條列摘要這篇文章」(5 tokens)中文看起來確實省——於是結論就這樣傳開了。
為什麼這些直覺不準？
問題在於實際的 tokenizer 行為和直覺的語義密度沒對上：
-
漢字的資訊密度優勢被吃掉了——tokenizer 把大多數漢字切成獨立的 1 個 token，單字元的語義密度不會讓它占用「比較少的 token」，只會讓它占用「同一個 token 空間但承載更多意義」。這個差異對 context window 有利，但對 API 帳單沒幫助。
-
字元數 ≠ token 數——英文「learn」5 字元但通常 1 個 token（tokenizer 合併了常見單字），中文「學」1 字元也是 1 個 token——英文的 tokenizer 壓縮率遠高於中文。
-
短句的個案不是大樣本代表——一兩個範例可能遇到 tokenizer 對特定片語的優化，但跨任務的平均值說話更準確。
實證：200 萬句大樣本研究
研究者用 200 萬句專業人工翻譯對照英文與各語言的 token 數：
| 語言（對英文基準） | 平均 token 倍數 |
|---|---|
| 英文 | 1.0x（基準） |
| 中文（Mandarin） | 1.76x |
| 粵語 | 2.10x |
| 日文 | 2.12x |
| 韓文 | 2.36x |
CJK 全部多吃 token，沒有例外。
🧪 六項任務實測：用 tiktoken 跑出來的真實數字
以下是本站用 OpenAI 官方 tiktoken 函式庫實測的結果，涵蓋現代模型實際使用的兩個 tokenizer：
- cl100k_base：GPT-4、Claude 3 系列、早期 GPT-3.5
- o200k_base：GPT-4o、GPT-5 系列、目前最新 OpenAI 主線
Task 1：短指令 prompt
EN: "Summarize this article and list the top 5 key takeaways in bullet points."
ZH: 「摘要這篇文章，並以條列式列出前 5 個重點。」
JA: 「この記事を要約し、重要なポイントを5つ箇条書きで挙げてください。」| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 18 | 29 | 31 | 1.61x | 1.72x |
| o200k_base | 18 | 19 | 24 | 1.06x | 1.33x |
短指令是 CJK 差距最小的情境——o200k 上中文幾乎打平。
Task 2：商業文章段落
EN: "Large language models have transformed how enterprises process unstructured text..."
（5 句完整段落，討論 LLM 對企業的影響）| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 69 | 174 | 202 | 2.52x | 2.93x |
| o200k_base | 69 | 107 | 150 | 1.55x | 2.17x |
這是最吃 token 的情境——長段落的商業文字在 cl100k_base 上差距拉到近 3x。
Task 3：翻譯任務（業績報告）
EN: "Q3 Sales Report: Revenue grew 23% year-over-year to $4.2M..."| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 56 | 120 | 139 | 2.14x | 2.48x |
| o200k_base | 56 | 79 | 101 | 1.41x | 1.80x |
Task 4：專案企劃書
EN: "Project Proposal: AI-powered customer service automation..."| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 90 | 177 | 197 | 1.97x | 2.19x |
| o200k_base | 89 | 119 | 145 | 1.34x | 1.63x |
Task 5：程式註解
EN: "# Retry the API call with exponential backoff..."| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 22 | 46 | 54 | 2.09x | 2.45x |
| o200k_base | 22 | 29 | 41 | 1.32x | 1.86x |
Task 6：創意文案
EN: "Imagine a world where your smartphone truly understands you..."| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 46 | 99 | 100 | 2.15x | 2.17x |
| o200k_base | 44 | 60 | 70 | 1.36x | 1.59x |
📊 六任務總結：真正的倍數分布
| 情境 | cl100k_base 中文倍數 | cl100k_base 日文倍數 | o200k_base 中文倍數 | o200k_base 日文倍數 |
|---|---|---|---|---|
| 最低 | 1.61x | 1.72x | 1.06x | 1.33x |
| 最高 | 2.52x | 2.93x | 1.55x | 2.17x |
| 平均 | 2.08x | 2.32x | 1.34x | 1.73x |
可以直接記住的粗估：
- 在 GPT-4 / Claude 3 上，中文 ≈ 2x 英文 token、日文 ≈ 2.3x
- 在 GPT-4o / GPT-5 上，中文 ≈ 1.3x 英文 token、日文 ≈ 1.7x
🧮 實測細節：中文字元少，但 token 反而多
這是最反直覺的部分——用 Task 2 和 Task 4 的實測數字驗證：
| 任務 | 英文字元 | 中文字元 | 字元比 | o200k token 比 |
|---|---|---|---|---|
| Task 2 商業文章 | 371 | 136 | 0.37x | 1.55x |
| Task 4 企劃書 | 342 | 141 | 0.41x | 1.34x |
中文字元只有英文的 37–41%，但 token 數反而多 34–55%。原因：
英文 tokenizer 會合併常見單字——“the”、“of”、“transformation”、“enterprise” 各自只占 1–2 個 token（儘管字元很多）。英文的平均每 token 字元數（CPT）約 5.4。
中文 tokenizer 幾乎不合併——每個漢字基本上就是 1 個 token，甚至有些漢字被切成 2 個 byte 片段。中文的平均每 token 字元數約 0.9–1.0。
這個 5.4x 的壓縮率差距，壓倒了漢字「字元少」的優勢——最終結果就是中文的 token 數反而更多。
不等價翻譯的陷阱
網路上流傳的「中文省 token」範例，經常來自不夠嚴謹的翻譯對照：
EN: "Summarize the following article and extract the top 5 key points in bullet format" (15 tokens)
ZH: 「摘要以下文章，並以條列式提取前 5 個重點」(9 tokens)中文看似省 40%——但中文版省略了「in bullet format」、縮短了動詞。這不是 tokenizer 效率，是翻譯風格差異。本文所有 Task 都使用盡可能語義等價的翻譯，確保比較公平。
📈 tokenizer 世代差異：o200k_base 是真正的進步
從 cl100k_base 到 o200k_base，OpenAI 把 CJK 懲罰削減約 40%——這是實打實的工程改進。
| 語言 | cl100k 平均倍數 | o200k 平均倍數 | 改善幅度 |
|---|---|---|---|
| 英文 | 1.00x | 1.00x | — |
| 中文 | 2.08x | 1.34x | -36% |
| 日文 | 2.32x | 1.73x | -25% |
⚠️ 反向案例：Claude Opus 4.7 2026/4/16 發布的 Claude Opus 4.7 換了新 tokenizer，官方揭露 CJK token 消耗比前代增加 15–35%——tokenizer 改版有時會倒退。你不能假設「新模型 = CJK 更省」。
🆚 各廠牌 tokenizer 三語言效率速查（2026/4 月）
CJK 用更多 token 是共通現象，但廠牌間差異仍然顯著。以下是各家實測中位數：
比較單位說明
這張表用的指標和前面不同——用字元 / token（CPT） 看「同語言內廠牌差異」（幫你選廠牌）。前面的倍數表看「同內容不同語言比例」（幫你估成本）。兩個指標互補，不能混用。
| Tokenizer | 英文 CPT | 中文 CPT | 日文 CPT | 中文效率排名 |
|---|---|---|---|---|
| DeepSeek V3 / V4 | ~5.0 | ~1.1–1.2 | ~0.9 | 🥇 最省中文 |
| Qwen 系列 | ~4.8 | ~1.1–1.3 | ~0.9 | 🥇 最省中文 |
| GPT-4o / o200k_base | ~5.4 | ~1.0–1.3 | ~0.9–1.3 | 🥈 |
| Gemini 3.x | ~5.5 | ~1.0 | ~0.82 | 🥉 |
| Llama 3 系列 | ~5.3 | ~1.0 | ~0.8 | 🥉 |
| Claude Opus 4.6 | ~5.5 | ~1.0–1.1 | ~0.9 | 🥉 |
| GPT-4 / cl100k_base | ~5.4 | ~0.7–0.8 | ~0.9–1.0 | ❌ 最耗中文 |
| Claude Opus 4.7 | ~5.5 | ~0.75–0.9 | ~0.7–0.8 | ❌ 最耗中文 |
關鍵觀察：
- 🇨🇳 中文效率：只有 DeepSeek / Qwen 兩家達到 CPT > 1.0（等於 1 個中文字 < 1 個 token），其他家都還是 1 個中文字 ≈ 1 個 token 或更差
- 🇯🇵 日文效率：各家差異不大，沒人認真優化
- 🇺🇸 英文效率：全部在 4.8–5.5 區間，差異很小
🎯 CJK 也不是全輸——三個仍然有優勢的面向
CJK 多吃 token 是事實，但不等於「用中文做 AI 就虧」。有三個反向效應值得知道：
1. Context window 裝得下更多「資訊」
雖然同語義的 token 數較多，但字元數少仍然是優勢——尤其當你想把一整本書、一整份合約塞進去時，中文版占據的字元空間小得多，即使 token 多一些，仍在 context 限制內。
例：Claude Opus 4.7 的 1M context
| 語言 | 平均每 token 字元 | 1M tokens 能塞多少字 |
|---|---|---|
| 英文 | ~5.4 | ~540 萬字元 |
| 中文 | ~0.85 | ~85 萬字元 |
85 萬字的中文相當於約 3–4 本標準小說。如果以「意思總量」來看，中文版塞下的資訊量可能不亞於 540 萬字元的英文。
2. 短指令幾乎打平
Task 1 顯示短指令型 prompt 上（<25 token），中文只多 6%、日文多 33%——如果你的應用是大量短對話（客服、搜尋、簡單工具呼叫），CJK 的成本劣勢很輕微。
3. 中文專用模型可以反超
DeepSeek V4 中文 CPT 約 1.1–1.2，已經比其他家的英文 token 密度接近了。加上 DeepSeek 單價是西方模型的 1/10–1/50，對中文應用來說，總成本可能比 GPT-4o 還低。
💰 真實成本差多少？月度試算
假設你跑一個中文客服應用，每月處理 100 萬筆對話，平均每筆輸入 200 字（中文）、輸出 150 字（中文）。
| 模型 | ZH 輸入 token（每筆） | ZH 輸出 token（每筆） | 月總 token | 單價（$/M in / out） | 月費 |
|---|---|---|---|---|---|
| GPT-4o | ~250 | ~190 | 2.5B in / 1.9B out | $2.5 / $10 | $25,250 |
| Claude Opus 4.7 | ~280 | ~220 | 2.8B in / 2.2B out | $5 / $25 | $69,000 |
| DeepSeek V4 | ~180 | ~140 | 1.8B in / 1.4B out | $0.28 / $0.42 | $1,092 |
| Qwen-Max | ~180 | ~140 | 1.8B in / 1.4B out | ~$0.5 / $2 | $2,700 |
同樣中文應用，DeepSeek 比 Claude Opus 4.7 便宜約 60 倍。 當然品質不在同一個水準，這只是說明「tokenizer 效率 × 單價」的綜合差距到底有多大。
🧠 看似聰明的反面教材：「翻譯雙跑」策略
既然英文省 token，CJK 使用者直覺會想到一個聰明策略：
「先讓 AI 把我的中文 prompt 翻成英文 → 用英文執行任務 → 最後再把輸出翻回中文」
聽起來合理，實測幾乎都更貴。 原因：你多付了兩次翻譯的錢，而這兩次翻譯本身也是用 token 算的。
試算：長文件分析
分析一份 50,000 字的中文報告，比較兩種流程：
| 步驟 | 中文原生流程 | 英文橋接流程 |
|---|---|---|
| 1. 讀入文件 | 55K token（中文） | 55K 讀入 → 37K 輸出英文譯本 = 92K |
| 2. 執行分析 | 55K 輸入 + 5.5K 輸出 = 60.5K | 37K 英文輸入 + 3.7K 英文輸出 = 40.7K |
| 3. 回譯輸出 | — | 3.7K 英文 + 5K 中文輸出 = 8.7K |
| 總計 | 60.5K | 141.4K |
英文橋接多吃 2.3 倍 token——完全反效果。
試算：短意圖 + 中等輸出（程式碼生成）
「幫我做一個 React todo app」這種短意圖、長輸出：
| 步驟 | 中文原生 | 英文橋接（直接寫英文 prompt） |
|---|---|---|
| 1. Prompt | 100 tokens | 75 tokens |
| 2. 執行 + 思考 | 30K | 25K |
| 3. 輸出 | 已是中文 | 最後解說翻中：3K |
| 總計 | 30K | 28K |
省 7%——但前提是直接用英文寫 prompt、跳過第一次翻譯。
這個策略真的能省的三個條件（缺一不可）
- ✅ Prompt 短或直接用英文寫（跳過第一次翻譯）
- ✅ 中間執行很重（大量 thinking token 的推理任務）
- ✅ 最終輸出不長或不需要回譯（程式碼、技術文件可留英文）
真正有效的 CJK 省 token 策略
不用翻譯雙跑，用混合策略：
| 策略 | 省多少 | 代價 |
|---|---|---|
| System prompt 用英文寫（使用者內容維持中文） | 每次呼叫省固定 token，高頻應用累積大 | 模型對英文 system prompt 理解完全沒問題 |
| Few-shot 範例用英文 | 同上 × 範例數 | 範例需人工準備 |
| 輸出留英文不回譯（技術任務） | 省一整個回譯步驟 | 使用者要能讀英文 |
| Prompt caching | Input 部分打 50–90% 折扣 | 需重複 prompt 才觸發 |
| 用 DeepSeek / Qwen 處理中文 | Token -20–30% + 單價低 10–50x | 品質可能略遜 |
| 中文 prompt 寫得更精煉 | 省 10–20% | 要磨 prompt |
一句話：別對整段內容雙向翻譯，那幾乎一定更貴。把「固定部分」英文化、「變動部分」維持 CJK、善用快取，才是有效策略。
🛠️ 實務建議
估算成本時的心法
- 不要用英文 token 數推估中文帳單——至少要乘 1.3–1.6x（o200k）或 1.6–2.5x（cl100k）
- 每次模型升級都要重測——Opus 4.6 → 4.7 的 CJK 惡化就是案例
- system prompt 和 few-shot 例子是大量重複傳送的內容——中文版 token 增幅的影響被放大，用 prompt caching 抵銷
選型建議
| 情境 | 推薦 |
|---|---|
| 中文為主、成本敏感（客服 / 高流量） | DeepSeek V4 / Qwen |
| 中文為主、品質優先（法律 / 金融 / 編碼） | Claude Opus 4.7 或 GPT-5 系列 |
| 混合語言 / 全球應用 | GPT-4o / Gemini 3 |
| 短指令高頻場景 | 任何 o200k 等級 tokenizer 差異都小 |
| 長文件批次處理 | 優先測 tokenizer 效率，不只看單價 |
壓縮 token 的實戰技巧
既然 CJK 多吃 token 已是事實，可從內容端著手：
- 用更簡潔的中文——避免贅語（「的話」「的時候」「做一個 X 的動作」）
- 結構化代替敘述——列點、表格、key-value 比長句省 token
- 切換寫作場景的 system prompt 到英文——只要使用者內容仍是中文，system prompt 用英文對模型理解不影響，但能省 token
- 善用 prompt caching——重複 system prompt 打折後，中文懲罰大幅降低
🧭 結論：承認事實比信仰更實用
「中文省 token」是一個流傳很廣、但與實測不符的迷思。原本的說法可能來自少數被放大的短句範例，或是混淆了「字元數」和「token 數」。
真實情況：
- 📉 CJK 在現代 LLM 上一律多吃 token，中文 1.1–1.6x、日文 1.3–2.2x
- 📈 tokenizer 改版可能改善也可能惡化（GPT-4 → 4o 改善 36%，Opus 4.6 → 4.7 惡化 15–35%）
- 💡 DeepSeek / Qwen 是真正的中文 tokenizer 優化者，搭配低單價成為中文應用的最佳性價比
- 📊 CJK 的「字元密度」優勢在 context window 層面仍然存在，但不要誤認為 token 效率優勢
別信直覺「用中文和 AI 對話比較省」——信實測。你的應用到底省不省，跑 100 筆代表性對話量一量就知道。
❓ FAQ
那「中文省 token」這個說法，有完全為真的情況嗎？
在精心挑選的短句上可能成立，但不是通則。
cl100k_base（GPT-4 時代）對某些高頻中文詞組有特殊優化，在極短、極常見的句子上偶爾會出現中文打平甚至略勝的個案。但只要把樣本拉大、把翻譯寫嚴謹，差距就會倒過來——2023 年 arxiv 2305.15425 的 200 萬句研究得出中文平均 1.76x 英文 token，和本文六任務實測一致。
可以記住的規則：現代 LLM 上，CJK 一律多吃 token，差別只在多多少。
那為什麼 context window 有時感覺「裝得下更多中文」？
因為你在感覺字元數，不是 token 數。 1M token 的 context，中文能塞 85 萬字元，英文能塞 540 萬字元——乍看差距大。但如果比「能塞多少本書」，中文的高資訊密度讓 85 萬字也能容納 3–4 本小說的內容量。
所以結論是：context window 層面 CJK 沒輸（甚至可能略勝），但API 帳單層面 CJK 輸——兩件事要分開看。
DeepSeek / Qwen 真的比 GPT / Claude 省中文 token 嗎？
是的，這是中文 tokenizer 領域唯一明確的反例。DeepSeek 和 Qwen 的訓練語料中文佔比遠高於西方模型，詞彙表分配也傾向中文——結果是 CPT（字元/token）達到 1.1–1.3，其他西方模型都在 1.0 以下。
實務影響：處理純中文內容時，DeepSeek / Qwen 的 token 消耗大約是 GPT-4o 的 70–85%。加上單價遠低於西方模型，中文應用的總成本可能只有西方模型的 1/10 到 1/60。
我現在用中文寫 prompt，該改成英文嗎？
大多數情況不用改。原因：
- 你用中文寫得出來的 prompt 比英文好——你的表達精準度比省 20% token 重要得多
- prompt quality > token efficiency——清楚的 prompt 讓模型一次做對，比省 token 但要重試 3 次划算
- token 懲罰沒想像中大——o200k 上中文 1.3x 而已，多付 30% token 成本通常不改變專案可行性
什麼時候該考慮用英文 prompt？
- 大量重複的 system prompt 和 few-shot 範例（乘以百萬次呼叫後差距會顯著）
- 技術領域術語在英文比中文精確（AI、法律、醫學）
- 高頻 API 呼叫的成本敏感應用
使用者輸入和模型輸出仍可以維持中文——只有固定的 prompt 模板值得英文化。
日文為什麼比中文還吃 token？
日文混合了三套書寫系統：
- 漢字：和中文類似，資訊密度高
- 平假名 / 片假名：每個假名只承載一個音節，但仍佔 1 個 token——每個假名的「資訊 / token」效率比漢字低很多
- 外來語的片假名拼寫（例如「コンピュータ」= computer）：一個英文單字被拉長成 6 個片假名 = 6 個 token
所以即使日文中混有高效率的漢字，整體平均下來仍比純漢字的中文更吃 token。這也是為什麼 Task 1–6 每一項日文都比中文更差。
怎麼自己實測我的應用 token 消耗？
三個方法（從易到難）：
- gptforwork.com/tools/tokenizer — 貼文字即時看 token 數，支援 GPT / Claude / Gemini / Grok
- OpenAI
tiktoken（Python）：import tiktoken enc = tiktoken.encoding_for_model("gpt-4o") print(len(enc.encode("你的文字"))) - 跑真實 API 看 usage 欄位——呼叫後從 response 讀
input_tokens/output_tokens，這是唯一 100% 準確的數字（特別是 Claude / Gemini，tokenizer 未公開）
建議：用代表性的 100 筆對話跑一次，算平均 token 數，這個數字比任何公開基準都準。
延伸閱讀：