如何從 OpenAI API 遷移到微調本地模型：90 天行動手冊

OpenAI 與美國國防部簽署了合約。Anthropic 拒絕了類似的交易。模型棄用持續發生。定價難以預測。而你正在運行一個依賴你無法控制的基礎設施的生產 AI 工作負載。

如果你已決定是時候擁有至少部分 AI 堆疊，這就是行動手冊。

這不是一份理論指南。它是一個 90 天的運營計劃，用於將真實的 AI 工作負載——你流量最高、最可預測的任務——從雲端 API 轉移到你擁有並在本地運行的微調模型。到第 90 天，你將擁有一個無需按 token 付費、無需擔心供應商行為改變、無需擔心策略轉變的生產 AI 系統。

何時不遷移

在開始之前，誠實地評估哪些工作負載是好的候選者，哪些不是。

不要遷移以下任務：需要對新穎、開放式問題進行前沿推理（最高水準的創意寫作、跨廣泛領域的複雜多步驟推理）；流量非常低（每月少於 1,000 次 API 呼叫——在這種規模下雲端更便宜）；頻繁改變其輸入/輸出要求，使訓練資料維護成本高昂；或真正需要開源尚未趕上的最新模型功能。

好的遷移候選者具有：高流量（每月 10,000 次以上呼叫）；一致、狹窄的任務範圍（分類、提取、具有定義格式的摘要、特定領域的問答）；來自日誌或現有標記範例的可用訓練資料；以及在特定任務上 90-95% 準確率就足夠的品質要求（對大多數特定領域的工作負載而言確實如此）。

遷移前稽核

在編寫任何訓練資料之前，盤點你的 AI 工作負載。對於每個用例，記錄：每月流量、每月 API 成本估算、任務類型（分類/提取/生成/問答）、輸入/輸出格式是否一致，以及你是否有或能創建 200 個以上的好範例。

對每個用例評分：高流量 × 一致任務 × 可用訓練資料 = 高遷移優先級。選擇你排名前 1-3 的候選者。從一個開始。不要嘗試一次遷移所有內容。

第 1-30 天：建立評估基礎

遷移中最重要的工作是評估。你需要能夠在生產環境中切換任何內容之前，測量微調模型是否實際上匹配你當前的 API 設置。

建立訓練資料集

從你的 API 日誌（大多數 API 提供商允許你匯出）中，收集模型產生良好輸出的範例。你在尋找：

200-500 個高品質的輸入/輸出對，代表你用例的真實分佈
涵蓋常見模式（看起來相似的 80% 輸入）和邊緣案例（更難的 20%）
乾淨的輸出——不要包含 API 產生了你不得不手動修正的內容的範例

