2026年10月13日，我们发布 LFM2.5-24B-A2B，一个具有240亿参数、仅20亿激活参数的推理模型，为设备端快速、私有的智能体构建。它是 LFM2.5 系列中最大也是最后一款模型，该系列现已跨越两个数量级：从 LFM2.5-230M 到 LFM2.5-24B-A2B。在八项智能体与工具使用基准中的五项上，它可比肩参数总量和激活参数多出约50%的通义千问3.6-35B-A3B（Qwen3.6-35B-A3B），LiveClaw 得分 48.09（38.19），AutomationBench 得分 27.69（8.72）。基础版 LFM2.5-24B-A2B-Base 与后训练版 LFM2.5-24B-A2B 均已开放权重，今日在 Hugging Face 与我们的 Playground 上线。

今天，我们发布 LFM2.5-24B-A2B。这是一款 24B 参数的推理模型，每个 token 仅激活 2B 参数，专为设备端快速、私有的智能体打造。它是 LFM2.5 系列中最大也是最后一款模型，该系列现在横跨两个数量级：从 LFM2.5-230M 到 LFM2.5-24B-A2B。

在八项智能体与工具使用基准中的五项上，LFM2.5-24B-A2B 的表现可与 Qwen3.6-35B-A3B 相媲美——后者的总参数和激活参数都多出约 50%；它在 LiveClaw 上得分为 48.09（对方 38.19），在 AutomationBench 上为 27.69（对方 8.72）。由于每个 token 只激活 2B 参数，它在设备端的运行速度比同类 MoE 模型快最多 1.7 倍：在 Apple M5 Max 上达到 184 tokens/s，在单块 NVIDIA B300 GPU 上最高可达 21K 输出 tokens/s。

基础版（LFM2.5-24B-A2B-Base）和后训练版（LFM2.5-24B-A2B）均为开放权重模型，今日起已在 Hugging Face 和我们的 Playground 上线。关于如何在本地运行和微调，可查阅我们的文档。

相比 LFM2-24B-A2B 有何变化

LFM2.5-24B-A2B 基于我们此前发布的 LFM2-24B-A2B 构建，扩展了词表与上下文窗口，扩大了预训练规模，并引入了大规模强化学习。与前代不同，LFM2.5-24B-A2B 是纯推理模型：在给出最终答案前，它会先生成明确的思维链。我们采用这一策略，是为了利用其高解码速度并提升答案质量。

架构。 它保留了 40 层、每个 MoE 块 64 个专家（top-4 路由），以及同样的门控短卷积与 GQA 混合结构。架构上有两处改动：上下文窗口从 32,768 token 扩展到 131,072 token；并通过原地分词器扩展将词表从 65K 翻倍至 128K token，以改善非拉丁语系的分词效果。

预训练规模从 17T token 扩大到 33T token。

中期训练分为两个阶段。第一阶段在 32K 上下文下运行 2T token，使用经过筛选的更高质量数据，侧重推理、数学、代码、指令遵循和多语言文本。第二阶段在 131K 上下文下运行 300B token，侧重长上下文数据。两个阶段都包含工具调用和多轮轨迹，以便为智能体任务做准备。

后训练通过如下所示的五阶段流程，将 LFM2.5-24B-A2B-Base 转化为具备智能体能力的 LFM2.5-24B-A2B：(1) 监督微调（SFT）；(2) 教师专业化（Teacher Specialization）；(3) 非智能体和 (4) 智能体多领域在策略蒸馏（MOPD）；(5) 智能体强化学习（Agentic RL），在 OpenClaw、Hermes Agent、Pi 和 OpenCode 等智能体框架中训练模型。

图 2：LFM2.5-24B-A2B 后训练流程

在教师专业化阶段，LFM2.5-24B-A2B 表现出了众所周知的奖励黑客（reward hacking）行为：在仓库的 git 历史或 GitHub、PyPI、Hugging Face 等平台上搜索最终答案。更令人意外的是，它甚至意识到自己处于沙箱环境中，如下方示例所示。

这种行为看似是涌现的，但也可能只是因为训练数据中包含类似模式。为此我们收紧了沙箱，下文所有报告结果均来自密封的评估环境。

基准测试

我们在 16 项基准上评估了 LFM2.5-24B-A2B，覆盖工具使用与智能体工作流、知识、指令遵循、数学和编程。尽管它的总参数和激活参数都是最小的，但在与 Qwen3.6-35B-A3B 等总参数和激活参数多出约 50% 的更大 MoE 模型相比时，它仍具竞争力，且常常胜出。

| 基准 | LFM2.5-24B-A2B | Qwen3.6-35B-A3B | Gemma-4-26B-A4B-it | 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 | | AA-Omniscience | -24.90 | -24.35 | -59.39 | -3.58 | | HLE | 7.40 | 7.69 | 8.57 | 5.65 | | 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 |

