A hero title card reading 'LFM3-1.7B-Base' with the subtitle 'The trunk behind six models', four spec chips reading 1.73B parameters, 24 layers, 256K context and LFM Open License v1.0, and six labelled tiles for Text, Vision, Audio, Omni, Decision 1 and Decision 2 rising from a base block reading 'BASE: 1.73B dense, 22T tokens, 256K context'. The OrcaRouter logo sits bottom-right.
Engineering & Research

LFM3-1.7B-Base: What the Repo Says, and What Liquid AI Hasn't Said

Author

Rowan Sterling

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

The most consequential checkpoint in Liquid AI's new family is the one with the least to read. LFM3-1.7B-Base is a 1.73-billion-parameter, text-only pre-trained model, and on October 27, 2026 it became the trunk that every post-trained LFM3 model was built from — the text model, the vision model, the audio model, the omni model, and both decision models. The family launch post mentions it in a single clause. There is no standalone announcement for it, no base-model benchmark table, and no press coverage aimed at it. The repository, meanwhile, is unusually explicit about what the checkpoint is and what it is for, which makes this an easy release to describe and a hard one to overstate. No markup is added to what the model provider charges. Provider list prices A vendor price change reaches your bill the same day.

What follows separates those two things. Everything in the first half comes from the model card, the config file, the license text, or Liquid's own launch post, and is checkable today. The second half is what remains genuinely unknown three days after the weights went up.

Two repositories, one launch post, and a twelve-hour gap

The timestamps tell the story of a release that happened in public before it happened in marketing. The post-trained LFM3-1.7B repository was created on October 23, 2026. The base repository was created on October 26 at 16:28 UTC, and its card was last modified on October 27 at 04:15 UTC — less than twelve hours later. The blog post, "Introducing LFM3: Every Modality for Specialized Intelligence," is dated October 27. By the time anyone outside the company could read a specification, the weights had already been sitting on Hugging Face for a day.

That ordering is worth stating plainly because it is the closest thing to a "quiet release" here. Liquid did announce the family, and the announcement names LFM3-1.7B-Base as the checkpoint the other six models were trained from. What the company did not do is announce the base checkpoint on its own terms — no separate post, no base-specific evaluation, no positioning beyond one paragraph in the card. The family got the launch. The trunk got a repository and a pointer to the family.

What is in the repository

The card is compact and, for once, complete on the basics. One model.safetensors file of 3.46 GB in bfloat16. A tokenizer with a 128,000-token vocabulary. Model code shipped as custom Python alongside the weights, loaded with trust_remote_code=True rather than through a merged upstream Transformers release. The license is the LFM Open License v1.0, the same family of terms Liquid has used since LFM2.

• Parameters — 1.73B, dense, every parameter read on every token.

• Layers — 24: thirteen gated short-convolution blocks, five sliding-window attention blocks, six full-attention blocks.

• Context — 262,144 tokens, input plus output.

• Attention geometry — hidden size 2,048, sixteen query heads, four key-value heads, head dimension 128. That is four-to-one grouped-query attention, not the eight-to-one of LFM2.5.

• Local window — 256 tokens, with a convolution cache of seven. This is a per-layer attention setting, not the context length, and it caused a small wave of misreporting when the architecture first surfaced in an engine pull request the day before launch.

• Vocabularies and languages — 128,000 tokens, sixteen languages listed: English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian, Polish.

• Memory — about 1 GB at 4-bit precision according to Liquid, 3.46 GB as shipped in BF16.

One small inconsistency is worth knowing about before you quote a size. Hugging Face's sidebar rounds the model to "2B params" while the card's table states 1.73B. The file settles it: 3.46 GB of bfloat16 is 1.73 billion parameters at two bytes each, so the sidebar label is a rounding convention, not a second specification. At the time of writing the repository showed fifteen downloads in the last month and eight likes — the profile of a checkpoint that shipped, got linked from the launch post, and has not yet been picked up by anyone.

