你 LLM 帳單變成真實 line item 時,你必須優化。預設「全部送 GPT-5」在低量 OK、規模化貴。好消息:有 7 個可疊加優化、每個砍成本 20-60%、大部分不損品質。
1. Prompt caching
單一最大贏。Anthropic、OpenAI、Google 全部支援重複 prompt 內容(系統 prompt、RAG context、few-shot 例子)的 cache。Cache 命中花普通 input token 的 10%。
典型 RAG 應用,系統 prompt 1000 token 不變:
- 沒 caching:每 query 付完整 input 率
- 有 caching:第一次寫 cache 後付那率的 10%
- 節省:重複前綴的 input 成本省 80-90%
實作:在 API call 裡標可 cache 前綴。Claude 跟 OpenAI 都用參數或 breakpoint 支援。Cache TTL 通常 5 分鐘(每命中更新),chat session work well。
2. 模型 routing
不是每個 query 都需要前沿智能。簡單分類器(常常較小模型)路由:
- 60% query 給便宜模型(Haiku 4.5、GPT-5 Mini、DeepSeek)
- 30% 給中段(Sonnet 4.5)
- 10% 給前沿(Claude Opus 4.7、GPT-5 Pro、o3)
真實例子:客服 agent。大部分問題是例行 FAQ 風($0.001 在 Haiku 上)。複雜多步問題升到 Sonnet。真正新場景用 Opus。
結果:5-10 倍成本減少,品質下降難以察覺。
實作:小分類器 prompt 給小模型:「這 query 簡單還是複雜?」用答案挑模型。
3. Output token capping
大部分 API 對 output 收費比 input 多 3-5 倍。長不必要完成是純浪費。
- 積極設
max_tokens。輸出有界(摘要 200 字)的話,cap 在 400 token。 - Tool-use loop,cap 每輪讓模型不囉嗦。
- 用 stop sequence 在自然邊界結束輸出。
平均輸出長度減 50% 能代表帳單減 30-40%,因為 output 主導成本。
4. 從 chat 換 completion 風
結構化任務(分類、抽取、摘要),不要用完整 chat API。一些 API 提供更便宜「completion」endpoint 或 batch API,是同步 chat 的 50% 價格。
OpenAI Batch API:50% off、24 小時 SLA。非即時 workload 很好。 Anthropic Batch API:50% off、類似取捨。 Provider 特定優惠:看你特定 provider 的 batch 定價。
5. 通用任務用較小開源
品質差難以察覺的任務(分類、抽取、簡單摘要),自架 Llama 3.1 70B、Qwen 2.5、DeepSeek 能取代前沿 API call。
Production 團隊真實數字:
- Claude Sonnet 每天 5M token:約 $1500/月
- 同量自架 Llama 3.1 70B:GPU + ops 成本後約 $300/月
- 簡單任務品質下降:極小
- 複雜推理品質下降:實質 — 那留前沿
6. 積極減 context
- 修剪對話歷史。大部分聊天不需要 20 個前輪全部。
- 摘要舊 context。10 個舊輪用一個摘要輪取代。
- 撈到 chunk 不真相關就不要含進來。用 reranker 挑 top-3 取代 top-10。
- Audit 系統 prompt。大部分比需要長 2-3 倍。
Context 減 30% 大致代表 input 成本減 30%。
7. Batch 跟 async 哪可以哪用
很多 operation 能 batch:
- 在一個 API call embed 100 個文件而非 100 次 call(較低每 call overhead)
- 過夜報告用 async batch API 處理
- 預先算常見 query 的回應
即時 UX,batching 加延遲。背景處理,batch API 在大部分 provider 上 50% off。
累乘節省
一起套,優化乘而非加:
- Prompt caching:input 成本省 50%(假設 80% cache 命中率)
- 模型 routing:混合成本省 70%(大部分 query 在便宜模型)
- Output capping:output 成本省 30%
- Context 修剪:剩 input 成本省 30%
- Batch API(可用時):batch 部分省 50%
套用所有這些的團隊能看到總帳單下降 70-80%,品質沒被察覺下降。
不要做什麼
不要所有東西用最便宜模型。 品質下降造成客戶抱怨、更多 support ticket、更多退款,假經濟。
不要為了「省錢」停 streaming。 Streaming 沒成本差;它是 UX 跟可能 time-to-first-token。
不要每天根據定價換 provider。 整合改變的工程成本超過大部分團隊的價格差。
不要在量測前加複雜度。 帳單 $200/月,優化不值得工程時間。$2000+/月才優化。
優化前先量測
優化前:
- 每個 API call log:模型、input token、output token、成本
- 按功能 / endpoint 聚合找什麼貴
- 識別驅動 80% 成本的 top 20% call
- 優化那些、留其他
沒量測你會優化錯東西。第一週設基本 log;第二週開始優化。
有幫助的工具
- Helicone、Langfuse、Portkey — 帶成本 dashboard 的 observability 平台
- OpenRouter — 多 provider router,內建 fallback 跟定價
- Martian、Anyscale — 自動化模型 routing 服務
- PostHog + 自訂 — 每功能追蹤 LLM 成本
早期團隊,自訂 log 夠。Production 規模,用專門平台。
什麼時候不要鑽
- 總帳單每月 $500 以下:聚焦產品、不優化
- Pre-product-market-fit:成本優化能等
- 還小的爆量流量:平均成本重要,不是 peak
成本真實重要時優化。在那之前,ship 更快。
決策樹
- 帳單 < $500/月:不優化、聚焦產品
- 帳單 $500-5k/月:啟用 prompt caching + output capping + 模型 routing
- 帳單 $5k-50k/月:所有 7 個優化 + observability 平台
- 帳單 > $50k/月:專門基礎建設團隊聚焦、可能自架
下一步
- 這週按功能設成本 log
- 明天啟用 prompt caching(5 分鐘改變大省)
- 為你 top 用途加簡單模型 router
- 為非即時 workload 看特定 provider 的 batch API