LFM3-1.7B

Research checked 6 November 2026. Publisher claims and third-party trials are identified separately; this page is not an AIDreamHub hands-on benchmark.

A bounded local component, not a universal assistant

LFM3-1.7B is a 1.73B post-trained text model built for local agents and specialised applications. Its 24-layer tri-hybrid design combines short convolutions with sliding-window and global attention. The card lists a 256K input-plus-output context and 16 languages, but those specifications are not guarantees for every task or device.

A practical first use is routing a known request to one of a few tools, extracting fields into a strict schema or answering only from supplied material. The publisher explicitly does not recommend it for agentic coding or complex multi-step reasoning. A narrow component can be useful without pretending to replace a larger general model.

Official project page captured by AIDreamHub; not a locally run product.

Memory headlines need a workload beside them

The advertised roughly 1 GB at 4-bit precision describes a compact deployment profile, not the memory cost of every 256K conversation. Context buffers, runtime and tool descriptions also consume resources. BF16, FP8, NVFP4, GGUF, MLX and ONNX are deployment options, not interchangeable binaries.

Choose the package for the actual OS and accelerator, then measure a realistic prompt and output budget. Keep model version and quantisation fixed. A short extraction fitting easily in memory does not establish long-context speed, tool reliability or privacy of a remote application using the model.

How to use: start with a schema and a small tool set

The model card provides a Transformers path with trust_remote_code. Inspect and pin the downloaded implementation before enabling it, and use an isolated environment. The example below demonstrates bounded text generation; it does not install an office agent or grant tools automatically.

For extraction, define required keys, types and null behaviour, then validate the parsed result outside the model. For tools, allow-list names and arguments, enforce permissions in the executor and return concrete errors. Begin with two harmless tools rather than exposing an entire workstation.

from transformers import pipeline
generator = pipeline("text-generation", model="LiquidAI/LFM3-1.7B", trust_remote_code=True)
messages = [{"role": "user", "content": "Extract supplier and total as JSON. Use null when missing. Text: Supplier North Pier; total 12.50 USD."}]
output = generator(messages, do_sample=True, temperature=0.1,
    top_k=50, repetition_penalty=1.1, max_new_tokens=256)
print(output[0]["generated_text"][-1]["content"])

Independent testing gives a useful boundary

MindStudio’s 28 October hands-on report describes successful JSON extraction and tool arguments in its local setup, but failed code fixes and HTML generation. It also reports a timezone assumption when the request omitted one. These are limited examples from a vendor’s publication, not our measurements or a statistically representative score.

Its broad translation test attempted about 80 languages, beyond the card’s stated 16. That does not establish failure across every supported language. The more defensible conclusion is to test your actual language, schema and tool contract, and make timezone and units explicit rather than relying on defaults.

An extraction or routing acceptance set

Build held-out examples with missing fields, conflicting dates, unsupported tools and instructions embedded in source documents. Require null or refusal where appropriate. Measure semantic correctness separately from valid JSON; a perfectly formatted wrong identifier is still a failure.

Record correction work, runtime memory and total accepted requests. Treat tool output as untrusted data and prevent a model-generated argument from escaping its permitted scope. If the job becomes complex debugging, route it to a stronger model or deterministic workflow rather than hiding repeated failures.

Compare the whole workflow

Compare LFM3 with another compact model using the same quantisation class and task set, a larger model for difficult interpretation, and rules for fully specified transformations. Do not use a combined benchmark average to decide a particular document pipeline.

For offline deployment, download weights and runtime dependencies first and verify that the surrounding application makes no external requests. Local weights do not automatically make the UI, logs or tool integrations private.

Read the custom license before commercial deployment

The checkpoint uses LFM Open License v1.0, not Apache-2.0. The license file includes a USD 10 million annual-revenue threshold and commercial-use limitations tied to the legal entity. Read the exact definitions and Section 5 with the responsible reviewer; do not turn a general “open” label into blanket commercial permission.

Licensing, accuracy and privacy are separate acceptance decisions. The hand drawing explains matching a small model to a bounded job, not a benchmark or generated model output.

Questions before adoption

Does it support every language?

The card lists 16 languages, not universal coverage. A third-party test over roughly 80 languages exceeded that scope. Evaluate your actual languages and formats with native review, particularly when numbers, dates and domain vocabulary matter.

Can I use it commercially under Apache-2.0?

No: this checkpoint has the custom LFM Open License v1.0. Its revenue threshold and commercial-use clauses must be checked for your legal entity. Download availability and a small model size do not remove those conditions.

Does 1 GB include a 256K conversation?

Do not assume so. Quantised weights, runtime memory, context state and output budgets are different quantities. Measure the selected package on the intended device with a representative workload before promising memory or latency.

Sources reviewed

• Liquid AI — model card
• Liquid AI — LFM Open License v1.0
• MindStudio — local hands-on report, 2026-10-28

Explore related tools

• Text models
• AI agents