Granite Switch 4.1 8B vs LFM2.5 2.6B Base: Is There a Real Choice Here?

This is the pairing in the set that looks least like a fair fight, so let us deal with that immediately rather than pretend otherwise. Granite Switch 4.1 8B is a 8.78-billion-parameter composed checkpoint IBM published on 14 October 2026: a frozen Granite 4.1 8B with two switchable adapters and a speech encoder, doing chat, decision scoring and transcription from one endpoint. LFM2.5 2.6B Base is a 2.69-billion-parameter pre-trained text model Liquid AI published on 1 August 2026, built specifically for on-device deployment — and, importantly, its own model card says it is a base checkpoint "only recommended for tasks that require heavy fine-tuning." Comparing them as if one could replace the other is a category error. Comparing them tells you something more useful: where the boundary of each one actually sits, and why almost nobody will be choosing between these two.

So this is not a bake-off. It is a map of the decision you would actually be making — the one where you have an edge target and a server target, and you are trying to work out which model goes where.

What each one is for

LFM2.5 2.6B Base is a hybrid architecture, and the hybrid is the point. Thirty layers, of which 22 are double-gated short-convolution blocks and 8 are grouped-query attention — so most of the stack is convolution rather than attention, which is what keeps the memory footprint and the per-token cost down on small hardware. Hidden size 2,048, 32 query heads against 8 KV heads, a 131,072-token context, a 128,000-token vocabulary, and a pre-training budget of 34 trillion tokens. Sixteen languages are listed: English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian and Polish. Liquid describes the family as built for on-device deployment and ships the sibling instruct model in GGUF, ONNX and MLX formats alongside the native checkpoint.

Granite Switch 4.1 8B is the opposite instinct applied to the opposite problem. Rather than shrink the model, it keeps a large-ish text backbone and adds capability sideways. The base is Granite 4.1 8B: 40 layers, hidden size 4,096, 32 query heads against 8 KV heads, a 131,072-token window, a 100,352-token vocabulary. On top of that sit guardian-core, a rank-16 activated-LoRA adapter over the attention projections that detects harm, jailbreaking, profanity, violence, sexual content, social bias and unethical behaviour; decision, a rank-64 adapter over all seven projections that returns a calibrated softmax over labelled option tokens in a single forward pass; and Granite Speech 5.0 TurboCTC, a 470M-parameter non-autoregressive conformer encoder for transcription. The composed total is 8,776,400,896 parameters against a base of 8,380,551,168 — a 4.72% increase.

The dimension that decides it: instruct versus base

The single biggest difference between these two checkpoints is not size or architecture. It is that one is a finished model and the other is raw material.

Granite Switch 4.1 8B ships ready to call. The adapters are composed in, the control tokens are wired through the chat template, the invocation recipes for the decision adapter are documented with working code, and the card lists the exact Transformers and vLLM versions it wants. You download it, run it, and it does the three jobs.

LFM2.5 2.6B Base does none of that, by design. Liquid's own guidance is that this checkpoint is for "language-specific (e.g., Japanese) or domain-specific (e.g., medical) assistants, training on proprietary data, or experimenting with novel post-training approaches" — and if what you want is a model that answers questions out of the box, the card points at the post-trained sibling instead. A base checkpoint has no instruction-following behaviour to compare, no alignment, and no chat template discipline. Put the two on the same eval and the Granite model will look dramatically better for a reason that has nothing to do with which is the better model: one has been post-trained and one has not.

• Parameters — 8.78B composed vs 2.69B.

• Layers — 40 dense transformer blocks vs 30 hybrid (22 double-gated short-convolution + 8 GQA).

• Context — 131,072 tokens vs 131,072 tokens. Dead even, which is unusual and worth noting.

• Vocabulary — 100,355 (three reserved ids for the adapters) vs 128,000.

• Modalities — text and audio in, text out vs text only.

• Checkpoint type — composed, post-trained, ready to call vs pre-trained base for fine-tuning.

• License — Apache-2.0 vs the LFM 1.0 licence, which is not Apache. That distinction matters commercially and it is easy to miss.

• Published evidence — one vendor-run Decision Index at 42.9 overall, no independent evaluation, vs no comparable public benchmark for the base checkpoint.

What 2.69B buys you that 8.78B cannot

