Granite Switch 4.1 8B: Eén 8B-checkpoint dat chat, beslist en transcribeert

Acht miljard driehonderdtachtig miljoen parameters gaan erin. Acht miljard zevenhonderdzesenzeventig miljoen komen eruit. Die 4,72% is het hele verschil tussen IBM's basismodel en Granite Switch 4.1 8B, en het is het interessantste getal in de release, want in dat dunne laagje zitten een veiligheidsclassifier, een beslissingsengine en een spraakherkenner — allemaal antwoordend vanaf één endpoint, allemaal lezend en schrijvend in dezelfde KV-cache die het basismodel toch al zou hebben opgebouwd.

De gewichten verschenen op 14 oktober 2026 op Hugging Face. IBM's eigen lanceringsblog, Granite Switch 4.1: Chat, beslissingen en spraak vanuit één endpoint, volgde op 15 oktober, wat vooraf ronduit gezegd moet worden: dit is geen stille release die iemand in een spiegel heeft gevonden. Het is een aangekondigde release die op het moment van schrijven ongeveer twee dagen oud is, en de versie van het verhaal die ertoe doet is niet "wat beweerde IBM", maar "wat kun je nu daadwerkelijk verifiëren aan de hand van het checkpoint dat op de Hub staat." Die twee dingen zijn niet hetzelfde, en dit stuk houdt ze gescheiden.

Wat de checkpoint daadwerkelijk bevat

Granite Switch is geen nieuwe architectuur. Het is een compositie: een bevroren basismodel, een set low-rank adapters die per token aan en uit geschakeld kunnen worden, en — in deze specifieke build — een encoder die er voor audio aan vastgeschroefd is. De composer staat in de granite-switch repository en het buildmanifest voor dit checkpoint is naast de gewichten ingecheckt, wat betekent dat elke structurele bewering hieronder rechtstreeks van de Hub af te lezen is in plaats van overgenomen uit een persbericht.

De basis is Granite 4.1 8B — dense decoder-only, grouped-query attention met 32 query-heads tegenover 8 key/value-heads, SwiGLU, RMSNorm, een venster van 131.072 tokens en een vocabulaire van 100.352 tokens. De samengestelde checkpoint erft dat allemaal en voegt twee geactiveerde LoRA-adapters toe:

• guardian-core — rang 16, alpha 64, uitsluitend gekoppeld aan de attention-projecties (k_proj, o_proj, q_proj, v_proj), overgenomen uit de Guardian Library-release en beschreven als het detecteren van schade, jailbreaking, godslasterlijke taal, geweld, seksuele inhoud, sociale vooringenomenheid en onethisch gedrag.

• beslissing — rang 64, alpha 128, gekoppeld aan alle zeven projecties, inclusief de MLP (down_proj, gate_proj, up_proj), en getraind om iets nauwers en vreemders te doen: gegeven een toestand en een vraag met gelabelde opties, in één enkele voorwaartse pass een gekalibreerde kansverdeling over die optielabels terug te geven.

Beide worden geactiveerd door controletokens — <|guardian-core|> en <|decision|> — die het chatsjabloon voor je invoegt wanneer je een adapter_name-argument doorgeeft. Je schrijft de tokens niet zelf, en dat detail is belangrijker dan het lijkt: het betekent dat adapterselectie een verzoekparameter is, niet een tweede model dat moet worden uitgerold.

Waarom is de parameterdelta zo klein?

De rekensom is het verhaal. Het basismodel heeft 8.380.551.168 parameters. Het samengestelde model heeft 8.776.400.896. Dat is +395,8 miljoen, of +4,72%, voor twee adapters. De reden dat dat getal zo laag blijft, is een ontwerpbeslissing die KV-cache-normalisatie heet: elke adapter ziet de key/value-cache van het basismodel in plaats van een eigen cache te onderhouden. In een conventionele multi-adapteropstelling is elke extra adapter een tweede set aandachtstoestand, en de geheugenrekening groeit met het aantal adapters waartussen je wisselt. Hier is dat niet het geval. De bewering van IBM in het lanceringsbericht is dat het samengestelde model "ongeveer dezelfde hoeveelheid VRAM op een GPU gebruikt als het basismodel op zichzelf zou doen," en hoewel niemand buiten IBM dat nog heeft gemeten, is de gewichtsdelta van 4,72% daarmee in overeenstemming — en in tegenstelling tot de VRAM-bewering is de gewichtsdelta slechts een getal in een manifest dat je kunt lezen.

