Token 是什麼？AI Token 定義、計算方式與費用完整解析

快速回答：Token 是什麼？

Token 是 AI 語言模型（LLM）處理文字的最小單位，你輸入的每一段文字都會先被切成一塊一塊的 Token 再處理。一個 Token 可能是一個完整的英文字（"hello"）、半個字（"un" + "happy"）、一個中文字（「你」）、甚至一個標點符號（"!"）。大約 1 個 Token ≈ 0.75 個英文單字 ≈ 0.5 個中文字。

Token 的概念在使用 AI 時隨處可見。當你用 ChatGPT 或 Claude 的網頁版，背後的系統就在計算你的對話消耗了多少 Token。當你呼叫 API 開發 AI 應用，帳單上列的也是 Token 的使用量。理解 Token 可以幫助你更有效地使用 AI，也能更精準地估算成本。

Token 的正式定義

Token 是語言模型在 Tokenization（分詞）過程中將原始文字拆分成的最小處理單元。每個 Token 對應模型詞彙表（Vocabulary）中的一個數字 ID，模型實際上是在處理這些數字序列，而非文字本身。這個從文字到數字的轉換過程是 AI 理解語言的第一步。

現代 LLM 主要使用 Subword Tokenization（子詞分詞）技術，這是介於字元級和單字級之間的折衷方案： - BPE（Byte Pair Encoding）：GPT 系列、Claude 使用的方法，從字元級別逐步合併高頻字元對，最終形成一個平衡了常見詞和罕見詞的詞彙表 - SentencePiece：Gemini、Llama 使用的方法，直接從原始文字學習分詞規則，不依賴預先定義的單字邊界 - 詞彙表大小通常在 50,000～260,000 之間（GPT-4o 約 200K，Gemini 約 262K，Claude 的詞彙表大小未公開但估計在類似範圍）

為什麼用子詞而不是整個單字？因為如果用整個單字作為 Token，詞彙表會非常巨大（英文有上百萬個不同的單字形態），模型的參數量和記憶體需求會大幅增加。如果用單一字元作為 Token，雖然詞彙表很小，但序列會很長，模型難以學習到跨字元的語意關係。子詞分詞在這兩者之間取得了平衡。

白話解釋

用樂高積木來想：你不會一個字母一個字母地拼句子（太慢），也不會把一整個句子當成一塊積木（太不靈活），而是用大小適中的積木塊來組合。Token 就是這些積木塊。

常見的字（"the"、"is"、"and"）是一塊完整的積木，因為它們出現得太頻繁了，值得給它們獨立的編號。罕見的字（"pneumonoultramicroscopicsilicovolcanoconiosis"）會被拆成好幾塊小積木（"pne" + "umon" + "oul" + "tra" + ...），因為把每個罕見的長字都給一個獨立編號太浪費了。

中文的情況稍有不同。因為中文字的數量龐大（常用字約 3,000-5,000 個），每個字在詞彙表中有自己的 Token，但兩個字組成的詞（如「人工」、「智慧」）不一定會被合併成一個 Token。這就是為什麼中文的 Token 效率通常低於英文。

你可以把 AI 模型想成一個只認得數字的計算器。你說的每句話，都要先翻譯成它認得的數字序列（Tokenization），它算完之後再把數字序列翻譯回文字。Token 就是這個翻譯過程中的最小單位。

Token 怎麼算？

英文

英文的 Token 計算相對直觀： - 約 4 個字元 = 1 個 Token - 約 0.75 個英文單字 = 1 個 Token - 範例："Machine Learning is amazing" ≈ 4-5 個 Token - 空格和標點符號也算 Token（有時和前後的文字合併成一個 Token）

短而常見的英文單字通常是 1 個 Token（"the"、"is"、"a"）。中等長度的單字通常是 1-2 個 Token（"computer" = 1、"understanding" = 2）。長而罕見的單字會被拆成多個 Token（"antidisestablishmentarianism" = 6-7 個 Token）。

中文

中文的 Token 計算比英文複雜一些： - 約 1～2 個中文字 = 1 個 Token - 中文的 Token 效率較低，同樣的語義內容，中文需要的 Token 數是英文的 2～3 倍 - 範例：「人工智慧很厲害」≈ 5-7 個 Token

常用的中文字通常是 1 個 Token（「的」、「是」、「在」）。較少使用的中文字可能需要 2-3 個 Token。中文的標點符號（「，」、「。」、「！」）通常各佔 1 個 Token。

程式碼

程式碼的 Token 計算也有自己的特點。關鍵字（if、for、return）通常是 1 個 Token。變數名稱根據長度和命名慣例可能是 1-3 個 Token。Python 的縮排空格也算 Token，所以縮排越深的程式碼消耗的 Token 越多。

