LFM2.5-2.6B-Base: Liquid AI's Quietest Release Is the One Fine-Tuners Actually Wanted

Read across the Hugging Face counters on August 5, 2026, and the gap is hard to miss: LFM2.5-2.6B, the agentic on-device model Liquid AI launched on August 4, sits at 47,393 downloads. LFM2.5-2.6B-Base, the pre-trained checkpoint that every one of those weights descends from, sits at 151. Same organisation, same architecture, same week, a 314-to-1 split.

The base checkpoint was not leaked and it was not hidden. It appeared in Liquid's launch post in exactly one parenthesis — "The base (LFM2.5-2.6B-Base) and post-trained (LFM2.5-2.6B) models are available today on Hugging Face" — and that is the entire published account of it. No benchmarks of its own, no section, no separate card. Everything below is read directly off the repository — the model card, config.json, the LICENSE file and the Hugging Face API — plus arithmetic we did ourselves. Where a number comes from Liquid's own evaluations we say so, because for this particular checkpoint the most important fact is how little has actually been measured.

That matters more than a footnote suggests. A post-trained model you can judge by trying it. A base checkpoint is an offer to spend two weeks and a GPU budget before you learn anything, so the terms of the offer — what is in it, what it is licensed for, what has been evaluated — are the whole decision.

What is actually in the repository

Nine files, one shard of weights, no modeling code. The card's specification list, corroborated against config.json:

• 2.69B total parameters, bfloat16, in a single 5.39 GB model.safetensors. Plan storage and VRAM off that number, not off "2.6B."

• 30 layers, hybrid. The card says 22 double-gated short convolution blocks plus 8 GQA attention layers. The layer_types array in config.json confirms it exactly: 22 entries of conv and 8 of full_attention, the attention layers spaced roughly every third or fourth block rather than clustered.

• 2048 hidden width, 10752 intermediate, 32 attention heads over 8 key-value heads — a 4-to-1 GQA ratio — with tied input and output embeddings and a rope theta of 10,000,000.

• 128,000-token vocabulary, and an 18 MB tokenizer to go with it. Liquid doubled the vocabulary in this generation, which is a meaningful cost at 2.6B: with tied embeddings, the vocabulary table alone accounts for roughly 262M of the parameter budget, near a tenth of the model.

• 34 trillion training tokens. That is an unusually long pre-training run for this size class, and it is the single strongest reason to look at the checkpoint at all.

• 16 languages declared: English, Arabic, Chinese, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Thai and Vietnamese.

One inconsistency for anyone planning long-context work: the card advertises a context length of 131,072 tokens, while config.json sets max_position_embeddings to 128,000. Liquid's own blog and docs both say 128K. The 3,072-token difference will not matter to most people, but if you are writing a training script that packs sequences to the advertised maximum, trust the config file over the card.

The architecture string is the practical headline: model_type is lfm2 and the class is Lfm2ForCausalLM — the same class LFM2 shipped with. LFM2.5 is extended pre-training and new post-training on an existing architecture, not a new one, so nothing here needs custom modeling code. That is why llama.cpp, vLLM, MLX, ONNX Runtime, SGLang and LM Studio all supported this family on day one, and why the fine-tuning path through Unsloth and TRL works without patches. You do need transformers>=5.0.0.

The card you get is the other model's card

Open the base repository and the first heading is "LFM2.5-2.6B" — the post-trained model's name, not the one you are looking at. This is not a nitpick; the whole page reads as the instruct card with a base paragraph spliced into it, and three of the artefacts left behind can cost you real time.

• The YAML frontmatter says base_mode: LiquidAI/LFM2.5-2.6B-Base. Two problems in one line: the key is a misspelling of Hugging Face's base_model, and it points the base repository at itself. Nothing breaks, but the model tree links you would expect from a properly declared lineage are not being generated from this.

• The repository is tagged conversational and ships a chat_template.jinja, so Hugging Face renders a "Chat template" badge on a checkpoint that has never been instruction-tuned. A template exists because the tokenizer configuration was inherited, not because the weights know what to do with it.

• The quick-start snippet then uses that template. The Python example on the base card calls tokenizer.apply_chat_template with a {"role": "user"} message and asks "What is C. elegans?" — the classic way to make a base model look broken. Wrap a raw pre-trained checkpoint in chat turns and you get drifting, repeating, self-continuing text, and it is easy to read that as a bad model rather than the wrong prompt format. Prompt this one as a text completer, few-shot, with stop sequences you control.

