Dev Tools
純前端檔案不上傳

AI Token 估算器

貼任意 prompt,**即時估算 5 種主流 AI 模型**(GPT-4 / GPT-3.5 / Claude / Gemini / Llama 3)的 token 數、成本與 context window 使用率。**啟發式估算**(無需 1MB tiktoken WASM),英文文本精確度 ±10%,中文按字元加權更貼近真實 BPE 行為。

字元: 190詞: 25CJK: 28≈ 83 Tokens
模型Tokens成本Context
GPT-4o / GPT-4.183$0.0004✓/ 128K
GPT-3.5 Turbo83<$0.0001✓/ 16K
Claude 3.7 / Opus 485$0.0003✓/ 200K
Gemini 1.5 / 2.083$0.0003✓/ 1000K
Llama 3 (70B)89free✓/ 8K
為什麼是估算?

真實 BPE 分詞要靠 tiktoken / SentencePiece,WASM bundle 約 1MB。我們用「英文 4 字元 ≈ 1 token、CJK 1 字元 ≈ 1.5 token」的啟發法,對英文 / 中文混合文本誤差 ±10%。用來估算成本與 context 是否爆是夠的;真正要精確,請用 OpenAI / Anthropic 官方 API tokenizer。

›如何使用
  1. 把 prompt(或整段對話)貼進輸入框。
  2. 工具同時對 5 個主流模型 估算:GPT-4o / Claude 3.5 / Gemini Pro / GPT-4o-mini / Claude Haiku。
  3. 右側顯示:tokens 數量、單次成本、context window 是否塞得下(綠 / 黃 / 紅燈)。
  4. 想壓縮 prompt?看哪個段落 token 密度高,先壓那段最有效。
Tips
  • 中文 1 字 ≈ 1.5-2 tokens,英文 1 字 ≈ 1.3 tokens,heuristic 估算誤差 ±10%。
  • 把 system prompt + few-shot 也算進去,別只算 user 輸入。

純前端 heuristic,不呼叫 OpenAI tokenizer API,所以你的 prompt 不會離開瀏覽器。

AI Token 計算完整指南:GPT / Claude / Gemini 怎麼算、為什麼會超 context、怎麼省錢

你的 prompt 「夠不夠塞」「要花多少錢」「會不會超 context window」— 這三個問題每個 AI 應用開發者都被 PM 問過。但 OpenAI / Anthropic / Google 三家算 token 的方式都不一樣,中英文比例差更多。這篇用我們的 `token-counter` 工具當範例,拆解 token 估算的真實邏輯、5 大模型的成本對照、實戰省 token 的 3 個技巧。

Token 不是「字」也不是「字元」,而是「BPE 拆出來的子詞」

Tokenizer 通常用 BPE(Byte Pair Encoding):把常見子詞合併成單一 token。 - "hello" = 1 token - "unhappiness" = un + happiness = 2 tokens - "你好嗎" = 你 + 好 + 嗎 各 1 token,共 3 tokens - "中華電信" = 中華 + 電信 = 2 tokens(看 tokenizer training corpus) 所以中文 1 字 ≈ 1-2 tokens,英文 1 字 ≈ 1.3 tokens,日文韓文介於兩者之間。寫 prompt 時,用「字數 × 1.5」估算上限,通常會略高於實際,比後悔超 context 好。

5 大模型成本對照(2026 年實際定價)

假設一個 5000 token 的 prompt + 500 token 的 reply,單次成本: - GPT-4o ($2.5/M input, $10/M output):$12.5 + $5 = $17.5 per 1000 calls - Claude 3.5 Sonnet ($3/M, $15/M):$15 + $7.5 = $22.5 - Gemini 1.5 Pro ($1.25/M, $5/M):$6.25 + $2.5 = $8.75 - GPT-4o-mini ($0.15/M, $0.6/M):$0.75 + $0.3 = $1.05 - Claude 3.5 Haiku ($0.8/M, $4/M):$4 + $2 = $6 結論:同樣任務,Gemini Pro 比 Claude Sonnet 便宜 ~60%。但品質排名是 Claude > GPT-4o > Gemini(對複雜推理而言)。便宜不等於划算 — 模型錯一次的 debug 成本可能超過跑 1000 次的省錢。

Context window 滿了會怎樣?三種失敗模式

Context window 是模型能「看見」的最大 token 範圍,GPT-4o 是 128K,Claude 3.5 是 200K,Gemini 1.5 是 1M+。 超出後三種失敗模式: - 直接報錯(OpenAI, Anthropic):API 回 400 context_length_exceeded - 頭部截斷(部分舊模型 / 部分 wrapper):前面的對話被砍掉,模型「忘了」你說過什麼 - 品質崩塌(接近上限時):還沒超,但模型對前段內容的注意力下降,出現幻覺、忘記 instruction 經驗法則:用到 80% context window 時開始主動壓縮,別等報錯。長對話用 summarize-and-discard:每 10 輪請模型摘要前 10 輪,再把摘要替換掉原文。

省 token 的 3 個實戰技巧

1. 把 few-shot 範例搬到 system prompt + 用 prompt caching Claude 跟 OpenAI 都有 prompt caching:重複的 system prompt 命中 cache 時成本 降到 1/10。把 few-shot examples 全部塞 system prompt,user prompt 只放當次任務。 2. 用 JSON 而非自然語言給結構化資料 「使用者名稱 Mark Liu,年齡 32 歲,職業是工程師」= ~15 tokens {"name":"Mark Liu","age":32,"job":"engineer"} = ~12 tokens JSON 雖然看起來複雜,但 BPE 對 { : " 這些 token 高度優化,密度其實更高。 3. 用 GPT-4o-mini 做「分類 / 路由」,難題才丟給 Claude 超過 70% 的 LLM 任務其實是「分類 / 抽取 / 格式化」,GPT-4o-mini 跟 Claude Haiku 完全夠用。把這些便宜模型當第一層,只有複雜推理才升級到大模型 — 平均成本可降 80%。

為什麼這工具用 heuristic 不用真正 tokenizer?

OpenAI 開源的 tiktoken、Anthropic 的 tokenizer 都需要載入 ~1MB 的 vocab 字典 + ~500KB 的 WASM runtime。對「估算用」這種日常工具,多 1.5MB bundle 才為了 ±2% 精度 不划算。 我們的 heuristic 邏輯: - 中文字:每字 1.5 tokens(範圍 1-2,取均值) - 英文字:依詞長拆 BPE 子詞,平均每字 1.3 tokens - 標點 / 數字 / emoji:獨立 token - 程式碼:識別常見 keyword,壓縮估算 典型誤差 ±10%,絕大多數預算估算 / context fit 檢查場景夠用。需要精確算錢結帳時,API 回應內 usage.total_tokens 才是 source of truth。

下次選 AI 模型或開新功能,先用 [AI Token 估算器](/zh-TW/tools/token-counter) 跑一次,看 prompt 在 5 大模型的成本對照,整個估算在瀏覽器跑,prompt 不會離開本機。

相關工具