LFM3-1.7B 在 vLLM 上：九天过去，原生支持仍只是两个待合并的 PR

Liquid AI 的 LFM3-1.7B于 2026 年 10 月 27 日发布，其模型卡把 vllm serve "LiquidAI/LFM3-1.7B" 印得就像一条普通命令。九天后，上游 vLLM 仍没有可用于运行它的 Lfm3ForCausalLM 架构。取而代之的是：10 月 30 日提交的一项功能请求、一个作为其他所有工作基础的内核拉取请求，以及六个开放的模型 PR——其中两个以两种不同方式实现了同一个 LFM3-1.7B 文本模型，且二者均未被合并。

这个差距就是这里的关键所在，而且它很窄。模型是真实且可下载的；运行时支持却还在排队。这是一篇关于这条队列的“目前已知”文章：哪些还在推进中，今天实际能运行什么，以及在模型卡上“可与 vLLM 配合使用”要成为部署计划所要求的那种事实之前，还必须落地哪些东西。

卡片上写的是 vLLM。支持的模型表上写的是 LFM2。

vLLM 自己的受支持模型文档列出了三个 Liquid AI 架构：Lfm2ForCausalLM、Lfm2MoeForCausalLM 和 Lfm2VlForConditionalGeneration。其中没有 LFM3 条目。与此同时，LFM3-1.7B 模型卡称，该检查点“可与 vLLM、SGLang 以及兼容 LFM3 的 llama.cpp 构建配合使用”，并给出了一个未附带任何标志的启动命令。

协调点就在检查点自身的配置中。LFM3-1.7B 带有一个 auto_map，指向其自带的 modeling_lfm3.py，因此 Hugging Face 侧的代码确实存在，并会自行克隆进允许远程代码的加载器。vLLM 针对该移植的跟踪 issue #64645——由 abhijithneilabraham 于 10 月 30 日提出，标题为“[Feature]: Support LiquidAI LFM3 models”——对后果说得很直白：“vLLM 没有 Lfm3ForCausalLM。”它列出的替代方案，是大多数人这个月最终会用上的逃生通道：“通过检查点的远程代码，配合 Transformers 后端来运行 LFM3。这会放弃分页注意力和卷积状态缓存。”

这个取舍值得直说，因为“运行在 vLLM 上”和“运行在 vLLM 的 transformers 后端上”是不同的产品。Paged attention 是让 vLLM 能够批处理长度差异极大的请求而不浪费 KV 内存的机制；conv state cache 则是把同样的思路应用到该架构的短卷积层上。把这两者都拿掉，你得到的只是一个能用的端点，却放弃了 vLLM 存在的两个理由。对于一个以低并发方式服务的 1.7B 模型来说，这也许是个可以接受的周末项目，但绝不是可接受的生产形态。

为什么 1.7B 模型还需要内核工作

LFM3-1.7B 并不是对 vLLM 已支持的 LFM2 系列进行简单重新调参。它是一个二十四层混合模型，包含三种而非两种层类型：13 个门控短卷积层、5 个窗口为 256 token 的滑动窗口注意力层，以及 6 个全注意力层。该 checkpoint 的 config 明确写出了这一几何结构——conv_L_cache: 7、sliding_window: 256、128K 词表——而 vLLM issue 中列出的差异还增加了 QK RMSNorm、逐头 sigmoid 注意力输出门、sandwich 归一化，以及全注意力层上的部分 RoPE（partial_rotary_factor: 0.5），并采用与 Gemma 4 相同的零尾部形状布局。

让这次移植失败的数字是七。LFM2 的短卷积宽度为三个抽头；LFM3 将其扩展到七个。vLLM 的 Triton causal_conv1d 内核只针对一组固定的宽度进行展开，正如跟踪 issue 中所说：“Triton causal_conv1d 的 prefill 内核展开宽度 2 到 4，decode 内核展开 2 到 6，因此宽度为 7 的模型目前无法在 CUDA 上运行。”

所以这个系列里的第一个 PR 根本不是一个模型。#64647，“[Kernel] Support width-7 causal conv1d”，由 abhijithneilabraham 于 10 月 30 日创建，涉及两个文件、新增 186 行：它把预填充内核从宽度 2–4 扩展到 2–7，把解码内核从 2–6 扩展到 2–7，并让两个包装器对超出该范围的任何值抛出 ValueError。该 PR 自己的描述解释了为什么这种拒绝与扩展同样重要：在改动之前，“更宽的权重会在没有匹配分支的情况下运行，并返回错误的值。”静默的数值损坏是比拒绝更糟糕的失败，而且它只会在你碰巧尝试的那个模型上才显现出来。

