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%」,拿著這個結果去跟公司要硬體投資——先證明價值,再要錢,遠比空口要預算有說服力。
公司的真實資料絕不上免費雲。免費額度的代價常常是資料被拿去訓練。練手、驗流程,一律用合成資料或公開資料集;等到要用真資料微調,再回到公司自管的環境(地端或私有雲)去跑。「外面訓」訓的是流程與手感,不是把機密丟出去。
實測後記:我把甜蜜點階梯真的跑了一遍
寫完這篇後,我用免費雲端 GPU 把 10 個開源小模型(0.5B 到 7B)全跑了一遍,零樣本與微調各測一次。結論很直接:甜蜜點比我原本預期的還小。
1. 3B 以上,光靠 prompt(零樣本)就會用固定格式——這種「要模型用固定三段回答」的窄任務,根本不用訓練。真正需要訓練的,只有 0.5B/1.5B 那種零樣本不穩的小模型。
2. 訓練不是萬靈丹,調不好還會反效果:學習率太高、又沒梯度裁剪,幾十步就把小模型「練爆」成一直重複同一個字。右尺寸也包含「訓練火候」的節制。
3. 把「零樣本合規率 vs 模型大小」畫成一張圖,門檻一目了然:能穩定達標的綠燈,集中在 2–3B 以上。
換句話說:這個任務的正確答案,不是「要不要用 120B」,而是「其實 3B 配一個好 prompt 就結束了」。
實戰踩坑清單(這些沒人先跟你講)
「小模型省錢」的前提,是你別在下面這些坑上把省下的時間賠回去。這些都是跨專案通用的工程細節:
| 坑 | 症狀 | 修法 |
|---|---|---|
| 硬體選錯 | 量化模型在舊卡上直接「no kernel image」跑不動 | 4-bit 量化要 Turing 世代(如 T4)以上的 GPU,別用更舊的卡 |
| 多 GPU 亂用 | 兩張卡自動平行,4-bit 訓練直接崩(illegal memory access) | 鎖成單卡再訓 |
| 框架版本咬人 | 升級後 tokenizer 回傳型別變了、參數被改名,舊寫法壞掉 | 對齊版本、用當版的寫法 |
| 模型語言偏好 | 中文模型預設吐簡體字 | 在系統提示明講「全程繁體中文」 |
| 貪婪解碼鬼打牆 | 輸出一直重複同一個詞 | 生成時加 repetition penalty |
右尺寸不只是「選對模型大小」,還包括「硬體選對、版本對齊、生成參數設對」這些工程成熟度。這些細節踩一個,就把小模型省下的時間全賠回去。
同一套哲學,搬到影像 OCR
工廠現場一堆單據照片——發票、檢驗報告、材質證明書——要變成系統吃得下的結構化資料。同一套「右尺寸 + 零樣本先試」搬到視覺語言模型(VLM)一樣成立。
- 零樣本先上線:用小型 VLM(3B 級)直接把乾淨單據讀成 JSON,不訓練就能用。
- 只對做不到的難 case 微調:歪、糊、蓋章、多張擠一頁、缺欄位的爛照片,才針對那種場景合成假資料去微調。
- 多模型在爛圖上比拚:乾淨圖每顆 VLM 都會,爛圖才見真章——挑「爛照片上還讀得準」的那顆上線。
心法完全一致:零樣本先上線,只對做不到的難題微調。不管文字還是影像,右尺寸都是「用最小的、剛好夠的」。
視覺模型讀單據:VLM 整張讀 vs 先 OCR 再拼
把「右尺寸」搬到工廠單據 OCR(發票、檢驗報告、料牌…),第一個反直覺的結論是:對這種「短表單 + 欄位配對」的文件,讓視覺語言模型(VLM)整張讀,勝過「先用 OCR 引擎把字拆出來、再拼回結構」。
原因:OCR 引擎會把「欄位名」和「值」拆成分開的文字框,key 與 value 的位置關係就丟了;VLM 看整張圖、版面完整,直接讀對配對。但注意:VLM 在乾淨印刷體上贏,照片一髒(模糊/反光/傾斜)就崩——所以穩定的拍攝(例如固定攝影機)比一直換模型更關鍵。
每站一個模型?「模型階梯」與「最新不一定最好」
不同單據需要不同模型,沒有單一贏家。做法是一道模型階梯:先用 baseline 掃全部 → 沒過門檻的換更大/別的模型 → 換了還不行的才進「需調參」。這樣每個文件都用「剛好夠的最小配置」。
還有一個硬體現實:VLM 微調在消費級/免費 GPU(只有 fp16)常常直接 nan(訓練發散);要穩定微調得有支援 bf16 的卡。所以免費層的正解是零樣本 + few-shot(在提示裡塞幾個範例),把微調留給有對的硬體時再做。
到 90% 的安全設計:信心分級 + 人工複核
抽取準確率 50-60% 很危險、要 90% 才敢用——這判斷是對的。但「危險」不是靠把數字硬衝到 90% 解決,而是靠「系統知道哪些該信、哪些要人看」。
目標從「衝到 90% 準確率」換成「自動放行的那批夠準,不確定的都被人看到」——這個現在就做得到,不必等模型微調破關。
收尾:右尺寸是一種紀律
回到開頭那句。判斷一個團隊 AI 落地成不成熟,不是看他們敢不敢上最大的模型——那誰都會。而是看他們能不能精準地用最小的:有沒有固定評測集、有沒有「過門檻就停」的紀律、有沒有一張越長越厚的「任務形狀 → 配置」對照表。
大模型是一種能力,右尺寸是一種紀律。前者靠買,後者靠練。下一次你又想「先丟個 120B 上去」時,停一下,問自己一句:這任務,3B 會不會其實就夠了?
發佈留言