2026 年 5 月 28 日，Liquid AI 發布 LFM2.5-8B-A1B 與 Base 版本：總參數 8B、每 token 啟用約 1B 的稀疏 MoE 模型，接替 LFM2-8B-A1B。定位是跑在手機、筆電與邊緣裝置上的「裝置內個人助理」，主打工具呼叫與 agentic 工作流程，回答前會先生成明確思考鏈。
這次改版的重點不是模型變大，而是訓練量暴增：預訓練從 12T tokens 拉到 38T，上下文從 32,768 擴到 128K。本地模型與雲端的差距正以另一種方式縮小——不靠堆參數，而靠資料與訓練分工。
從 12T 到 38T：三階段訓練管線
訓練分三個階段：第一階段是 38T tokens 的預訓練；第二階段是 2T tokens 的中期訓練，聚焦推理、數學、工具使用與長文件，先把上下文推到 32K；第三階段再加 400B tokens，並提高 RoPE base θ，把上下文擴到 128K。詞表也從 65,536 擴到 128K BPE tokens，並採原地擴充。
強化學習有兩個設計值得注意：一是針對「doom loops」（模型原地打轉）做偏好最佳化；二是 avg@k 獎勵——同一題抽樣多次，以答案一致性計獎，壓低幻覺。
基準分數：工具呼叫與推理的大幅躍進
與前代 LFM2-8B-A1B 相比（舊 → 新）：
- IFEval：79.44 → 91.84
- MATH500：74.80 → 88.76；AIME25：20.00 → 42.53，AIME26 達 50.00
- BFCLv3：45.07 → 64.36；BFCLv4：25.52 → 48.50
- Tau² Telecom：13.60 → 88.07；Tau² Retail：7.02 → 39.82
- 非幻覺率（Non-Hallucination Rate）：7.46 → 63.47
工具呼叫相關的 BFCL 與 Tau² 漲幅最大，與裝置內代理的定位一致。詞表擴充讓 16 種語言的 tokenizer 效率明顯改善：泰文 +238.2%、印地文 +120.4%、越南文 +117.9%、阿拉伯文 +38.8%。
「只推理」的設計取捨
LFM2.5-8B-A1B 是「reasoning-only」模型：回答前先生成明確的思考鏈。好處是數學與多步驟任務直接受惠，幻覺率也壓得下去；代價是延遲與 token 消耗增加。在端側場景這是大膽選擇——手機使用者對速度最敏感——但 Liquid AI 顯然認為回答品質值得這個代價。
效能數字：CPU 上的每秒 253 tokens
官方推理數字：Apple M5 Max 的 CPU 上每秒 253 tokens；AMD Ryzen AI Max+ 395 上每秒 146 tokens、記憶體佔用低於 6GB；手機上約每秒 30 tokens。GPU 側，單張 H100 SXM5 在高併發下每秒輸出 18.5K tokens，一天超過 16 億 tokens。
架構維持混合設計：稀疏 MoE 加上 GQA 與 gated short convolution 區塊；Hugging Face 模型卡標示 24 層（18 層 convolution、6 層 GQA）、總參數 8.3B、每 token 啟用 1.5B。
授權的細節值得注意
權重已上架 Hugging Face（LiquidAI/LFM2.5-8B-A1B），提供 GGUF、ONNX 與 MLX 格式，官方說法是「下載、微調、部署，沒有限制」。但模型卡標示的授權是 Liquid 自訂的 LFM 1.0 條款，而非 Apache 2.0——放進商業產品前值得先讀一遍。
對端側 AI 開發者的意義
三點觀察。第一，128K 上下文進入手機級模型：長文件、多輪對話與本地 RAG 變得實際可行。第二，工具呼叫能力（BFCLv4 達 48.50）已足以認真考慮「本地代理」，且 llama.cpp、vLLM、SGLang 等主流框架第一天就支援。第三，約 1B 啟用的 MoE 證明「啟用量」比「總參數」更決定端側體驗——對硬體選型與續航都是好消息。
參考來源
- LFM2.5-8B-A1B: An Even Better On-Device Mixture-of-Experts — Liquid AI
- LiquidAI/LFM2.5-8B-A1B — Hugging Face
本文由 AI 協助自上述來源整理，經人工審核後發布。