LFM3-1.7B 在 Ollama 上：一条命令，以及一张一分为二的成绩单

在撰写本文时，lfm3 的 Ollama 页面已经上线大约一个小时，并记录到 45 次下载。这就是它迄今为止全部公开使用量。它背后的模型，LiquidAI/LFM3-1.7B，是在一天前，即 2026 年 10 月 27 日发布的，作为 LFM3 家族中的文本成员，基于 LFM3-1.7B-Base 主干构建——与 Liquid AI 同一批推出的视觉、音频、全模态和两个决策模型一同亮相。10 月 28 日改变的不是模型，而是交付方式：ollama run lfm3 取代了寻找兼容 LFM3 的 llama.cpp 构建这一发布当天的途径。

它之所以比一行更新日志更有价值，原因在于那张基准测试表。LFM3-1.7B 交出了小模型类别中最悬殊的记分板之一：在浏览器自动化、工具调用和指令遵循上，它击败了 Qwen3.5-9B——一个规模超过它五倍的模型——而在通用知识和长上下文检索上，则以两位数的差距输给对方。那张表里的每一个数字都出自 Liquid AI 自己。目前尚无任何一项得到独立复现。

10月28日究竟发生了什么变化

Ollama 为 lfm3 列出了五个标签，发布时间都落在同一小时内，都带有 256K 上下文说明和纯文本输入。默认的那个是大多数人会拉取的。

• lfm3:latest 和 lfm3:1.7b — 1.7 GB，默认的 Q4 级产物，两个名称下的摘要相同

• lfm3:1.7b-mlx-bf16 — 3.5 GB，适用于 Apple 芯片的全精度 MLX

• lfm3:1.7b-mxfp8 — 2.1 GB，8 位 MLX

• lfm3:1.7b-nvfp4 — 1.7 GB，这一项需要仔细查看

最后一个 tag 携带的摘要是 2012d88e202f——与 :latest 背后是完全相同的产物。通过 Ollama 拉取 lfm3:1.7b-nvfp4 并不能让你得到 NVFP4 检查点；真正的那个是 Hugging Face 上的一个独立仓库，是为 GPU 推理服务发布的，而不是供本地拉取的。这个 tag 究竟是占位符还是发布时的疏漏，Ollama 的页面并没有说明。摘要可以核对，而且它们确实完全相同——如果你原本指望在笔记本上靠 FP4 节省显存，这一点才是关键。

Ollama 页面本身并非社区上传。Liquid AI 的模型卡将 Ollama 列为受支持的 GGUF 引擎之一，与 llama.cpp 和 LM Studio 并列，因此这是厂商指定的路径姗姗来迟，而不是某个陌生人的构建。页面上的模型卡文字出自 Liquid 本人：“LFM3-1.7B 是一个面向本地智能体和专用应用的三混合模型。”

架构，从决定其是否契合的标准来看

LFM3-1.7B 拥有 17.3 亿参数，共 24 层，其中只有六层执行全注意力。十三层是核大小为七的门控短卷积（上一代核大小为三），另外五层是窗口为 256 个 token 的滑动窗口注意力。长提示中的大多数 token 根本不会进入全局注意力矩阵，这正是其内存优势的由来。

Liquid 将 128K token 的 KV 缓存控制在 1.6 GB。Qwen3.5-4B 的同一指标为 4.3 GB，MiniCPM5-2B 则为 5.6 GB。正是这一差距，而非参数规模，使得 1.7B 模型能在 4B 模型无法胜任的硬件上承载长上下文。还有两个数字值得记住：22T 预训练 token，以及最后一个 3.5T token 的中训练阶段，该阶段侧重智能体轨迹和工具调用。最后这个阶段，是对接下来两节中所有内容最清楚的解释。

模型卡还列出了 16 种语言、与 LFM2.5-8B-A1B 共享的 128K 词表，以及默认开启的思考模式——Ollama 将其作为能力标签呈现，而不是隐藏标志。从配置意义上讲，256K 上下文是真实的，但模型卡仅在 128K 下公布了 KV 数值；在完整的 256K 下，缓存会随窗口扩展，因此应将该范围的上限视为数据中心配置，而非笔记本电脑配置。

评分强劲之处

这一模式在每一项奖励使用工具做事、而非了解世界知识的任务中都保持一致。这些是厂商报告的数据，对比对象则是 Liquid AI 所选定的那些。

• WebArena-Verified — LFM3-1.7B 为 38.42，LFM2.5-2.6B 为 3.02，Qwen3.5-9B 为 28.94

• AutomationBench — 41.29，而 LFM2.5-2.6B 为 0.94，Qwen3.5-9B 为 15.10

