LFM3-1.7B 与 Granite 4.2 30B：两款按维度得出不同评判的智能体模型

把 LFM3-1.7B 和 Granite 4.2 30B放在同一页面上，总体平均值会因你查看的是哪一行而指向相反的方向。在 Berkeley Function Calling Leaderboard V4 上，Liquid AI 的 17.3 亿参数模型得分为 71.39，而 IBM 的得分为 61.39——一个约小十七倍的模型领先十分。在 SWE-bench Verified 上，Granite 得分为 57.00，而 LFM3-1.7B 为 43.40，在另一个方向上领先 13.6 分。路由不会在提供商的标价上增加利润。提供商标价按 0% 加价 透传。

这两个模型都是为智能体构建的，二者在2026年相隔不到两个月发布，而且两家厂商都公布了足够多重叠的基准测试，使得进行真正的比较成为可能，而不是拼凑。这使这次对比成为难得的对决：有趣的问题不是哪个模型更好，而是你的工作负载实际落在哪个维度上。很少有任务同时需要71分的BFCL成绩和57分的SWE-bench成绩，而那些确实需要两者的任务，仅靠任一模型都无法得到很好的满足。

交叉的两个数字

Granite 4.2 30B 于 2026 年 8 月 25 日在 Apache 2.0 许可下发布，是一个密集的约 300 亿参数模型，基于 Granite 4.1 30B 基础模型构建，并使用约 15 万亿 token 训练。IBM 的定位是企业级：三种可配置的思考模式、基于 OpenAI schema 的原生工具调用、十二种经过测试的语言，以及一个以多阶段 GRPO 强化学习收尾的三阶段训练流程。

LFM3-1.7B 于两个月后问世，于 2026 年 10 月 27 日发布，专门针对智能体运行框架进行了后训练——Liquid 在模型卡中提到了 Hermes Agent、PI 和 OpenClaw。它是一个拥有 256K 上下文的 1.73B 稠密模型，明确面向本地智能体和工具调用，而非通用推理。

基准测试上的交叉并非某个薄弱数字带来的偶然。LFM3-1.7B 整张公开表都偏向智能体方向：BFCL V4 为 71.39，ToolSandbox 为 80.36，τ³-bench 为 68.01，LiveClaw 为 45.60，WebArena-Verified 为 38.42。Granite 的表则偏向工程方向：SWE-bench Verified 为 57.00，SWE-bench Pro 为 33.29，SWE-bench Multilingual 为 41.89，SciCode 为 38.76，TerminalBench 2.1 上为 29.24。每家厂商都针对不同的“agent”定义进行了优化，而基准表也如实反映了各自对应的是哪一种。

τ³ 为 68.01，对比 68.05，这才是真正的头条。

在这两个悬殊差距之下，隐藏着一场难分高下的较量。在 τ³-bench 上——这项通过用户模拟器和领域策略衡量多轮任务完成情况的工具使用评估中，LFM3-1.7B 得分为 68.01，Granite 4.2 30B 得分为 68.05——相差 0.04 分，与噪声无法区分。

这个结果比那两个大差距中的任何一个都更有意思，因为 τ³ 是最接近大多数智能体部署实际所做事情的基准：进行对话、遵循策略、调用正确的函数、从错误中恢复。如果一个 1.73B 模型在那里与一个 30B 稠密模型打平，那么参数数量换来的就是别的什么，而不是胜任的多轮工具使用。

它带来的收益体现在 BFCL 和 SWE-bench 上，而这两者衡量的内容并不相同。BFCL V4 依据 schema 测试单轮函数调用的正确性——LFM3-1.7B 的 71.39 表明，Liquid 在真实 agent 执行框架上的后训练直接见效了。SWE-bench Verified 测试的是端到端修复一个真实的 GitHub issue，这要求将代码仓库保持在上下文中、跨文件进行规划，并生成能通过测试的补丁——Granite 的 57.00 反映出一个具备这种能力的模型，以及为其量身构建的训练集。

所以这种划分是清晰的。小模型，在工具模式上训练充分：赢得函数调用测试。大模型，在代码修复上训练：赢得仓库测试。在两者都经过专门训练的多轮中间地带打成平手。

上下文是规范差异最严重的地方

• 上下文——LFM3-1.7B 为 262,144 个 token；Granite 4.2 30B 原生支持 128K，可扩展至 512K。扩展并非免费，而且 IBM 坦诚它是扩展而非原生窗口。

• 长上下文保持能力——LFM3-1.7B 在 128K 长度下于 RULER 上得分 65.56，而 Granite 4.2 30B 在同一基准系列上得分为 81.4。更大的模型能记住长文档中更多的内容，这与宣传中的上下文长度数字所暗示的恰恰相反。

• 占用 — 在 4 位下约为 1 GB，相较约 30B 的 BF16 权重，并提供官方 FP8、NVFP4 和 MXFP4 构建。这是单 GPU 模型，不是笔记本模型。

