Ollama 0.40.13 為 Linux 和 Windows 加入 Liquid AI LFM3 音訊模型支援

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.”

Why this is interesting for live audio pipelines

Most production STT still routes through a cloud endpoint. That is fine until you care about:

• Round-trip latency when the speaker is on the other side of a WebSocket and your capture path is already adding 20–40 ms of WASAPI buffering.
• Privacy: the raw PCM never leaves the box.
• Cost when you are doing continuous transcription for hours of interview or meeting audio.
• Offline / degraded-network behavior.

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.

Quick start on Windows

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:
    # 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.

Tradeoffs versus larger speech LLMs

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:

• Accuracy on noisy, accented, or domain-specific speech will lag specialized larger models and commercial streaming APIs. Expect to hybridize.
• Speaker diarization and rich structured output are not the primary design goal of the 2B audio checkpoint. You still need a separate diarizer or post-processing if the call has more than two people.
• Real-time factor on CPU is usable for short chunks but will not match a CUDA-accelerated larger model or a dedicated streaming endpoint that returns partials in ~100 ms. Measure on your hardware.
• License is Liquid’s open license, not a pure Apache/MIT. Read it if you plan to ship a product.

For a Windows call assistant the interesting architecture is therefore layered:

1. WASAPI loopback or microphone capture + low-latency VAD (Silero or a tiny local model).
2. Local LFM3-audio (or Parakeet GGUF, or faster-whisper) for the first transcript and language ID.
3. Optional cloud escalation for the high-confidence or high-stakes segments.
4. Local TTS (Phonon, LFM3-audio, or another small model) only when you need to speak a reply back.

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.

What still has to be built

Ollama giving you the model is the easy part. The hard parts remain:

• Stable low-latency audio capture on Windows that survives device changes, exclusive-mode conflicts, and screen-share sessions.
• Turn-taking that does not cut the speaker off or wait forever.
• Handling code-switching and mid-sentence language changes without resetting the whole pipeline.
• Keeping the UI responsive while the model is generating.

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.