• BFCL V4 工具调用 — 71.39，而相同的两个模型分别为 55.89 和 62.83

IFBench — 73.03，而 Qwen3.5-9B 为 48.84

• IFEval — 96.66，Liquid 表格中的最高值

• LiveCodeBench v6 — 73.46，领先于 Qwen3.5-9B 的 69.86

最有趣的一行并不是最大的那一行。AA-Omniscience 是一个基准，其评分部分取决于模型是拒绝回答而不是猜测；LFM3-1.7B 在非幻觉方面记录为 92.93，而 Qwen3.5-9B 为 52.59。它在同一集合上的准确率为 7.07。将这两个数字放在一起看，它们描述的是一个大多会说自己不知道的模型——对于即将采取行动的智能体来说，这是一种被低估的特性，而对于被期望回答问题的助手来说，则是一种糟糕的特性。

在它失手的地方，有时输得很惨

同一张表，反过来读。

• GPQA Diamond — 63.37，而 Qwen3.5-9B 为 80.40，MiniCPM5-2B 为 65.15，后者是一个能胜过它的 2B 模型

• Humanity's Last Exam，不使用工具 — 7.17，对比 Qwen3.5-9B 的 16.41

• RULER 128K — 65.56，相比之下 Qwen3.5-4B 为 84.63，Qwen3.5-9B 为 87.11

• AA-LCR 长上下文推理 — 52.83，而 Qwen3.5-9B 为 62.00

• MCP-Atlas — 32.57，而 Qwen3.5-4B 为 41.37，Qwen3.5-9B 为 42.67

• SWE-bench Verified — 43.40，而 Qwen3.5-9B 为 51.20

• Terminal-Bench 2.1 — 12.92，而 Qwen3.5-9B 为 17.98

RULER 这一行值得单独用一句话说明：那个主打规格为 256K 窗口的模型，在自己的对比表中却是最弱的长上下文检索模型，还被宣称窗口只有其四分之一的模型击败。长窗口和在窗口中查找内容的能力是两项不同的技能，而 LFM3-1.7B 只掌握了前者，没有掌握后者。任何打算用它处理大型代码仓库或长篇合同的人，都应先测试这一行，再相信规格表。

MCP-Atlas 和 SWE-bench 这对基准，是以不同方式讲述的同一个教训。LFM3-1.7B 擅长驱动契约清晰的单一工具。但在智能体框架真正面向的多步骤、多工具工作上，它处于落后状态；当工作还需要了解代码库的功能时，它落后得更多。

这些数字是什么，以及它们不是什么

以上每一个数字都来自 Liquid AI 自己的评测运行，并与发布一同公布。公告中没有说明方法论：没有每项测试的测试框架配置，没有说明对多少次尝试取平均，也没有说明对比模型是由 Liquid 运行的，还是直接引自其各自的模型卡。一张由单一主体提供的 27 行表格是一种主张，而不是一次测量。

截至10月28日，Artificial Analysis上没有LFM3-1.7B的条目，因此没有第三方数据可以与厂商提供的数字进行对照。这种情况将会改变，而一旦改变，最有信息量的比较将是智能体（agentic）相关行，因为厂商在这些行上的领先幅度最大，因而最需要第二种意见。

有一个细节则朝相反方向起作用，值得肯定。Liquid 专门训练了一个量化感知蒸馏检查点，以弥补 Q4_0 量化带来的精度损失，并将其作为单独的 GGUF 文件发布。以人们实际会运行的精度公布小模型数据，比大多数厂商做得更多，也使 4 位数据比事后量化稍微更可信。

运行它，以及那些重要的设置

单行命令是 ollama run lfm3，而在 16 GB 内存的机器上，1.7 GB 的默认版本就是正确的起点。页面上还列出了四个单行启动器，可将该模型接入现有的智能体框架——ollama launch claude --model lfm3，以及面向 OpenCode、Hermes Agent 和 OpenClaw 的相同模式。这是页面上最有用的内容：它意味着无需编写客户端，就能把模型放进你已经在运行的智能体循环中，这比大多数本地模型发布所要求的门槛都要低。

卡片上列出了两种采样配置，它们不可互换：用于聊天、工具使用、智能体和编程时，使用 temperature 0.1、top_k 50 和重复惩罚 1.1；用于数学和科学时，使用 temperature 1.0、top_p 0.95 和 top_k 20。在数学问题上使用智能体配置，是让这个模型显得比实际表现更差的最常见方式。

