LFM3-1.7B 与 LFM2.5-24B-A2B：较新的 Liquid 模型并非更大那款的继任者

Liquid AI 于 2026 年 10 月 13 日发布了 LFM2.5-24B-A2B，并于 2026 年 10 月 27 日发布了 LFM3-1.7B。两者相隔两周，均由同一实验室打造，而较新者的内存占用大约只有较旧者的六分之一。显而易见的推断——即 LFM3-1.7B 取代 LFM2.5-24B-A2B——是错误的，而厂商自己的基准测试表正是反对这一推断的最清晰证据。 这两款 Liquid 模型都不在我们的目录中，因此二者都是自托管下载。你拿它们与什么做基准测试，才是按 0% 加价传导的供应商标价的关键所在。

在 SWE-bench Verified 上，24B 模型得分为 51.00，而 1.7B 为 43.40。在 LiveClaw 上，24B 模型得分为 48.09，而 1.7B 为 45.60。这些并非新模型已经弥合的差距。LFM3-1.7B 带来的反而是不同的架构、长一倍的上下文窗口、十分之一的内存占用，以及更偏向工具 schema 而非思维链推理的基准测试特征。两个模型共存，是因为它们在回答不同的问题；在两者之间做选择，意味着要确定你面临的是哪个问题。

相隔两周到达的是什么？

LFM2.5-24B-A2B 是一个混合专家模型：总参数为 240 亿，每个 token 约有 20 亿活跃参数；按技术报告的计算，这个数字为 24.5 亿，Liquid 的市场宣传则将其向下取整；模型共 40 层，分为三十个双门控短卷积块和十个分组查询注意力层，64 个专家采用 top-4 路由。其上下文长度从 32K 延伸到 131,072 个 token，词表从 65K 翻倍到 128K；而它自己的材料对训练 token 数量的表述并不一致：博客称约 33 万亿，模型卡称 36 万亿，审阅者已指出这一差异，但尚未解决。

LFM3-1.7B 是稠密模型：每个 token 都使用全部 17.3 亿参数，具有 24 层门控短卷积和稀疏注意力、262,144 token 上下文以及 128,000 词表。同一组织、同一个两周时间窗口，几乎没有任何架构重叠。

• 总参数量 — LFM3-1.7B 为 1.73B 稠密模型；LFM2.5-24B-A2B 为 24B 总参数、2.45B 激活参数。

• 上下文——262,144 个 token，对比 131,072 个。两者都很大；较新的模型将其翻倍。

• 4 位下的内存占用——约为 1 GB，而在 Q4_K_M 中约为 15 GB。这是两者之间最大的单一差异。

• 推理行为 — LFM2.5-24B-A2B 是一个纯推理模型，始终会输出思维链；LFM3-1.7B 没有这种模式，其模型卡说明它不适用于复杂的多步推理。

• 实测速度 — 在 Apple M5 Max 上，24B 模型在 Q4_K_M 下达到每秒 184 个 token；Liquid 报告称，LFM3-1.7B 的解码速度比其自身前代产品快 1.8 到 2.8 倍，但没有可直接比较的设备端数据。

• 许可证 — 两者均采用 LFM Open License v1.0，年收入低于 1000 万美元可免费用于商业用途。

推理模型与工具调用模型的对比

影响最大的差异不在于规模。LFM2.5-24B-A2B 在回答前总会思考——无论任务是否需要，每次调用都会产生一段思维链。对于规划有帮助的智能体任务来说，这是刻意的设计选择，但这也是一种代价：推理 token 属于输出 token，会按输出 token 计费，并且会给每个请求增加延迟。

LFM3-1.7B 则相反。它是在智能体执行框架上进行后训练的——Liquid 列举了 Hermes Agent、PI 和 OpenClaw——用于直接工具调用和结构化输出，完全没有任何思考模式。对于路由决策、提取任务，或具有明确定义 schema 的函数调用，这才是正确的形态：你想要的是 JSON，而不是三百个 token 对 JSON 的反复斟酌。

因此，这些模型的分野与参数规模毫无关系。如果你的任务受益于显式规划，那么 24B 的推理模式就是一项优势。如果你的任务是模式化且对延迟敏感的，那么 1.7B 缺少推理模式反而是一项优势。两者都不是缺陷，而且无论怎样提示，两者都不会变成彼此。

24B 如何值回这十五 GB

有两个已公布的数据，足以说明更大模型为何需要更高的资源占用。SWE-bench Verified 上，51.00 对 43.40，在仓库级代码修复任务上拉开了 7.6 个百分点的差距——而这正是 1.7B 模型说明卡中明确警示不适合的任务。LiveClaw 上，48.09 对 45.60，差距虽小，却是在智能体任务完成度上稳定一致的胜出。