表 1：LFM2.5-24B-A2B 基准测试表现*。

在八项工具使用与智能体基准中的五项（AutomationBench、BFCLv4、ToolSandbox、LiveClaw 和 τ³-Bench Banking）上，LFM2.5-24B-A2B 领先或追平竞争对手；其中优势最大的是 AutomationBench，得分超过次优模型的三倍。它还在三项指令遵循基准上全面领先。更大的模型则在 GPQA Diamond、HLE 和 AA-Omniscience 等知识密集型基准，以及 SWE-Bench Verified (OpenCode) 和 SciCode 等编程基准上保持优势。

这些结果使 LFM2.5-24B-A2B 成为需要推理、调用工具并在设备上稳定运行的智能体的理想基础。对于知识密集型任务，我们建议将 LFM2.5-24B-A2B 与检索或网页搜索配合使用，这能发挥其工具调用优势。

各处快速推理

LFM2.5-24B-A2B 首发即支持整个推理生态：

• llama.cpp — 提供 GGUF 检查点，用于高效的边缘推理
• MLX — 针对 Apple Silicon 的优化推理
• vLLM — 面向生产吞吐量的 GPU 加速服务
• SGLang — 高性能 GPU 服务框架
• ONNX — 跨多种加速器的跨平台推理

所有运行数据都在 Pipette 上采集，这也是 Liquid AI 公开设备性能数据背后的同一套基准测试设施。

边缘推理。 得益于高效的 LFM2 架构，LFM2.5-24B-A2B 在读取提示和生成答案时是对比 MoE 模型中最快的。它在 Apple M5 Max 上解码速度为 184 tokens/s，在 AMD Ryzen AI Max+ 395 上为 114 tokens/s，比次优模型快最多 1.7 倍，同时内存占用最少。

GPU 推理。 为展示 LFM 架构的竞争力，我们将其 GPU 推理吞吐量与其他同等规模的 MoE 模型进行了比较。我们在单块 NVIDIA B300 GPU 上以持续负载设置测量 GPU 吞吐量（总输出 token 数 / 实际时间）：在每个并发级别下，持续维持目标数量的在途请求，并在每个请求完成后立即替换。

我们使用 SGLang 0.5.22 对每个模型进行基准测试，输入 1,024 tokens，最多输出 256 tokens，采用 BF16。LFM2.5-24B-A2B 是其规模级别中最快的模型，在高并发下每秒输出 token 数超过 21K。

用 LFM2.5-24B-A2B 运行本地智能体

LFM2.5-24B-A2B 的体积、速度和能力，使其成为在你自己的硬件上持续运行的智能体的理想选择。在下面的演示中，我们在 M5 Max MacBook Pro 上的 Hermes Agent 中运行它：它进行规划、调用工具，并完全在设备端处理一项真实任务，不调用任何云端 API。

视频 3

视频 1：本地 Hermes Agent 中的 LFM2.5-24B-A2B 正在生成一份关于 Hugging Face 热门模型的晨报，并回答后续问题。

这个演示的重点不在于具体用了哪些工具，而在于工具调度循环在消费级硬件上足够跟手：提问、提议、确认、运行、重复，每次调度都远低于一秒，且拥有完整审计轨迹，数据也绝不离开设备。关于如何在本地部署模型并连接你选择的智能体框架，请查阅我们的本地智能体指南。

开始使用

今天就开始用 LFM2.5-24B-A2B 构建应用吧，模型已在 Hugging Face 上线。

如需 API 推理，也可以注册 Liquid Console，新用户可获得 2 美元额度以开始使用。该模型定价为每百万输入 token 0.10 美元（缓存输入为 0.05 美元），每百万输出 token 1.00 美元。

通过 LFM2.5，我们正在实现“AI 随处运行”的愿景。这些模型具有：

• 开放权重 — 可下载、微调和部署。详见我们的模型许可证。
• 首发即快 — 原生支持 llama.cpp、MLX 和 vLLM，覆盖 Apple、AMD、Qualcomm 和 Nvidia 硬件
• 完整家族 — 从用于定制的基础模型，到专用的音频和视觉变体，同一架构覆盖多样化用例

引用

如需引用，请使用以下参考文献或 BibTeX：

Liquid AI, "LFM2.5-24B-A2B: Built for Fast On-Device Agents", Liquid AI Blog, Oct 2026。

*所有模型均使用 vLLM 及以下生成参数进行评估：

