從提示快取到微調：何時做出轉換

當 AI API 費用開始攀升時，提示快取是大多數團隊首先採用的最佳化方式。它確實有效——Anthropic 的提示快取可將快取 token 的費用降低高達 90%，OpenAI 也提供類似的節省。對於許多工作負載而言，快取在數月甚至數年內都是正確的答案。

但快取有其上限。它最佳化了每個 token 的成本，但沒有消除按 token 計費的經濟模式。在某一規模或某些工作負載配置下，您將達到這個上限，需要做出不同的架構選擇：微調您擁有並在本地運行的模型。

本指南介紹快取何時足夠、何時不夠，以及如何完成過渡。

提示快取的工作原理

Anthropic 和 OpenAI 現在都提供提示快取，可顯著降低重複上下文的成本。

機制很簡單：如果您提示的前 N 個 token 在請求之間相同，這些 token 將被快取在提供商的基礎設施上。後續共享相同前綴的請求只需支付正常輸入 token 成本的一小部分。

Anthropic 提示快取：

• 快取輸入 token：90% 折扣（您支付正常輸入價格的 10%）
• 最小可快取前綴：Claude Sonnet 為 1,024 個 token，Haiku 為 2,048 個
• 快取 TTL：5 分鐘（每次命中時刷新）

OpenAI 提示快取：

• 快取輸入 token：50% 折扣
• 超過 1,024 個 token 的提示自動快取
• 自 2025 年底起無需明確選擇加入

對於具有 2,000 個 token 系統提示且在請求之間保持不變的典型 SaaS 用例，節省是顯著的：

僅通過快取系統提示就可節省 72% 的費用。無需更改代碼，無需更改模型，對品質沒有影響。

提示快取是正確答案的情況

在以下條件成立時，快取是最佳選擇：

1. 您有一個大型、穩定的系統提示。 系統提示相對於用戶輸入越大，節省越多。5,000 個 token 的系統提示搭配 200 個 token 的用戶輸入，比 800 個 token 的系統提示搭配 2,000 個 token 的用戶輸入節省更多。

2. 您的請求量適中。 每月 10,000–100,000 個請求時，快取可能足以降低成本，使剩餘費用可以接受。微調有前期時間投入，需要通過持續節省來證明其合理性。

3. 您的用例頻繁變化。 如果您每週都在迭代 AI 功能——更改系統提示、添加新任務類型、試驗格式——快取讓您無需再訓練就能迭代。微調鎖定了需要付出努力才能改變的行為。

4. 您還沒有訓練資料。 快取從第一天起就能工作，無需任何資料。微調需要 500–5,000 個高品質的訓練示例。如果您處於構建 AI 功能的早期階段，快取為您爭取積累資料的時間。

5. 您需要前沿模型能力。 快取讓您以更低的成本存取最佳模型。微調給您一個在特定任務上訓練的較小模型。如果您的任務確實需要 Claude Opus 或 GPT-4o 級別的推理，快取讓您以較低的成本繼續使用這些模型。

您已超越快取的五個跡象

跡象 1：快取後 API 費用仍然過高

計算一下。如果您快取後的月度 API 成本超過 AU$5,000 且隨使用量增長，快取降低了斜率，但沒有改變基本的線性成本曲線。您仍然為每個請求的每個 token 付費，只是費率更低。

例如：SaaS 產品每月處理 500,000 個請求，系統提示 3,000 個 token：

• 不使用快取：約 AU$15,000/月
• 使用快取（Anthropic，快取 token 90% 折扣）：約 AU$5,200/月
• 使用微調本地模型：約 AU$1,200/月（固定基礎設施）

快取降低了 65% 的費用。但本地模型降低了 92% 的費用。在這個量級，每月額外節省 AU$4,000 可以證明微調投資是合理的。

跡象 2：大多數 token 在用戶輸入中，而非系統提示

快取只對重複的前綴有幫助。如果您的請求有短系統提示和長的唯一用戶輸入——文檔處理、電子郵件分析、代碼審查——可快取部分很小。您可能從 8,000 個 token 中快取 1,000 個。折扣僅適用於 12.5% 的輸入 token。

在這些情況下，快取節省 5–15% 而非 60–90%。這不足以改變您的利潤狀況。

跡象 3：您的任務定義明確且重複性強

如果您 80% 的 AI 請求遵循相同的模式——相同的輸入格式、相同的輸出格式、相同的任務類型——這是微調的信號。這些模式正是微調所捕捉的。微調模型在沒有系統提示的情況下產生相同的輸出品質，因為行為已內化在模型權重中。

快取最佳化了向通用模型傳遞指令的方式。微調消除了模型已學習的任務對指令的需求。

