Liquid AI在Hugging Face上釋出LFM2.5系列的一批新checkpoint,格式為GGUF Q4_0,訓練方法叫QAD(quantization-aware distillation,量化感知蒸餾)。四種尺寸(230M、350M、1.2B-Instruct、2.6B)在評測上分別恢復了各自BF16基準97.1%、96.5%、97.4%和96.6%的成績。
對不玩本機推論的人來說,這行數字沒什麼衝擊力。要看懂它,得先知道Q4_0在llama.cpp生態裡是什麼地位。
一個被社群放棄的格式
Q4_0是最早那批4位元量化方案,規則簡單粗暴:每32個權重一組,共用一個縮放係數,其餘直接壓成4位元整數。後來社群做出K-quant系列(Q4_K_M、Q5_K_M等),按張量重要性分配不同位元寬度,同樣體積下精度明顯更好,Q4_0就基本退場,只留在一些老舊裝置和老舊執行環境裡。
它有一個別人拿不走的優點:結構規整,能直接對應到Arm CPU的int8點積指令上。K-quant的分塊和查表在手機CPU上得多繞幾步,Q4_0不用。Liquid AI這次給的速度數據就是衝著這一點來的——同一批模型,Q4_0 checkpoint比Q5_K_M快4%到33%,比Q4_K_M快3%到14%。
所以卡住Q4_0的,一直是精度那一端。QAD衝的就是這個。
把量化搬進訓練流程
常規做法是PTQ(post-training quantization,訓練後量化):模型訓完再壓,壓完看掉多少,掉太多就換個格式重來。QAD的思路是讓模型在訓練階段就先知道自己未來會被壓成什麼樣:高精度的教師模型往量化後的學生模型上蒸餾,量化限制參與訓練,權重分佈提前往4位元網格上靠。Liquid AI在部落格裡的說法是QAD大幅改善了Q4_0 checkpoint。
這不是新概念,量化感知訓練在視覺模型上已經用了很多年。搬到語言模型上麻煩在成本:每一種目標格式都要單獨跑一輪訓練。廠商願意花這筆錢,代表它算過帳——端側模型的下載量和呼叫量,值得為一種格式單獨訓練一次。
四台機器上的驗證
測試涵蓋兩類硬體:MacBook Pro和NucBox EVO-X2走GPU推論,三星Galaxy S26 Ultra和樹莓派5走Arm CPU推論。樹莓派5出現在名單上有點意思,它代表的是那類沒有GPU、記憶體也吃緊的場景,Q4_0的優勢在這裡最大。
粗算一下體積:2.6B參數按4位元存,權重大約1.4GB出頭,加上KV cache和執行時開銷,一台8GB記憶體的手機裝得下,還能空出手做其他事。230M那個更是幾百MB的量級,塞進一個App裡當本機功能用完全現實。
這批checkpoint在賭什麼
取捨的方向倒是新的。過去兩年端側推論的主流做法是把模型做小:蒸餾出更少的參數量,或是換更聰明的量化格式。Liquid AI這次選了第三條路,格式不動、參數量不動,把優化壓力全部轉移到訓練端。
代價是它只對自家模型有效。社群沒辦法拿這套方法去救別人放出來的Q4_0權重,那需要原始訓練流程。這是模型廠商才能提供的東西,也是端側小模型這條賽道上少數幾個能拉開差距的地方——同樣是2.6B、同樣跑在llama.cpp上,誰的4位元版本掉得少,誰就贏一局。
對開發者來說門檻沒變:GGUF Q4_0是最通用的格式,llama.cpp和任何相容Q4_0的執行環境都能直接載入,不改程式碼,不加新運算子。選它而不用自訂格式的原因也在這裡,相容性本身就是分發能力。
參考來源:Liquid AI官方部落格、CocoLoop、Hugging Face模型頁;四個尺寸的精度恢復比例與兩組速度區間已對照官方公布數據核實。