模型蒸餾，是用教師模型提供的學習訊號訓練學生模型，讓學生在指定任務上學會更好的判斷與回應。常見目標是把能力轉移到較容易部署的小模型，降低使用時的資源需求。它需要新的訓練過程，效果取決於教師、學生本身的能力，以及準備了什麼資料。
理解這件事，最有用的起點是分清楚兩種做法：讓學生學教師的機率分布，以及讓學生學教師產生的完整答案。這也能解釋為什麼同樣叫蒸餾，有的需要取得模型內部輸出，有的只靠生成文字就能進行。
內容目錄
模型蒸餾是什麼？教師提供訊號，學生更新參數
Hinton、Vinyals 與 Dean 的知識蒸餾論文提出用大型模型或模型集成的預測分布，訓練另一個容易部署的模型。學生學習的是教師在不同輸入下的行為，不必照抄教師的架構，也不是把教師權重直接截取一部分。
一般離線蒸餾會先準備好教師，再固定教師的參數，由學生反覆預測、計算差距、更新自己的參數。完成訓練後，學生可以獨立推論。若產品另外設計了雲端備援，那是部署流程的選擇，並非蒸餾必然要求。
軟標籤：除了正確答案，還學選項之間的關係
以辨識貓、狗與汽車為例，人工標籤可能只寫「貓」。教師除了選出貓，還會對其他類別給出機率。狗的可能性高於汽車，透露出這張照片在模型眼中更接近哪類事物。這種帶有相對關係的訊號，就是軟標籤的價值。這裡是概念示例，並非實測數據。
經典做法會調整 softmax 的溫度，讓機率分布更平滑，使原本很小的機率差異更容易參與學習。溫度過高也會讓分布過於平均，因此仍需驗證。它不是「溫度越高，學生就越聰明」的設定。
PyTorch 官方教學示範把兩種訓練目標加權：一種要求學生接近教師分布，另一種要求學生符合真實標籤。分布差距可透過 KL divergence 等目標衡量。訓練時仍應保留正確答案的約束，教師的自信不等於答案一定正確。
實作時，直接比對逐 Token 分布通常還需要處理詞彙表、Tokenizer 與序列位置的對齊。光是教師和學生都能生成中文，並不足以保證它們的機率陣列可以直接相減。
回答蒸餾：把教師輸出變成學生的訓練資料
另一條路徑是先讓教師回答問題，整理成「輸入與目標回答」的資料集，再用監督式微調訓練學生。學生逐步學習如何產生這些答案，不需要拿到教師的全部權重。若服務只提供文字輸出，也可能採用這種方式，前提是取得與使用資料的條件允許。
Sequence-Level Knowledge Distillation在機器翻譯研究中，探討把整段生成序列作為蒸餾訊號。放到語言模型的應用裡，資料可以包含回答格式、分類結果、解題步驟與工具使用範例，但具體要教什麼，仍由資料與訓練目標決定。
例如，希望學生整理客服工單，就應準備真實會遇到的問法，要求教師產生正確分類、摘要與缺漏欄位，再經規則或人工檢查。只收集漂亮、流暢的回答，未必能教會學生處理錯字、矛盾敘述與資訊不足。這是本文用來說明資料設計的應用示例。
DeepSeek-R1 的蒸餾模型，為什麼會叫 Qwen 或 Llama？
DeepSeek-R1 官方模型卡說明，Distill 系列以 Qwen 與 Llama 的既有模型為基礎，使用 DeepSeek-R1 生成的樣本進行微調。名稱同時反映了提供訓練訊號的來源，以及學生採用的基礎模型。
因此，DeepSeek-R1-Distill-Qwen 不是把完整 R1 的參數切小，也不能直接當成 R1 的量化版。挑選時應確認學生模型、適用任務、Tokenizer 設定與部署需求。官方基準測試能提供參考，但不能推論小模型在所有領域都等同教師。
蒸餾、微調、量化與剪枝，各自在改什麼？
微調著重於用資料更新既有模型。蒸餾著重於知識訊號來自教師，兩者可以同時成立。用教師生成的答案微調學生，就是常見的交集。LoRA則是透過低秩更新降低需要訓練的參數量，是微調方法之一，本身不代表模型已完成蒸餾，也不等於把基礎模型縮成更少參數。
量化著重於數值表示的精度。Hugging Face 量化文件說明，較低精度的權重表示能降低記憶體需求，並盡量保留準確度。參數量可以不變，但每個權重佔用的空間減少。量化後是否更快，還要看硬體、運算支援與實際負載。
剪枝著重於移除或遮蔽部分權重與結構。PyTorch 剪枝教學展示了不同剪枝方式。權重變成零，不保證一般推論程式就會自動跳過運算。要換成實際加速，仍需相應的結構或稀疏運算支援。
這些方法可以組合，例如先訓練出合用的學生，再評估量化部署。想把概念接到本機環境，可延伸閱讀Qwen 本地部署與 GGUF 設定，但不同模型與硬體的需求要分別核對。
API 已經夠方便，什麼情況還值得蒸餾？
判斷方式是先看工作量與限制。若需求經常改變、使用量不大，直接使用現成模型可能更省事。若每天反覆處理相近任務，而且對回應時間、併發量、離線使用有明確要求，才值得把學生模型列入比較。這是部署規劃上的判斷，並非固定的成本結論。
比較時要把整段使用週期算進去，包括教師生成資料、資料審查、訓練、評估、硬體、維運，以及學生失敗後的重試或轉接。單次推論便宜，不能代表整個專案一定便宜。反過來，網路速度很好，也不會消除資料處理範圍與服務可用性的需求。
開始訓練前，先測未蒸餾的小模型是否已經夠用。如果簡單提示詞或現成模型就能完成工作，便沒有必要為了使用蒸餾而建立訓練管線。需要測試不同本地與雲端模型時，可參考LibreChat 與 Ollama 的整合方式，用同一批任務比較實際結果。
本地蒸餾模型的隱私，要沿著資料流檢查
學生在本機推論，確實可以減少把使用者輸入送往外部服務的需要。不過，隱私取決於整個系統如何傳遞與保存資料，不能只看模型檔案放在哪裡。
先看訓練前的資料準備。如果把內部文件送給雲端教師生成範例，資料在這一步就已經離開本機。再看實際使用時，是否另有雲端搜尋、遠端 Embedding、外部工具、遙測或日誌服務。最後看備援路徑，學生答不好時若自動轉給雲端大模型，轉交的問題、文件與歷史對話仍可能外傳。
有資料不外傳的要求時，應設計為本地處理、明確拒答或交由內部人員處理。允許混合部署時，則應先定義可外傳的資料範圍，並告知使用者何時轉交。把「本地模型」當作隱私保證，容易漏掉真正的資料出口。
實作蒸餾，先定義任務，再決定要不要訓練
以下是依前述方法整理的實務流程，適合用來規劃第一個小型試驗，不代表所有專案都需要同一套訓練參數。
先建立基準與驗收題目
選一個邊界清楚的任務，例如工單分類或固定欄位擷取。先測現成學生模型和教師各自的表現，定義正確率、格式完整性、回應時間與可接受的失敗方式。測試題目應與訓練資料分開，也要包含少見與資訊不足的情況。
生成範例後，先檢查品質
教師輸出需要去重、檢查事實、移除敏感內容，並確認符合任務規格。對答案可直接驗證的題目，優先使用程式規則或單元檢查。若蒸餾的是解題步驟，也不能只檢查最後答案正確，就認定中間推導全部可靠。
選擇訓練訊號，保留比較組
只有教師文字輸出時，可從回答資料微調開始。能取得分布且處理好對齊時，再評估軟標籤蒸餾。進一步的GKD 方法會讓學生在自己生成的序列上取得教師回饋，處理訓練資料與學生實際生成行為之間的差異。方法更複雜，並不代表每個任務都需要採用。
驗證泛化能力，再測實際部署
The False Promise of Imitating Proprietary LLMs在其研究設定下發現，模仿模型可以學到很像教師的回答風格，卻未必同步取得相同的事實能力。這項結果提醒我們，應檢查資料覆蓋之外的任務，不能只以流暢程度驗收，也不宜把該研究解讀成所有蒸餾都無效。
完成離線評估後，還要用目標硬體測記憶體、延遲與同時請求的表現。如果任務需要查詢經常更新的內部資料，可考慮讓模型搭配檢索，而非每次更新文件都重新蒸餾。站內的CrewAI 與 RAG 概念整理可作為理解工具與檢索分工的延伸閱讀。
模型蒸餾常見問題
模型蒸餾就是把大模型壓縮成小檔案嗎？
蒸餾是用教師訊號訓練學生，模型檔案大小取決於學生架構與數值精度。若只改變權重精度以縮小檔案，通常是在做量化。
只有教師模型的 API，也能做蒸餾嗎？
若 API 提供的輸出及使用條件允許，可以收集教師回答來微調學生。這與取得完整機率分布後進行的軟標籤蒸餾不同。
蒸餾後的小模型一定和大模型一樣強嗎？
不一定。效果受學生原本能力、資料覆蓋與任務影響，必須使用獨立題目評估，不能只看回答是否流暢。
Token 成本低，還需要自己蒸餾嗎？
未必。先比較現成模型是否夠用，再看使用量、延遲與離線需求。成本需要包含資料準備、訓練和維運，不能只看單次推論。
把小模型用在能驗收的任務上
蒸餾最值得關注的成果，是學生能否在你的任務上穩定達到要求，同時讓部署更容易。先建立現成模型的基準，找出缺口，再決定要準備什麼教師資料。當品質、速度與整體成本都有實際驗證，才能判斷這次訓練是否值得。
近期留言