當大家把目光放在動輒上千億參數的通用大模型時，這篇 Training a 4B model to produce 81% faster query plans than Postgres 展示了另一條路，作者 polyphilz 訓練了一個僅 40 億參數的模型，專門用來產生資料庫查詢計畫，結果比 Postgres 原生規劃器快上 81%。這則消息之所以值得關注，在於它證明「小模型＋特定領域」的組合，可能比通用大模型更適合解決資料庫這類高度結構化的問題。
為什麼查詢計畫值得用模型來做
資料庫查詢計畫的產生，本質上是一個搜尋與成本估算的問題。Postgres 的規劃器依賴統計資訊與啟發式規則，當資料分布傾斜、資料表關聯複雜時，往往選出不是最佳的執行順序。作者看準的正是這個長年存在的問題，查詢計畫的好壞，直接決定資料庫回應時間。
傳統做法是調整統計目標或手寫提示，但這些手段需要經驗，也難以規模化。若能讓模型學會從查詢結構直接推斷出較佳的計畫，就有機會繞過人工調校的瓶頸。
40 億參數的模型，為何反而夠用 ?
這項實驗的關鍵在於把問題縮小到「查詢計畫」這個單一任務。相較於通用語言模型需要理解整個世界，這個 40 億參數的模型只需要學會查詢語法、資料表結構與成本之間的對應關係。作者並未追求模型規模，而是聚焦在訓練資料與目標函數的設計。
換句話說，這是一個典型的領域特化案例：模型不需要什麼都懂，只要在特定任務上比現有工具更準、更快，就有實用價值。這也解釋了為何它能在相對小的參數量下，達到 81% 的加速幅度。
81% 的加速代表什麼意義
根據原始文章，這個模型產生的查詢計畫在測試中比 Postgres 原生規劃器快 81%。這個數字若能在更多工作負載上重現，代表資料庫效能有機會在不改硬體的前提下明顯提升。對需要處理大量查詢的服務來說，這直接關係到成本與使用者體驗。
不過，單一基準測試的結果仍需謹慎看待。查詢計畫的品質會隨資料分布、索引設計與並行度而變動，81% 是特定條件下的成果，而非通用保證。
社群討論的幾個重點
社群討論集中在幾個方向，有人質疑模型是否真的理解成本模型，還是只是記住了訓練資料中的模式；也有人關心這樣的做法能否整合進現有資料庫，而不只是實驗室裡的展示。
另有留言指出，若模型能持續從執行結果回饋中學習，長期下來可能比靜態的統計資訊更適應資料變化。這些討論反映出社群對「模型輔助資料庫」的期待，同時也提醒了驗證與落地的重要性。
用領域特化的小模型解決特定問題
這則案例的價值不在於模型多大，而在於它示範了一種務實路線，用領域特化的小模型，解決傳統工具難以最佳化的問題。
CyberQ 認為，對台灣的開發團隊而言，與其追逐通用大模型，不如先盤點自身系統中重複出現的效能問題，評估是否能用小規模模型切入。當然，任何加速數字都需經過獨立驗證，才能成為正式產品的一部分。
