NVIDIA Nemotron Labs Dory 1.0 4B vs LFM2.5 2.6B Base: One Is Finished, the Other Is Deliberately Not

N​VIDIA N​emotron Labs Dory 1.0 4B and LFM2.5-2.6B-Base are both small, both text-only, both downloadable as GGUF, and both ones you run yourself — and they sit at opposite ends of the post-training pipeline. Dory arrives fully finished: supervised fine-tuning on an N​VIDIA-curated set, then multi-environment reinforcement learning with GRPO, with reasoning permanently switched on in the serving path. LFM2.5-2.6B-Base arrives deliberately unfinished, described on its own card as a pre-trained checkpoint "only recommended for tasks that require heavy fine-tuning". Liquid AI ships the finished version of that model separately as LFM2.5-2.6B, post-trained for agentic workloads. So the honest framing is not "which 4B-class model is better", because a base checkpoint and a finished reasoning model are not competing for the same slot in your stack. The useful question is which half of the pipeline you are buying for.

What each artifact actually is

N​VIDIA N​emotron Labs Dory 1.0 4B is a 4B dense model published by N​VIDIA to Hugging Face in four quantisations — BF16, MXFP8, NVFP4 and a Q5_K_M GGUF export — under the OpenMDW 1.1 licence. Its card stamps the build "GA (10/16/2026)" and describes a looped, latent-recurrent architecture: an 8-layer input block, a 20-layer recurrent block applied a variable number of times, and an 8-layer output block, with hybrid interleaved sliding-window and full attention. Context runs to 256K tokens, the language is English only, and the whole release went up with no accompanying announcement from N​VIDIA. The card notes that reasoning is always on in the vLLM serving path, which is a statement about intent as much as mechanics: this is not a raw text predictor that will complete your document, it is a model configured to think before it answers.

LFM2.5-2.6B-Base is Liquid AI's 2.69B pre-trained checkpoint, released under the company's own LFM licence (tagged lfm1.0) and updated in mid-August 2026. It is the raw checkpoint that the rest of the 2.6B line is derived from. The architecture is a hybrid of 22 double-gated short-convolution blocks and 8 grouped-query attention layers, trained on roughly 34 trillion tokens with a mid-training context extension to 128K, over a 128,000-token vocabulary and 16 languages. The card is explicit about the audience: domain-specific assistants, language-specific work, training on proprietary data. There is no chat template behaviour to speak of, because there is no instruction tuning in it.

Both are text-in, text-out. That is roughly where the similarities end.

The specification contrast, side by side

• Parameters — Dory 1.0 4B is a 4B dense stack. LFM2.5-2.6B-Base is 2.69B. The gap is smaller than the names suggest, and both fit comfortably on a single consumer accelerator at reasonable quantisation.

• Post-training — Dory has SFT plus multi-environment RL across math, code, science, instruction following, tool use and structured output. LFM2.5-2.6B-Base has none, by design. If you need a model that follows instructions out of the box, one of these is the wrong choice and it is not the one with fewer parameters.

• Context — Dory reaches 256K tokens, with 262,144 positions validated in vLLM under N​VIDIA's shipped launch command. LFM2.5-2.6B-Base supports 131,072 tokens, reached through a mid-training extension. Dory's window is roughly double; whether you can afford to fill it depends on the KV-cache behaviour discussed below.

• Languages — Dory is English only, with pre-training data covering 43 programming languages. LFM2.5-2.6B-Base covers 16 natural languages including English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian and Polish. For anything outside English, this dimension decides it on its own.

• Architecture — hybrid short-convolution-plus-attention on the Liquid side; looped latent-recurrent normalized-G​PT with interleaved sliding-window attention on the N​VIDIA side. Both are departures from a plain transformer stack, and they depart in different directions.

• Compute behaviour — Dory's depth is a runtime parameter. Loop count 1, 2 or 4 trades compute for accuracy without a second checkpoint, and N​VIDIA recommends two as the default. LFM2.5-2.6B-Base has fixed depth; its cost lever is quantisation and, in the wider family, a speculative drafter.

• Licence — OpenMDW 1.1 for Dory, the LFM licence for the Liquid checkpoint. Both permit commercial use; the Liquid licence is the company's own rather than a standard open-source text, which is worth a read rather than an assumption.

• Formats shipped — Dory: BF16, MXFP8, NVFP4, GGUF. LFM2.5-2.6B-Base: BF16 weights on the Hub, with GGUF, ONNX and MLX builds available elsewhere in the family. The Liquid ecosystem is broader here; the Dory repositories are hours old.

Fine-tuning is the axis that separates them

If the reason you are looking at LFM2.5-2.6B-Base is that you intend to train on it — a domain assistant, a proprietary corpus, a language the base model already speaks — then Dory 1.0 4B is a poor substitute for a reason that has nothing to do with quality. Fine-tuning a fully post-trained reasoning model to do a narrow task is usually harder than fine-tuning a base checkpoint, because you are fighting the behaviour that the RL stage installed rather than shaping a blank predictor. The Liquid card recommends its base checkpoint for domain- and language-specific work for exactly this reason, and 34 trillion pre-training tokens over 16 languages is a broader starting point than an English-only model offers.

