LFM2.5-2.6B

LFM2.5-2.6B is Liquid AI's 2.69B-parameter dense language model built for one job: running agents on the device you already own. It is text-only, ships with a 131,072-token context window, and has native tool calling post-trained into it rather than bolted on with a prompt template. Liquid released it on August 4, 2026 alongside a separate base checkpoint (LFM2.5-2.6B-Base) intended for fine-tuning.

The pitch is not "small model, surprisingly good at everything." Liquid's own documentation steers you toward tool use, structured data extraction, RAG, and long-context tasks, and explicitly away from coding and knowledge-heavy work. That is an unusually honest scope statement, and it should shape how you evaluate this model. If you need a local agent that plans, calls functions, and grinds through multi-step tasks without burning API credits, this is one of the few sub-3B models trained specifically for it. If you need a coding assistant or a trivia engine, look elsewhere.

The competitive set at this size is dense and crowded: Qwen3-4B, Llama 3.2 3B, Gemma 3 4B. LFM2.5-2.6B's differentiator is not raw benchmark scores on knowledge tasks, Liquid claims parity with models roughly 4x larger on tool use and instruction following, not on MMLU-style evaluation. It is the combination of a 128K context window, an efficient hybrid architecture, and a ~2.5 GB runtime footprint that makes it deployable where 4B-class models are awkward.

This is a dense model, all 2.69B parameters are active on every token. There is no router and no expert sparsity. That means inference cost scales predictably with sequence length and batch size, and there is no "capacity you can't afford to compute" tradeoff to reason about. The whole model fits in roughly 2 GB at 4-bit, which is the point.

The 30-layer stack is hybrid: 22 double-gated short convolution blocks + 8 grouped-query attention (GQA) layers. The practical consequences matter more than the architecture diagram:

• Only 8 layers carry a KV cache, so long-context memory growth is far cheaper than a transformer of the same depth with attention in every layer.
• Convolution blocks are cache-light and parallelize well, which is why CPU-only inference is viable at usable speeds.
• GQA reduces KV head count further, compounding the savings.

That combination is what makes the 131,072-token context window practical on consumer hardware. Liquid added a dedicated context-extension phase during mid-training specifically to reach it, so long inputs are trained-for, not extrapolated.

The vocabulary is 128,000 tokensdoubled from the LFM2 tokenizer in place rather than retraining from scratch. This matters if you work in Chinese, Japanese, Korean, Arabic, Hindi, Thai, or Vietnamese, a larger vocabulary means fewer tokens per unit of text, which directly reduces both generation time and context consumption for non-Latin scripts. The model covers 16 languages: Arabic, Chinese, English, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Thai, and Vietnamese.

Pre-training budget was ~34 trillion tokens. The published generation parameters are temperature: 0.1, top_k: 50, repetition_penalty: 1.1a low-temperature default reflecting the structured, deterministic outputs an agent loop needs.

Function calling and tool use. This is the headline capability, and it was trained with agentic reinforcement learning inside popular agent harnesses rather than on synthetic tool-call traces alone. That shows up as better behavior when the model is embedded in a real loop with multiple tools, not just in single-turn function-selection evals.

Structured data extraction. Liquid lists data extraction as a primary use case. Concretely: pulling fields out of invoices, parsing semi-structured logs into JSON, normalizing tables, converting messy documents into schema-conformant records. The 128K vocabulary and long context help here because you can pass large source documents without pre-chunking.

RAG and long-context work. The 131,072-token window supports stuffing many retrieved passages at once, and the hybrid architecture keeps the KV cache manageable while you do it. This is the most practical reason to pick this model over a 3B transformer of similar quality.

Local and parallel agent loops. When per-token cost is zero, you can run many agents concurrently on one machine. A 4090 running several LFM2.5 instances in parallel is a realistic design, this is the workload the model was built for.

General chat and instruction following. It handles conversational use and structured-output compliance fine. Keep temperature low.

