PAN 2 vs LFM2.5-2.6B-Base: Two Kinds of Checkpoint You Are Meant to Fine-Tune

The first thing to notice about LFM2.5-2.6B-Base is the word Base. Liquid AI's 2.69-billion-parameter checkpoint is not a model you chat with; it is the pre-trained substrate from which the post-trained LFM2.5-2.6B variants are made, published so that other people can make their own. PAN 2 is the same kind of object at thirty times the scale: a 29-billion-parameter diffusion transformer from MBZUAI's Institute of Foundation Models, published under Apache-2.0 with training configs in the repository, meant to be adapted rather than merely consumed. Put side by side they look absurd — one is a language model you can run on a laptop, the other a video world model that wants four B300s. But both are base artifacts with a licence attached, and for anyone whose actual job is to take a checkpoint and make it do something it was not trained for, the interesting comparison is not capability at all. It is what each one gives you to work with, and what it costs to hold the thing while you find out.

Start with the licence, because it is the one hard difference

PAN 2's own code and weights are Apache-2.0. The third-party pieces — Qwen3.5-9B as text encoder, Wan 2.2 as VAE, Diffusers — are used under their own terms and are not redistributed by MBZUAI; you download them from their authors. That is a clean, boring, corporate-legal-friendly arrangement, and it is the main reason a company with a review process can adopt PAN 2 at all.

LFM2.5-2.6B-Base is released under the LFM1.0 licence, which Hugging Face records as other with a link to the LICENSE file rather than an SPDX identifier. That is not a criticism — Liquid's licence permits commercial use up to a revenue threshold, which is a common and reasonable shape for an open-weights release — but it is a different shape from Apache-2.0, and the difference is not a detail you discover after the fine-tune. If your legal team has a list of pre-approved licences, one of these two models is on it and the other needs a conversation.

That asymmetry runs the opposite way from the parameter counts, and it is worth sitting with. The tiny model is the one with strings; the enormous one is the one you can ship without asking anyone.

What a base checkpoint actually hands you

LFM2.5-2.6B-Base is a hybrid architecture: thirty layers, of which twenty-two are double-gated short-convolution blocks and eight are grouped-query attention. That mix is the whole point of the LFM line — convolution blocks are cheap at long sequence lengths and attention blocks hold recall — and it is why the model can carry a 131,072-token context at 2.69 billion parameters. Training ran to 34 trillion tokens over a 128,000-token vocabulary, with coverage for sixteen languages including Arabic, Japanese, Korean, Thai and Vietnamese.

What it does not have is any post-training. No instruction tuning, no chat template worth the name, no safety alignment. A base model predicts the next token and that is all it does, which makes it the wrong thing to evaluate on an instruction-following benchmark and the right thing to evaluate on how quickly a LoRA converges on your domain. Liquid publishes the post-trained sibling separately, and the existence of GGUF and ONNX builds of that sibling is the clearest statement of intent: this family is for running on devices you own.

PAN 2 hands you considerably more scaffolding, and less freedom in one specific way. The repository ships training configs for both pre-training and supervised fine-tuning — config/pretrain_29B_720p.yaml and config/sft_29B_720p.yaml — and the documentation tells you to point their data paths at your own latents. So the fine-tuning path exists. But the data it expects is not text. It is video latents annotated in a specific structured caption format: events in order, actions bound to actors, camera motion, within a text-encoder budget of 1,536 tokens. If you want to fine-tune PAN 2 on your domain, your first project is not a training run. It is a data pipeline that turns your footage into that format, and the repository gives you a validator but not the annotator.

• Compute to fine-tune — LFM2.5-2.6B-Base: a single GPU, LoRA on a workstation, hours not weeks. PAN 2: a 67.37 GB transformer at BF16 before optimizer state, plus a 15.87 GB frozen encoder and a VAE, on video latents. Multi-node, and nobody has published a recipe.

• Data you must supply — LFM2.5-2.6B-Base: text, in whatever format your task uses. PAN 2: video plus structured world-state captions in the repository's schema.

• What you get out — LFM2.5-2.6B-Base: a text generator, and after post-training, an assistant or an agent policy. PAN 2: a video of up to 20 seconds at 704×1248 and 24 fps, showing the consequence of an action.

• Licence — LFM2.5-2.6B-Base: LFM1.0, other, read it. PAN 2: Apache-2.0 on its own weights.

On the one benchmark where they almost meet

There is a genuine overlap, and it is small enough to be interesting. OpenBMB's MiniCPM5-2B model card benchmarks LFM2.5-2.6B against its own 2B model and a set of others, and one of the rows is long context. On AA-LCR, OpenBMB reports 5.3 for LFM2.5-2.6B against 59.0 for MiniCPM5-2B. On NoLiMa, 0.7 against 68.1. On LongBench v2, 30.3 against 43.7.

