LLM API 帳單暴衝怎麼辦？八個實測有效的省 token 做法

半夜兩點，一個獨立開發者收到 Anthropic 的用量通知信。他上週上線的一個小功能——把使用者上傳的 PDF 自動摘要——這七天燒掉了四百三十美元。他預期的數字是三十。

問題出在哪？他每次呼叫都把整份文件塞進提示詞，而使用者很喜歡對同一份文件連續問五六個問題。同樣的兩萬個 token，重複送了六次。

模型 API 的成本邏輯跟雲端資源很不一樣。你不能「關機」，因為每一次呼叫都是獨立事件；你也很難「降規」，因為換小模型可能直接毀掉產品體驗。這篇整理的是實際有效、而且我自己或身邊團隊真的驗證過的做法。

一、先量測，再優化

這聽起來像廢話，但九成的團隊在開始省錢時根本不知道錢花在哪個功能上。

最低限度你要記錄三件事：每次呼叫的輸入 token 數、輸出 token 數、以及對應的功能名稱。有了這三個欄位，你才能算出「摘要功能每次呼叫平均成本」這種可以行動的數字。用 Helicone 或 Langfuse 這類可觀測性工具可以省下自己寫的功夫。

我看過太多團隊直接跳到優化，結果花三天優化了一個只佔總成本 4% 的功能。

二、提示詞快取是投報率最高的一招

這是目前最被低估的功能。主要模型供應商都提供某種形式的提示詞快取——當你的請求有很長的共同前綴（系統提示、文件內容、範例），第二次之後的呼叫可以用大幅折扣的價格重複使用。

回到開頭那個案例：如果他把 PDF 內容放在提示詞的固定前綴並啟用快取，同一份文件的後續問答成本可以降低一個數量級。這是結構性的改變，不是省一點點。

實務上的注意事項是：快取有時效，而且要求前綴完全一致。把會變動的東西（使用者問題、時間戳、隨機 ID）放到提示詞的最後面，這個順序決定了快取能不能命中。

三、模型分級：不是每件事都需要旗艦模型

一個常見的浪費是所有任務都打同一個最貴的模型。實際上大部分工作可以分成三級：

• 分類、抽取、格式轉換：小模型完全夠用，成本可能只有旗艦的二十分之一
• 一般問答、摘要、改寫：中階模型的品質已經很接近，差異多數使用者感覺不出來
• 複雜推理、程式生成、多步驟規畫：這時候才值得用旗艦模型

做法是在應用層加一個路由邏輯，依任務類型分派。OpenRouter 這類服務可以讓你用一組 API 金鑰切換多家模型，實作起來不會太痛苦。

四、把提示詞瘦身

很多團隊的系統提示詞是長期堆積出來的——這裡加一條規則、那裡補一個例外，半年後變成兩千個 token 的怪物，而且每一次呼叫都要付這筆錢。

實際做法：把系統提示詞印出來逐條檢視，問每一條「拿掉之後輸出會變差嗎」。我做過一次，砍掉了 40% 的內容，輸出品質沒有可測量的差異。少數例子（few-shot examples）尤其要檢查，很多時候三個例子跟八個例子的效果差不多。

五、輸出長度要主動控制

輸入 token 通常比輸出便宜，但輸出的成本容易失控——模型很喜歡多講。設定 max_tokens 上限、在提示詞裡明確要求輸出格式與長度（「用三個要點回答，每點不超過三十字」），這兩招加起來的效果比想像中大。

特別提醒推理型模型：它們的思考過程也算 token，而且經常比最終答案長好幾倍。用推理模型處理簡單任務，是我看過最貴的錯誤之一。

六、批次處理能打對折

如果你的任務不需要即時回應——例如每天處理一批文件、產生報表、批次分類——主要供應商都提供批次 API，價格通常是即時呼叫的一半，代價是等待時間拉長到數小時。

這一招適用的場景比多數人以為的多。問問自己：這個功能真的需要三秒內回覆嗎？還是使用者可以接受「明天早上會好」？

七、加一層語意快取

除了供應商提供的提示詞快取，你也可以在自己的應用層做語意快取：把問題向量化，如果新問題跟過去的問題足夠相似，直接回傳之前的答案。

這在客服、FAQ、產品問答這類場景特別有效，因為使用者問的問題重複度極高。缺點是要維護向量資料庫，而且相似度門檻設太鬆會回傳不對的答案，需要仔細調校。

八、設硬上限，不要只設告警

告警的問題是它假設有人在看。凌晨三點的失控迴圈不會等你醒來。

最有效的保護是在應用層設硬上限：單一使用者的每日呼叫次數上限、單次請求的 token 上限、以及整體的每小時支出上限，超過就直接拒絕。這會影響少數重度使用者的體驗，但比起帳單暴衝，這個代價非常划算。

台灣團隊常踩的三個坑

第一個坑：用繁體中文計算 token 的直覺是錯的。 中文字的 token 效率比英文差，同樣的內容中文版本可能多出三到五成的 token。如果你的產品同時服務中英文使用者，成本結構會有明顯差異，做預估時要分開算。

第二個坑：把匯率跟手續費忘了。 模型 API 都是美元計價，加上信用卡的外幣手續費（通常 1.5%）與匯差，實際成本會比帳單上的數字高。做預算時記得乘上一個係數。

第三個坑：測試環境沒有設限。 我看過不只一次，正式環境管得很嚴，但開發環境沒有任何限制，結果某個測試腳本跑了迴圈燒掉五位數。開發環境的用量也要納管。

想了解雲端資源本身的成本管理，可以看 AI 時代的雲端帳單為什麼失控，兩者的邏輯不同但需要一起管。

TheAI學院 總結與評語

省 token 這件事有個很反直覺的地方：最有效的做法通常不是換便宜模型，而是「不要重複送同樣的東西」。

快取、批次、輸出長度控制——這三招沒有一個是在犧牲品質，它們都是在消除純粹的浪費。而換小模型雖然單價便宜，卻可能因為輸出品質下降導致使用者重問三次，總成本反而更高。

評語：先消除浪費，再考慮降級。順序反了，你會用更差的產品體驗換到更貴的帳單。

給台灣開發者的具體建議：這週先把用量記錄補上（輸入、輸出、功能名稱三個欄位就夠），跑一週看數據。你大概會發現八成的成本集中在一兩個功能上，而那一兩個功能通常有很明顯的優化空間。從那裡開始，比全面優化有效十倍。

相關工具可以在 AI 開發者工具 找到，也可以看看 提示詞範本 學習怎麼把提示詞寫得更精簡。