將它們格式化為 JSONL，結構為 {"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}。

如果你沒有 API 日誌，手動創建範例。200 個高品質範例勝過 2,000 個雜亂的範例。品質優於數量是最重要的微調原則。

建立評估集

與訓練資料分開：50-100 個你不會用於訓練的保留範例。這是你衡量模型品質的方式。

確保你的評估集包含可能暴露失敗的邊緣案例——不尋常的輸入格式、邊界條件、你真實工作負載中最難的 10%。

建立 API 基準

通過你當前的 API 設置運行你的整個評估集，並記錄每個輸出。計算你的基準指標（分類的準確率、生成的 ROUGE/BLEU、開放式任務的人工判斷分數）。

現在定義你的驗收標準：微調模型需要達到什麼才能替換 API？常見目標是評估集上 API 基準的 ±5% 以內。一些團隊的目標是匹配效能；其他人接受小幅下降以換取成本和控制優勢。

第 31-60 天：微調和驗證

選擇你的基礎模型

對於大多數特定領域的任務，在你的資料上微調的 7B-14B 參數模型將匹配或超越 GPT-4 等級的效能。更大的基礎模型並不總是更好——它們更慢、運行成本更高，而微調增益通常更小。

推薦的起始點：

Llama 3.1 8B 或 3.3 70B（Meta）：允許商業使用；Llama 3 社群許可證允許重新分發微調模型
Qwen 2.5 7B 或 14B（阿里巴巴）：允許商業使用；強大的多語言效能
Mistral 7B（Mistral）：Apache 2.0 許可證——完全允許商業使用
Phi-4（Microsoft）：MIT 許可證；在小型規模上具有出色效能

如果你的任務涉及長文件或複雜推理，從 14B 範圍開始。如果你的任務狹窄且流量高（分類、提取），7B 通常就足夠了。

使用 Ertas Studio 微調

上傳你的訓練資料集，選擇你的基礎模型，並配置 LoRA（Low-Rank Adaptation）設置。LoRA 微調在凍結的基礎模型之上訓練一個小型適配器層——高效、快速，生成的適配器通常為 50-200MB，而不是完整的模型大小。

設置大約需要 2 分鐘。在雲端 GPU 上使用 500 個範例訓練 7B 模型通常在一小時內完成。

與你的基準進行評估

在你的完整評估集上運行微調模型。與你在第 1-30 天建立的 API 基準進行比較。

如果品質符合你的驗收標準：匯出為 GGUF 格式並繼續部署。

如果品質不達標：最常見的修復方法是：

擴展訓練資料（添加 200 個更多高品質範例，針對模型失敗的案例）
調整 LoRA 秩（更高的秩 = 更多的學習能力；如果你從秩 8 開始，嘗試秩 16 或 32）
嘗試更大的基礎模型（7B → 14B）
審查你的訓練資料品質——不一致的範例比數量不足更讓模型困惑

大多數團隊需要 1-2 次迭代。在重新考慮任務的遷移準備程度之前，三輪改進是合理的上限。

匯出為 GGUF

GGUF 是一種在 Ollama、llama.cpp、LM Studio 和其他推理運行時上運行的開放格式。匯出為 GGUF 給你一個可在任何相容硬體上運行的可攜帶模型——無需雲端依賴、無需推理 API，只需你擁有的權重。

第 61-90 天：並行部署和切換

這是你降低過渡風險的地方。你在 API 旁邊運行微調模型，逐漸轉移流量。

第 9 週：在你的本地基礎設施上部署微調模型（Ollama 是最簡單的起點——ollama run your-model）。將 10% 的生產流量路由到微調模型。監控輸出的品質問題。

第 10 週：如果第一週的品質指標符合你的預期，將 25% 的流量路由到微調模型。開始追蹤成本節省。

第 11 週：路由 50% 的流量。審查觸發回退到 API 的任何案例——這些是下一次微調迭代的邊緣案例候選者。

第 12 週：如果所有指標保持，將 100% 的流量路由到微調模型。保留 API 整合程式碼，但對此工作負載停用它。在建立信心的同時，留它作為備用 30 天，然後評估是否完全移除它。

經濟效益

以一個真實例子：一家在 OpenAI API 上運行 15 個客戶自動化工作流程的機構每月花費 AU$4,200。在共享基礎設施上本地運行的每個客戶 LoRA 適配器的費用為每月 AU$14.50。這是 99.6% 的削減——而微調模型在特定領域任務上實際上超越了 API。

在一個獨立 SaaS 應用的 8,000 個用戶上：每月 $620 的雲端 API 費用在本地推理上變成約 $28/月。在 40,000 個用戶時，雲端費用為每月 $3,000。本地費用仍然約為每月 $28——一旦基礎設施運行，每次查詢的成本本質上為零。

微調投資（訓練資料的時間 + 微調計算成本）的盈虧平衡通常在中等流量下為 2-4 個月。

第 90 天你擁有的內容

一個生產 AI 工作負載，具有：

固定模型版本：你決定何時更新，而不是你的供應商
確定性行為：模型在你訓練新版本之前不會改變
零按查詢費用：本地推理以基礎設施成本運行，而不是按 token
完全可攜帶性：GGUF 在任何相容硬體上運行
完整的治理：你確切知道模型是在什麼資料上訓練的、何時以及由誰訓練

無供應商行為改變。無策略轉變。無棄用通知。無漲價。模型是你的。

查看早鳥定價 →

Ertas Studio 處理從資料集上傳到 GGUF 匯出的整個管道——不需要 Python、不需要 YAML 配置、不需要 CLI。從免費帳戶開始，在承諾任何事情之前微調你的第一個模型。