LFM2.5-24B-A2B 与 Granite 4.2 30B：稀疏型笔记本模型，还是稠密型工作站模型

“开放权重”在LFM2.5-24B-A2B和Granite 4.2 30B身上扮演着两种截然不同的角色。Liquid AI 的模型于 2026 年 10 月 13 日发布，是一个 240 亿参数的混合专家模型，每个 token 激活 24.5 亿参数，并以厂商自有的 lfm1.0 许可证发布。IBM 的 Granite 4.2 30B 于 2026 年 8 月 25 日发布在 Hugging Face 上，是一个稠密的、仅含解码器的推理模型——其 BF16 safetensors 中约有 290 亿参数，每一个参数在每个 token 上都会参与激活——并以 Apache 2.0 发布。这两份许可证中，一份是不附带任何附加条件的标准 Apache 授权。另一份则不是，而这一差异，无论你围绕这两者展开怎样的基准测试之争，都不会消失。

第二个区别是一道任何评测都掩盖不了的算术题。一个激活参数为 2.45B 的 MoE，其规模正好适合你已经拥有的机器。而一个稠密的 29B 模型则需要一块显存足以容纳它的 GPU，这使得比较与其说是“哪个更聪明”，不如说是“这两个当中，哪一个是你真正能在眼前的硬件上跑起来的”。

参数的位置

LFM2.5-24B-A2B 共有 40 层，分为 30 个双门控短卷积块和 10 个分组查询注意力层，每个块有 64 个专家，并采用 top-4 路由。按发布文章中的说法，Liquid 用了 33 万亿个 token 来训练它——而针对同一发布版本的 Hugging Face 模型卡则给出 36 万亿个 token，两份文档都未澄清这一差异——随后分两个阶段进行中期训练，最后以五阶段后训练流程收尾，该流程以在真实智能体运行框架内进行的智能体强化学习结束。它的上下文长度为 131,072 个 token，词表大小为 128,000 个 token。

Granite 4.2 30B 是单一稠密堆栈，无需进行路由，它基于 Granite-4.1-30B-Base 检查点构建，并使用三种可选推理模式进行训练：包裹在 <think> 标签中的完整思考、低投入思考，以及完全不思考。它具备 128K 原生上下文，并有文档记载可扩展至 512K 的长上下文能力，支持十二种经过测试的语言，其模型卡建议在各任务中采用 temperature 1.0 和 top_p 0.95。

实际影响体现在吞吐的形态上，而不只是吞吐量本身。稀疏路由意味着 LFM2.5-24B-A2B 每处理一个 token 都要读取一个 24B 权重的文件，却只做 2.45B 的算术量——对内存带宽是好事，对其他任何方面也谈不上有什么坏处。稠密则意味着 Granite 4.2 30B 每生成一个 token 都要做满 29B 的工作量。如果你的工作负载是包含大量短轮次的长智能体循环，这种差异会不断累积放大。

供应商数据并列展示，并附上注意事项

没有人将这两者进行过正面比较。IBM 的数据来自 Granite 4.2 模型卡；Liquid 的数据则来自其发布当日的 vLLM 表格，而 Granite 在该表格中并未作为单独一列出现。因此，下表中的各行只是将两家厂商各自的说法并列呈现，并非正面交锋；并且四项基准测试中有两项使用了部分重叠但并非完全相同的测试框架。

• 参数——总计 24.0B，其中激活 2.45B，对比约 29B 的稠密模型，全部激活. 这个单一数字决定了你的硬件选择。

• 上下文 — 131,072 个 token，对比原生的 128K 和扩展的 512K。 在原生窗口下大致持平；如有需要，Granite 还能更进一步。

• 许可 — lfm1.0 与 Apache 2.0 对比。Apache 2.0 没有收入触发条件，也不存在使用领域的问题。请将 Liquid 的条款与你自己的数据进行对照。

• 智能体工具使用 — BFCLv4 65.01 对 BFCL v4 61.39。Liquid 的数值来自其自有评测工具链，IBM 的来自 4.2 模型卡。两者差距小到可以说，评测工具链比这点差距更重要。

