大型語言模型呼叫如何拆解成本：談談模型串聯

許多團隊一提到降低成本，第一反應是換成小型模型，不然就是刪減預算。這兩種方法都過於粗糙。另一種更可控的做法稱為模型串聯（Model Cascade）：讓便宜的模型先處理，當便宜模型「信心不足」時，再交給昂貴的模型處理。

原理

以意圖分類為例。當客服訊息進入時，先經過一個兩階段的流程：

一是由小型模型負責初步篩選，判斷是諮詢、故障回報、投訴還是無效訊息。二是如果小型模型給出的信賴度超過預設閾值，例如 0.9，就直接採用，這筆請求只花費便宜模型的 Token。三是若低於閾值，則升級至強大模型重新判斷，並將小型模型的判斷結果一同寫入上下文供參考。

帳很好算：將昂貴模型的單位成本記為 C1，便宜的記為 C2，升級率為 p，那麼單筆請求的平均成本為 C2 + p × C1。如果八成請求被便宜模型消化，升級率為 20%，綜合成本大約是原本的 40% 出頭；將閾值調寬一些、把升級率壓到 10%，成本還能再降一截，代價則是品質風險上升。

真正的工作量：資料與閾值

串聯並非搭建好管線就完事，有三項工程任務是無法迴避的。

**定義升級條件。** 模型自行回報的信賴度最為直觀，但不少推論框架要不就是不輸出 logits，要不就是需要根據溫度參數重新正規化後才勉強可用。可以退一步使用啟發式規則：同樣的問題讓小型模型採樣兩次，若給出不同答案，則視為信心不足；輸出過短、遺漏必填欄位、不符合格式約束，也直接升級。這些規則比單純使用信賴度更穩定，因為信賴度會隨著提示詞的微調而漂移。

**累積黃金測試集。** 從歷史請求中抽取五百到一千筆資料，讓強大模型給出參考答案，再讓便宜模型在同一組資料上執行一遍。你調整的其實是閾值曲線：在升級率多高時，正確率的下降幅度能控制在可接受範圍內，例如 1% 以內。沒有這組資料，閾值就只能憑感覺設定，切換流量後全靠線上錯誤來兜底。

**為昂貴模型保留後路。** 當升級鏈條滿載、強大模型超時或發生錯誤時該怎麼辦？是回傳小型模型的結果，還是明確表示「無法判斷」？在客服場景中或許可以兜底，但在涉及合規或金錢的場景中，悄悄用便宜模型冒充昂貴模型回答屬於嚴重事故。這個策略必須在切換流量前確定下來，並寫入警報機制中。

什麼情況不適合使用

三種場景下，使用串聯反而會虧損：

一是上游流量本來就很少，一天不到幾百筆請求，打通流程所花費的人力成本比省下的 Token 費用還多。二是任務具有強序列性，例如長文翻譯，便宜模型產出初稿後，昂貴模型仍須整篇審閱，「先便宜再昂貴」的總成本可能比直接呼叫昂貴模型還要高。三是從未測量過升級率，純靠猜測設計流程，那就先做好日誌埋點，量化出真實分布後再說。

最小落地路徑

若想嘗試，四步就夠。選擇一個日請求量一千筆以上、且有明確對錯標準的任務，累積五百筆黃金測試集。先開啟影子模式：完整執行串聯流程，但對外回傳的仍然是強大模型的結果，僅記錄兩邊的差異與耗時。對齊一兩週，當一致率和延遲都達標後再切換流量，先切換五分之一，不要一開始就全量切換。切換後持續監控升級率這一指標，若它突然上升，往往意味著資料漂移、提示詞改动或是上游出現異常，這個信號比查看錯誤日誌來得更早。

模型串聯並不神秘，本質上是將「每次都使用最昂貴的」改為「依據不確定程度付費」。難點在於資料和閾值，而非架構。