跡象 4：您想擁有自己的模型和資料管道

快取讓您繼續使用他人的基礎設施，受其定價變化、棄用計劃和速率限制的約束。微調給您一個完全由您控制的模型。您可以在自己的硬體上運行它，在氣隙環境中部署它，永遠不用擔心 API 提供商更改條款。

跡象 5：延遲很重要，快取還不夠

快取提示比未快取的更快，但它們仍然是雲端 API 調用。典型延遲：快取請求 500–2,000ms。本地微調模型在像樣的硬體上：同一請求 50–200ms。如果您的產品需要低於 200ms 的 AI 響應——實時建議、內聯自動完成、互動工作流程——本地推理是正確的路徑。

決策框架

以下是表格形式的框架：

如果您在「切換到微調」欄中勾選了 3 項以上，是時候規劃遷移了。

遷移路徑：從快取到微調

過渡不是二元切換。以下是逐步流程：

步驟 1：審計您的快取工作負載（1 週）

分析您過去 30–60 天的 API 日誌：

• 您有多少個不同的任務類型？
• 快取 token 與唯一 token 的百分比是多少？
• 請求複雜性的分布是什麼？
• 哪些任務具有最一致的輸入/輸出模式？

步驟 2：構建訓練資料集（1–2 週）

您現有的 API 響應就是您的訓練資料。對於您想要遷移的每種任務類型：

• 從 API 日誌中導出 2,000–5,000 個請求-響應對
• 篩選高品質響應（用戶沒有重新生成或編輯的響應）
• 格式化為指令-響應對

您已經擁有這些資料——它在您的 API 日誌中。您已經為每次 API 調用付費積累了它。現在它成為消除未來 API 成本的資產。

步驟 3：微調和評估（1 週）

對您的資料集微調 7B 或 14B 模型。使用 QLoRA，這需要不到 2 小時的 GPU 時間。然後評估：

• 在 200–500 個示例測試集上運行微調模型
• 將輸出與您的 API 黃金標準進行比較
• 根據您的特定標準（精確度、格式符合度、語氣）評分品質
• 目標：對定義明確的任務達到 90–95% 以上的品質對等

步驟 4：部署和路由（1 週）

通過 Ollama 或 llama.cpp 在 OpenAI 相容 API 端點後面部署微調模型。更新路由以將已遷移的任務類型發送到本地模型。保留雲端 API 作為備用。

步驟 5：監控和迭代（持續進行）

在生產中追蹤品質指標。常見監控方法：

• 對 5% 的本地模型響應進行影子評分，與雲端 API 比較
• 追蹤用戶反饋信號（重新生成率、編輯距離、滿意度分數）
• 每月用模型處理不佳的新生產示例進行再訓練

您在雲端 API 上保留的內容

微調並不完全替代雲端 API。以下內容保留在快取雲端 API 調用上：

• 新的實驗性功能，您仍在迭代提示和任務定義的地方
• 長尾邊緣案例，您的微調模型見過的示例還不夠多
• 需要廣泛世界知識的任務，這些知識隨時間變化（時事、近期資料）
• 複雜多步驟推理，確實受益於超過 2,000 億參數模型

大多數 SaaS 產品的最終狀態是混合：70–90% 的請求使用微調本地模型，10–30% 使用快取雲端 API 調用。您的大部分流量獲得本地推理的成本結構，需要的任務獲得前沿模型的能力。

規模化成本比較

以下是 SaaS 產品從每月 100,000 增長到 500,000 個請求的 12 個月成本預測：

與原始 API 調用相比，快取在 12 個月內節省了 AU$70,200。微調混合在快取基礎上再節省 AU$19,500——與僅 API 相比總節省 AU$89,700。

差距隨規模擴大。每月 100 萬個請求時，微調混合的費用與 50 萬個請求時大致相同（基礎設施相同）。API 和快取 API 選項都翻倍。

過渡不是永久的

這種遷移路徑的一個優點是：它是可逆的。如果微調模型在某個任務類型上表現不佳，您將該任務類型路由回雲端 API 並添加更多訓練資料。您不會被鎖定。

您的路由層給了您一個旋鈕，而不是開關。隨著微調模型的改進，逐漸向本地推理轉移，並保持雲端 API 可用於需要它的任務。

出色執行這一過渡的團隊最終兩全其美：複雜任務上的前沿模型品質，其他所有任務上的微調模型效率，以及與業務一起擴展而非相互對抗的成本結構。

---

延伸閱讀

• 從提示工程到微調 — 從提示到微調模型的完整旅程
• 如何微調 LLM — 您第一個模型的逐步微調指南
• 從 API 畢業到微調 — SaaS 專用遷移手冊