為什麼「換更大的模型」常常不是答案：AI 系統的選型與降級鏈

上次一個朋友被線上故障逼到牆角，第一反應是「把 GPT-4 換成更大、更貴的模型」。結果故障沒好，帳單倒是翻了一倍。這個反應本身沒錯——大型語言模型確實更強。但大多數真實的線上問題，並不是「模型不夠聰明」，而是工程面沒把冗餘、成本、延遲這幾件事理順。先把這個區分清楚，後面所有選型決策才不至於跑偏。

先看清問題出在哪一層

一次對話延遲高、答非所問、還是報錯，對應的解法完全不同。延遲高，往往不是模型弱，而是上下文太長、KV Cache 沒命中、或者請求沒並發好；答非所問，可能是提示詞寫漏了約束、結構化輸出沒鎖死格式；報錯率飆升，那多半是流控超限或網路抖動。把「延遲高」歸因到「模型不夠大」，你只會花大錢請一個更慢的演員來演同一齣戲。換句話說，先定位到是模型能力層、推論優化層，還是工程層的問題，再動手。

能小就不要大

這是一個被反覆驗證、但也最常被忽略的原則。分類、抽取、簡單問答、格式轉換這類任務，一個小模型或經過蒸餾的小型模型，在實際指標上常常打平甚至超過大型模型，而成本能差一到兩個數量級，延遲也低得多。真正需要大型模型的場景很窄：真正的多步推論、複雜程式碼、開放性創作。別圖省事全堆到旗艦模型上，那是把 90% 用不上的算力當成保費在交。

搭一條降級鏈，而不是押單一模型

生產系統裡，單一模型就是你的單點故障。本地小模型掛了、雲端 API 限流、或者某家服務整體抖動，只要你的鏈路只有一條，用戶就看得見。常見的做法是分層：優先走本地或便宜的小模型處理大部分請求，命中不了或信賴度低，再升級到更強的雲端模型；同時接第二家雲端模型作為備援。哪一層卡住就往下走，哪一層超預算就往上退。關鍵不在於某一層多完美，而在於整條鏈能在任何單點失效時繼續給出「能用」的回答，哪怕品質降一檔。

成本是設計出來的，不是算出來的

一個回答到底值多少錢，取決於它走了哪條鏈、消耗了多少 token、快取命了多少。把這筆帳拆開看，你會發現三件事經常比「換模型」更省錢：複用前綴快取止血重複請求，用結構化輸出減少無效重新生成，對高頻任務蒸餾一個小模型專門頂上。這些手段不碰模型本身，卻能把整個系統的有效成本壓下去一大截。等到哪天你發現帳單又漲了，別再想「要不要換更大的」，先問「這條鏈還能不能縮」。

小結

「模型更大」是一個直覺，不是一個方案。真正的系統能力來自分層編排：先準確定位問題在哪一層，能小就小、該大才大，把降級鏈搭厚、把成本拆細。模型會一顆一顆地換、一版一版地迭代，但你搭的這套架構能一直用下去。下次再遇到線上問題，先別急著升配，先問一句：這到底要更大的腦子，還是要更好的接線？