Token 優化策略與成本控制：系統化降低 API 成本
Token是Claude API計費的基本單位。1 Token ≈ 4 個字符或 1 個詞。一個看似簡單的優化決策，可能帶來 50-70% 的成本節省，同時保持甚至提升輸出品質。本文系統介紹Token成本的測量、優化策略、批處理設計，以及完整的成本計算框架。
1. Token 的基本概念
Token 計數規則
- Input Token：用戶送入的內容（提示詞 + 上下文）
- Output Token：Claude 產生的回應
- Cache Hit Token：使用快取的內容（成本降低 90%）
模型定價對比（2026年4月）
| 模型 | Input 成本 | Output 成本 | 特性 |
|---|---|---|---|
| Claude Opus 4.6 | $3/M | $15/M | 最強能力、最高成本 |
| Claude Sonnet 4.6 | $3/M | $15/M | 均衡方案、速度快 |
| Claude Haiku 4.5 | $0.80/M | $4/M | 輕量任務、成本低 75% |
| Prompt Caching | $0.30/M | — | 快取 Input（成本減 90%） |
計費範例：100K tokens input + 50K tokens output（Opus）= (100K × $3/M) + (50K × $15/M) = $0.30 + $0.75 = $1.05
2. 第一層優化：模型選擇
40% 的成本節省來自選擇合適的模型。不是所有任務都需要 Opus：
| 任務類型 | 推薦模型 | 成本節省 | 說明 |
|---|---|---|---|
| 簡單歸類、提取 | Haiku | 75% | 邏輯簡單，Haiku足夠 |
| 客服自動回覆 | Haiku + Few-Shot | 70% | 模式固定，無需推理 |
| 數據清洗、格式轉換 | Haiku | 75% | 結構化任務 |
| 複雜推理、創意生成 | Sonnet | 0% | 需要平衡性能與成本 |
| 最高難度推理 | Opus | 0% | 必要投資 |
案例 1：模型選擇帶來的成本改善
場景：批量處理 10,000 個客戶評論，分類情感（正面/中立/負面）。
原方案（Opus）：
• 每個評論平均 150 input + 20 output tokens
• 10K × (150 × $3/M + 20 × $15/M) = $5.50
優化方案（Haiku）：
• 相同大小，但用 Haiku
• 10K × (150 × $0.80/M + 20 × $4/M) = $1.38
• 成本節省：75%（$4.12）
準確率差異：Opus 95%，Haiku 92%。對情感分類而言，3% 差異可接受。
3. 第二層優化：提示詞精煉
不必要的文字最容易被忽視，但佔用最多token。以下技巧可減少 20-40% 的input tokens：
五項精煉規則
- 移除冗餘例子：3-5 個 Few-Shot 例子足夠，超過 10 個開始浪費
- 使用短變數名：「customer_name」vs「c_name」可節省 10% 的token
- 精簡系統提示詞：「你是一個X領域的專家，有Y年經驗...」改為「X領域專家」
- 刪除說教語氣：「請你一定要非常仔細地...」無意義，直接說需求
- 結構化 vs 自然語言：JSON 結構化指令比自然語言節省 15-25% token
案例 2：提示詞精煉的實測效果
原始版本（冗長）：
你是一位在數據科學領域擁有15年經驗的資深專家，深諳各種機器學習演算法和統計學原理。
請你非常仔細地分析下面的數據集，並請確保你的分析非常準確和詳細。
我們需要你進行以下分析：
1. 描述數據的基本統計特性
2. 識別潛在的異常值
3. 提出改善建議
請確保你的回答清晰、全面、準確。
[數據]Token 消耗：約 130 tokens
精煉版本：
數據科學家。分析以下數據：
1. 基本統計（平均、標準差、分佈）
2. 異常值
3. 改善建議
[數據]Token 消耗：約 50 tokens
節省：61% tokens，品質差異 <5%
4. 第三層優化：批處理與分批策略
批量處理帶來 2 重好處：（1）攤薄系統提示詞成本，（2）啟用緩存。
批處理架構
【系統提示詞 200 tokens】（一次付款，多個任務共用）
Task 1: [問題] → [回答]
Task 2: [問題] → [回答]
Task 3: [問題] → [回答]
...
Task 50: [問題] → [回答]成本計算：
- 系統提示詞成本：200 tokens（50個任務共用）→ 平均每個任務 4 tokens
- 逐個調用：需要支付 50 × 200 = 10,000 tokens 系統提示詞成本
- 批處理節省：99.6% 的系統提示詞成本
案例 3：批處理實例
場景：翻譯 100 篇文章從英文到繁體中文。
方案 A（逐個翻譯）：
• 系統提示詞：「你是翻譯專家...」（200 tokens）
• 每篇文章：平均 2,000 input + 2,200 output tokens
• 成本：100 × (200 + 2000 × $3/M + 2200 × $15/M) = ~$3,400
方案 B（批處理，10 篇/批）：
• 系統提示詞：200 tokens（10篇文章共用）
• 10 批 × (200 + 10 × 2000 × $3/M + 10 × 2200 × $15/M) = ~$3,200
• 節省 5.9%
方案 C（批處理 + 提示詞緩存）：
• 系統提示詞 200 tokens（50 篇文章，啟用緩存）
• 首批（建立快取）：200 + 50 × 2000 × $3/M + 50 × 2200 × $15/M = ~$1,650
• 第二批（快取命中）：50 × 2000 × $0.30/M + 50 × 2200 × $15/M = ~$1,650
• 100 篇總成本：$3,300 → 成本節省 3% vs逐個，但速度 +40%
5. 第四層優化：Prompt Caching
Prompt Caching 是成本優化的終極武器。相同的 System Prompt 或上下文被重複使用時，後續調用的成本降低 90%。
快取的三大應用場景
- 持久系統提示詞：相同的 system message 被數千個請求共用（客服機器人、內容分類）
- 大型知識庫：相同的參考文檔被反複查詢（FAQs、技術文檔）
- 多輪對話：對話歷史被保留且不斷增長
案例 4：快取帶來的規模效應
場景：24小時內，1,000 個客戶提出客服問題。系統提示詞恆定。
無快取：
• System Prompt（200 tokens）× 1,000 請求 × $3/M = $0.60
• 用戶問題（平均 100 tokens）× 1,000 = $0.30
• 回答（平均 200 tokens）× 1,000 × $15/M = $3.00
• 總成本：$3.90
啟用快取：
• System Prompt 首次：200 × $3/M = $0.0006（另計入base成本）
• System Prompt 後續 999 次：200 × 999 × $0.30/M = $0.06（90% 折扣）
• 用戶問題：$0.30（不變）
• 回答：$3.00（不變）
• 總成本：$3.36（節省 13.8%）
6. 第五層優化：上下文管理
多輪對話中的上下文會快速增長。優化策略：
四項上下文控制規則
- 對話摘要：每 10 輪對話，生成摘要替換舊內容（減少 50-70% tokens）
- 優先級排序：最近 5 輪保留，更早的對話進行摘要
- 相關性過濾：移除與當前問題無關的歷史（減少 30-40% tokens）
- 重置邊界：對話超過 10,000 tokens 時，開始新對話而非無限延長
【對話 1-10】完整保留（2,000 tokens）
【對話 11-20】保留摘要而非完整內容（300 tokens）
【對話 21-30】超過 10K token 閾值 → 新對話開始7. 成本計算與監控框架
成本監控三層模型
- 請求層：每個 API 呼叫記錄 input/output tokens
- 特性層：按功能（客服、翻譯、分類）統計成本
- 用戶層：按客戶/產品統計成本分佈
案例 5：完整的成本監控實例
情景：SaaS 應用，日均 5,000 API 呼叫。
日均成本分析：
【功能維度】
- 客服回答（60% 調用）：5,000 × 0.6 × $0.15 = $450/天
- 內容翻譯（25% 調用）：5,000 × 0.25 × $0.40 = $500/天
- 數據分類（15% 調用）：5,000 × 0.15 × $0.08 = $60/天
日成本：$1,010
月成本：$30,300
【優化機會】
- 客服轉用 Haiku（節省 75%）：$450 → $112.50 （-$337.50/天）
- 翻譯啟用快取（節省 30%）：$500 → $350 （-$150/天）
- 分類優化提示詞（節省 20%）：$60 → $48 （-$12/天）
優化後月成本：$19,845（節省 34.5%）8. 成本 vs 品質平衡
並非所有節省都值得。以下決策框架幫助判斷：
| 優化類型 | 成本降低 | 品質影響 | 推薦指數 |
|---|---|---|---|
| 模型降級（Opus→Haiku） | 75% | -3% 準確率 | ⭐⭐⭐ 簡單分類 |
| 提示詞精煉 | 30% | 0%（無損） | ⭐⭐⭐⭐⭐ 必做 |
| 批處理 | 5-15% | 0%（無損） | ⭐⭐⭐⭐ 推薦 |
| Prompt 緩存 | 10-20%（高重複時） | 0%（無損） | ⭐⭐⭐⭐⭐ 必做 |
| 上下文摘要 | 20-40% | -2% 連貫性 | ⭐⭐⭐ 長對話 |
| 減少 Few-Shot 例子 | 10-20% | -5-10% 準確率 | ⭐⭐ 謹慎 |
9. 實務優化工作流
一個月的成本優化計劃
- Week 1：審計與監控
• 記錄所有 API 調用的 input/output tokens
• 按功能分類，找出成本最高的 3 個功能
• 建立成本基線 - Week 2：快速勝利
• 優化 Week 1 找出的成本最高功能的提示詞
• 預期節省 20-30% - Week 3：架構改進
• 實施批處理（如適用）
• 啟用 Prompt 緩存
• 預期額外節省 10-20% - Week 4：模型優化
• 評估是否可從 Opus 降級至 Sonnet 或 Haiku
• 測試品質損失是否可接受
• 預期額外節省 30-50%（如適用）
10. 常見誤區
誤區 1：過度優化成本而損失品質
症狀：使用 Haiku 進行需要 Opus 的複雜推理，結果準確率降至 60%。
改善：先測量品質損失。如果品質損失 >10%，不值得節省 50% 成本。
誤區 2：忽視快取的設置複雜性
症狀：計劃中快取可以節省 50% 成本，但實施需要 2 周工作。
改善：優先實施 ROI 高的優化（提示詞精煉、批處理），再考慮快取。
誤區 3：不考慮延遲的成本
症狀：批處理省成本，但延遲增加，影響用戶體驗。
改善：對延遲敏感的功能（如客服），優先考慮品質。對離線任務，優先考慮成本。
總結
系統化的 Token 優化可帶來 50-70% 的成本節省，同時保持甚至提升品質。核心策略：
- ✅ 第一層：選擇合適的模型（30-40% 節省）
- ✅ 第二層：精煉提示詞（20-30% 節省）
- ✅ 第三層：批處理設計（5-15% 節省）
- ✅ 第四層：Prompt 緩存（10-20% 節省，高重複場景）
- ✅ 第五層：上下文管理（20-40% 節省，長對話）
按優先級順序實施，每個優化都應有明確的 ROI 與品質檢驗。
