Implementation support

The rest of this reference describes what IBM publishes. This page records something else: how far one independent inference implementation gets through the same 172 catalogued models. That implementation was written by the author of this reference to run Granite checkpoints and is not published. It is neither IBM's code nor Hugging Face transformers.

It is here because trying to run every model is a practical test of the catalogue. It shows which architectures an outside implementation could cover from the published files, which adapters could be merged into their base models, and which releases need behaviour that it refuses on purpose.

This is not a benchmark. No output quality, accuracy or speed was measured. Because you cannot inspect the implementation, every row is a statement by the author about work you cannot re-run; the evidence grade says how strong that statement is. What you can check is the configuration side: each model that publishes a config.json has its sha256 in claims.json (see evidence).

Every one of the 172 catalogue ids appears exactly once below. The support assessment and the public catalogue cover the same ids, so no model can drop out of this page unclassified.

Terms

• checkpoint — one published set of model weights; one row of the catalogue.
• the implementation — the unpublished inference implementation assessed here.
• stored checkpoint — a checkpoint's weights converted into the implementation's own file format; it is what the implementation actually loads. Grade ids and statuses spell this pack, and the grade table calls a stored checkpoint made by merging adapters into a base an extension pack.
• class — the architecture class a configuration declares, such as GraniteForCausalLM.
• normalized configuration — a published config.json with the fields that record provenance rather than behaviour set aside (see findings §6).
• shape — class plus depth, width and the stack of layer kinds; see method §4.
• forward pass — one run of the model over an input.
• reference recording — outputs (logits) saved from the model's own published reference implementation, so the independent implementation's outputs can be compared with them. Parity in a grade name means such a comparison was made; the tolerance used is not published here.
• LoRA adapter — a small set of weight changes published to modify a base model. aLoRA (activated LoRA) switches on at a particular token position partway through a sequence.
• merge — add a LoRA adapter's weights into its base model's weights once, when the stored checkpoint is built, so that the result loads like an ordinary checkpoint. Grade ids, statuses and the grade table spell this fold.
• approved — a merged stored checkpoint whose sha256 digest the author has checked and accepted. The implementation also records which adapters went into which stored checkpoint.
• covered base — a base model the implementation already runs.

The assessment column is the status the support assessment records, quoted exactly:

• runs — the implementation runs this model.
• runs (adapter seam) — this adapter runs only merged into a covered base (adapter seam is the implementation's name for its merge step).
• foldable, not packed — an adapter that could be merged into a covered base, but no merged stored checkpoint has been built for it.
• refused by design — the implementation declines this model on purpose.
• out of scope — outside what the implementation sets out to run.

Reading the tables

For ordinary model rows, a matching stored checkpoint means the assessment records one or more stored checkpoints with the same normalized configuration. It does not establish that one of them holds the exact weights of the linked checkpoint. Base, instruct and guardian releases of one generation often share a configuration exactly, so one stored checkpoint can match several catalogue rows, and the assessment cannot always say which of those rows it holds the weights of. Where it can, the grade begins own-; where it cannot, shape-. Both are true statements, and they are not the same statement.

Adapter rows add a second distinction: the stored checkpoints they list may be those of a compatible base, while their status says whether anything was actually merged. Classification follows the status first, and the reason column keeps both facts visible.

runs is one word covering several strengths of claim, so each row also carries the strongest evidence that exists for it. The grade is computed from the stored checkpoints, the recorded passes and the comparisons made, not written down by hand. Each grade's first phrase below is the one the overview uses; what follows the dash adds detail. Strongest first:

A row that does not claim runs gets no implementation grade, because a grade answers "how well does this run" and those rows do not ask it:

The stored checkpoints, recorded passes and reference recordings behind these grades belong to the unpublished implementation and are not published here. The grade is the whole public statement.

Summary

Runs, with a stored checkpoint of the same configuration

The implementation runs this architecture, and at least one stored checkpoint has the same normalized configuration. That is a match of configuration, not proof that it holds this checkpoint's published weights.

_{↑ summary}

Runs, with no stored checkpoint of the same configuration

The implementation runs this architecture class, or the adapter has been merged into a covered base, but no stored checkpoint with this exact configuration is recorded. For the adapter rows the evidence is the merged stored checkpoints; for the others it is the class alone.

_{↑ summary}

Adapter that could be merged, not yet merged

A plain LoRA that could be merged into a covered base, but nothing has been merged for this release. A stored checkpoint of the compatible base, where one is counted, says a suitable base is stored, not that this adapter was applied to it.

_{↑ summary}

Not implemented

None in scope. No catalogued model outside the out-of-scope rows (the GneissWeb and geospatial releases) needs an architecture the implementation lacks.

_{↑ summary}

Refused by design

The model needs behaviour at run time that merging weights once cannot express. The implementation refuses these by name when loading them, and its tests check the refusal.

_{↑ summary}

Out of scope

The release is in IBM's Granite catalogue but outside what the implementation sets out to run.

_{↑ summary}