Granite Switch 4.1.1: check the release tag before loading weights

The model card named a release tag. The Hub did not list it.

I hit that mismatch while checking Granite Switch 4.1.1, IBM’s patch to its composed model. The card advertises granite-switch-4.1.1-30b. My request for that revision returned HTTP 404. The repository’s refs response listed the older release tag and main.[1][2]

That is a useful failure to find before downloading weights. 🔎

Original diagram of the observed metadata checks. No model inference was run.

A patch can change a component behind the same name

IBM’s announcement says the base model stays unchanged while the speech model and Decision adapter are updated. It describes the release as backwards compatible.[3]

The checkpoint card gives a narrower, useful detail: the Decision adapter’s prompt format, invocation and readout stay the same while its weights change.[1]

Those statements concern the integration contract. They do not establish that every answer, score or downstream threshold behaves identically. An application can keep sending valid requests while receiving different predictions.

💡 For an update review, I would keep interface checks and task evaluation separate. The former asks whether requests still work. The latter asks whether their results still satisfy the application’s requirements.

Ask the registry what exists

Here is the exact Python metadata check I ran. Save it as check_release.py and run python3 check_release.py. It uses the standard library and public HTTP reads. It does not load model code or weights.

import json
from urllib.request import urlopen
repo = "ibm-granite/granite-switch-4.1-30b"
api = f"https://huggingface.co/api/models/{repo}"
def read_json(url):
    with urlopen(url, timeout=30) as response:
        return json.load(response)
refs = read_json(api + "/refs")
expected = "granite-switch-4.1.1-30b"
print("advertised tag present:", expected in {r["name"] for r in refs["tags"]})
sha = next(r["targetCommit"] for r in refs["branches"] if r["name"] == "main")
assert read_json(api + "/revision/" + sha)["sha"] == sha
print("resolved main:", sha)
url = f"https://huggingface.co/{repo}/resolve/{sha}/BUILD.md"
with urlopen(url, timeout=30) as response:
    build = response.read().decode()
assert "decision-4.1.1" in build
print("pinned BUILD.md names decision-4.1.1:", True)

My output was:

advertised tag present: False
resolved main: eb206725d03c0f1c409ce3aa512afe325fdf8731
pinned BUILD.md names decision-4.1.1: True

✅ This establishes a narrow result: the advertised tag was missing from the refs response, while the resolved commit’s composition record named the updated Decision component. It does not verify the tensor contents or the model’s accuracy.

Your first line may change if the publisher adds the tag. That is why the check asks the service instead of treating this article’s snapshot as permanent registry state.

A resolved commit identifies the repository snapshot to inspect. A deployment also needs its actual tokenizer, serving configuration and component settings recorded. Pranjul Rathour’s adapter-serving walkthrough makes a related point: a changed chat template or serving precision can change what is being served.[4]

Read the composition record as well as the headline

The pinned BUILD.md names guardian-core and decision as embedded adapters. It records their control tokens, target modules and sources.[5] Those details are useful when checking whether the composed artifact contains the component your application calls.

The speech documentation deserves the same treatment. The announcement says ten languages; the inspected composed-model card and speech-model card list seven: English, French, German, Spanish, Portuguese, Italian and Japanese.[1][3][6]

I cannot resolve that disagreement from these documents. I would use the checkpoint-specific list as the documented scope to test, and ask for clarification before depending on another language. This is a documentation discrepancy, not an observed transcription failure. ⚠️

What the working check actually buys

The failed tag request and the successful commit lookup answer different questions. The first tests whether a documented name resolves. The second gives an inspectable snapshot even while that name is missing.

Neither replaces running the model on the task that matters. This walkthrough stops at metadata and composition records; it contains no transcription benchmark, Decision accuracy result or compatibility certification.

For me, the useful habit is to turn an upgrade instruction into a small executable question before the expensive step: does this revision exist, and does its composition record describe the component I meant to inspect?

That is a much better place for a 404 than halfway through a deployment. 🧩

References and figure

1. Granite Switch checkpoint card at the inspected commit.
2. Public repository refs endpoint.
3. IBM: Granite Switch 4.1.1 announcement.
4. Pranjul Rathour: From adapter to deployment.
5. Pinned composition record.
6. Granite Speech 5.0 TurboCTC model card.

Code and metadata-check diagram are original. The diagram summarizes public source observations; it is not a screenshot or a model-output comparison.

AI disclosure

AI was used to draft the article.