今天，我們發布了 QAD Q4_0 GGUF 檢查點。這些是 LFM2.5-230M、LFM2.5-350M、LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B 模型的更新版 4 位元檢查點。它們讓開發者能夠以 Q4_0 的記憶體和速度執行 LFM2.5 模型，同時避免通常會發生的品質下降。
這些模型是透過「量化感知蒸餾 (Quantization-Aware Distillation, QAD)」技術訓練的，此技術將一個高精度教師模型蒸餾到一個量化後的學生模型中。它們保持了原生 Q4_0 的低記憶體佔用和高吞吐量，並恢復了約 97% 因量化而損失的 BF16 平均準確度。
針對這四個模型，我們將其透過訓練後量化 (PTQ) 生成的 GGUF 與 QAD Q4_0 檢查點進行了比較。測試基準涵蓋了推理、指令遵循、工具使用和代理能力，包括 GPQA Diamond、MMLU-Pro、IFEval、IFBench、Multi-IF 和 BFCLv4。
BF16 GGUF 作為格式內的性能上限。我們還加入了適合規模的數學評估：LFM2.5-230M 和 LFM2.5-350M 使用 GSM8K，而 LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B 則使用 AIME25，並報告了五次重複測試的平均值。
總體而言，QAD 技術顯著提升了所有四個模型的 Q4_0 檢查點效能。這些 QAD 檢查點分別保留了其 BF16 基準效能的 97.1%、96.5%、97.4% 和 96.6%。
我們在四種目標裝置上測量了 LFM2.5-230M、LFM2.5-350M、LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B 這四個模型的解碼吞吐量，這些裝置包括 MacBook Pro、NucBox EVO-X2、Samsung Galaxy S26 Ultra 和 Raspberry Pi 5。
其中 MacBook Pro 和 NucBox 使用 GPU 推論，而 Samsung 和 Raspberry Pi 則使用 Arm CPU 推論。BF16 和 F16 作為已分析的全精度參考。
230M 和 350M 的 QAD Q4_0 檢查點在評估誤差範圍內，達到了 Q5_K_M 的品質，同時解碼吞吐量提高了 4-33%。而 1.2B 和 2.6B 的 QAD Q4_0 檢查點則達到了 Q4_K_M 的品質，吞吐量提高了 3-14%。
此外，QAD Q4_0 檢查點在適用情況下（針對 230M 和 1.2B 模型）也與 Unsloth 強大的外部訓練後量化檢查點 UD-Q4_K_XL 表現相當。
您可以使用 llama.cpp 或任何支援 GGUF Q4_0 檔案的執行環境來使用這些檔案。例如，透過以下指令：llama-cli -hf LiquidAI/LFM2.5-350M --hf-file LFM2.5-350M-QAD-Q4_0.gguf -p "What is C. elegans?"
QAD GGUF 檔案現已在 Hugging Face 上提供，包括 LFM2.5-230M、LFM2.5-350M、LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B。我們期待看到您將用它們創造出什麼。
如需引用，請使用以下參考資料或 BibTeX：Liquid AI, "LFM2.5 Q4_0: Quantization-Aware Distillation for Edge Deployment", Liquid AI Blog, Aug 2026。或者使用 BibTeX 引用格式。
