一句話解釋

Tokenizer（分詞器）是 AI 模型的「翻譯員」，負責把人類寫的文字拆解成模型能處理的最小單位（tokens）。

白話解釋

AI 模型不認識「文字」。它只認識數字。所以在你的文字被送進模型之前，需要有人把文字翻譯成一串數字。這個翻譯員就是 Tokenizer。

但 Tokenizer 做的事情比「一個字對一個數字」複雜得多。它會先把文字切成一段段的「碎片」，每段碎片叫做一個 token。然後每個 token 都有一個對應的數字編號。

這些碎片可能是一整個英文單字（"hello" = 1 token），也可能是一個字的一部分（"unhappiness" 可能被切成 "un" + "happiness" = 2 tokens），也可能是一個中文字（"你" = 1 token，但也可能被切成更小的 byte 組合）。

不同的 AI 模型用不同的 Tokenizer，所以同一段文字在不同模型眼裡，切法和 token 數量都不同。這就是為什麼你會看到「GPT-4 算出 200 tokens，Claude 算出 180 tokens」的情況。

Tokenizer 的歷史演進

第一代的文字處理方式是「以字元為單位」——每個字母、每個符號各自對應一個 token。英文 "cat" 就是 c、a、t 三個 token。這種方式簡單但效率極差，一個句子動輒幾百個 token。

第二代改用「以單字為單位」——整個 "cat" 是一個 token。但問題來了：英文有幾十萬個可能的單字，加上變形（running、ran、runs），詞彙表會無限膨脹。碰到沒見過的字就完全看不懂。

第三代就是現在主流的「子詞切分」（Subword Tokenization），BPE 是其中最有名的演算法。它在字元和完整單字之間找到平衡：常見的字直接是一個 token，罕見的字拆成幾個常見的片段。

BPE 演算法：Tokenizer 怎麼決定切在哪裡

BPE（Byte Pair Encoding）的概念很直覺。整個訓練過程分三個階段：

初始化階段。Tokenizer 的詞彙表只有最基本的字元——26 個英文字母（大小寫）、數字 0-9、常見標點符號，大約 256 個 byte 級別的基礎 token。

合併階段。演算法會去看大量文本（通常是幾十 TB 的語料庫），統計哪兩個相鄰的 token 最常一起出現。把最常見的組合合併成一個新的 token，加進詞彙表。然後重新統計，繼續合併。重複這個過程幾萬次。

舉個具體的例子。假設語料庫中 "t" 和 "h" 最常連在一起，演算法就把 "th" 變成一個 token。接著發現 "th" 和 "e" 很常連在一起，就把 "the" 變成一個 token。然後 "the" 和空格很常連在一起…… 就這樣，常見的「詞語片段」漸漸被合併成單一 token。

終止條件。合併到目標的詞彙表大小就停。GPT-4 的 cl100k_base 有 100,256 個 token，Claude 的詞彙表也在 10 萬左右，Llama 2 只有 32,000 個。

最終結果：常用的英文單字（like、the、and）通常是一個 token，不常用的長字（unconstitutionally）可能被切成好幾個 tokens，而非常罕見的字串會退回到字元級別的切分。

BPE 有幾個常見的變體。Byte-level BPE（GPT 系列用的）是直接在 byte 級別操作，理論上可以處理任何 Unicode 文字。SentencePiece（Llama 系列用的）則把空格也當作普通字元處理，不預設空格是分隔符，對中文和日文比較友善。Unigram Language Model 是另一條路線，從大詞彙表開始，不斷砍掉出現機率最低的 token，和 BPE 的「從小到大」方向相反。

中文和英文的 Token 差異

這是很多台灣使用者關心的問題：為什麼中文比英文「貴」？

原因在於 Tokenizer 的訓練資料。大多數主流模型的 Tokenizer 是用以英文為主的資料集訓練出來的。英文的常見單字在合併過程中很早就被合成一個 token 了。但中文字出現的頻率相對低，很多中文字沒有被合成為獨立 token，而是用更底層的 byte 組合來表示。

具體來看幾個例子：

英文 "Hello, how are you?" 大約 6 個 tokens。中文 "你好，你怎麼樣？" 在 GPT-4 的 Tokenizer 裡大約 7-9 個 tokens。意思相同，但中文用了更多 tokens。

更極端的例子："The quick brown fox jumps over the lazy dog" 是 9 個 tokens。翻譯成中文 "那隻敏捷的棕色狐狸跳過那隻懶狗" 在同一個 Tokenizer 中大約需要 15-20 個 tokens。

中文的每個字平均佔 1.5-2 個 tokens。一個中文字在 UTF-8 編碼下佔 3 個 bytes，如果 Tokenizer 沒有把這個字學成獨立的 token，它就要用 3 個 byte token 來表示。常見的中文字（的、是、在、了）通常已經被學成獨立 token 了，罕見字則要拆成 bytes。

