Liquid AI Releases LFM3: Choose One Workflow Before Fine-Tuning

Liquid AI’s release announcement introduces six models in roughly the two-billion-parameter class, derived from LFM3-1.7B-Base. The company says every model can be fine-tuned on a single GPU and presents notebooks for adapting text, vision, audio, and omni models. These are documented capabilities and vendor claims, not results we independently reproduced.

The lineup separates input and output needs. LFM3-1.7B handles text; LFM3-VL-2B accepts text, images, and video and produces text. LFM3-Audio-2B accepts text and audio and can produce text and speech. LFM3-Omni-2B combines visual and audio inputs with text and speech outputs.

The remaining two models, d1-2B and d1-omni-2B, target structured decisions. The first handles text, images, and video; the second adds audio. For a small team, this makes model selection an interface decision: determine what the application receives and what the next workflow step actually needs.

Our editorial recommendation is to start with the narrowest model that covers the workflow. An application extracting fields from existing text can begin with the text model. Receipt photographs call for evaluating visual input. Spoken requests suggest the audio model, while questions that require both an image and speech make the omni model relevant.

This distinction also applies to outputs. If the next step needs a category, extracted value, or score, evaluate a decision model alongside a generative model. If it needs a written explanation, the output requirements point elsewhere. Supporting more modalities does not establish better performance on your specific task.

For local agents, read the limitations alongside the positioning. The LFM3-1.7B model card explicitly says the model is not recommended for agentic coding or complex multistep reasoning because of its size. Its agent benchmarks should not become a blanket recommendation to replace a coding assistant.

The d1-2B model card describes typed answers produced in one forward pass without generating tokens. Supported questions include classifications, ordered scores, document values, quantity estimates, and object locations. Liquid AI describes the answers as calibrated and provides probability fields for relevant question types.

That creates a concrete evaluation candidate for ticket routing or document extraction. A proposed ticket pilot could ask for the responsible team and applicable topics, then compare those answers with human labels. Measure errors by category so a strong overall score does not hide repeated failures on uncommon requests.

The card itself instructs users to calibrate decision thresholds on their own data. It also says answers become less reliable beyond approximately 64K tokens of state, despite listing a 128K context length. Treat the supported context length and dependable task performance as separate questions. Include missing fields and ambiguous inputs in the evaluation.

Liquid AI reports that LFM3-1.7B outperforms LFM2.5-2.6B while using 35% fewer parameters. Its text model card supplies benchmark results and evaluation settings. Those results can help identify tasks worth investigating, but they do not establish accuracy for your documents, tools, or users.

The text card lists a 256K-token context window covering input and output. Liquid AI also says the text model takes about 1 GB at four-bit precision. Do not use that headline alone as a complete application memory budget: measure the selected runtime with realistic inputs, output lengths, and concurrent work.

Configuration matters when interpreting the evidence. The published text capability benchmarks use BF16 serving, while the edge inference comparison uses Q4_0 GGUF files in llama.cpp. A team choosing a quantized local checkpoint should evaluate that actual checkpoint and runtime. Our AI platform evaluation checklist offers a framework for tying infrastructure choices to workload requirements.

The announcement links fine-tuning examples for extracting JSON from messy documents, reading receipt photos, and mapping spoken commands to function calls. These examples make the intended specialization path concrete. The single-GPU statement, however, does not establish that every training recipe will fit whatever GPU your team already has.

Before training, record baseline results on representative examples and reserve a separate evaluation set. For document work, score required fields, incorrect values, missing information, and output validity. For spoken commands, score the intended function and its arguments separately. These are proposed evaluation criteria; we have not executed the notebooks.

Fine-tune only when the errors suggest a repeatable learning problem, such as terminology or formatting. Keep the evaluation set out of training and compare the adapted checkpoint with the original under identical conditions. Otherwise, improvements on familiar examples can obscure failures on new inputs.

A useful first pilot ends with a decision about one task. Record the checkpoint, precision, runtime, input preparation, output checks, and observed failures. Measure completion quality and elapsed time for the whole workflow, including preprocessing and any repeated attempts.

For tool use, inspect both the selected function and its arguments before connecting outputs to consequential actions. Our reliable AI workflow guide can help define acceptance criteria and failure handling around the model.

LFM3 merits evaluation when your application has a specific modality or decision requirement that the family addresses. Expand only after the chosen checkpoint meets your task criteria on representative inputs. The release supplies new candidates and adaptation examples; your own evaluation must establish whether one belongs in the application.