Liquid AI builds compact foundation models for local devices

Liquid AI develops foundation models designed for constrained hardware and local deployment. Its Liquid Foundation Models, or LFMs, are relevant when an application must work with limited memory, unreliable connectivity or information that should stay on a device. The decision is whether a chosen model and runtime can complete a narrow job reliably inside those constraints, rather than whether a small model can imitate every capability of a large hosted service.

01 / ProductModel weights, deployment tools and a commercial license

The current model library spans text, vision-language, audio and task-focused variants. It also marks older checkpoints as deprecated. A new implementation should choose a supported model for its input type and runtime, rather than copy an old example simply because it uses the LFM name.

Liquid’s FAQ distinguishes open weights from open source and describes direct downloads and LEAP customization. It says Liquid does not offer a general hosted API of its own, while mentioning playground access, third-party hosting and selected partner arrangements. This makes local deployment the clearest basis for the proposed workflow, rather than an assumed universal Liquid API subscription.

One documented option is LFM2.5-2.6B, a dense text model with native tool calling and a published 128K-token context window. Those specifications identify a candidate to evaluate. They do not mean every phone can use the full context affordably or that a tool call is automatically safe to execute.

02 / AudienceA fit when device constraints are part of the product

A field-service application, a private desktop assistant or an embedded interface may need a model to work when a network is unavailable. In those situations, local inference can remove a dependency on a remote request. The application still needs local documents, runtime support and a clear response when it lacks enough information to answer.

The less suitable starting point is a product that needs broad research over fresh online information but has no mechanism for supplying it. A model’s weights are not a current maintenance manual. Likewise, a compact model does not remove the work of organizing documents or defining what the assistant is permitted to do.

The Mistral blueprint offers a comparison across another model family and deployment ecosystem. The Hugging Face blueprint helps with the surrounding model distribution and collaboration layer. Compare candidates on the same device, task set and runtime settings; parameter count alone cannot establish the better user experience.

03 / WorkflowA proposed offline maintenance assistant with read-only tools

Imagine a proposed tablet assistant for technicians servicing one family of industrial pumps. Its job is to locate the right manual section, explain a diagnostic step and prepare a service note. It has no permission to operate equipment or change a maintenance record. This example is an implementation design, not a test or endorsement of Liquid AI for safety-critical operation.

Start with the device envelope: available memory after the main app loads, storage for the model and manuals, expected battery use and the longest acceptable pause. Include an older supported device in the sample. A prototype that works on a developer laptop can still be unsuitable for a technician using a hot tablet beside machinery.

Select a current text checkpoint and one supported runtime. Record the exact weights, quantization, chat template and generation settings. A model family name is insufficient for reproducing behavior because two packages can have different memory requirements and output quality. Treat a later runtime upgrade as a change requiring evaluation, even if the weights remain the same.

Prepare a versioned manual bundle with equipment identifiers, revision dates and section references. A local retrieval component should return the relevant passage and its provenance. The assistant can then answer from that material, while the interface lets the technician inspect the original instruction. If the equipment variant is unknown, the appropriate response is to ask for it.

Define read-only tools such as locating a manual section or finding a part number in an approved catalog. The model proposes a call; application code validates its name and arguments before executing it. Do not let arbitrary generated text become a shell command or an equipment action. Native tool calling simplifies a format boundary, but it does not replace permission checks.

Create examples that challenge the boundary: two pumps with similar names, a superseded manual, an unreadable serial number and a question whose answer depends on a measurement the technician has not taken. Include requests to skip a prerequisite. The assistant should preserve the missing information instead of converting a likely answer into an authoritative instruction.

Run the same cases with the network disabled, during repeated use and after the application has loaded realistic document context. Measure completion of the defined task, reference correctness, peak memory and user-visible waiting time separately. An answer that arrives quickly but cites the wrong pump revision is not a success. Long context should be tested only where it improves this task.

Liquid’s fine-tuning guide recommends checking prompts, templates, constrained decoding and tool descriptions before training. If a persistent failure remains, build task examples around that failure and freeze a separate evaluation set. Fine-tuning should teach the assistant how to use evidence or produce the required note format, not conceal a retrieval problem.

Finally, design an update and rollback process for both manuals and model packages. The service note should preserve which manual version supported the answer. If a new model improves routine explanations but becomes more willing to guess missing measurements, retain the earlier package until the regression is resolved. That is a product release decision grounded in the proposed evaluation, not a vendor benchmark.

04 / PricingThe license and the cost of operating locally are different

Liquid’s pricing page offers free commercial use below its stated revenue threshold and an enterprise route above it. The LFM Open License adds the actual conditions, including attribution and the treatment of derivatives. Open weights should therefore not be described as unrestricted Apache licensing.

The pricing summary and FAQ use slightly different language about contacting sales, and the threshold boundary deserves confirmation for a business near it. Review the license attached to the exact checkpoint and resolve the applicable legal entity before production distribution. A small product team inside a larger group should not assume its own project revenue is the relevant measure.

A zero model-license charge does not make the tablet workflow free to operate. Budget for integration, device testing, model distribution, document updates and support. A hosted alternative moves some of that work to a provider but introduces request charges and network dependence. Compare the complete operating arrangement for the actual workload, rather than token pricing against hardware in isolation.

05 / DistinctionsLocal inference changes the failure modes you must manage

The distinctive opportunity is that inference can happen beside the data and the user. In the maintenance example, an offline answer can remain available during a network outage. However, the application must still ensure that its local manual bundle is current, that logs are handled appropriately and that optional cloud features do not send information elsewhere.

Liquid’s deployment overview names runtimes across CPU, GPU and other device environments. Treat that breadth as a set of integration options, not a guarantee of equal support for every model or feature. A vision or audio model can require a different runtime path from the text checkpoint selected for the pilot.

The useful tradeoff is specialization. If the assistant’s job is limited to a known equipment family, the team can measure success in detail and reject unsupported answers. Expanding immediately to arbitrary industrial questions would make it harder to tell whether a failure comes from missing documents, retrieval, model capability or the interface.

06 / QuestionsCheck the actual device and distribution boundary

Does the selected runtime support the model’s tool format and the features the application needs? Validate a representative call and an intentionally malformed one. The application should reject unsupported output cleanly and present a useful fallback, instead of leaving the user with a stalled agent loop.

What happens when the model has insufficient evidence? Test the assistant on an absent manual and a conflicting revision. The desired behavior may be to show the retrieved passage, explain the uncertainty and ask the technician to consult the approved source. Fluent uncertainty is useful only if the product does not subsequently perform an unjustified action.

Can the company keep operating under the same license as it grows or changes ownership? Resolve the commercial terms before distributing a model widely across customer devices. Also decide how old packages will be retired. A downloaded model is a durable software dependency whose lifecycle needs an owner, even when no recurring API invoice arrives.

07 / DecisionChoose a measurable local task before choosing a model size

Liquid AI is a credible candidate when running a model locally is part of the product requirement. Start with a narrow workflow, a supported checkpoint and a real device envelope. The first milestone should demonstrate that the assistant can use the right evidence and fail appropriately when that evidence is missing.

For the maintenance example, useful completion means a technician reaches the correct manual section and prepares a traceable note without an unsupported action. Once that behavior holds across realistic conditions, the team can consider fine-tuning, multimodal inputs or broader equipment coverage with a clear baseline.