這個差距在不同世代的 Tokenizer 之間也在縮小。早期的 GPT-2 Tokenizer（r50k_base）對中文極不友善，一個中文字可能要 3-4 個 tokens。GPT-4 的 cl100k_base 已經好很多，大部分常用中文字是 1-2 個 tokens。Claude 的 Tokenizer 在中文效率上表現也不錯。

這直接影響三件實際的事情。

成本。API 是按 token 收費的，中文使用者同樣的對話內容要多付 30-50% 的費用。GPT-4o 的輸入價格是每百萬 token 2.5 美元，如果你的中文 prompt 產生的 token 數比等義英文多 40%，你實際上多付了 40% 的費用。

Context Window 使用效率。同樣的 128K token 窗口，能放的中文內容比英文少。一篇 5,000 字的中文文章大約佔 7,000-10,000 tokens，但等義的英文只佔 5,000-7,000 tokens。

Prompt 設計。中文 prompt 要更精簡。「請用三句話摘要」比「請用精簡的語言把以下內容做一個重點摘要」省了一半的 tokens，但意思差不多。

各模型的 Tokenizer 差異

不同模型的 Tokenizer 之間有實質差異，以下是 2026 年主流模型的比較。

GPT-4 / GPT-4o 用的是 tiktoken 的 o200k_base，詞彙表約 200,000 個 tokens。這是目前公開的最大詞彙表之一，對多語言的支援比前一代好很多。GPT-3.5 用的是 cl100k_base，約 100,000 個 tokens。

Claude 系列用 Anthropic 自己的 Tokenizer，規模跟 tiktoken 接近但編碼方式不同。Anthropic 沒有公開 Tokenizer 的技術細節，但 API 會回傳每次請求的 input_tokens 和 output_tokens 數量，你可以從中推算。

Llama 3 系列用 SentencePiece 搭配 BPE，詞彙表 128,256 個 tokens，比 Llama 2 的 32,000 大了四倍，中文支援也好了很多。

Gemini 用 Google 自己的 SentencePiece Tokenizer，詞彙表規模沒有公開但估計在 25 萬以上。Google 在多語言 NLP 方面積累深厚，Gemini 的中文 token 效率算是業界較好的。

這意味著你不能用一個模型的 token 計數器去估算另一個模型的成本。OpenAI 的 Tokenizer 工具算出的 token 數，跟你實際用 Claude API 時的計費 token 數會不同。

各模型的 Tokenizer 工具整理：

OpenAI：platform.openai.com/tokenizer 網頁工具，或用 Python 的 tiktoken 套件在本機計算。

Anthropic：API 回傳中的 usage.input_tokens 和 usage.output_tokens，沒有獨立的網頁工具。

Hugging Face：tokenizers 套件支援大部分開源模型的 Tokenizer，可以在本機精確計算。

粗略估算法：英文大約每 4 個字元 = 1 token，中文大約每 1-2 個字 = 1-2 tokens。這只是粗估，實際計算建議用各模型的官方工具。

為什麼 Tokenizer 很重要

對一般使用者來說，理解 Tokenizer 有幾個實際好處。

估算成本。API 是按 token 收費的，知道你的 prompt 大概幾個 tokens，就能估計每次請求的花費。如果你每天呼叫 API 處理大量中文文件，Tokenizer 效率直接影響你的月帳單。

善用 Context Window。模型的輸入窗口是用 token 數量計的。128K tokens 的窗口可以放大約 300 頁英文，但中文大約只能放 200 頁。把文件塞進 context 前，先估算 token 數可以避免超出限制被截斷。

寫更有效的 prompt。了解 token 的概念後，你會知道哪些表達方式比較省 token。中文的成語和四字詞語通常比白話說明省 token——「言簡意賅」4 個 token，但「用精簡的語言把意思表達清楚」可能要 12 個 token。

理解模型的「盲區」。有些模型對特殊字元、罕見語言、表情符號的處理不好，通常是因為 Tokenizer 對這些內容的編碼方式不佳。如果 Tokenizer 把一個表情符號切成 10 個 byte token，模型理解它的難度就比只用 1 個 token 的英文單字高得多。

理解模型在數學上的弱點。語言模型不擅長做算術（例如大數乘法），部分原因是數字的 tokenization 方式。"1234567" 可能被切成 "123" + "4567" 兩個 token，模型很難從這兩個 token 理解這是一個七位數的概念。

Tokenizer 與 Prompt Caching 的關係

