Choose the LFM3 checkpoint around a task you can inspect

Liquid AI’s 27 October announcement describes a family spanning text, vision, audio and omni capabilities. The first decision is the actual checkpoint and task: a family-level announcement is not evidence that one downloaded model accepts every input type. Keep the model identifier in the pilot record. (Liquid AI)

Specify the job before the runtime

Choose one useful output that a person can inspect without guessing what success means. For example, a proposed pilot might extract an equipment reference and a reported symptom from fictional maintenance notes. Define the expected fields, what to do when a field is absent and how a reviewer will identify an unsupported addition.

That example is illustrative and has not been run. Its purpose is to keep the pilot narrow enough to learn from. A broad request such as “make our assistant local” bundles together interface work, model choice, language coverage, tool access and operational responsibility. Separate those decisions before spending time on deployment.

Read the specific card, including the caveat

The LFM3-1.7B card describes downloadable text-only weights and 256K combined context. It documents local agents, tools and coding guidance while discouraging agentic coding and complex multi-step reasoning for this checkpoint. Listed languages do not establish Swiss German quality. No Hugging Face Inference Provider is shown; that does not rule out other hosted access. (Liquid AI)

Use that distinction to narrow the first task. A documented capability can be a reason to investigate a model; it is not acceptance evidence for your application. If the intended job falls within the card’s discouraged uses, choose a different pilot scope or assess another model rather than silently discarding the caveat.

For a multilingual Swiss team, use examples from the actual operating language, including mixed terminology where that occurs. Make language-specific failures visible rather than reporting only one overall result. Choose the samples before comparing outputs, and retain a way to see which language or wording produced each failure.

Measure the workload that must stay local

Keep model weights, context, application state and concurrent work as separate lines in the resource plan. A compact file or a quantisation claim does not describe the total memory needed by the complete application. Define the longest intended input, expected output and simultaneous work before deciding whether a device is sufficient.

• Record the exact checkpoint and quantisation rather than only the family name.
• Choose a runtime build that explicitly supports that checkpoint and review its maintenance and dependencies before execution.
• Collect peak resource use and response time under the proposed workload, once a test is authorised and run.
• Include interrupted, malformed and oversized inputs in the acceptance design.
• Preserve a known configuration so that a later update can be compared on the same cases.

These are measurements to collect, not results from a KIURO benchmark. Manufacturer comparisons can inform questions for the pilot, but they do not provide the hardware budget or performance guarantee for a different task.

Download, hosted access and permission are separate checks

Decide whether the pilot requires local execution before comparing access routes. Record the supplier, model identifier, execution location and operating responsibility for each option. An unresolved access route is a dependency to investigate, not a reason to assume that another route has the same terms.

LFM Open License v1.0 includes redistribution conditions and a commercial-use limitation tied to a USD10 million annual-revenue threshold and its defined legal entity. Do not describe it as unrestricted Apache2-style permission. The precise threshold boundary and an organisation’s circumstances need their own review. (Liquid AI)

Keep a record of the intended operator, affiliated entities relevant to that review, whether a modified artefact will be distributed and who will resolve any licensing uncertainty. This article does not decide an individual organisation’s eligibility or provide a licence opinion.

A pilot needs a decision at its end

Set the next decision in advance: continue with the same scope, revise the task, investigate a different checkpoint or stop. The record should show the observed outputs, resource measurements, open limitations and the person accepting the result. No operating cost has been measured here; include hardware, integration, evaluation and maintenance effort in a real estimate.

If the task needs new application behaviour as well as model selection, take this bounded pilot record into a software and applied AI scoping discussion. It gives the discussion a concrete workload and evidence to investigate.