A generated title card reading 'LBS-27B vs Granite 4.2 30B' with the subtitle 'Dense by design against a spec that does not exist.', a left card listing Granite 4.2 30B as 30B dense, 128K native and 512K extension, and BFCL v4 61.39, a right card listing LBS-27B as 27B in name only, architecture unknown and no weights, a footer reading 'Granite figures per IBM; LBS values not yet published', and the OrcaRouter logo.
Guides & Insights

LBS-27B vs Granite 4.2 30B: Dense by Design Against a Spec That Doesn't Exist

Author

Elias Hawthorne

Date Published

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

IBM made a deliberate choice with Granite 4.2 30B: it kept the model dense. Sixty-four layers, a 32,768-wide feed-forward block, every parameter read for every token. In a year when most labs of this size reached for mixture-of-experts routing, IBM shipped a straight-through 30B and priced it accordingly. That decision is the right lens for comparing it with LBS-27B, because the only thing we know about inclusionAI's new repository is a name and a licence — and the first question that name has to answer is whether it describes a dense model or a sparse one.

Granite 4.2 30B has a complete public record: weights since August 2026, an Apache-2.0 licence, a model card with nineteen benchmark rows and a documented tool-calling stack. LBS-27B has a repository created on 26 October 2026 containing a .gitattributes file and a 28-byte README that declares Apache-2.0 and says nothing else. This is not a comparison of two models. It is a comparison of one model against a specification that has not been written yet, and the useful output is a list of the specific things that specification would need to contain.

What IBM actually shipped

Granite 4.2 30B is a dense decoder with 30 billion parameters — Hugging Face lists 29B in BF16 — across 64 layers, a hidden size of 4,096, 32 attention heads and 8 key-value heads under grouped-query attention. The vocabulary is 100,352 tokens, the native context is 131,072, and IBM documents a long-context extension to 512K. It is text-only. The card names twelve tested languages: English, German, Spanish, French, Japanese, Portuguese, Arabic, Czech, Italian, Korean, Dutch and Chinese.

It is a reasoning model in the ordinary 2026 sense. The card describes full-thinking, non-thinking and low-effort modes, with reasoning wrapped in think tags. It was fine-tuned from Granite 4.1 30B Base, released under Apache-2.0, and IBM dates the release to 25 August 2026.

Dense is not a technical shortfall. It is a trade. A dense model has predictable per-token compute and memory behaviour, no router to mis-route a token, no expert-parallel sharding to design, and a fine-tuning story that behaves the way most teams expect. In exchange it costs more to serve per token than a sparse model of the same total size. IBM is selling that trade to enterprises that would rather have a boring deployment than a cheap one.

A benchmark profile with a shape

Granite's card is unusually complete, which makes it possible to see where the model is strong and where it is not. All of these are vendor-reported and have not been independently reproduced.

• Mathematics — AIME25 89.17 and HMMT February 2025 89.17. These are the standout numbers on the card and they sit well above what a 30B model was doing a year ago.

• Knowledge and science — GPQA 66.41, MMLU-Pro 77.60, MMLU-ProX lite 66.64, SciCode 38.76. Competent, not class-leading. The gap between an AIME score near 90 and a GPQA score in the mid-60s is the shape of this model: it is better at working through a structured problem than at recalling or reasoning across broad domain knowledge.

• Software engineering — SWE-Bench Verified 57, SWE-Bench Pro 33.29, SWE-Bench Multilingual 41.89, Terminal-Bench 2.1 29.24, LiveCodeBench v6 75.77. The drop from LiveCodeBench to Terminal-Bench is large, and it matters: competitive-programming ability is not the same as finishing a multi-step task in a real terminal.

• Long context — RULER 64K 89.96 and RULER 128K 81.38. This is the most reassuring pair on the card, because it measures retrieval across the window rather than assuming a large context is a usable one. A seven-point fall from 64K to 128K is a gentle slope.

• Instruction following and chat — IFBench 77.17, Arena-Hard-V2 67.93, tau3 averaged at 62.00, BFCL v4 61.39.

The honest reading is that Granite 4.2 30B is a solid, uneven model: excellent at contest mathematics and long-context retrieval, ordinary at broad knowledge, and mid-pack at agentic software work. That is a specific product, not a generic one.

Tool calling is the argument IBM is making

The phrase IBM uses is "reasoning-augmented tool calling" — the model reasons about which tool to invoke and why before invoking it. The implementation details are practical rather than exotic: OpenAI-style function definitions, a vLLM tool parser named qwen3_coder, SGLang auto-resolution to the same parser, and integrations with OpenCode, Pi and OpenHands.

Whether that is better than the alternatives is an empirical question, and the card's own numbers are mixed. BFCL v4 at 61.39 and tau3 at 62.00 are respectable but not dominant; the models that lead those leaderboards are generally larger. What Granite offers is a documented, reproducible tool-calling path with permissive licensing and a dense serving profile — which is often what an enterprise agent project actually needs, more than a leaderboard crown.

This is the area where LBS-27B will be judged first if it is aimed at the same buyer. A model that cannot call tools reliably is not a candidate for agentic work regardless of its MMLU score, and tool-calling evaluations are exactly the kind of thing that does not appear in a repository until the model is finished.

