在你的應用程式資料上微調模型：獨立開發者指南

你構建了一個應用程式。它使用 AI API——也許是 OpenAI，也許是 Anthropic——而且能用。但 API 費用在攀升，延遲不可預測，你開始意識到模型為你的應用程式做的 90% 是相同的狹窄任務重複數千次。你不需要一個天才通才。你需要一個專家。

在你的應用程式實際資料上微調一個較小的模型，就是你獲得那個專家的方式。儘管 ML 推特討論可能讓你認為不同，你不需要博士學位或一堆 H100 來做到這一點。本指南為從未接觸過模型訓練的開發者逐步演示整個過程。

為何在你的資料上微調很重要

通用前沿模型是非凡的通才。它們可以寫詩、調試程式碼、摘要法律文件和生成 SQL——都在同一個對話中。但這種通用性是有代價的：它們不針對任何單一任務優化。

你的應用程式可能需要模型做好一件事。也許它分類支援票。也許它從發票中擷取結構化資料。也許它以特定語氣生成產品描述。對這類任務，一個在你的資料上微調的 3B 參數模型將一貫優於 70B 通用模型——以極小的成本和延遲。

微調不是讓模型更聰明。而是讓它更專注。

第 1 步：訓練資料是什麼樣子的

微調的訓練資料只是一個演示你希望模型執行的任務的輸入-輸出配對集合。如果你的應用程式向 API 發送提示並獲得回應，你已經有了原材料。

標準格式是 JSONL——每行一個 JSON 物件：

{"input": "Classify this ticket: My order hasn't arrived in 2 weeks", "output": "shipping_delay"}
{"input": "Classify this ticket: The app crashes when I upload photos", "output": "bug_report"}
{"input": "Classify this ticket: Can I change my subscription plan?", "output": "account_inquiry"}

格式的具體細節取決於你的工具，但概念是通用的：告訴模型什麼進去，什麼應該出來。

從記錄你的 API 呼叫開始。你的應用程式發送給 AI API 的每個請求和它接收的每個回應都是潛在的訓練範例。如果你還沒有記錄層，添加一個，讓它累積幾週。

第 2 步：你需要多少資料

最常見的問題——答案是比你想的少。

對於狹窄、定義明確的任務（分類、擷取、重新格式化），1,000 到 3,000 個高品質範例通常足以看到比基礎模型有意義的改進。一些任務以少至 500 個範例就能收斂。

品質遠比數量重要。一千個精心整理的範例將優於一萬個嘈雜的範例。專注於：

• 多樣性： 涵蓋你的應用程式處理的全部輸入範圍，包括邊緣案例
• 正確性： 你的訓練集中的每個輸出應該恰好是你希望模型產生的
• 一致性： 類似的輸入應該有格式一致的輸出

如果你有 50,000 個 API 日誌，但一半包含錯誤或格式不一致，要嚴格過濾。2,000 個乾淨範例的資料集優於 20,000 個混亂的範例。

第 3 步：選擇基礎模型

對應用程式特定的微調，較小的模型幾乎總是正確的選擇。以下是推理：

• 3B 參數： 快速推論，在消費級硬體上運行，對分類和擷取任務出色
• 7B 參數： 大多數應用程式的最佳點，能很好地處理生成任務，仍然在單個 GPU 上運行
• 13B 以上： 只有當輸出品質至關重要的複雜生成任務才需要

從最小的可能合理地處理你的任務的模型開始。微調 3B 模型需要幾分鐘。微調 13B 模型需要幾小時。如果 3B 模型讓你達到 90%，就部署它然後繼續前進。

對基礎模型選擇，查看按大小過濾的 Hugging Face 排行榜。Llama 3、Mistral、Phi 和 Qwen 等模型都有強大的小型變體，微調效果很好。

第 4 步：微調過程

你不需要理解微調背後的數學才能有效使用它。以下是在實際層面上重要的事情：

LoRA（低秩適應） 是你將使用的技術。LoRA 不是修改模型中所有數十億個參數，而是向特定層添加小型可訓練矩陣。這意味著：

• 訓練很快——幾分鐘到幾小時，而不是幾天
• 記憶體需求低——7B 模型可以在具有 16GB VRAM 的單個消費級 GPU 上微調
• 輸出是一個小型適配器文件（50-150MB），而不是完整的模型副本

訓練循環本身很直接：模型看到你的輸入-輸出配對，調整 LoRA 權重以更好地預測預期輸出，並在你的資料集上重複幾輪（epochs）。對大多數任務，2 到 4 個 epochs 是典型的。

第 5 步：評估你的模型

在部署之前，你需要知道微調後的模型是否真的比你當前的設置表現更好。將 10-20% 的資料保留為測試集——模型在訓練期間從未見過的範例。

在測試集上運行你當前的基於 API 的解決方案和微調後的模型。比較：

• 準確率： 微調後的模型產生正確輸出的頻率與之前一樣或更多嗎？
• 格式合規性： 它是否一致地遵循你預期的輸出結構？
• 邊緣案例： 它如何處理讓通用模型出錯的不尋常輸入？

這個階段的常見品質問題：

• 過擬合： 模型記憶訓練範例而不是學習模式。通過添加更多多樣化資料或減少訓練 epochs 來修復。
• 格式漂移： 模型以格式不一致的方式產生正確答案。通過確保你的訓練資料有完美一致的格式來修復。
• 不熟悉輸入上的幻覺： 模型對訓練資料中代表性不佳的輸入類型自信地產生錯誤輸出。通過擴大訓練資料以涵蓋這些案例來修復。

第 6 步：部署你的模型

一旦你的模型通過評估，部署就是容易的部分。

匯出為 GGUF 格式。 GGUF 是使用 Ollama 和 llama.cpp 等工具在本地運行模型的標準格式。你的微調適配器與基礎模型合併成一個可移植的文件。

使用 Ollama 運行。 安裝 Ollama，載入你的 GGUF 文件，你就有了一個本地 API 端點，它是你的應用程式當前使用的雲端 API 的直接替換。在你的應用程式配置中更改端點 URL，你就上線了。

你獲得什麼： 零每 token 成本、可預測的延遲、完全的資料隱私，以及沒有速率限制。對於運行 SaaS 產品的獨立開發者，從 API 呼叫切換到自託管微調模型可以將 AI 成本降低 95% 或更多。

要避免的常見錯誤

資料多樣性太少。 如果你的訓練資料只涵蓋正常路徑輸入，模型在任何不尋常的情況下都會失敗。刻意包含邊緣案例和錯誤場景。

錯誤的基礎模型大小。 因為「更大更好」就從 70B 模型開始，浪費時間和金錢。從小型開始，評估，只有在較小的模型真的無法處理任務時才擴展。

跳過評估。 在沒有適當測試集的情況下部署是盲目的。在你根據基線測量之前，你不會知道你的微調模型是否更好。

Ertas 如何讓這變得可訪問

Ertas 是為希望獲得微調好處而不需要 ML 基礎設施開銷的開發者構建的。上傳你的訓練資料、選擇基礎模型，並啟動訓練運行——不需要 Python 腳本、CUDA 調試或 YAML 配置文件。

該平台處理資料驗證、訓練編排、評估指標和 GGUF 匯出。你從 API 日誌到可部署的模型，無需離開瀏覽器。

對於獨立開發者和小型團隊，這是「我應該有一天微調」和本週實際部署微調模型之間的差異。

延伸閱讀

• Your Vibe-Coded App's AI Costs Will Explode — Here's the Fix
• Fine-Tune AI Without Writing Code
• Self-Hosted AI for Indie Apps