LFM3-1.7B 对比 Gemma 4 12B：当小七倍的模型赢得编程基准测试

LFM3-1.7B是一个拥有 17.3 亿参数的文本模型，由 Liquid AI 于 2026 年 10 月 26 日发布到 Hugging Face，并于次日作为其 LFM3 系列发布的一部分公布。Gemma 4 12B是一个拥有 119.5 亿参数的稠密模型，由 Google DeepMind 于 2026 年 6 月 3 日发布，它不仅能读取文本，还能读取图像和音频。在两家厂商都发布的唯一一个编程基准——LiveCodeBench v6——上，较小的模型得分为 73.46，较大的模型得分为 72.0。请把这一点读两遍，因为这正是本页面存在的全部原因，也是互联网上最容易被误读的数字。路由不会在提供商的标价上增加加价。0% 加价请在我们的定价页面查看直通定价。

两个数字均来自厂商自报。两者都没有被独立评估方复现。它们由不同团队、在不同测试框架上、相隔数月得出，而且 Liquid 没有发布任何方法说明，解释其 LiveCodeBench 运行是如何配置的。因此，上面那句话的诚实版本并不是“一个 1.7B 模型在代码上击败了一个 12B 模型”。而是：两家厂商在一个同名基准上报告了几乎相同的分数，而 GPQA Diamond 上反向的九分差距表明，这两个模型根本算不上接近等价。

什么是真正可比的，什么不是

大多数“X vs Y”页面只是把两家厂商的表格并排放置，就称之为对比。这种做法只有在两张表格存在重叠项时才成立。在 Liquid 的 LFM3 发布文章和 Google 的 Gemma 4 模型卡之间，恰好有两个基准测试名称在双方都出现且定义兼容：LiveCodeBench v6 和 GPQA Diamond。其他所有内容都只有一家厂商报告，另一家没有报告，而空白单元格并不等于零。

在这两个共同维度上，结果是泾渭分明的分化。LFM3-1.7B 在 LiveCodeBench v6 上以 73.46 对 72.0 胜出。Gemma 4 12B 在 GPQA Diamond 上以 78.8 对 63.37 胜出——15.4 个百分点的差距，在只有几百道题的评估中绝非噪声。

这种模式值得被点明，而不是用平均化掩盖。LiveCodeBench 衡量的是模型完成竞技编程题目的能力，这是一种狭窄且高度模式化的技能，只要小模型用合适的数据训练就能擅长。GPQA Diamond 衡量的是研究生水平的科学推理，依赖知识广度——而这正是参数规模能带来的。一个 1.7B 模型可以在前者上具备竞争力，但在后者上会落败，这是一个自洽的结果，而非矛盾。

该供应商压低了自己最好的报价

下面这部分应该会改变你对 73.46 的解读方式。滚动到 LFM3-1.7B 模型卡片的底部，Liquid 用平实的语言写道：该模型专为本地智能体、工具调用和结构化输出而设计，而且由于其体积较小，不建议用于智能体编程或复杂的多步推理。

这是供应商，而不是竞争对手，在告诉你上限。这与一个略胜 11.95B 通用模型的 LiveCodeBench 分数放在一起显得别扭，而调和之处在于它们衡量的是不同的事情。解决一个孤立的竞赛编程问题，与在上下文中保持一个代码仓库并进行二十处协同编辑，并不是同一项任务。一个模型可以在前者上很强，却明确不适合后者，而 Liquid 正是在说明这一点，而不是让基准测试暗示相反的情况。

姑且信厂商的说法。如果你的工作负载是智能体编程，那么这场比较不应以 LFM3-1.7B 收尾。如果你的工作负载是工具调用、结构化抽取、分类，或是在你自己拥有的设备上运行本地助手，那么卡片上的警告并不适用于你，而 1 GB 的占用空间就成了全部理由。

而 12B 只是另一类东西

Gemma 4 12B 的多模态能力无法通过对 LFM3-1.7B 进行微调来添加。Google 的模型卡描述道，图像和音频输入会直接投影到与文本 token 相同的空间，无需单独的编码器——音频在 12B 及其较小的同系列模型上是原生支持的。LFM3-1.7B 是文本输入、文本输出。Liquid 的视觉能力存在于 LFM3-VL-2B 中，这是一个带有单独编码器的独立检查点，而文本模型不会仅仅因为经过微调就获得一个编码器。

• 参数 — LFM3-1.7B 的稠密参数为 1.73B；Gemma 4 12B 的稠密参数为 11.95B。比例为 6.9 比 1。