A generated two-column scoreboard. LBS-27B: parameters unverified 27B, architecture unknown, context unknown, tool calling no data, licence Apache-2.0, availability none. Granite 4.2 30B: parameters 30B dense, architecture 64 dense layers, context 128K native and 512K extension, tool calling BFCL v4 61.39, licence Apache-2.0, availability weights on Hugging Face. Footer reads 'Granite figures per IBM card; LBS values not yet published.'

The LBS-27B side of the page

There is very little to say, and it is important to say it precisely rather than fill the space with inference.

• The repository exists. It was created at 05:36 UTC on 26 October 2026 and has not been modified since.

• It contains two files: a 1,519-byte .gitattributes and a 28-byte README. The README is licence frontmatter only: license: apache-2.0.

• There are no weights, no config, no tokenizer, no model card and no evaluation data. Downloads are not tracked and likes are zero. We found no announcement, paper or public discussion.

• "27B" is part of the repository name. Nothing in the repository confirms it as a parameter count, and nothing indicates whether the model is dense or sparse.

That last point is not a minor gap. Dense and sparse 27Bs are different products with different serving economics, different fine-tuning behaviour and different failure modes. Until a config file exists, the Granite comparison has one fully specified side and one empty one.

Screenshot of the Hugging Face model page for inclusionAI/LBS-27B captured 26 October 2026, showing an Apache-2.0 licence badge, a Like count of 0, the notice 'README.md exists but content is empty', a panel saying downloads are not tracked for this model, and 'This model isn't deployed by any Inference Provider'.

The comparison, dimension by dimension

• Parameters — Granite 4.2 30B is 30B dense (29B listed in BF16); LBS-27B is an unverified 27B with no architecture disclosed.

• Layers and width — 64 layers with a 4,096 hidden size for Granite; unknown for LBS.

• Context — 131,072 native and a documented 512K extension for Granite; unknown for LBS.

• Modality — text only for Granite; unknown for LBS, with text-only the reasonable base case.

• Languages — twelve tested languages for Granite; unknown for LBS.

• Reasoning modes — full, non-thinking and low-effort for Granite; unknown for LBS.

• Tool calling — documented function-calling path with BFCL v4 61.39 and tau3 62.00 for Granite; nothing published for LBS.

• Licence — Apache-2.0 for Granite; Apache-2.0 declared for LBS, changeable before weights ship.

• Availability — Granite weights are downloadable and self-hostable today; LBS has nothing to download.

Context length is where the two could diverge most

Granite's 128K native window with a 512K extension is a deliberate enterprise feature, and the RULER scores suggest it is not just marketing: 81.38 at 128K is a usable result. For contract review, log analysis, codebase retrieval and long audit trails, that combination — a documented extension path plus retrieval evidence near the top of the window — is more valuable than a larger number with no evidence behind it.

If LBS-27B ships with a 256K or 512K window, the interesting question will not be the number. It will be whether inclusionAI publishes retrieval evaluations at the far end of it. A window is a capacity claim; RULER-style results are a capability claim, and the two diverge sharply in practice.

Deployment, licensing and where a router fits

Both models declare Apache-2.0, which is the most permissive outcome for commercial use and the reason Granite is popular with teams that cannot accept a custom licence. Granite 4.2 30B is not on OrcaRouter, and neither is LBS-27B; if you want Granite, you download it and serve it yourself, or use a hosting platform.

That self-hosted deployment is exactly where a hybrid architecture makes sense. Run Granite on your own hardware for the routine volume — the classification, extraction and tool-calling traffic where a dense 30B is more than enough — and route the genuinely hard cases to a hosted frontier model. OrcaRouter is useful for that second half: one API key across 200-plus models, automatic failover if a provider degrades, and a routing DSL that lets you express the split as policy rather than as code in three services. We pass through provider list price at 0% markup, so the hosted side of the bill is the provider's number, not ours with a margin on top.

What we will not claim is that either model in this comparison is available through us. It is not, and a comparison page that implies otherwise is worse than useless.

Screenshot of IBM's Granite 4.2 technical blog published 25 August 2026, headlined 'Granite 4.2 LLMs: How They're Built', describing a family of dense decoder-only reasoning models in 3B, 8B and 30B sizes, with a 512K-token context extension and Apache-2.0 licensing.

What would settle this comparison

Three artefacts would turn this page from a specification exercise into a real matchup.

The first is a config.json with expert fields, which settles dense versus sparse and gives the active-parameter count. If LBS-27B is sparse with a small active count, it will undercut Granite on serving cost and the comparison becomes a price-and-quality trade. If it is dense, it is a direct substitution question and IBM's tooling maturity becomes the tiebreaker.

The second is a tool-calling evaluation on a named harness version. Granite's BFCL v4 and tau3 numbers are not spectacular, which means a new model does not need to be spectacular to beat them — it needs to be measured on the same harness.

The third is long-context retrieval evidence at 128K or beyond. Granite's RULER numbers are its strongest claim to enterprise relevance, and they are the number a challenger should be asked to match.

For an enterprise buyer deciding today, Granite 4.2 30B is a known quantity with a permissive licence, a documented tool stack and a dense serving profile that many infrastructure teams prefer. LBS-27B is a name with a licence line. The gap between them is not a verdict on inclusionAI's engineering. It is simply the difference between a model that has been published and one that has been reserved.