從 API 依賴到模型擁有者：90 天遷移操作手冊

您已閱讀關於供應商依賴風險的內容。您已完成獨立性檢查清單。您知道成本數學有利於擁有的模型。現在您需要一個計劃。

這個操作手冊涵蓋了從 API 依賴遷移到模型擁有的最初 90 天。它是為沒有 ML 專業知識的團隊設計的，假設您可以訪問您的 API 日誌和領域數據。目標不是消除所有 API 使用——而是擁有您最關鍵的 AI 能力並為持續的獨立性建立基礎。

開始之前：遷移心態

兩個原則使順暢遷移和痛苦遷移之間有所不同：

並行運行，不是冷切換。 您不是在第一天就拔掉 API 整合並用微調模型替換它。您是並排運行兩者、比較品質，並逐漸路由流量。API 保持活躍，直到微調模型證明自己。

從窄開始，系統性擴展。 不要試圖一次遷移所有內容。選擇一個任務。做對它。建立信心和機構知識。然後重複。

第一階段：稽核（第 1-14 天）

第 1 週：盤點您的 AI 接觸點

映射您的應用程序或工作流調用 AI API 的每個地方。對於每個接觸點，記錄：

大多數團隊發現他們在生產中有 3-8 個不同的 AI 任務。有些有更多。

第 2 週：評分和優先排序

在三個維度上對每個任務評分：

微調適合性（1-5）：

• 一致的輸入/輸出格式 → 更高分數
• 大量 → 更高分數
• 可用訓練數據 → 更高分數
• 特定領域詞彙或知識 → 更高分數
• 主觀或創意輸出 → 更低分數

業務影響（1-5）：

• 高每月成本 → 更高分數
• 面向客戶 → 更高分數
• SLA 敏感 → 更高分數
• 產生收入 → 更高分數

遷移複雜性（1-5，越低越好）：

• 簡單分類/提取 → 低複雜性
• 多步驟推理 → 中等複雜性
• 開放式生成 → 較高複雜性
• 多模態（文本 + 圖像） → 最高複雜性

優先級 = 適合性 × 影響 ÷ 複雜性

您得分最高的任務是您的試點遷移目標。在大多數企業中，它是以下之一：

• 客戶支持工單分類/路由
• 以特定格式生成內容
• 從結構化文件提取數據
• FAQ/知識庫響應生成
• 線索資格鑑定或評分

第二階段：試點（第 15-45 天）

第 3 週：準備您的訓練數據集

您的 API 日誌是您的訓練數據。從您的生產系統提取輸入/輸出對。

最小數據集大小： 500 個高品質示例。這對於格式一致的明確定義任務就足夠了。

推薦： 1,000-2,000 個示例。給模型更多邊緣案例來學習。

品質優於數量。 500 個經過仔細審查的示例優於 5,000 個嘈雜的示例。花時間在數據品質上，而不僅僅是數量。

數據集準備步驟：

1. 匯出原始數據。 從您的 API 日誌、CRM 或數據庫中提取輸入/輸出對。格式化為您的訓練工具期望的聊天消息結構的 JSONL。

2. 過濾品質。 刪除 API 輸出不正確、格式不良或需要手動糾正的示例。您只需要任務正確完成的示例。

3. 去重複。 幾乎相同的示例會增加噪音。刪除重複和近重複項。

4. 平衡類別。 如果您在訓練分類器，確保所有類別都有合理的代表性。極端不平衡（90% 類別 A，2% 類別 B）會導致模型在少數類別上表現不佳。

5. 分割數據。 保留 10-15% 作為不會在訓練中使用的測試集。這是您的評估基準。

第 4-5 週：微調模型

選擇您的基礎模型。 對於大多數業務任務：

• 7B 參數 — 快速推理，在消費級硬體上運行，適合分類和提取
• 14B 參數 — 更適合生成任務，需要更多計算但仍然實用
• Llama 3、Qwen 2.5 或 Mistral — 都是生產品質，都是商業寬鬆許可

選擇您的訓練方法：

