LLM token 怎麼算才準？5 種計量方案實測比較（中文差 47% 的坑）

TL;DR

Token 計量沒有單一正解，而是一條光譜：從「字數 ÷ 4」的啟發式，到本機 tiktoken，到 provider 官方 count API，到 liteLLM／tokencost 這種跨模型計價庫，再到 Langfuse／Helicone 這種線上 observability。

重點是分清楚你要的是「事前估」還是「事後對帳」——前者用本機 tokenizer，後者直接讀 API response 的 usage。

最容易踩的坑：tokenization 不跨 provider 標準化。我本機實測同一段 66 字中文，GPT-4 的 cl100k_base 算 62 token，GPT-4o 的 o200k_base 只算 42 token——差 47%。拿錯 tokenizer 估成本，數字直接歪一截。

📌 目錄

• 我為什麼要回頭補這篇
• 先講清楚：你要計的是哪種「token」
• 本機實測：同一段文字，三種算法三個答案
• 五種方案逐個拆
• 五種方案優劣總表
• 怎麼選：一張決策流程圖
• 踩坑紀錄
• 我實際下的指令
• 常見問題 FAQ
• 延伸資源

🧠 我為什麼要回頭補這篇

前一篇寫 agent-browser 的文章，我提到它靠 accessibility-tree snapshot「省 82% token」，然後在文裡老實標了一句：那個數字是原文作者實測的，我自己那輪沒做嚴格的 token 計量。

標完之後我自己卡住了——我連「要怎麼嚴格計一段對話的 token」都沒有一套乾淨的工具鏈。每次想知道某個 prompt 多少 token、某次 API call 花多少錢，我都在土法煉鋼：要嘛憑感覺抓「中文大概一個字一個 token」，要嘛事後翻帳單反推。

所以這篇就是去補那個 loose end。把市面上能計 token 的方案整理一遍，本機實際跑過，講清楚各自適合什麼場景、坑在哪。

⚖️ 先講清楚：你要計的是哪種「token」

很多時候「計 token」這個需求講不清楚，是因為它其實是兩件不同的事，工具也完全不同：

搞混這兩者，就會發生「為了算成本去本機重新 tokenize 一次回應」這種多此一舉的事——回應的 token 數，API 早就告訴你了。

⚡ 本機實測：同一段文字，三種算法三個答案

我本機裝了 tiktoken 0.12.0（OpenAI 官方 tokenizer），跑了三個樣本、兩種 encoding。這是這篇最該記住的一張表：

結論很簡單：估成本一定要用對應模型的 tokenizer，不能一招打天下。

🔗 五種方案逐個拆

把計 token 的方案從輕到重排成五層，每層解決的問題不一樣。

方案一：啟發式估算（字數 ÷ 4）

最粗的做法：英文約 4 字元 = 1 token、0.75 word = 1 token；中文常用「1 字 ≈ 1～2 token」抓。

• 優：零依賴、零延遲，腦袋裡就能算。寫文案、抓個數量級夠用。
• 劣：誤差大，中文尤其不准（看上面那張表，66 字可以是 42 也可以是 62）。絕對不能拿來做計費或 context 安全判斷。
• 適合：草稿階段抓感覺、跟人解釋「大概多少」。

方案二：本機 tokenizer（tiktoken / gpt-tokenizer）

OpenAI 開源的 tiktoken（Python）跟 gpt-tokenizer（JS）實作了 GPT 系列的 BPE，本機就能算，不用連網、不用 key。

• 優：精準（對 OpenAI 模型就是計費用的同一套）、零 API 成本、可離線、適合在迴圈裡大量算。
• 劣：只覆蓋 OpenAI。Claude、Gemini 用 tiktoken 算只能近似（很多庫對舊 Claude 退回 cl100k_base 硬估）。要記得選對 encoding（cl100k_base vs o200k_base）。
• 適合：OpenAI 為主、需要事前估、或要在送出前做 context 裁切的場景。

方案三：Provider 官方 count API

Anthropic 有 count_tokens endpoint、Google 有 CountTokens API。重點：這些 count endpoint 都免費，不消耗 inference 算力，只做 tokenize。

• 優：對該家模型 100% 精準（用的就是它自己的 tokenizer），結構化輸入（含 system prompt、tool、image）也能正確算。
• 劣：要連網、要 API key（Anthropic 的 count_tokens 不計費但仍需驗身份）、有網路延遲，不適合在緊迴圈裡每次都打。
• 適合：Claude／Gemini 的事前精算、輸入含 tool/圖片等結構化內容、數字會影響 routing 或計費決策時。

方案四：跨模型計價庫（liteLLM / tokencost）

不只算 token，還幫你換算成「多少美金」。

• liteLLM 的 token_counter 依模型挑 tokenizer，沒對應的 fallback 到 tiktoken；再配 cost_per_token 直接吐一次 call 的 USD。
• tokencost（AgentOps-AI）走 clientside 計價，宣稱支援 400+ 模型，內建一張各家每百萬 token 的價目表；Claude 3+ 走 Anthropic beta count API，舊版用 cl100k_base 近似。
• 優：一個介面打遍 400+ 模型、自帶價目表（不用自己維護各家漲價）、calculate_prompt_cost() 之類一行算成本。
• 劣：價目表是第三方維護，可能跟最新官方定價有時間差；跨 provider 的 token 數仍是近似（非 OpenAI 模型靠 fallback）。要拿來對帳前先抽樣驗一下跟帳單對不對得上。
• 適合：多模型混用、要做成本預估／預算告警、想要單一介面的應用。

方案五：線上 observability（Langfuse / Helicone / OpenLLMetry）

事後對帳的終極型態：把每次 call 的 token、成本、latency、錯誤全部自動收進一個 dashboard。

