教師模型與學生模型的核心關係

AI模型蒸餾的直接答案是：以大型教師模型的輸出，訓練較小的學生模型模仿其行為。教師模型不只提供正確答案，還提供不同候選答案的相對信心；學生模型因此能學到比單一標籤更豐富的判斷邊界。這項方法特別適合分類、摘要、問答、嵌入與重排序等可明確評測的任務。

以情緒分類為例，硬標籤只會告訴模型某段文字屬於「正面」；教師模型卻可能輸出正面 99%、中性 0.7%、負面 0.2%、其他 0.1% 的機率結構。學生模型可從這些細微差異理解哪些語句接近邊界案例，降低只背答案、不懂脈絡的風險。

蒸餾不是把教師模型的所有參數複製到學生模型，而是轉移特定任務所需的行為能力。因此，學生模型的架構可以更小、上下文長度可以更聚焦，甚至可針對裝置端的記憶體限制重新設計。成功標準應是業務 KPI 與品質門檻，而非學生模型是否逐字複製教師回覆。

• 教師模型：產生高品質答案、評分或中間表徵。
• 學生模型：以較低推論成本重現目標任務能力。
• 蒸餾目標：縮小行為差距，而非複製全部通用智能。

軟標籤、logits 與溫度縮放如何傳遞暗知識

軟標籤是蒸餾效果優於一般監督式訓練的關鍵。模型在 softmax 前輸出的 logits，保留各類別之間的相對距離；加入溫度參數後，可把原本過度尖銳的機率分布拉平，使學生看見教師認為「次可能」的答案，而不只看到最高機率類別。

實務上會同時使用硬標籤損失與蒸餾損失。前者維持任務真實性，避免學生過度繼承教師錯誤；後者通常以學生與教師機率分布的 KL divergence 衡量差距。溫度提高後，損失項也要依設計調整權重，否則訓練訊號可能被其中一方主導。

對 LLM 而言，軟標籤不必只限於每個 token 的完整機率分布，也可蒸餾教師產出的解題步驟、偏好排序、工具呼叫格式或結構化 JSON。企業應注意，若教師 API 未開放 logits，就要改用答案蒸餾、偏好資料或評審模型分數，並確認服務條款是否允許這類訓練用途。

• logits：softmax 前的原始分數，可保存相對偏好。
• 溫度縮放：讓低機率候選答案也成為可學習訊號。
• 混合損失：兼顧真實標註與教師行為。

常見蒸餾類型與適用情境

選蒸餾方法時，應先看任務需要複製「答案」、「思考特徵」還是「樣本關係」。響應蒸餾直接模仿最終輸出，導入門檻最低；特徵蒸餾對齊隱藏層表示，適合影像、語音或已有相容架構的模型；關係蒸餾則保留樣本間的相似度與距離結構。

線上蒸餾讓教師與學生在訓練中共同更新，適合有充足算力與研究能力的團隊；自蒸餾則讓同一模型的深層或歷史版本指導較淺層，能減少外部教師依賴。多數企業的第一個專案，較適合採取離線響應蒸餾：先固定教師輸出，再重複訓練與檢查資料品質。

例如 MiniLM 的公開研究顯示，在速度快 2 倍的同時，達到了原始 BERT base 模型 99% 的準確率。這不代表任何任務都可得到相同結果，但它提醒團隊：若工作範圍已收斂，較小模型不一定是能力妥協，反而可能是更可靠的正式服務選項。

• 響應蒸餾：適合問答、分類、摘要與格式化輸出。
• 特徵蒸餾：適合視覺、語音與表徵學習模型。
• 關係蒸餾：適合檢索、排序與相似度任務。

先定義教師模型、任務邊界與成功指標

蒸餾專案的第一步不是挑最強模型，而是明確定義學生模型必須做好哪些工作。請先拆分輸入類型、輸出格式、允許錯誤類型、敏感資料規則與服務等級，例如客服分流、內部知識問答或文件欄位擷取。若目標模糊，教師輸出再漂亮，也無法形成可驗收的訓練資料。

教師可選擇 GPT-4o Mini、Llama 或 Gemini Flash 等模型，但評估時不能只看單次示範。應以保留測試集檢查正確性、格式合規率、拒答品質、幻覺率與人工覆核時間，並保留原始提示、模型版本、解碼參數及輸出時間，以便重現問題與追查品質變化。