2025 年起，Anthropic 和 OpenAI 都推出了 Prompt Caching 功能。Prompt Caching 可以讓你重複使用的 system prompt 只在第一次時被完整處理，之後的請求直接用快取。

但 Prompt Caching 的計費和觸發門檻都是以 token 數量為單位的。例如 Anthropic 要求快取的前綴至少 1,024 tokens（Claude Sonnet）或 2,048 tokens（Claude Opus），快取的讀取費用是原價的 10%。知道你的 system prompt 有多少 tokens，可以幫你判斷是否值得啟用 Prompt Caching，以及如何安排 prompt 結構來最大化快取命中率。

安全與限制

Tokenizer 有幾個值得注意的安全層面。

Token 邊界攻擊。某些 Prompt Injection 手法會利用 Tokenizer 的切詞方式來繞過安全過濾。如果安全過濾器在 token 化之前運作，攻擊者可能用特殊的字元組合讓敏感詞被切成不同的 tokens，避開偵測。例如，把 "ignore" 拆成 "ig" + "nore" 中間插入零寬度字元，Tokenizer 可能把它切成三個不同的 token，過濾器就認不出 "ignore" 這個詞了。

Glitch Token。某些 Tokenizer 的詞彙表中存在「異常 token」——這些 token 在訓練資料中幾乎沒有出現過，當模型被要求處理它們時可能產生不穩定的行為。著名的案例是 GPT 早期版本的 " SolidGoldMagikarp" token，當使用者輸入這個字串時模型會產生奇怪的回應。

資訊洩漏。Tokenizer 的詞彙表是公開的。研究者可以從詞彙表中推測模型的訓練資料包含哪些語言和領域。例如，如果詞彙表中包含大量醫學術語的獨立 token，可以推測訓練資料中有大量醫學文獻。

不均等的語言效能。Tokenizer 對某些語言效率較差，這些語言的使用者需要花更多錢、能處理更少的文字。這是一個公平性問題。以台灣原住民族語言為例，這些語言幾乎完全不在訓練資料中，所有字都要退回到 byte 級別切分，token 效率極差。

特殊字元問題。某些 Unicode 字元組合（如結合字元、控制字元）可能讓 Tokenizer 產出異常長的 token 序列，消耗大量計算資源。部分 API 有輸入長度限制和字元過濾來防止這種問題。

常見問題

我怎麼知道一段文字有多少 tokens？

各家有提供工具。OpenAI 有 Tokenizer 網頁工具和 tiktoken Python 套件。Anthropic 的 API 回傳中包含 token 計數。Hugging Face 的 tokenizers 套件支援大部分開源模型。粗略估算：英文大約每 4 個字元 = 1 token，中文大約每 1-2 個字 = 1-2 tokens。

為什麼同一句話在不同模型的 token 數不一樣？

因為每個模型用不同的 Tokenizer，詞彙表和合併規則都不同。就像不同的翻譯員會用不同方式切割同一段文字。估算成本時要用目標模型的 Tokenizer 來算，不能用 OpenAI 的工具去算 Claude 的成本。

中文使用者怎麼省 token？

幾個實用技巧：用簡潔的中文寫 prompt，避免重複描述。長文件考慮先摘要再處理，減少每次 API 呼叫的 token 數。批次處理多個小任務，共用 system prompt 的部分可以用 Prompt Caching 省錢。如果 prompt 很長但變動的部分很少，把固定部分放在前面讓快取命中。

Tokenizer 會影響模型的能力嗎？

會。如果 Tokenizer 把某個概念切得很碎，模型理解和生成那個概念就會比較困難。這也是為什麼早期模型處理中文比較差——中文被切得太碎，模型要花更多「注意力」才能拼回完整意思。新一代的多語言 Tokenizer 已經改善很多，但對低資源語言（例如台灣原住民族語）仍然是個問題。

我能自己訓練 Tokenizer 嗎？

技術上可以。SentencePiece 和 Hugging Face 的 tokenizers 套件都支援自訓 Tokenizer。但一般人不需要。自訓 Tokenizer 通常只在你要從頭訓練一個新模型、或是你的應用場景涉及非常特殊的語料（例如特定的程式語言或專業術語）時才有意義。如果只是用現有模型，你無法改變它的 Tokenizer。

為什麼 AI 做數學這麼差？跟 Tokenizer 有關嗎？

部分有關。Tokenizer 把數字切割的方式讓模型很難理解數值的「大小」。"42" 和 "4200" 可能被切成完全不同的 token，模型不容易從 token 本身理解 4200 是 42 的 100 倍。加上 BPE 可能把 "1000000" 切成 "100" + "0000"，模型要從兩個 token 拼出「一百萬」的概念。不過數學能力差的主因還是在模型架構本身，Tokenizer 只是雪上加霜。

相關文章

參考資料