Granite models: an independent reference

An independent reference to IBM's Granite models — release 1.0, published 2026-09-22. A snapshot of 172 repositories in the ibm-granite catalogue; latest upstream modification timestamp represented: 2026-09-18. Unofficial; not affiliated with IBM. Notice · Licence · How to cite

What each model is, how it is built, and how the families relate — excluding quantised and format repackagings of models already listed.

For each of the 139 models that publish a configuration, its sha256 is in evidence/claims.json, so a reader can tell whether their config.json matches the one analysed here. The remaining 33 are explicitly marked as publishing none. Every one of the 172 is pinned to an upstream commit, and on 2026-09-22 all 139 published configurations at those commits matched their recorded digests byte for byte.

The catalogue pages are compiled from public sources only — the vendor's model catalogue and every published configuration that is available, which is 139 of the 172. support.md is deliberately separate: it compares that catalogue with the tracked implementation assessment. Nothing here is a benchmark score and nothing is a recommendation; it is a description of what exists and what this reference records.

How strong "supported" is, before you read any of it

A support status is one word and the evidence behind it is not uniform. Of the 136 rows that claim to run, 2 carry an exact comparison against that checkpoint's own reference implementation. The rest stand on something weaker, and every row says which on support.md.

Reading every "supported" row as equivalent numerical parity is the mistake this table exists to prevent. Nothing here is a benchmark and nothing was scored; the grades describe what was checked, not how well anything performed.

The suite at a glance

Licensing

Granite is unusually uniform here: 169 of 172 models are Apache-2.0, including every general-purpose language model, every code model, the vision family, every speech model but granite-speech-5.0-470m-turboctc-nc, and the embedding models.

How to read the tables

• parameters is the published total, including embeddings. A sparse model's total is its whole parameter count, not the subset active per token — a 32-expert model stores every expert whether or not a given token routes to it.
• geometry is layers x width, then attention heads (H) and key/value heads (KV) when they differ, then experts and the number active per token.
• mixer is how a model moves information between positions, read from the layer types a config lists or, where it lists none, from what the architecture class settles; a dash means neither said. Most are plain attention; the hybrid family alternates state-space layers with attention, and the sliding-window family bands most of its attention layers to a fixed span.
• context is the published maximum position count in tokens, shown exactly as configured. It is an upper bound on the architecture, not a promise about quality at that length.
• a geometry of 48H/1KV is multi-query attention: every query head shares one key/value head. Some models declare this with a flag rather than a head count; it is read either way.
• every model name is a link to its published page, built from the repository id recorded with the model rather than from its name.
• revision is the upstream commit these pages describe, linked to the repository as it stood at that commit. Its configuration was checked against the digest in evidence/claims.json on 2026-09-22; if a model has changed since, the page is describing the pinned commit, not the current one.
• role is the only column derived from the model's name rather than its configuration, because nothing in a configuration distinguishes a base model from an instruction-tuned one — they are the same architecture. Treat it as a reading aid, not as a fact the publisher asserts.

Contents