LFM3 与 Qwen3.8-27B：16 倍的规模差距，在指令遵循上缩小至 9%

LFM3-1.7B 拥有 17.3 亿个参数。Qwen3.8-27B 拥有 277.8 亿个参数，外加一个视觉编码器——权重是前者的 16.1 倍。把它们放到同一条基准测试线上，算术就不肯好好配合了。在 IFBench 上——该测试考察模型是否遵守它从未经过微调训练的约束——两者差距不到 9%。在 Terminal-Bench 2.1 上，差距是 5.6 倍。两个模型，固定的规模差距，而结果会从“你究竟为什么要花钱买大的那个”一路摆到“小的那个根本做不了这件事”，取决于你看的是哪一行。

这个差额就是整个决策的关键。这不是一个小模型追赶大模型的故事，也不是大模型被浪费在小任务上的故事。这是一个关于任务边界的故事：这条边界非常一致地横亘在遵循指令与执行计划之间——以及关于一项许可条款的故事：对于在收入超过某一门槛的公司工作的人来说，它会悄然重排价格比较的次序。

这些实际上分别是什么

Liquid AI 宣布推出 LFM3 系列，发布时间为2026-10-27——就在本文撰写的前一天——该系列包含六个大致属于 2B 级别的开放权重模型，均从共享的 LFM3-1.7B-Base 主干分支而来。LFM3-1.7B 是其中的文本成员：采用 24 层的 tri-hybrid 架构（13 个门控短卷积层、5 个窗口大小为 256 个 token 的滑动窗口注意力层，以及 6 个全注意力层），在 22 万亿 token 上预训练，并进行了最后一轮 3.5 万亿 token 的中训练，其中包含智能体轨迹和工具调用。权重已发布在 Hugging Face 上，Ollama 以 lfm3:latest 形式提供，下载大小为 1.7 GB，而厂商自己的模型卡建议不要将其用于智能体式编程或复杂的多步推理。最后一句话比模型卡上的其他任何内容都更重要，我们之后还会回到这一点。

Qwen3.8-27B 并不新。阿里巴巴发布了其权重，发布时间为2026 年 8 月中旬，采用 Apache 2.0 许可；它已有十周时间来积累下载量、量化版本和真实用户报告，而刚发布一天的版本根本不可能拥有这些。它是一个 27.78B 的稠密模型，基于由 Gated DeltaNet 和 Gated Attention 层组成的重复块构建，共 64 层，原生支持视觉和视频输入，并具有 262,144 个 token 的上下文，可通过 YaRN 扩展至 1M。思考默认开启，并可通过推理强度设置进行调节。

诚实地讲，这组对比存在一种很重要的不对称：一个模型有厂商基准测试表，却没有实际使用报告；另一个两者都有。下面关于 LFM3-1.7B 的任何内容，都应视为关于 Liquid AI 测试套件的说法，而不是关于你的工作负载。

小模型不落下风的那条规格线

从那些即使参数增加16倍也毫无收益的维度开始，因为这类维度比规模差异所暗示的还要多。

• 上下文窗口——两者原生均为 262,144 个 token。LFM3-1.7B 在中期训练阶段达到该长度；Qwen3.8-27B 原生支持该长度，并可通过 YaRN 扩展至 1M。

• 语言 — LFM3-1.7B 声明支持 16 种语言（包括英语、中文、日语、韩语、阿拉伯语和印地语）；Qwen3.8-27B 则针对多种语言进行了广泛训练，但未公布具体数量。

• 模态——LFM3-1.7B 为文本输入、文本输出；Qwen3.8-27B 为文本、图像和视频输入，文本输出。这是 27B 唯一在做本质上不同类型工作、而非同一工作更大规模版本的地方。

• 4 位精度下的内存占用——LFM3-1.7B 约为 1 GB，而 Qwen3.8-27B 约为 14–16 GB。

• BF16 下的内存占用——3.46 GB 对比约 56 GB，这正是笔记本电脑与多 GPU 工作站之间的差距。

• 许可证 — LFM Open License v1.0 与 Apache 2.0 对比。先记住这一点。

