Updated 11 hours ago
Liquid LFM3: choosing text, vision, audio and decision models for local AI

Liquid LFM3: choosing text, vision, audio and decision models for local AI

Liquid’s October 27 release separates six model variants by inputs and answer format. Downloadable weights, hosted access and commercial‑use conditions are different choices.

LFM3 is a family to choose from, rather than one model for every input

Liquid AI released LFM3 on October 27, introducing a family of open‑weight models for text, vision, audio and combined inputs. Its launch announcement describes six models around the two‑billion‑parameter range, derived from the same LFM3‑1.7B‑Base backbone. They are available through downloadable weights and Liquid’s hosted services.

The useful first decision is the application’s input and expected output. A text agent, a question about a video, a spoken conversation and an invoice‑routing result do not require the same model. Sharing a backbone does not make those variants interchangeable. Liquid also separates models that generate responses from decision models that return structured answers.

Compare the six variants by input and required result

Start with what the application receives, then decide whether it needs a conversational answer or a typed result. A question about a video and a spoken question about that video share visual material but have different audio requirements. Liquid describes the following six roles in its [October 27 release](https://www.liquid.ai/blog/lfm3). | Model | Input described by Liquid | Response format | Reader job to evaluate | | --- | --- | --- | --- | | [LFM3‑1.7B](https://www.liquid.ai/blog/lfm3) | Text | Text responses for conversation and agent work | A text‑only agent or specialized language task | | [LFM3‑VL‑2B](https://www.liquid.ai/blog/lfm3) | Images or video, with questions about the visual material | Answers about images or recordings | Ask about a photo or a clip without requiring its soundtrack | | [LFM3‑Audio‑2B](https://www.liquid.ai/blog/lfm3) | Text or audio | Text, speech or both | A spoken interaction or a question about an audio recording | | [LFM3‑Omni‑2B](https://www.liquid.ai/blog/lfm3) | Visual material together with audio and language | Text, speech or both, using combined visual and audio context | A video question whose answer depends on both pictures and sound | | [d1‑2B](https://www.liquid.ai/blog/lfm3) | Text and pictures | Typed answers such as extracted fields, regions and selected options | Extract an invoice field or select an applicable outcome | | [d1‑Omni‑2B](https://www.liquid.ai/blog/lfm3) | Decision inputs that also include audio | Typed decision answers | Route or check a spoken request | The decision variants specifically target typed answers. The table does not mean the conversational variants can never produce structured output: the release also describes tool calling in the audio and omni models. Choose the role that matches the task, then check the particular model and runtime before deployment.

Text, vision and audio have different interfaces

LFM3‑1.7B is the text option, which Liquid describes as supporting a 256K‑token context window and local agents. That context specification belongs to the text model; it should not be assumed for every member of the family. The release names tool‑using agent workflows, but connecting tools and granting access remain part of the application built around the model. Source: Liquid AI

LFM3‑VL‑2B takes visual inputs, including video, for questions about images or recordings. LFM3‑Audio‑2B accepts text or audio and can respond with text, speech or both. Those are different routes: a developer who needs spoken replies has a different requirement from one analyzing a silent recording. Liquid’s examples describe intended capabilities, rather than tests performed for this article.

LFM3‑Omni‑2B brings vision, audio and language together. The company describes spoken questions about images and video with accompanying audio. That makes it the relevant variant to investigate when a task depends on seeing and hearing the same material, instead of assuming a vision‑only model also handles its soundtrack.

Decision models target typed results instead of conversation

The remaining two variants are d1‑2B, based on the vision‑language model, and d1‑Omni‑2B, which also accepts audio. Liquid’s decision‑model description separates them from chat: an application supplies a situation and questions and receives typed answers.

The announced answer types include pointing to a region, extracting text, numbers or dates with source spans, estimating a value with a range, and selecting applicable options. A document‑processing application might need an extracted field and its location rather than a paragraph describing the document. A voice‑routing application adds an audio requirement, making the omni decision variant the appropriate one to assess.

The release describes probabilities and ranges, but those outputs do not independently establish how well calibrated a model will be for a new organization’s records. Developers still need to evaluate missing fields, incorrect extraction and uncertain decisions on their own representative inputs. No benchmark ranking or deployment‑quality claim is established here.

Downloading weights and using a hosted API are separate deployment choices

Liquid links the release to downloadable weights, its Playground and the Liquid AI API. Its models page distinguishes local builds from hosted access and GPU serving. Downloading a model means taking responsibility for the runtime and the resources it uses; calling a hosted endpoint is a separate service arrangement. Open weights do not mean that every deployment has no compute or service cost.

The same models page says downloading, running and fine‑tuning LFMs, including commercially, is free until a company passes $10 million in annual revenue. That is the vendor’s stated condition, rather than an unrestricted commercial‑use claim. The detailed pricing and licensing agreement was not reviewed for this article, so organizations should check the applicable terms before committing to a deployment.

For the deployment layer, OpenTools’ llama.cpp reference explains local model files, quantization and a self‑hosted API; the vLLM reference distinguishes serving infrastructure from model weights. For a method to evaluate a serving setup, the Time to First Token roadmap covers latency, load and cache behavior. These are background references, not a tested LFM3 configuration. The roadmap’s hands‑on exercises require GPU access and may involve paid compute.

AI‑generated conceptual illustration separating text, visual and audio inputs from prose and structured‑decision outputs. It is not LFM3 product UI, an actual model response or a diagram of its architecture. Original artwork by OpenTools Team, based on Liquid’s October27 announcement.

Share this article

PostShare

Related News