LFM2.5-24B-A2B: Local Inference Does Not Make an Agent Private

Liquid AI’s LFM2.5-24B-A2B makes a new on-device reasoning model available for tool-using agents. It does not make the surrounding workflow private by default. For a German enterprise evaluating the release, the useful acceptance boundary is the complete task: model endpoint, tool processes, retrieval, logs and fallback routes. Approve a local pilot only after that boundary is observable and enforced—not because the model URL points to localhost.

What changed in this release

On 13 October 2026, Liquid AI released LFM2.5-24B-A2B, with downloadable base and post-trained checkpoints. The model card describes a text-only model with 24 billion total parameters and approximately two billion active parameters per token. It targets reasoning and tool use rather than image processing. This is not the earlier vision-language DSpark release or its speculative-decoding sidecar.

Compared with LFM2-24B-A2B, the new release keeps the hybrid convolution-and-attention MoE architecture while expanding the context window from 32,768 to 131,072 tokens and the vocabulary from roughly 65K to 128K tokens. The important integration change is that the new model is reasoning-only: its chat template starts an assistant answer with a reasoning tag. A client expecting immediately displayable prose or a tool call must handle that structure correctly.

Liquid AI lists llama.cpp, MLX, vLLM, SGLang and ONNX support. The card links GGUF, FP8, MLX and ONNX variants, but labels the dedicated DSpark draft model “coming soon.” Do not build a procurement case around a drafter that is not yet available. Pin the actual model revision, tokenizer, chat template, precision and serving build together; the model family name is not a reproducible deployment specification.

Access, commercial terms and the hosted alternative

The weights can be retrieved from Hugging Face for deployment on customer-controlled hardware. That gives buyers an alternative to sending prompts to a hosted inference endpoint; it is not a contractual guarantee about German processing, support or every component in an agent application. Hardware capacity and runtime compatibility still have to be established on the intended machine.

The announcement also advertises Liquid Console inference at US$0.10 per million input tokens, US$0.05 per million cached input tokens and US$1.00 per million output tokens. These are the vendor’s published API rates at the time of checking, not a local-running cost estimate or a guarantee about regional processing. Local inference trades token invoices for hardware, energy, capacity management and maintenance. A hosted fallback changes the data-flow decision even if it improves availability.

The repository’s LFM Open License v1.0 contains a commercial-use limitation and defines a US$10 million annual-revenue threshold. Its legal-entity definition also matters. Do not translate the announcement’s “without restrictions” wording into unrestricted enterprise commercial rights. Have counsel review the exact threshold language, organizational scope and intended use; obtain suitable terms where required. No price for a separate enterprise agreement is established by these sources. This is a procurement checkpoint, not legal advice.

The privacy boundary has more than one process

Consider a proposed maintenance assistant: it reads an approved local manual, checks an asset record and drafts a work order for review. The model can run locally while a search tool transmits the question to a remote service, an application exports traces, or a fallback provider receives the conversation after a timeout. These are architectural possibilities to test, not allegations about this model.

Liquid AI’s agent-harness guide explains connecting a harness to an OpenAI-compatible local endpoint. That configures inference routing, not an operating-system network policy. The guide currently illustrates another family member, LFM2.5-2.6B; its artifact sizes and example commands must not be copied as sizing evidence for the 24B release.

Define “private” operationally before the pilot. One policy may permit only local files and local services after artifacts are staged. Another may permit named internal APIs while prohibiting public egress. A third may allow an approved external lookup with a minimized payload. These are different deployment profiles. A green result under one is not approval for the others.

Enforce the chosen profile outside the model: constrain tool identities, filesystem access and network destinations, separate artifact installation from task execution, and make any fallback explicit. Loopback binding reduces accidental endpoint exposure but does not prevent the harness from opening an outbound connection. Conversely, blocking every connection without a positive-control task can make a broken system look perfectly private.

