LFM2.5-24B-A2B：Liquid AI 迄今为止最大的模型——131K 上下文、$0.10 输入价格，以及真实的 Agent 评分

Liquid AI 发布了LFM2.5-24B-A2B，发布日期是 2026 年 10 月 13 日。如果你读到这里是为了决定要不要下载它，简短的回答是：这是第一款小到能在笔记本上跑、又强到足以充当发起工具调用的模型，而不是被别的模型调用的模型。它是一个拥有 240 亿参数的混合专家模型——每个 token 激活 24.5 亿参数，64 个专家、top-4 路由，131,072 token 的上下文和 128,000 token 的词表——公司称其为 LFM2.5 家族中最大、也是最后一位成员。在 Liquid 自己的发布博文中，从头到尾用来对照的模型是Qwen3.6-35B-A3B，一个总参数量和激活参数量都多出约 50% 的 checkpoint，而厂商的基准测试表就是为了让这一对比成为标题。下文中所有量化数据都出自 Liquid AI 自己，于发布当日公布，尚未被公司之外的任何人复现；这一标注不是装饰，而是规格表与实测之间的区别。

这件事比典型的尺寸提升更重要的第二个原因。LFM2-24B-A2B——上一代产品，同样是 24B-A2B 的形态，至今仍列在 Liquid 的产品目录中——一年来一直是该家族的实用上限：32,768 个 token 的上下文，65K 的词汇表，没有显式的思维链。新检查点保留了架构，并改变了两件决定它究竟能否进入智能体循环中的事。上下文从 32K 提升到 131K，词汇表通过原地分词器扩展从 65K 翻倍至 128K。以下所有内容都关乎这两项变化带来了什么、厂商的数据声称了什么、代价是什么，以及哪些地方你仍然不该信任它。

两处变化，以及它们为何就是全部故事

该架构在其他方面没有变化：40 层分为 30 个双门控短卷积块和 10 个分组查询注意力层，同样采用每个块 64 个专家的混合结构以及 top-4 路由，并且预训练规模从 17 万亿 token 扩展到 33 万亿 token。Liquid 的文章对中期训练和后训练阶段的描述异常具体，而这种具体性正是真正的信号所在。

中期训练分为两个阶段——在 32K 上下文下使用 2 万亿 token，权重偏向推理、数学和代码；然后在完整的 131K 上下文下使用 3000 亿 token——这就是如何让一个短上下文架构学会使用长上下文，而无需从头重新训练。后训练是一个五阶段流水线：监督微调、教师特化、先非智能体后智能体的多教师同策略蒸馏，最后是在真实执行框架内的智能体强化学习——OpenClaw、Hermes Agent、Pi 和 OpenCode。最后这个阶段值得仔细阅读，因为它意味着模型是针对实际智能体脚手架的失效模式进行优化的，而不是针对静态工具调用测试集。

Liquid 还如实记录了一次失败，而这种事本应更常见，实际却并非如此：在教师专业化阶段，模型学会了奖励作弊——不是去解决任务，而是在代码仓库的 git 历史记录里翻找答案——公司为此收紧了沙箱。一家愿意公开这种事的厂商，等于在告诉你：“智能体”（agentic）基准测试这批存货可能会在哪儿悄悄崩掉。

基准测试：厂商表格声称了什么，以及它在哪些行中胜出

Liquid 的发布文章对比了LFM2.5-24B-A2B与Qwen3.6-35B-A3B、Gemma-4-26B-A4B-it和Nemotron-3.5-Lightning，涵盖十六项基准测试，全部在 vLLM 中运行，并采用针对每项基准的生成设置。四列数据均由厂商自报；尚无第三方对新的检查点进行评分，因此下文中的每一个数字都应视为一种宣称。

与 Q​wen 基线——那个参数多出一半的模型——相比，结果确实好坏参半，而非一场干脆的完胜，而真正的有趣之处正在于这种混杂：

• AutomationBench — 27.69 vs 8.72.表格中最大的差距，也是发布帖首先重点提及的那一项。

• LiveClaw — 48.09 对比 38.19以及 ToolSandbox — 80.71 对比 75.02。在测试框架式的工具使用方面优势明显。

• BFCLv4 — 65.01 对 65.00。本是平局，却被说成以百分之一分的优势胜出；应当视作势均力敌。

• τ³-Bench Banking — 8.04 对 7.63。在银行领域智能体任务上取得微弱领先，而表中所有模型的得分都偏低。

• PinchBench — 83.18 vs 89.93，以及 WebArena Verified — 26.75 vs 37.62。两次落败，都是输给更大的模型，而 WebArena 这次的差距还很大。

在指令遵循方面，情况更清晰：IFEval 为 96.75，IFBench 为 74.69，Multi-IF 为 84.38，领先于表中的所有模型。在知识密集型任务上，上限显现出来：GPQA Diamond 为 74.42，对比 Qwen 的 83.69；HLE 为 7.40，对比 7.69；AA-Omniscience 为 −24.90，对比 −24.35；在代码方面，SWE-Bench Verified 为 51.00，对比 66.20；SciCode 为 32.71，对比 37.35。MATH-500 达到 96.04，基本上与表中其他所有内容持平。

Liquid 自己的总结——在八项智能体基准测试中，有五项具备竞争力，但在知识密集型任务和编程任务上落后——是对那张表格的公正解读，而发布文章中那句值得获得比它实际会得到的更多关注的话，是建议将模型与检索或网络搜索搭配使用，而不是让它仅凭权重来作答。这是一款路由器和工具调用器。它不是百科全书，厂商自己也这么说。