两侧都是 256K 上下文窗口，这才是真正令人意外的地方。上下文长度历来与参数数量同步增长，而在这里，一个大约 1GB 就能运行的模型，却提供了与需要工作站的模型相同的名义窗口。“名义”在这句话里确实有实际分量——1.7B 模型上的 256K 窗口，只有当模型能在其中找到内容时才有用，而这正是下面长上下文几行所测试的内容。

当 16 倍参数只换来 9% 的提升

Liquid 运行了一套 27 行的测试套件，并公布了完整表格，其中也包括竞争对手胜出的那几列。两个模型均报告了IFBench，这是整个对比中最干净的同口径对比行，因为它是由两家厂商报告的同一基准版本。

LFM3-1.7B 得分为 73.03。Qwen3.8-27B 得分为 79.5。差距为 6.5 分，不到较大模型得分的百分之九——而模型规模却小了 16.1 倍。对于一个主要任务是"接收这些杂乱输入，输出这种精确的 JSON 结构，绝不破坏 schema"的工作负载来说，这一差距几乎可以视为噪声，而部署上的差异则是 1GB 对 16GB。

Liquid 自己的表格在对比一个更接近的竞争对手时也说明了同样的道理。面对 Qwen3.5-9B——一个规模是 LFM3-1.7B 五倍的模型——这个小模型在 IFBench 上以 24 分的优势获胜（73.03 对 48.84），在 IFStruct 上领先 4.5 分（93.72 对 89.20），在 Multi-IF 上领先 4.7 分（89.10 对 84.44）。无论其他情况如何，指令遵循并不是一种会随参数数量平滑扩展的能力，一个训练良好的 1.7B 模型在这方面可以击败一个平庸的 9B 模型。

长上下文这几行更含糊，值得直说，而不是往对 Liquid 有利的方向四舍五入。在 AA-LCR 上，LFM3-1.7B 得到 52.83——就其规模而言是实打实的分数，与 Qwen3.5-4B 的 52.67 大致持平。在 RULER 128K 上，它得分 65.56，明显领先于 MiniCPM5-2B 的 37.96，但远远落后于 Qwen3.5-9B 的 87.11。所以 256K 窗口并非摆设，但也无法与更大模型的上下文窗口相提并论。Qwen3.8-27B 根本没有出现在那张表中，这意味着对于这一特定组合，没有同类可比的长上下文数字——只有一个很强的先验判断：原生 262K 的 27B 会胜过名义窗口相同的 1.7B。

在参数多出16倍的情况下，换来五倍半的提升

现在来看模型卡所警告的那些行。这里的每一项都是两家厂商都会报告的基准版本，因此不存在跨版本相减的情况。

• Terminal-Bench 2.1 —— LFM3-1.7B 为 12.92，而 Qwen3.8-27B 为 73.0。相差 5.6 倍。

• Humanity's Last Exam，无工具 — 7.17 对 30.8。差距为 4.3 倍。

• GPQA Diamond — 63.37 对 89.2。差距为 1.4×。

• LiveCodeBench v6 — 73.46 对 90.3。1.2 倍的差距。

那份列表的排序本身就是发现所在。差距在单次代码生成上最小，LFM3-1.7B 比一个规模是其十六倍的模型低约 19%。差距在 Terminal-Bench 上最大，那里的任务不是“写代码”，而是“在多个步骤中操作一台机器、从自身错误中恢复，并在任务完成时停下”。这恰恰是 Liquid 自己的模型卡中所说该模型缺乏的能力，而数据也与模型卡一致。在 GPQA 和 HLE 上，差距在于知识，这是这里最不令人意外的结果——一个在 22T tokens 上训练的 1.7B 模型，所见过的内容就是比一个在更多数据上训练的 27B 模型少，再多的架构优化也无法弥补。

有一行数据指向相反方向，而它是两张卡片上最有趣的数字。在 AA-Omniscience 的公开划分上，LFM3-1.7B 记录到 7.07 的准确率和 92.93 的非幻觉率。这一对数字意味着，该模型主要是拒绝作答，而不是错误作答。它是 Liquid 自家对比表中最高的非幻觉率数值，领先于表中所列的所有更大模型。Qwen3.8-27B 在 HLE 上的 30.8 则是相反姿态：它知道得更多，并且敢于据此作答。