• LoRA/QLoRA — 標準方法。在凍結的基礎權重之上訓練輕量級適配器（50-200MB）。內存效率高，訓練快速，適配器是可攜帶的。
• 完整微調 — 修改所有權重。對於複雜任務更好，但需要更多計算。對於明確定義的業務任務通常是不必要的。

訓練配置（起始點）：

• 學習率：2e-4
• 批量大小：4-8
• 輪次：2-3
• LoRA 秩：32

使用 Ertas： 上傳您的 JSONL 數據集，選擇您的基礎模型，開始訓練。平台處理 GPU 配置、超參數管理和進度追蹤。設置大約需要 2 分鐘。訓練時間取決於數據集大小和模型——LoRA 微調通常需要 15-60 分鐘。

運行 2-3 次實驗。 嘗試不同的基礎模型、LoRA 秩或訓練持續時間。跨實驗的並排比較有助於找到最佳配置。

第 6 週：評估

通過 API 模型和您的微調模型運行您的保留測試集。比較：

定量指標：

• 準確率（對於分類/提取任務）
• 格式合規性（輸出是否符合您的預期結構？）
• 一致性（對等效輸入的相同答案？）
• 延遲（每個請求的響應時間）

品質閾值： 對於有良好訓練數據的特定領域任務，預期：

• 分類和提取準確率 90-95%
• 在生成品質上與 API 模型相差 5-10% 以內
• 格式合規性超過 98%

如果微調模型達不到：

• 在表現不佳的領域添加更多訓練示例
• 檢查數據品質問題（錯誤標注的示例、不一致的格式）
• 嘗試更大的基礎模型（7B → 14B）
• 增加 LoRA 秩以獲得更多容量

大多數品質差距通過更好的數據而不是更大的模型來解決。

第三階段：驗證（第 46-60 天）

第 7-8 週：影子部署

將您的微調模型與 API 並排部署。通過兩個模型路由所有生產流量，但只向用戶提供 API 模型的響應。

實時比較輸出：

• 記錄每個請求的兩個響應
• 標記分歧以供人工審查
• 追蹤真實生產流量（而不僅僅是測試集性能）的品質指標
• 監控訓練數據中沒有出現的邊緣案例

影子部署捕獲靜態評估遺漏的問題：

• 輸入分佈轉移（真實流量模式與訓練數據不同）
• 罕見邊緣案例（您的測試集未涵蓋的輸入）
• 格式變化（用戶不總是像您的訓練示例那樣寫作）

第 8-9 週：A/B 測試

一旦影子部署確認品質對等，進行真正的 A/B 測試：

• 將 10-20% 的生產流量路由到微調模型
• 向這些用戶提供微調模型的響應
• 比較業務指標：用戶滿意度、任務完成率、錯誤率
• 如果指標保持，擴展到 50%
• 在每個流量百分比下至少監控一整週

繼續的決策標準：

• 在您的關鍵指標上品質在 API 模型的 5% 以內
• 用戶投訴或錯誤報告沒有增加
• 格式合規性超過 95%
• 延遲在您的應用程序可接受範圍內

開始您的 90 天遷移。Ertas 處理最難的部分——數據集準備、訓練、評估、GGUF 匯出——都在視覺界面中。以早鳥定價預訂 →

第四階段：擴展（第 61-90 天）

第 9-10 週：試點任務的生產切換

A/B 測試驗證後，將您的試點任務流量 100% 路由到微調模型。

切換檢查清單：

• 將模型匯出到 GGUF 格式
• 在您的生產推理基礎設施（Ollama、vLLM 或 llama.cpp）上部署
• 為品質指標配置監控和警報
• 維護 API 備用（保持 API 整合活躍但休眠——如果需要可以路由回去）
• 更新您的文件和操作手冊

衡量影響：

• 每月成本減少（API 賬單降低）
• 延遲改善（本地推理通常更快）
• 可靠性改善（不依賴外部 API 正常運行時間）
• 品質指標（應保持 A/B 測試期間驗證的水平）

第 11-12 週：開始下一次遷移

將相同的過程應用到您的第二優先級任務。由於您已建立了機構知識，這進行得更快：

