LFM3-1.7B 与 Gemma 4 26B A4B：低成本 token 的两种配方，只有一种能装进手机

从纸面上看，这两个模型对同一个问题采取了相同的思路。LFM3-1.7B由 Liquid AI 于 2026 年 10 月 27 日发布，与Gemma 4 26B A4B（Google DeepMind 于 2026 年 4 月 2 日推出）的存在，都是为了回答同一个问题：如何让一个能力足够的模型装进很小的内存预算？而它们给出的答案截然相反。Liquid 把模型做小了。Google 则让模型保持庞大，只在每个 token 上为其中一小部分付费。权重是免费的，所以账单位无非就是最便宜且靠谱的托管服务商所收的费用。我们按提供商的标价原样转嫁，加价幅度为 0%。

这种区别听起来像是架构上的冷知识，直到你算清一次部署的成本，到那时它就成了唯一重要的事。Gemma 4 26B A4B 每处理一个 token 激活 38 亿个参数，但你仍然得把其中 252 亿个参数保留在某个地方。LFM3-1.7B 会激活其全部 17.3 亿个参数，并且存储的也正是这么多。前者计算成本低。后者拥有。

打造廉价 token 的两种方案

Gemma 4 26B A4B 是一个混合专家模型：128 个路由专家加一个共享专家，30 层，每个 token 大约激活八个专家。这使它具备 25.2B 稠密模型的知识容量，而计算成本更接近 4B 模型。谷歌自己的说法是，它在约 12% 的 FLOPs 下，达到稠密 Gemma 4 31B 约 97% 的 MMLU-Pro 得分。

LFM3-1.7B 走的是另一条路。它完全稠密——每个参数都会在每个 token 上参与运算——而节省来自重新设计的架构，而非稀疏性。Liquid 的三混合栈共 24 层：13 层门控短卷积、5 层滑动窗口注意力层、6 层全注意力层。序列建模的大部分由卷积完成，卷积开销很低，全注意力只出现六次。正因如此，一个 1.73B 模型才能承载 262,144 token 的上下文和 128,000 token 的词表，而不会让 KV 缓存吃光机器资源。

• 总参数量——LFM3-1.7B 为 1.73B；Gemma 4 26B A4B 为 25.2B。

• 每 token 活跃参数——1.73B 对约 3.8B。这是两者唯一处于同一量级的一行。

• 4 位精度下的内存 — 约 1 GB 对比约 18 GB。这一行决定了能否部署。

• 上下文——两者均为 262,144 个 token，再次是真正的平局。

• 模态 — 仅支持文本，而非文本和图像输入，具备原生函数调用和可配置的思考模式。

• 许可证 — LFM Open License v1.0，年收入低于 1000 万美元时免费；Gemma 4 26B A4B 采用 Apache 2.0，无收入门槛。

为什么 3.8B 活跃参数并不意味着 3.8B 的内存占用

这是阅读混合专家（MoE）规格表时最常见的错误，所以值得直说。活跃参数决定计算量，粗略地说也决定速度。它们并不决定你下载文件的大小，也不决定你预留的显存。Gemma 4 26B A4B 需要其全部 252 亿参数常驻，才能在专家之间进行路由；按 4-bit 计算，这大约会落到 18 GB。你可以在单张 24 GB 显卡上部署运行它，Google 也提供了 FP8 和 NVFP4 构建来让这变得可行，但你不能把它放到手机上。

LFM3-1.7B 在 4 位精度下约为 1 GB——Liquid 的产品说明称它能装进手机或笔记本电脑，而在这一体积下，这一说法可信，并非营销话术。它还在 128K tokens 下保持 1.6 GB 的 KV cache，而这个数字才真正决定你能同时承载多少个长上下文请求。

实际后果是：26B-A4B 部署属于推理服务器层面的决策，而 1.7B 部署属于应用交付层面的决策。它们是不同的项目，有着不同的团队和不同的成本结构，任何基准测试都无法弥合两者之间的差距。

每个供应商发布了什么，以及这能告诉你什么

Google 为 Gemma 4 26B A4B 发布了一张宽表：MMLU-Pro 上 82.6，GPQA Diamond 上 82.3，AIME 2026 无工具条件下 88.3，LiveCodeBench v6 上 77.1，Codeforces Elo 为 1718，MMMU-Pro 上 73.8，以及在 128K 上下文、八针设置下的 MRCR v2 上 44.1。全部为厂商报告数据，均未经独立复现。第三方追踪显示其 LMArena Elo 接近 1438。

