從原型到產品：用微調模型替換 API 調用

您的原型已能正常工作。您用 Lovable 或 Bolt 或 Replit 構建了它，接入了 OpenAI API，用戶開始註冊。也許您有 500 個用戶，也許 2,000 個。產品-市場契合感覺很真實。

但這裡有個在「先把它發布出去」階段沒有考慮到的問題：每一次 AI 互動都要花錢。每次調用費用不多——可能是 $0.003 到 $0.02，取決於模型和 token 數量——但加起來就很可觀了。在 2,000 個用戶每天發出 10 個 AI 請求的情況下，您每月僅 API 費用就要燒掉 $600–$1,200。

您的原型能用。但您的單位經濟不成立。

本指南是從雲端 API 遷移到微調本地模型的逐步手冊。它是為擁有可運作產品且需要讓經濟效益成立的開發者而寫的——無需破壞已有效的功能。

沒人談到的原型到生產差距

每個 AI 教程都在同一個地方結束：「現在您的應用使用 GPT-4！」沒有人談論第 3 個月當您有了用戶，API 費用成為重要支出項目時會發生什麼。

原型和生產之間的差距不是代碼品質或測試覆蓋率。對於快速開發的應用，是成本結構。您的原型假設了無限廉價的 API 調用。生產需要可預測、有邊界的成本。

好消息是：您不必重寫您的應用。您不需要成為機器學習工程師。您需要用您自己擁有和運行的模型替換最昂貴的 API 調用。其餘部分保持不變。

第一階段：審計您的 API 使用情況

在更改任何東西之前，先了解您的支出情況和位置。記錄兩週的每個 API 調用。對於每次調用，追蹤：

• 端點/功能：您應用中的哪個功能觸發了它？
• 輸入 token：提示有多大？
• 輸出 token：響應有多大？
• 頻率：每天發生多少次此調用？
• 每次調用成本：輸入 token × 輸入價格 + 輸出 token × 輸出價格。

您通常會發現類似這樣的情況：

這個審計是最重要的步驟。它告訴您確切應該關注哪裡。

第二階段：識別微調候選項目

並非每個 API 調用都應該被替換。尋找以下調用：

• 高量：每天發生數千次的調用。即使很小的每次調用節省也會累積。
• 重複性：模型每次基本上執行相同類型的任務。分類這個，總結那個，提取這些字段。
• 特定領域：您的應用有特定的詞彙、格式或領域。通用 GPT-4 是過度設計。
• 類模板輸出：響應遵循一致的結構或格式。

在上面的示例中，最佳候選項目是：

1. 內容分類 — 高量、簡單任務、結構化輸出。微調的 3.8B 模型可以輕鬆處理。
2. 語氣分析 — 簡單分類任務。不需要前沿模型。
3. 摘要生成 — 具有一致格式的重複任務。微調 7B 模型的領域。
4. 聊天回覆 — 最大的支出。更複雜，但如果您的聊天遵循模式（客戶支援、特定領域問答），微調 8B 模型效果很好。

保留在 API 上的內容：

5. 複雜分析 — 低量、高複雜度、可變推理。保留在 GPT-4o 或 Claude 上。它只佔支出的 11%，但需要前沿模型能力。

第三階段：從您的 API 日誌收集訓練資料

您幾個月來一直在向 OpenAI 付費。好的一面是：您進行的每一次 API 調用都是一個訓練示例。

對於每個微調候選項目，從您的日誌中提取 2,000–5,000 個輸入-輸出對。篩選品質：

• 刪除用戶抱怨或更正輸出的示例
• 刪除有錯誤響應或截斷輸出的示例
• 刪除異常值（異常長的提示、邊緣案例）
• 保留代表每個功能「正常路徑」的示例

格式化為 JSONL：

{"input": "分類以下客戶消息：'我需要更新我的帳單地址'", "output": "category: account_management, intent: update_info, urgency: low"}

專業提示：如果特定功能的示例不夠，再積極記錄一週。2,000 個乾淨的示例是良好微調的最低標準，5,000 個更好。

第四階段：使用 Ertas 進行微調

對於每個候選功能，訓練一個獨立的 LoRA 適配器。為什麼要分開？因為每個功能有不同的要求，分開的適配器讓您可以更新一個而不影響其他的。

以下是實際工作流程：

1. 上傳您的資料集到 Ertas Vault。每個功能一個資料集。
2. 選擇您的基礎模型。對於簡單任務（分類、提取）：Phi-4 3.8B。對於中等任務（摘要、生成）：Qwen 2.5 7B 或 Llama 3.3 8B。
3. 配置訓練。默認值效果很好。如果您想調整：3–5 個 epoch，學習率 2e-4，LoRA rank 16–32。
4. 訓練。根據資料集大小，每個適配器需要 20–60 分鐘。
5. 評估。Ertas 在保留的測試集上顯示精確度指標。在繼續之前，您希望任務上的匹配率超過 90%。