# 這段程式碼大約消耗 20-25 個 Token
def hello(name):
    return f"Hello, {name}!"

為什麼中文比較「貴」？

現代 LLM 的 Tokenizer 主要以英文語料訓練，英文在訓練資料中佔了大多數的比例。因此，Tokenizer 對英文的常見組合做了很多最佳化（例如 "ing"、"tion" 這類常見的字尾會被合併成一個 Token），但對中文的最佳化較少。結果就是同樣的語義內容，中文使用者需要消耗更多的 Token，也就需要支付更多的 API 費用。

好消息是，隨著中文語料在訓練資料中的比例增加，新一代的模型（如 GPT-4o、Claude 3.5 以後的版本）的中文 Token 效率已經比早期的模型好了不少。Gemini 系列因為 SentencePiece 的設計，對中日韓文的 Token 效率也比較好。

為什麼 Token 很重要？

決定費用

API 計費的基本單位就是 Token。你傳給模型的文字（Input Token）和模型回覆的文字（Output Token）都要收費，而且 Output Token 通常比 Input Token 貴 3～5 倍。這是因為生成 Output Token 需要消耗更多的計算資源——模型是一個 Token 一個 Token 地生成回覆，每生成一個 Token 都需要一次前向傳播（forward pass）。

舉一個具體的例子：你用 Claude Sonnet 5 的 API 傳送一段 1,000 Token 的 prompt，模型回覆了 500 Token。費用計算是：Input 1,000 Token × $3/1M = $0.003，加上 Output 500 Token × $15/1M = $0.0075，總共 $0.0105。看起來不多，但如果你的應用每天處理 10,000 個請求，每月就是 $3,150。

決定 Context Window 上限

每個模型都有 Token 上限（Context Window），你的 Prompt 加上模型回覆的總 Token 數不能超過這個上限。超過了，最早的內容會被截斷或遺失。在多輪對話中，隨著對話越來越長，早期的對話內容會逐漸被「擠出」Context Window，模型就會「忘記」之前聊過的東西。

這也是為什麼長對話到後來，AI 可能會重複之前已經回答過的內容，或者忘記你在對話開頭提到的限制條件。了解 Context Window 的限制可以幫助你設計更好的對話流程，例如定期重述關鍵資訊，或者用 RAG 架構來管理長期記憶。

影響回應速度

Token 越多，模型需要處理的時間越長。Input Token 影響的是「首個 Token 的延遲」（Time to First Token，TTFT），也就是模型開始回覆之前的等待時間。Output Token 影響的是「總回覆時間」，因為模型是一個一個 Token 生成的，每個 Token 的生成速度大約是 30-100 Token/秒（視模型和硬體而定）。

所以一個需要生成 2,000 Token 回覆的請求，即使用最快的模型，也至少需要 20-60 秒才能完成。這對使用者體驗和系統設計都有影響——你的應用需要處理長時間的等待，或者使用串流輸出（streaming）讓使用者可以即時看到回覆的生成過程。

2026 年主流模型 Token 費用比較

以下為各模型 API 的大致費用（每百萬 Token，美元）：

（費用為 2026 年 7 月的參考值，實際費用以各平台官網為準）

從這個表可以看出幾個趨勢。首先，同一家公司的不同等級模型，價格可以差 10-20 倍（Claude Opus 的 Output 價格是 Haiku 的 18.75 倍）。其次，Output Token 的價格普遍是 Input Token 的 3-5 倍。第三，Gemini 2.5 Pro 提供了最大的 Context Window（1M Token），但價格和 Claude Sonnet、GPT-4o 在同一個等級。

對於台灣的開發者和企業來說，選擇模型時除了看價格，還要考慮中文能力和延遲。部分模型的伺服器在美國，從台灣連線的延遲可能比較高。如果對延遲敏感，可以考慮 AWS Bedrock 或 GCP Vertex AI 的亞洲區域部署。

Context Window 與 Token 的關係

Context Window（上下文窗口）是模型一次能處理的最大 Token 數，你可以把它想成模型的短期記憶容量。所有的輸入（System Prompt、對話歷史、附加資料）和輸出（模型的回覆）都必須在這個窗口之內。

各模型的 Context Window： - Claude 系列：200K Token（約 15 萬個中文字，相當於一本 300 頁的書） - Gemini 2.5 Pro：1M Token（約 75 萬個中文字，相當於好幾本書） - GPT-4o：128K Token（約 9.6 萬個中文字）

Context Window 越大，能塞進越多的對話歷史和參考資料，但費用也跟著增加。而且即使 Context Window 很大，模型對窗口中間位置的資訊的注意力可能較弱（這個現象被稱為 "Lost in the Middle"），位於開頭和結尾的資訊通常會得到更多的關注。

如何有效利用 Context Window

