Token 計算器

估算文本在 AI 模型中的 Token 數量，支援主流大模型定價計算

輸入文本

選擇模型

統計結果

Token 數量0

字元數0

中文字數0

單詞數（估算）0

字元/Token 比值0

預估成本

輸出 Token

輸入 Token0

輸出 Token1,000

總成本$0.0100

$2.50 / 1M Token 輸入
$10.00 / 1M Token 輸出

什麼是 Token？

Token 計數器用來估算 AI 模型會如何把文字切成處理單位。Token 不一定等於一個詞或一個字，它可能是一整個單字、單字的一部分、標點、空白處理結果，或在某些語言中接近單一字元。Token 數會影響上下文長度、費用估算、提示詞設計、RAG 分段、聊天記錄保留，以及輸入是否能放進模型請求。不同模型家族使用不同 tokenizer，因此數字不是通用常數，而是模型相關的估算。這個工具適合在送出前協助縮短、拆分或重新組織文字，但最終仍應以實際模型限制為準。

使用方式

基本操作

在輸入區域中輸入或貼上文字
選擇目標 AI 模型（GPT-4、Claude、Gemini 等）
在右側面板查看 Token 數量估算
設定預估輸出長度以計算 API 成本

Tokenization 規則

GPT 系列：約 4 個英文字元 = 1 個 token，約 1.5 個中文字元 = 1 個 token
Claude 系列：與 GPT 相似，僅有些微差異
DeepSeek 系列：針對中文最佳化，約 2 個字元 = 1 個 token
特殊字元、標點符號和換行也會消耗 token
程式碼和 JSON 等結構化文字通常具有較高的 token 密度

使用場景

跨模型家族估算提示詞大小貼上文字後從 OpenAI、Claude、Gemini、Llama、Mistral 或 DeepSeek 模型預設中選擇。估算器會根據所選家族，對中文字元、英文字詞、標點和空白使用不同的啟發式係數。快速切換預設可以揭示為某廠商設計的提示詞在另一廠商處如何計費，在洽談供應商合約時特別有用。

預估粗略的輸入與輸出成本面板將預估的輸入 Token 數與使用者輸入的預期輸出 Token 數以及模型特定的每千 Token 價格結合。它顯示輸入 Token、輸出 Token 和預估總成本，方便快速檢查預算。對於長期運行的批次任務，可將單次請求的估算乘以計劃的請求次數，在確定模型前預估月度支出。

了解多語言文本的組成結構除了 Token 預估外，工具還會報告總字元數、中文字數、詞數和字元/Token 比值。在精簡提示詞、比較中英文草稿或為模型上下文限制準備內容時非常有用。較高的字元/Token 比值表示 tokenizer 在每個 Token 中打包了更多文字，通常能降低每頁成本。

並排比較不同 tokenizer 的估算結果在同一段文字上切換 GPT、Claude 和 Gemini 的模型預設，觀察中英文成本如何變化，在跨供應商移植提示詞或為 RAG 管線估算分塊大小時很有用。BPE 和 SentencePiece tokenizer 之間的差異變得可見：BPE 傾向於將罕見詞拆分為更多子詞 Token，而 SentencePiece（Llama 和 Mistral 使用）可能以不同方式分割空白並將中文字元視為更大的單位。

在嵌入或檢索前確定分塊大小將每段文字控制在所選模型的上下文片段附近（如 512 或 1024 Token），將邊界句子複製到分割器中，並為每個分塊標記 Token 數以供下游檢索索引使用。GPT-4o 使用的 cl100k_base 詞彙表、較新 OpenAI 模型使用的 o200k_base 以及 Claude 大約 10 萬符號的 SentencePiece 詞彙表，在同一份文件上會產生不同的分塊邊界。

技術原理

現代 LLM 的分詞器使用子詞演算法——主要是位元組對編碼（BPE）和 SentencePiece——而非按空白分割。BPE 從單一位元組開始，迭代合併最常見的相鄰配對，產生通常為 32k-200k 個符號的固定詞彙表。常見詞成為單一 token，罕見詞被拆分為多個子詞，任意位元組（表情符號、控制字元）仍能安全編碼，因為字母表涵蓋全部 256 個位元組。SentencePiece（Llama、Mistral、Gemini 變體使用）透過 `▁` 標記將空白視為普通字元，因此前導空白成為下一個 token 的一部分，這就是為什麼 ` hello` 和 `hello` 通常是不同的 token ID。 OpenAI 透過 `tiktoken` 函式庫發布了三個主要的 BPE 詞彙表：`p50k_base`（50,281 個 token，GPT-3 / Codex）、`cl100k_base`（100,277 個 token，GPT-3.5 Turbo 和 GPT-4）以及 `o200k_base`（約 200k 個 token，GPT-4o 和 o1），後者增加了非英語覆蓋並將中文/日文的 token 數量縮減了約 1.4-1.7 倍。Claude 使用相關但專有的分詞器，具有相似的詞彙表規模。粗略的工作比例：英文文字平均約 4 個字元/token，中文在 cl100k_base 上約 1.5-2 個字元/token，在 o200k_base 上約 2 個字元/token，單個表情符號通常消耗 2-5 個 token，因為它被編碼為多個 UTF-8 位元組。 Token 數量決定了上下文視窗使用量和成本。目前的視窗大小包括 GPT-4o 128k、Claude 3.5 Sonnet 200k 和 Gemini 1.5 Pro 2M；計費方式為 `tokens × 每 1M 價格`，輸入和輸出分別計價（例如 GPT-4o 為 $2.50/$10.00 每 1M，Claude 3.5 Sonnet 為 $3.00/$15.00）。本計數器使用每個模型家族的啟發式係數，因為載入每個分詞器的詞彙表檔案需要數百萬位元組的傳輸量，因此結果是工作估算——權威數字來自模型 API 回應的 `usage` 欄位。