對於推理需求較高的工作，可把大型推理模型當成資料生成器，再以較小模型承接高頻任務。DeepSeek-R1-Distill-Qwen-32B 為 320 億參數模型，正說明蒸餾成果也可能仍有相當規模；是否適合部署，仍取決於你的併發量、延遲預算與硬體環境。

• 先定義任務範圍與不可接受的失敗模式。
• 建立獨立測試集，不可與訓練資料混用。
• 完整記錄提示、版本與解碼設定。

以真實資料與合成資料建立訓練集

高品質資料比大量資料更能決定蒸餾是否成功。企業可先從去識別化的真實案例抽樣，再以教師模型補足罕見情境、反例與邊界案例。資料集應涵蓋短問句、長文件、錯字、模糊需求、禁止處理的請求，以及正式環境可能遇到的語言與格式。

只有合成資料容易造成分布偏移：學生模型可能很會回答教師習慣的問法，卻無法處理真實使用者的表達。更嚴重時，若反覆以模型生成內容餵回模型，錯誤和偏見會被放大。因此需要人工抽檢、來源標記、去重、毒性檢測與資料版本控管。

小規模驗證可先比較約1000個由人工標註的樣本，再逐步增加教師生成資料。重點不在追求單一固定數量，而是觀察新增資料是否改善長尾案例；若錯誤集中在少數流程，應優先補強這些流程，而不是盲目擴大同質問答。

• 真實資料用來維持業務分布與例外情境。
• 合成資料用來擴充覆蓋率與困難案例。
• 每筆資料應保留來源、版本、標註與審核狀態。

以多維度評估決定是否可上線

蒸餾模型能否上線，必須同時通過品質、速度、成本與風險四種檢查。除了準確率或 Rouge 等自動指標，也應以任務導向評估檢查答案是否可執行，例如 JSON 是否可解析、檢索引用是否正確、客服分類是否送往正確隊列，以及安全規則是否確實生效。

效能測試至少要分開紀錄 TTFT、每輸出 token 延遲、端到端延遲、吞吐量、P50、P95、錯誤率與每請求成本。只報平均延遲很容易掩蓋尖峰問題；正式服務若 P95 明顯惡化，使用者體感與客服負擔通常會先受影響。

以下表格可作為 Go／No-Go 的最小驗收面向。實際門檻必須依任務風險設定，例如金融審核與行銷文案不能採用相同容錯標準；高風險決策也應保留人工覆核與升級至強模型的機制。

• 品質與格式測試必須使用未參與訓練的資料。
• P50 與 P95 應一起觀察，避免平均值誤導。
• 上線前要設計回退模型與人工處理流程。

蒸餾與量化解決的是不同問題

AI模型蒸餾縮小的是模型能力的承載規模，AI模型量化縮小的是數值表示所需的位元。蒸餾透過訓練讓學生模型學到教師行為；量化則把權重、啟動值或 KV Cache 從高精度格式轉換為低精度格式。兩者可串接，但不能互相取代。

常見格式包括 FP32、FP16、INT8 與 INT4。若只比較權重，從 32 位元改為 8 位元，理論上的儲存空間可降至四分之一；但真實速度仍受 GPU 核心、記憶體頻寬、算子支援、批次大小和量化工具影響，不能只用模型檔案大小判斷。

以 Llama2 7B 為例，FP16 下每个参数占用 2 个字节，总共约需 14 GB 显存（7B 参数 × 2 字节/参数）；若改用適當低精度格式，模型权重所需的显存可降至约 7 GB，显存占用减少一半。這仍未包含 KV Cache、框架開銷與同時服務多位使用者的空間。

• 蒸餾：改變模型學到的能力與架構規模。
• 量化：改變權重或啟動值的數值精度。
• 部署估算：必須把 KV Cache 與併發需求一起計入。

選擇 PTQ、QAT 與 LLM 量化方法

初次部署通常可從訓練後量化開始，再依品質落差決定是否投入量化感知訓練。PTQ 在訓練完成後轉換精度，速度快且成本低；QAT 則在訓練時模擬量化誤差，通常較能維持品質，但需要重新訓練與更嚴謹的資料流程。

LLM 常見的 GPTQ、AWQ 與 SmoothQuant，分別著重權重誤差最小化、保護重要權重通道及平衡啟動值與權重的尺度。它們沒有絕對優劣，應以你的模型架構、推論引擎、硬體與測試集比較；同一份 INT4 模型在不同平台也可能有不同延遲表現。

校準資料不能隨意挑選。它應盡量反映正式輸入的長度、語言、領域詞彙與格式，因為啟動值分布會直接影響量化誤差。對長文件應特別測試關鍵資訊在前段、中段與末段時的品質，避免短樣本校準後在長上下文情境失真。

