标题卡上写着“推出 LFM3”,副标题为“六个 2B 模型,一个主干网络”,并有三个标签:“256K 上下文”、“6 个检查点”和“4 位下 1 GB”。
Guides & Insights

推出 LFM3:六个 2B 模型、一个骨干网络,以及一个并非上下文的 256 Token 窗口

作者

Rowan Sterling

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

Liquid AI 的 LFM3 系列于 2026 年 10 月 27 日推出,是六个 2B 级检查点,而非一个旗舰模型:面向文本的 LFM3-1.7B、面向视觉的 LFM3-VL-2B、面向语音的 LFM3-Audio-2B、可同时处理一切的 LFM3-Omni-2B,外加两个决策模型,d1-2B 和 d1-omni-2B。这六个模型都源自同一个预训练骨干模型,LFM3-1.7B-Base,Liquid 也发布了该模型。公司的定位是“专业化智能”——刻意拒绝推出小型通用模型并在错误的维度上竞争。

公告发布不到一天,技术文档里的一个数字就已经被误读了。LFM3 的架构中列出了带有 256 token 窗口的滑动窗口注意力层。这是每一层注意力的几何结构,而不是模型的上下文长度。文本模型接受的上下文是 256K token。那些匆匆扫过层表、便断定 Liquid 推出的是一款 2026 年、记忆只有 256 token 的模型的读者,脑子里装的是错误的模型;得先把这一点纠正过来,这篇文章后面的内容才谈得上理解。

三混合架构实际上是什么

LFM3 以三种层类型堆叠在 24 层主体中,取代了 LFM2 的双向混合结构。其中十三层是门控短卷积,五层是窗口大小为 256 个 token 的滑动窗口注意力,六层是完全全局注意力。卷积核宽度从 3 扩展到 7。另有三项较小的改动随之引入:一个 sigmoid 门控,独立缩放每个注意力头的输出;全局层中的部分旋转嵌入,仅旋转每个头中频率最高的那一半;以及一种三明治式归一化,对每个块的输入和输出都进行条件化。

这个押注是:短卷积以低成本承载大部分局部结构,稀疏注意力负责中等距离,而一小片全局注意力把整个256K窗口缝合起来。这正是KV缓存能够保持足够小、从而真正有意义的原因——Liquid报告称,在相同测量条件下,完整的128K token缓存为1.6 GB,而Qwen3.5-4B为4.3 GB,MiniCPM5-2B为5.6 GB。文本模型本身在4位精度下约占1 GB。

训练分四个阶段进行:22 万亿个预训练 token;3.5 万亿 token 的中期训练阶段,该阶段大量包含智能体轨迹和工具调用,并将上下文扩展到 256K;在 1.75 万亿 token 上进行监督微调;随后将强化学习与来自六个专家教师模型的多领域同策略蒸馏相结合。词表大小为 128K token,与 LFM2.5-8B-A1B 共享,并且相比前代能够更高效地对非拉丁文字进行分词。

六个模型,以及它们的上下文分别去哪里

Liquid 明确表示,这些模型是同级关系,而非层级关系。每个模型都采用相同的骨干网络,并针对不同的输出形态进行了后训练。

Screenshot of Liquid AI's blog post 'Introducing LFM3: Every Modality for Specialized Intelligence', dated OCT 27, 2026, showing its opening paragraphs: that LFM3 brings text, vision, audio, omni and decision models onto one shared backbone, that the first release covers the 2B parameter range, that it was built on a new hybrid architecture and 22T tokens of pre-training, and that the base and post-trained models are open-weight on Hugging Face, the Liquid Playground and the Liquid AI API.

• LFM3-1.7B — 密集文本与智能体模型,1.73B 参数,256K 上下文,原生工具调用和结构化输出。

• LFM3-VL-2B — 视觉语言模型,19 亿参数,配备自研视觉编码器,Liquid 称其所需算力约为 SigLIP2 的三分之一。

