Granite Switch 4.1 30B: IBM reduceerde twaalf adapters tot twee

Vijf maanden geleden zette IBM een 30B Granite Switch-preview op Hugging Face met twaalf adapters erin en een parametertoeslag van 11,68% bovenop het basismodel. Op 14 oktober 2026 arriveerde het voltooide model — Granite Switch 4.1 30B — en het heeft precies twee adapters en een parametertoeslag van 3,89%. Het belangrijkste cijfer daalde met twee derde, en dat is de release.

Om precies te zijn wat "arrived" betekent, want dit is waar veel verslaggeving slordig wordt: de gewichten belandden op 14 oktober 2026 op de Hub, en IBM's eigen lanceringsbericht, Granite Switch 4.1: Chatten, beslissingen en spraak vanuit één endpoint, verscheen op 15 oktober. Dat is twee dagen voordat dit wordt geschreven. Het is een aangekondigde release, geen stille drop die iemand in een mirror heeft gevonden, en het is geen hervermelding van de preview van mei — het artifact is anders, het aantal adapters is anders, en het audiopad bestond helemaal niet in de preview. Wat volgt scheidt wat je uit de repository kunt aflezen van wat alleen IBM heeft gezegd.

Wat er eigenlijk in het checkpoint zit

Granite Switch 4.1 30B is een compositie, geen nieuwe architectuur. Het neemt Granite 4.1 30B — een dense decoder-only transformer, een venster van 131.072 tokens, een vocabulaire van 100.352 tokens — bevriest die, en schroeft er twee geactiveerde LoRA-adapters plus een spraakencoder op. Het buildmanifest is naast de weights in de repository ingecheckt, en daarom is elke structurele bewering hieronder leesbaar in plaats van gerapporteerd.

• guardian-core — aLoRA, rang 16, alpha 64, alleen gekoppeld aan de attention-projecties (k_proj, o_proj, q_proj, v_proj), afkomstig uit de Guardian Library en gericht op schade, jailbreaking, grof taalgebruik, geweld, seksuele inhoud, sociale bias en onethisch gedrag. Controletoken <|guardian-core|>, id 100352.

• beslissing — aLoRA, rank 64, alpha 128, gekoppeld aan alle zeven projecties, inclusief de MLP, en getraind om iets te doen dat nauwer is dan chat: gegeven een toestand en een vraag met gelabelde opties, geef een gekalibreerde waarschijnlijkheidsverdeling over die labels terug in één forward pass. Controletoken <|decision|>, id 100353.

• Spraak — granite-speech-5.0-470m-turboctc, een niet-autoregressieve conformer-CTC-encoder met 470M parameters, uitsluitend Engels, aangesloten als een audiotoevoerpad in plaats van als een tweede service.

De gewichtsberekening is het zuiverste getal in de release. Basis: 28.865.728.512 parameters. Samengesteld: 29.989.814.272. Het verschil is 1.124.085.760 parameters, of +3,89%. Je schrijft de controletokens niet zelf — het chatsjabloon voegt ze in wanneer je een adapter_name-argument doorgeeft, wat betekent dat het wisselen van functionaliteit een aanvraagparameter is in plaats van een tweede deployment.

De preview werd geleverd met twaalf adapters. De release wordt geleverd met twee.

Dit is de beslissing die het waard is om te begrijpen, want op het eerste gezicht lijkt het een regressie. Het preview-checkpoint — nog steeds op de Hub, nog steeds Apache-2.0, gedateerd 5 mei 2026 — bevat twaalf adapters uit drie Granite Libraries: citation, query rewrite, query clarification, hallucination detection, answerability, factuality detection, policy guardrails, factuality correction, guardian-core, uncertainty, requirement check en context attribution. Dat is een echt nuttige bundel, en het is een bundel waarover je moet redeneren, want twaalf adapters betekent twaalf aanroeprecepten en twaalf verschillende outputcontracten.

