將 Claude 或 GPT 蒸餾為本地 7B 模型

您有一個在 Claude Sonnet 或 GPT-4o 上運行的系統。它運作良好。品質很扎實。但每個請求都要花錢，每個請求都增加延遲，每個請求都將您的資料發送到別人的伺服器上。您希望擁有驅動您產品的模型。

本教程帶您完成完整的蒸餾管道：從定義任務到生成合成資料、微調 7B 模型，以及通過 Ollama 在本地部署。每個步驟都包括具體參數、預期輸出和疑難排解指導。

總時間： 3 至 4 小時（包括訓練等待時間） 總成本： 整個管道 10 至 30 美元 預期結果： 在您的特定任務上達到教師模型品質的 85 至 95%

先決條件

開始之前，您需要：

• 一個 Ertas 帳戶（免費方案對本教程足夠）
• 對您的教師模型的 API 存取——Anthropic API 金鑰（用於 Claude）或 OpenAI API 金鑰（用於 GPT-4o）
• 明確定義的任務——分類、提取、格式化或領域問答
• 50 個種子示例，包含您任務的正確輸入輸出對
• 一台用於本地部署的機器——超過 8GB VRAM 的 GPU 或超過 16GB RAM 用於 CPU 推理

讓我們逐步說明每個步驟。

步驟 1：定義任務範圍

蒸餾適用於窄任務。越窄越好。您的任務定義應該能用一句話概括：

好的任務定義：

• 「將客戶支援電子郵件分類為 8 個類別之一，並返回包含類別和信心值的 JSON 物件。」
• 「從發票 PDF（預處理為文字）中提取供應商名稱、發票號碼、日期和總金額。」
• 「將自然語言搜尋查詢轉換為我們產品目錄架構的 Elasticsearch DSL 查詢。」
• 「使用相關文件部分作為上下文，回答關於我們 API 文件的問題。」

不好的任務定義（太廣泛）：

• 「幫助客戶解決問題。」
• 「處理文件。」
• 「回覆電子郵件。」

您的任務定義應指定：

1. 輸入格式： 模型收到什麼？典型輸入有多長？範圍是什麼？
2. 輸出格式： 模型應該確切產生什麼？JSON？標籤？結構化文字？
3. 輸出空間： 可能的輸出有多少個？（12 個類別、5 個提取字段等）
4. 品質指標： 如何衡量輸出是否正確？準確率？F1？精確匹配？

把這寫下來。您將在整個過程中引用它。

在本教程中，我們使用一個持續的例子：將 SaaS 產品反饋分類為 6 個類別（錯誤報告、功能請求、可用性問題、效能投訴、正面反饋、問題），並提取受影響的產品區域。

步驟 2：手動創建 50 個種子示例

這個步驟感覺繁瑣，但決定了下游所有東西的品質。您需要 50 個手工製作的輸入輸出對，代表您任務的黃金標準。

為什麼是 50 個？因為這些種子示例有三個目的：

1. 提示校準——它們幫助您為教師模型編寫提示
2. 品質參考——它們定義「正確」的樣子
3. 測試集基礎——其中 20 個將成為您的初始評估集

種子示例的指導原則：

• 涵蓋所有類別/輸出類型。 如果您有 6 個類別，每個類別至少包含 8 個示例。
• 包含邊緣案例。 添加 5 至 10 個模糊、多標籤或不尋常的示例。
• 匹配生產分佈。 如果您的真實輸入中 40% 是錯誤報告，那麼大約 40% 的種子應該是錯誤報告。
• 輸出要精確。 您的輸出應該確切是您希望模型產生的——相同的 JSON 架構、相同的格式、相同的詳細程度。

將種子示例格式化為 JSONL：

{"input": "The dashboard keeps crashing when I try to export reports. This has been happening since the last update.", "output": "{\"category\": \"bug_report\", \"confidence\": 0.95, \"product_area\": \"dashboard\", \"summary\": \"Dashboard crashes on report export since last update\"}"}
{"input": "It would be amazing if you could add a dark mode to the mobile app.", "output": "{\"category\": \"feature_request\", \"confidence\": 0.92, \"product_area\": \"mobile_app\", \"summary\": \"Request for dark mode on mobile app\"}"}