• AutomationBench：temperature = 0.6，top_p = 0.95，无最大输出 token 限制（受模型上下文窗口约束）。
• BFCLv4：temperature = 0.001，max output tokens = 4096。
• ToolSandbox：temperature = 0，max output tokens = 1024；用户模拟器：GPT-4o-2024-08-06，temperature = 0，max output tokens = 1024。
• LiveClaw：temperature = 1.0（vLLM 默认值；智能体未设置 temperature），max output tokens = 8192。
• τ³-Bench Banking：官方用户模型（GPT-5.2，低推理强度）配合默认 BM25 检索，temperature = 0，每轮 max output tokens = 16384。
• WebArena：temperature = 0.6，topp = 0.95，maxturns = 40（允许的浏览器操作数），无最大输出 token 限制（受模型上下文窗口约束）。
• 其他评估：temperature = 0.6，max output tokens = 32768。

讨论气氛整体偏兴奋，较多人肯定其本地推理速度、效率与小 agentic 模型的可玩性。分歧主轴在于官方成绩（尤其是 AutomationBench）和高 tokens/s 能否等同于真实能力：一方认为它已在参数效率上追平 Qwen，另一方则用编码失败案例和私有基准指出它仍明显不如 Qwen，并质疑 AutomationBench 到底测了什么。

肯定本地速度、效率与小模型可玩性

• 较多人肯定其在消费级硬件上的本地推理速度与效率：未调优即可在 5070 Ti 上以 131k 上下文跑到数百 tokens/s，小 agentic 模型本身也有可玩性；也有人称赞 Liquid 持续投入本地模型，原本受内存限制只能用 Gemma 4 12B 的用户表示会下载试跑。（较多人）
• 需要引用时，只用一句中文意译： > 我用 5070 Ti 在 131k 上下文、未调优的 llamacpp 下跑到 200–320 tokens/s，体验很不错，但目前还谈不上判断它的智能水平；这类小型 agentic 模型本身就很好玩。（@serf）

认为它已在参数效率上追平 Qwen

• 若 Qwen 发布同规模 MoE，按朴素外推其能力应与该模型接近，因此可视为有人在参数效率上追平了 Qwen（尽管对比的是 1–2 个月前的 Qwen）。（少数人）
• 需要引用时，只用一句中文意译： > 如果 Qwen 发布同规模的 Qwen3.8 MoE，按朴素外推能力应该和这个模型差不多；也就是说有人在参数效率上追平了 Qwen（虽然是 1–2 个月前的 Qwen）。（@2001zhaozhao）

质疑 AutomationBench 高分代表性，与其他基准不一致

• 该模型在 AutomationBench 上表现突出，但在其他基准上只是和其他本地模型接近，因此其高分到底意味着什么仍不清楚，关键在于 AutomationBench 究竟测什么。（少数人）
• 需要引用时，只用一句中文意译： > 它在其他基准上和别的本地模型相差不大，所以 AutomationBench 的高分到底意味着什么还需要先弄清楚：这个基准究竟测的是什么？（@sebmellen）

实测编码与通用知识仍不如 Qwen，速度优势未转化为能力

• 在真实编码任务中，它在简单 todo 实现上反复失败，而更慢的 Qwen 3.8 却完成了任务；另有私有基准显示，它的通用知识远不如 Qwen 35B A3B，只是按速度大概率仍胜过 Qwen 9B。（少数人）
• 需要引用时，只用一句中文意译： > 我让它在 ghostty 代码库里实现一个最简单的 todo，它反复出错、修一个编译错误又引入另一个；Qwen 3.8 虽然只有 40 tokens/s（慢于它的 75 tokens/s），却真的把任务做完了。（@blinkingled）

关注编码代理要达到 Claude/Codex 体验所需的速度门槛

• 有评论追问：需要多少 tokens/s 才能让编码代理有 Claude 或 Codex 那种跟手感；这说明评估模型时不能只看高 tokens/s，还需明确实用交互的速度门槛。（少数人）
• 需要引用时，只用一句中文意译： > 184 tokens/s 看起来不错，但一个编码代理到底需要多少 tokens/s 才能让人觉得像 Claude 或 Codex？（@nico）

担忧许可证中的非商用条款可执行性存疑且令人困惑

• 模型的许可证包含一条非商用使用条款，评论认为其可执行性存疑、表述令人困惑，希望团队咨询过知识产权律师；这可能会影响实际采用。（少数人）
• 需要引用时，只用一句中文意译： > 这个模型的许可证里有一条可执行性存疑的非商用使用条款，条款写得令人困惑，真希望他们咨询过知识产权律师。（@MatthiasPortzel）

有价值的补充

• 该模型已有 Unsloth 量化版本，内存/显存受限（例如原本只能用 Gemma 4 12B）的用户可以下载试跑；同线程中也有人推荐一并尝试 Ternary-Bonsai-27B。