為什麼您的微調資料集無法用於端側 AI——以及如何修復它

您在企業資料上微調了一個 70B 模型。它表現良好。現在您將其蒸餾成一個 0.5B 模型，用於在行動 NPU 上部署。準確率從 92% 降至 61%。

這不是蒸餾問題。這是資料問題。

今天大多數微調資料集都針對大型模型進行了優化。示例冗長、複雜，並假設模型有數十億個參數來編碼細微的模式。當您將這些知識壓縮到一個參數少 140 倍的模型中時，資料集就變成了負擔而不是資產。

修復方法不是更好的蒸餾技術。而是從一開始就為目標模型設計資料集。

為什麼大型模型資料集在小規模下失敗

70B 模型大約有 700 億個參數。0.5B 模型有 5 億個。這是 140:1 的比例。考慮一下這對學習能力意味著什麼。

注意力頭限制。 70B 模型可能在 80 層中有 64 個注意力頭。0.5B 模型可能在 24 層中有 16 個頭。70B 模型輕鬆處理的複雜多步推理鏈，超出了 0.5B 模型的注意力容量。需要 5 步推理的訓練示例，對於可靠地處理 2 至 3 步的模型來說是浪費容量。

上下文視窗限制。 生產中的大型模型通常使用 8K 至 32K 標記的上下文。由於記憶體限制，端側模型通常使用 512 至 2048 個標記的上下文。如果您的訓練資料每個示例平均 3,000 個標記，模型學習的模式超出了其生產上下文視窗。它在學習永遠無法使用的技能。

詞彙利用率。 小型模型有更小的有效詞彙量。對 70B 模型通過其龐大的嵌入空間處理的技術術語、罕見術語和特定領域縮寫，對 0.5B 模型來說成為噪音。具有 50,000 個唯一標記的訓練資料，要求小型模型將有限的容量分散得太薄。

分佈敏感性。 70B 模型優雅地處理類別不平衡。如果 80% 的訓練示例是 A 類，20% 是 B 類，大型模型仍然充分學習 B 類。同樣場景下的 0.5B 模型可能有效地忽略少數類別。小規模下的分佈不平衡產生只適用於多數情況的模型。

管道不是訓練 → 部署

標準企業 AI 管道假設：準備資料 → 訓練模型 → 部署。當訓練和部署使用相同的架構時，這是有效的。

對於端側 AI，實際管道是：

1. 教師模型（70B 以上）定義品質上限
2. 合成資料生成，使用教師模型，針對學生模型進行校準
3. 資料過濾，刪除超出學生能力的示例
4. 微調學生模型（0.5B 至 8B）
5. 量化，針對目標硬體（Q4/Q5/Q8）
6. 運行時匯出（ExecuTorch、LiteRT、ONNX、Qualcomm AI Hub）
7. 端側驗證，針對生產限制

資料準備涵蓋步驟 2 和 3——這些步驟比微調本身更能決定結果。在這個規模下，準備良好的資料集加上平庸的微調超參數，優於準備不良的資料集加上最優的超參數。

感知蒸餾的資料準備是什麼樣的

步驟 1：在接觸資料之前定義目標限制。

在準備任何訓練示例之前，記錄：

• 目標模型大小（0.5B、1B、3B、8B）
• 目標硬體（Snapdragon NPU、Apple Neural Engine、Intel NPU 等）
• 生產上下文視窗（512、1024、2048 個標記）
• 延遲預算（推理速度需要多快？）
• 量化級別（Q4、Q5、Q8）

這些限制塑造了後續的每個資料決策。

步驟 2：以正確的複雜度級別生成合成資料。

使用您的教師模型（70B 以上）生成訓練示例，但限制生成：

• 最大輸出長度：匹配學生的生產上下文視窗
• 推理深度：對低於 1B 的模型限制到 2 至 3 步鏈，對 3B 至 8B 模型限制到 3 至 5 步
• 詞彙：限制到學生模型在生產中將遇到的術語
• 格式一致性：在所有示例中使用相同的輸出模板

生成 500 字合約分析的 70B 教師，對訓練在生產中產生 50 字分類的 0.5B 模型毫無用處。

步驟 3：積極過濾。

對於大型模型，更多資料通常更好。對於低於 1B 的模型，如果資料稀釋了分佈，更多資料可能是積極有害的。

應用：

• 長度過濾：刪除超出您生產輸入分佈第 10 至第 90 百分位數的示例
• 複雜度評分：使用學生模型本身的困惑度——高困惑度示例超出其能力
• 去重：在小規模下，近似重複消耗不成比例的容量
• 領域相關性評分：根據模型將執行的特定任務對每個示例進行評分
• 平衡執行：確保類別分佈與預期的生產分佈相匹配

對於低於 1B 的模型，目標是 5,000 至 20,000 個高品質示例。這違反直覺——但在這個規模下，10,000 個完美校準的示例始終優於 100,000 個嘈雜的示例。

步驟 4：在擴展之前在目標硬體上驗證。

取您過濾的資料集，微調一個小樣本（1,000 個示例），在實際目標設備上部署，並衡量真實世界的性能。如果準確率低於閾值，問題幾乎總是資料分佈——而不是模型架構或訓練超參數。

本地部署要求

企業團隊還有一個額外的複雜因素：這些資料集的源資料通常是敏感的。臨床記錄、法律文件、財務記錄、專有業務資料。

您不能僅僅因為目標部署是端側的，就將 700 GB 的建築工程量清單發送到雲端標注工具。即使最終模型在端側運行，訓練資料準備也必須在本地進行。

這創建了一個工作流程：

• 資料準備在本地進行（無資料出口）
• 微調在雲端 GPU 上進行（模型權重，而非原始資料）
• 部署在端側進行（推理資料保持本地）

每個步驟有不同的基礎設施要求，但資料準備步驟——決定端側模型是否真正有效的步驟——必須完全氣隙。

Ertas Data Suite 在這裡的作用

Ertas Data Suite 作為原生桌面應用程式運行，完全在本地。對於端側 AI 資料準備：

Clean 模塊提供品質評分、長度過濾和去重，針對您的目標模型大小進行校準。設置您的目標參數（0.5B、1024 上下文視窗、Q4 量化），品質分數會調整以標記超出模型容量的示例。

Augment 模塊使用本地 LLM 生成合成訓練資料，生成限制與您的學生模型規格相匹配。資料不離開建築物。沒有雲端 API 呼叫。合成資料是為將實際使用它的模型設計的。

Export 模塊輸出針對您的微調框架格式化的 JSONL，帶有元資料追蹤哪些示例通過了哪些品質過濾器——以便在端側性能未達到目標時可以迭代資料集。

預約探索電話，討論您的端側 AI 資料準備要求，了解 Ertas Data Suite 如何適合您的管道。