BPE 將常見位元組配對合併為固定詞彙表；OpenAI 詞彙表包括 `cl100k_base`（GPT-4/3.5）、`o200k_base`（GPT-4o/o1）、`p50k_base`（Codex）。
SentencePiece 將前導空白編碼為 `▁`，因此在 Llama/Mistral/Gemini 中 ` world` 和 `world` 對應不同的 token ID。
英文啟發式約 4 字元/token；CJK 在 cl100k_base 上約 1.5-2 字元/token，在 o200k_base 上約 2 字元/token；表情符號通常每個 2-5 個 token。
成本公式：`(input_tokens / 1,000,000) × 輸入價格 + (output_tokens / 1,000,000) × 輸出價格`，輸入和輸出分別計價。
2025 年上下文視窗：GPT-4o 128k、GPT-4 Turbo 128k、Claude 3.5 Sonnet 200k、Gemini 1.5 Pro 2M、DeepSeek V3 128k。
相同文字在不同供應商處的 token 數量不同：分詞器詞彙表、位元組回退規則和空白處理方式都有差異。
權威計數來自 API 回應的 `usage.prompt_tokens` / `usage.completion_tokens`（OpenAI）或 `usage.input_tokens` / `usage.output_tokens`（Anthropic）。

範例

GPT-4 下的英文短句

輸入：    Hello, world!
模型：    GPT-4 (cl100k_base)
Tokens:   4   ->  ["Hello", ",", " world", "!"]
字元數：  13
比例：    3.25 字元/token

中文文本每字元消耗較多 token

輸入： 你好，世界！  (英文 Hello, world! 的中文)
GPT-4:        ~8 tokens (1.5 字元/token)
DeepSeek V3:  ~4 tokens (2 字元/token，針對 CJK 最佳化)
Claude 3.5:   ~7 tokens

預估 1,000 字英文文章的成本

輸入：        1,000 個英文單字（約 1,330 tokens）
預期輸出： 500 tokens
模型：        GPT-4o（每 1M tokens 輸入 $2.50 / 輸出 $10.00）

輸入成本：   1,330 / 1,000,000 * $2.50 = $0.00333
輸出成本：  500   / 1,000,000 * $10.00 = $0.00500
總計：        每次請求約 $0.0083

經驗法則：英文約 75 字 ≈ 100 tokens

段落（75 字）：
"The quick brown fox jumps over the lazy dog. Pack my box with five
dozen liquor jugs. How vexingly quick daft zebras jump! The five
boxing wizards jump quickly. Sphinx of black quartz, judge my vow."

GPT-4 tokens: ~100
Claude tokens: ~95

嵌入向量資料庫前的分塊大小

目標分塊： 512 tokens（text-embedding-3-small 上限：8191）
英文文本：  每塊約 384 字
中文文本：  每塊約 768 字（GPT tokenizer）

重疊：       塊間 50 tokens（保留上下文）

常見問題

計數器使用哪一種 tokenizer？

通常是 OpenAI 的 tiktoken（cl100k_base 對應 GPT-4、GPT-3.5；o200k_base 對應 GPT-4o），有時也會搭配 Anthropic 的 Claude tokenizer 或 Hugging Face 上的開源模型 tokenizer。不同模型切詞方式不同，所以同樣文字在不同模型下計數會有差異。

為什麼 token 數和字數不一樣？

Token 是「次詞」單位。「Hello world」是 2 個 token，「antidisestablishmentarianism」則是 5-6 個 token。英文平均每個 token 約 0.75 個單字（所以 1000 token ≈ 750 字）。其他語言密度更高，例如中文每個字常占 1-2 個 token，雖然只有一個字元。

我的提示詞會被上傳嗎？

不會。Tokenizer 是在你的瀏覽器中執行的——tiktoken 有 JavaScript 版本可在本機編碼，提示詞不會送上網路。

成本估算有多準確？

Token 數是精確的。費用數字取決於所選模型每千 token 的單價，頁面會讀取已公布的價目表。供應商調價後頁面會更新；若要做預算決策，請務必對照最新官方定價驗證。

為什麼我這邊的計數和 OpenAI playground 略有差異？

不同版本的 tiktoken 可能有些微差異。特殊 token（聊天訊息會有 role/system 框架 token）每則訊息會額外加上幾個 token，無結構的計數器可能不會算進去。若要精確算出 API 呼叫的計費，請以你程式實際送出的內容為準。

如何處理程式碼、JSON 和結構化資料？

Tokenizer 會把標點、括號和空白切成許多小 token。JSON 很「耗 token」——一個小型 JSON 物件就可能用掉 50 多個 token，程式碼也比同等散文更耗 token。要把 JSON 或程式碼餵給上下文吃緊的模型時，務必把這點納入規畫。

可以為清單上沒有的模型計算 token 嗎？

前提是該模型的 tokenizer 有瀏覽器版本可用。常見的（GPT、Claude、Llama）都有 JS 實作。對於小眾或封閉的模型，請使用模型供應商的官方計數工具，或用估算方法（英文約每 4 個字元 ≈ 1 個 token）。