在這個步驟上花 1 至 2 小時。種子示例的品質直接決定最終模型的品質。

步驟 3：使用教師模型生成 2,000 個合成示例

現在您要擴大規模。您將使用 Claude 或 GPT-4o 作為教師模型來生成 2,000 個標記示例。

3a：編寫教師提示

使用您的種子示例為教師模型製作系統提示。提示應該：

• 精確描述任務
• 包含 3 至 5 個種子示例作為少樣本示範
• 指定確切的輸出格式
• 包含邊緣案例指導

You are a product feedback classifier. Given a piece of user feedback about a SaaS product, classify it and extract the relevant product area.

Output a JSON object with these fields:
- category: one of [bug_report, feature_request, usability_issue, performance_complaint, positive_feedback, question]
- confidence: float between 0.0 and 1.0
- product_area: the affected product area (e.g., dashboard, api, mobile_app, billing, onboarding, integrations, general)
- summary: one-sentence summary of the feedback

Examples:
[Include 3-5 seed examples here]

Classify the following feedback:

3b：生成多樣化輸入

您需要多樣化的輸入來餵給教師。有幾個來源：

生產資料。 如果您有歷史反饋，這是理想的。真實資料具有正確的分佈、詞彙和邊緣案例。

合成輸入生成。 使用教師模型本身來生成真實的輸入。提示它：「生成 50 個涵蓋所有六個類別的多樣化 SaaS 產品反饋示例。使其真實，長度不等（1 至 5 句話），語氣多樣（沮喪、中性、興奮），具體程度也各異。」

基於模板的生成。 創建帶有插槽的模板並以程式化方式填充它們。「當我嘗試 {action} 時，{feature} 會 {problem_description}。」

目標是 2,500 個原始輸入。在品質過濾期間您會丟棄一些。

3c：運行教師模型

通過教師模型處理所有 2,500 個輸入。這是管道中最昂貴的步驟，但它是一次性成本。

2,500 個示例的成本估算：

• Claude Sonnet：約 3 至 5 美元（每個示例約 200 個輸入標記 + 100 個輸出標記）
• GPT-4o：約 4 至 7 美元

使用批次處理來降低成本。Anthropic 和 OpenAI 都提供 50% 折扣的批次 API。批次處理後：

• Claude Sonnet 批次：約 1.50 至 2.50 美元
• GPT-4o 批次：約 2 至 3.50 美元

將所有輸入輸出對保存為 JSONL。這是您的原始訓練資料集。

3d：速率限制和錯誤處理

運行 2,500 個 API 呼叫時，您會遇到速率限制。實作：

• 指數退避加抖動（從 1 秒開始，最大 60 秒）
• 重試邏輯用於 429 和 500 錯誤（最多 3 次重試）
• 檢查點——每 100 個示例保存一次進度，以便在腳本崩潰時可以恢復
• 並行請求——對於標準 API 層，5 至 10 個並發請求通常是安全的

實作良好的腳本在 15 至 30 分鐘內處理 2,500 個示例。

步驟 4：品質過濾資料集

原始教師輸出並非全部可用。預計在品質過濾期間丟棄約 25% 的示例。這是正常的也是重要的。

自動過濾器

以程式化方式運行這些檢查：

1. 架構驗證。 將每個輸出解析為 JSON。丟棄任何輸出不是有效 JSON 或不匹配您預期架構的示例。（預計 2 至 5% 失敗率。）

2. 類別驗證。 檢查類別字段是否包含有效值之一。教師模型偶爾會幻覺一個不存在的類別。（預計 1 至 3% 失敗率。）

3. 信心值閾值處理。 丟棄教師信心低於 0.70 的示例。低信心輸出通常是不正確或模糊的，對其進行訓練會混淆學生模型。（預計移除 5 至 10%。）

4. 去重。 刪除近似重複的輸入。在嵌入上使用閾值為 0.95 的餘弦相似度。在近似重複上訓練浪費計算並使模型產生偏差。（預計移除 5 至 10%。）

5. 長度異常值。 刪除輸入或輸出異常長或短的示例（超出平均值 2 個標準差）。這些通常是格式錯誤的。（預計移除 2 至 3%。）

