LFM2.5-Audio-1.5B Deployment Deep Dive: WebGPU, born, GGUF, and Ollama Compared

Forum topic · QianXun · 2026-07-25

Summary

A four-path deployment analysis of Liquid AI's LFM2.5-Audio-1.5B, an end-to-end speech-to-speech model composed of four heterogeneous sub-networks: a FastConformer audio encoder, an LFM2.5 backbone with hybrid gated short-conv and GQA layers, an RQ/depth-transformer with 8 audio codebooks, and a Mimi-compatible detokenizer producing 24 kHz waveforms. WebGPU deployment uses Liquid's official ONNX package of five separate graphs (encoder, embedding, LM decoder, vocoder depthformer, detokenizer) plus onnxruntime-web, q4-only in browsers, with a working demo in Liquid4All/cookbook. GGUF is the shortest path for local full-pipeline s2s but lives in Liquid's fork of llama.cpp via PR #18641 (~4,122 lines, 53 commits), with audio output still requiring split PRs such as #18645. Ollama has no audio output path and no library entry. The born Go ML framework would require at least six new operator classes (causal Conv1D, STFT/iSTFT, FastConformer block, RQ interleaved generator, Mimi detokenizer with ConvTranspose1d, LFM2 GGUF loader), making it a contribution effort rather than a deployment shortcut.

Key points

Model architecture: a four-component pipeline, not one model

Audio flow: microphone → mel frontend → FastConformer encoder (115M, from NVIDIA canary-180m-flash) → LFM2.5 backbone (1.2B, 16 layers = 10 gated causal depthwise short-conv with kernel=63 + 6 GQA, 32k context) → RQ/depth-transformer (8 codebooks, 2049×8 audio vocab) → Mimi-compatible detokenizer (LFM-based) → 24 kHz waveform.
Two generation modes: interleaved (text/audio tokens, real-time dialogue) and sequential (ASR/TTS).
License: LFM Open License v1.0; encoder code derived from NVIDIA NeMo (Apache 2.0).
Deployment difficulty stems from the four-piece pipeline; any runtime that can only host a standard LLM (Ollama, MLC, current born) can only run the central LM backbone.
Source: HF model card.

WebGPU deployment → ONNX with 5 separate graphs (official, ready to run)

Format: ONNX (5 independent graphs + external weights) + onnxruntime-web with WebGPU ExecutionProvider.
Official repo: LiquidAI/LFM2.5-Audio-1.5B-ONNX.
Graph sizes (q4, including external data): audio_encoder ~139 MB, audio_embedding ~134 MB, decoder ~1.22 GB, vocoder_depthformer ~187 MB, audio_detokenizer ~56.5 MB; plus embed_tokens.bin/json, mel_config.json, tokenizer.json. Quantization tiers: fp32, fp16, q4, q8.
Constraint: browsers only support q4 or fp16; q8 is server-only and unsupported by WebGPU EP (per Liquid ONNX deployment docs).
Total q4 weight footprint ~1.7 GB, fits within browser 4 GB WASM/VRAM caps; cache via Cache API/IndexedDB.
Requires Chrome/Edge 113+ with WebGPU enabled.
Ready-made demo: Liquid4All/cookbook → examples/audio-webgpu-demo (Vite + ONNX Runtime Web; ASR / TTS / Interleaved modes; npm install && npm run dev); also deployed on HF Spaces.
Export tool: Liquid4All/onnx-export (lfm2-audio-export one-command pipeline).
transformers.js supports LFM2 text but not the audio pipeline; the official demo hand-orchestrates the 5 graphs with onnxruntime-web.
Limitation: Interleaved mode currently plays after full generation; true streaming (per-frame playback) is on the official roadmap and requires manual KV-cache continuation, conv-state preservation, per-frame detokenize, and AudioWorklet playback.

born deployment → requires ≥6 new operator classes (source-code audit)

born-ml/born is a pure-Go, zero-CGO ML framework (v0.9.18, Apache 2.0), NOT a Rust Burn fork. Its "WebGPU backend" is native wgpu (Dawn/Vulkan) on desktop; browser inference is not mature.
Current born inventory: ~60 backend ops (MatMul, BatchMatMul, Conv2D, MaxPool2D, Softmax, Embedding, Gather, Cat/Chunk, Rsqrt, Where, etc.); nn modules include Linear, RMSNorm/LayerNorm, GQA (RepeatKV), SwiGLU, MHA, KVCache, RoPE, TransformerBlock; only models/llama; GGUF v3 reader with Q2_K–Q8_K, Q4_0, Q5_0, Q8_0 dequant; WebGPU ops limited to Add/Mul/MatMul/Softmax/activations/Transpose/Embedding/Gather/Conv2D/flash_attention.
Gaps for LFM2.5-Audio: no Conv1D, no ConvTranspose, no FFT/STFT; no conformer block; no relative-position attention; no LFM2 architecture (short-conv layers unrecognized); GGUF loader does not understand LFM2 tensor naming or mmproj/vocoder GGUFs; no multi-codebook interleaved sampler.
Six required additions:

InterleavedGenerator

