為什麼開源 LLM 應該按工作負載來選，不該看熱度

2026 年選開源 LLM，應該先看工作負載是否匹配，而不是追逐排行榜與發布熱度。

開源 LLM 已經多到不能再用「最新、最強、最多人討論」來做選型。真正該問的是：它在你的程式碼庫、RAG 流程或 agent 迴圈裡，會不會穩定做對事。模型一旦進入真實系統，錯的往往不是語言能力，而是工具呼叫、格式遵守、證據對齊與失敗恢復。

第一個論點：通用基準分數不是生產決策單位

HumanEval、MMLU、Chatbot Arena 這些分數只能說明模型在某種抽象測試裡表現不錯，不能直接推論到你的工作流。舉例來說，一個在公開榜單上很亮眼的模型，到了實際 coding assistant 場景，可能會改錯檔案、忽略 repo 內既有慣例，甚至在多步驟修改中把上下文弄亂；分數高，不代表它懂你的倉庫。

更實際的做法，是把評估改成工作負載導向。若你在選 coding 模型，就拿真實專案的修補任務測 revision drift；若你在做 RAG，就看它是否忠於檢索內容、是否會亂編引用；若你在做 agent，就測 JSON 合法率、工具呼叫重試與停止條件。這些指標直接對應成本、維運與事故風險，比單一 leaderboard 更有決策價值。

第二個論點：專精化比盲目追大模型更重要

2026 年的開源模型市場，正在獎勵專精而不是純粹堆參數。很多 7B 到 14B 的 instruct 模型，若針對結構化輸出、工具使用或檢索對齊做過訓練，實際表現可以壓過更大的通用模型。對 agent 來說，一個能穩定吐出合法工具呼叫的小模型，往往比一個會長篇大論、但常常偏離 schema 的大模型更有價值。

這也是為什麼「越大越好」在今天已經不成立。70B 模型在 demo 裡很有氣勢，但如果你的產品依賴固定格式、低延遲與可預測的 stop behavior，7B 的 JSON 專精模型反而可能是更好的生產選擇。RAG 也是同樣邏輯：最好的模型不是最會說話的那個，而是最能被檢索證據約束、最少胡猜的那個。

反方可能怎麼說

支持通用榜單的人並不是沒有道理。對很多團隊來說，時間很少、人力更少，先看公開排名可以快速縮小候選名單；在完全沒有內部評測資料時，這些分數至少提供一個粗略起點。對小團隊而言，這種 triage 甚至是必要的，因為自己從零建立評測集本身就有成本。

而且，公開基準確實有它的價值。它們能幫你避開明顯落後的模型，也能讓不同供應商之間有一個共同語言。問題不在於它們存在，而在於很多團隊把它們誤當成最終答案，忽略了自己產品的失敗模式。

但這個反方立場只能成立在「初篩」階段。只要你的系統會碰到真實用戶、真實資料與真實金錢，通用排名就不夠了。你需要的是能在你的任務上維持正確率、延遲與成本平衡的模型，而不是一個在抽象題庫裡看起來很強的名字。

你能做什麼

如果你是工程師、PM 或創辦人，別再問「哪個模型最好」，改問「哪個模型最適合這個工作負載」。先從自己的 production sample 做一個小型 golden set，挑兩到三個模型跑同一組任務，分別量測 coding 的 revision drift、RAG 的 evidence fidelity、agent 的 tool-call reliability，再用延遲與成本做第二層篩選。最後選那個在你場景裡最穩、最便宜、最少出事的模型；這才是能上線的選型方式。