手動抽樣檢查

自動過濾後，隨機抽樣 100 個示例並手動審查。注意：

• 教師錯誤（錯誤的類別、不正確的提取）
• 格式不一致（有時包含 markdown，有時不包含）
• 「正確」答案有爭議的模糊示例

如果超過 10% 的抽樣檢查有問題，您的教師提示需要改進。返回步驟 3a 並細化。

預期結果： 從 2,500 個示例開始，最終得到約 1,800 至 2,000 個乾淨示例。這對微調來說已經足夠了。

步驟 5：在 Ertas Studio 中微調

將過濾後的 JSONL 資料集上傳到 Ertas Studio。以下是標準蒸餾運行的配置。

模型選擇

在本教程中，選擇 Llama 3.1 8B 或 Qwen 2.5 7B。兩者都是出色的蒸餾目標。

• Llama 3.1 8B：社群更大，如果遇到問題有更多教程
• Qwen 2.5 7B：在基準測試上略好，Apache 2.0 授權

LoRA 配置

訓練參數

訓練時間和成本

有 2,000 個示例和上述配置：

• 在 Ertas Studio 上： 30 至 45 分鐘，費用約 8 至 12 美元
• 在您自己的 A100（80GB）上： 20 至 30 分鐘
• 在您自己的 RTX 4090（24GB）上： 40 至 60 分鐘（使用 QLoRA 量化）

Ertas Studio 顯示即時訓練指標：損失曲線、學習率排程和每個訓練輪次邊界的評估指標。

訓練期間需要注意什麼

• 訓練損失應在第 1 至 2 個訓練輪次穩步下降，並在第 3 個訓練輪次開始趨於平穩
• 評估損失應與訓練損失密切追蹤。如果評估損失開始增加而訓練損失在下降，您正在過擬合。停止訓練。
• 如果損失在前 100 步驟中驟增，您的學習率太高了。嘗試 1e-4。
• 如果損失幾乎沒有下降，您的學習率太低了。嘗試 5e-4。

步驟 6：對照教師模型評估

訓練完成後，在您保留的測試集（您保留的 20 個種子示例，加上 Ertas 自動保留的 10% 訓練資料）上評估學生模型。

需要檢查的指標

分類準確率： 學生正確分類了多少百分比的示例？

• 目標： 與教師的一致率超過 90%
• 可接受： 超過 85%
• 需要改進： 低於 85%

結構化輸出的精確匹配： 有多少百分比的輸出是完全正確的（所有字段匹配）？

• 目標： 超過 85%
• 可接受： 超過 75%

按類別細分： 分別檢查每個類別的準確率。如果某個類別明顯比其他類別差，您可能需要為該類別添加更多訓練示例。

並排比較

Ertas Studio 提供並排比較視圖，您可以看到每個測試示例的教師和學生輸出。手動審查分歧。通常您會發現：

• 40 至 50% 的分歧是學生實際上正確的情況（教師犯了錯誤）
• 30 至 40% 是兩個答案都合理的情況（模糊輸入）
• 10 至 20% 是可以通過更多訓練資料修復的真正學生錯誤

如果品質低於目標

如果您的評估分數低於目標：

1. 首先檢查資料品質。 審查 50 個隨機訓練示例。如果超過 5% 的標籤不正確，清理資料並重新訓練。
2. 為薄弱類別添加更多資料。 如果某個類別表現不佳，專門為該類別生成 200 至 300 個額外示例。
3. 增加 LoRA rank。 從 rank 16 移到 rank 32。這給模型更多容量來學習複雜模式。
4. 嘗試更大的模型。 如果 Qwen 7B 不夠，嘗試 Qwen 14B 或 Llama 8B。
5. 添加更多目標模塊。 除了注意力層，還包括 MLP 層（gate_proj, up_proj, down_proj）。

步驟 7：匯出到 GGUF 並通過 Ollama 部署

對評估結果滿意後，匯出模型用於本地部署。

GGUF 匯出

在 Ertas Studio 中，選擇您訓練的模型並點擊匯出。選擇您的量化級別：