Reference scale: llama.cpp needed 53 commits / +4,122 C++ lines (PR #18641) plus existing ggml conv/FFT infrastructure. Porting to born is comparable Go effort + new FFT library + WGSL shaders.
Verdict: a valuable open-source contribution (born lacks even lfm2 text arch); not a deployment shortcut. For quick Go-side usage, exec Liquid's prebuilt runner, or call ONNX Runtime via onnxruntime_go (requires CGO, conflicts with born's zero-CGO philosophy but is fine outside born).

GGUF support → official first-class, but in a Liquid fork of llama.cpp

Official GGUF repo: LiquidAI/LFM2.5-Audio-1.5B-GGUF — 4 components × 3 quantizations = 12 GGUF files (LM backbone, mmproj audio encoder, vocoder detokenizer, tokenizer) plus prebuilt runner binaries for each platform.
llama.cpp mainline status: PR #18641 [Do Not Merge] model : LFM2.5-Audio-1.5B — Draft, 53 commits, +4,122 lines, by Liquid engineer tdakhran. Adds llama-liquid-audio-cli and llama-liquid-audio-server; vocoder GGUF loaded with -mv.
Strategy: split into smaller PRs — #18607 (n_embd_out), #18601 (llama_memory_hybrid_iswa), #18645 (mtmd_audio_streaming_istft for streaming audio output), #19687 (audio tokenizer); ngxson handles llama-server voice-output API (TBD).
Audio input (ASR) is closer to mainline via mtmd; audio output / s2s currently requires the fork build.
Verdict: the shortest path to local full-pipeline s2s today (download prebuilt runner, no Python), but locked to Liquid's fork until the split PRs land.

Ollama → not viable for voice; weak for text

No model in Ollama library; Liquid's official account only ships text models (lfm2.5-1.2b-instruct, lfm2.5-350m).
Ollama added audio input in v0.20 (2026-04) but only for Gemma 4's audio_tower; FastConformer/mmproj-LFM unsupported.
No audio output path in the engine; s2s structurally impossible.
Forcing a GGUF via Modelfile FROM may load the LM backbone for text chat, but audio components are ignored/errored; no community reports of working voice.
Better alternatives: Liquid's prebuilt llama-liquid-audio-server (closest to an Ollama-like local HTTP service) → LM Studio (text only + external TTS) → LEAP SDK (Liquid's official mobile/edge audio path; Mac/Android/iOS Voice Assistant samples in cookbook).

Streaming voice-to-voice: mechanism and route fidelity

Interleaved generation runs an "n text tokens → n audio frames" loop; audio steps emit all 8 codebooks at once per depth step (not 8 sequential steps).
Mimi-compatible frame rate 12.5 Hz → 80 ms per waveform frame; detokenizer is causal LFM + iSTFT, frame-decodable, which is the structural basis for low first-packet latency.
Official claim: <100 ms end-to-end (4 s audio in → first sound, hardware unspecified); LFM2.5 detokenizer 8× faster on mobile CPU after INT4 QAT. Comparison: Moshi ~200 ms, Qwen2.5-Omni first-packet ~640 ms+.
Backbone detail (arXiv 2511.23404): 1.2B, 16 layers = 10 gated causal depthwise short-conv (kernel=63) + 6 GQA; conv layers have no KV cache, only a 63-step sliding window state — very cache-friendly on CPU/edge.
Fidelity by route:
Python reference (liquid-audio): generate_interleaved yields per token/frame — gold standard.
GGUF / custom llama.cpp: requires -mm (mmproj) + -mv (vocoder) + speaker pipeline; #18645 adds streaming iSTFT; high fidelity; degrades to ASR/text if vocoder not loaded.
WebGPU/ONNX demo: currently batch-generate-then-play; true streaming needs custom KV-cache continuation + conv-state preservation + per-frame detokenize + AudioWorklet; medium fidelity.
Ollama: no audio output; N/A.
born: depends on your interleaved sampler implementation.

Deployment decision tree

Local machine, fastest s2s: official GGUF + prebuilt llama-liquid-audio runner.
Browser/frontend, zero install: ONNX q4 five-graph + onnxruntime-web, clone cookbook demo and customize.
Want one-command Ollama: give up; fall back to llama-liquid-audio-server or use text-only lfm2.5-1.2b.
Mobile/embedded: LEAP SDK (official edge path).
Pure Go / born: expect to write 6 operator classes (Conv1D, FFT, ConvTranspose, interleaved sampler, …); treat as open-source contribution, not a deployment shortcut; for urgent use, exec Liquid's prebuilt runner.

Three-line summary

1. WebGPU needs ONNX, not GGUF — Liquid's five-graph q4 package ships with a working demo; browsers only accept q4/fp16. 2. GGUF is the shortest full-pipeline path, but "llama.cpp compatible" currently means "Liquid's fork compatible"; mainline arrival tracks split PRs like #18645. 3. Ollama and born are the same kind of "no" for voice — both runtimes only understand standard LLMs; the other three sub-networks have no home. Making born work means re-doing the +4,122-line C++ effort in Go.