• LFM3-Audio-2B — 语音识别、语音合成、语音翻译和音频理解,采用自研编码器加 LiquidCodec。

• LFM3-Omni-2B — Liquid 的首个全模态模型:输入文本、图像、视频和音频,输出文本或语音。

• d1-2B — 一个基于视觉分支构建的决策模型,它在单次前向传播中使用校准后的概率而非自由形式的文本来回答结构化问题。

• d1-omni-2B —— omni 分支上相同的决策接口。

上下文窗口并不统一,而这正是大多数发布报道遗漏的细节。Liquid 为文本模型和基础模型公布了窗口——256K,输入和输出合计——而其余四个模型一个都没有公布。无论是公告还是模型文档,都没有说明 LFM3-VL-2B、LFM3-Audio-2B、LFM3-Omni-2B 或任一决策模型的上下文长度。第三方文章流传视觉模型为 128K、全模态模型为 32K,这些数字很可能没错,但截至 10 月 28 日,它们并不在 Liquid 自己的页面上。如果你正在规划一个既能阅读长文档、又会查看截图的智能体,那么目前完全无法根据第一方文档确定 omni 模型的上下文规模。这是一个值得指出的缺口,而不是靠一篇从别处补齐信息的博客来填补。

Screenshot of the Hugging Face model card for LiquidAI/LFM3-1.7B showing 1.73B parameters, 24 layers made of 13 gated short convolutions, 5 sliding-window attention and 6 global attention, 256K token context, a 128,000-token vocabulary, 16 listed languages, the LFM Open License v1.0, about 1 GB of memory at 4-bit precision, 6,311 downloads in the last month, and the card's own note that the model is not recommended for agentic coding or complex multi-step reasoning due to its small size.

基准表,如实解读

下面每一个性能数字都来自 Liquid 自己,是在 Liquid 自己的评测框架上产生的,而且没有任何一项被独立复现。截至 2026 年 10 月 28 日,Artificial Analysis 上还没有 LFM3 条目——没有 Intelligence Index,也没有来自中立方的速度或延迟测量。这一点在这里比平时更重要,因为发布所依赖的比较是同框架比较,而这种比较会偏向该框架为之调优的那个模型。

LFM3-1.7B 在 Liquid 的 27 项基准平均分上得分为 49.37。该公司自家的 LFM2.5-2.6B 在同一组基准上得分为 31.55,这正是“参数减少 35%”这一说法的来源。真正值得关注的并非平均分:

• 工具使用 — BFCL V4 71.39、ToolSandbox 80.36、τ³-bench 68.01、MCP-Atlas 32.57。

• 智能体 Web — WebArena-Verified 38.42,AutomationBench 41.29,BrowseComp-Plus 37.00,LiveClaw 45.60。

• 代理式编程 — SWE-bench Verified 43.40,SWE-bench Multilingual 23.00,Terminal-Bench 2.1 为 12.92。

• 指令遵循 — IFEval 96.66,IFStruct 93.72,IFBench 73.03,Multi-IF 89.10。

• 知识 — GPQA Diamond 63.37,HLE 无工具时 7.17,有工具时 13.90。

• 长上下文 — RULER 128K 65.56,AA-LCR 52.83。

与其看总分,不如把它看成一个形状,这个能力轮廓是自洽的:指令遵循非常强,单轮工具调用尚可,而一旦任务需要许多连续步骤,表现就会急剧下滑。Terminal-Bench 2.1 的 12.92 和 SWE-bench Multilingual 的 23.00,不是能用来构建自主编码智能体的数字。Liquid 并未掩饰这一点——模型卡引导用户避开复杂推理和多步编码,这在厂商发布日是一种异常直白的定位。