For the broader authorization design, use the existing agent control-boundary guidance. This release adds a specific acceptance question: can the newly available local reasoning model complete the approved task while the rest of its harness remains inside the declared data boundary?

Fast decode is not a completed private task

Liquid AI reports 184 decoded tokens per second on an M5 Max and 114 on a Ryzen AI Max+ 395. The model card identifies llama.cpp, Q4_K_M quantization and a 4K-token input context for those edge measurements. Its GPU throughput claim uses a single B300 with SGLang 0.5.22, BF16, 1,024 input tokens, up to 256 output tokens and sustained concurrency. These are vendor measurements under different conditions, not independent evidence for your device or workload.

The two-billion-active-parameter label describes sparse computation; it is not the total weight-storage requirement. Longer contexts, concurrent requests and runtime buffers also affect capacity. Measure peak memory and completion latency with the actual quantization and context budget rather than treating the advertised context maximum as a sensible default.

Reasoning tokens can consume time before a useful answer or action appears. Report time to first valid tool proposal, end-to-end task duration, unsuccessful tasks and operator interventions—not only decode rate. Compare the candidate with the current approved workflow on the same tasks and permissions. The self-hosted inference SLO framework supplies the service-level baseline; it does not replace task-level correctness checks.

The vendor’s benchmark results are mixed across tasks: its published table reports 65.01 on BFCLv4 but 8.04 on τ³-Bench Banking. These benchmarks have different definitions and cannot be averaged into a business success rate. They justify testing tool use, not unattended operation on production assets. No independent hardware or model benchmark was run for this article.

A release-specific acceptance checklist

Use synthetic asset records and harmless tool endpoints first. The following decision table is a proposed pilot gate, not a report that LFM2.5-24B-A2B has passed these tests.

1. Freeze the inference route and artifacts

Record model and tokenizer revisions, template, quantization, server build, endpoint binding and served context. Run a harmless tool-call fixture through the exact client integration. Check that reasoning text is not executed as a tool request and that tool results return to the intended conversation. Reject malformed or unauthorized calls at the application boundary rather than asking the model to repair permissions.

2. Observe every permitted data exit

Inventory the harness, child processes, tools, retrieval stores and telemetry exporters. Capture destination and process evidence without routinely retaining sensitive prompt bodies. Exercise a permitted local operation and a controlled denied outbound operation. A model’s statement that it stayed offline is not network evidence; an empty trace without a functioning capture is inconclusive.

3. Force the failure path

Make the local endpoint unavailable in an isolated test. The acceptance condition for an offline profile is a visible failure, not silent provider substitution. Where a hosted fallback is allowed, require an explicit policy decision about the payload and destination before enabling it. Also test unavailable retrieval and denied tools: the agent should report the missing capability rather than invent a successful result.

4. Verify useful outcomes under the same controls

Use representative German terminology, local documents with known answers and multi-step tasks with observable final state. Count correct completions separately from policy-compliant failures. Enforce task duration, reasoning/output and tool-call budgets in the harness. A task that stays local but never finishes has met a containment condition, not the service requirement.

5. Keep a reversible, reviewable release record

Retain the configuration, policy, synthetic fixtures, observed destinations, outcomes and commercial approval together. The reproducible release-bundle pattern makes this record usable when a tokenizer, runtime or permission policy changes. Start with read-only work and human-reviewed outputs; local hosting is not permission to actuate equipment or alter production records autonomously.

Decide what the pilot must prove

LFM2.5-24B-A2B is worth evaluating when customer-controlled inference and tool use address a real operational constraint. It is a weaker fit when the task depends heavily on external knowledge, the hardware cannot sustain the required context, or commercial rights remain unresolved. Retrieval can improve grounding, but its location and permissions become part of the same review.

Bring one workflow, its allowed destinations and its failure policy to an AI implementation review. The next deliverable should be a bounded pilot with observable task outcomes and a verified data boundary. A local model is one component of that evidence—not the conclusion.