• The variants table lists only the post-trained line — LFM2.5-2.6B, plus its GGUF, ONNX and MLX builds. There is no GGUF or MLX build of the base checkpoint at all, so "run it locally tonight in LM Studio" is not on the table without converting it yourself.

Hugging Face also reports that no inference provider serves this repository. There is no hosted endpoint for the base checkpoint anywhere; if you want its logits, you rent the GPU.

The benchmark section that does not exist

Not one evaluation number has been published for LFM2.5-2.6B-Base. No MMLU, no MMLU-Pro, no GPQA, no HellaSwag, no ARC, no perplexity figure — nothing, on any of Liquid's three surfaces (the model card, the launch post, the docs). For a base checkpoint that is the conspicuous absence, because those knowledge-and-reasoning scores are precisely how you judge whether 34T tokens of pre-training left you something worth fine-tuning.

What does exist belongs to the post-trained sibling, is reported by Liquid, and has not been independently reproduced. On Liquid's own evaluations, LFM2.5-2.6B scores 51.87 on AIME25, 59.17 on IFBench, 80.07 on Multi-IF, 56.88 on BFCLv4, 77.83 on ToolSandbox and 26.89 on BrowseComp+ inside the OpenClaw harness, measured against gemma-4-E2B-it (5.1B), gemma-4-E4B-it (8B), Qwen3.5-4B (4.7B) and Qwen3.5-9B (9.7B). Liquid's summary is that it leads every instruction-following benchmark and nearly every tool-use one, and its own chart is candid about the exceptions: Qwen3.5-9B is ahead on AIME25 at 56.07 and on BFCLv4 at 60.13. Speed claims follow the same rule — 220 tokens/s decode on an M5 Max, 113 on a Ryzen AI Max+ 395, about 30 on a phone, under 2.5 GB of memory, and roughly 15K output tokens/s at high concurrency on one H100 — all vendor-measured, none verified by anyone else yet.

The trap is assuming any of that transfers. Those scores are the product of a four-stage pipeline applied on top of this checkpoint: two rounds of supervised fine-tuning, per-domain teacher specialisation, multi-domain on-policy distillation, then agentic reinforcement learning with GRPO run inside real harnesses. Tool-calling and instruction-following are exactly the behaviours that pipeline installs. Take the base weights and you are starting before all of it. What you inherit is the pre-training — the languages, the world knowledge, the long-context capability, the efficient hybrid architecture — and you should assume you inherit none of the agentic scoreboard.

151 downloads is not just early — it is off the family's own pattern

Liquid ships base checkpoints routinely, so this release is unremarkable in kind. It is the neglect that is measurable. Comparing each LFM2.5 base repository against its instruct sibling on the same day gives a clear house norm — and one clear outlier.

• LFM2.5-230M — 58,676 downloads against 6,982 for its base: about 8 to 1.

• LFM2.5-350M — 94,526 against 9,397: about 10 to 1.

• LFM2.5-1.2B — 583,914 for the Instruct build against 17,867 for the base: about 33 to 1.

• LFM2.5-8B-A1B — 171,520 against 3,996: about 43 to 1.

• LFM2.5-2.6B — 47,393 against 151: about 314 to 1.

Some of that is simply age; the base repository was created on August 1 and the instruct model had a four-day head start plus a launch post. But the older base checkpoints in this family settled between 8-to-1 and 43-to-1, so an order of magnitude past the worst of them is a real anomaly rather than a rounding artefact of a new repo.

The likes tell a subtler story. The base repository has 28 likes against 151 downloads — roughly one bookmark for every five pulls. The instruct model has 232 likes against 47,393, about one for every 204. People are marking the base checkpoint to come back to it, not pulling it. Two community fine-tunes and seven quantizations already exist in its model tree, which is what the leading edge of adoption looks like before the volume arrives.

"Without restrictions" is not what the license says

Liquid's launch page describes the release as open-weight: "Download, fine-tune, and deploy without restrictions." The file in the repository says something narrower, and this is the section to read twice if you are considering building a product on these weights.

The license is LFM Open License v1.0 — not Apache-2.0, not MIT, and not the same terms as most small open-weight models you are probably comparing it against. Quoting the file directly, Section 5 is titled "Commercial Use Limitation" and reads: "The rights granted under this License for Commercial Use are conditioned upon You or Your Legal Entity not exceeding the Threshold," followed by "Any Commercial Use of the Work or a Derivative Work by a Legal Entity that exceeds the Threshold is not licensed under this Agreement." Section 1 defines the Threshold as "annual revenue of 10 million United States dollars ($10,000,000) or more."

