LFM3-1.7B on vLLM: Nine Days In, Native Support Is Still Two Open PRs

Liquid AI's LFM3-1.7B shipped on 27 October 2026 with a model card that prints vllm serve "LiquidAI/LFM3-1.7B" as though it were an ordinary command. Nine days later, upstream vLLM has no Lfm3ForCausalLM architecture to run it with. What exists instead is a feature request opened on 30 October, one kernel pull request that everything else is stacked on, and six open model PRs — two of which implement the same LFM3-1.7B text model in two different ways, and neither of which has been merged.

That gap is the whole story here, and it is a narrow one. The model is real and downloadable; the runtime support is a queue. This is a what-we-know-so-far piece about the queue: what is in flight, what actually runs today, and what would have to land before "works with vLLM" on a model card becomes true in the sense a deployment plan needs it to be.

The card says vLLM. The supported-models table says LFM2.

vLLM's own supported-models documentation lists three Liquid AI architectures: Lfm2ForCausalLM, Lfm2MoeForCausalLM and Lfm2VlForConditionalGeneration. There is no LFM3 entry. The LFM3-1.7B card, meanwhile, states that the checkpoint "works with vLLM, SGLang, and LFM3-compatible llama.cpp builds" and gives a serving command with no flags attached.

The reconciliation is in the checkpoint's own configuration. LFM3-1.7B carries an auto_map pointing at its bundled modeling_lfm3.py, so the Hugging Face-side code exists and clones itself into loaders that permit remote code. vLLM's tracking issue for the port, #64645 — "[Feature]: Support LiquidAI LFM3 models", opened 30 October by abhijithneilabraham — is blunt about the consequence: "vLLM has no Lfm3ForCausalLM." Its listed alternative is the escape hatch most people will end up using this month: "Run LFM3 through the checkpoint's remote code with the Transformers backend. That gives up paged attention and the conv state cache."

That trade is worth stating plainly, because "runs on vLLM" and "runs on vLLM's transformers backend" are different products. Paged attention is the mechanism that lets vLLM batch requests of wildly different lengths without wasting KV memory; the conv state cache is the same idea applied to this architecture's short-convolution layers. Take both away and you have a working endpoint that has given up the two reasons vLLM exists. For a 1.7B model served at low concurrency that may be an acceptable weekend, not an acceptable production shape.

Why a 1.7B model needs kernel work at all

LFM3-1.7B is not a straightforward retune of the LFM2 family vLLM already serves. It is a twenty-four-layer hybrid with three layer types rather than two: 13 gated short-convolution layers, 5 sliding-window attention layers with a 256-token window, and 6 full-attention layers. The checkpoint's config spells the geometry out — conv_L_cache: 7, sliding_window: 256, a 128K vocabulary — and the vLLM issue's own list of differences adds QK RMSNorm, a per-head sigmoid attention output gate, sandwich normalisation, and partial RoPE (partial_rotary_factor: 0.5) on the full-attention layers, laid out in the same zero-tail shape Gemma 4 uses.

The number that broke the port is the seven. LFM2's short convolution is three taps wide; LFM3 widened it to seven. vLLM's Triton causal_conv1d kernels unroll a fixed set of widths, and as the tracking issue puts it: "The Triton causal_conv1d prefill kernel unrolls widths 2 to 4 and the decode kernel 2 to 6, so a width-7 model cannot run on CUDA today."

So the first PR in the stack is not a model at all. #64647, "[Kernel] Support width-7 causal conv1d", opened 30 October by abhijithneilabraham, touches two files and 186 added lines: it extends the prefill kernel from widths 2–4 to 2–7 and the decode kernel from 2–6 to 2–7, and makes both wrappers raise ValueError for anything outside that range. The PR's own description explains why the rejection matters as much as the extension: before the change, "a wider weight ran with no matching branch and returned wrong values." Silent numerical corruption is a worse failure than a refusal, and it is the kind of thing that only shows up on the model you happened to try.

One caveat deserves to travel with that PR. Its author states plainly that they have no CUDA machine: the CPU reference path passes 96 tests, the Triton kernels were checked by static analysis over the kernel AST, and the GPU validation is left to CI. That is an honest disclosure rather than a defect, but it means the single change every other LFM3 PR depends on has not yet been exercised on the hardware most readers will run it on.

Two implementations of the same text model

Within six days, two separate groups wrote native LFM3 support for vLLM. They are not variants of one patch; they are independent designs that happen to install the same architecture name.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)", opened 1 November by atmikshetty, is the conservative one: seven files, and by its own description it reuses ShortConv at width 7, Lfm2MLP, the LFM2 weight mapper and the existing proportional RoPE, changing no core components. It registers the model in the registry, adds it to the hybrid-model test set and the supported-models table, and — usefully for anyone who gets it running — documents the serving flags it validated with: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Its validation section reports 324 kernel tests passing on an A100-SXM4-40GB in BF16, registry and initialisation tests passing, and a log-probability comparison against the Hugging Face remote-code reference.

PR #65826, "[Model] Add LFM3-Text", opened 5 November by paulpak58 — who is Liquid AI — is the vendor's own version: ten files and 829 added lines, including its own config class under transformers_utils/configs/lfm3.py and its own test module. It was opened as "[Model] Add LFM3" and retitled the same day when the family was split into four stacked PRs: #65826 for text, #65827 for vision-language, #65828 for audio and #65829 for omni, each built on the one before it.

