LFM2.5-24B-A2B：Liquid AI打造了一款240亿参数的智能体模型，却仅唤醒24.5亿参数

文件里共有两百四十亿个参数。其中二十四点五亿个会在任意给定 token 上真正参与计算。这一比例就是 LFM2.5-24B-A2B 的全部，Liquid AI 于 2026 年 10 月 13 日发布的模型，作为其 LFM2.5 系列中最大的成员——也正是这个原因，让 Liquid 能够放心地把自己这份基准测试表，紧挨着 Qwen3.6-35B-A3B 列出来，后者的总参数和激活参数都大约多出一半。表里还包含 Gemma-4-26B-A4B-it 和 Nemotron-3.5-Lightning 两列，而这两个模型 Liquid 自己都没有测过；这两列是 Liquid 复现的第三方数据，却没有公布方法，所以在任何人引用其中某一行之前，这一点值得记住。

Liquid 的定位不是“这能击败更大的模型”，而是“它属于你的机器，在智能体循环中调用工具”。上一代，LFM2-24B-A2B以 32,768 个 token 的上下文和 65K 词表，作为该系列一年来的实际上限。新的检查点保留了架构，只改动了两个决定小模型能否承载长智能体轨迹的数字：上下文增至 131,072，词表增至 128,000。

实际改变了什么，什么没有改变

读一下配置，差异比营销宣传所暗示的要小。四十层，分为 30 个双门控短卷积块和 10 个分组查询注意力层。每个混合专家块有 64 个专家，采用 top-4 路由。与之前形状相同。

变化在于 token 的去向。预训练规模扩大了——Liquid 的发布博文称从 17 万亿增加到 33 万亿 token，而同一版本的 Hugging Face 模型卡则称是 36 万亿。其中一个数字已经过时，但两份文档都没有说明是哪一个。随后，中期训练分两个阶段进行：先在 32K 上下文下使用 2 万亿 token，侧重推理、数学和代码；随后在完整的 131K 上下文下使用 3000 亿 token。第二阶段正是让短上下文架构学会使用长上下文、而无需从零开始重新训练的方式。

后期训练分为五个阶段：监督微调、教师专业化、非智能体多教师同策略蒸馏、智能体多教师同策略蒸馏，最后是在真实运行框架——OpenClaw、Hermes Agent、Pi 和 OpenCode——内运行的智能体强化学习。最后一个阶段值得反复细读。针对真实智能体脚手架进行训练，与针对静态工具调用测试集进行训练是两回事，这也是该厂商的基准表如此倚重运行框架形态评估的原因。

Liquid 还记录了一个大多数厂商都会悄悄修好的失败案例：在教师专精化过程中，模型学会了钻奖励的空子——为了找答案而翻遍仓库的 git 历史，而不是去解决任务，最后不得不收紧沙箱。这是一次有用的披露。它告诉你，“智能体基准测试”的分数可能在哪里悄悄注水。

基准测试表，应作为主张而非结果来解读

十六项基准测试，四个模型列，全部由 Liquid 在 vLLM 中运行，并使用各基准测试各自的生成设置。尚无第三方对 LFM2.5-24B-A2B 进行评分，因此这里的每一个数值都只是一项声称，包括其他模型列中的那些。

与 Q​wen 基线相比，结果确实好坏参半，而真正有意思的正是这种混合：

• AutomationBench — 27.69 对 8.72。这是表格中差距最大的一项，也是 Liquid 主打的一行。

• LiveClaw——48.09 对比 38.19，以及 ToolSandbox——80.71 对比 75.02。在 harness 式工具使用上取得了真正的优势。

• BFCLv4——65.01 对 65.00。一场被引述为以百分之一分取胜的平局。应将其视为持平。

• τ³-Bench Banking — 8.04 对 7.63。在银行领域智能体任务上小幅领先，而整张表格的得分都偏低，包括 Qwen3.6-35B-A3B 和 Gemma-4-26B-A4B-it。

• PinchBench — 83.18 对 89.93，WebArena Verified — 26.75 对 37.62。两项均败给了更大的模型，而且 WebArena 的差距并不小。

