摘要： 文章說明各家 tokenizer 會把相同文字切成不同 token 數，因此只比每百萬 token 牌價會誤判真實成本。TensorZero 測得 claude-opus-4-7 在純文字上為 gpt-5.4 的 1.57 倍，工具定義上達 2.65 倍；Firecrawl 另測得 15 個網頁從原始 HTML 改為 Markdown 後 token 減少 21.5 倍。
當你拿兩個模型的每百萬 token 價格來比，挑了便宜的那一個，帳單卻還是更高——這不是哪裡算錯了，而是兩個供應商把你的文字切成了不同數量的 token。這就是 LLM tokenization，它藏身在每一筆 token 帳單的最底層。
Token 量不出長度，它是模型真正會去讀取的最小單位。每一家供應商的 tokenizer 都帶著自己的一份詞彙表，條目數通常落在 10 萬到 25 萬之間，內容由訓練語料塑造。詞彙表裡常見的字可能剛好一個 token 就帶過，冷僻的字則要拆成好幾段。結果就是同一段文字交給不同模型，讀出來的 token 數不會相同。
差距有多大：從單一個字到整份文件
劍橋大學與香港大學的研究團隊曾拿十種 tokenizer 實測，結果「antidisestablishmentarianism」這個字在 Claude 上要切成 9 個 token，在 Gemini 和 Grok 上只要 5 個，整體範圍從 4 到 9 不等。Firecrawl 自行計數的結果也一致：Gemini 的 countTokens 給出 5，Anthropic 給出 8。
一個字只是茶餘飯後的趣聞，放大到一百萬字就成了預算科目。同一份研究顯示，表情符號與數字這兩類內容的壓縮比差距可達 100%，其餘內容則落在 20% 到 50% 之間。英文散文的壓縮效率比技術寫作好上大約 25%。換句話說，你的 token 成本取決於送進去的是哪一種文字，而不只是份量多寡。
TensorZero 在 2026 年 4 月做過最乾淨的一組比較：把相同的輸入送進各家 API，再以 OpenAI 為基準換算。結果顯示，純文字上 Gemini 只比 OpenAI 多 6%，claude-opus-4-7 卻多了 57%；換到工具定義，Gemini 多 82%，claude-opus-4-7 多 165%。各模型相對 gpt-5.4 的 token 倍數整理如下：
| 模型 | 純文字 | YAML | JSON | 工具定義 |
|---|---|---|---|---|
gpt-5.4 |
1.00x | 1.00x | 1.00x | 1.00x |
gemini-3.1-pro-preview |
1.06x | 1.18x | 1.11x | 1.82x |
claude-sonnet-4-6 |
1.17x | 1.25x | 1.22x | 2.06x |
claude-opus-4-7 |
1.57x | 1.53x | 1.70x | 2.65x |
橫著看，內容愈結構化，每個模型的表現就愈差；直著看，供應商彼此的落差會從純文字的 1.57 倍一路擴大到工具 schema 的 2.65 倍。
價目表排名會翻轉：沒有哪個模型永遠最便宜
真正的成本，要把 token 倍數乘上牌價才算得出來。從 TensorZero 的數據看，工具用量大的工作上，claude-opus-4-7 的實際成本是 gpt-5.4 的 5.3 倍，兩者牌價明明只差 2 倍。更關鍵的是，排名根本不會固定：Gemini 在純文字上最便宜，換算下來每百萬 token 只要約 2.12 美元，但只要送上工具定義，就會落到比 OpenAI 貴 46% 的位置。
因此「哪個模型比較便宜」並沒有固定答案，只能針對你自己的內容組合去實測。如果你過去拿 agent 的 token 成本做過比較，這裡的數據正是該拿去修正的偏差。
結構化內容最燒 token
JSON、YAML、工具 schema 這類結構化文字，是 tokenizer 最不擅長的領域。引號、冒號、縮排、括號，這些符號都會拆出幾乎不帶意義的短 token。以 JSON 的 key「created_at」為例，它還沒開始用 token 表達概念，就已經先耗掉兩個引號和一個底線。
工具 schema 之所以會落在 2.65 倍那一端，原因就在這裡；載入一堆工具定義，會在 agent 還沒動手前就把成本堆高，也是同一個道理。Firecrawl 另外提到，Claude Code 的 skill 一啟動就要先花約 100 token，而這些開銷大多來自 frontmatter，不是指令本身。
原始 HTML 這種輸入最糟：差距達 21 倍
Firecrawl 自己跑了一組基準測試：抓取 15 個真實網頁，同一頁各有兩種版本——原始 HTML，以及只保留主要內容的 Markdown——再讓各家 tokenizer 各算一次。原始 HTML 那一側合計 4,103,706 個 GPT token，Markdown 那一側僅 190,817 個，縮減幅度達 21.5 倍。每頁中位數落在 19 倍；最低是 Hacker News 首頁的 2.6 倍，最高是 Vercel 首頁的 283 倍。
三家 tokenizer 都呈現同樣的縮減幅度：Gemini 22.5 倍、GPT 21.5 倍、Claude 20.8 倍。省成本的部分很明顯，但可行性的問題更尖銳：15 頁當中有 5 頁的原始 HTML 突破 20 萬 token，200k 的 context window 根本裝不下；一旦轉成 Markdown，就沒有任何一頁逼近上限。
讓人意外的是，頁面一旦清乾淨，各家 tokenizer 反而拉開距離（Claude 由 1.168 倍升到 1.210 倍），Gemini 則是往反方向收窄。理由是 HTML 充其量只是大量重複的 ASCII 標記，交給哪一家 tokenizer 處理都差不多；標記清掉之後只剩下散文，各份詞彙表的差異到這時才暴露出來。
英文以外的內容：tokenizer 稅
如果你爬取的不只是英文，這會是 tokenization 效應裡最強的一個。NeurIPS 2023 的 Petrov 等人研究顯示，處境最不利的語言，要表達同等內容得付出超過英文 12 倍的成本，而這段落差早在 tokenization 階段就已成形——用他們的說法是「遠在語言模型看到任何資料之前」。延遲要付同樣的溢價，context window 能裝下多少文字也一樣。
實務建議：格式先修，模型後換
可以帶走三個可操作的結論：
- 先把輸入格式清乾淨：HTML 先轉成 Markdown，往往就能省下一個數量級的 token，效果勝過換模型。
- 拿自己的內容實測：別只看牌價，用你實際的文字、JSON、工具定義，交給各家 API 的計數器跑一遍，換算成有效成本。
- 別忽略結構化內容的隱藏成本：JSON、工具 schema 這類輸入會把模型之間的差距放大到 2 倍以上，挑模型時務必特別注意。
Tokenization 由不得你決定，但送什麼內容進去操之在你。格式與 tokenizer 是兩根各自獨立的槓桿；清理輸入未必能換到更划算的匯率，卻永遠能讓你要交換的量少掉一個數量級。