大多數團隊都支付了過高的 AI API 費用。這並非因為他們選錯了模型，而是因為他們忽略了三個僅需少量代碼修改的優化手段：prompt caching、智慧模型路由（smart model routing）以及批次處理（batch processing）。
以下是每種技術的詳細分析與實際數據。
如果您仍在判斷目前的供應商組合是否為問題所在，請先閱讀 pricing comparison。如果您的主要痛點是重試風暴（retry storms）或供應商節流（throttling）而非原始支出，請將本頁面與 rate limiting guide 搭配閱讀。
1. Prompt Caching：最顯著的成效
如果您的應用程式在每次請求中都發送相同的 system prompt，那麼您正在為供應商已經處理過的 token 支付全額費用。
運作原理
OpenAI 會針對超過 1,024 tokens 的輸入自動進行 prompt caching。快取後的 tokens 成本僅為標準輸入價格的 50%。您不需要更改代碼中的任何內容。
Anthropic 則透過 cache_control 斷點使用顯式快取。寫入成本比標準輸入高 25%，但讀取成本降低了 90%。快取 TTL 為 5 分鐘，每次命中都會延長。
在較新的 OpenAI 定價中，實際折扣可能比團隊預期的更好。GPT-4.1 的快取輸入價格僅為標準輸入的四分之一，這意味著一致的前綴（prefixes）所產生的節省遠比舊有的「聊勝於無」觀念所暗示的要大得多。
成本計算
以一個典型的客戶服務機器人為例：
- System prompt：2,000 tokens
- 用戶訊息：平均 200 tokens
- 每天 5,000 次請求，使用 Claude Sonnet 4.6
不使用快取：
每日輸入成本 = 5,000 × 2,200 tokens × $3.00/1M = $33.00
使用 Anthropic prompt caching（假設 95% 的快取命中率）：
快取寫入：250 × 2,200 × $3.75/1M = $2.06
快取讀取：4,750 × 2,200 × $0.30/1M = $3.14
用戶 tokens：5,000 × 200 × $3.00/1M = $3.00
每日總計 = $8.20 (輸入成本節省 75%)
實作方式
from anthropic import Anthropic
client = Anthropic(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc"
)
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are a customer support agent for Acme Corp...",
"cache_control": {"type": "ephemeral"} # This enables caching
}
],
messages=[{"role": "user", "content": user_message}]
)
# Check cache performance in response headers
# cache_creation_input_tokens vs cache_read_input_tokens
對於 OpenAI 模型，快取是自動的。只需確保您的 prompts 超過 1,024 tokens，並在不同請求之間保持靜態前綴的一致性。
團隊常犯的錯誤：
- 在每個 prompt 的頂部放置時間戳記或請求 ID
- 在每次調用時重新排列系統指令
- 在穩定前綴之前嵌入變動的用戶上下文
如果前綴每次都改變，快取就完全起不到作用。應將 prompt 的結構視為成本的基本要素，而不僅僅是 prompt engineering 的細節。
2. 智慧模型路由：為每項任務選擇合適的模型
並非每個請求都需要最昂貴的模型。一個 GPT-4.1 處理成本為 $2.00/1M 輸入 tokens 的分類任務，使用 GPT-4.1-mini 處理效果同樣出色，但成本僅為 $0.40/1M，成本降低了 5 倍。
路由策略
| 任務類型 | 推薦模型 | 輸入成本/1M |
|---|---|---|
| 複雜推理 | Claude Opus 4.6 / GPT-4.1 | $5.00 / $2.00 |
| 一般對話 | Claude Sonnet 4.6 / GPT-4.1 | $3.00 / $2.00 |
| 分類、擷取 | GPT-4.1-mini / Claude Haiku 4.5 | $0.40 / $1.00 |
| Embeddings | text-embedding-3-small | $0.02 |
| 簡單格式化 | DeepSeek V3 | $0.28 |
實作方式
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
def route_request(task_type: str, messages: list) -> str:
"""Pick the cheapest model that handles this task well."""
model_map = {
"classification": "gpt-4.1-mini",
"extraction": "gpt-4.1-mini",
"summarization": "gpt-4.1-mini",
"complex_reasoning": "gpt-4.1",
"creative_writing": "claude-sonnet-4-6",
"code_generation": "claude-sonnet-4-6",
}
model = model_map.get(task_type, "gpt-4.1-mini")
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
實際節省
一個編碼助手將 60% 的請求（語法檢查、格式化、簡單補全）路由到 GPT-4.1-mini，將 40% 的請求（架構設計、除錯）路由到 Claude Sonnet 4.6：
優化前（全部使用 Claude Sonnet 4.6）：
1,000 req/day × 3K input × $3.00/1M = $9.00/day
優化後（60/40 分流）：
600 req × 3K × $0.40/1M = $0.72/day (mini)
400 req × 3K × $3.00/1M = $3.60/day (sonnet)
總計 = $4.32/day (節省 52%)
3. 批次處理：降低非緊急任務的價格
OpenAI 提供 Batch API，輸入和輸出 tokens 均有 50% 的折扣。代價是：結果會在 24 小時內交付，而非即時交付。
Anthropic 對支援的模型也提供 50% 的批次折扣。如果您的工作負載是隔夜處理、非同步或以審核為導向的，通常沒有理由支付即時價格。
適合批次處理的場景：
- 每日內容生成
- 大量文件分類
- 數據集標籤化
- 定時報告生成
# Create a batch file (JSONL format)
import json
requests = []
for i, doc in enumerate(documents):
requests.append({
"custom_id": f"doc-{i}",
"method": "POST",
"url": "/v1/chat/completions",
"body": {
"model": "gpt-4.1-mini",
"messages": [
{"role": "system", "content": "Classify this document..."},
{"role": "user", "content": doc}
]
}
})
# Write JSONL file
with open("batch_input.jsonl", "w") as f:
for req in requests:
f.write(json.dumps(req) + "\n")
# Submit batch
batch_file = client.files.create(file=open("batch_input.jsonl", "rb"), purpose="batch")
batch = client.batches.create(input_file_id=batch_file.id, endpoint="/v1/chat/completions", completion_window="24h")
實際產品中適合批次處理的場景：
- 隔夜內容更新任務
- 支援票據摘要
- Embeddings 回填
- 大型代碼庫或文件審查
- 低優先級的用戶通知
不適合的場景：
- 聊天回覆
- 互動式編碼輔助
- 下一個用戶操作取決於立即回覆的工作流
4. 額外建議：減少 Token 數量
在進行 API 層級的優化之前，請檢查您是否發送了不必要的 tokens。
常見的浪費：
- 冗長的 system prompts，重複模型已經遵循的指令
- 包含完整的對話歷史，而實際上只有最後 3-5 輪對話重要
- 發送原始 HTML/markdown，而純文本即可滿足需求
- 未使用
max_tokens來限制輸出長度
prompt 長度減少 30% 直接轉化為輸入成本降低 30%。
發現浪費最簡單的方法是按路由或功能記錄 prompt 長度。大多數團隊面臨的不是模型定價問題，而是「每天發送 100,000 次同樣臃腫的 prompt」的問題。
5. 在盲目優化前增加成本可視化
當團隊憑直覺進行優化時，成本優化往往會失敗。
在更改路由規則之前，請記錄：
- 路由或功能名稱
- 模型
- 輸入 tokens
- 輸出 tokens
- 快取命中或未命中
- 重試次數
- 用戶感知的延遲
這能讓您回答關鍵問題：
- 哪個路由昂貴是因為它確實有用？
- 哪個路由昂貴是因為 prompt 浪費？
- 哪個路由應該轉向批次處理？
- 哪個路由應該轉向更便宜的模型層級？
如果您無法回答這四個問題，您的「成本優化」只會是將成本轉移到別處。
6. 實際的優化順序
最有效的順序通常是：
- 消除明顯的 token 浪費。
- 開啟或修復快取。
- 將廉價任務與昂貴任務分開。
- 將任何非緊急任務改為批次處理。
- 最後才重新協商供應商組合。
這個順序很重要，因為最大的節省通常發生在切換供應商之前。如果您在不修復 prompt 結構的情況下更換供應商，您仍會繼續為同樣的低效率支付費用。
7. 具體的優化前後對比
以一個目前的支援工作流為例，它在每次請求中都執行以下操作：
- 發送 2,000 tokens 的 system prompt
- 對所有請求調用同一個頂級模型
- 在臨時失敗時重試相同的請求結構
- 同步運行每晚摘要，而非批次處理
第一個版本通常感覺「簡單」，因為它只有一條代碼路徑。但在財務上，它同時在做四件昂貴的事情。
更高效的部署看起來像這樣：
- 將穩定的政策文本移至 prompt 前端，以便快取能真正命中。
- 將分類、擷取和簡短摘要路由到更便宜的模型層級。
- 將頂級模型保留給升級處理、複雜推理或最終答案合成。
- 將隔夜摘要和回填推送到批次處理。
- 每週審查日誌，找出 prompt 結構偏移並破壞快取效率的路由。
這種部署不需要重寫代碼。它需要一週的檢測工作，以及將 prompts 和路由視為生產環境重要環節的意願。
8. 應避免的做法
浪費成本優化努力最快的方法就是優化了錯誤的東西。
避免這些陷阱：
- 在衡量 prompt 浪費之前更換供應商
- 在未驗證輸出質量的情況下將廉價任務路由到廉價模型
- 在每次請求前綴都會改變的 prompts 上啟用快取
- 將真正需要即時響應的面向用戶工作改為批次處理
- 僅關注 token 價格而忽略重試、延遲和備援（fallback）開銷
當節省成本後產品表現依然良好時，成本優化才是成功的。如果用戶體驗變差，試算表上的節省就是虛假的。
總結
| 技術 | 投入難度 | 典型節省比例 |
|---|---|---|
| Prompt caching | 低（添加 cache_control） | 輸入成本 40-75% |
| 模型路由 | 中（任務分類） | 總體成本 30-50% |
| 批次處理 | 中（非同步工作流） | 批次任務 50% |
| Token 減量 | 低（精簡 prompts） | 輸入成本 10-30% |
這些技術具有疊加效應。一個實施了這四項技術的團隊，實際上可以在不降低輸出質量的情況下，將每月 API 帳單從 $3,000 降至 $1,000 以下。
核心見解：AI API 的成本優化不在於尋找更便宜的供應商，而是在於針對每個特定任務，以正確的價格層級、正確的快取策略使用正確的模型。
如果您已經在使用多個供應商，營運方面也很重要。migration guide 和 OpenRouter comparison 可以幫助您決定何時該集中路由，而不是繼續修補分開的整合方案。
今天就開始優化：LemonData 讓您透過一個 API key 存取 300 多個模型，支援 OpenAI 和 Anthropic 模型系列的 prompt caching，並提供一個統一的地方來比較各模型的用量。