• 您的數據管線已建立
• 您的評估框架已存在
• 您的部署基礎設施正在運行
• 您的團隊了解微調工作流

後續遷移的典型時間：3-4 週（相比第一次的 6 週）。

第 12 週：建立持續節奏

設置保持您的微調模型最新的系統：

重新訓練計劃。 隨著您的業務發展，您的模型需要更新。每月或每季度用新數據重新訓練可以保持高性能。使用您的生產日誌作為新訓練數據——模型自己的輸出（由人工驗證）反饋到未來的訓練中。

品質監控。 持續追蹤準確率指標。設置品質降級的警報。如果準確率下降到您的閾值以下，觸發重新訓練週期。

版本管理。 保留以前的模型版本以供回滾。追蹤每個環境中部署了哪個模型版本。

常見陷阱（以及如何避免它們）

陷阱 1：試圖一次遷移所有內容

錯誤： 花幾週時間為所有 8 個 AI 任務構建精心設計的遷移計劃，然後嘗試並行執行。

解決方法： 先交付一次遷移。從中學習。將這些學到的東西應用到下一次。在構建新的組織能力時，順序勝過並行。

陷阱 2：訓練數據品質不足

錯誤： 將 10,000 個原始 API 日誌倒入訓練數據集而不審查。日誌包括不正確的輸出、不一致的格式，以及 API 模型處理不當的邊緣案例。

解決方法： 在數據策劃上花更多時間，在數據量上花更少時間。審查示例。刪除壞的。確保格式一致。800 個策劃的示例優於 5,000 個未審查的示例。

陷阱 3：跳過影子部署

錯誤： 直接從測試集評估到生產部署。測試集沒有捕獲真實世界輸入的完整分佈。

解決方法： 始終進行影子部署。始終進行 A/B 測試。額外的 2-3 週驗證可以防止需要超過 2-3 週恢復的生產事件。

陷阱 4：為錯誤的指標優化

錯誤： 在您的 API 模型只達到 85% 時追求 99% 的準確率。微調模型達到 92%——比 API 更好——但團隊繼續迭代因為它不「完美」。

解決方法： 您的基準是當前的 API 模型，而不是理論上的完美。如果微調模型在您的指標上匹配或超過 API，那就是成功的遷移。

陷阱 5：忘記備用

錯誤： 遷移到微調模型後刪除 API 整合。三個月後，您需要重新訓練模型，在訓練窗口期間沒有備用。

解決方法： 保持 API 整合休眠。如果您不調用它，您就不需要為它付費。但在緊急情況下擁有它——即使是短暫的——值得最低限度的維護成本。

Ertas 捷徑

上面的操作手冊適用於任何微調工具鏈。但許多手動工作——GPU 配置、訓練配置、數據集格式化、GGUF 匯出——可以通過正確的平台壓縮。

使用 Ertas，第 2-3 階段大幅壓縮：

• 數據集上傳替代手動 JSONL 準備（或使用視覺編輯器）
• 一鍵訓練替代 GPU 設置、配置文件和監控腳本
• 內置評估替代自定義評估管線
• 跨實驗並排比較替代手動追蹤
• GGUF 匯出替代量化工具鏈

手動工具需要 6 週的遷移可以用整合平台壓縮到 2-3 週。最難的部分——團隊卡住的地方——正是平台處理的部分。

90 天後

在這個操作手冊結束時，您應該有：

• 1-2 個生產任務在您擁有的微調模型上運行
• 已記錄和量化的已證明成本節省
• 評估框架為未來的遷移準備好
• 部署基礎設施正在運行和監控
• 優先排序的下一批任務列表要遷移
• 微調工作流的機構知識

您不再完全依賴 API。您擁有關鍵的 AI 能力。您的成本更可預測。您的產品更具彈性。

下次 AI 供應商發送棄用通知或定價變更時，您將有選擇——而不僅僅是義務。

---

開始您的遷移。Ertas 在視覺界面中處理整個管線——從數據集到 GGUF——不需要代碼。以早鳥定價預訂。查看方案 →