LFM3 泄露：Liquid AI 的下一代系列是四款小型全模态模型

2026年10月27日，GitHub上有人开了一个拉取请求，想教会SGLang如何服务一个在公开世界里并不存在的模型家族。它列出了四个检查点——LFM3-1.7B、LFM3-VL-2B、LFM3-Audio-2B和LFM3-Omni-2B——再对照已发布的LFM2.5-2.6B和LFM2.5-24B-A2B来读，就像一份 Liquid AI 下一步要造什么的蓝图。这个PR尚未合并，它的三项CI检查全部失败，Liquid AI 对此只字未宣布。截至今天，那段未合并的diff就是LFM3全部的公开记录，而它比大多数发布文章都更有信息量——前提是你按它的本来面目去读它。

因此，让我们把证据说准确些，因为它在某个方向上很薄弱，在另一个方向上却异常详细。这里没有任何内容是发布日期、价格、许可条款或基准分数。没有 LFM3 模型卡，没有 Hugging Face 仓库，没有博客文章，没有 API 列表。存在的是来自 tugot17——Piotr Mazurek 的贡献，他在过去两个月里将 LFM 运行时支持提交到了 SGLang、llama.cpp 和 mlx-vlm；此外还有 Liquid 自己已发布的、关于它即将取代的 LFM2.5 世代的材料。以下所有内容都按相应来源作了标注。

这个拉取请求实际上提出了什么

该 PR 的标题是 [Feat] lfm3：新增文本、视觉、音频和 Omni 支持，它带有两个标签，用来说明这是哪种类型的变更：jit-kernel 和 Multi-modal。它为四个模型组成的系列新增了原生文本生成能力，每个模型都有自己的检查点路径：

• LFM3-1.7B — 文本输入、文本输出，该系列基础层的纯语言模型

• LFM3-VL-2B — 文本、图像和视频输入，文本输出

• LFM3-Audio-2B — 输入文本和音频，输出文本，并且还接入了 /v1/audio/transcriptions 端点

• LFM3-Omni-2B — 输入文本、图像、音频和视频（包括视频自带的音轨），输出文本

那份清单里有一个细节值得停下来想一想。每个变体都输出文本。这个 PR 里任何地方都没有音频输出路径，而该音频模型的非聊天功能面是转写——语音输入、文本输出。这比 Liquid 当前的音频产品线要窄，后者有文档说明 LFM2.5-Audio-1.5B 能在单一模型中处理 ASR、TTS 和交错语音聊天。要么 SGLang 的首个版本只覆盖了 LFM3-Audio 的文本生成那一半，要么全模态家族确实放弃了语音合成。这个 PR 无法确定是哪一种，任何说它能确定的人都是在猜。请把“LFM3 会说话”视为未经证实。

diff 的其余部分属于实现细节，尽管如此仍能据此判断这项工作的年代。视觉和音频编码器及其投影器、共享主干、混合缓存集成、带 PyTorch 回退的 CuTe DSL 卷积内核，以及一条说明：FlashInfer 默认采用分页预填充，因此滑动窗口注意力能正常运作。验证在 H100 上以 FP16 运行，使用的是描述中所称的 开发检查点——这四个词之后很关键。

架构那句话，以及人们会误读的数字

该 PR 将 LFM3 描述为一种共享骨干网络，由门控短卷积与全注意力和滑动窗口注意力组成。这是 LFM2 谱系的延续，而非取代：LFM2.5-24B-A2B 被记载为跨 40 层的门控短卷积与分组查询注意力的混合架构。泄露信息中看起来新的部分，是与全注意力并存的显式滑动窗口组件。

验证说明提到某个提示词运行超出了 256 个 token 的滑动窗口，而这就是接下来一整周会被断章取义引用的那个数字。它不是 LFM3 的上下文长度。在混合设计中，注意力层只需要看局部，因为卷积层承载了长程信号——这正是该架构的整个前提，也是为什么该系列能在 LFM2.5-24B-A2B 上容纳 131,072 个 token 的上下文，而其大多数层根本不做二次方注意力。256 个 token 的注意力窗口说明的是模型在单层内部看向哪里，而不是它能接受多少文本。该 PR 并未说明 LFM3 的总上下文长度，Liquid 之外目前也无人知晓。