A headless-browser capture of the Hugging Face model card for LiquidAI/LFM3-1.7B-Base, showing the model-details table with 1.73B parameters, 24 layers of gated short convolutions plus sliding-window and global attention, a 256K-token context, a 128,000-token vocabulary, sixteen languages and the LFM Open License v1.0, plus a sidebar reading 'Model size 2B params' and fifteen downloads last month.

The architecture, without the diagram

The design is best understood as a budget argument. Full attention is the expensive part of a transformer at long context: every token compares itself with every other token, and the cost grows with the square of the sequence. Liquid's tri-hybrid stack spends only six of its twenty-four layers on that operation. Thirteen layers are gated short convolutions, which mix information locally at a fixed cost per token, and five are sliding-window attention blocks that see 256 tokens at a time. Two-thirds of the network never performs a global attention operation at all.

This is the same bet Liquid has been making since LFM2, pushed further. LFM2.5-2.6B-Base used thirty layers split into twenty-two convolutions and eight full-attention blocks, with no sliding-window tier. LFM3 replaces a pair of convolutions with a sliding-attention block at five points in the stack, raises the convolution cache from three to seven, and adds the sandwich normalisation and partial-rotary settings that show up in the config. Whether that specific trade improves quality is a question only evaluation can answer, and as of publication there is no base-model evaluation to answer it. What the config does establish is that the 256K context is not achieved by scaling attention to 256K; it is achieved by keeping most of the stack local.

The base model ships with a chat template

This is the detail most likely to confuse anyone who downloads the checkpoint expecting raw text completion. LFM3-1.7B-Base includes a full chat template, and the card says mid-training included chat data both with and without thinking traces, formatted with the same template as the post-trained model. Call apply_chat_template and reasoning is enabled by default: the response begins inside a thinking block unless you pass enable_thinking=False, which prefills an empty trace and asks for a direct answer.

So it behaves a little like an instruct model and is documented as something else entirely. The card's own recommendation is unambiguous: LFM3-1.7B-Base "is only recommended for tasks that require heavy fine-tuning, like language-specific or domain-specific assistants, training on proprietary data, or experimenting with novel post-training approaches." For chat, tool calling and agents, it points at LFM3-1.7B. The template is there because the mid-training data was formatted that way and because a fine-tune inherits it — not because the checkpoint was tuned for conversation. Anyone treating the template as a readiness signal will be disappointed by the outputs, and the card says so before they start.

The numbers people will quote are not this model's numbers

The launch post carries a substantial benchmark table, and almost none of it applies to the checkpoint this article is about. The headline average of 49.37 belongs to LFM3-1.7B, the post-trained model, measured across Liquid's own suite. The comparison rows — LFM2.5-2.6B at 31.55, MiniCPM5-2B at 39.19, Gemma 4 E4B at 31.74, Qwen3.5-4B at 39.27, Qwen3.5-9B at 47.24 — are post-trained models against post-trained models. The 43.40 on SWE-bench Verified and 73.46 on LiveCodeBench v6 are likewise the tuned model's scores.

Two claims get attached to the base checkpoint in casual reading and should not be. The first is "35% fewer parameters" — that is LFM3-1.7B outperforming LFM2.5-2.6B, a statement about the post-trained pair, not a base-to-base result. The second is the claim that LFM3 "matches Gemma 4 12B." That sentence is about LFM3-VL-2B, the vision model, across 62 vision benchmarks. It says nothing about the text base checkpoint, which has no published evaluation at all. A base model with no benchmark table is not unusual — Liquid deliberately published none for LFM2.5-2.6B-Base either — but the absence means every quality claim about this checkpoint is currently a claim about the model it produced.

A generated single-column scoreboard titled 'LFM3-1.7B-Base — the scoreboard', listing 1.73B dense parameters, a 24-layer architecture with 13 convolutions, 5 sliding-window and 6 global attention blocks, a 262,144-token context, 3.46 GB in BF16 and about 1 GB at 4-bit, 22 trillion pre-training tokens, and the LFM Open License v1.0 with a $10M threshold, above a footer reading 'Specifications from the model card and config; no base-model benchmarks published.'

