Fibo 2.0 vs LFM2.5 2.6B Base: 2.7 Billion Parameters of Text, or 8.1 Billion Parameters of Pictures

The size gap is the first thing anyone notices and the least useful thing about it. Fibo 2.0, released by Bria on 20 October 2026, carries 8,127,342,213 parameters and returns images. LFM2.5 2.6B Base, released by Liquid AI on 1 August 2026, carries 2.69 billion and returns text — and not finished text, but the raw continuation behaviour of a pre-trained base checkpoint with no instruction tuning applied. Asking which is better is like asking whether a camera is better than a dictionary. The question that has an answer is narrower and more practical: each is the smallest credible open option in its own lane, and knowing where each lane's floor sits tells you which one your constraint actually rules out. Neither model card records what happens when a checkpoint like this is deployed badly, and the recorded incidents are catalogued in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

The floor, in both directions

Both models are interesting for the same structural reason — each sits near the bottom of what is viable for its job — and that is the only axis on which they are comparable at all.

• Parameters — Fibo 2.0 8,127,342,213 in BF16; LFM2.5 2.6B Base 2.69 billion. Roughly a three-to-one ratio in weights, which is roughly the ratio in memory too.

• Output — Fibo 2.0 returns an image; LFM2.5 2.6B Base returns text tokens and nothing else.

• Where it runs — Fibo 2.0 needs a GPU with enough VRAM for a 44-block diffusion transformer at 50 steps, or four steps in the Turbo variant; LFM2.5 2.6B Base ships in GGUF, ONNX and MLX formats and is built to run on a phone, a laptop or a single-board computer.

• Tuning state — Fibo 2.0 Dev is a non-distilled base with classifier-free guidance, documented for fine-tuning; LFM2.5 2.6B Base is pre-trained only, with no instruction-following behaviour until somebody tunes it.

• Licence — Fibo 2.0 is CC BY-NC 4.0 for non-commercial use with commercial use by agreement; LFM2.5 2.6B Base is under the LFM 1.0 licence, which permits commercial use subject to its own terms.

• Scores — Fibo 2.0 sits at 1,087.05 Elo on AA-Image-Editing v2.1, first among open weights; LFM2.5 2.6B Base carries an estimated Intelligence Index of 8.39, GPQA 55.8%, Terminal-Bench 2.1 at 4.5% and HLE 6.2%.

Those two score lines cannot be placed in the same sentence as a comparison. One is a crowd preference score over rendered images; the other is a composite over text benchmarks. The only honest use of both is to characterise what each model is for.

What a base checkpoint actually is, because the name misleads

"Base" in LFM2.5 2.6B Base is not a modest way of saying "standard". It means the model has been trained on 34 trillion tokens of next-token prediction and nothing else — no instruction tuning, no chat template, no refusal behaviour, no awareness that a question is a question. Give it "Summarise this email:" and it will continue the string in whatever style the pre-training data suggests, which may be the rest of an email thread rather than a summary.

That makes it a fine starting point and a poor product. Liquid AI ships it for people who intend to fine-tune, and the architecture is chosen for that job: 30 layers, 22 double-gated short convolutions and 8 grouped-query attention layers, a 128K vocabulary, a 131,072-token context, and coverage of 16 languages in pre-training. The convolution-heavy stack is why it fits on a phone — attention cost grows with context and convolutions do not, which is the whole design thesis.

• Architecture — 30 layers: 22 double-gated short convolution blocks and 8 GQA blocks, 128K vocabulary.

• Training — 34 trillion tokens, 16 languages, pre-trained only.

• Context — 131,072 tokens, which is the number the convolution stack is designed to make affordable.

• Formats — GGUF, ONNX and MLX, so llama.cpp, ONNX Runtime and Apple silicon are all first-class targets.

• What it does not do — follow instructions, hold a conversation, or produce anything but a text continuation, until you tune it.

The comparison to Fibo 2.0's Dev checkpoint is closer than it first looks. Fibo 2.0 Dev is also a base — non-distilled, 50 steps with classifier-free guidance at 5.0, explicitly the checkpoint Bria points at for fine-tuning. Both projects ship a tuning target alongside, or instead of, a usable product. The difference is that Fibo 2.0 Edit Turbo exists as the usable version of the same weights, distilled to four steps with no guidance, while LFM2.5 2.6B has to be tuned before it is usable at all.

Licence and the actual cost of "open"