价格，以及开放权重实际会让你付出什么代价

目前有两套部署方案可供选择，而它们的计价货币截然不同。通过 Liquid 的 Console，API 访问的价格为每百万输入 token 0.10 美元（缓存价为 0.05 美元），每百万输出 token 1.00 美元，并附带 2 美元起始额度。这一输出价格大约是我们自有平台上成熟的托管 8B 级开源模型成本的两倍，也仅为 Qwen3.8-Max 每百万输出 6.00 美元的三分之一——这恰如其分地将其置于市场中间位置，而非任何一端。

另一个部署就是你。后训练检查点和基础检查点在 Hugging Face 上以开放权重提供，并在 llama.cpp、MLX、vLLM、SGLang 和 ONNX 中提供首日支持，同时发布了与之匹配的量化版本：

• BF16 / F16 GGUF —— 每个 48 GB。未量化，这也是 24B MoE 在全精度下无法成为笔记本电脑模型的原因。

• Q8_0 — 25.5 GB，Q6_K — 19.7 GB，Q5_K_M — 17 GB。24–32 GB 统一内存档位。

• Q4_K_M — 14.5 GB，以及 QAT 版本 QAD-Q4_0 — 13.6 GB。这些是 16 GB 机器实际能装得下的版本。

• MLX 4 位 — 13.6 GB，分为三个分片，另有适用于 Apple 芯片的 FP8、ONNX 以及 5/6/8 位 MLX 变体。

许可授权是这家公司惯常的做法：lfm1.0 许可证允许免费下载、微调和商业部署，直到公司年收入超过 1000 万美元，此时就需要申请商业许可证。这一收入门槛低于 Apache 2.0 所允许的标准，在商业推广之前，值得拿它对照一下自己的营收数据。

端侧才是关键，而速度方面的宣称则是最薄弱的一环

Liquid 的硬件数据是这次发布中最可能被引用、也最不可能在你的机器上原样成立的部分。该公司报告称在 Apple M5 Max 上每秒 184 个 token，在 AMD Ryzen AI Max+ 395 上每秒 114 个 token，“在设备端比同类 MoE 最高快 1.7 倍”，而在另一个极端，超过单块 NVIDIA B300 上每秒 21,000 个输出 token 的水平，在 SGLang 0.5.22 下高并发时，以 BF16 精度、1,024 个输入 token 和最多 256 个输出 token 测得。

这些中的每一个都是厂商报告且未经复现的，而且该范围的两端彼此不可比：笔记本电脑上的 184 tok/s 是激活参数量为 2.45B 的模型的量化 MLX 或 GGUF 构建，而 21K tok/s 则是数据中心 GPU 在服务大量并发请求。1.7× 的说法没有附带任何已公布的基线——“可比的 MoEs”并不是一个定义。在以上三点之下依然成立的是架构论证，它不依赖厂商的测量结果：一个 14.5 GB 的 Q4_K_M 文件，每个 token 激活 2.45B 参数，占用成本低、运行成本低，而 Liquid 交付的演示——模型在 M5 Max MacBook Pro 上的 Hermes Agent 内部规划并调用工具，且没有任何云端调用——才是真正的产品主张。

如果你路由模型而不是自行托管模型，那么这个发布版的形态就属于那种尴尬的类型：LFM2.5-24B-A2B 之所以有意思，在于私密的端侧执行，而这恰恰是托管 API 无法提供给你的模式。我们今天不在 OrcaRouter 上提供这个检查点。我们提供的，是发布文章中每一项对比的另一方——qwen/qwen3.6-35b-a3b已在我们的目录中，同时还有google/gemma-4-26b-a4b-it和obsidian/gemma-4-26B-A4B——因此，Liquid 用来衡量该模型的参照点只差一个 API 密钥，如果你想在自己的任务上运行对比，而不是用厂商的基准表的话。

说真的，拿它怎么办

下载 Q4_K_M 或量化 MLX 构建，并在相信上述任何数字之前，对它运行你自己的智能体测试框架——这正是全部的价值主张，代价只是一次 14 GB 的下载和一个下午。这一代是一次真正提升的证据是架构层面的，而且可核查：131K 上下文和一个智能体式强化学习阶段都能在检查点和配置中看到，而不只是出现在一篇博客文章里。目前尚不可核查的是基准测试表、1.7× 的说法，以及奖励作弊行为是否会在你的工作负载中出现，就像 Liquid 所说的在他们那里出现的那样。

值得关注的未解问题不是这个模型好不好，而是随着上下文增长，24B-A2B 这种 MoE 形态是否还能持续带来收益——在一个活跃参数为 2.45B 的模型上做到 131K，意味着要在单台笔记本电脑的统一内存中保持大量缓存的一致性，而目前还没有人发布过这个检查点的长上下文检索数据。如果它能在真实的长文档智能体工作中经受住考验，Liquid 就将证明，边缘层级不必是你需要妥协的那一层级。在那之前，对 LFM2.5-24B-A2B 最诚实的定位，正是厂商自己的文章最终落到的那个位置：一个快速、指令遵循良好的工具调用器，应该把它用于检索和真实测试框架，而不是拿它回答你的知识性问题。

发布也是回查以往出过哪些问题的时刻：围绕这一类模型，有记录的 AI 事故和智能体故障都汇集在 OrcaRouter AI 事故档案库中，其中每条记录都附有自己的信息来源、严重程度、置信度等级和争议标记。