把最重要的指示放在 System Prompt 的開頭（最高注意力區域）。參考資料放在 Prompt 的中間。具體的問題或任務放在 Prompt 的結尾（第二高注意力區域）。如果需要處理超出 Context Window 的資料量，使用 RAG 架構來動態載入相關的部分。

Token 省錢技巧

精簡 Prompt

移除不必要的冗詞和重複說明。直接、具體的 Prompt 省錢之外，通常結果也更好。例如，「請你詳細地、仔細地、逐步地分析以下文字，並且給出你的看法和建議」可以改成「分析以下文字，列出 3 個改進建議」。不只省了 Token，指示也更明確。

使用 Prompt Caching

Anthropic 和 OpenAI 都提供 Prompt Caching 功能，重複使用相同的 System Prompt 時可以節省高達 90% 的 Input Token 費用。如果你的應用有一段固定的 System Prompt（例如角色設定、輸出格式要求），開啟 Prompt Caching 可以大幅降低成本。這對於 System Prompt 較長的 AI 應用（例如包含大量背景知識的客服機器人）效果特別明顯。

選對模型

不是所有任務都需要最貴的模型。以下是模型選擇的建議：

簡單的分類、摘要、格式轉換任務：用 Haiku 4.5 或 GPT-4o mini，成本只有高階模型的 1/10 到 1/50。

中等複雜度的寫作、分析、程式碼生成：用 Sonnet 5 或 GPT-4o，在品質和成本之間取得平衡。

高難度的推理、數學、多步驟任務：用 Opus 4 或 GPT-4o，這些場景中模型的能力差異最明顯。

批次處理

使用 Batch API 通常有 50% 的費用折扣，適合不需要即時回覆的大量處理任務。例如批次翻譯文件、批次分類客戶回饋、批次產生商品描述等。Batch API 的回覆時間通常在 24 小時內，但單價只有即時 API 的一半。

控制 Output 長度

在 Prompt 中指定回覆長度限制（「用 100 字以內回答」），或使用 API 的 max_tokens 參數控制 Output Token 數量。這在 Output Token 價格較高的情況下（例如 Claude Opus 的 Output 是 $75/1M Token），節省的費用很可觀。

結構化輸出

要求模型以 JSON 格式回覆，可以減少不必要的文字修飾和開場白，直接得到結構化的結果。同時也讓後續的程式處理更方便，減少二次解析的 Token 消耗。

常見誤解

「1 個 Token = 1 個字」——不一定。英文中 1 個 Token 約等於 0.75 個單字，中文中 1 個 Token 可能是 0.5～1 個字。Token 的切法取決於 Tokenizer，不同模型的 Tokenizer 也不同。所以同一段文字在不同模型中可能產生不同數量的 Token。

「Token 越多回答越好」——不一定。更長的回答消耗更多 Token、花更多錢，但不一定更正確或更有用。研究顯示，很多情況下簡潔的 Prompt 反而能得到更精確的回答。好的 Prompt 設計能用更少的 Token 得到更精確的結果。

「所有模型的 Token 價格都一樣」——差很多。同一家公司的不同等級模型，價格可以差 10-20 倍。不同公司之間的定價策略也不同。而且價格一直在變動，通常是越來越便宜——OpenAI 和 Anthropic 都有在降價的趨勢。

「Context Window 越大越好」——不一定。更大的 Context Window 意味著你可以塞進更多資料，但也意味著更高的費用和更長的處理時間。而且模型對超長 Context 中間部分的注意力會下降，不是所有塞進去的資料都能被有效利用。

安全與隱私考量

Token 的計算和處理過程涉及到你的原始文字，這帶來了一些安全和隱私的考量。

首先，你傳送給 API 的每個 Token 都會經過模型提供者的伺服器。即使 API 政策表示不會用你的資料來訓練模型，你的文字仍然會在傳輸和處理過程中被系統讀取。如果你的 Prompt 中包含敏感資訊（例如客戶個資、公司機密、密碼等），這些資訊都會被傳送到外部。

其次，在使用 Token 計算工具（例如線上的 Tokenizer）時，注意不要把敏感文字貼進去。線上工具可能會記錄你輸入的內容。如果需要計算敏感文字的 Token 數，使用本地的 Tokenizer 程式庫（如 Python 的 tiktoken）。

第三，API 的使用量日誌通常會記錄每次請求的 Token 數量，但不應該記錄 Token 的實際內容。如果你自建的 AI 應用有記錄日誌的需求，記錄 Token 數量即可，不要記錄實際的 Prompt 內容。

常見問題 FAQ

參考資料

• OpenAI Tokenizer — OpenAI Tokenizer 工具
• Token Counting — Anthropic — Anthropic Token 計算說明
• Lexical Analysis: Token — Wikipedia — Token 語法分析定義