有一个注意事项应当随该 PR 一并说明。其作者明确表示自己没有 CUDA 机器：CPU 参考路径通过了 96 项测试，Triton 内核已通过对内核 AST 的静态分析进行检查，而 GPU 验证则留给 CI。这属于坦诚披露，而非缺陷，但这意味着其他所有 LFM3 PR 都依赖的那一项改动，尚未在大多数读者实际运行它所用的硬件上得到验证。

同一文本模型的两种实现

六天之内，两个彼此独立的团队为 vLLM 编写了原生 LFM3 支持。它们不是同一个补丁的变体；而是恰好采用了相同架构名称的独立设计。

PR #64959，题为“[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)”，由 atmikshetty 于 11 月 1 日提交，是较为保守的那个：共涉及七个文件，且按其自身描述，它复用了宽度为 7 的 ShortConv、Lfm2MLP、LFM2 权重映射器以及现有的比例 RoPE，未更改任何核心组件。它将模型注册到 registry 中，将其加入混合模型测试集和支持模型表，并且——对任何让它运行起来的人都很实用——记录了其验证时使用的 serving 标志：--reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice。其验证部分报告：在 A100-SXM4-40GB 上以 BF16 运行，324 个 kernel 测试通过，registry 和初始化测试通过，并与 Hugging Face remote-code 参考实现进行了 log-probability 比较。

PR #65826，标题为“[Model] Add LFM3-Text”，由 Liquid AI 的 paulpak58 于 11 月 5 日创建，是厂商自家的版本：涉及十个文件、新增 829 行，包括位于 transformers_utils/configs/lfm3.py 下的自有配置类以及自己的测试模块。它最初以“[Model] Add LFM3”为标题创建，并在该系列被拆分为四个堆叠 PR 的同一天更名：#65826 对应文本、#65827 对应视觉语言、#65828 对应音频、#65829 对应全模态，每个都基于前一个构建。

二者与其说相互冲突，不如说是并行推进，而讨论清楚地展示了依赖关系网。在内核 PR 上，paulpak58 于 11 月 4 日写道：“我们内部有自己的 LFM3 模型 PR，但这是一个我们可以支持的干净增补。”在社区文本 PR 上，abhijithneilabraham 提出，合并可能需要先合并 Liquid 的 transformers 工作——“我认为合并这个 PR 需要来自 @paulpak58 的 transformers PR”——对此 atmikshetty 回复说，Lfm3Config 尚未进入 transformers 发布版本，因此该分支“通过 trust_remote_code 从检查点加载配置，执行时使用原生 vLLM 模型”。这是大多数读者不会想到的第二道关卡：即使 vLLM PR 已合并，也需要有一个随某处发布的配置类。

在 transformers 一侧，对应的 PR 是 #50322，即“[Model] LFM3 Family: LFM3-Text”，于 11 月 3 日开启，目前仍处于开启状态，是从一个更大的家族 PR 中拆分出来的。它自身关于卷积的说明与 vLLM 的 issue 一致：short conv 在 LFM3 中“仅由 torch 实现（Hub 上的 causal_conv1d 内核支持宽度 2–4，而 LFM3 使用的是 7）”。

视觉-语言部分同样在重复。除了 Liquid 的 #65827 之外，一个独立的 LFM3-VL PR（#65450，11 月 3 日提交）仍处于开启状态，并且依赖于社区的文本 PR。因此截至目前，两个阵营合计有六个处于开启状态的 LFM3 PR，且没有一个被合并。

今天实际运行的是什么

抛开猜测，11月5日的实际情况是这样的。

• vLLM，原生方式 — 在原版构建上无法实现。注册表中没有 Lfm3ForCausalLM，受支持模型表中没有 LFM3 行，而本应添加它的 PR 尚未合并。

• vLLM，transformers 后端——文档中记载的变通方案，使用检查点内置的远程代码和 trust_remote_code。你会失去分页注意力和卷积状态缓存；但会保留 OpenAI 兼容服务器。

• SGLang——厂商自家的服务器路径。Liquid 的发布文章在单块 NVIDIA B300 上以 BF16 精度、使用 SGLang 测量其吞吐量数据，其中包含在 1,024 个并发请求下每天 36 亿个 token。vLLM 在该文中仅作为承载竞品模型的运行时出现。

• llama.cpp——卡片中提到的是“兼容 LFM3 的 llama.cpp 构建”，这是一个有实际意义的限定条件，而非套话；Liquid 的设备端数据是基于 Q4_0 量化、32K 上下文的 llama.cpp 得出的。

