AI 落地的成熟度,不是看你敢不敢用最大的模型,而是看你能不能精準地用最小的。
- 把「遇到任何問題就丟一顆 120B」當預設,是懶惰且昂貴的做法:慢、離線跑不動、還學不到「這任務其實 3B 就夠」。
- 正確工程是「甜蜜點測試」:定好門檻、固定評測集,由小往大爬,第一個過門檻的配置就停,不再往上。
- 硬體限制(例如一台 64GB 的筆電)不是絆腳石,而是逼你右尺寸的好事。
痛點:別遇到問題就丟最大的模型
很多人做 AI 落地,養成一個壞習慣——不管什麼任務,先抓一顆手上最大的模型上去跑。分類文件?丟 120B。抽個欄位?丟 120B。對帳?也丟 120B。反正大模型什麼都會,能跑就好。
這看起來很省事,其實代價很高。第一,慢又貴:一顆百億參數的模型,推理延遲和算力成本是小模型的好幾倍,量一大就是真金白銀。第二,離線跑不動:很多工廠現場、資安嚴格的內網根本沒有高階 GPU,大模型塞不進去,整套方案在現場直接卡死。第三,也是最隱形的——你學不到東西。當「丟最大的」永遠會過,你永遠不會知道「這個任務其實 3B 就解得漂亮」。這份知識,是把 AI 從玩具做成生產線的關鍵。
真正的工程,是替每個任務找到剛好夠解的最小配置。這篇分享一套可操作的方法:甜蜜點階梯。
核心觀念:任務越窄,甜蜜點越小
先建立一個直覺:模型需要的大小,跟任務的「寬窄」成正比,而不是跟任務的「重要性」成正比。一個窄、重複、規則清楚的任務,甜蜜點通常小得驚人。
企業自動化(RPA 類的活)的痛點,恰好幾乎都長這樣:把 A 系統的欄位搬到 B、判斷這張單該不該放行、把一段非結構化文字整理成固定 JSON、對兩份報表找出差異。這些任務窄、重複、規則清楚——這正是小模型的天下。你不需要一顆會寫詩、會證明數學、會多國語言的通用大腦,來做「把日期字串正規化」這種事。
所以硬體限制反而是好事。當你只有一台 64GB 的筆電可用,你被迫去問「這任務最小要多大?」,而不是無腦往上加。這個約束,會逼出右尺寸的紀律。相關的機器實測與 MoE 取捨,我在 DGX Spark 打造私密 AI 分身 和 本地 AI 模型完整實測 裡有更細的數字。
甜蜜點測試協議:由小往大爬,第一個過門檻就停
這是全文最該收藏的一段。甜蜜點測試不是玄學,是四個步驟:
- 先定「夠好」的門檻——用可驗證的標準,不要用「我覺得對了」。例如:準確率 / F1 分數,或最務實的「人工看 N 筆(例如 50 筆)要全對」。門檻先寫死。
- 準備一份固定的評測集——同一批題目,從頭到尾用它量每一個配置。評測集不能中途換,否則分數不可比。
- 由小往大爬階梯,每一階用同一份評測集量分。
- 第一個過門檻的配置,就是甜蜜點,記下來,不再往上。把它累積成一張「任務形狀 → 配置」對照表,下次遇到同型任務直接查表起跑。
階梯的順序長這樣(由便宜到貴):
重點在那個「就停」。只要 ③ 的 7B 已經穩定過門檻,你就不需要知道 14B 會不會更好——它更貴、更慢、更難塞進現場,而效果對這個任務沒有差別。停在夠用的那一階,就是右尺寸。
不同任務形狀,從哪一階起跑?
與其每次都從 3B 從頭爬,不如用一張先驗表,依任務的「形狀」決定起跑階。起跑不代表終點——還是要跑評測集確認,但這張表能省掉前幾階的空轉:
| 任務形狀 | 建議起跑點 | 說明 |
|---|---|---|
| 固定類別分類 | 3B 起 | 類別固定、規則清楚,小模型 + few-shot 常常就夠。 |
| 抽欄位成 JSON | 7B 起 | 要穩定吐合法結構,7B 的指令遵循明顯比 3B 可靠。 |
| 規則對帳 / 數值比對 | 常常不用 LLM | 先寫規則(if / diff),小模型只兜「規則抓不到的異常」。別拿 LLM 做算術。 |
| 摘要 | 7B 起 | 要抓重點又不失真,7B 是務實起點。 |
| 要查知識的問答 | 7B + RAG | 知識放外部檢索,模型只負責組織答案,不靠參數硬記。 |
| 多步推理 / 需要規劃 | 14B 起 | 真的需要「想」的任務,才值得往上加大腦。 |
這張表的精神:需要「想」才給大模型,只是「做」的活給小模型,純「找」的活優先寫規則。 想更白話地判斷從硬體到能力該怎麼選,可以參考 我該選哪個 AI 模型? 這篇。
心法一:外面訓、裡面跑
階梯爬到 ⑤ 要微調時,很多人卡在「現場沒 GPU、又不能連網,怎麼訓?」答案是把訓練和推理拆開。
訓練在外、部署在內。 在有網路的環境(例如免費雲端 GPU)把 LoRA 權重訓好,打包成一個離線推理包;斷網、資安嚴格的工廠現場,只跑推理,不做訓練。現場那台機器永遠只需要載入模型 + 權重吐結果,不需要算力去 fine-tune。這樣既滿足資安(現場離線),又不被現場硬體綁死。把開源模型養成專屬資產的完整流程,我寫在 開源腦微調實戰;一個從收資料到訓練小模型的完整案例則在 工廠自動化收資料到訓小模型。
心法二:零本地機器,也能今天就開始
最後一個常見藉口:「我們還沒買 GPU,等硬體到位再說。」不必等。
用免費雲端 GPU(每週有數十小時額度)+ QLoRA,就能微調 7B 以下的模型。你可以先用它證明「這任務微調後真的從 78% 拉到 95%」,拿著這個結果去跟公司要硬體投資——先證明價值,再要錢,遠比空口要預算有說服力。
公司的真實資料絕不上免費雲。免費額度的代價常常是資料被拿去訓練。練手、驗流程,一律用合成資料或公開資料集;等到要用真資料微調,再回到公司自管的環境(地端或私有雲)去跑。「外面訓」訓的是流程與手感,不是把機密丟出去。
收尾:右尺寸是一種紀律
回到開頭那句。判斷一個團隊 AI 落地成不成熟,不是看他們敢不敢上最大的模型——那誰都會。而是看他們能不能精準地用最小的:有沒有固定評測集、有沒有「過門檻就停」的紀律、有沒有一張越長越厚的「任務形狀 → 配置」對照表。
大模型是一種能力,右尺寸是一種紀律。前者靠買,後者靠練。下一次你又想「先丟個 120B 上去」時,停一下,問自己一句:這任務,3B 會不會其實就夠了?
發佈留言