为什么运行时拉取请求是信号，而非噪音

仅凭一份基础设施层面的差异就推断产品策略，保持怀疑是合理的。但在这个具体案例中，这一模式太过一致，不容忽视，因为 Liquid 提供引擎支持是与与权重同步进行的，而不是在权重发布之后。LFM2.5-2.6B 将 llama.cpp、MLX、vLLM、SGLang、ONNX 和 Transformers 5.0+ 列为首日支持目标。LFM2.5-24B-A2B 在发布时即已获得 llama.cpp、MLX、vLLM、SGLang 和 ONNX 的支持。一个带着五种运行时一同问世的模型系列，必然在发布公告之前就已写好其内核，这意味着 PR 先落地，博客文章随后发布。

作者完全符合那条时间线。Mazurek 的公开记录是一连串 LFM 集成工作：九月在 SGLang 中为 LFM2-VL 实现 DSpark 投机解码，同月在 llama.cpp 中修复 LFM2.5-VL-3B 与 DSpark 草稿模型，在 mlx-vlm 中继承自文本模型的投机解码，以及 10 月 13 日在 SGLang 中复用 LFM2-MoE 配置。LFM3 是这一序列中的下一条，提交于该系列更名的那个周末。

有两处缺失，和存在本身一样能说明问题。Hugging Face Transformers 中没有与 LFM3 对应的拉取请求——在该仓库中搜索没有任何结果——而 SGLang 的 PR 通过原版 Transformers 5.19.0 配合 --trust-remote-code 加载其检查点，这正是当某架构尚未原生支持于该库时会采取的做法。还有一次提交明确拒绝了针对 LFM3 的推测解码，因此为 2.5 代发布的 DSpark 工作尚未被沿用。来得很早，而且按设计就是不完整的。

没人回答过的尺寸问题

在这里，泄密与所宣称的雄心背道而驰，而这种张力是这份文件中最有趣的地方。

Liquid 的预训练负责人 Maxime Labonne 将 LFM3 的目标描述为：检验那种在 3.5 亿至 12 亿参数规模上行之有效的短卷积方法，能否在超过 100 亿参数的规模下依然站得住脚——而这一区间正是注意力架构历来占据优势的领域。这是一个关于扩展的问题，也意味着要做一个大型模型。

泄露的检查点分别是 1.7B 和一个 2B 的三个。它们当中没有一个高于该问题所涉及的那个阈值。

有两种解读仍然成立。第一种是，这些是紧凑的第一波——在大型同门型号到来之前，面向手机和汽车的全能系列，这与 Liquid 一贯以小型模型打头阵的做法相符，也与 PR 将它们描述为开发检查点而非最终发布相符。第二种是，1.7B 和 2B 只是便于用来验证内核的尺寸，并不能说明最终会发布什么。诚实的立场是：这次泄露证明了该系列存在，也证明了它的形态；但并未证明它的上限。如果你在等一个 >10B 的 Liquid 模型，这份 PR 既没有承诺，也没有排除。

LFM3 继承了哪些东西，无论好坏

它必须超越的基线是近期且文档完备的。LFM2.5-24B-A2B 于 2026 年 10 月 13 日发布，总参数为 24B，激活参数为 2B，具有 40 层、64 个专家和 top-4 路由，上下文长度为 131,072 个 token，词表大小为 128K，预训练 token 数为 33T。LFM2.5-2.6B 于八月初推出，体积不足 2.5GB，支持 128K 上下文。LFM2.5-VL-3B 将 2.6B 基础模型与 SigLIP2 视觉编码器搭配。

值得直说：Liquid 为此发布的每一项基准测试都是厂商在 Liquid 自有测试框架上运行的，未附任何独立评估。LFM2.5-24B-A2B 的头条数字——AutomationBench 27.69、BFCLv4 65.01、ToolSandbox 80.71、IFEval 96.75——都是 Liquid 的数据，而同一张表显示其在 WebArena Verified（26.75 对 37.62）、GPQA Diamond 和 SWE-Bench Verified 上输给 Qwen3.6-35B-A3B。包含失利项的厂商表格比不包含的更可信，但可信不等于已验证。根本不存在任何 {{1}}LFM3{{/1}} 数字，所以目前还没有可比较的内容。