如果你的流水线的故障模式是一个自信的错误值落进数据库，那么一个有 93% 的时间弃权的模型就是特性，准确率上限就是代价。如果你的流水线的故障模式是本该有值的地方出现 null，那么同样的行为就是缺陷。这是这场对比中最尖锐的关键点，任何聚合分数都无法体现。

三个你绝不能相减的数字

关于这一组合的对比页面往往倾向于罗列两家厂商公布的所有基准测试成绩。但其中有三项数据经不起方法论的推敲。

SWE-bench。Liquid 报告称，LFM3-1.7B 在使用 OpenCode 评测框架的 SWE-bench Verified 上得分为 43.40。阿里巴巴报告称，Qwen3.8-27B 在 SWE-bench Pro 上得分为 61.7。不同的基准、不同的评测框架、不同的任务分布。这两个数字之间的 18 分差异并不能衡量任何东西。如果你想了解差距的大致轮廓，请使用 Terminal-Bench 2.1，两者在该基准上报告的是同一版本。

任何综合指数。Artificial Analysis 在其 Intelligence Index 上以 xhigh 推理设置给 Qwen3.8-27B 打出 33.7 分。截至 2026-10-28，Artificial Analysis 上根本没有 LFM3 条目。发布仅一天的版本尚未经过独立评估，诚实的说法是 LFM3-1.7B 没有任何独立复现的数字。本文中归于它的每一个数字——以及本周其他所有地方——都源自 Liquid AI 自己的测试套件、基于 Liquid AI 自行选择的基准。

推理投入设置。Qwen3.8-27B 公布的成绩在 low、medium、xhigh 和非推理模式下差异显著；33.7 这个指数是 xhigh 模式下的数值，非推理模式的数字则明显更低。任何把 Qwen 的数值与 LFM3 的数值并列、却不说明推理投入设置的比较，都是在拿一个会反复斟酌的模型去比一个快速模型，然后把这种差异称作架构差异。

真正能定论的做法很直接：在相同测试框架上独立运行 LFM3-1.7B，并明确说明所用的投入设置，最好是在社区拿到权重并试用几周之后。在那之前，公平的总结是：厂商报告的指令遵循差距很小，而厂商报告的多步执行差距很大，且这两项说法都来自同一个利益相关方。

许可证才是真正的价签。

这部分会颠覆小与大的比较通常得出的结论。

LFM3-1.7B 以 LFM Open License v1.0 发布。其权重可免费下载、免费运行，但年收入达到或超过 1000 万美元的实体不得进行商业使用。Qwen3.8-27B 以 Apache 2.0 发布，没有收入触发条件，没有使用领域限制，也无需单独协议。

因此，对于一家只有两个人的初创公司来说，这笔账显而易见：一个能塞进 1 GB 内存、每个 token 零成本、还能运行在你已有硬件上的模型，几乎就是免费午餐。而对于一家营收超过 1000 万美元的公司——也就是说，大多数拥有值得优化的生产推理预算的公司——便宜模型并不免费，昂贵模型则毫无疑问已获得授权。那个看起来像省钱选项的模型，恰恰是附带法务沟通的那个。

这不是反对 LFM3-1.7B 的理由。这恰恰说明，应当先读许可证，再读基准测试表，因为许可证决定了基准测试表究竟是否可供你使用。

实际运行每一个需要什么

LFM3-1.7B 只需一行命令即可安装。它已收录在 Ollama 库中，名称为 lfm3:latest 和 lfm3:1.7b，二者均为 1.7 GB 下载，并声明支持 256K 上下文窗口；它还能在 Transformers 中运行，并支持单 GPU 微调。Hugging Face 发布版包含用于 SFT、DPO 和 GRPO 的 notebook，还包括一个完整示例：训练模型在手机应用中的 108 个工具里选出正确工具。如果你的目标是打造一个小型、专用、经过微调的提取器，并让它与数据位于同一台机器上，那么从下载到部署确实是一条很短的路径。

