蒸餾有一個行銷版故事，也有一個真實版故事。行銷版說：你用一個便宜的 7B 學生模型換掉昂貴的前沿模型，還能保住 95% 的品質。真實版是：多數嘗試蒸餾的團隊會發現，學生模型在評估集上還可以、在生產環境普普通通、一旦漂移就完全無法除錯。蒸餾是一個真的有用的工具——但「什麼時候該把它從工具箱拿出來」這個決策，值得比目前常見的做法更謹慎。

這篇是一份決策框架，不是教學。如果你正在評估某個特定工作負載該不該用 Claude 做蒸餾，以下就是你要看的訊號、你要推算的經濟結構，以及一些能讓你不至於「把整個產品押在一個學生模型上」的路由模式。

那個假承諾（為什麼「用 7B 取代 Opus」通常是錯的）

聽起來很誘人：你的 Claude 帳單一直往上爬，開源小模型微調的花費只是一小部分，一旦分攤下來、在自家 GPU 上做推論幾乎等於免費。換過去，繼續出貨。

實際上會發生的事沒那麼單純。學生模型在你當初拿來蒸餾的那個分佈上表現不錯，然後在長尾靜悄悄地失手。使用者問了一個稍微超出範圍的東西，或是用不熟悉的方式問了一個熟悉的請求，Claude 本來會給出保留、會反問、或會拒絕，而學生就會產出一段自信滿滿的胡言亂語。你好幾週都不會發現，因為你的評估集跟訓練資料是從同一個分佈抽出來的。

第二個問題是：能力在你沒量測的維度上崩塌。你為了「幫這張工單分類」而蒸餾，學生分類做得很好。但在你管線的另一處，你原本也倚賴 Claude 幫每張工單寫一句連貫的摘要放進稽核記錄裡。學生產出的摘要能通過粗略檢查、但仔細一讀就漏洞百出。沒人會注意到，直到稽核人員注意到。

第三個問題是：如果你把成本算誠實一點，「便宜的 7B 學生」通常比 API 還貴。GPU 租用、營運工時、打造和維護訓練管線的工程師人月、每次資料分佈漂移都要重新訓練的循環——這些成本都真實存在，而且都前置。不管蒸餾模型最後有沒有進生產，你都得付。

以上這些都不代表蒸餾是錯的。它們代表「用 7B 換掉 Opus」這個框架本身就不對。對的框架是：我工作負載中的哪一個特定切片，具備讓蒸餾真的划算的那些特性？

5 個訊號：這個任務適合蒸餾

蒸餾能真正回本的任務，共享一組特徵。當你看到其中大多數都成立時，經濟數字才會開始站得住腳。

1. 任務範圍夠窄。 不是「客戶支援」，而是「給定一張工單，把它分到十二個類別之一，並抽出受影響的產品 SKU」。範圍窄的任務有界的輸入分佈、有界的輸出空間，而且很少有需要廣泛世界知識才能處理的邊界情況。Claude 的通用性用在這種任務上是浪費，而這正是學生模型追得上的原因。

2. 行為很穩定。 這個任務過去半年沒實質變過，未來也不打算變。如果你的產品經理下一季要加三個新類別，每次改動就是一次重訓循環。蒸餾獎勵穩定、懲罰動盪。

3. 呼叫量很高。 你一個月的呼叫是以百萬計，不是幾千。蒸餾有固定成本——老師端推論來建資料集、訓練、評估、部署——加上每次呼叫的節省。高流量會攤掉固定成本；低流量攤不掉。

4. 推理理由「像程式」。 Claude 在這個任務上的推理看起來像是照著檢查表走、或套用一組規則，而不是綜合出全新的洞見。像程式的推理理由可以被壓進小模型裡；開放式推理不行。如果你可以想像把邏輯寫成一個很長的決策樹，那你大概蒸餾得了。

5. 結果可以驗證。 你可以便宜且自動地判斷學生的輸出對不對。結構化輸出、抽取式任務、能編譯又能通過測試的程式碼、有標準答案的分類——這些都是可驗證的。「這個模型有沒有寫出好回覆」不是可驗證的，除非你另外有一個你信任的驗證器。

蒸餾的強力理由，是這五點裡有四到五點成立。只成立兩三點，你多半應該繼續用 Claude，改去最佳化別的東西——prompt 長度、快取、路由。

5 個訊號：這個任務不適合蒸餾

反過來看同樣重要。以下是那種「紙上看起來很誘人、生產環境會讓你失望」的任務。

1. 任務範圍廣或開放式。 「回答任何客戶問題」或「寫一封有幫助的回信」，這些會拉到通用能力。基於某個特定範例分佈訓出來的學生，一旦現實漂離那個分佈就會壞——而現實一定會漂。

2. 推理理由需要世界知識或判斷力。 當 Claude 是在調用廣泛知識、權衡利弊、或行使品味時，它就是個不適合蒸餾的目標。老師在這些任務上的輸出，不只是輸入的函數；它是「輸入 + 老師整個訓練歷程」的函數。這種東西你壓不進 7B 模型裡。

3. 分佈正在漂移。 你的輸入每個月都在變——新產品、新使用者行為、新術語。蒸餾模型會在你訓練的那一刻凝結。如果前沿模型能自然適應變動中的世界、而學生不能，你會燒掉數個工程師人月只為了維持原地不動。