建議： 從 Q5_K_M 開始。它提供出色的品質-大小平衡。只有在有硬體限制時才降至 Q4。只有在需要最後 1 至 2% 的品質時才使用 Q8。

匯出需要 2 至 5 分鐘。您將得到一個 .gguf 文件。

使用 Ollama 部署

創建 Modelfile：

FROM ./your-model-Q5_K_M.gguf

PARAMETER temperature 0.1
PARAMETER top_p 0.9
PARAMETER num_ctx 512

SYSTEM """You are a product feedback classifier. Given user feedback, classify it and extract the relevant product area. Output a JSON object with: category, confidence, product_area, summary."""

註冊並運行：

ollama create feedback-classifier -f Modelfile
ollama run feedback-classifier "The search function is incredibly slow, takes 10+ seconds to return results"

預期輸出：

{"category": "performance_complaint", "confidence": 0.94, "product_area": "search", "summary": "Search function has 10+ second response times"}

整合

對於生產環境，使用 Ollama 的 HTTP API：

curl http://localhost:11434/api/generate -d '{
  "model": "feedback-classifier",
  "prompt": "The search function is incredibly slow, takes 10+ seconds to return results",
  "stream": false
}'

Ollama 以每秒 30 至 120 個標記的速度服務請求，視您的硬體而定。對於典型的 50 個標記分類輸出，預計響應時間為 50 至 150 毫秒。

步驟 8：監控生產效能並迭代

部署不是終點。生產資料會揭示訓練資料未涵蓋的邊緣案例。

監控清單

1. 記錄所有輸入和輸出。 每個生產請求都是下次迭代潛在的訓練示例。

2. 追蹤信心分數。 如果模型輸出低於 0.70 的信心，標記請求以供審查。低信心請求比例上升表明分佈漂移。

3. 基於抽樣的品質審計。 每週審查 50 個隨機的生產輸出。計算您的真實世界準確率，並與評估集準確率比較。

4. 類別分佈監控。 隨時間追蹤預測類別的分佈。如果分佈顯著偏移，調查輸入分佈是否已改變，或模型是否在漂移。

5. 延遲監控。 追蹤 p50、p95 和 p99 延遲。如果延遲增加，檢查部署伺服器上的資源競爭。

迭代週期

每 2 至 4 週（或當品質降至閾值以下時）：

1. 收集標記的低信心示例和錯誤預測
2. 手動修正標籤（或對模糊案例使用教師模型）
3. 向訓練集添加 200 至 500 個新示例
4. 重新訓練（增量訓練需要 15 至 20 分鐘）
5. 評估並重新部署

每次迭代通常將準確率提高 1 至 3 個百分點。3 至 4 次迭代後，大多數模型收斂到給定模型大小的品質上限。

預期結果和成本摘要

品質： 在您的特定任務上與教師模型達到 85 至 95% 的一致率。在許多任務（分類、提取）上，微調模型超過 90%。

總成本細分：

與在生產中運行教師模型的持續成本比較：

• 每月 10,000 個請求：每月 API 費用 10 至 50 美元
• 每月 100,000 個請求：每月 100 至 500 美元
• 損益兩平：1 至 4 週

時間估算：

• 步驟 1（任務定義）：30 分鐘
• 步驟 2（種子示例）：1 至 2 小時
• 步驟 3（教師生成）：30 分鐘主動，15 至 30 分鐘處理
• 步驟 4（品質過濾）：30 至 45 分鐘
• 步驟 5（訓練）：10 分鐘主動，30 至 45 分鐘等待
• 步驟 6（評估）：20 至 30 分鐘
• 步驟 7（匯出和部署）：15 至 20 分鐘
• 總計：3 至 5 小時，包括等待時間

您早上開始時按標記付費。到午餐時，您擁有了這個模型。

有關本教程背後的技術基礎，請閱讀我們的 使用 LoRA 進行模型蒸餾指南。想要完全使用開源模型且零法律風險地做到這一點？請參閱 如何合法蒸餾開源模型。有關蒸餾背後的倫理和策略，請閱讀 模型蒸餾不是盜竊——但以下是為什麼您應該自己做。Ertas 新手？從 Ertas 入門 開始。