Run LFM3 on Linux with Ollama (voice included)

01what actually shipped

Until Wednesday night, Liquid AI's LFM3 family checked your chip at the door: ollama served the models to Apple silicon and told every other machine to move along. ollama v0.40.13 (2026-10-28, tagged 19:55 UTC) takes the rope down — lfm3, lfm3-audio and lfm3-omni now pull and run on Linux and Windows, plain CPU boxes included. Hours earlier the same day, llama.cpp kept its young versioned lane moving with v0.8.0: the same LFM3 family, verified against Liquid's reference implementation, plus a streaming-audio API and /v1/realtime + /tts server endpoints.

Three doors, one family. The library page splits it clean:

The claim sentence, if you only lift one: v0.40.13 is the first ollama release where a no-GPU Linux box can run a Liquid voice model at all.

02run it in three commands

The version gate is the only trap. LFM3 support landed in 0.40.13 — anything older greets you with a model-not-found, which reads like a broken pull and isn't.

$ ollama --version
ollama version is 0.40.13
$ ollama pull lfm3
$ ollama run lfm3 "Reply with the single word: ready"

verify: the pull lands 1.1 GB on disk and ollama list shows the 1.7b tag. Verified on 2026-10-29 inside the bench VM below — if your pull runs bigger, you grabbed a bf16/nvfp4 tag by accident; drop back to plain lfm3:1.7b.

Same shape for the voice pair — ollama pull lfm3-audio and ollama pull lfm3-omni — with one honest caveat in section 04.

03the CPU rung, benched

Ran the 1.7b rung on a throwaway 4-thread QEMU-KVM VM (8 GB RAM, Arch, ollama 0.40.13 from the official release archive, CPU-only, default sampling). Fixed prompt — classify a crash ticket, one word. Cold load, then warm repeat, the raw API receipts verbatim:

$ # cold — first call after pull
{"model":"lfm3:1.7b","load_ms":2326837325,"prompt_eval_rate":null,"eval_count":866,"eval_rate":null,"total_ms":53533988331,"response":"Bug"}
$ # warm — second call, model still resident
{"model":"lfm3:1.7b","load_ms":530219,"prompt_eval_rate":null,"eval_count":589,"eval_rate":null,"total_ms":34362526621,"response":"Crash"}

Read the receipt with the units ollama actually returns (durations in nanoseconds, whatever the field names imply): cold load 2.33 s, warm load 0.53 ms — it never left RAM. The API's own rate fields came back null both runs, so the rate is computed by hand: 866 tokens over the 51.2 s it spent generating, then 589 over 34.4 s — ~17 tok/s both times, steady. For a 1.2 GB model on four CPU threads, that's honest work.

Now the wound: count the eval tokens. 866 and 589 tokens, for answers of one word. Whatever the model does between your prompt and that "Bug", it bills every step of it at 17 tok/s — that's your 34–54 seconds. If you're classifying tickets at volume, the per-ask wall-clock is the number that matters, and it is 30–50× the word count you asked for. Plan sizing around it.

The tag page also lists 1.7b-bf16, 1.7b-mxfp8 and 1.7b-nvfp4 — I'd call them the Apple-rope quants: formats tied to Apple silicon and GPU stacks. On the d3 family last weekend those exact formats refused to load on CPU ("this model requires MLX support"). Expect the same wall here; the Q4 rung is the CPU rung. (Expectation, not a fresh test — the bench pulled the default tag.)

04the voice models, honestly

Pulled lfm3-audio:2b (1.7 GB) and probed it text-side — what loads, what answers, before anyone promises you a talking machine:

$ # same ticket prompt, one word
{"model":"lfm3-audio:2b","load_ms":2342981058,"prompt_eval_rate":null,"eval_count":288,"eval_rate":null,"total_ms":19045284554,"response":"File Size"}
$ ollama ps
lfm3-audio:2b    3327c1a06755    1.6 GB    100% CPU     4096       llamacpp

Measured: it loads (2.34 s), it holds 1.6 GB at 100% CPU, and it answers a plain text prompt — the same crash ticket, classified "File Size". What this post does not carry: a real audio-in/audio-out receipt — a microphone clip transcribed, a WAV spoken back, timed. The release notes say TTS and the omni pair now run on Linux; llama.cpp v0.8.0's /v1/realtime + /tts endpoints are the lanes where that test lives. The bench that proves it ships when the bench has run — not before.

lfm3-omni:2b does speech-to-speech end-to-end at 2B parameters — a smaller download than one Chrome tab's afternoon memory appetite.

05worth your disk

Yes — for 1.1 GB of disk and 1.2 GB of RAM, a no-GPU Linux box now runs Liquid's text model at ~17 tok/s on 4 threads, and the voice pair is one pull away. That sentence was false on Tuesday. Wednesday's release notes wrote it, Thursday's bench signed it — with the asterisk the notes skipped: one-word answers bill 500–900 tokens, so a single classification costs about half a minute warm. Speed is fine; the hidden per-ask tax is the number to size against.

If you came from the d1-vs-d3 decision-model comparison: same box, same pattern — the usable rung is small, the big formats stay behind the Apple rope. If you came from the CPU bench ledger: the ladder discipline holds, and the voice ladder is next.

The missing receipt is real audio through the API — clip in, WAV out, timed. It runs on the same throwaway VM as this one. When the numbers exist, they land here.