Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
獨立知識媒體
與任何項目無關聯
探索AI智慧的思維邊界
claude-me.com
最新
Anthropic 親口說的八個原則:Claude 愈用愈笨,很可能是你的方式有問題  ·  Claude Code 現在可以自己「循環工作」了:Anthropic 公開四種 Loop 模式,讓 AI 真的幫你跑完整個流程  ·  Claude Cowork 真實評測:三個月後,哪些任務真的省了時間,哪些讓我後悔開了自動化  ·  七月開局的兩個大消息:Claude Sonnet 5 正式發布,Fable 5 出口管制解除全球重新開放  ·  RAG 是什麼:為什麼 Claude 讀不了你公司內網的資料,以及怎麼讓它讀到  ·  Claude Cowork 進階工作流:從「交代一件事」到「讓它跑完一整個流程」,三個真實可用的範本
名詞解析 · core-concepts

Token

Token(語言模型的基本單位)
core-concepts 新手

30 秒版 · 給沒耐心的人
AI 語言模型處理文字的最小單位。Token 不等於字——英文大約每 0.75 個詞是一個 Token,中文大約每個字是 1-2 個 Token。API 費用就是按 Token 計費的:你輸入多少 Token、Claude 輸出多少 Token,加起來是這次對話的費用。理解 Token 能幫你更有效地控制 AI 的費用和 Context Window 的使用效率。
完整解說 +
01 · 這是什麼?

Token 是 AI 語言模型處理文字的基本單位,但它不完全等同於我們日常說的「字」或「詞」。現代 LLM 通常用一種叫 BPE(Byte Pair Encoding)或類似的分詞演算法,把文字分割成「次詞(subword)」單位——比詞更細但比字母更粗。

不同語言的 Token 效率

英文:一般每個 Token 大約對應 3/4 個詞。「Hello, how are you?」這句話大約是 6 個 Token。

中文:中文字通常是 1-2 個 Token 一個字。中文的訊息密度較高,同樣的語意用的 Token 通常比英文少(但也取決於模型的詞表設計)。

代碼:代碼的 Token 效率取決於語言。Python 的關鍵字(defreturnimport)通常是一個 Token;變數名和字串可能多個 Token。

直觀的量感:Claude 的 200,000 Token Context Window,大概等於一本 400 頁的小說(英文),或者連續 8 小時的對話逐字稿。大多數日常任務遠遠用不到這個上限。

Tokenizer 工具Anthropic 提供了線上的 Tokenizer 工具,可以直接貼入文字,看看會被分成多少個 Token。這對估算 API 費用和 Context Window 使用量很有用。

02 · 為什麼存在?

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。

03 · 如何影響你的決策?

為什麼同樣的內容,有時候 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 工具直接計算。

04 · 你該怎麼辦?

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%,輸出品質幾乎沒有影響。

常見誤解 +
✕ 誤解1
× 誤解一:Token 就是「字」,1,000 Token = 1,000 個字。Token 不等於字。英文的平均轉換率是 1 Token ≈ 0.75 個詞(所以 1,000 個英文詞大約是 1,333 Token);中文大約每個字是 1-2 個 Token。而且不同的模型可能用不同的 Tokenizer,同樣的文字在不同模型裡的 Token 數可能不同。最準確的計算方式是用 Anthropic 的 Tokenizer 工具,或者在 API 回應裡查看 `usage.input_tokens` 和 `usage.output_tokens`。
✕ 誤解2
× 誤解二:設定更大的 max_tokens 讓 Claude 輸出更多、更完整。`max_tokens` 是輸出的上限,不是目標長度。Claude 在認為回答完整時就會停止,不管 max_tokens 設了多少。設 max_tokens = 4,000 不會讓 Claude 自動生成 4,000 Token 的回答——如果它認為 300 Token 就能回答好,它就只輸出 300 Token。max_tokens 的主要用途是防止 Claude 生成超出你期望長度的輸出,以及控制費用的上限。
這件事跟你有什麼關係 +
直接影響

Token 計費模型的核心取捨是「靈活性 vs 可預測性」。按 Token 計費讓費用和實際使用量精確對應——短的問答幾乎不花費用,複雜的長文分析才花比較多。但這也意味著費用難以完全預測,特別是對有大量用戶輸入的應用(你無法控制用戶問多長的問題)。對費用可預測性要求高的應用,需要額外的控制機制:限制用戶輸入的最大長度、設定每用戶每日的 Token 配額、監控異常的高用量請求。把費用管理設計進系統架構,而不是等帳單來了才發現問題。

提問
請至少輸入 10 個字
相關文章
LLM 到底怎麼生成文字?給非工程師的真正解釋
fundamentals · 06月17日
Context Window 完全實用指南:你的對話「記憶體」到底有多大、怎麼用才不浪費
beginners · 06月16日