把每一個分類、摘要、抽欄位的需求都丟給雲端大模型，是這兩年最常見也最貴的架構錯誤。當 7B、8B 等級的開源模型可以在一張消費級 GPU、甚至筆電上跑出堪用結果，「先打 OpenAI 再說」這條預設路徑就值得重新審視。
為什麼小模型值得重新評估
小型語言模型這一兩年的進展，重點不是 benchmark 分數，而是「在窄任務上夠用」的門檻被大幅拉低。像 Llama、Qwen、Gemma、Phi 這些系列都釋出了參數量較小但經過良好指令微調的版本，搭配 llama.cpp、Ollama、vLLM 等執行框架，部署成本比兩年前低很多。
關鍵在於：大部分企業內部的 AI 任務並不需要通用智慧。舉例來說，假設你要做的事情是「把客服信件分到十個分類」、「從 PDF 抽出固定五個欄位」、「為商品描述產生 SEO 摘要」，這些都是窄、可重複、可被 few-shot 或微調覆蓋的任務。對這類工作，大模型多出來的能力是付費浪費。
更實際的考量是資料邊界。一旦輸入內容含個資、合約、未公開財報，把資料送出公司網路本身就是合規風險。本地端推論不是炫技，是把法遵問題從合約層退回到技術層解決。
那什麼時候還是該用雲端大模型
小模型不是萬靈丹。以下情境我們的經驗法則仍是優先選大模型 API：
- 任務本身需要長鏈推理或跨領域常識，例如複雜的程式碼重構、法律條文比對。
- 流量極低、用量極不穩定，自架反而養機器養得不划算。
- 團隊還沒有 MLOps 能量，連監控、版本管理、retry 都沒人顧。
一個務實的架構是「混合路由」：先用小模型處理九成的標準請求，遇到信心分數低、或被分類為複雜的請求才升級到雲端大模型。下面是一段示意骨架：
# 示意：實際模型呼叫請依照所用框架文件
def route(prompt: str):
result = local_llm(prompt)
if result.confidence < THRESHOLD or result.needs_reasoning:
return cloud_llm(prompt)
return result
這種路由的好處不是只省 API 費用，而是讓你保有議價權——當某家雲端供應商漲價或封鎖你的用途時，至少底層需求還跑得動。
我們的觀察
小模型不會取代大模型，但會把「AI = 呼叫 OpenAI」這個直覺打散。我們在報價時通常會建議客戶先把任務拆細，問三個問題：這個請求需不需要通用推理？輸入裡有沒有不該外流的資料？流量穩不穩定？這三題的答案，往往就決定了該不該為這個功能多養一台 GPU，而不是模型本身有多潮。