On 28–29 October 2026 Ollama shipped v0.40.13 and explicitly added Linux and Windows support for Liquid AI’s LFM3 family. That includes lfm3-audio and lfm3-omni, the variants that do speech recognition, translation, and text-to-speech across roughly 18 languages inside a ~2B parameter envelope.
The text-only checkpoint is already tiny (around 1.1 GB at Q4_K_M). The audio variants add a projector or audio encoder and still land in the 1.5–2.4 GB range depending on quant and runtime. For a Windows desktop that already runs an overlay or a call assistant, that is the difference between “needs a dedicated GPU and 16 GB VRAM” and “runs on the same machine as the rest of the app.”
Most production STT still routes through a cloud endpoint. That is fine until you care about:
A 2B speech model that can be pulled with one command and served on localhost changes the design space. You can keep a local model for the first pass (VAD + rough transcript + language ID) and only escalate to a larger cloud model when confidence is low or the domain requires specialized jargon.
Ollama’s release notes are short and factual: “Liquid AI’s LFM3 models, including text-to-speech in lfm3-audio and lfm3-omni, now run on Linux and Windows as well as Apple silicon.” The practical implication is that the same GGUF-ish workflow that previously forced you onto llama.cpp or an Apple-only MLX path now works through the Ollama HTTP API on a Windows box.
Update Ollama (installer or ollama service), then:
ollama pull lfm3-audio
ollama run lfm3-audio
For the omni variant that can take text, image, or audio and emit text or speech:
ollama pull lfm3-omni
ollama run lfm3-omni
The library page documents 16 kHz input for audio and 24 kHz output for speech. Context is 32K tokens for the audio models (far less than the 256K text-only checkpoint). That is plenty for a rolling transcript window of a few minutes, but not for dumping an entire two-hour recording in one shot.
If you are already talking to Ollama from Python for chat completions, the audio path is still young. The OpenAI-compatible /v1/audio/transcriptions and /v1/audio/speech endpoints are the intended surface; real-time bidirectional streaming is still catching up in most local runtimes. For a first integration you stream short chunks (1–4 s) after VAD, get the partial or final text, and decide whether to re-prompt a larger model.
A minimal client sketch (not production-ready):
import requests
def transcribe_chunk(pcm_bytes: bytes, model: str = "lfm3-audio") -> str:
files = {"file": ("chunk.wav", pcm_bytes, "audio/wav")}
data = {"model": model}
r = requests.post("http://127.0.0.1:11434/v1/audio/transcriptions", files=files, data=data, timeout=10)
r.raise_for_status()
return r.json().get("text", "")
You still own the capture, the VAD, the resampling, and the decision of when a turn is complete. The model just turns the audio into text (or speech) locally.
A few days earlier NVIDIA released Nemotron 3.5 Transcribe, a 30B-A4B speech LLM that can do long-form, multi-speaker, instruction-controlled transcription in 40 languages. That model is impressive on the Open ASR leaderboard, but it is not a 2 GB drop-in for a live Windows process. The LFM3 audio checkpoints are the opposite end of the spectrum: small enough to keep resident, fast enough on CPU or a modest GPU, and explicitly aimed at on-device agentic use.
Tradeoffs you will hit:
For a Windows call assistant the interesting architecture is therefore layered:
That is exactly the shape of the problem Talkaside solves on the Windows side: keep the capture path tight, the overlay out of screen-share, and the language barrier manageable without forcing every millisecond of audio through a remote API.
Ollama giving you the model is the easy part. The hard parts remain:
Small local models lower the cost of experimenting with those pieces. You can iterate on the capture and VAD logic without burning API budget, then plug in a stronger remote model only where it actually moves the needle.
If you are already running Ollama on a Windows machine for coding agents, pulling lfm3-audio is now a one-line experiment. The resulting local STT/TTS path is not a replacement for every cloud endpoint, but it is finally small and cross-platform enough to be part of a real desktop audio pipeline instead of a research curiosity.
I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.