Training, and the part that is actually distinctive

Liquid says the checkpoint saw 22 trillion tokens in two stages. The main pre-training stage changed the data mix relative to LFM2, adding more scientific papers, repository-level code, mathematics and a wider spread of knowledge sources. The final 3.5 trillion tokens are a mid-training stage on curated, higher-quality data with a larger share of agentic traces and tool calls, and that stage is where the context window is extended to 256K.

The unusual part is not the token count; it is that agentic data went into the base model rather than only into post-training. Most vendors keep tool-call traces for the instruction-tuning stage. Liquid put them in the trunk and then post-trained six different models on top of it with SFT, mixed RL, multi-domain on-policy distillation and agentic RL. That is a coherent strategy for a family meant to share one backbone across modalities, and it is also why the base checkpoint carries a chat template. It is a claim about training methodology that cannot be checked from the outside, and no independent reproduction exists.

What you can do with it today

The card links two TRL notebooks, one for supervised fine-tuning on extracting structured JSON from messy documents and one for continued pre-training on a new language, using Turkish from raw text as the example. Both are written against LFM3-1.7B and require changing a single model_id to point at the base checkpoint. The docs page covers the rest of the fine-tuning path. The instruct model has a full set of runtime variants — BF16 for vLLM, SGLang and Transformers; FP8 and NVFP4 for SGLang; GGUF for llama.cpp, Ollama and LM Studio; MLX for Apple silicon; ONNX Runtime. The base checkpoint has exactly one artifact: the BF16 safetensors file. No GGUF, no MLX build, no quantized release. If you want to run it on a phone, you are doing that conversion yourself.

Where this fits if you serve models for a living

A pre-trained checkpoint is not a chat endpoint, and it is worth being concrete about that. LFM3-1.7B-Base does not appear on OrcaRouter's catalogue at the time of writing, and a base model would be an odd thing to route: it has no instruction following to route to. The useful place for a router starts one step later, after the fine-tune exists. OrcaRouter puts more than 200 models behind one API with 0% markup on provider list prices, automatic failover and a routing DSL, so a domain-tuned LFM3 checkpoint can sit beside a larger general model and be compared or failed over to without a second integration. Model fusion — a panel answering together — is the other option when a 1.73B specialist is good at one thing and you need a second opinion. None of that requires the base checkpoint itself to be hosted anywhere.

What is still unconfirmed

• Base quality. No benchmark table, no evaluation harness output, no comparison to LFM2.5-2.6B-Base on any task.

• Independent verification. No third-party lab has published a run of either the base or the tuned model. Every number in the launch post is Liquid's own.

• Upstream Transformers support. The repository uses custom modeling code and trust_remote_code. That is normal at launch and a maintenance cost later.

• How the base is served. The launch post says the base and post-trained models are available on Hugging Face, the Liquid Playground and the Liquid API. What an API does with an untuned base checkpoint is not explained, and no pricing for it is published.

• License edge cases. The LFM Open License v1.0 is free for commercial use below $10 million in annual revenue; above that threshold a commercial license applies. The text is public, but how it treats a derivative model trained on the base and then served commercially is a question for a lawyer, not a model card.

What to watch

The next meaningful signal is not another announcement — it is the first independent evaluation of the post-trained model, and the first public fine-tune that reports what the base checkpoint was like to train on. Liquid's own framing invites that test: a 1.73B trunk that produced six models and claims to beat a 2.69B predecessor is either a genuinely efficient architecture or a well-chosen benchmark suite, and only outside runs will separate the two. Until then, the repository is the whole story: a 3.46 GB file, a clear specification, a chat template that is not an invitation, and a license worth reading before the revenue line gets close.

A headless-browser capture of Liquid AI's LFM3 launch post dated October 27, 2026, showing the opening paragraph naming the base and post-trained models as open-weight and available on Hugging Face, the Playground and the Liquid API, and a Highlights box reading that six 2B-class models were trained from LFM3-1.7B-Base, with a 256K context window and about 1 GB at 4-bit.