Granite Switch 4.1 30B: IBM Cut Twelve Adapters Down to Two

Five months ago IBM put a 30B Granite Switch preview on Hugging Face with twelve adapters inside it and a 11.68% parameter surcharge over the base model. On 14 October 2026 the finished model arrived — Granite Switch 4.1 30B — and it has exactly two adapters and a 3.89% surcharge. The headline number went down by two thirds, and that is the release.

To be precise about what "arrived" means, because this is where a lot of coverage gets sloppy: the weights landed on the Hub on 14 October 2026, and IBM's own launch post, Granite Switch 4.1: Chat, Decisions, and Speech from One Endpoint, went up on 15 October. That is two days before this is being written. It is an announced release, not a quiet drop someone found in a mirror, and it is not a re-listing of the May preview — the artifact is different, the adapter count is different, and the audio path did not exist in the preview at all. What follows separates what you can read off the repository from what only IBM has said.

What is actually in the checkpoint

Granite Switch 4.1 30B is a composition, not a new architecture. It takes Granite 4.1 30B — a dense decoder-only transformer, 131,072-token window, 100,352-token vocabulary — freezes it, and bolts on two activated-LoRA adapters plus a speech encoder. The build manifest is checked into the repository next to the weights, which is why every structural claim below is readable rather than reported.

• guardian-core — aLoRA, rank 16, alpha 64, attached to the attention projections only (k_proj, o_proj, q_proj, v_proj), lifted from the Guardian Library and pointed at harm, jailbreaking, profanity, violence, sexual content, social bias and unethical behaviour. Control token <|guardian-core|>, id 100352.

• decision — aLoRA, rank 64, alpha 128, attached to all seven projections including the MLP, and trained to do something narrower than chat: given a state and a question with labelled options, return a calibrated probability distribution over those labels in one forward pass. Control token <|decision|>, id 100353.

• Speech — granite-speech-5.0-470m-turboctc, a 470M-parameter non-autoregressive conformer CTC encoder, English-only, wired in as an audio input path rather than a second service.

The weight arithmetic is the cleanest number in the release. Base: 28,865,728,512 parameters. Composed: 29,989,814,272. The difference is 1,124,085,760 parameters, or +3.89%. You do not write the control tokens yourself — the chat template inserts them when you pass an adapter_name argument, which means switching capability is a request parameter rather than a second deployment.

The preview shipped twelve adapters. The release ships two.

This is the decision worth understanding, because on its face it looks like a regression. The preview checkpoint — still on the Hub, still Apache-2.0, dated 5 May 2026 — carries twelve adapters from three Granite Libraries: citation, query rewrite, query clarification, hallucination detection, answerability, factuality detection, policy guardrails, factuality correction, guardian-core, uncertainty, requirement check and context attribution. That is a genuinely useful bundle, and it is a bundle you have to reason about, because twelve adapters means twelve invocation recipes and twelve different output contracts.

Granite Switch 4.1 30B keeps two of them and adds a speech encoder. The trade IBM made is legibility for coverage: the finished model is a chat model that can also answer a decision question with a probability and transcribe audio, and those are three things a caller can hold in their head at once. The other ten adapters are not gone — they are still published, still composable, and the composer in the granite-switch repository will build you a checkpoint with any subset you want, including all twelve. What changed is what arrives switched on by default.

That is a real cost, and it is worth naming rather than smoothing over: if you were waiting for the preview's hallucination-detection and context-attribution adapters to reach a 1.0 checkpoint, this is not that. It is a narrower model with a lower overhead, and the composition tooling is the thing that closes the gap.

The decision adapter is the half that is not a chat model

Reading a probability distribution out of a language model is not new. Doing it in one forward pass against a fixed set of option labels, with numbers calibrated well enough to route on, is the part that needs explaining. The documented recipe is a fixed decision-engine system prompt, a State: turn evaluated on the frozen base, then a ### DECISION turn presenting the question and single-token-labelled options. You request the logprobs of exactly those label token ids and exponentiate. The card's own example returns something like A: 0.982, B: 0.0035, C: 0.014 — and the interesting part is that those came from a normal completion endpoint, not a classifier.