Granite Switch 4.1 30B behoudt er twee en voegt een spraakencoder toe. De afweging die IBM maakte is overzichtelijkheid ten koste van dekking: het uiteindelijke model is een chatmodel dat ook een beslissingsvraag met een waarschijnlijkheid kan beantwoorden en audio kan transcriberen, en dat zijn drie dingen die een beller in één keer kan onthouden. De andere tien adapters zijn niet verdwenen — ze worden nog steeds gepubliceerd, zijn nog steeds composeerbaar, en de composer in de granite-switch-repository bouwt voor u een checkpoint met elke subset die u wilt, inclusief alle twaalf. Wat is veranderd, is wat standaard ingeschakeld wordt geleverd.

Dat is een reële kostenpost, en het is de moeite waard om die te benoemen in plaats van te verdoezelen: als je erop wachtte dat de adapters voor hallucinatiedetectie en contextattributie van de preview een 1.0-checkpoint zouden bereiken, dan is dit dat niet. Het is een smaller model met een lagere overhead, en de compositietooling is wat de kloof dicht.

De beslissingsadapter is het deel dat geen chatmodel is.

Een kansverdeling uit een taalmodel lezen is niet nieuw. Dat je dit in één forward pass doet tegen een vaste set optielabels, met getallen die goed genoeg gekalibreerd zijn om op te routeren, is het deel dat uitleg behoeft. Het gedocumenteerde recept is een vaste decision-engine-systeemprompt, een State: beurt geëvalueerd op de bevroren base, en dan een ### DECISION beurt waarin de vraag en opties met één-tokenlabels worden gepresenteerd. Je vraagt de logprobs op van precies die label-token-id's en exponentieert die. Het voorbeeld op de kaart zelf levert zoiets op als A: 0.982, B: 0.0035, C: 0.014 — en het interessante is dat die van een normaal completion-endpoint kwamen, niet van een classifier.

Er is een technische complicatie die de aankondiging overslaat. Het mechanisme voor logprob-token-id's is beperkt tot 128 id's per aanvraag, dus een beslissingsvraag met meer dan 128 opties mislukt ronduit. De gedocumenteerde oplossing is om de label-id's op te splitsen in blokken van 128, één aanvraag per blok uit te voeren met een identieke prompt, en ze samen te voegen — wat wiskundig identiek is aan een niet-afgekapte aanroep, omdat de geretourneerde logprobs de volledige woordenschat beslaan en de waarde van elk label dus niet afhangt van welk blok erom vroeg. Eén extra aanvraag per 128 opties. Dit is het soort detail dat alleen in een repository bestaat.

Het enige gepubliceerde getal dat aan de adapter is gekoppeld, is de Decision Index, editie v0.3, openbare snelle subset van 1.068 rijen: Totaal 50,1, met Kennis 32,4, Taal 58,6, Retrieval 49,8, Tools 76,5 en Kunsten 26,4. Kijk naar de vorm in plaats van naar de kop — 76,5 op Tools naast 26,4 op Kunsten is een zeer onevenwichtig profiel, en het vertelt je meer over waar je deze adapter veilig op kunt richten dan het totaalcijfer doet. IBM meldt ook dat het lokaal serveren van de adapter en het serveren achter een gehost vLLM-endpoint binnen ongeveer 0,6 punt met elkaar overeenkwamen, wat een nuttige sanity check is op het serveerpad, ook al voerde IBM beide helften ervan uit.

Spraak-naar-tekst, en het voorbehoud dat IBM in zijn eigen kaart opnam

Het audiopad leidt het transcript door de ingebedde encoder en voegt het in de chatcontext in op de plaats van het audiocontentdeel, zodat een verzoek met audio eruitziet als een normale chatcompletion met een input_audio deel. Geen tweede spraakserver, geen tweede latentiebudget.

