LLM API 成本怎麼算：把 Token 帳算清楚

開發 LLM 應用時，最常被問到的一句話是「這個功能每天要花多少錢」。答案取決於一個變數：每次請求消耗多少 Token。這篇文章將這筆帳拆開來算一遍，順便講講哪幾個地方最容易算錯。

Token 到底是什麼單位

模型不是按字數收費，而是按 Token 收費。Token 是模型處理文字的最小單元，大致規律如下：英文 1 個 Token 約等於 3/4 個單字；中文因分詞方式不同，通常 1 個 Token 對應 1 到 1.5 個中文字。具體比例取決於你使用的模型之 Tokenizer，但量級上足夠參考——中文 1000 字大約是 700 到 1000 個 Token。

一個容易忽略的重點：上下文中的每樣東西都是 Token。使用者訊息、系統提示（System Prompt）、工具函式定義、檢索出來的文件片段、歷史對話輪次，全部計入輸入。許多應用的實際輸入 Token 數量是「使用者那段話」的 5 到 10 倍。

一次請求的成本怎麼算

帳單公式很直白：

成本 = (輸入 Token 數 + 輸出 Token 數) × 對應單價

先釐清兩個陷阱。第一，輸入和輸出的單價通常不一樣，輸出一般較貴，比例從 2 倍到 5 倍不等。第二，單價在階梯計價和包月額度下會變動，小規模測試時得出的「單次成本」放到大量使用後不一定成立。

舉個具體例子。一個客服機器人：

- 系統提示 800 字 ≈ 900 Token

- 保留最近 10 輪對話，平均每輪 150 字 ≈ 1000 Token

- 檢索注入 3 段產品文件 ≈ 800 Token

- 模型回覆約 200 字 ≈ 250 Token

單次請求約 2700 Token 輸入 + 250 Token 輸出。假設單價為輸入 0.5 美元/百萬 Token、輸出 1.5 美元/百萬 Token（各廠商差異很大，以下都用這個假設做例子）：

單次 ≈ 2700/1000000 × 0.5 + 250/1000000 × 1.5 ≈ 0.0017 美元

一天 1 萬次請求 ≈ 17 美元/天，月成本約 500 美元。這個數字的量級感是真實的：一個每週 50 萬次請求的中等規模客服，月帳單過萬並不誇張。

成本優化只有四條路

1. **壓縮上下文**。歷史對話最常見的做法是加「過期機制」：超過 15 分鐘的輪次丟棄，或用摘要替代原文。檢索文件注入前先做一次相關性過濾，只留最相關的 1 到 2 段。每砍掉 500 Token 輸入，萬次請求就省 5 萬 Token/天。

2. **快取穩定前綴**。系統提示、工具定義這類每次都重複的長文字，多數廠商支援 Prefix Caching，命中部分按折扣價計費。系統提示越長、請求量越大，快取收益越明顯。這是改動最小、見效最快的一招。

3. **依難度路由**。分類、匹配、格式化這類任務，用規則或小模型；真正需要多步推理的請求才交給大型模型。這不是口號，而是一個 if 分支的事，通常能把大型模型的調用量壓掉一大截。

4. **限制輸出長度**。將 `max_tokens` 設一個合理上限，配合提示詞明確要求「3 句話內回答」。一個回答 50 字就夠用的場景，不該允許模型囉嗦到 500 字——輸出 Token 單價又高，囉嗦等於雙倍花錢。

這四個手段的組合拳，把單次請求成本壓低 30% 到 50% 是常見水準，而且不影響回答品質。

怎麼知道自己實際花了多少

別靠估算，要靠日誌。每次 API 回應的 `usage` 欄位裡有 `prompt_tokens` 和 `completion_tokens`，把這兩個數字寫進你的存取日誌，按天聚合，就是一條真實的成本曲線。不要等月底對帳單才發現超支。

兩個常見異常要能立刻發現：

- 輸入 Token 突然翻倍：多半是某處的上下文拼接出了 Bug，例如在迴圈裡重複注入同一段文件，或者歷史輪次沒截斷。

- 請求開始大量報「超過上下文長度」：上下文快滿了，你的壓縮策略失效了，要么砍歷史記錄，要么換成長上下文模型（後者更貴）。

小結

把 Token 用量當成和回應時間一樣的工程指標：有監控、有預算、有警報。上線前列一個靜態估算，跑一週後用真實的 usage 數據修正一遍。之後每次修改提示詞、調整上下文物件、更換模型，都重新校驗一次。成本問題不是一次性算出來的，而是持續校準出來的。