There is an engineering wrinkle the announcement skips. The logprob-token-id mechanism caps at 128 ids per request, so a decision question with more than 128 options fails outright. The documented fix is to split the label ids into chunks of 128, issue one request per chunk with an identical prompt, and concatenate — which is mathematically identical to an uncapped call, because the returned logprobs span the full vocabulary and each label's value therefore does not depend on which chunk asked for it. One extra request per 128 options. This is the kind of detail that only exists inside a repository.

The one published number attached to the adapter is the Decision Index, edition v0.3, public fast subset of 1,068 rows: Overall 50.1, with Knowledge 32.4, Language 58.6, Retrieval 49.8, Tools 76.5 and Arts 26.4. Read the shape rather than the headline — 76.5 on Tools sitting next to 26.4 on Arts is a very uneven profile, and it tells you more about where this adapter is safe to point than the overall figure does. IBM also reports that serving the adapter locally and behind a hosted vLLM endpoint agreed to within about 0.6 points, which is a useful sanity check on the serving path even though IBM ran both halves of it.

Speech-to-text, and the caveat IBM wrote into its own card

The audio path runs the transcript through the embedded encoder and splices it into the chat context in place of the audio content part, so a request with audio looks like a normal chat completion with an input_audio part. No second speech server, no second latency budget.

The limits are all from IBM's own documentation rather than from a sceptic: English only, lowercase and unpunctuated output, no decode-time steering, and — the one that should slow you down — the speech encoder and the language model are not jointly trained. There is no trained projection coupling them. A mistranscription can therefore change what the model, or the decision adapter, responds to, and nothing in the pipeline will flag it. If you are deploying anything where a transcription error has consequences, that sentence is your entire threat model.

Confirmed, vendor-reported, unverified

• Confirmed from the repository — base model identity, both adapter ranks and their target modules, the control-token ids, the composed parameter count and the +3.89% delta, the 131,072-token window, Apache-2.0 licensing, and the pinned support window (Transformers 5.16–5.17, vLLM 0.26–0.28, PyTorch 2.11+).

• Vendor-reported, not reproduced — the Decision Index figures, the claim that Granite Speech 5.0 TurboCTC is the fastest ASR model on the OpenASR leaderboard, the claim that the composed model consumes roughly the same VRAM as the base, the assertion that the Guardian adapter beats several named closed decision models on safety-related tasks, and the launch post's aside that a custom 3B Granite Switch build played Doom at 60–100 decisions per second against a reported 10 per second. IBM says more data is coming "in the upcoming weeks", which is an admission that today's evidence is thin.

• Nobody has checked — everything else. No third-party evaluation, no leaderboard entry, no independent latency or throughput measurement, no hosted IBM endpoint. The repository shows a handful of likes and, at the time of writing, effectively no downloads. Two days old and largely unread.

Where this sits in a stack

Granite Switch 4.1 30B is a self-host story. The card lists Hugging Face Transformers and vLLM, pins a narrow version window, and the checkpoint runs on both without conversion. There is no managed endpoint, so the practical first step is one GPU and a container.

Being straight about the rest: no Granite model is in the OrcaRouter catalogue today, so if you want this checkpoint, the route is IBM's release and your own hardware. What the platform does give you is the surrounding decision — 200-plus models behind one key with automatic failover, provider list price passed through with 0% markup — which matters most in exactly this situation. A two-day-old checkpoint with no independent evaluation is a candidate, not an incumbent, and the cheap thing to do with a candidate is keep it beside the model already in production and compare on your own traffic instead of rewiring a production path around it.

The open question

The bet behind Granite Switch is that composition beats scale for a specific class of work — applications that answer, decide and transcribe, where three models mean three deployments, three latencies and three bills. Sharing one KV cache across adapters and paying 3.89% for it is a genuinely unusual piece of engineering, and it is the part of this release that will still matter a year from now.

What is not settled is whether the composed answer is good. The decision adapter's published profile is uneven, the speech path is English-only and not jointly trained, and the model is two days old with no independent run behind it. Read the build manifest, compose your own subset, and benchmark the decision adapter against your own label set before you trust anyone's 50.1.

Comparisons like this one are also where the failure modes show up: the documented AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.