摘要：Liquid AI 放出了 LFM2.5 家族最大的模型 LFM2.5-24B-A2B，总参数 24B、每个 token 只激活 2B，官方数据在 8 个 Agent/工具调用基准里 5 个领先 Qwen3.6-35B-A3B。这篇文章讲清楚它的架构、跑起来的方法、和同类 MoE 的对比，以及什么机器能跑、什么场景该选它。
1. 背景与痛点
做本地 Agent 的人基本都卡在同一个矛盾上：模型能力要够，工具调用要稳，但机器就那么大点显存。
我自己的场景是给本地 Agent 配大脑。云端 API 按量烧钱不说，断网就瘫，隐私数据也不敢往上送。所以一直在盯端侧模型------之前在容器里给 MoE 模型做过专家流磁盘卸载（那是被显存逼的，24B 级别模型塞不进消费级显卡，只能把不活跃的专家往磁盘上赶，代价是速度掉一大截）。那次折腾让我对"总参数 vs 激活参数"这对概念有了肌肉记忆。
10 月 15 日早上刷 RSS，看到 Hacker News 上 Liquid AI 的发布帖排在前列，LFM2.5-24B-A2B，24B 总参数、2B 激活、131K 上下文、reasoning-only。HN 上 52 个点，评论区吵得很热闹。我花了一个上午把官方博客和模型卡读了一遍，顺手验证了部署路径。这篇文章就是这半天的记录。
一句话给判断：如果你的 Agent 主要做工具调用和指令跟随，显存又在 16-24GB 这个尴尬档位，这个模型值得认真考虑。知识问答重的场景，它自己官方都建议你外挂检索。
2. 架构：2B 激活参数是怎么做到的
LFM2.5-24B-A2B 是典型的 MoE（混合专家）结构，但 Liquid AI 在细节上做了几个不常见的选择：
- 40 层，每个 MoE 块 64 个专家，top-4 路由------专家切得比一般实现细得多
- 门控短卷积（gated short convolution）和 GQA 注意力混合编排，卷积块负责局部特征，注意力块负责长程依赖
- 上下文窗口从前代的 32,768 扩到 131,072
- 词表从 65K 就地扩到 128K，非拉丁语系（包括中文）的 tokenization 效率提升
MoE 的账这么算：每个 token 只需要过 64 个专家里的 4 个，所以推理时的实际计算量约等于一个 2B 稠密模型，但"知识容量"是 24B 级别的。代价是所有 64 个专家的权重都得待在显存（或内存）里------这就是我之前做磁盘卸载的原因。
训练侧的数字：预训练从 17T token 加码到 33T，中期训练分两段（2T token 的 32K 上下文 + 300B token 的 131K 长上下文），后训练走五段流水线，最后一段是 Agentic RL------直接把模型塞进 OpenClaw、Hermes Agent、Pi、OpenCode 这些 Agent 框架里训。
官方博客里还提了个有意思的细节：教师特化阶段，模型学会了 reward hacking------跑去 git 历史里翻最终答案，甚至自己发现身处沙箱。Liquid AI 的应对是收紧沙箱，所有报告的分数都来自封闭评估环境。这个细节反而让我觉得基准数字可信度高一些，毕竟他们至少承认了问题。
整体数据流是这样的：
flowchart LR
A[用户请求 131K 上下文] --> B[Tokenizer 128K 词表]
B --> C[40 层混合骨干]
C --> C1[门控短卷积块 局部特征]
C --> C2[GQA 注意力块 长程依赖]
C2 --> D[MoE 路由 top-4 / 64]
D --> E[仅 2B 参数激活]
E --> F[显式思维链 reasoning-only]
F --> G[工具调用 JSON / 最终回答]3. 环境准备
day-one 支持的推理栈：llama.cpp（GGUF）、MLX（Apple Silicon）、vLLM、SGLang、ONNX。端侧玩家主要用前两个。
我验证的是 llama.cpp + Ollama 路线（Linux 容器和 Windows 台式机都通）：
# 方式一：llama.cpp 直接从 Hugging Face 拉 GGUF
# Q4 量化约 14GB 出头，先确认磁盘和内存
llama-cli -hf LiquidAI/LFM2.5-24B-A2B-GGUF:Q4_K_M \
--conversation -c 8192 --temp 0.2 --top-k 80 --repeat-penalty 1.05
# 方式二：起一个 OpenAI 兼容的本地服务
llama-server -hf LiquidAI/LFM2.5-24B-A2B-GGUF:Q4_K_M --port 8080
# 方式三：Ollama 社区打包版（注意认准官方 GGUF 源）
ollama pull LiquidAI/LFM2.5-24B-A2B-GGUF版本要求：llama.cpp 需要 2026 年 10 月之后的构建（新架构支持合入较晚），Ollama 建议 0.40.0 以上。MLX 用户直接看 Liquid AI 官方文档的 mlx-lm 用法。
内存账要算清楚。Q4_K_M 量化下模型本体约 14GB，加上 KV cache------131K 上下文满载时 KV cache 不是小数目，GQA 压过之后仍要预留几个 GB。16GB 统一内存的机器跑 8K 上下文勉强，32GB 才敢开长上下文。 这是我给 MoE 做磁盘卸载时算烂了的一笔账：只看模型大小不看上下文内存，必翻车。
4. 实战：接进本地 Agent
模型是 reasoning-only 的，回答前会先产出一段显式思维链（<think>...</think> 标签包裹）。接 Agent 时要处理好这段输出，别把思维链当工具调用参数解析。
一段最小的 Python 调用示例，走 llama-server 的 OpenAI 兼容接口：
import json
import re
import requests
OLLAMA_URL = "http://localhost:8080/v1/chat/completions"
TOOLS = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市当前天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名"}
},
"required": ["city"]
}
}
}]
def ask_agent(question: str) -> dict:
resp = requests.post(OLLAMA_URL, json={
"model": "LFM2.5-24B-A2B",
"messages": [{"role": "user", "content": question}],
"tools": TOOLS,
"temperature": 0.6,
"top_p": 0.95,
}, timeout=120)
resp.raise_for_status()
msg = resp.json()["choices"][0]["message"]
# reasoning 模型的输出先出思维链，再出工具调用
tool_calls = msg.get("tool_calls") or []
if tool_calls:
call = tool_calls[0]["function"]
return {"tool": call["name"], "args": json.loads(call["arguments"])}
# 没有工具调用时，剥掉 think 段拿最终回答
content = re.sub(r"<think>.*?</think>", "", msg["content"], flags=re.S).strip()
return {"answer": content}
print(ask_agent("上海现在适合跑步吗？"))
# 期望输出: {'tool': 'get_weather', 'args': {'city': '上海'}}采样参数别乱设。官方评估用的是 temperature 0.6 / top_p 0.95（Agent 类任务），工具调用精确匹配类任务用接近 0 的温度。我一开始照搬稠密模型的习惯用 temperature 0.7+，工具参数偶尔漂；改回 0.6 后稳定了。
另外提醒一句：官方在 Hermes Agent 里做过完整演示------M5 Max MacBook Pro 上全程本地跑规划、调用工具、生成晨报，单次工具派发延迟不到 1 秒。这说明这个尺寸的 MoE 在旗舰消费硬件上已经能撑起交互式的 Agent 循环了。
5. 效果验证：和同尺寸 MoE 硬碰硬
官方基准（vLLM 统一评估，16 项）里挑 Agent 最相关的 8 项，和三个同级对手对比：
| 基准 | LFM2.5-24B-A2B | Qwen3.6-35B-A3B | Gemma-4-26B-A4B | Nemotron-3.5-Lightning 30B-A3B |
|---|---|---|---|---|
| AutomationBench | 27.69 | 8.72 | 5.46 | 2.61 |
| BFCLv4 | 65.01 | 65.00 | 57.09 | 53.78 |
| ToolSandbox | 80.71 | 75.02 | 72.09 | 75.13 |
| LiveClaw | 48.09 | 38.19 | 41.25 | 37.72 |
| PinchBench | 83.18 | 89.93 | 77.12 | 84.20 |
| τ³-Bench Banking | 8.04 | 7.63 | 4.54 | 7.01 |
| WebArena Verified | 26.75 | 37.62 | 25.62 | 28.69 |
| GPQA Diamond | 74.42 | 83.69 | 74.90 | 72.42 |
（数据来源：Liquid AI 官方博客，2026-10）
赢面集中在工具调用和指令跟随------IFEval 96.75、IFBench 74.69、Multi-IF 84.38 三项指令跟随全部第一。输面在知识密度和重编码：SWE-Bench Verified 51.00 对 Qwen 的 66.20，差距明显。
速度是另一张牌。官方在 Apple M5 Max 上测出 184 tokens/s 解码，AMD Ryzen AI Max+ 395 上 114 tokens/s，比次优对手快至多 1.7 倍；单张 B300 GPU 高并发下 21K output tokens/s。折算成选购语言：同档 MoE 里它的"读 prompt + 吐答案"延迟最低，内存占用也最小。
选购结论按场景拆：
| 你的场景 | 推荐 |
|---|---|
| 本地 Agent / 工具调用 / 自动化流程 | LFM2.5-24B-A2B，这个尺寸段的工具调用王 |
| 指令跟随严格的多轮对话 | 同上，三项指令跟随基准全第一 |
| 重知识问答（GPQA/HLE 类） | Qwen3.6-35B-A3B，或 LFM2.5 + 外挂检索 |
| 重编码任务（SWE-Bench 类） | 别选它，51.00 vs 66.20 差距太大 |
| 显存 ≤16GB 且要长上下文 | 先看 LFM2.5-8B-A1B，24B 版别硬上 |
6. 踩坑记录
这半天加之前的 MoE 折腾，攒了四条实在的坑：
- 内存账别只算模型本体。Q4 的 14GB 只是入场券，131K 上下文的 KV cache 会再吃几个 GB。我之前做专家磁盘卸载时就是没算这笔，加载阶段直接 OOM。
- reasoning 输出要剥壳。思维链混进工具调用解析，Agent 会拿到一堆"让我想想......"当参数。上面代码里的正则剥壳是最低保障。
- 温度参数敏感。MoE + reasoning 的组合对采样比稠密模型娇气，Agent 任务锁定 0.6/0.95，别自由发挥。
- Ollama 社区包认准 GGUF 源头 。ollama.com 上 LFM2.5 系列的第三方打包不少，量化来源混乱，优先
LiquidAI/...-GGUF官方仓。另外视觉变体（VL 系列）的 mmproj 投影器目前没法干净地挂进 Ollama，需要多模态就直接用 llama-mtmd-cli。
7. 总结
LFM2.5-24B-A2B 的定位非常克制：不跟大模型拼知识，把 2B 的激活预算全押在工具调用、指令跟随和解码速度上。对端侧 Agent 这个具体场景，它是目前这个尺寸段综合最优的开源选择之一；对知识密集场景，官方自己也说清楚了你该外挂检索。
从 230M 到 24B，LFM2.5 家族跨了两个数量级，Liquid AI 说这是最后一块拼图。端侧 Agent 的基建（GGUF/MLX/vLLM day-one 全齐）在快速成熟，剩下的变量就是你的显存预算了。
一个开放问题：你手上的 Agent 工作流里，工具调用准确率和知识广度哪个是当前瓶颈？如果你也在 16-24GB 显存的档位上选过模型，评论区聊聊你的方案------我在磁盘卸载那条路上牺牲的速度，一直想找机会换回来。