Qwen3.8-27B 是一个不同类型的项目。在 BF16 精度下，它约占 56 GB，需要多 GPU 服务器或较为激进的量化；在 4 位量化下，它可装入 14–16 GB，适合高端单 GPU 或配置良好的笔记本电脑，而 KV 缓存还会进一步推高实际内存占用。它可在 Transformers、vLLM、SGLang 和 TokenSpeed 中运行。如果你不想自备这类硬件，也可以使用托管服务——在 OrcaRouter 上，它由两家上游提供商提供服务：第一家每百万输入 token 收费 $0.33、每百万输出 token 收费 $2.40，第二家则分别为 $0.40 / $4.21。

这种两家提供商之间的价差值得停下来想一想，因为这种事只有在查看实时目录而不是新闻稿时才会显现。相同的权重、相同的上下文窗口，第二家提供商的输出费用大约高出 75%。OrcaRouter 以 0% 加价透传提供商的标价，因此两个价格可以并排看到，而自动故障转移意味着某家提供商出现小故障时会自动绕开，而不会暴露给你的用户。如果你正在评估将 Qwen3.8-27B 作为从一个小模型起步的流水线的升级路径，那这就是你会放在同一个密钥后面的那一段。

把另一半说明白：OrcaRouter 并不提供 LFM3-1.7B 的推理服务。它是一份权重下载，运行它意味着在你自己的硬件上搭建你自己的端点。本文之所以要提到我们，原因在于升级这一环，而不是这个小模型。

谁应该选哪个

真正决定这件事的并不是基准测试表，而是两个你在运行任何东西之前就能回答的问题。

如果任务是单轮且受模式约束，就选择 LFM3-1.7B——抽取、分类、路由、结构化输出、设备端工具选择——并且数据不能离开设备。如果你打算微调，它也是合适的选择，因为一个 1.7B 模型附带 SFT/DPO/GRPO 路径，且只需单 GPU 预算，是一个周末项目而不是一个季度。256K 窗口、16 种语言和弃答行为都指向同一个用例：一个狭窄、高吞吐、隐私敏感的组件，在这里错误答案比没有答案更糟，而且你的公司还处在营收线以下。

在以下情况下选择 Qwen3.8-27B：模型必须进行规划。多步骤智能体、终端操作、长时程编程，以及任何需要模型在十几次工具调用中从自身错误中恢复的任务——5.6× 的 Terminal-Bench 差距不是调参问题，而是模型卡在如实告诉你。当你需要的是知识而非格式、需要视觉或视频输入，或者 Apache 2.0 是硬性要求而非偏好时，它也是正确的选择。

如果你的流水线确实分成两半，那诚实的答案就是两个都选。适合这种搭配的模式是：用一个廉价、本地、受 schema 约束的首轮处理，并在首轮拒绝时升级到 27B——而这恰恰是一个有 93% 的时间选择弃权的模型所要发出的信号。这种架构用的是每个模型最好的那一行，而不用任何一个模型最差的那一行。

什么会改变这个答案

有两件事，而且这两件事都值得观察，而不是靠猜。

首先是针对 LFM3-1.7B 的一项独立评估。上文中的每一项能力主张都建立在 Liquid AI 自家测试套件之上，而该系列的 Base 检查点发布时根本没有附带任何基准测试表——这说明该系列的数据讲的是训练后（post-training）的故事，而不是架构的故事。在 IFBench 和 Terminal-Bench 上进行一次中立评测，要么会证实本文描述的这种割裂，要么会使其消解。

第二点是，Liquid 是否会在这一骨干架构上推出更大的文本模型。整个比较都围绕 16× 的参数差距展开，而指令遵循结果表明，训练配方所起的作用超过了参数数量。如果一款中等规模的 LFM3 问世，有趣的问题就不再是“1.7B 能否遵循指令”——它已经可以——而变成“这套配方在四十亿参数上会带来什么”。

在其中任何一种情况发生之前，有用的概括比记分牌更聚焦：LFM3-1.7B 是一个真正优秀的指令遵循者，但不会规划；Qwen3.8-27B 是一个真正优秀的规划者，其许可证足以让你创办一家公司。在两者之间做选择，不是基准测试问题，而是这两句话中哪一句更能描述你的工作负载的问题。