# Ollama 0.40.13 puts Liquid LFM3 audio on Windows: local STT/TTS that fits in 2 GB > Source: > Published: 2026-10-30 05:13:01+00:00 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): ``` python import requests def transcribe_chunk(pcm_bytes: bytes, model: str = "lfm3-audio") -> str: # Assumes you have already converted to the expected sample rate / format 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](https://talkaside.com/), a Windows app for job interviews and calls in another language. *Drafted with AI assistance from this project's code and logs.*