Those are competitor-reported numbers on a competitor's harness, and the model card publishing them has an obvious interest in the comparison. But the size of the gap on the two hardest long-context probes is not the kind of thing a harness choice explains away, and it is a useful corrective to reading "131,072-token context" as a capability claim. A context window is a capacity; recall at length is a behaviour. The Base checkpoint has the first and, on third-party evidence, not much of the second — which is precisely why a fine-tune is the intended use rather than a long-document assistant straight out of the box.

PAN 2 has no equivalent cross-check. Nobody outside MBZUAI has benchmarked it, and the model card's own numbers are the only ones that exist. That is a weaker evidentiary position than LFM2.5-2.6B-Base's, even though the model is a hundred times more expensive to run — a reminder that independent evaluation follows adoption, and adoption follows the ability to run the thing at all.

The cost of holding each checkpoint

LFM2.5-2.6B-Base is about 2.7 billion parameters. In BF16 that is comfortably under 6 GB of weights, and the GGUF builds of the post-trained sibling bring it well below that. You can keep it resident on the same machine as the rest of your stack, fine-tune it overnight, and forget it is there.

PAN 2 is 86.17 GB across sixty files, and the number that matters is not the total but the shape. The transformer is 67.37 GB and every inference worker holds a full copy — the repository's own inference script runs one worker per GPU, each taking every Nth prompt, because there is no tensor-parallel sharding in that path. The vLLM recipe is the sharded option, and its headline is thirteen seconds of 704×1248 video in about 119 seconds on four B300s with classifier-free-guidance parallelism across two ranks and Ulysses sequence parallelism across two. The default is eight H200s. A fifty-step sampler with guidance on every step means a hundred forward passes per clip, and that is the arithmetic behind every configuration choice in the recipe.

So the honest cost comparison is not "6 GB versus 86 GB". It is "zero marginal cost per inference versus a multi-GPU node per two minutes of output". A fine-tuned 2.6B model answering a query costs nothing measurable. A fine-tuned PAN 2 rendering a twenty-second clip costs a GPU node for three minutes, and you will run it hundreds of times before you know whether the fine-tune worked.

Where a router touches either of these

Neither model is something a routing layer can serve. LFM2.5-2.6B-Base is a base checkpoint with no hosted endpoint worth routing to — it is a file you download. PAN 2 has no hosted endpoint at all, from MBZUAI or anyone else. If your plan involves either of them, your plan involves GPUs.

The reason to mention routing anyway is that almost nobody deploys a base model in isolation. A fine-tuned LFM2.5 is one component in an application that also needs a general reasoner, and a PAN 2 simulation is one stage in a pipeline whose first stage is a language model writing structured captions. That surrounding layer is where a single API for 200-plus models is worth having: you keep the tuned checkpoint on your own hardware, route the commodity calls through OrcaRouter at provider list price with 0% markup passed through, and get automatic failover when a provider has a bad hour. For a PAN 2 pipeline specifically, the caption stage is the elastic part — the report ranks Claude Opus 5.5, GPT-6 Astra, Kimi K3 and Qwen3.8-Flash by full-plan completion, and Qwen3.8-Flash is on OrcaRouter, so you can test which planner actually completes your plans without provisioning four models.

What OrcaRouter will not do is host either checkpoint. Saying otherwise would be the kind of claim that sounds like a feature and behaves like a bug.

What the base-model framing hides

Both of these releases are, in the strict sense, unfinished. LFM2.5-2.6B-Base has no instruction tuning by design; PAN 2 has a limitations section that says about two in three simulated plans contain at least one step that is not carried out. Neither is a product. The difference is what "unfinished" means in each case.

For LFM2.5-2.6B-Base, unfinished is a stage in a pipeline the vendor has already completed downstream — the post-trained model exists, the quantized builds exist, and the base checkpoint is published for people who want to diverge. The gap is deliberate and documented.

For PAN 2, unfinished is the state of the whole release. The weights are up, the framework support landed on 10 November, and the only thing anyone has said about it in public is a two-paragraph post on the lab's own X account the same afternoon. Its limitations are not a design choice handed to downstream users; they are open problems the team is naming in public. If you fine-tune PAN 2, you inherit those problems along with the weights.

That is the real comparison, and it does not resolve into a recommendation between the two models because they are not substitutes. It resolves into a question about your project: are you adapting a known-good component, or are you building on a research artifact whose failure modes are still being measured? LFM2.5-2.6B-Base is the first. PAN 2 is the second, and the Apache-2.0 licence is the only reason the second is even an option.