• 模态 — 仅文本，对比文本、图像和音频输入。

• 上下文——两者均为 262,144 个 token。这是小模型毫不妥协的唯一一行，而且这是三混合架构的真正成就，而非巧合。

• 占用空间——4 位量化下约为 1 GB，而相比之下约为 7 GB。在手机上，这一差异就是能否发布的分水岭。

• 语言 — 16 种具名语言，对比 140 多种预训练语言，并具备强大的开箱即用支持。对于拉丁字母产品，这一差距很少成为问题；而对于区域化部署，它却是决定性的。

• 许可证 — LFM Open License v1.0 在年收入低于 1000 万美元时可免费用于商业用途，超过该门槛则需购买付费许可证。Gemma 4 12B 采用 Apache 2.0 许可，没有收入触发条件。

这两张票据并非以同一种货币计价。

Gemma 4 12B 之所以有市场价格，是因为第三方在提供它。Artificial Analysis 报告称，在托管这些开放权重的各平台上，每百万输入 token 的混合中位数为 0.10 美元，每百万输出 token 为 0.30 美元——这是各提供商之间的中位数，而非标价，并且会随供给变化而变动。按这个价格，大多数团队根本不会考虑自己运行一个 12B 模型。

LFM3-1.7B 没有这样的价格。Hugging Face 模型卡明确说明，该模型未由任何推理服务商部署；这与我们这边看到的情况一致：OrcaRouter 目前不路由 LFM3-1.7B。如果你想调用它，需要下载 3.46 GB 的 BF16 权重或约 1 GB 的 4-bit 构建，并自行运行 vLLM、SGLang、llama.cpp、MLX 或 ONNX。Liquid 自己的 API 会提供它，若干第三方平台也会提供。

因此，成本比较并不是 token 与 token 的对比，而是微调与部署账单同按调用计费账单之间的对比。在低用量下，API 毫无悬念地胜出；而在你已拥有的硬件上持续高用量时，一个 1 GB 模型还能把 GPU 的其余部分空出来，这完全是另一种经济形态。真正值得考虑小模型的理由，正是这种不对称性——而不是 LiveCodeBench 上那四个百分点的差距。

每个到底是用来做什么的？

请选择 LFM3-1.7B，当部署目标是限制条件时：一部手机、一台笔记本电脑，或一块还要兼做其他工作的单个小型 GPU。256K 上下文在这个尺寸上确实少见，16 种语言的词表覆盖了大多数区域性产品，而六路推理支持意味着你不必押注于单一运行时。要接受这一点：你购买的是工具调用和抽取模型，而不是推理模型，并围绕厂商自己指出的知识缺口来规划检索。

选择 Gemma 4 12B它在研究生水平的科学推理上得分高出 15 分，能原生读取图像，而且上市首日即可按已公布的中位价格获得。代价在于内存：4 位量化下需要 7 GB，这意味着它适合笔记本电脑或规格适中的 GPU，而不是手机。

两者都选——当你拥有一条高流量窄路径和一条低流量宽路径时。将宽路径交给托管型通用模型，把小型模型留在设备端，用于处理窄路径中延迟敏感的调用。OrcaRouter 正是为这种拆分的前半部分而构建——一个密钥即可访问 200 多个模型，提供商目录价按 0% 加价透传，因此价格变动当天即可生效；如果提供商服务劣化，还能自动故障转移。它无法帮你托管 LFM3-1.7B，因为我们不提供该模型，暗示并非如此是不诚实的。

什么才能了结此事

对 LFM3-1.7B 在其并未自行选择的测试框架上进行一次独立评测，其价值将超过这一整页内容。Liquid 的发布表格详尽且内部自洽，而本博客将其视为厂商自报的数据而非经过核实的结论——事实也确实如此。真正值得关注的具体事项包括：能复现 73.46 这一成绩的第三方 LiveCodeBench 或 SWE-bench 运行结果；一份能将两个模型置于同一量表上的 Artificial Analysis 档案；以及任何关于该模型处理真实仓库任务的报告——而这恰恰是模型卡所警告的用法。

在此之前，站得住脚的解读比标题所暗示的范围更窄。一个拥有 256K 上下文、1 GB 占用和强大工具调用表现的 1.73B 模型，在某一项孤立的编码基准上追平了一个 12B 通用模型，但在知识方面远远落后于它。这不算爆冷。这是两个为不同任务而构建的模型，而有用的问题是：你手头的是哪种任务。