What it is not for: competitive programming, code generation beyond simple scripts, deep domain knowledge QA, and heavyweight math reasoning. At 2.69B parameters those capabilities are fundamentally capacity-limited, and Liquid's own guidance reflects that.

• Q4_0 / Q4_K_Mroughly 1.7–1.8 GB of weights. This is the recommended starting point. Liquid published quantization-aware distillation work specifically targeting Q4_0 for LFM2.5, so Q4_0 is a first-class format here rather than a compromise. Total runtime memory lands under 2.5 GB with modest context.
• Q5_K_M / Q6_K~2.1–2.5 GB weights. Worth it if you have headroom; small quality gain.
• Q8_0~2.9 GB weights, ~3.5–4 GB runtime.
• BF16 / FP16~5.4 GB weights, ~7 GB runtime with overhead. Use this only for fine-tuning or vLLM/SGLang serving.

The KV cache is the variable most people underestimate. With only 8 GQA attention layers, a full 131,072-token context costs roughly 1–2 GB at 8-bit KV cache depending on the head configuration, real, but far below what a 30-layer full-attention model would demand. Budget for it if you actually run long context.

• Apple Silicon: MLX builds run natively. Liquid reports 220 tok/s on an Apple M5 Max. Any 16 GB Mac handles this comfortably; unified memory means the model and context both fit without contention.
• CPU-only: 113 tok/s on an AMD Ryzen CPU per Liquid's own numbers. That is genuinely unusual for a 2.6B model and is the direct payoff of the convolution-heavy architecture. A modern x86 laptop is a valid deployment target.
• Consumer GPUs: an RTX 3060 12GB or RTX 4060 8GB runs Q4 with full context without strain. An RTX 4090 is overkill for a single sequence, but it is the right card for batching many parallel agent instances.
• Phones and edge SoCs: the intended target. Under 2.5 GB total memory puts it inside mobile budgets.

Use 220 tok/s (M5 Max) and 113 tok/s (Ryzen CPU) as the reference points. High-end discrete GPUs will exceed both for short sequences. Expect throughput to fall as context fills on any hardware, that is true of every model, not a specific weakness here.

GGUF via llama.cpp is the fastest path: brew install llama.cpp, then llama-cli -hf LiquidAI/LFM2.5-2.6B-GGUF -c 4096 --color -i with the sampling flags above. Ollama works if you import the GGUF through a Modelfile or pull a published community tag, llama.cpp, MLX, ONNX, and CoreML builds are all officially maintained. For serving, Liquid's docs cover vLLM 0.14, SGLang >= 0.5.10 (with a tool-call parser flag), and Transformers >= 5.2.0 with device_map="auto" and bfloat16. Note that the Hugging Face model card lists the LFM 1.0 license; check the LICENSE file in the repo before commercial deployment.

vs. Qwen3-4B. Qwen3-4B is the stronger generalist. It beats LFM2.5-2.6B on knowledge and reasoning evaluations and is far better at code. But its native context window is 32K, extensible only with YaRN, and it carries a larger memory footprint at matched quantization. Choose Qwen3-4B if you need reasoning depth or code and can spare the RAM. Choose LFM2.5-2.6B if you need long context and reliable tool calls inside a tight memory budget or on CPU.

vs. Llama 3.2 3B. The closest structural competitor, similar parameter count, same 128K context, broad ecosystem support. Llama 3.2 3B has a larger install base and more community fine-tunes, but it was never trained with agentic RL inside production agent harnesses, and its tool-calling reliability reflects that. For pure chat, either works. For agents, LFM2.5-2.6B is the better starting point.

The deciding factor is usually the deployment target. If the machine is a laptop, a CPU-only server, or anything memory-constrained, LFM2.5-2.6B's efficiency and long context are hard to match at this size. If the machine has 16 GB of VRAM to spare and you need general intelligence rather than agentic reliability, a 4B generalist will serve you better.