Token 計算器完全指南：開發者與內容創作者如何精確估算 AI 成本

先搞清楚：token 不是「字數」，也不是「字母數」

很多人第一次看 AI 的 API 帳單，會直覺以為「token 就是字數」，於是拿文章字數乘一乘就想估成本——結果算出來跟實際帳單對不上，還以為自己被多收了。

問題出在對 token 的理解。token 是模型把文字切開來處理的最小單位，用的是一種叫做 subword（子詞）的切分方式：常見的短英文單字可能整個算一個 token，但比較長或罕見的字會被拆成好幾塊，連空格、標點、換行都各自佔用 token。所以它既不是「一個字一個 token」，也不是「一個字母一個 token」，而是介於兩者之間、由 tokenizer 演算法決定的東西。

依 OpenAI 說明文件〈What are tokens and how to count them?〉的粗略經驗法則，英文文字大約每 4 個字元對應 1 個 token，換算下來約等於 0.75 個英文單字。注意這是「英文」的估算，中文完全是另一回事——這點後面會專門講，因為它直接關係到華語使用者的成本。

為什麼 AI 要按 token 收費，而且輸入輸出還分兩種價

模型運算的成本，本質上跟它要處理多少 token 有關，所以主流供應商幾乎都以 token 為計價單位，通常標成「每百萬 token 多少錢」或「每千 token 多少錢」。這是可以理解的：你丟越長的內容、要它生成越長的回覆，它要跑的運算量就越大。

比較容易被忽略的是，攤開 OpenAI、Anthropic 這些供應商的官方定價頁（截至 2026-07 的頁面結構），你會發現輸入 token（你送進去的 prompt）和輸出 token（模型生成的回覆）是兩個不同的單價欄位，而且輸出那一欄的數字通常比輸入大。換句話說，同樣是 1000 個 token，「模型寫給你的」往往比「你寫給它的」貴。實際單價會隨模型與時間調整，我不在這裡寫死數字，你要估成本時請直接看該供應商當下的官方定價頁。

另外兩件事也吃 token，卻很容易漏算。第一是對話歷史：多輪對話時，先前的往返內容常常會被一起送進去當上下文，所以對話越長，每一輪的輸入 token 就越滾越大。第二是上下文視窗（context window），它本身就是以 token 為單位的上限，輸入加輸出都得塞在這個額度裡。近年 OpenAI、Anthropic 也都提供了「快取重複輸入以降低成本」這類機制（功能確實存在，細節依各家官方文件），但要不要用、怎麼用是另一個話題了。

中文使用者的隱藏成本

這一段對華語圈讀者特別有關係，也是估算時容易漏掉的一塊。所以拿同一段意思去比，中文在這些 tokenizer 下切出來的 token 數，常常會比英文多——這一點你可以用下面的方法自己驗，不必信我。

這不是我下的結論，是你可以自己驗證的操作。打開 OpenAI 的 Tokenizer 網頁工具，貼一段中文進去，再貼一段意思相近的英文，比對兩邊顯示的 token 數，差距通常一眼就看得出來。我刻意不給你一個「中文是英文幾倍」的具體數字，因為那會隨字元、標點、模型世代而變——不同世代的模型用的 tokenizer 不同，中文的切分效率也不一樣，比較踏實的做法是拿你真正要用的那個模型去實際跑一次。

實務上的意義很直接：如果你的工作大量是中文長文（客服對話、內容生成、文件摘要），token 消耗會比你照英文經驗法則估的更高。把這件事納入估算，你的成本預期才不會失真。

幾個主流 token 計算器，各自到底在算什麼

「token 計算器」其實不是單一種東西，它至少分成三類：手動貼文字看數字的網頁工具、可以寫進程式裡批次跑的開源程式庫，以及供應商內建的 API 端點。它們的關鍵差異，在於「用哪一套 tokenizer」——因為不同模型家族的切分規則不同，用錯 tokenizer 算出來的 token 數就會跟你實際被計費的對不上。

幾個實用提醒。tiktoken 是 OpenAI 開源的 tokenizer 程式庫，適合你要在程式裡自動化估算、或跑一整批檔案時用，因為它可離線、可批次。網頁工具的好處是零門檻、隨手貼隨手看，適合臨時抓個粗估。至於第三方網頁計算器，方便歸方便，但要特別留意它背後用的 tokenizer 是否對得上你真正要呼叫的模型——對不上的話，數字只能當「大概」，不能拿去算精確帳單。想串進自己流程的人，關於資料清洗與格式化，我在JSON 格式化工具那篇也整理過相關工具。