如果你直接拉取 GGUF，而不是通过 Ollama，那么文件大小的分布会显得很方便。QAD Q4_0 检查点为 1.05 GB，略小于 1.1 GB 的 Q4_K_M，而且它正是为承受量化而训练的版本。Q6_K 为 1.43 GB，Q8_0 为 1.85 GB（如果有足够余量的话）；BF16 为 3.47 GB，在这个尺寸下很少值得使用。

该许可证是 LFM Open License v1.0——实质上等同于 Apache 2.0，但增加了一条：年收入低于 1000 万美元时，商业使用免费；达到或超过该门槛，则需获得付费许可证。该门槛按企业集团合并计算，并随微调模型一同适用，因此改名的衍生模型也无法规避。非营利和研究用户无论收入多少均获豁免。如果你接近该界限，请阅读许可证正文而非摘要，包括本摘要。

拆分配置文件对你部署它的方式意味着什么

一个在指令遵循和工具契约上很强、在参数化知识和长上下文检索上很弱、又便宜到能在笔记本上运行的模型，并不是通用助手。它是一个执行器。适合它的架构是一个本地循环——由模型决定调用哪个工具、格式化参数、遵循 schema——而把知识密集型以及真正需要长上下文的步骤交给更大的模型来完成。

这种分工正是路由器能体现自身价值的情形，而值得准确说明的是，OrcaRouter 在这里覆盖什么、不覆盖什么。LFM3-1.7B 是开放权重模型，运行在你自己的硬件上；它不在我们的目录中，本文也完全不是在为它做 API 推介。我们所提供的是这种分工的另一半：一个密钥即可访问200 多个托管模型，用于升级步骤，并享有按供应商标价 0% 加价、供应商性能下降时自动故障转移，以及可将多个模型组合成单次调用的路由 DSL。实际版本是：本地模型仍是循环中的默认选择，而需要真实知识的调用通过一个端点发出，而不是再引入第二个 SDK 和第二个合同。

如果你是在评估这个模型而不是部署它，那么故障转移是判断它是否经得起考验的更省钱的方法：将一部分流量路由到它，保留已配置的回退方案，并用自己的任务来比较，而不是看 Liquid AI 的表格。

此次发布留下的未解问题

Ollama 构建版本和 Hugging Face GGUF 是同一个东西吗？

不完全是。Ollama 的 1.7 GB 默认版本属于 Q4 级别，匹配的是通用 GGUF，而不是量化感知检查点；后者是 Hugging Face 上一个单独的 1.05 GB 文件，经过训练以恢复 Q4_0 精度。nvfp4 标签解析出的摘要与 :latest 相同，因此尽管名字如此，它并不是 NVFP4 构建。如果量化质量对你的任务很重要，请拉取 QAD 文件，并直接用 llama.cpp 运行它。

笔记本电脑能否使用完整的 256K 窗口？

很少见。Liquid 公布的 1.6 GB 缓存数字是针对 128K 的，而缓存内存会随窗口扩展，因此在计入权重和运行时之前，完整的 256K 大致需要翻倍。在一台 16 GB 的机器上，32K 到 64K 范围的工作上下文才是现实的上限；更大的窗口更适合被理解为面向服务器部署的余量宣称，而不是笔记本电脑的能力。

为什么智能体得分和知识得分之间的差异这么大？

因为它们衡量的是不同的东西，而这次训练更偏向其中一项。最后的 3.5T token 中期训练阶段强调智能体轨迹和工具调用，随后后训练加入了在 1.75T token 上的监督微调，以及跨工具使用和结构化输出的强化学习。参数化知识正是 1.7B 模型最没有空间存储的内容，而 AA-Omniscience 的分项结果——准确率 7.07，对应非幻觉率 92.93——表明它被训练成拒绝作答，而不是猜测。这是一种设计选择，而且对智能体来说是正确的选择。

裁决

LFM3-1.7B 是这个参数量级中首个真正值得因为智能体基准测试的表现而下载的模型，那些基准测试结果才是下载理由，而不是无关紧要的脚注。如果你正在构建一个本地智能体，需要可靠地调用工具、遵循模式并在不知道时选择弃答而不是编造答案，那么现在只差一条命令，而且它的特性正好适合这项工作。如果你需要一个知识渊博、能准确从长文档中检索信息，或能完成多步工程任务的模型，表格已经明确表明你应该另寻他处——而 256K 这一规格是表中最不可信的一项。

值得关注的不是 49.37 这个平均值，而是一次独立运行能否复现智能体任务上的领先幅度，因为正是在这些条目中，一个 1.7B 模型声称能击败 9B 模型，也正是厂商自家评测框架最有空间把结果说得更漂亮的地方。