The two are not in conflict so much as in parallel, and the discussion shows the dependency mesh clearly. On the kernel PR, paulpak58 wrote on 4 November: "We have our own internal PRs for LFM3 models, but this is a clean addition we can back." On the community text PR, abhijithneilabraham suggested the merge may need Liquid's transformers work merged first — "I believe the merge of this PR requires the transformers PR from @paulpak58" — to which atmikshetty replied that Lfm3Config is not in a transformers release yet, so the branch "loads the config via trust_remote_code from the checkpoint, and execution uses the native vLLM model." That is the second gate most readers will not have thought about: even a merged vLLM PR needs a config class that ships somewhere.

On the transformers side the equivalent PR is #50322, "[Model] LFM3 Family: LFM3-Text", opened 3 November and still open, split out of a larger family PR. Its own note on the convolution matches the vLLM issue: the short conv is "torch-only in LFM3 (the Hub causal_conv1d kernels serve widths 2-4, LFM3 uses 7)".

Vision-language is duplicating too. Besides Liquid's #65827, an independent LFM3-VL PR (#65450, opened 3 November) is still open and depends on the community text PR. So there are, as of today, six open LFM3 PRs across two camps and no merged one.

What actually runs today

Strip out the speculation and the practical picture on 5 November looks like this.

• vLLM, native — not possible on a stock build. No Lfm3ForCausalLM in the registry, no LFM3 row in the supported-models table, and the PR that would add one is unmerged.

• vLLM, transformers backend — the documented workaround, using the checkpoint's bundled remote code and trust_remote_code. You lose paged attention and the conv state cache; you keep the OpenAI-compatible server.

• SGLang — the vendor's own server path. Liquid's launch post measures its throughput numbers on a single NVIDIA B300 in BF16 with SGLang, including 3.6 billion tokens per day at 1,024 concurrent requests. vLLM appears in that post only as the runtime competing models were served on.

• llama.cpp — the card refers to "LFM3-compatible llama.cpp builds", which is a real qualifier rather than boilerplate; Liquid's on-device figures are llama.cpp at Q4_0 with a 32K context.

• MLX — the separate vLLM-Metal project's 0.33.0 release notes list LFM3 text MLX checkpoints, behind --trust-remote-code. That is a different codebase from upstream vLLM and does not imply CUDA support.

• Hosted — Liquid's own API and playground. The card gives no rate card, so cost per token is not something you can budget from public material.

Two numbers put the self-hosting case in perspective. The weights are small enough that memory is not the constraint — Liquid claims about 1 GB at 4-bit — and the vendor says a 128K-token context costs roughly 1.6 GB of KV cache. The constraint is the serving stack, not the GPU.

What would change this, in order

The dependency chain is unusually clean, which makes the thing worth watching unusually specific. First #64647 has to merge, because every other LFM3 PR either includes that commit or is stacked on it. Then one of the two text PRs has to win review — the community one has the more complete validation record, the Liquid one has the author who also owns the transformers side. Then Lfm3Config has to land in a transformers release, or every deployment keeps passing trust_remote_code. Only after that does LFM3-VL-2B, LFM3-Audio-2B and LFM3-Omni-2B become realistic, and those sit behind further PRs that assume the text model is already in.

None of this should be read as a criticism of the pace. Nine days from a launch to a complete, tested kernel-plus-model PR stack is fast, and the fact that two independent teams produced working implementations in under a week says more about how close LFM3 sits to LFM2 than about any delay. But a model card is a compatibility claim, and the honest reading of LFM3-1.7B's today is "compatible with vLLM through the transformers backend", not "supported by vLLM".

If you need a small tool-calling model this week

LFM3-1.7B is an attractive thing to want. Its vendor-reported numbers are strong exactly where small models usually fail — 71.39 on BFCL V4, 80.36 on ToolSandbox, 96.66 on IFEval, 43.40 on SWE-bench Verified — against an overall average of 49.37 that Liquid puts ahead of its own LFM2.5-2.6B at 31.55. Those are the vendor's own evaluations, run by the company that built the model, with no independent reproduction and no Artificial Analysis entry that we could find as of today; treat the ordering as a hypothesis and the individual figures as claims. The companion caveat comes from the same source: the model card advises against agentic coding and complex multi-step reasoning, and the knowledge benchmarks agree with that advice — 63.37 on GPQA Diamond and 65.56 on RULER at 128K are not the numbers of a generalist.

So the decision is not really about the model. It is about whether you can afford to build on a serving path that is currently an open pull request. If you can run SGLang or llama.cpp, you can use LFM3-1.7B today and the vLLM question is academic. If your stack is vLLM by policy, you are choosing between the transformers backend's missing paged attention and waiting.

There is a third option worth naming for the workloads that cannot wait: route something else. OrcaRouter does not carry LFM3-1.7B — a check of our catalogue today returns more than 200 model ids and none of them Liquid's — so this is not a pitch to call it through us. It is the simpler point that an unmerged kernel PR is a bad single point of failure for a production path. Fronting a hosted model with one API and automatic failover costs you a config change, and lets you swap in LFM3-1.7B on the day its native support merges rather than the day you finish betting on it. If you are modifying the model rather than just calling it, our own LFM3-1.7B-abliterated release is a refusal-direction ablation of the same checkpoint, and it inherits precisely this serving situation.

The short version

LFM3-1.7B is out, small, and well suited to the single-turn tool-calling jobs it was trained for. Its vLLM support is being written right now, by two teams, on top of a kernel extension that has not yet been run on CUDA by the person who wrote it. Watch #64647 first — when the width-7 convolution merges, the rest of the stack moves quickly, and "works with vLLM" on the model card stops being a statement about remote code and starts being a statement about paged attention and batching. Until then, anyone quoting "day-one vLLM support" for this model is quoting something the repository does not yet contain.