• PTQ：適合快速驗證與既有模型轉換。
• QAT：適合對品質極敏感的量產模型。
• 校準集：必須反映實際提示與上下文分布。

以硬體與任務結果，而非位元數做決策

INT8 或 INT4 是否更快，答案取決於部署硬體是否有對應核心與推論引擎支援。有些 CPU、NPU 或 GPU 對 INT8 最成熟，有些新平台對 FP8 更有優勢；若量化後需要頻繁反量化，或者某些算子回退至一般核心，延遲反而可能不如 FP16。

執行模型推論優化時，應固定模型版本、輸入長度、輸出長度、併發數、批次策略與硬體，再比較品質與效能。例如 4096 個 token 的長上下文壓力，與短問答完全不同；權重雖可壓縮，KV Cache 仍可能成為主要顯存瓶頸。

工具層可依環境選擇 NVIDIA TensorRT、ONNX Runtime、TFLite 或 OpenVINO，但轉檔成功不等於正式可用。建議建立逐層驗證：先比對輸出正確性，再量測延遲與吞吐量，最後測試失敗重試、模型載入時間與尖峰併發，才能避免只在實驗環境漂亮。

• 先確認硬體支援的精度與算子，再選量化格式。
• 長上下文需獨立測試 KV Cache 壓力。
• 模型檔變小不必然代表端到端延遲更低。

先診斷推論瓶頸，再決定優化工具

模型推論優化應從量測瓶頸開始，而不是一開始就量化或換 GPU。LLM 的延遲通常可拆成請求排隊、預填充、解碼、網路傳輸與後處理；視覺模型還要檢查影像解碼與前處理。不同階段的瓶頸不同，錯用技術只會增加維運複雜度。

預填充階段受輸入長度與注意力計算影響，解碼階段則常受記憶體頻寬與 KV Cache 讀寫限制。可以使用前綴快取、PagedAttention、連續批次、FlashAttention 或預填充與解碼分離等策略，但應先確認真實流量是否有重複前綴、長提示或高併發特徵。

固定長度 padding 也是常被忽略的浪費。若 transformer 在训练时填充到了固定长度（例如 512）并在部署时使用相同的填充，那么在处理短序列时，它的运行速度会不必要地慢（慢几个数量级）。因此，序列分桶與動態批次通常比單純提高批次上限更值得優先驗證。

• 先分解排隊、prefill、decode、I/O 與網路延遲。
• 以 TTFT 和每 token 延遲分開判讀 LLM 問題。
• 短序列服務應避免固定長度 padding 浪費。

模型路由如何控制 LLM成本優化

模型路由的核心是依請求難度、風險與成本，把任務送往最合適的模型。高頻且規則明確的分類、欄位擷取或 FAQ，可優先交給蒸餾後的小模型；低信心、複雜推理、跨文件衝突或高風險問題，再升級至較強模型或人工流程。

這種大小模型協作，是 LLM成本優化 比單一模型降價更可持續的方法。路由器可依意圖分類器、學生模型信心、檢索分數、提示長度、使用者權限與預算判斷；但信心分數必須經過校準，不能把模型自信直接當作正確率。

成本差異會影響架構選擇。每百萬 token 輸入 0.55 美元、輸出 2.19 美元，與 GPT-4o 的定價是 2.50 美元 / 10 美元相比，特定用量下接近 4 倍差距。實際帳單還需納入重試、快取命中率、輸出長度及尖峰保留容量，不能只比較單價。

• 低風險且高頻任務優先使用蒸餾學生模型。
• 低信心與高風險請求應升級至強模型或人工。
• 路由規則要以離線回放與線上 A/B 測試持續校準。

批次、快取與推論引擎的服務化設計

要提高 GPU 利用率，關鍵是讓請求在不犧牲延遲目標下有效合併。vLLM 等引擎可透過連續批次處理不同時間抵達的請求，而 TensorRT-LLM、ONNX Runtime 或 llama.cpp 則各自適合不同模型與硬體。選型前應先確認量化格式、串流輸出、可觀測性與多模型共存需求。

設定值應從測試開始而非直接照抄。像 max_num_batched_tokens=4096、max_num_seqs=128、max_tokens=100 或 max_batch_size=32，只是配置範例；若輸入大多是長文件，過高併發可能擠壓 KV Cache，造成排隊、OOM 或 P95 延遲惡化。