Liquid 为 LFM3-1.7B 发布了一张范围更窄的表格，且更偏向智能体任务：BFCL V4 上为 71.39，ToolSandbox 上为 80.36，τ³-bench 上为 68.01，LiveClaw 上为 45.60，WebArena-Verified 上为 38.42。它还报告了 IFEval 上 96.66、IFBench 上 73.03、GPQA Diamond 上 63.37、LiveCodeBench v6 上 73.46，以及 128K 下 RULER 上 65.56。Liquid 没有公布 LFM3-1.7B 的 MMLU-Pro 数据，这一缺失并不等于零——它只是尚未测量。

只有 LiveCodeBench v6 和 GPQA Diamond 才能干净地重叠。Gemma 4 26B A4B 在这两项上均胜出，分别领先 3.6 分和 18.9 分。在 Liquid 的测试套件转向智能体（agentic）的地方，没有可用来对比的 Gemma 数值——Google 报告的 τ²-bench 成绩是 68.2，而 τ² 并不是 τ³，因此把 68.01 放在它旁边，只会是一场披着严谨比较外衣的捏造对比。

1.7B 在对话中保留在哪里

3.6 个百分点的 LiveCodeBench 差距小于 14 比 1 的参数比例所预示的差距，原因在于架构。竞赛编程看重的是保持一个模式并输出正确函数的能力——这种能力更受益于干净的训练信号，而非原始容量。如果编程题就是全部工作，那么 26B 会胜出，这一节也会很短。

真正让 LFM3-1.7B 保持竞争力的，是 262,144 个 token 的上下文与 1 GB 占用空间的组合。一个能容纳一份大文档、并直接运行在阅读它的设备上的模型，与一个只能在服务器上容纳同一份文档的模型，是两种不同的产品。Liquid 报告称，在 128K 长度下 RULER 得分为 65.56——这算不上惊艳的长上下文成绩——Gemma 4 26B A4B 在同一基准系列上报告的是 81.4——但至少它真的被测出来了，在设备端，在 1 GB 的体量下。

在指令遵循方面，这个小模型也毫不逊色：IFEval 96.66 和 IFBench 73.03 对于这一尺寸级别来说都是很强的数字，且均为厂商报告的数据。对于工具调用或结构化输出的工作负载，这比 GPQA Diamond 更接近真正重要的指标。

路由层实际改变了什么

Gemma 4 26B A4B 已收录在 OrcaRouter 目录中——一个 API 密钥即可访问它，并同时访问另外 200 多个模型，提供商标价按 0% 加价率透传，因此供应商调价当天即可生效，而无需等待重新定价周期。这一点在这里比通常更为重要，因为该模型的经济性完全取决于提供商定价：权重免费，所以账单就是最便宜且合格的托管商所收取的费用，而这个数字会变动。

自动故障转移是另一半。一个具有 256K 上下文的 26B 混合专家模型，正是那种会在高峰时段触及容量上限的工作负载，而跨提供商路由意味着单台主机遭遇不顺的下午不会成为你的宕机事故。LFM3-1.7B 不需要这些，因为它运行在你控制的硬件上，也没有可从中故障转移的提供商。这不是它的优点，也不是它的缺点——这是选择另一套方案的结果。

对我们角色的坦诚定位是：我们为大型稀疏模型提供路由，而不为小型稠密模型提供服务；至于在两者之间如何选择，这并不是路由器能替你做出的决定。

一次完成决策

如果部署目标的内存不足 20 GB——手机、笔记本电脑、Jetson 或 AI PC——那么 Gemma 4 26B A4B 就不在候选之列，比较也就到此为止。选用 LFM3-1.7B，围绕 Liquid 自身指出的知识缺口来规划检索，并将其用于工具调用和结构化抽取——在这些场景中，它的指标确实具有竞争力。

如果你在 GPU 上提供服务，而且工作负载属于知识密集型、多模态，或需要达到 82.3 GPQA Diamond 和 82.6 MMLU-Pro 级别的推理能力，那么 Gemma 4 26B A4B 是更好的模型，而 18 GB 就是入场门槛。Apache 2.0 彻底免去了许可方面的讨论，对大型组织来说，这比几个基准测试分数更有价值。

如果你正在打造一款同时面向两者的产品——一个会把难题升级到服务器的端侧助手——那么这两者根本不是竞争对手。它们是同一套架构的两个层级，而真正有意思的工程问题在于你把升级的分界线划在哪里，而不是哪个模型在表格上胜出。

悬而未决的问题不是能力——这一点已明确对 Google 有利——而是一个拥有 256K 上下文的 1 GB 模型，是否足以胜任大多数端侧产品实际需要的那类狭窄智能体任务。Liquid 自己的模型卡异常坦率地说明它并不是推理模型。这种坦率比 LiveCodeBench 上的差距更有价值，因为它能告诉你该把工作负载的哪一半送到哪里。