如果精確度低於 85%，修復方法幾乎總是資料品質。回到您的訓練示例，刪除嘈雜的示例，添加更多代表性示例，然後重新訓練。

第五階段：與您的應用一起部署

將每個微調模型導出為 GGUF 文件（Q5_K_M 量化）。部署到運行 Ollama 的 VPS。

您的生產設置如下所示：

┌─────────────┐     ┌──────────────────────┐
│  您的應用    │────▶│  您的 VPS（Ollama）   │
│  (Vercel /   │     │                      │
│   Railway)   │     │  ├─ classify-model   │
│              │     │  ├─ summary-model    │
│              │────▶│  └─ chat-model       │
│              │     └──────────────────────┘
│              │
│              │     ┌──────────────────────┐
│              │────▶│  OpenAI API          │
│              │     │  （僅複雜任務）        │
└─────────────┘     └──────────────────────┘

Ollama 在端口 11434 提供 OpenAI 相容 API。您的應用代碼幾乎不需要更改——您只是在替換 URL 和模型名稱，而不是重寫邏輯。

對於單個伺服器上的多個模型，Ollama 自動處理模型加載和卸載。一個 32GB RAM 的 VPS（每月 $50–80）可以輕鬆提供 2–3 個微調 7B 模型。

第六階段：漸進式遷移

不要一次性切換。逐步遷移：

第 1 週——影子模式。 將每個請求同時發送到微調模型和 API。比較輸出。暫時不向用戶提供微調輸出。記錄差異。

第 2 週——10% 路由。 將 10% 的流量路由到微調模型。監控用戶行為——完成率、參與指標和錯誤率是否穩定？

第 3 週——50% 路由。 一半流量轉到微調模型。您的 API 費用應該明顯下降。注意微調模型處理不佳的邊緣案例。

第 4 週——完全切換。 將所有候選流量路由到微調模型。對於信心度低的請求，保留 API 作為備用。

這種漸進式方法讓您在影響所有用戶之前發現問題。這是「我們順利遷移了」和「我們讓應用宕機了一天」之間的差別。

前後架構對比

之前：全部 API

• 每個 AI 功能 → OpenAI API
• 成本：每月 $3,834 且在增長
• 風險：一次 API 定價變更就能讓您的業務崩潰
• 延遲：每個請求 200–800ms（網路 + 推理）

之後：混合架構

• 分類、語氣、摘要、聊天 → VPS 上的微調模型
• 複雜分析 → OpenAI API（保留用於邊緣案例）
• 成本：$80/月（VPS）+ $14.50/月（Ertas）+ 約 $120/月（複雜任務的 API）= $214.50/月
• 節省：$3,619/月（降低 94%）
• 延遲：本地模型 50–200ms，比 API 更快

這不是筆誤。從 $3,834 降到 $214.50，就是當您停止為小型微調模型能更好地處理的任務按 token 付費時會發生的事情。

哪些應保留在 API 上

誠實面對微調模型無法做到的事情：

• 開放式創意任務，用戶可以字面上問任何問題
• 需要前沿模型能力的複雜多步推理
• 訓練示例少於 500 個的任務（不夠進行良好的微調）
• 您仍在迭代的新功能（在功能穩定之前使用 API，然後再微調）

目標不是零 API 成本。而是將正確的請求路由到正確的模型。前沿模型用於前沿任務。您的模型用於您的任務。

遷移心態

大多數快速開發者錯過的一點是：從 API 到微調模型的遷移不是一次性的項目。這是一種思維方式的轉變。

每個新功能都從 API 開始。這沒問題——它是驗證的最快方式。但一旦功能穩定，您知道什麼是好的輸出，您就進行微調。您把它移到您的技術棧中。您擁有它。

隨著時間推移，您的 API 成本漸近地接近一個小的固定數字——只有真正複雜的東西。所有例行的東西都在您擁有的模型上運行，在您控制的基礎設施上，成本不隨您的用戶增長。

這就是 2026 年快速開發應用的生產環境應有的樣子。

---

延伸閱讀

• 從 OpenAI API 遷移到微調本地模型 — 將 API 調用替換為本地推理的技術深度解析。
• 從 Lovable 原型到真實產品 — 從原型到生產還會發生什麼其他變化。
• 為您的應用微調模型 — 在您的特定用例上訓練模型的端到端指南。