Token 是 AI 語言模型處理文字的基本單位,但它不完全等同於我們日常說的「字」或「詞」。現代 LLM 通常用一種叫 BPE(Byte Pair Encoding)或類似的分詞演算法,把文字分割成「次詞(subword)」單位——比詞更細但比字母更粗。
不同語言的 Token 效率:
英文:一般每個 Token 大約對應 3/4 個詞。「Hello, how are you?」這句話大約是 6 個 Token。
中文:中文字通常是 1-2 個 Token 一個字。中文的訊息密度較高,同樣的語意用的 Token 通常比英文少(但也取決於模型的詞表設計)。
代碼:代碼的 Token 效率取決於語言。Python 的關鍵字(def、return、import)通常是一個 Token;變數名和字串可能多個 Token。
直觀的量感:Claude 的 200,000 Token Context Window,大概等於一本 400 頁的小說(英文),或者連續 8 小時的對話逐字稿。大多數日常任務遠遠用不到這個上限。
Tokenizer 工具:Anthropic 提供了線上的 Tokenizer 工具,可以直接貼入文字,看看會被分成多少個 Token。這對估算 API 費用和 Context Window 使用量很有用。
API 的 Token 費用怎麼計算?有哪些省 Token 的實用方法?
費用計算方式:API 費用分輸入和輸出兩部分,以 Claude Sonnet 4.5 為例:
輸入 Token:約 $3 / 1M Token 輸出 Token:約 $15 / 1M Token
輸出 Token 比輸入貴 5 倍,這意味著你應該謹慎設定 max_tokens(不要設太大),並且在任務允許的情況下,明確告訴 Claude「簡短回覆就好」能顯著降低輸出費用。
Token 的主要來源:每次 API 呼叫裡,Token 來自三個地方:System Prompt(每次呼叫都要傳輸,是固定成本);對話歷史(多輪對話累積,越來越長);用戶的當前輸入。
省 Token 的有效方法:
System Prompt 精簡化——去掉不必要的解釋,只保留 Claude 真正需要的背景資訊。500 Token 的 System Prompt 和 2,000 Token 的 System Prompt,如果效果差不多,前者每次呼叫能省 1,500 Token 的費用。
對話歷史管理——不要無限累積對話歷史,用滑動窗口保留最近的 N 輪,或者定期生成摘要壓縮舊歷史。
啟用 Prompt Caching——System Prompt 超過 1,024 Token 時,加 cache_control 標記,快取命中時輸入費用降低 90%。
明確指定輸出長度——「用 3 個條列點回答,每點不超過 20 字」這樣的格式指令,能大幅減少不必要的輸出 Token。
為什麼同樣的內容,有時候 Token 數差很多?有沒有規律可以估算?
Token 數受幾個因素影響,理解這些規律能幫你更準確地估算費用:
語言差異:英文的 Token 效率通常比中文低——同樣的概念,英文可能需要更多 Token 表達。但代碼裡的中文注解通常比英文注解用更多 Token(因為中文字的 Token 分割方式)。
標點和空白:標點符號和空白字元也佔用 Token。很多空行、多餘的空格,也是 Token 費用的一部分。
重複性文字:重複出現的短語(如你的 System Prompt 裡有很多重複的句式),因為 Tokenizer 把它們分成相同的 Token 組合,但這不能節省費用——每個 Token 都要計費,不管是不是重複的。
一個實用的估算方法:英文文字,每 1,000 字大約是 750 Token;中文文字,每 1,000 字大約是 1,000-1,500 Token(因為中文字密度高但每字 Token 數可能更多);代碼,每 1,000 字符大約是 250-500 Token(代碼有很多特殊字符和關鍵字,Token 效率較高)。
最準確的方式還是用 Anthropic 的 Tokenizer 工具直接計算。
Token、Context Window、記憶這三個概念經常被混在一起——它們的關係是什麼?
這三個概念確實相關,但是不同層次的東西:
Token:AI 處理文字的基本單位,是計量用的。就像「公分」是長度的單位一樣,Token 是文字長度的單位。
Context Window:用 Token 計量的「一次對話裡 AI 能看到的最大文字量」。Claude 的 Context Window 是 200,000 Token,意思是在一次對話裡,所有的輸入(System Prompt + 對話歷史 + 當前問題)加起來不能超過 200,000 Token。
記憶(Memory):AI 跨對話保存和使用的個人化資訊(你的名字、偏好、背景)。和 Context Window 完全不同:Context Window 是「這次對話裡的短期記憶」,記憶功能是「跨對話的長期記憶」。一次對話結束後,Context Window 裡的內容消失;但記憶功能裡的內容在下次對話裡仍然可以使用。
三者的關係:記憶功能在每次對話開始時,會把相關的記憶摘要載入到 Context Window 裡,佔用一部分 Token。Context Window 的其餘空間,用來放 System Prompt、對話歷史和當前輸入。理解這個關係,能幫你明白為什麼長對話後期 Claude 開始「忘記」前面說的話——因為 Context Window 被填滿了,最早的內容被推出去了。
一個行銷主管用 Claude API 為她的公司構建了一個客戶郵件回覆工具。她發現每個月的 API 帳單比預期高 40%,想了解原因並降低費用。
用 Token 的視角分析帳單:
問題一:System Prompt 太長。她的 System Prompt 有 3,200 Token(詳細的品牌指南、語氣說明、各種例外情況處理)。每次 API 呼叫都要傳輸這 3,200 Token,每天 500 次呼叫 = 每天 160 萬 Token 只是 System Prompt。
改善方式:把 System Prompt 精簡到核心的 800 Token,剩餘的邊緣案例說明移到範例文件裡(只在需要時引用)。每天省下 120 萬 Token = 每月約 $180 的費用節省。
問題二:沒有啟用 Prompt Caching。800 Token 的 System Prompt 低於 1,024 Token 的快取閾值,但她在 System Prompt 後面加了一些固定的客戶背景資料,讓總長度超過 1,024 Token,啟用 Prompt Caching 後快取命中率 85%,輸入費用降低約 30%。
問題三:輸出 max_tokens 設太大。她設定的 max_tokens = 2,000,但實際郵件回覆平均只有 300 Token。設定上限不影響實際輸出長度(Claude 在自然結束時停下),但她意識到可以用格式指令讓輸出更精簡。加了「回覆控制在 150 字以內」的指令後,平均輸出從 300 Token 降到 180 Token。
三個改善加起來,月費用從 $420 降到 $195,降低了 54%,輸出品質幾乎沒有影響。
Token 計費模型的核心取捨是「靈活性 vs 可預測性」。按 Token 計費讓費用和實際使用量精確對應——短的問答幾乎不花費用,複雜的長文分析才花比較多。但這也意味著費用難以完全預測,特別是對有大量用戶輸入的應用(你無法控制用戶問多長的問題)。對費用可預測性要求高的應用,需要額外的控制機制:限制用戶輸入的最大長度、設定每用戶每日的 Token 配額、監控異常的高用量請求。把費用管理設計進系統架構,而不是等帳單來了才發現問題。