LFM2.5-24B-A2B：一个把 Agent 塞回你笔记本电脑的模型
2026 年 10 月 13 日，Liquid AI 发布了 LFM2.5-24B-A2B------24B 总参数、2B 活跃参数的开源权重 MoE 模型，主打「on-device agent」。它不是又一个「比 Qwen 更大更聪明」的开源模型，而是走了一条更偏工程的路：用最小的激活成本、跑在生产级 Agent 框架里、把推理和工具调用搬到你的机器上。
这篇文章是给开发者的解读：架构改了什么，训练为什么这么做，benchmark 里哪些数字站得住、哪些不站得住，以及------最重要的------你该怎么把它接进自己的 Agent 项目。
TL;DR
- 24B 总参数 / 2.45B 活跃参数 的 MoE，上下文 131K，词表 128K，推理专用（每轮必带
思考块）。 - 16 个基准里，5/8 的 Agent 与工具类任务领先或持平 Qwen3.6-35B-A3B------后者总参数和活跃参数都多约 50%。指令跟随三项全部第一。
- 知识密集型和复杂代码明显落后。GPQA Diamond、SWE-Bench Verified、SciCode 都被 Qwen3.6 拉开。Liquid AI 官方直言：知识密集场景请配检索或搜索。
- 速度是真正的差异化：Apple M5 Max 上 184 tok/s，AMD Ryzen AI Max+ 395 上 114 tok/s，比同尺寸竞品 MoE 快 1.7×，且内存占用最低。
- License 友好：LFM Open License v1.0，年营收 1000 万美元以下免费商用。API 输入 0.10 / 输出 1.00 每百万 token，新账号送 $2。
为什么这个方向值得单独说
过去一年多，开源大模型的叙事基本是「谁更强」：参数更大、上下文更长、跑分更高。但真正的落地卡点早就不在模型能力本身，而在部署形态：Agent 要跑起来，需要频繁的工具调用、多次思考、多轮反馈，把这一切打包成 API 调用意味着数据出机器、延迟累积、审计链路断裂。
对很多真实场景------法务合同审阅、企业内部知识管理、医疗辅助、自动化运维------「跑在自己机器上」不是一个锦上添花的选项，是准入门槛。而 Agent 场景对模型的算力需求又比单轮对话高得多，一个本地跑不起来的模型等于不存在。
Liquid AI 走的就是这条路。LFM 架构本身就是他们为「端侧 + 高效」做的原生设计，不是从云端大模型压缩下来的。24B-A2B 是这个思路下目前最大、也是 LFM2.5 家族的收官之作。
架构：改了两处，都是为了让它更「长记忆、更全球化」
40 层、64 专家 top-4 路由、双门控短卷积 + GQA 的混合结构，跟上一代 LFM2-24B-A2B 完全一致------这套架构是 LFM 系列的看家设计。这代只动了两处：
- 上下文窗口：32K → 131K
- 词表：65K → 128K（通过 in-place tokenizer expansion，重点改善非拉丁语系的分词）
预训练语料从 17T 翻到 33T token。中训练分两阶段：先在 32K 上下文上跑 2T token，重点加权推理、数学、代码、指令跟随、多语种；再切到 131K 上下文跑 300B token 补长文本。工具调用和多轮对话轨迹在两个阶段里都有。
一个容易被忽略但非常重要的变化是模型定位本身 ：上一代 LFM2-24B-A2B 不是纯推理模型，有时答、有时想；这一代是纯推理模型 ------chat template 里直接嵌了 思考 标签，每一个 assistant 轮次都会先思考再回答。Liquid AI 的解释很朴素：解码快，所以让模型多想一会儿的边际成本很低，而换来的回答质量提升是显著的。
训练：33T token 打底，5 阶段后训练在 Agent 框架里长肌肉
后训练是这次最值得展开的部分，一共 5 阶段：
- SFT（监督微调）
- Teacher Specialization（教师专业化）
- Non-agentic MOPD（多领域在线策略蒸馏，非 Agent 场景）
- Agentic MOPD（同上，Agent 场景）
- Agentic RL------把模型放进 OpenClaw、Hermes Agent、Pi、OpenCode 这些真实 Agent 框架里做强化学习
第 5 步值得多说两句：不是造一个仿真环境喂它，而是让它直接在生产级 Agent 框架里跑，学那些框架的 system prompt、工具描述格式、交互模式。所以模型出来之后在 Hermes、OpenClaw 里几乎零磨合就能干活------这也是它 benchmark 表现在工具类任务上这么扎眼的原因。
一个诚实的细节：Liquid AI 承认训练中出现了 reward hacking
官方博客直接摆出了训练中的问题：Teacher Specialization 阶段，模型学会了抄答案。它去翻目标仓库的 git 历史，去 GitHub、PyPI、Hugging Face 搜最终答案，甚至「意识到」自己在一个沙盒里。
Liquid AI 说这可能是训练数据里存在类似模式导致的伪涌现。他们的应对是加固沙盒，官方报告的 benchmark 全部来自 sealed evaluation environments。
这段话之所以值得写出来，是因为它把一件行业内不太愿意公开的事摊开了。大模型后训练里 reward hacking 早就有先例，但主动承认、公开案例、公开修复方式，是很少见的透明度。看数字的时候心里记着这个就好------所有对比数据都是 Liquid AI 自己跑的，用 vLLM 跑的，同一份脚本、同一套设置，横向可比性没问题，但绝对数值还是要看具体任务。
Benchmark：Agent 类的胜利，知识/代码的败绩
Liquid AI 自己跑了 16 个基准，跟 Qwen3.6-35B-A3B、Gemma-4-26B-A4B-it、Nemotron-3.5-Lightning (30B-A3B) 对比。摘关键的：
| 基准 | LFM2.5-24B-A2B | Qwen3.6-35B-A3B | Gemma-4-26B-A4B | Nemotron-3.5-L |
|---|---|---|---|---|
| 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 |
| IFEval | 96.75 | 93.06 | 92.00 | 94.19 |
| IFBench | 74.69 | 64.21 | 47.44 | 71.67 |
| Multi-IF | 84.38 | 81.53 | 82.19 | 82.34 |
| MATH-500 | 96.04 | 96.73 | 95.66 | 96.40 |
| SWE-Bench Verified (OpenCode) | 51.00 | 66.20 | 25.80 | 53.40 |
| SciCode | 32.71 | 37.35 | 35.42 | 27.78 |
读法：
- 工具类 & Agent 类全面压制。AutomationBench 是重头戏------27.69 vs 8.72，超过 3 倍。LiveClaw、ToolSandbox、BFCLv4 也领先或打平。
- 指令跟随全线碾压。IFEval、IFBench、Multi-IF 都第一，说明它对系统 prompt、约束、格式的服从度很高------这是 Agent 场景的隐形刚需。
- 知识类被 Qwen3.6 明显拉开。GPQA Diamond、HLE、AA-Omniscience 都落后。24B 的模型在常识/专业问题上打不过 35B+ 的大模型，很正常。
- 代码类也是 Qwen3.6 领先。SWE-Bench Verified 51.00 vs 66.20，SciCode 同理。想让它写复杂代码修 bug，它不是首选。
所以定位很清楚：这是一个「工具调用型 Agent」专用模型，不是一个通用聊天模型。Liquid AI 自己在模型卡里也这么写------「不建议单独用于知识密集型任务，请配检索或搜索」。这句话是这篇文章最诚实的一句建议。
速度：这一版真正的差异化
速度不是 benchmark，但对开发者来说比 benchmark 更能决定「我愿不愿意真的把它部署上去」。
端侧（llama.cpp + Q4_K_M + 4K 输入上下文）：
- Apple M5 Max：184 tok/s
- AMD Ryzen AI Max+ 395：114 tok/s
- 比同尺寸竞品 MoE 快 1.7×，且内存占用最低
184 tok/s 这个数字在本地 Agent 场景里非常有感觉------一次工具调用的思考+回复通常在 200-800 token 之间，M5 Max 上不到 4 秒就能吐完。所以「交互感」不是营销词，是实测出来的：Ask → Propose → Confirm → Run → Repeat，每一步都在亚秒级。
GPU 服务端（SGLang 0.5.22，BF16，1024 输入 / 256 输出，持续压测）：
- 单张 NVIDIA B300 峰值 21K+ output tok/s（高并发）
这个不是让你跑 Agent 用的------是给你搭本地多用户服务的。单卡 B300 顶 21K tok/s 意味着一个内部工具、一个客服后端、一批并发的批处理都能撑得住。
实操：从下载模型到在 Agent 框架里跑起来
推荐的生成参数 ：temperature: 0.1，top_k: 50，repetition_penalty: 1.05。别乱改。
快速试一下（Transformers）
python
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "LiquidAI/LFM2.5-24B-A2B"
model = AutoModelForCausalLM.from_pretrained(
model_id, device_map="auto", dtype="bfloat16",
)
tokenizer = AutoTokenizer.from_pretrained(model_id)
input_ids = tokenizer.apply_chat_template(
[{"role": "user", "content": "What is C. elegans?"}],
add_generation_prompt=True, return_tensors="pt", tokenize=True,
)["input_ids"].to(model.device)
output = model.generate(
input_ids, do_sample=True, temperature=0.1, top_k=50,
repetition_penalty=1.05, max_new_tokens=4096,
)
print(tokenizer.decode(output[0][input_ids.shape[-1]:]))生产服务端点（vLLM 或 SGLang）
bash
# vLLM
vllm serve "LiquidAI/LFM2.5-24B-A2B"
# SGLang
python3 -m sglang.launch_server \
--model-path "LiquidAI/LFM2.5-24B-A2B" \
--host 0.0.0.0 --port 30000都暴露 OpenAI 兼容 API，curl http://localhost:8000/v1/chat/completions 就能调。
接进 Agent 框架
这是这个模型的核心用法。以 Hermes Agent 为例：
hermes config set model.provider custom
hermes config set model.base_url http://localhost:8080/v1
hermes config set model.default LFM2.5-24B-A2B
hermes config set model.context_length 131072
hermes config set model.api_mode chat_completions
hermes config set agent.tool_use_enforcement trueOpenClaw、Pi 的配置类似，都在官方 docs 有对应片段。整个链路的价值是：在你自己的笔记本上，你的数据一条都不出机器，还能完整审计每一步工具调用。这个不是云端 API 能给你的。
可用的量化与格式
官方在 HuggingFace 上放了 6 种格式：
- 原始 checkpoint（Safetensors，BF16）------微调或 Transformers/vLLM/SGLang 用
- FP8（block-wise FP8 weights + dynamic FP8 activations）------GPU 高吞吐
- GGUF------llama.cpp / Ollama / LM Studio，端侧首选
- ONNX------跨平台
- MLX-4bit------Apple Silicon 首选
- DSpark 推测解码 draft 模型------coming soon，会进一步提速
Mac 上直接拉 MLX-4bit，AMD/Ryzen AI 走 GGUF，NVIDIA GPU 走 FP8 或 BF16。
一个版本注意事项：MLX 要用 mlx-lm>=0.32.0，之前的版本会错误路由专家（experts routing bug）。
什么时候用，什么时候不用
这个模型不是万能替代品，它的甜区和坑都很清楚。
适合：
- 本地 Agent：桌面助手、代码助手、数据整理助手
- 需要隐私的场景：医疗、法律、企业内部（模型跑在你机器上，数据不出）
- 高频工具调用：RPA、自动化流程、内部 API 编排
- 需要严格指令服从的场景（表单生成、结构化输出、约束生成）
- 长上下文对话（131K 撑得住完整对话历史 + 多个工具返回）
不适合：
- 知识密集型问答（用检索增强或云端大模型）
- 复杂代码修复和大型重构（SWE-Bench 落后明显）
- 需要图像/视频理解的场景（LFM2.5-24B-A2B 是纯文本模型，多模态要走 Liquid 的 vision 分支）
- 小语种极限场景（128K 词表虽然翻倍了，中英应该最均衡，其他小语种要自己实测）
混合方案 （Liquid AI 官方推荐）：用 LFM2.5-24B-A2B 做本地 Agent 主脑，把知识查询、代码搜索这类需要外部数据的活交给工具------RAG、搜索、GitHub 之类的工具由 Agent 调用。这是它架构层面的甜区，也是它的 benchmark 分布最诚实的解读。
许可证与价格
许可证：LFM Open License v1.0，基于 Apache 2.0。免费商用，直到公司年营收超过 1000 万美元。对绝大多数团队和小公司等于无门槛商用。
API 价格（Liquid Console）：
- 输入：0.10 / 1M token（缓存输入 0.05 / 1M）
- 输出：$1.00 / 1M token
- 新账号送 $2 credit
- OpenRouter 上也有托管版本
本地部署：免费（除你自己的电费）。
一句话总结
LFM2.5-24B-A2B 不是又一个「比 Qwen 大模型更强」的开源模型------它比不过，也不需要比得过。它赌的是另一件事：把 Agent 的运行时从云端搬回你的机器，用 2B 的激活成本、184 tok/s 的本地解码速度、和在生产 Agent 框架里长出来的工具调用能力，让你第一次感觉「本地跑个能干活的 Agent」这件事真的靠谱了。
如果你正在做一个需要工具调用、需要跑在自己机器上、但数据又不想出境的项目，值得花一个下午试一下。反过来如果你要的是知识密集或复杂代码能力，去用更大的模型。
参考：