De beslissingsadapter is de interessante helft.

Een waarschijnlijkheidsverdeling uit een taalmodel lezen is niet nieuw; het doen in één forward pass met een vaste vocabulaire van optielabels, en getallen krijgen die voldoende gekalibreerd zijn om op te handelen, is het deel dat het begrijpen waard is. Het aanroeprecept is gedocumenteerd in de kaart: een vaste systeemprompt voor de beslissingsengine, een Status: beurt geëvalueerd op de bevroren basis, dan een ### BESLISSING beurt die de vraag en opties met één-token-labels presenteert. Je vraagt dan aan de server om de logprobs van precies die label-token-id's — vLLM stelt dit beschikbaar via logprob_token_ids — en exponentieer. Het gedocumenteerde voorbeeld retourneert zoiets als A: 0.982, B: 0.0035, C: 0.014.

Er zit hier een echte technische complicatie die de marketingversie van deze release overslaat. vLLM beperkt logprob_token_ids tot 128 id's per verzoek. Als je beslissingsvraag meer dan 128 opties heeft, krijg je een HTTP 400, en de oplossing is om de label-id's op te splitsen in blokken van 128, één verzoek per blok te doen met een identieke prompt, en samen te voegen — omdat de geretourneerde logprobs over het volledige vocabulaire gaan, is de waarde van elk label onafhankelijk van welk blok erom vroeg, dus één softmax over de volledige labelset is wiskundig identiek aan een aanroep zonder limiet. Dat is één extra verzoek per 128 opties. Het is een echt nuttig detail, en het is precies het soort ding dat alleen in de repo bestaat.

Het enige gepubliceerde cijfer dat aan deze adapter is gekoppeld, is de Decision Index (JEV), editie v0.3, publieke snelle subset van 1.068 rijen: Totaal 42,9, Kennis 29,1, Taal 48,9, Ophalen 49,8, Hulpmiddelen 59,8, Kunsten 18,0. Beschouw dat als door de leverancier gerapporteerd, want dat is het: IBM heeft het uitgevoerd, gepubliceerd, en geen enkele derde partij heeft het gereproduceerd. Het loont ook om naar de vorm te kijken in plaats van naar het totaalcijfer — 59,8 op Hulpmiddelen naast 18,0 op Kunsten is een zeer onevenwichtig profiel, en de kaart zelf waarschuwt dat de optiekansen "een prior zijn om een beslissing te onderbouwen, niet een gecertificeerde classificatie" op domeinen waarvoor de adapter niet is getraind.

Spraak-naar-tekst is echt, en beperkter dan de kop doet vermoeden.

Het audiopad integreert Granite Speech 5.0 TurboCTC, een niet-autoregressieve conformer-CTC-encoder met 470M parameters, en transcribeert inkomende audio voordat het transcript in de chatcontext wordt ingevoegd in plaats van het audio-contentdeel. Het aanroepen ervan verandert de vorm van het verzoek niet: het is een input_audio contentdeel bij een normale chat completion, en de transcriptie draait op hetzelfde endpoint als chat en beslissingen, dus er is geen tweede spraakserver die opgezet hoeft te worden.

De kanttekeningen, allemaal uit IBM's eigen modelkaart in plaats van van een criticus: de encoder is alleen Engels, de uitvoer is in kleine letters en zonder leestekens, er is geen sturing tijdens het decoderen, en — degene die je zou moeten tegenhouden — de spraakencoder en het LLM zijn niet gezamenlijk getraind. Er is geen getrainde projectie die hen koppelt. Een verkeerde transcriptie kan dus geruisloos veranderen waarop het model, of een adapter, reageert. Als je iets bouwt waarbij een transcriptiefout gevolgen heeft, is die zin de hele beveiligingsreview.