效率方面的说法是这套推介的另一半。在 Q4_0 和 32K 上下文下,Liquid 表示 LFM3-1.7B 在三台测试设备上都是最快的模型,比排名第二的竞争者快 1.8 倍到 2.8 倍,同时内存占用最低。在单台配备 SGLang、使用 BF16 的 NVIDIA B300 上,它在 1,024 个并发请求下每天可处理 36 亿个 token。该公司还在安然邮件存档上并行运行了超过 300,000 个 LFM3-1.7B 智能体,作为压力演示。这些都是厂商数据,未经审计,但这类数字很难悄悄夸大。

Single-column scoreboard for LFM3-1.7B with six rows: parameters 1.73B dense, context 256K tokens, BFCL V4 71.39, SWE-bench Verified 43.40, AA Intelligence Index none yet, and licence LFM Open v1.0. The footer reads 'All figures vendor-reported by Liquid AI; no independent evaluation as of 28 Oct 2026.'

许可证及运行成本

权重以 BF16、FP8、NVFP4、GGUF、MLX 和 ONNX 构建版本形式发布在 Hugging Face 上,并在 vLLM、SGLang、Transformers、llama.cpp、MLX、ONNX Runtime、Ollama 和 LM Studio 中提供首日支持。许可证为 LFM Open License v1.0:年收入低于 1000 万美元可免版税商用,超过该门槛则需另行签订协议。决定 LFM3 对某家公司是否免费的界线是这个门槛,而不是参数规模。

Liquid 还提供托管 API,但在那里,公开记录比发布信息所显示的更少。文档列出了模型 ID 和 256K 的输入加输出上限,却没有费率表。第三方报道称,LFM3-1.7B 的托管费率约为每百万输入 token 0.08 美元、每百万输出 token 0.20 美元,而 vision、audio、omni 和 decision 变体的价格更高;Liquid 尚未在自己的页面上公布这些数字,因此应将其视为报道数据而非已确认数据。相比之下,自托管完全没有按 token 计价——成本在于机器,而在 4-bit 下,这台机器可以是一部手机。

OrcaRouter 适用于何处——以及不适用于何处

LFM3 不在 OrcaRouter 的目录中,我们也不会假装它在。它是开放权重软件,你可以自行运行,或通过 Liquid 自己的 API 调用。路由器真正擅长的是它外围的那一层。一个密钥、0% 加价之后——供应商标价直接透传——因此,从 LFM3 升级到前沿模型的路径是一条路由规则,而不是第二份合同。它的自动故障转移最重要的地方,恰恰是 LFM3 所面向的工作负载:在这种负载中,单个小模型是请求与错误之间唯一的屏障。

路由 DSL是更值得一提的契合点。在一次调用中把专才模型与通才模型组合起来——把 LFM3 形态的工作路由到小模型,其余的一切则落到托管模型上——正是这一系列模型为之而生的部署模式。Liquid 的整套主张就是:在狭窄任务上,2B 模型能以低得多的成本击败前沿模型。而路由器,正是让你既能拿到这份节省、又不必把整条流水线押上去的方式。

看什么

未解的问题不在于 LFM3 是否擅长它所声称的事情,而在于这些声称能否经受住一个并非由 Liquid 编写的评测框架。首先应重新测试的是该系列在智能体方面的数据,因为 WebArena-Verified 上的 38.42 和 AutomationBench 上的 41.29 远高于 1.7B 模型历来所能达到的水平,而智能体基准对提示词脚手架和重试策略最为敏感。一次独立运行若能落在 Liquid 表格的几个百分点之内,就会使 LFM3 成为端侧工具调用的默认选择。若一次运行低了十个点,就会使它成为一个不错的指令遵循模型,但智能体表现被夸大了。

在那一轮运行出现之前,诚实的总结是这样的:LFM3 是一个工程实现出色、异常坦诚的小模型系列,具有真正新颖的层组合、实实在在的内存优势、以可操作的许可证门槛发布的权重,并且没有任何主打基准测试的独立验证。架构表中的 256 token 窗口并不是上下文长度。发布内容中的其他所有部分,在有人证明并非如此之前,都值得按表面说法采信——也值得你在把它呈现给用户之前亲自实测。