But the Dory card is silent on fine-tuning in a way that is itself informative. It documents the training pipeline, publishes the formats and gives serving instructions for two engines; it says nothing about adapters, LoRA support or a fine-tuning recipe. That is the profile of a checkpoint published to be served, not to be trained on. Reading absence of evidence as evidence would be a mistake, but the asymmetry is worth naming: one card markets itself to fine-tuners, the other markets itself to deployers.

One more honesty note on numbers. Liquid publishes a full evaluation table for the post-trained LFM2.5-2.6B against Gemma 4 E2B and E4B and Qwen3.5-4B and 9B, and that table is not transferable to the base checkpoint — a base model scored on instruction-following benchmarks measures something different from a post-trained model scored on the same benchmarks. N​VIDIA publishes a benchmark table for Dory against Qwen3.5-4B, Qwen3.5-9B, Gemma 4 26B A4B and Qwen3.6-35B-A3B, measured on its own harness, with no independent reproduction. There is no shared harness result for Dory and either LFM checkpoint, and no published head-to-head at all.

Running them on real hardware

The edge story is where the two diverge most sharply in practice, and Liquid wins it clearly. The LFM2.5 family is built for on-device deployment — the 2.6B instruct sibling is benchmarked at 220 tokens per second on an Apple M5 Max and 113 on a Ryzen AI Max+ 395, in under 2.5 GB of memory, with a phone-class figure of around 30 tokens per second claimed. There are ONNX and MLX builds in the family and a 328M speculative drafter, DSpark, that the company says delivers roughly 2.6× faster decoding with identical outputs. If your target is a laptop, a mini-PC or a phone, LFM2.5-2.6B-Base is on the right side of that line and Dory is not obviously designed for it.

Dory's serving path is narrower and newer. vLLM support is under review in an open pull request, and until it merges the card tells you to install vLLM from that branch with a precompiled-kernel flag, then serve with overrides that set the loop count and the KV-cache mode. llama.cpp support lives in a second open pull request, with a pinned commit and build instructions that target native ARM64 macOS on Apple Silicon. N​VIDIA's published speed figures are quantisation speedups on a DGX Spark rather than throughput: 1.69× and 1.84× for MXFP8 over BF16 depending on the input/output length mix, 2.17× and 2.44× for NVFP4.

The counterweight, and it is a genuine one, is the memory design. Standard looping keeps a separate KV cache per loop, so memory climbs with every added pass — which is the usual reason recurrent architectures are awkward to serve. Dory supports a last-loop KV-caching mode that keeps a single cache per recurrent attention layer and overwrites it on each pass, holding the footprint at roughly the one-loop size for any loop count. N​VIDIA says accuracy stays close to the per-loop mode with nearly unchanged output lengths. That claim is the most valuable thing in the Dory card to verify, because if it holds, the 256K window is affordable at more than one loop, and if it does not, the elastic-depth feature is much less useful than it sounds.

What a router does and does not do here

Neither model is on the OrcaRouter catalogue. N​VIDIA N​emotron Labs Dory 1.0 4B is weights-only with no hosted endpoint anywhere we can confirm, and LFM2.5-2.6B-Base is a fine-tuning checkpoint that no platform would sensibly serve as-is — its post-trained sibling is the one that belongs behind an API. There are no hosted LFM2.5 models on our catalogue either, so the accurate statement is the boring one: for this comparison, everything runs on your hardware.

Which is precisely when a routing layer stops being optional plumbing and starts being a testing tool. Running a fine-tuning experiment on a base checkpoint and a serving experiment on a looped 4B means two local stacks, two sets of quantisations, two sets of serving flags, and no clean way to compare either against the hosted models that are the actual baseline for your application. OrcaRouter exists for that second half: one API key reaches the hosted models you would benchmark against at provider list price with 0% markup, so the control group does not need its own SDK or its own contract. The routing DSL lets a self-hosted endpoint and hosted ones sit behind a single call, and automatic failover keeps a long evaluation run alive when a local GPU pool is busy. It will not tell you whether Liquid's base checkpoint fine-tunes better than N​VIDIA's finished model serves. It removes the setup cost from finding out.

Choosing between them

Take LFM2.5-2.6B-Base if you are buying a starting point rather than an answer: you have training data, you need a language Dory does not speak, you want to run on Apple Silicon or an NPU, or you want the speculative-decoding path and the ONNX and MLX builds that come with the family. It is the smaller, faster, more multilingual, more ecosystem-connected artifact, and it is honest about not being finished.

Take N​VIDIA N​emotron Labs Dory 1.0 4B if you are buying a deployed behaviour: you want a finished reasoning model with tool-calling and structured-output training already in it, you are English-only, your context runs long, and you are willing to build vLLM or llama.cpp from a branch today in exchange for a compute dial that no conventional dense model gives you. Accept that you will be one of the first people outside N​VIDIA to run it, that every number on its card is a vendor number, and that the last-loop KV-cache claim — the one feature that makes the whole design practical — is unverified.

The comparison that would actually be informative is Dory 1.0 4B against the post-trained LFM2.5-2.6B, and nobody has published it. If Liquid's 2.6B instruct model and N​VIDIA's elastic-depth 4B end up within a few points of each other on your workload, then the deciding factor becomes the 2.69B-versus-4B memory difference and the maturity gap, not the architecture. That is the experiment worth running, and it is cheaper to run than it was last week.

None of that is hypothetical: the documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.