LFM3: a small AI for a specific job

Sorting a message, reading a receipt photo and drafting a reply do not necessarily need the same assistant. With LFM3, announced on October 27, Liquid AI offers several small models to choose from, with downloadable files so you can run them yourself. The practical possibility is AI closer to your data, provided you give it a clearly defined job. Liquid AI announcement.

One model, one job

Think of a toolbox: you pick a screwdriver for a screw, even if a bigger machine could do the job too. LFM3 follows that approach with versions for text, images, voice and decisions. The supplier also provides examples for adapting the models to your own data using a single graphics card. These are components to build into an application, rather than a finished app you can simply open. Family overview.

For text, LFM3-1.7B targets uses including local assistants and answers in a required format. Its documentation lists French among its languages, but advises against autonomous software development and complex reasoning across multiple steps. Small does not mean universal. If you need to extract an order number, start there before handing over the entire order process. Text model documentation.

Reading an image takes a different version

LFM3-VL-2B accepts text, images and video. Liquid AI describes uses including reading documents, charts and application screens. However, its documentation advises against extended conversations and complex reasoning: examining an image does not guarantee the ability to carry out an entire investigation. Vision model documentation.

One possible experiment would be a first reading of a receipt, followed by checking every amount against the original. Keep difficult examples too: blurry photos, cropped documents and missing fields. A demonstration using a tidy document does not answer those questions.

Sorting rather than chatting

The d1-2B version targets a different step: classifying a request, extracting a value or choosing between options. It returns structured answers with probabilities, rather than a conversation. Its documentation says decision thresholds should be calibrated using data from your own use case. Decision model documentation.

For a support team, you could test routing messages to delivery or billing. Set up a review queue for ambiguous requests instead of forcing every message into a category. A routing mistake should be visible and correctable before it triggers the next action.

The real test happens inside your application

These sources describe the supplier’s announcement and evaluations. They do not independently validate the tool you might build. Our reading is that the useful starting point is a small, observable action with an answer someone can check.

Prepare a set of documents whose correct answers you already know. Compare mistakes, waiting time and the corrections needed on the intended machine. If keeping data local is your aim, also check where the application sends its logs and files. The model is only one piece: the document’s entire journey determines what actually stays with you.