ollama pull lfm3 on my lab VM got me this:
Error: pull model manifest: 412: The model you are attempting to pull requires a newer version of Ollama that may be in pre-release.
Liquid AI launched LFM3 today (blog post, X post at 10:07 AM PT) and Ollama announced it at 11:25 AM PT: "LFM3 from @liquidai is on Ollama! ... Text model fits in about 1 GB at 4-bit ... 256K context window ... Available to run locally." The blocker turned out to be the runtime. The only Ollama release with LFM3 support is a pre-release, and it is Apple hardware only. My VM runs Linux, so Ollama stayed at 0.40.10 throughout. llama.cpp merged LFM3 support the same morning, so I built that instead and ran the official GGUF on the old Xeon.
What Liquid AI announced
Everything in this section is a vendor claim, from the LFM3 blog post and the Hugging Face card.
Six models come from one LFM3-1.7B-Base backbone, all around the 2B class: the LFM3-1.7B text model, LFM3-VL-2B for vision with video input, LFM3-Audio-2B covering 18 languages, LFM3-Omni-2B, and two decision models, d1-2B and d1-Omni-2B. Weights are open on Hugging Face under the "LFM Open License v1.0".
Per the blog, the text model has 24 layers: 13 gated short convolutions (kernel 7, up from 3 in LFM2), 5 sliding-window attention layers with a 256-token window and 6 global attention layers, with head-wise sigmoid gated attention, partial RoPE on the global layers and a sandwich norm. Vocabulary is 128K, pre-training covered 22T tokens and context is 256K.
On performance, Liquid claims LFM3-1.7B outperforms LFM2.5-2.6B with 35% fewer parameters, and that the text model fits in about 1 GB at 4-bit. In its on-device test (llama.cpp, Q4_0, 32K context), it was "decoding 1.8 to 2.8 times faster than the next one" across their three devices. On memory, the claim is "a full 128K-token context needs 1.6 GB of KV cache, against 4.3 GB for Qwen3.5-4B and 5.6 GB for MiniCPM5-2B." Their benchmark table compares against Qwen3.5 at 4B and 9B:
| Benchmark (Liquid AI) | LFM3-1.7B | Qwen3.5 4B | Qwen3.5 9B |
|---|---|---|---|
| BFCL V4 | 71.39 | 55.12 | 62.83 |
| IFEval | 96.66 | 92.52 | 92.08 |
| GPQA Diamond | 63.37 | 75.76 | 80.40 |
| SWE-bench Verified (OpenCode) | 43.40 | 41.20 | 51.20 |
| RULER 128K | 65.56 | 84.63 | 87.11 |
Liquid's own text says larger models still win on agentic coding and knowledge, and the GPQA and RULER rows agree. There is also a partner number from MacPaw that Liquid quotes: on 65 macOS agent tasks, 64% task success against 48% for Qwen3.5-2B, with 58% fewer tokens. Same vendor-claim status.
Why Ollama stayed at 0.40.10
The VM runs Ollama 0.40.10, same as the recent CPU posts. The latest stable is 0.40.11, released Oct 23, and it does not include LFM3 either. The only release that does is v0.40.12-rc1, a pre-release published Oct 26 at 5:07 PM PT. Its notes: "lfm3 and d1 2b are supported on Apple hardware in rc1. Support for Linux/Windows coming soon."
That settled it. Running the official upgrade script would move the VM to stable 0.40.11, which has no LFM3, and installing the rc on this Linux box would gain nothing either, since its support is Apple only. Ollama was not upgraded. After all the testing below, the 18 models already on the box were still listed. The library page tells the same story from the other side: latest is 1.7b-nvfp4 (MLX, 1.7 GB), alongside 1.7b-mxfp8 (2.1 GB) and 1.7b-mlx-bf16 (3.5 GB). Every listed tag is an MLX build.
Building llama.cpp instead
llama.cpp merged LFM3 support in PR #31252 at 9:06 AM PT on launch day. No tagged llama.cpp release contained it when I tested, so I compiled master at commit 338fce651, CPU only with an AVX build because this Xeon has AVX but no AVX2, and ran it from a user folder with no system install. Keep that in mind for the numbers: this is a self-built snapshot of master, with none of the soak time a tagged release gets.
The hardware is the LLMBits lab VM, built in my home lab on Proxmox: a Xeon E5-2670 with 8 vCPUs, 16 GB of RAM and no GPU, the same box from the Ollama install post and the tiny model CPU shootout. I stopped the Docker containers during timed runs and restarted them after.
Model files came from the official LFM3-1.7B-GGUF repo, which carries BF16, F16, Q8_0, Q6_K, Q5_K_M and Q4_K_M plus a QAD-Q4_0, which Liquid says is Quantization-Aware Distillation, trained to recover accuracy lost to Q4_0. The README carries one line that matters: "Requires an LFM3-compatible llama.cpp build". I tested QAD-Q4_0 (a 1.05 GB file) and Q4_K_M (1.10 GB). Baselines were the exact GGUF files behind the VM's existing Ollama models (qwen3:1.7b, qwen3.5:2b-q4_K_M, gemma4:e4b-it-q4_K_M), loaded in the same llama.cpp build.
llama-bench on the Xeon (measured)
Measured by me with llama-bench, 8 threads, 2 reps, numbers in tok/s:
| model | size GB | prompt pp512 | generate tg128 |
|---|---|---|---|
| LFM3-1.7B QAD-Q4_0 | 1.04 | 49.6 | 19.2 |
| LFM3-1.7B Q4_K_M | 1.09 | 85.4 | 22.2 |
| Qwen3 1.7B Q4_K_M | 1.35 | 46.5 | 12.8 |
| Qwen3.5 2B Q4_K_M | 1.26 | 84.4 | 18.6 |
| Gemma 4 E4B Q4_K_M | 5.48 | 30.1 | 7.35 |
Two reads. LFM3 Q4_K_M tops the table in both columns, and it roughly triples Gemma's generate rate from a 1.09 GB file next to Gemma's 5.48 GB. The QAD-Q4_0 file, though, was slower than Q4_K_M here, on prompt and generate both. Liquid measured its on-device numbers at Q4_0 on different hardware than this box, so I'd read that as an AVX-only result rather than evidence against their numbers.
Runtime caveat: earlier LLMBits CPU posts measured through Ollama. Gemma 4 E4B made 3.51 tok/s under Ollama 0.40.10 in the Nemotron Bolt post and 7.35 here under llama-bench. Different runtime and different method, so treat this table as its own comparison set.
KV cache, measured
One vendor claim I could check directly. llama.cpp prints a memory breakdown, and with f16 KV and one sequence, LFM3 at the full 131072-token context allocated 1536 MiB of global KV, plus 7.5 MiB for the sliding-window layers and 0.6 MiB of conv state. That is the vendor's 1.6 GB, seen on my own run. At 32K the KV drops to 384 MiB, and the projected host total (weights, KV and compute) came to 1688 MiB at 32K and 2936 MiB at 128K.
The wrinkle is Qwen3.5 2B. It gave identical KV numbers, 384 and 1536 MiB (it also has 6 full-attention layers), plus 19 MiB of recurrent state, projecting to 2145 MiB at 32K and 3393 MiB at 128K. So Liquid's comparison names Qwen3.5-4B and MiniCPM5-2B, while the 2B Qwen matches LFM3 on KV. The older dense Qwen3 1.7B is the one that pays for its design: 28 attention layers, 3584 MiB of KV at 32K and a projected 5223 MiB total. On a 16 GB VM all three fit at 32K. At 128K, LFM3 and Qwen3.5 2B both stay under 3.4 GB projected, and LFM3 is the smaller of the two by about 450 MiB.
Five tasks through llama-server (measured)
Speed and memory aside, I ran five small prompts through llama-server with the chat template, 32K context and thinking on as shipped: call a get_weather tool for Tokyo in celsius, write three bullets under 8 words each about SSH keys, work out how many access ports are in use on a switch with 48 ports, 7 uplinks and 12 disabled (correct answer 29), extract JSON host and ip from "core-sw1 answered ping from 10.20.0.2 in 3 ms", and write one sentence on what BGP is.
LFM3 QAD-Q4_0 ran with the card's recommended general sampling (temperature 0.1, top_k 50, repetition_penalty 1.1) and a 768-token cap, and finished all five correctly. Qwen3.5 2B got the same settings first, then a fairness rerun with its own Ollama defaults (temperature 1, top_p 0.95, top_k 20, presence_penalty 1.5) and a 2048 cap:
| task | LFM3 QAD-Q4_0, 768 cap | Qwen3.5 2B, same settings | Qwen3.5 2B, own defaults, 2048 cap |
|---|---|---|---|
| get_weather for Tokyo | correct, 6.0 s | correct, 10.4 s | correct, 11.2 s |
| SSH bullets | correct, 22.2 s | hit cap while thinking | hit 2048 while thinking, about 144 s |
| switch port math | correct ("29"), 30.3 s | hit cap while thinking | hit 2048 while thinking, about 144 s |
| JSON extraction | correct, 9.1 s | hit cap while thinking | correct, 42.6 s (660 tokens) |
| BGP sentence | correct, 10.3 s | hit cap while thinking | correct, 107.6 s (1599 tokens) |
What slowed Qwen3.5 was thinking length. Forced onto LFM's sampling, it burned the whole 768-token cap on four tasks without answering. On its own defaults it answered three of five, and the BGP answer took 1599 tokens, though the sentence was clean when it landed. LFM3's BGP answer was correct but awkwardly worded: "BGP (Border Gateway Protocol) stands for the inter-network routing protocol used to exchange routing information between different autonomous systems". Server peak memory (VmHWM) was 1.57 GB for LFM3 and 2.14 GB for the Qwen3.5 rerun.
Scope caveat: five prompts, one run each. This is behavior I saw, far too small to call a benchmark.
What I'd do
Linux users: leave Ollama on stable for now. Upgrading to 0.40.11 adds no LFM3, the rc1 notes themselves say Linux support is coming, and all the lfm3 library tags today are MLX builds. If you want the model this week, build llama.cpp master as above, pick the Q4_K_M on an older AVX-only CPU since the QAD-Q4_0 was measurably slower here, and remember that a master snapshot moves daily. A tagged llama.cpp release with LFM3 will be the calmer path.
Mac users: this pre-release is aimed at you. Per the rc1 notes, lfm3 and d1 2b are supported on Apple hardware in v0.40.12-rc1, so installing that pre-release is the route on a Mac. I did not test the Mac path for this post. The listed tags run 1.7 to 3.5 GB. If you would rather stay on stable, watch the Ollama releases for a build that adds Linux and Windows support; the rc1 notes give no date.