三個實戰場景：文案、程式碼審查、資料分析各怎麼估

場景一：批量文案生成

假設你是行銷，要用同一套 prompt 模板批量生成幾百則產品描述。這時你的 token 帳分成兩塊：每一則都重複送出去的「模板＋指令」（輸入），以及模型每則寫出來的文案（輸出）。批量的陷阱在於——那段固定模板會被乘上你的產品數量，重複計費。估算時，先用計算器算出「單則的輸入 token × 數量」，再加上「預期輸出 token × 數量」，你才會看到真正的規模。至於固定指令要不要移進 system prompt、或用供應商的輸入快取機制，各家的傳輸與計費細節不同，請以該供應商官方文件為準——把內容換個位置放，並不等於它就不再被送出、也不等於不再計費。

場景二：整檔程式碼審查

假設你是開發者，習慣把整個檔案貼進去請 AI 幫你 review。程式碼很吃輸入 token：縮排、括號、變數名、註解全都算。檔案一大，你可能還沒開始問問題，光是貼進去就逼近上下文視窗的上限。合理做法是先用 tiktoken 對檔案跑一遍，知道它到底幾個 token，再決定是整檔丟、還是拆成幾段丟。這一步能幫你避免「送出去才發現超過視窗被截斷」的尷尬。

場景三：表格與資料分析

假設你是分析師，想把一份 CSV 或表格丟給 AI 做摘要。表格是 token 的隱形殺手：每個數字、每個逗號、每個欄位分隔都算 token，格式化過的資料尤其膨脹。丟整張表之前，先估一下它的 token 量，往往會發現「其實只需要丟關鍵欄位或抽樣幾列」就夠模型理解結構，不必整份灌進去。要處理這類結構化資料，搭配線上計算工具先做清洗也會省事。

把帳單壓下來：從 prompt 下手的幾個做法

token 最佳化不玄，方向就一句話：該送的送、不該送的別送，該短的讓它短。

• 砍掉客套與冗詞：prompt 裡的「請你務必幫我仔細地」這類語氣詞對結果幫助有限，卻在每次呼叫都佔 token，量大時累積起來很可觀。
• 限制輸出長度：既然輸出 token 單價通常較高，明確要求「用三句話回答」或設定 max_tokens，就是直接省在單價通常較高的那一欄。
• 指令部分可以試試英文：如果只是給模型的操作指令（不是要生成給人看的中文內容），用英文寫有時 token 數較少——你可以把同一段指令的中英文各貼進 tokenizer 比對確認，這是能自己驗證的，不必聽我說。
• 批次前先抽樣估算：要跑大批任務，先拿幾筆樣本用 tiktoken 算平均，乘上總量，你就有一個可靠的預算數字，不會事後被帳單嚇到。

老實說，token 最佳化不是每個人都非做不可。如果你只是偶爾用網頁版 ChatGPT、Claude 這類訂閱制產品聊聊天，那些產品的收費方式跟 API 的按 token 計費是兩回事（實際方案內容以各家官方定價頁為準），那你其實不太需要糾結這些——這種情況我在AI 工具訂閱方案對比那篇談得比較細。真正該認真算 token 的，是「走 API、量大、而且量還會長大」的人：做產品整合的開發者、跑批量生成的內容團隊、把 AI 接進自家流程的公司。反過來，如果你的用量小到一個月成本零頭都不到，那就別為了省幾塊錢把 prompt 改到彆扭——把力氣留給讓輸出更好，比較實在。

常見問題

Token 和中文字數到底怎麼換算？

沒有一個放諸四海皆準的固定比例，這是最需要打破的迷思。英文有 OpenAI 提出的「約 4 個字元對 1 個 token」經驗法則，但中文因為 tokenizer 的切分方式不同，一個漢字常被切成多個 token，換算比例跟英文完全不一樣，而且還會隨標點、罕見字、模型世代變動。比較踏實的做法是不要用比例硬換，而是把你真正要送的那段文字直接貼進對應模型的 tokenizer 工具，或用 tiktoken 跑一遍，看實際數字。想抓月預算的話，就拿幾筆代表性樣本算平均值再乘上量，會比套用固定換算比例更貼近實際。

免費的第三方 token 計算器準不準？