So the practical reading:

• Under $10M in annual revenue — you have a broad, perpetual, royalty-free grant covering reproduction, derivative works, distribution and sublicensing, commercial use included.

• At or above $10M — commercial use is not licensed by this agreement. Not "requires attribution," not "requires notification." You need to talk to Liquid, which is presumably why the card ends with a link to their sales team.

• Derivative works inherit the limitation. Your fine-tune of this checkpoint is a Derivative Work, so a model you spend a quarter training carries the same revenue-conditioned grant. If your company crosses the threshold — or gets acquired by one that already has — the terms your product depends on change underneath it.

• Qualified non-profits are carved out: the Threshold does not apply to a 501(c)(3) or foreign equivalent using the work for non-commercial or research purposes. Ordinary obligations also apply — pass the license along, keep the attribution notices, mark files you changed.

None of this makes the release stingy; a $10M threshold exempts almost every startup and every researcher, and it is a legitimate way to publish weights. But "without restrictions" is marketing copy that the license contradicts, and the mismatch bites hardest exactly here. Fine-tuning a base checkpoint is the most expensive, least reversible way to adopt a model. That is the worst place to discover a revenue clause.

Who should actually take this checkpoint

Liquid's own guidance is refreshingly narrow, and worth following: the card says the pre-trained checkpoint is "only recommended for tasks that require heavy fine-tuning, like language-specific (e.g., Japanese) or domain-specific (e.g., medical) assistants, training on proprietary data, or experimenting with novel post-training approaches." That word "only" is doing real work. If you want an on-device agent that calls tools, the post-trained LFM2.5-2.6B is strictly the better starting point and the base checkpoint will waste your month.

The cases where it is genuinely the right pick:

• A language the post-training under-serves. 34T tokens across 16 languages is a strong multilingual foundation, and Liquid has already proven the pattern in-house with a Japanese build in the 1.2B line. Continued pre-training on your language, then your own instruction tuning, avoids fighting an English-centric post-trained persona.

• A regulated vertical with proprietary data. Under 2.5 GB at inference, no cloud dependency, and a permissive-enough license below the revenue threshold is a rare combination for medical, legal or industrial deployments where the data cannot leave the device.

• Post-training research. Liquid published its recipe — SFT, teacher specialisation, MOPD, agentic RL — and then handed over the exact input to that recipe alongside the output. Being able to run your own method on the same starting weights and diff against a strong reference implementation is unusual and valuable.

• Distillation targets. A 2.6B hybrid that decodes at 220 tokens/s on a laptop is an attractive student for compressing a much larger teacher into something shippable.

That last pair is where the cost actually lands, and it is not GPU hours — it is data. Liquid's pipeline runs on teacher specialisation and on-policy distillation, which means the real prerequisite for reproducing anything like it is a large volume of generated data from stronger models, plus preference pairs and verifiable-reward rollouts. That is a many-model job before it is a training job: you want to compare candidate teachers on your domain, then generate at volume from whichever wins. It is the part of the work our own product is aimed at — OrcaRouter puts 200+ models behind one API key at 0% markup, so what you pay for a synthetic SFT set is the provider's list price rather than a routed premium (when a vendor cuts prices, that lands on our side the same day), automatic failover keeps a twenty-hour generation run from dying on one provider's bad hour, and the routing DSL lets you fan a single prompt across several teachers and keep the best answer. To be clear about what we do not offer: LFM2.5-2.6B-Base is not on OrcaRouter and no inference provider hosts it — you run these weights yourself. We are useful for the teachers, not the student.

The same split is worth keeping in mind for whatever you ship. Liquid's post argues that local agents make inference free and remove per-token cost as a constraint, which is true of the marginal token and not of the total bill — you have prepaid it in hardware, and a 2.6B model still has a ceiling. Liquid says so itself, advising against this family for coding-heavy or knowledge-intensive agentic work. The durable pattern is a fine-tuned local model handling the high-volume common path on-device and escalating the hard minority to a frontier model over an API, which keeps the privacy and latency wins where they matter without pretending 2.6B parameters can do everything.

The path from these weights to something usable