4. 一個微妙失敗的代價很高。 蒸餾模型的失敗方式跟老師不一樣。它們傾向於「自信地失敗」，產出聽起來合理、但錯得很微妙的東西，人類審查者也可能沒抓到。如果一個錯誤答案的代價很高——法律審查、醫療分診、金融建議——蒸餾的尾端風險通常不值得省下來的執行成本。

5. 你建不出驗證器。 沒有自動檢查學生輸出的方法，你就沒辦法持續評估、沒辦法建一個「低信心就退回 Claude」的路由器、也沒辦法偵測退步。沒有驗證器的蒸餾，是一場閉眼下的賭注。

注意這裡的不對稱：要多個正面訊號才足以支持蒸餾，而任何一個強烈的負面訊號通常就足以否決它。這個比例才對。蒸餾是一種最佳化；最佳化只有在案例夠清楚時才該追。

經濟結構：老師端成本 vs 執行期節省

經濟問題不是「我學生模型的推論比 API 便宜嗎？」，而是「在我在乎的時間範圍內，蒸餾的總成本能不能贏過持續用 API 的總成本？」這是一道「損益兩平」計算，值得先用符號推一次，再套數字。

設：

繼續用老師大概花費 N · c_t。

蒸餾並加上路由大概花費 D + T + M + N · ((1 - q) · c_s + q · c_r)。

蒸餾要贏得看：

N · c_t > D + T + M + N · ((1 - q) · c_s + q · c_r)

換句話說，每次呼叫節省下來的 (c_t - (1 - q) · c_s - q · c_r)，乘上 N 次，要夠大到把 D + T + M 償還。

這條公式立刻能看出幾件事。呼叫量在實務上是二次方地重要：N 越高，既攤掉固定成本，也讓節省變得看得見。品質差距的影響比大家想像的更大：如果 q 是 20%、而 c_r 又貼近 c_t，你光是退回路徑就把大部分節省吃掉了。維護成本不是可選項：不編進去，你會在事故裡付出來。

不要在這裡放假數字。這條公式的重點是逼你誠實估每一項。多數團隊把數字一套進去就會發現：要不是 N 太小，就是 q 太高，不然就是把 M 忽略了，最後的損益兩平年限比這個功能的壽命還長。

當公式真的成立時，通常是壓倒性地成立——省 5 倍、10 倍，不是 20%。如果你估出來的節省只有 15%，那大概是有某項沒算到，真正的答案很可能是負的。

3 種路由模式

即使蒸餾在經濟上說得通，單獨部署學生模型也很少是對的架構。真正有趣的問題是：怎麼在學生、老師和其他元件之間路由。三種模式可以涵蓋絕大多數的生產環境設定。

串接（Cascade）

每次請求先送給學生。如果學生的輸出通過某個信心閾值——一個基於 logit 的分數、驗證器的檢查、或某個「離開分佈」的訊號——就把它回傳。如果沒通過，退回老師。

這是主力模式。它在高信心的多數流量上抓到大部分執行期節省，同時在長尾上保留老師的品質。工程複雜度中等：你需要一個真正的信心訊號（不是模型自報的確信度，那通常沒用），也需要把退回率當成「漂移的先行指標」來監控。

串接會壞掉的時候，是你的信心訊號本身壞掉。如果學生是「自信地錯」，串接就會讓那些失敗漏過去。要投資的是訊號，不只是學生。

蒸餾 + 驗證

學生產出一個輸出，然後由一個獨立的驗證器——有時是老師、有時是一個小型規則引擎、有時是第二個蒸餾模型——去檢查。驗證失敗就用老師重試或升級處理。

當驗證器比老師便宜很多、也比學生自報的信心可靠很多時，這個模式最亮眼。抽取式任務（模型是不是拉到對的欄位？）、結構化輸出（這份 JSON 過不過驗證？）、程式碼（能不能編譯、能不能通過測試？）都是天然人選，因為驗證幾乎不花錢、幾乎不會漏。

陷阱是當「驗證器」其實只是另一個和學生盲點相同的模型。那你只是加了延遲、沒加安全。

集成（Ensemble）

學生和老師平行跑；你把它們的輸出合併或仲裁。有時候用學生做初版、便宜、快答；老師做權威答案，第二串流才回來。有時候你做投票加權。

在成本敏感的設定裡，集成是最少見的模式，因為通常比只用老師還貴。它真正的價值出現在延遲敏感的路徑上：學生的答案立刻串流給使用者，老師的答案在背景完成、若不同意就覆蓋。那是 UX 上的勝利，不是成本上的勝利。

多數團隊應該先選串接，等有驗證器時再加上；只有在有某個特定延遲需求、其他方法都做不到時，才去打造集成。

對的問題

對的問題不是「我們該不該把 Claude 蒸餾出來？」，而是「我們的工作負載裡，哪一個切片具備那些特性——範圍窄、行為穩定、呼叫量高、推理像程式、結果可驗證——讓蒸餾真的值得那些持續成本？」對多數團隊來說，答案是「一到兩個切片，不是整個產品」。那些切片值得謹慎地去追。其餘的，還是留給老師。

如果你覺得自己已經找到好人選了，接下來的問題就轉為實務：要怎麼建一份能真正教會學生「Claude 到底知道什麼」的推理理由資料集、以及要怎麼讓蒸餾聚焦在解釋、而不只是模仿。那是另外兩篇文章的主題。