Wat is bevestigd, wat is door de leverancier gerapporteerd, wat niemand heeft gecontroleerd

• Bevestigd vanuit de repo — de identiteit van het basismodel en het aantal lagen, de twee adapterrangen en hun doelmodules, de controletoken-id's, het samengestelde aantal parameters, het venster van 131.072 tokens, licentiëring onder Apache-2.0, en de gedocumenteerde vLLM- en Transformers-versies die de kaart vraagt.

• Door de leverancier gerapporteerd, niet gereproduceerd — de scores van de Decision Index, de bewering dat Granite Speech 5.0 TurboCTC het snelste ASR-model op de OpenASR-leaderboard is, de bewering "dezelfde VRAM als het basismodel", en de terloopse opmerking in de lanceringspost dat een aangepast 3B Granite Switch-model Doom speelt met 60–100 beslissingen per seconde tegenover een gerapporteerde 10 per seconde voor een gesloten beslissingsmodel. IBM zegt dat het meer data "in de komende weken" zal publiceren, wat een toegeving is dat het huidige bewijs mager is.

• Niemand heeft het gecontroleerd — al het overige. Er is geen onafhankelijke evaluatie, geen vermelding op een leaderboard van derden, geen gehoste API van IBM, en geen gepubliceerde latentie- of doorvoermeting van iemand anders dan IBM. De Hub-repo toont een paar dozijn downloads en een handvol likes: dit model is twee dagen oud en grotendeels ongelezen.

Wat het kost om te runnen, en waar OrcaRouter past

Granite Switch 4.1 8B is momenteel een self-hostverhaal. De kaart vermeldt HuggingFace Transformers en vLLM als backends, legt een tamelijk smal ondersteuningsvenster vast (Transformers 5.16–5.17, vLLM 0.26–0.28), en het checkpoint werkt met beide zonder codewijzigingen. Er is geen beheerd endpoint om naar te verwijzen, wat voor de meeste teams betekent: één GPU en een container voordat het eerste verzoek er is.

Om eerlijk te zijn over de rest: Granite Switch staat vandaag niet in de OrcaRouter-catalogus, en geen enkel ander Granite-model ook — dus als je dit checkpoint wilt, is de route de eigen release van de leverancier en je eigen hardware, niet wij. Wat OrcaRouter je wél geeft, is het bredere besluit eromheen. Het platform routeert meer dan 200 modellen achter één enkele sleutel met automatische failover, en geeft de lijstprijs van de provider door met 0% opslag, dus wanneer een model dat je aan het benchmarken bent wél een gehost endpoint krijgt, is het vergelijken ervan met de gevestigde partij op je eigen verkeer een configuratiewijziging in plaats van een tweede contract. Dat is juist in deze situatie het belangrijkst: een checkpoint van twee dagen oud zonder onafhankelijke evaluatie is een kandidaat, geen gevestigde partij, en het goedkope dat je met een kandidaat doet, is het in een side-by-side houden in plaats van een productiepad eromheen te herbedraden.

De open vraag

Granite Switch 4.1 8B is een gok dat compositie het wint van schaal voor een specifieke klasse van werk: toepassingen die moeten antwoorden, beslissen en transcriberen, waarbij het draaien van drie modellen drie implementaties, drie latentietijden en drie facturen betekent. De engineering om die gok goedkoop te maken — gedeelde KV-cache, adapteromschakeling per token, control tokens die in de chat-template worden opgelost — is werkelijk ongewoon, en het is het onderdeel van deze release dat over een jaar nog steeds belangrijk zal zijn.

Wat nog niet vaststaat, is of het samengestelde antwoord goed is. Het gepubliceerde profiel van de decision adapter is onevenwichtig, het spraakpad is alleen Engelstalig en niet gezamenlijk getraind, en het geheel is twee dagen oud zonder enige onafhankelijke run erachter. Lees het buildmanifest, voer het compose-commando zelf uit, en benchmark de decision adapter op je eigen labelset voordat je iemands 42,9 gelooft.