Both models are downloadable. What you may do with them diverges sharply, and in a direction that inverts the usual intuition about size: the tiny model is the commercially usable one.

• Fibo 2.0 — CC BY-NC 4.0 for non-commercial use. Commercial use requires a separate agreement with Bria. The Hugging Face repository is gated with a company-and-intended-use form.

• LFM2.5 2.6B Base — LFM 1.0 licence, which permits commercial deployment under its own terms. No per-use negotiation, though the terms are not Apache-2.0 and are worth reading rather than assuming.

• Why Bria's term is what it is — the training corpus is roughly a billion licensed images the company paid for. Free weights that let anyone undercut Bria's own API on that corpus would hand away the asset the corpus bought.

• The practical split — an internal research pipeline can use both tomorrow. A shipping product can embed LFM2.5 2.6B Base in a device tomorrow and cannot ship Fibo 2.0 without a signature.

This is not a knock on Bria. It is the cost structure of the two problems. Liquid AI trained on text, most of which is free to license; Bria trained on photographs, none of which is. The licence terms track the input data, not the model quality, and that is the correct place for them to track.

Where they meet: the on-device assistant that describes before it renders

There is one architecture in which these two models belong in the same system, and it is the reason this piece is a comparison rather than a dismissal. Fibo 2.0's conditioning path takes a structured JSON caption — VGL, Bria's Visual GenAI Language — with named fields for subject, composition, lighting, camera, style and text-in-image. A 2.6B text model that fits on the device capturing the photo is exactly the kind of thing that could write that JSON locally, without a round trip.

Whether it can is a different question from whether it should. A pre-trained base with an estimated index of 8.39, GPQA 55.8% and HLE 6.2% is not going to reliably emit schema-valid JSON from a photograph without task-specific fine-tuning — and fine-tuning it on a VGL corpus is a well-defined, small-model-sized job. That is the honest version of the meet-in-the-middle argument: LFM2.5 2.6B Base is a plausible substrate for a fine-tuned caption writer, not an off-the-shelf one.

• What the 2.6B brings — it runs where the photo is taken, under 3 GB of weights, no network, no per-call cost.

• What it needs first — supervised fine-tuning on VGL-format examples, plus constrained decoding or a JSON grammar to guarantee valid output.

• What the renderer brings — it still needs a GPU. The on-device half describes; the server half draws. That is the only split that works today.

• What breaks the idea — if the caption has to be good, a 12B-class multimodal model reads the source image better than a 2.6B text-only one can, because the 2.6B cannot see the photo at all.

That last point is the one that settles most real designs. LFM2.5 2.6B Base is text-in, text-out. It can write a VGL caption from a written brief; it cannot look at the image it is describing. Anyone pairing the two should be clear about which of those jobs they are actually buying.

Getting each one

Fibo 2.0 comes from Bria's API at $0.032 per image, from Bria's hosted creation tool, through ComfyUI nodes, or as gated weights on Hugging Face. LFM2.5 2.6B Base comes from Hugging Face in GGUF, ONNX and MLX, with no gating on the base release. Neither is on the OrcaRouter catalogue, and neither claim needs softening: Fibo 2.0 is an image endpoint and Liquid's 2.6B base is a downloadable checkpoint, and a router serves neither well.

What a router does serve is everything around them. OrcaRouter runs one key across more than 200 models with provider list prices passed through at 0% markup, so a vendor price change on the text side shows up the day it happens. If you are building the fine-tuning pipeline for a VGL caption writer, the model generating synthetic training pairs and the model grading them can both sit behind that one key, with automatic failover while you iterate and the routing DSL to fan a benchmark across several models in a single call. The renderer stays Bria's. The tuning loop is where routing earns its place.

The decision, stated plainly

If your constraint is where the model runs, LFM2.5 2.6B Base is not competing with Fibo 2.0 — it is the only one of the two that runs on the device at all, and its 8.39 estimated index is a ceiling you are choosing on purpose in exchange for that. If your constraint is what the output is, Fibo 2.0 is the only one of the two that produces the output, and its 1,087 Elo among open weights is the current high-water mark for downloadable image editing. Nobody is choosing between these models. They are choosing between a deployment target and a deliverable, and those are different decisions that happen to have arrived in the same week's news.

The one genuinely shared question is the licence, and it resolves the same way for both halves of a commercial build: the 2.6B base is usable under its terms, the 8B renderer needs Bria's agreement, and the smaller model being the freer one is a fact about training data rather than about engineering. Plan the product around that, not around parameter counts.