LiquidCodec makes speech tokens easier to predict, not just faster to decode

LiquidCodec tackles a small but consequential part of a voice model: turning sound into tokens and turning predicted tokens back into sound. Liquid AI's new technical account describes a roughly 74-million-parameter codec designed around streaming speech and efficient local execution. Its importance lies in the work around the language model, where delays can accumulate even when the model itself is small.

The codec already underpins LFM3-Audio-2B and LFM3-Omni-2B. This publication explains that component and its evaluation; it should not be mistaken for the launch of a complete new voice assistant.

A compact representation has to be learnable

A conventional reconstruction test starts with a recording, encodes it and then decodes it. The result can be compared with the original. A speech-generation system has a harder job: its language model must predict suitable audio tokens from text or other context, without first encoding the exact recording it wants to produce.

That creates two objectives. The representation should preserve speech faithfully, and it should be practical for another model to predict. Improving the first does not automatically improve the second. A codec can reproduce its own encoded input well while giving a generative model an awkward sequence to learn.

Liquid AI uses grouped finite scalar quantization. In plain terms, it splits features into groups and rounds their values into discrete choices. The company contrasts this with a residual process in which each successive codebook represents error left by the preceding ones. Reducing that sequential dependency makes parallel prediction of groups possible; it does not mean the entire conversation runs without dependencies or delay.

Eighty-millisecond frames do not mean an eighty-millisecond assistant

The model card specifies 24 kHz mono speech, 12.5 frames per second and 12 tokens per frame, at approximately 1.65 kbps. A frame therefore represents 80 milliseconds of audio. That is the unit of representation, not a measured end-to-end response time.

A conversational application still has to capture input, decide when to respond, run its other models, generate tokens and play audio. Network access may add another stage if the application uses it. A faster codec reduces one part of that chain; it cannot establish the latency of every application built around it.

Liquid AI reports encoding at about 361 times real time and decoding at about 87 times real time using FP32, a single CPU thread and an Apple M4 Max MacBook Pro. These are the developer's measurements on that configuration. The decoding figure means the codec processes audio faster than playback under the stated test, not that the full assistant answers a question 87 times faster.

The comparison is useful because it holds other parts still

For its text-to-speech experiment, Liquid AI says it held training data, architecture and compute budget constant while changing the codec representation. It used 101,000 hours across six languages and three generation seeds at evaluation. That design tries to isolate the contribution of the codec rather than comparing unrelated finished assistants.

The company reports the strongest naturalness score on all eight evaluated test sets, but the best word or character error result on only four. That split is informative. Naturalness and intelligibility are different measures, so the results do not support a claim that LiquidCodec wins every quality test. Nor are developer-run metrics a substitute for independent listening tests across accents, languages and devices.

The released model is explicitly trained and evaluated for speech. The card says music, singing and environmental audio have not been evaluated. It also separates the standalone BF16 repository from quantized decoders bundled into the LFM3 Audio and Omni GGUF packages; they are not described as separate standalone quantized codec downloads.

For readers following local AI systems, the consequential idea is that model size alone does not determine a good voice experience. The representation between components can make their work easier or harder. LiquidCodec's strongest contribution is a concrete attempt to improve that handoff, with enough published conditions to see where the speed claim ends.