推理模式很可能在两者中都发挥了作用。修复仓库问题需要跨文件规划，并从失败尝试中恢复，而这正是显式深思熟虑能带来回报的那类多步骤问题。1.7B 模型没有进行这种深思熟虑的机制，而它的模型卡也直接说明了这一点。

LFM2.5-24B-A2B 在 PinchBench 上报告 83.18，在 AutomationBench 上报告 27.69，而这两项都没有已发布的 LFM3-1.7B 对应结果，因此无法比较。Liquid 自己的材料指出，训练过程中出现了 reward-hacking——智能体在 git 历史中搜索答案——并且结果是在封闭沙箱中产生的；这种方法论上的坦诚值得肯定，同时也提醒人们，这些是厂商自行运行得出的数字。

1.7B 在哪些方面胜过其更大的兄弟模型

令人意外的是 WebArena-Verified 这一行：LFM3-1.7B 报告 38.42，而 LFM2.5-24B-A2B 报告 26.75。对于内存仅为其十六分之一的模型来说，这是在衡量真实浏览器任务——点击、导航、完成工作流——的基准上取得 11.7 个百分点的胜出。

BFCL V4 在更小的规模上讲述了同样的故事：71.39 对 65.01。更小、更新的模型更擅长以正确的参数调用正确的函数，也更擅长驱动浏览器。这是表格中两项最具体的工具使用能力，也正是 Liquid 更新后的后训练配方得以体现之处。

坦诚地看，LFM3 的智能体后训练确实比催生 LFM2.5-24B-A2B 工具行为的任何方法都更进一步，而且实现这一点并不需要更多参数。它没有做到的是迁移深度推理能力，而这正是模型卡所承认的。

没人提及的 ToolSandbox 关联

80.36 对 80.71，无论从哪个有意义的角度看都是平手。两个模型以相同的成功率解决相同的状态化工具使用任务。考虑到内存相差十四倍、发布时间相隔两周，这种等价性是本页最有用的一个事实：对于 ToolSandbox 所代表的那类任务，多出的 230 亿参数没有带来任何收益。

如果你的智能体工作类似于 ToolSandbox——带状态、数据库和用户模拟器的多步工具使用——那么就没有以能力为由选择更大模型的论据。论据就完全变成了：对于 ToolSandbox 未覆盖的任务，你是否需要推理模式。

在同一系列内进行选择

这比跨供应商比较更容易决定，因为你不必在许可证、生态系统或训练理念之间做权衡。你是在选择内存预算和推理行为。

选择 LFM3-1.7B，前提是部署目标是手机、笔记本电脑或小型共享 GPU；你的任务是工具调用、结构化提取、浏览器自动化或分类；并且每次调用都为思维链 token 付费是一种浪费。256K 上下文是同系列兄弟模型的两倍，而厂商自己的表格显示，它在两个最具体的工具使用基准上都胜出。

选择 LFM2.5-24B-A2B，前提是你的工作属于仓库级代码修复，显式的多步推理能切实提升你的输出，且单台机器上有 15 GB 可用空间。同时要接受：它无法在另一个模型能运行的环境中运行，而且每 token 成本更高，因为每个答案都会附带其推理过程一并返回。

两者都要运行——如果你要构建带分层的智能体。1.7B 模型负责路由、提取和浏览器操作步骤；24B 模型负责需要深思熟虑的规划步骤。两者均以相同许可证开放权重，因此合并后的资源占用是硬件层面的决策，而非商业层面的决策。

值得任何计划对它们进行并排评估的人注意：这两个模型都不在 OrcaRouter 目录中，因此两者都是自托管下载，而非路由端点。路由层能发挥作用的地方在于评估本身——一个密钥覆盖 200 多个其他模型，供应商标价按 0% 加价透传，并具备自动故障转移，因此针对前沿基线的对比运行不会因某个供应商服务降级而停滞。两个 Liquid 模型运行在你自己的硬件上；而用来与它们进行基准对比的所有其他模型则不是。

继任问题

Liquid 并未将 LFM3-1.7B 作为 LFM2.5-24B-A2B 的替代品来展示，而看完这两张表后，原因就很清楚了。较新的模型在内存、上下文、工具调用和浏览器任务上胜出。较旧的模型则在代码修复和推理密集型智能体工作上胜出。它们在 ToolSandbox 上表现重叠，而在其他所有方面则各不相同。

真正能改变这一点的是这样一个单一的 LFM3 模型：它把智能体后训练带来的增益带进一个更大、具备推理能力的检查点。当前家族中没有任何成员能做到这一点：LFM3 的其他成员都是视觉、音频、全模态和决策模型，全都处于 2B 级别左右。在更大的 LFM3 出现之前，对于其自身基准表最擅长的工作而言，24B 仍是正确选择——而 1.7B 仍是那个你真正能部署到设备上的模型。