• 语言 — LFM3-1.7B 为十六种，而 Granite 测试了十二种，两者重叠的语言不同。Granite 的十二种包括捷克语和荷兰语；Liquid 的则包括泰语、越南语和印尼语。

• 思考模式 — Granite 4.2 30B 提供完整、低投入和无思考模式。LFM3-1.7B 没有此类功能面，而且其模型卡还表示，它本来就不适用于复杂的多步推理。

• 许可证 — Granite 采用 Apache 2.0 许可证，而 LFM 采用 Open License v1.0：年收入低于 1000 万美元时可免费使用，超过则需获得商业许可证。

30B dense 有哪些 1.73B 没有的成本

Granite 4.2 30B 是稠密模型，这意味着全部三百亿参数都会参与每个 token 的计算。这里不存在激活参数带来的折扣：每个 token 的计算成本约为小模型的十七倍，内存成本则是完整的权重文件。IBM 提供了各种量化版本以使其具备可行性，但无论在何种配置下，它都无法在手机上运行。

LFM3-1.7B 的优势主要不在于速度，而在于该模型能适配与你应用其余部分相同的内存预算。一个 1 GB 的模型可为文档存储、缓存以及同一设备上的第二个模型留出空间——这正是让本地智能体成为可能，而不只是理论上本地运行的原因。Liquid 报告称，在测试硬件上，其解码速度比前代产品快 1.8 到 2.8 倍，并且在 128K 下 KV 缓存为 1.6 GB，这两点对于在设备端运行、需要进行长对话的智能体都很重要。

作为平衡，Granite 的 30B 容量在 SWE-bench 数据中确实发挥了实际作用。如果你的智能体任务是在整个代码仓库中修改代码，那么 13.6 分的差距并不是更小的模型靠提示词就能弥补的，而节省下来的算力换来的却是更差的结果。

许可、签署与采购问题

Apache 2.0 正是大型组织无需经过法务审查即可采用 Granite 4.2 30B 的原因。没有营收门槛，没有商业触发条件，也无需谈判。自 2026 年 4 月起，IBM 还一直在对已发布的 Granite 模型进行加密签名——这听起来像是个细枝末节，直到你成为那个必须证明生产环境中所用的权重就是经过审核的权重的人。

Liquid 的 LFM 开放许可证 v1.0 在初创规模下确实相当宽松——年收入低于 1000 万美元可免费用于商业用途——但超过这一门槛就需要付费商业许可证。对于个人开发者或小团队来说，这不成问题。而对于大型公司内部的业务部门来说，这却是一场在首次部署之前就已开始、且可能不会很快有结果的对话。这种不对称性在任何基准测试中都没有体现，却往往能单独决定问题的答案。

同时运行两者，但不押注任何一方

对于评估这两个模型的团队来说，实际做法并不是先选一个。两者都是开放权重，而且都尚未经过独立评估者的验证，这意味着唯一重要的基准就是你自己的基准。通过单一端点路由候选模型，让相同的智能体轨迹分别跑过两者，并在你的任务上而不是在 BFCL 或 SWE-bench 上进行比较。

在这里，OrcaRouter 的用处与其说是作为托管方，不如说是作为控制面：一个密钥、一份账单，覆盖 200 多个模型，提供商目录价按 0% 加价透传，并具备自动故障转移，以免一次评估运行因某个提供商某一小时表现不佳而中断。目前 LFM3-1.7B 和 Granite 4.2 30B 都不在我们的目录中——两者都是开放权重下载项，且各自都需要走自托管这条路。路由真正体现价值的地方在于周边技术栈：你的智能体升级调用的前沿模型，或当本地模型的补丁未通过测试时用来对照的第二意见。

谁应该拿哪一个

LFM3-1.7B适合以下情况：智能体运行在用户设备上；任务是对 API 进行工具调用和结构化抽取；而 256K 上下文、1 GB 占用正是让产品得以成立的关键。请接受厂商自己的警告——它不适用于智能体编程，并在其后保留一个更大的模型，以应对需要的情况。

选择 Granite 4.2 30B，如果智能体需要接触代码库，如果你需要 Apache 2.0 和已签名权重以满足采购要求，如果工作负载能从可配置的思考强度中受益，并且你有可用于部署它的 GPU。BFCL 的差距确实存在，但范围很窄：它衡量的是单次调用中的模式正确性，而在实践中，一个 30B 模型配合设计良好的工具模式可以弥合其中大部分差距。

采用这种分工，如果你正在构建两家厂商都瞄准的东西——一个在 1GB 内存内处理常规工具调用、并把仓库规模的工作转交给服务器的本地代理。这种架构把每个模型用在它自己的基准测试表显示其擅长的位置，而且这是唯一能让交叉坐标轴不再成为问题的安排。

值得关注的问题是，Liquid 的智能体后训练配方是否能迁移到更大的检查点。如果未来的 LFM 模型既能保持 71.39 级别的 BFCL 表现，又能增加处理代码仓库工作的能力，那么这种轴向上的分野就会消失，这一比较也就变成了一个简单的规模决策。在那之前，这两个模型并不是在竞争同一项工作——它们是一体的两半。