要看它背後用的是哪一套 tokenizer。如果它用的 tokenizer 剛好對應你要呼叫的模型家族，那結果會很接近；但如果對不上——比如你要用 Claude，它卻拿 OpenAI 的切分規則在算——數字就會有偏差，只能當粗估。判斷方法很簡單：看它有沒有註明對應哪些模型，沒註明的就別拿去算精確帳單。要精確，還是回到官方管道：OpenAI 系列用官方 Tokenizer 或 tiktoken，Claude 系列用 Anthropic 提供的計算方式，Cohere 用它自己的 tokenize 端點，這樣算出來的會比較貼近該供應商自己的切分規則。

中文是不是特別「燒 token」？

就多數以英文為主的 tokenizer 來說，同樣意思的內容，中文的 token 數確實傾向比英文多，因為漢字常被拆成多個 token。這代表如果你的工作大量是中文長文，成本會比照英文經驗法則估的更高，估算時要把這個差距算進去。但也別因此就一律改用英文——輸出內容本來就要給中文讀者看的話，為了省 token 硬改成英文再翻譯，往往得不償失。比較務實的取捨是：給模型的「指令」部分可以精簡或試英文，真正要生成給人看的內容維持中文，兩邊分開對待。

輸入和輸出的 token，哪個比較貴？

攤開主流供應商的官方定價頁（結構截至 2026-07），輸入 token 和輸出 token 是分開標價的兩欄，而且輸出那欄的單價通常比輸入高。實際數字會隨模型與時間調整，我不寫死，請以你使用當下的官方定價頁為準。實務上的意義是：控制成本時，「限制模型回覆的長度」往往比「精簡你的提問」更有感，因為你是在單價通常較高的那一欄省錢。當然，若你的 prompt 本身很長（例如塞了大量上下文或對話歷史），輸入端一樣不容小覷，兩邊都值得估。

怎麼在程式裡自動算 token，而不是手動貼？

OpenAI 系列可以用它開源的 tiktoken 程式庫，載入對應的編碼後，把字串丟進去就能拿到 token 數，適合寫進批次流程、離線跑一整批檔案。Claude 系列則可透過 Anthropic 提供的計算 token 方式（走它的 API），Cohere 有自己的 tokenize 端點。差別在於：tiktoken 不需要 API key、可完全離線；而走供應商 API 端點的做法通常需要金鑰、需要連線，但好處是「算的就是它自家模型的規則」，準確度上比較沒有 tokenizer 對不上的風險。要哪種，看你重視離線方便，還是重視「用的就是它自家規則」。

華語地區使用這些計算工具會有限制嗎？

純粹的網頁 tokenizer 工具和開源程式庫（像 tiktoken），本質上是本地或前端的文字切分，不涉及帳號與計費，一般不會有地區門檻，你能開網頁、能裝套件就能用。真正可能卡關的是「呼叫供應商 API」這一步——那需要註冊帳號、綁定付款方式，各家對帳號與金流的支援政策不同，且會隨時間調整，這部分請以你所在地當下能不能完成註冊與付款為準。單就估算 token 這件事，用開源程式庫離線跑不需要帳號也不需要連線，這部分的地區門檻自然比較少。

上下文視窗塞滿了會怎樣？

上下文視窗是以 token 為單位的上限，輸入（含對話歷史）加上預留給輸出的空間都得塞在裡面。一旦你送進去的內容逼近上限，可能發生的狀況包括輸入被截斷、或沒有足夠空間讓模型完整回覆。多輪對話時這特別容易踩到，因為歷史會越滾越大。避免的做法是：長文件先估 token 再決定要不要分段送、對話過長時做摘要壓縮、以及在送出前用計算器確認總量還在視窗內。先估這一步，能省掉很多「送出去才發現被截斷」的來回。

花時間做 token 最佳化，到底值不值得？

這要看你的用量規模。如果你是走 API、量大而且還在成長的開發者或內容團隊，最佳化帶來的是每個月都持續生效的成本控制，前期花點時間建立估算流程，我會覺得划算。但如果你主要用的是按月訂閱的網頁版產品（計費跟 token 無關），或 API 用量小到成本只是零頭，那就不必為了省幾塊錢把 prompt 改到彆扭——把時間拿去讓輸出品質更好，回報通常更高。一句話：先估出你目前的月成本落在什麼量級，再決定要不要投入最佳化，別在還沒算清楚前就先焦慮。

最後更新：2026 年