快取也不應只做答案快取。對重複系統提示與文件片段可使用前綴快取，對檢索結果可設定短期快取，對語意相近的低風險問題可評估語意快取。每一層都要設計失效條件與權限隔離，避免將不同使用者的私密內容錯誤重用。

• 連續批次有助於提升 GPU 使用率與總吞吐量。
• 批次參數必須以真實輸入長度和 SLA 壓測。
• 快取須兼顧命中率、權限、更新與資料隔離。

依流量、延遲與資料治理選擇部署位置

GPU推論伺服器是否需要自建，應由流量穩定度、資料敏感性與延遲需求共同決定。雲端 API 適合快速開始與需求波動大的情境；受管端點適合希望降低維運負擔的團隊；地端或私有雲則適合資料不能離開內網、需要固定低延遲或已有硬體資源的場景。

AI模型部署不應把「模型能跑」視為完成。正式環境還需考慮身分權限、日誌去識別化、模型版本回滾、監控告警、金鑰管理、容量預測與災難復原。若服務使用 RAG，文件更新、索引版本和引用可追溯性也必須納入發布流程。

對有即時性需求的工廠、門市或移動設備，邊緣AI部署可以減少網路往返與資料外流風險。然而裝置端的 CPU、NPU、記憶體與散熱限制更嚴格，因此應先選擇已蒸餾、量化且任務範圍明確的模型，再測試離線、斷線重連與異常輸入情境。

• 雲端、受管服務與地端部署各有成本及治理取捨。
• 正式服務必須具備版本、監控、回滾與權限控制。
• 邊緣場景應優先驗證裝置限制與斷網行為。

以 PoC 降低蒸餾與部署決策風險

最可靠的做法是先以最小可行範圍驗證蒸餾效果，再決定是否投入正式系統。ALION 的 AI PoC 開發支援採用現場調查、目標設定、原型實證與效益驗證的方式，先釐清真正的業務瓶頸，而不是在需求尚不清楚時就直接購買大量 GPU 或開發完整平台。

PoC 的測試資料應貼近真實流程，例如將過往銷售與庫存資料用於需求預測，並比較多個模型的精度與可帶來的下單、庫存或生產計畫效益。對生成式 AI 而言，則可以用實際文件、真實提示與現場使用者回饋，驗證蒸餾模型是否真的降低人工處理時間。

ALION 的 AI 上游工程訂閱服務為月費 20 萬日圓起，包含需求梳理、設計文件與示範製作。這類小規模起步的價值，在於把模型品質、推論成本與使用體驗轉化為可討論的證據；即使結論是暫不開發，也能避免後續的大型投資浪費。

• 先用實際資料驗證，而非只看公開 benchmark。
• PoC 應輸出品質、效能、成本與 ROI 的判斷依據。
• 原型、設計與測試資產應可延續到正式開發。

建立持續監控與治理閉環

蒸餾模型上線後仍需要持續比較，因為資料分布、使用方式與教師模型能力都會改變。建議保存經過去識別化處理的輸入特徵、路由結果、延遲、成本、拒答、人工更正與使用者回饋，定期檢查品質是否因新產品、季節用語或政策變動而下降。

監控應把模型指標與業務指標放在同一張儀表板，例如任務完成率、人工轉接率、處理時間、每件成本與客訴類型。若只監看 GPU 利用率，可能錯過模型答得很快卻無法解決問題的狀況；若只看準確率，也可能忽略成本失控。

技術與法律治理也不可省略。訓練前要確認教師模型輸出能否用於蒸餾、資料是否含個資或營業秘密、第三方內容是否有授權限制，以及輸出是否需標示 AI 參與。可參考 Hinton 等人的原始論文、AWS 與 NVIDIA 文件建立技術基線，但企業仍應依自身合規要求完成審查。

• 持續監控資料漂移、品質退化與路由錯誤。
• 把技術指標連結到完成率、工時與成本等業務成果。
• 確認教師輸出授權、個資處理與稽核留痕要求。

可信參考資料

Hinton、Vinyals、Dean 的蒸餾論文：https://arxiv.org/abs/1503.02531；AWS Model Distillation 文件：https://docs.aws.amazon.com/bedrock/latest/userguide/model-distillation.html；NVIDIA TensorRT 文件：https://docs.nvidia.com/deeplearning/tensorrt/；vLLM 官方文件：https://docs.vllm.ai/；ONNX Runtime 量化文件：https://onnxruntime.ai/docs/performance/model-optimizations/quantization.html。