小模型正在吃掉大模型的午餐

把每一次分類、摘要、欄位抽取都丟給雲端大模型，可能是這兩年最貴的技術債之一。不是因為大模型不好，而是因為大部分企業內的 AI 任務，其實根本不需要那麼大的腦袋。

過去一年多，開源小模型（大致落在 3B 到 14B 參數區間，例如 Llama、Phi、Qwen、Gemma 這些系列）在特定任務上的表現，已經追到足以取代前一代旗艦模型的程度。搭配 llama.cpp、vLLM、Ollama 這類推論工具，一張消費級 GPU、甚至純 CPU 都能撐起中等流量的內部服務。這件事的商業意義不是「模型變強」，而是「單位任務成本可以壓到讓你重新思考架構」。

什麼任務適合切給小模型

經驗上，越是「格式固定、判斷邊界清楚、上下文短」的任務，小模型的性價比越高。舉幾個典型情境（這些是說明用的假設場景，不是特定客戶案例）：

• 意圖分類與路由：客服訊息分流、工單分派、內部搜尋 query 分類。這類任務答案空間有限，小模型加上 few-shot 就能穩定。
• 結構化抽取：從發票、合約、報價單、Email 抽出固定欄位。搭配 JSON schema 約束輸出，7B 級模型往往夠用。
• 短文本摘要與改寫：例如把冗長客訴整理成一句話標題、把技術規格改寫成行銷語言。
• 內容審核與標籤：判斷是否觸及某類敏感詞、打上情緒或主題標籤。

反過來，需要廣泛世界知識、多步推理、或跨長文件比對的任務，例如「幫我讀完這 200 頁法規再回答一個開放性問題」，還是乖乖用大模型或 RAG + 大模型。硬把這種活塞給小模型，只會得到看起來像答案的幻覺。

導入時最常見的四個坑

1. 沒有評估集就開始換模型。憑感覺說「這個模型比較好」是最貴的錯誤。先花時間標一組幾百筆的評估資料，之後每次換模型、改 prompt 都能量化比較。
2. 以為 prompt 可以直接搬。同一段 prompt 在 GPT 級模型跑得好好的，換到 7B 小模型可能整個崩掉。指令要更明確、範例要更多、輸出格式要用 schema 或 grammar 強制約束。
3. 太早跳進 fine-tune。多數企業任務用 few-shot、好的 system prompt、加上結構化輸出就能解掉，fine-tune 帶來的維運成本（資料版本、重訓、評估）常常不划算。等到 prompt 工程真的打不動了再考慮。
4. 忘了算 TCO。本地推論不是免費的，GPU、電費、維運人力、模型更新都是成本。要跟雲端 API 的實際用量放在同一張表上比。

我們的觀察

真正在生產環境跑得穩的架構，幾乎都不是「全部本地小模型」或「全部雲端大模型」，而是混合：便宜、量大、格式固定的任務交給本地小模型；少數真的需要推理深度的請求，才路由到雲端大模型。決策點不在「哪個模型比較強」，而在「這個任務的錯誤成本和呼叫頻率，值不值得付大模型的錢」。在報價時我們通常會建議客戶先做這層分流盤點，再選型，順序反過來會很痛。