2026 年 8 月 5 日,Liquid AI 发布了 LFM2.5-2.6B。它不是又一个「小模型也能聊天」的玩具,而是专门为智能体工作流设计的端侧模型——26 亿参数,完全在手机等终端本地运行,不依赖任何云端 API。
最值得注意的一组数字:在指令遵循和工具使用基准上,它的表现可媲美规模近四倍的大模型;推理速度在 M5 Max 芯片上达到 220 token/秒,在手机上也能维持 30 token/秒。对端侧 Agent 来说,30 token/秒基本跨过了「能用」的门槛。
为什么端侧 Agent 值得单独做一套模型?
过去做本地小模型,思路是「把大模型能力压缩一点」。LFM2.5 换了思路——后训练阶段直接对着 Agent 场景优化。它的训练流程分四步:
| 阶段 | 做了什么 | 解决什么问题 |
|---|---|---|
| 监督微调 | 基础指令对齐 | 听得懂人话 |
| 教师特化 | 大模型蒸馏 | 把大模型的判断力压进小身体 |
| 多领域在策略蒸馏 | 跨领域策略学习 | 换个场景不失灵 |
| 智能体强化学习 | 面向 Agent 任务做 RL | 规划、工具调用、多步任务 |
基础盘也不含糊:约 34 万亿词元预训练,词表扩展到 128K。词表大对中文和多语言场景尤其友好——同样一句中文,词表大意味着切出来的 token 更少,实际吞吐比标称数字还好看一点。
先说清楚它不是什么:2.6B 的模型不会替代云端旗舰做复杂推理和长程规划。它的战场是「高频、简单、要快、要私密」的那一类 Agent 任务——本地文件整理、离线问答、设备控制、表单填写、隐私数据预处理。任务定义清楚才是它的主场。
Step 1:选对量化版本
模型已在 Hugging Face 全面开源(含基础版本),原生支持 llama.cpp、MLX、vLLM 三大主流推理框架。GGUF 量化版本按需选:
| 量化版本 | 体积 | 适用场景 | 速度 |
|---|---|---|---|
| Q4_0 | 约 1.4GB | 最低配设备 / 老手机 | 最快 |
| Q4_K_M | 约 1.5GB | 平衡推荐 | 快 |
| Q5_K_M | 约 1.7GB | 质量优先 | 中等 |
| Q6_K | 约 2.0GB | 高质量需求 | 较慢 |
| F16 | 约 4.8GB | 研究 / 做对比基线 | 最慢 |
Step 2:用 llama.cpp 跑起来
# 1. 拉取并编译 llama.cpp
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j
# 2. 下载 GGUF 权重(以 Q4_K_M 为例)
wget https://huggingface.co/LiquidAI/LFM2.5-2.6B-GGUF/resolve/main/LFM2.5-2.6B-Q4_K_M.gguf
# 3. 起一个交互式会话验证
./main -m LFM2.5-2.6B-Q4_K_M.gguf \
-p "你好,介绍一下你自己" \
--color -c 8192 -n 512 --temp 0.7
关键参数怎么调:
| 参数 | Agent 场景推荐值 | 说明 |
|---|---|---|
| -c 上下文长度 | 8192 起 | 多步任务要装得下历史 |
| --temp 温度 | 0.1 - 0.3 | 工具调用要低温,别用聊天的 0.7 |
| --top-p | 0.9 | 控制多样性 |
| -n 最大生成 | 512 | 单步产出别放太开 |
| --repeat-penalty | 1.1 | 减少小模型常见的复读 |
温度是最容易搞错的一项。大量教程默认给 0.7,那是给创意写作用的。跑 Agent 时把温度压到 0.1-0.3,工具调用的 JSON 格式正确率会有肉眼可见的提升。
Step 3:Mac 用户走 MLX 通道
如果你用的是 M 系列 Mac,MLX 是苹果自家的机器学习框架,对统一内存架构优化更到位——官方给出的 M5 Max 220 token/秒就是这条路径的成绩。
# 安装 MLX
pip install mlx-lm
# 直接从 Hugging Face 拉起来跑
mlx_lm.generate \
--model LiquidAI/LFM2.5-2.6B \
--prompt "列出当前目录下所有大于 10MB 的文件" \
--temp 0.2 \
--max-tokens 512
# 起一个 OpenAI 兼容的本地服务
mlx_lm.server --model LiquidAI/LFM2.5-2.6B --port 8080
Step 4:验证工具调用能力(最关键的一步)
端侧 Agent 成不成,就看工具调用稳不稳。用最小代码验一遍:
from openai import OpenAI
# 指向本地服务
client = OpenAI(base_url="http://localhost:8080/v1", api_key="local")
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名"}
},
"required": ["city"]
}
}
}]
resp = client.chat.completions.create(
model="lfm2.5-2.6b",
messages=[{"role": "user", "content": "北京今天天气怎么样?"}],
tools=tools,
temperature=0.2,
)
print(resp.choices[0].message.tool_calls)
Step 5:接进 Agent 框架
因为暴露的是 OpenAI 兼容接口,接入几乎是零成本的:
# 通用环境变量方式(大多数框架都吃这套)
export OPENAI_API_BASE=http://localhost:8080/v1
export OPENAI_API_KEY=local
export OPENAI_MODEL=lfm2.5-2.6b
# 接 Ollama 生态也可以
ollama pull liquidai/lfm2.5-2.6b
ollama run lfm2.5-2.6b
# 接 goose(见本站教程 236)
export GOOSE_PROVIDER=ollama
export GOOSE_MODEL=lfm2.5-2.6b
混合架构才是正解。成熟做法不是「全部用小模型」,而是分层路由:高频简单任务走本地 LFM2.5,复杂规划和长程推理再打到云端旗舰。既省钱又保隐私,用户还感知不到延迟。
Step 6:手机端部署要注意什么
硬件门槛(参考同体量 GGUF 实测):
· 内存 最低 4GB,推荐 8GB 以上
· 存储 预留 5GB 可用空间
· CPU 四核起步,八核体验更好
· 系统 iOS / Android / Linux / Windows / macOS 均可
手机端落地路径:
· iOS → MLX Swift 或 llama.cpp 的 iOS 封装
· Android → llama.cpp JNI 绑定 / MediaPipe
· 边缘盒子 → 直接跑 llama.cpp server
三个真实约束别忽略:① 发热与降频——手机持续推理几分钟后会掉速,长任务要分段;② 电量——端侧推理是耗电大户,后台常驻要谨慎;③ 首次加载——模型载入内存需要几十秒,做好预热和加载态提示。
什么场景该用它,什么场景别用
| 场景 | 建议 | 理由 |
|---|---|---|
| 本地文件整理 / 重命名 | ✅ 强烈推荐 | 高频、简单、涉隐私 |
| 离线环境问答助手 | ✅ 推荐 | 无网可用是刚需 |
| 设备控制 / IoT 指令解析 | ✅ 推荐 | 低延迟要求高 |
| 医疗、法务等敏感数据预处理 | ✅ 推荐 | 数据不出域 |
| 复杂多步骤项目交付 | ❌ 别硬上 | 长程规划仍需大模型 |
| 需要最新联网知识 | ❌ 需搭配检索 | 端侧模型知识固化 |