Portability, and it is not a soft advantage. A 2.69B model with 22 of its 30 layers built from short convolutions is designed to live on a device — a laptop, a phone-class SoC, an embedded box — and Liquid ships quantized GGUF, ONNX and MLX variants for exactly that. An 8.78B composed checkpoint with a 470M speech encoder is a server-side artifact. It runs on a GPU, in a container, behind an endpoint.

That means the deployment shapes do not overlap: one is for the case where the request cannot leave the device, the other is for the case where it can. If the constraint is "no network," the comparison is over before it starts, and no amount of composition changes it. Add the licence point on top — LFM 1.0 rather than Apache-2.0 — and the 2.6B checkpoint is the one you would pick when you intend to fine-tune your own model on your own data and ship it in a product, while Granite Switch is the one you pick when you want three capabilities today under a permissive licence.

What composition buys you that 2.69B cannot

Three jobs from one endpoint, and a probability instead of an answer.

The decision adapter is the part with no equivalent on the other side. Given a state and a question with labelled options, it returns a calibrated softmax over those labels in one forward pass — the documented call asks vLLM for the logprobs of exactly the label token ids via logprob_token_ids and exponentiates them, giving output shaped like A: 0.982, B: 0.0035, C: 0.014. Prompts give you a token; this gives you a number you can threshold, average and log. There is also a documented wrinkle worth knowing before you build on it: vLLM caps logprob_token_ids at 128 ids per request, so a question with more than 128 options needs its label ids chunked into groups of 128, one identical-prompt request per chunk, with the results concatenated and a single softmax applied over the complete label set. Because the returned logprobs span the full vocabulary, each label's value is independent of which chunk requested it, so the chunked result is mathematically identical to an uncapped call.

Speech on the same endpoint is the second. Send an input_audio content part on an ordinary chat completion and the 470M encoder transcribes it before splicing the transcript into context. IBM's caveats are specific and worth repeating: English-only, lowercase and unpunctuated output, and the encoder and the language model are not jointly trained — there is no trained projection coupling them, so a mistranscription can silently change what the model responds to. An edge model with no audio path at all has a different problem rather than no problem.

And the safety adapter is the third: a harm and jailbreak classifier riding the same checkpoint, activated by a control token the chat template inserts when you pass an adapter_name, rather than a second model to deploy and pay for.

Where a router fits when the answer is "both"

The realistic version of this comparison ends with both models in the same product. LFM2.5 2.6B Base, fine-tuned, on the device, handling what cannot leave it; Granite Switch 4.1 8B, self-hosted, handling decisions and transcription server-side. That is a two-tier architecture, and the operational question it raises is what happens at the seam — an on-device model that fails, a server that is saturated, a request that needs to fall through to something else. Neither checkpoint is in the OrcaRouter catalogue today, so we are not the way to get either one; the point where we become relevant is the fallback chain behind them. One API key covers 200-plus hosted models with automatic failover, the routing DSL lets you compose several models into a single call rather than hand-rolling the fan-out, and provider list price is passed through with 0% markup so a vendor price cut is live the same day. img src="4.png" alt="A screenshot of the OrcaRouter models catalogue, headed 210 models, 16 providers, one API key, one bill, with modality facets showing 173 text, 12 image, 5 embeddings, 10 video and 10 TTS models, a filter sidebar for input modalities, context length, input price, status, access tier, series and supported parameters, and a newest-first list of model cards beginning with OrcaCyber Zero 1.5, OpenAI GPT-6.1 Sol and Anthropic Claude Sonnet 5.5 with their per-million-token input and output rates." /> That is the layer that makes a two-tier design survivable rather than fragile, and it is worth having in place before the edge tier starts failing in the field.

The verdict, such as it is

Choose LFM2.5 2.6B Base if you are going to fine-tune, if the inference has to happen on the device, or if a 2.69B footprint is the hard constraint. Choose Granite Switch 4.1 8B if you need a calibrated decision distribution, an inline safety classifier, or transcription from the same endpoint as chat, and if a GPU-backed container is acceptable. The overlap between those two use cases is close to zero, which is why the honest answer to "which wins" is that the question is malformed — and why the more useful thing to carry away is that a 2.69B base checkpoint and an 8.78B composed instruct model are not two points on one quality line. They are two different products that happen to have adjacent parameter counts.