• 编程 —— SWE-Bench Verified 51.00 对 57.00。Granite 领先，而这符合规律：LFM2.5-24B-A2B 是工具调用者，Granite 4.2 30B 则是同样能调用工具的推理模型。

• 指令遵循——IFEval 96.75 与 IFBench 74.69，对比 IFBench 77.17。两者都很强；两家厂商使用了不同的行对，因此请比较共有的一行。

在 Granite 的模型卡补充了 Liquid 未公布的细节之处，不妨将其视为推理方的论据：AIME 2025 为 89.17，GPQA 为 66.41，LiveCodeBench v6 为 75.77，MMLU-Pro 为 77.60，SciCode 为 38.76，RULER 在 64K 上为 89.96，在 128K 上为 81.38。最后一对数据正是 LFM2.5-24B-A2B 目前根本不具备的那种长上下文证据——Liquid 没有公布其 131K 窗口在任何上下文长度下的检索数据。

持有每一个的成本是多少

Liquid 为 API 访问定价为 每百万输入 token 0.10 美元——缓存部分 0.05 美元——以及 每百万输出 token 1.00 美元，均在其自有 Console 上提供，并附赠 2 美元起始额度。但托管端点其实并非真正的产品；产品是 24B-A2B 文件本身，而厂商宣称的吞吐量数据全部来自设备端：在 Apple M5 Max 上每秒 184 个 token，在 AMD Ryzen AI Max+ 395 上每秒 114 个 token。这两项数据均为厂商自报且未经复现，而无论它们是否成立，架构层面的论点都站得住脚：一个 2.45B 激活参数的 MoE 能以一种稠密 29B 模型无法做到的方式运行于统一内存之上。

IBM 未在模型卡上公布每 token 价格——Granite 4.2 30B 被定位为自托管检查点，以 BF16 以及 FP8、NVFP4/MXFP4 和 GGUF 量化格式分发。其全部成本就是你为容纳约 29B 稠密权重而必须购买或租用的 GPU，而 FP8 下的稠密 30B 所需内存远高于量化后的 2.45B 激活参数 MoE。按每 token 服务量计算，稀疏模型的运营成本更低；而在冷启动和最坏情况延迟方面，稠密模型没有需要预热的门控路由。你更在意其中哪一点，完全取决于该端点是否始终在线。

如果你想在不绑定任何一方的情况下测试两者，这两条路都可行。Granite 4.2 30B 在 Apache 2.0 下可自行托管，没有收入上限，而上述每个数字中由服务提供的那一侧——qwen/qwen3.6-35b-a3b和google/gemma-4-26b-a4b-it也在其中——都通过一个密钥放在我们的目录里，在每家提供商自己的标价上加价 0%，因此供应商的价格变动会在公布当天就同步到端点，而不是等到下一个计费周期。

该选哪一个

如果机器是限制条件，而工作负载是工具调用，就选 LFM2.5-24B-A2B。在衡量 harness 形态工作的场景中，它会胜出；它能在笔记本电脑可承载的占用里容纳 131K 上下文；而且 Liquid 是拿真实 agent 脚手架而不是静态测试集来训练它的——这个细节对路由器比对推理器更重要。这样做时，你需要接受两件事：lfm1.0 许可证不是 Apache 2.0，并且 Liquid 之外还没有人给这个 checkpoint 打过分。

如果你有相应的硬件、需要一款先推理再行动的模型，或者需要许可证是你们法务团队已经熟知的那种，就选 Granite 4.2 30B。它在编码方面领先，是两者中唯一公布了长上下文检索数据的模型，而且其 512K 扩展是实打实的文档，而非营销宣传。它的智能体指标则更薄弱——在 BFCL v4 上为 61.39，而 Liquid 为 65.01——这恰恰与参数规模所暗示的相反，也提醒我们：密度换来的是推理能力，而不自动等于工具使用纪律。

坦率的结论是，这两者并不是彼此的替代品。LFM2.5-24B-A2B 的定位，是那个在没有云连接的设备上运行循环的模型。Granite 4.2 30B 的定位，则是那个会深入思考问题、并且拥有证明自己能够交付的许可证的模型。如果你两者都有，路由问题就是该由哪一个来接收请求——而这是路由层存在的意义，不是基准测试表该做的决定。

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