• Langfuse：開源、可自架，把一次 agent 的 6 個 LLM call 串成一條 trace，逐步拆 token 與成本。
• Helicone：改個 base URL 就開始記錄每筆 request 的 token／成本／錯誤，號稱最好接、支援 100+ 模型（2026 年初被 Mintlify 收購）。
• OpenLLMetry：vendor-neutral 的 OpenTelemetry instrumentation，spans 能被 Langfuse／Phoenix／LangSmith 等多數後端吃，可攜性最好。
• 優：事後 100% 真實（讀的是 API 回的 usage）、自動歸因到每個 user／feature／trace、適合 production 長期監控與抓異常。
• 劣：要接 SDK 或改 proxy、有基礎設施成本（自架要養 DB，SaaS 要付費）、是事後而非事前——擋不了「這次 call 會爆 context」這種事前問題。
• 適合：已上線、要追實際花費、要做成本歸因與告警的團隊。

📊 五種方案優劣總表

✓ = 強項 / △ = 可用但有條件 / ✗ = 不適用

🎯 怎麼選：一張決策流程圖

一句話版本：事後對帳優先讀 usage，量大上 observability；事前估看模型挑 tokenizer，多模型用計價庫，抓量級用啟發式。

🚧 踩坑紀錄

拿錯 encoding，中文成本估歪 47%

這就是開頭那張表的教訓。我一開始只記得 cl100k_base（GPT-4 時代留下的肌肉記憶），如果拿它去估 GPT-4o 的中文輸入成本，會比實際的 o200k_base 高估約 47%。選 tokenizer 前先確認目標模型用哪個 encoding。

用 tiktoken 算 Claude，數字只是「看起來像」

tiktoken 是 OpenAI 的。很多計價庫對 Claude 舊版會 fallback 到 cl100k_base 硬算——它會回給你一個數字，但那不是 Claude 真正的 tokenization。要 Claude 的精準值，只能走 Anthropic 自己的 count_tokens。回得出數字 ≠ 數字是對的。

為了算成本，把回應重新 tokenize 一次

最常見的多此一舉。輸出的 token 數，API response 的 usage.output_tokens 早就給你了，那還是計費依據本身。除非你要在送出前預估輸出長度，否則不需要自己再算回應。

count API 塞進緊迴圈，被延遲拖垮

provider count API 要連網。如果你在一個每秒跑幾百次的迴圈裡每次都打它估 token，延遲會疊起來。緊迴圈裡要事前估，用本機 tiktoken；count API 留給「數字要夠準才下決策」的關鍵點。

💻 我實際下的指令

本機跑 tiktoken 做那張對照表的最小重現（需要 pip install tiktoken）：

import tiktoken
text = "Token 計量在不同 LLM 供應商之間並沒有統一標準。"
for name in ["cl100k_base", "o200k_base"]:
    enc = tiktoken.get_encoding(name)
    print(name, len(enc.encode(text)))
# cl100k_base 32
# o200k_base  21

Anthropic 官方 count_tokens（免費、不計費，但要設 ANTHROPIC_API_KEY）：

import anthropic
client = anthropic.Anthropic()  # 讀環境變數的 key
result = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": "幫我估這段有幾個 token"}],
)
print(result.input_tokens)

事後對帳——其實最簡單，直接讀回應的 usage：

resp = client.messages.create(model="...", max_tokens=100, messages=[...])
print(resp.usage.input_tokens, resp.usage.output_tokens)
# 這兩個數字就是計費依據本身，不用自己再算

跨模型一行算成本（pip install tokencost）：

from tokencost import calculate_prompt_cost
cost = calculate_prompt_cost(
    [{"role": "user", "content": "hello world"}],
    model="gpt-4o",
)
print(cost)  # Decimal USD

❓ 常見問題 FAQ

Q1：中文一個字到底是幾個 token？
沒有固定答案，看 tokenizer。我本機實測 66 字中文，cl100k_base 算 62、o200k_base 算 42——同一段差 47%。粗估可以抓「1 字 ≈ 1～1.5 token」，但要計費請用對應模型的 tokenizer 實算。

Q2：tiktoken 可以拿來算 Claude 或 Gemini 嗎？
只能近似。tiktoken 是 OpenAI 的 BPE，Claude 用 SentencePiece、Gemini 用自有方案。很多庫對非 OpenAI 模型會 fallback 到 cl100k_base 硬估，數字「看起來像」但不是真的。要準就用 Anthropic／Google 各自的 count API。

Q3：Anthropic 的 count_tokens 要錢嗎？
不計費。它只做 tokenize、不跑 inference，所以沒有 compute 成本——但仍需要 API key 驗身份。沒有理由為了省錢避開它做事前精算。

Q4：我只是想知道某次 call 花多少錢，需要裝這麼多東西嗎？
不用。事後對帳直接讀 API response 的 usage（input_tokens / output_tokens），那就是計費依據。只有「上線後要長期追蹤、做成本歸因」才需要 Langfuse／Helicone 這類 observability。

Q5：liteLLM / tokencost 的成本數字可信嗎？
token 數對 OpenAI 精準、對其他家是近似；價目表是第三方維護，可能跟最新官方定價有時間差。拿來做預算告警／量級預估很好用，但要拿去跟帳單對帳前，先抽樣驗一下對不對得上。

🔗 延伸資源

• tiktoken — OpenAI 官方 tokenizer（GitHub）
• tokencost — 400+ LLM 計價庫（AgentOps-AI）
• liteLLM Token Counting 文件
• Langfuse — Token & Cost Tracking 文件
• 本站前一篇：agent-browser 是什麼？AI agent 專用瀏覽器自動化 CLI 實戰（那篇「省 82% token」的數字，就是這篇要補的計量功課）