De beperkingen komen allemaal uit IBM's eigen documentatie, niet van een scepticus: alleen Engels, uitvoer in kleine letters en zonder leestekens, geen sturing tijdens het decoderen, en — degene die je zou moeten afremmen — de spraakencoder en het taalmodel zijn niet gezamenlijk getraind. Er is geen getrainde projectie die hen koppelt. Een transcriptiefout kan dus veranderen waarop het model, of de beslissingsadapter, reageert, en niets in de pijplijn zal het signaleren. Als je iets implementeert waarbij een transcriptiefout gevolgen heeft, is die zin je hele dreigingsmodel.

Bevestigd, door leverancier gemeld, niet geverifieerd

• Bevestigd vanuit de repository — de identiteit van het basismodel, beide adapterrangen en hun doelmodules, de id's van de control-tokens, het samengestelde aantal parameters en de +3.89%-delta, het venster van 131,072 tokens, de Apache-2.0-licentie en het vastgezette ondersteuningsvenster (Transformers 5.16–5.17, vLLM 0.26–0.28, PyTorch 2.11+).

• Door de leverancier gerapporteerd, niet gereproduceerd — de cijfers van de Decision Index, de bewering dat Granite Speech 5.0 TurboCTC het snelste ASR-model op het OpenASR-leaderboard is, de bewering dat het samengestelde model ongeveer hetzelfde VRAM verbruikt als de basisversie, de bewering dat de Guardian-adapter het wint van verschillende met naam genoemde gesloten beslissingsmodellen bij veiligheidsgerelateerde taken, en de terloopse opmerking in de lanceringspost dat een aangepaste 3B Granite Switch-build Doom speelde met 60–100 beslissingen per seconde tegenover een gerapporteerde 10 per seconde. IBM zegt dat er meer data aankomt "in de komende weken", wat een erkenning is dat het bewijs van vandaag dun is.

• Niemand heeft het gecontroleerd — al het overige. Geen evaluatie door derden, geen vermelding op een ranglijst, geen onafhankelijke latency- of doorvoermeting, geen gehost IBM-endpoint. De repository vertoont een handjevol likes en, op het moment van schrijven, vrijwel geen downloads. Twee dagen oud en grotendeels ongelezen.

Waar dit in een stack staat

Granite Switch 4.1 30B is een self-hostverhaal. De kaart vermeldt Hugging Face Transformers en vLLM, legt een nauw versievenster vast, en de checkpoint draait op beide zonder conversie. Er is geen managed endpoint, dus de praktische eerste stap is één GPU en een container.

Om eerlijk te zijn over de rest: er staat vandaag geen Granite-model in de OrcaRouter-catalogus, dus als je dit checkpoint wilt, is de route IBM's release en je eigen hardware. Wat het platform je wel geeft, is de omliggende beslissing — meer dan 200 modellen achter één sleutel met automatische failover, de lijstprijs van de provider doorgegeven met 0% opslag — wat juist in deze situatie het zwaarst weegt. Een checkpoint van twee dagen oud zonder onafhankelijke evaluatie is een kandidaat, geen gevestigde partij, en het voordeligste wat je met een kandidaat doet, is hem naast het model houden dat al in productie is en vergelijken op je eigen verkeer, in plaats van een productiepad eromheen om te leggen.

De open vraag

De gok achter Granite Switch is dat compositie het wint van schaal voor een specifieke klasse van werk — applicaties die antwoorden, beslissen en transcriberen, waar drie modellen drie deployments, drie latenties en drie rekeningen betekenen. Eén KV-cache delen tussen adapters en daar 3,89% voor betalen is een werkelijk ongebruikelijk staaltje engineering, en het is het onderdeel van deze release dat over een jaar nog steeds van belang zal zijn.

Wat niet vaststaat, is of het samengestelde antwoord goed is. Het gepubliceerde profiel van de decision adapter is onevenwichtig, het spraakpad is uitsluitend Engelstalig en niet gezamenlijk getraind, en het model is twee dagen oud zonder enige onafhankelijke run erachter. Lees het buildmanifest, stel je eigen subset samen en benchmark de decision adapter tegen je eigen labelset voordat je iemands 50,1 vertrouwt.