The launch post has nothing to say about this, but the base card quietly carries the most practical thing in the whole repository: seven ready-to-run Colab notebooks covering the exact pipeline stages a base checkpoint needs. Two of them are continued pre-training — one for text completion, one for translation — which is the step that only makes sense from base weights and the one nobody writes tutorials for. The rest cover supervised fine-tuning through Unsloth and TRL, DPO through TRL, and GRPO through both. Liquid also ships LEAP Finetune as its own training stack if you would rather not assemble one.

Reading Liquid's fine-tuning docs against the shape of this model, the realistic sequence looks like this:

• Prompt it as a completer first, before you train anything. Ignore the chat template on the card. Few-shot, raw text, your own stop sequences. This is how you find out whether the pre-training already covers your domain and language, which decides whether you need continued pre-training at all or can skip straight to SFT.

• Continued pre-training only if you are adding knowledge or a language. This is the expensive branch — corpus-scale, not example-scale — and the one thing the post-trained sibling genuinely cannot give you.

• Then SFT with LoRA, on 500 to 5,000 examples. Liquid's own guidance is that quality and distribution beat volume and that the examples should match production inputs. At 2.6B a LoRA pass is short: the docs put a 1.2B run at minutes to tens of minutes on one modern GPU, so this size is still a same-afternoon loop.

• Freeze a held-out set before you train. Blunt, and worth repeating for this checkpoint in particular, because there is no published baseline to compare against — your eval set is the only number anyone has.

• Preference or RL stages last, and only if behaviour is the problem. DPO and GRPO recipes exist for the family, but they are refinement on top of a model that already answers; reaching for them before SFT lands is how base-checkpoint projects stall.

Note what is not on that list: nothing here needs a custom kernel, a patched trainer or a modelling file. Because LFM2.5 reuses the LFM2 architecture, the base checkpoint drops into the standard stack, and the entire cost of this project is the corpus and the evaluation set you build for it.

What would change the picture

Three things are worth watching, all of them cheap for Liquid to resolve and none of them resolved today.

The first is base evaluations. A single MMLU-Pro or GPQA number on the pre-trained checkpoint would tell fine-tuners more than every agentic benchmark in the launch post combined, and the fact that 34T tokens went in makes its absence more curious, not less. The second is the card itself — a base repository whose heading names a different model, whose quick-start applies a chat template to a non-chat model, and whose frontmatter misspells base_model is a ten-minute fix that would stop people concluding the weights are broken when the instructions are. The third is the LFM2.5 technical report. The citation block points at arXiv 2511.23404, which is the LFM2 technical report from November 2025; the 2.5 generation's own paper is not out, so the pre-training data mix behind those 34T tokens remains undisclosed.

Until then, the honest summary is that this is a well-specified, long-trained, efficiently-shaped 2.6B foundation with an unusually clear intended audience, published with no measurements and a revenue-capped license, and so far almost nobody has taken it out of the box. If you are inside the audience the card describes, it is worth your GPU time — and you will be among the first people anywhere to know how good it actually is.

Questions worth answering

Is this the same checkpoint LFM2.5-2.6B was post-trained from, or a separate pre-training run?

The card states that LFM2.5-2.6B-Base "is the pre-trained text-only checkpoint, used to create all the LFM2.5-2.6B variants," so it is the actual input to the published pipeline rather than a parallel or cut-down release. That is what makes it useful for post-training research: your method and Liquid's four stages start from identical weights, so a comparison between them is meaningful. Worth noting the base repository was created on August 1 and last modified on August 4, the launch day — check the commit history before assuming the file you downloaded early is the file that shipped.

Can I fine-tune it and sell the result?

If your legal entity's annual revenue is below $10,000,000, yes — the LFM1.0 grant covers commercial use of derivative works, subject to keeping the license and attribution notices intact and marking changed files. At or above that threshold, commercial use of the model or anything derived from it falls outside the license and needs a separate arrangement with Liquid. The threshold attaches to your entity's revenue rather than to the model or the revenue it generates, so the same fine-tune can be licensed for one company and not for another, and a company that grows across the line does not keep the grant it had.

Why not just fine-tune the post-trained LFM2.5-2.6B instead?

For most projects you should, and Liquid's card effectively says so. The reason to start from the base checkpoint is when the post-training is working against you rather than for you: heavy continued pre-training on a new language or a specialist corpus tends to damage instruction-tuned behaviour anyway, and refusal patterns, tool-calling conventions and response style baked in by SFT and RL are hard to remove and easy to conflict with. If you are adding knowledge or a language, start from base. If you are adjusting behaviour at the margins, start from the post-trained model and keep the four stages of work someone already paid for.