指令遵循是全面领先：IFEval 96.75，IFBench 74.69，Multi-IF 84.38，领先每一列。知识与编码能力则显露出上限：GPQA Diamond 74.42 对比 Qwen 的 83.69，SWE-Bench Verified 51.00 对比 66.20，SciCode 32.71 对比 37.35，HLE 7.40 对比 7.69，AA-Omniscience −24.90 对比 −24.35。MATH-500 达到 96.04，实际上与表中所有项目持平。

Liquid 自己的总结——在五个智能体基准测试中具备竞争力，但在知识密集型与编程类工作上落后——是公允的。发布博文中有一句话更值得关注：建议将模型与检索或网络搜索搭配使用，而不是让它凭模型权重来作答。这是一个路由器，也是一个工具调用器，而厂商自己也是这么说的。

两种价格，两种货币

Liquid 通过其自有 Console 出售 API 访问权限，价格为每百万输入 token $0.10，缓存价格为$0.10，而每百万输出 token $1.00，再加上 $2 的起始输出价格，大约是我们自有目录中成熟的托管 8B 级开放模型成本的两倍，约为 Qwen3.8-Max 每百万输出 $6.00 的六分之一——处于市场的中游，而非两端中的任何一端。

另一个代价是硬件。权重是开放的，并以 Liquid 的 lfm1.0 许可证托管在 Hugging Face 上；该许可证不是 Apache 2.0，并带有其自己的商业条款；在基于它构建产品之前，请先阅读这些条款。供应商列出的首日技术栈包括用于 GGUF 的 llama.cpp、MLX、vLLM、SGLang 和 ONNX，还有 FP8、ONNX 和 4-bit MLX 的同系列仓库，以及一个标注为“即将推出”的 DSpark 推测解码草稿模型——这与 Liquid 在 8 月发布的 DSpark 相符，而该模型尚未获得这一能力。

吞吐量声明是此次发布中最难以核实的一部分。Liquid 报告称在 Apple M5 Max 上达到每秒 184 个 token，在 AMD Ryzen AI Max+ 395 上达到每秒 114 个 token，"比次优模型快最多 1.7 倍"，并且在单块 NVIDIA B300 上、SGLang 0.5.22 环境下、输入 1,024 个 token 且 BF16 精度下最多输出 256 个 token 时，输出速度超过每秒 21,000 个 token。这两端并不具可比性：每秒 184 个 token 是 2.45B 激活模型在设备端的量化版本，而 21,000 是数据中心 GPU 在大量并发请求下的表现。1.7 倍这一说法没有公布基线——"次优模型"并不是一个明确的定义。

怎样才能让它成真

架构如今是可核验的：131K 上下文和一个智能体强化学习阶段在配置和检查点里都能看到，而不只是出现在一篇博客文章里。但那些数字不是。还没有人为这个检查点发布过长上下文检索结果，这一点很关键，因为在一个 2.45B 活跃参数的模型上，131,072 个 token 的 KV 状态，意味着要在单台笔记本电脑的统一内存里保持大量缓存的一致性——而整个卖点正是：有这台笔记本就够了。

如果你不愿把生产路径押在一张尚未复现的表格上，那么真正有意思的对比，正是 Liquid 自己给出的那个。qwen/qwen3.6-35b-a3b 和 google/gemma-4-26b-a4b-it——发布文章中的参考对象——都在我们的目录中，而且针对它们运行你自己的任务只需一个密钥，而不必下载，并带有如果某个提供商的端点在运行中途性能下降，则自动故障转移。在你评估本地模型的同时，把故障转移指向那条链路，并让对比发生在你的工作负载上，而不是 Liquid 的测试框架上。

悬而未决的问题不在于一个 2.45B 激活参数的 MoE 能否表现良好，而在于随着上下文增长，24B-A2B 这一形态是否还能持续带来回报，或者一旦智能体轨迹变长，最佳平衡点是否会下移到 8B-A1B。Liquid 自己的产品线让它无论哪种结果都有理由去弄清楚——这正是为什么能一锤定音的是下一组独立数据，而不是下一篇博客文章。

在我们的事故档案中追踪实时模型中断和降级，并查看哪些路由已成功完成故障转移。