• MLX — 独立的 vLLM-Metal 项目在其 0.33.0 版发布说明中列出了 LFM3 文本 MLX 检查点，需通过 --trust-remote-code 启用。该项目与上游 vLLM 属于不同的代码库，并不表示支持 CUDA。

• 托管 — Liquid 自家的 API 和演练场。该卡片未提供价目表，因此无法根据公开材料为每个 token 的成本做预算。

两个数字能更清楚地说明自托管方案的可行性。模型权重足够小，因此内存并不是瓶颈——Liquid 声称在 4 位量化下约为 1 GB——而厂商表示，128K token 的上下文大约需要 1.6 GB 的 KV 缓存。瓶颈在于服务栈，而不是 GPU。

按顺序，什么会改变这一点？

这条依赖链异常清晰，这也让真正值得关注的点变得异常具体。首先，#64647 必须合并，因为其他所有 LFM3 PR 要么包含那个提交，要么基于它堆叠。然后，两个文本 PR 中必须有一个在评审中胜出——社区那个拥有更完整的验证记录，Liquid 那个则拥有同时负责 transformers 一方的作者。接着，Lfm3Config 必须进入某个 transformers 版本发布，否则每次部署都还得继续传 trust_remote_code。只有到那时，LFM3-VL-2B、LFM3-Audio-2B 和 LFM3-Omni-2B 才变得现实可行，而它们还排在更多 PR 后面，那些 PR 都假定文本模型已经合入。

这些都不应被解读为对进度的批评。从发布到一套完整、经过测试的“内核 + 模型”PR 栈只用九天，这已经很快了；而两个独立团队在不到一周内就做出了可用的实现，这一点更能说明 LFM3 与 LFM2 有多接近，而不是说明存在任何延迟。但模型卡是一种兼容性声明，对 LFM3-1.7B 当下的诚实解读是“通过 transformers 后端兼容 vLLM”，而不是“受 vLLM 支持”。

如果你这周需要一个小型工具调用模型

LFM3-1.7B 是一个很值得向往的目标。其厂商报告的数据恰好在小型模型通常失利的方面表现强劲——BFCL V4 上为 71.39，ToolSandbox 上为 80.36，IFEval 上为 96.66，SWE-bench Verified 上为 43.40——相比之下总体平均分为 49.37，Liquid 将其排在自家 LFM2.5-2.6B 的 31.55 之上。这些都是厂商自己的评估，由构建该模型的公司运行，没有独立复现，截至今天我们也没能找到 Artificial Analysis 的收录条目；请把这一排序视为假设，把各个数字视为宣称。伴随的警示来自同一来源：模型卡不建议用于智能体编程和复杂多步推理，而知识基准也与这一建议相符——GPQA Diamond 上的 63.37 和 128K 下 RULER 的 65.56，并不是通才模型会有的数字。

所以这个决定其实并不在于模型本身，而在于你是否承担得起在一个目前仍是未合并拉取请求的服务路径上构建。如果你能运行 SGLang 或 llama.cpp，那么今天就可以使用 LFM3-1.7B，vLLM 的问题也就只是学术问题。如果你的技术栈按政策规定必须使用 vLLM，那你就是在 transformers 后端缺失的 paged attention 与继续等待之间做选择。

对于无法等待的工作负载，还有第三种值得一提的选择：把请求路由到别处。OrcaRouter 并不提供 LFM3-1.7B——今天查我们的目录会返回 200 多个模型 ID，其中没有一个是 Liquid 的——所以这并不是在推销通过我们来调用它。更简单的一点是：一个尚未合并的内核 PR 对生产路径来说是个糟糕的单点故障。用一个 API 前置一个托管模型并启用自动故障转移，代价只是一次配置变更，还能让你在 LFM3-1.7B 原生支持合并的那天就换用它，而不是等到你完成押注的那天。如果你是在修改模型而不只是调用它，我们自己的 LFM3-1.7B-abliterated 版本就是同一检查点的拒绝方向消融，并且它恰好继承了这一服务处境。

简短版

LFM3-1.7B 已发布，体积小，非常适合它受训所针对的单轮工具调用任务。它的 vLLM 支持目前正由两个团队编写，建立在一种内核扩展之上，而该扩展的作者尚未在 CUDA 上运行过它。先关注 #64647——当宽度为 7 的卷积合并后，技术栈的其余部分会迅速推进，模型卡上的“可与 vLLM 配合使用”就不再是关于远程代码的陈述，而开始成为关于分页注意力和批处理的陈述。在那之前，任何针对该模型引用“首日 vLLM 支持”的人，引用的都是仓库中尚不存在的东西。