许可也将延续。Liquid 近期在 Hugging Face 上的 LFM 检查点，每个都标记为 license: other——一种定制的 LFM 许可证，而非 Apache-2.0 或 MIT。无论 LFM3 以何种许可发布，在模型卡另有说明之前，都假定适用同样的自定义条款，并在基于这些权重构建产品之前阅读这些条款。

当它可能真正实现的时候

没有人知道确切日期，连那些专业做预测的人也不例外。Manifold Markets 上有一个关于 LiquidAI LFM3 何时发布的问题，给出的概率是：2026 年第四季度 40%，2027 年第一季度 21%，2027 年第二季度 21%，2026 年第三季度 11%，2026 年第二季度 7%——总交易量约为 Ṁ160，这个量小到这些百分比反映的只是少数几个交易者的判断，而不是共识。把它理解为“大概率在未来两个季度内的某个时候”，仅此而已，不要指望比这更精确。

从机制上看，宜早不宜迟。将内核工作并入主流运行时属于后期而非早期工程——你不会为一个还要一年才推出的模型去编写 CuTe 卷积内核并接入混合缓存。该系列名称已在四个变体和四条检查点路径上稳定为 LFM3。但该 PR 尚未合并，三项检查全部为红，且缺少所需的批准审查；22 项 omni 验证检查中有 2 项、16 项视觉检查中有 2 项仍未通过其 ROUGE 比较。那是一个仍在推进中的分支，而不是发布候选版本。

如果你这周要选择模型，这意味着什么

LFM3 的任何信息都不应改变你今天做出的决定。它尚未公开可用、未公开定价、未公开基准测试，也未公开授权。如果你现在需要一个小型多模态模型，LFM2.5 代才是真正的答案；而它的各项限制——厂商自报的分数、自定义许可证，以及 Liquid 自家表格和外部报道都视为弱项的编码表现——才是需要权衡的地方。

这次泄露真正有用的地方在于规划。它告诉你一个紧凑的 omni 系列即将到来，很可能同时登陆多个运行时，而且它的音频变体或许不能合成语音。如果你的路线图曾假定 Liquid 的下一步是更大的文本模型，那么目前的证据并不支持这一假设。

运行时碎片化是这个模型家族将会带来的实际问题。Liquid 同时向 llama.cpp、MLX、vLLM、SGLang 和 ONNX 发布产品的习惯，有利于可移植性，却让任何想要单一端点的人感到棘手：五个引擎意味着五种部署形态、五套预处理怪癖，以及修复落地时间有五个不同日期。OrcaRouter 的200 多款模型目录目前不包含任何一个 LFM checkpoint，因此无法通过它调用 LFM3，本文也不应被解读为承诺未来会有。在这种情况下，路由层的实际用途，是充当未经证实的模型与生产路径之间的接缝——把一部分流量发送给新东西，同时让已知模型留在它后面，并由故障转移来兜住缺口，这样就能评估一个尚未发布的模型家族的继任者，而不必把面向客户的功能押在一个概率为 40% 的预测市场上。

值得关注的未解问题

有四件事会比任何进一步的猜测更快地解决这个问题。这四个 checkpoint 路径是否会成为真实、可下载的 Hugging Face 仓库——目前搜索 LiquidAI 组织时，在 LFM3 下没有任何返回，而 PR 中提到的仓库无法公开解析。是否会有一个 Transformers PR 出现，这将表明该架构正被正确地上游合并，而不是通过远程代码运行。失败的验证检查是否会关闭，因为 22 项 omni 检查中有 2 项失败，正是演示与合并之间的差别。以及该系列中是否会出现一个 >10B 成员，这是 Labonne 说 LFM3 存在所要回答的问题。

在那之前，任何人关于 LFM3 能写出的最准确的一句话，就是本文开头的那句：确实存在一个拉取请求，它尚未合并，并且提到了 Liquid AI 尚未宣布的四款小型全模态模型。这是一个真实的信号——只不过是一个早期信号，而早期信号就应该被当作早期信号来解读。