Granite Switch 4.1 30B: IBM skar ner tolv adaptrar till två

För fem månader sedan lade IBM upp en förhandsversion av 30B Granite Switch på Hugging Face med tolv adaptrar i den och ett parameterpåslag på 11,68 % jämfört med basmodellen. Den 14 oktober 2026 anlände den färdiga modellen — Granite Switch 4.1 30B — och den har exakt två adaptrar och ett påslag på 3,89 %. Rubriksiffran sjönk med två tredjedelar, och det är lanseringen.

För att vara exakt om vad "anlänt" betyder, eftersom det är här mycket av bevakningen blir slarvig: vikterna landade på Hub den 14 oktober 2026, och IBM:s eget lanseringsinlägg, Granite Switch 4.1: chatt, beslut och tal från en enda slutpunkt, publicerades den 15 oktober. Det är två dagar innan detta skrivs. Det är ett aviserat släpp, inte ett tyst släpp som någon hittade i en spegel, och det är inte en återpublicering av majförhandsvisningen — artefakten är annorlunda, adapterantalet är annorlunda, och ljudvägen fanns inte alls i förhandsvisningen. Det som följer skiljer på vad du kan utläsa från repositoriet och vad bara IBM har sagt.

Vad finns det egentligen i checkpointen?

Granite Switch 4.1 30B är en komposition, inte en ny arkitektur. Den tar Granite 4.1 30B — en dense decoder-only-transformer, fönster på 131 072 tokens, ordförråd på 100 352 tokens — fryser den och monterar på två aktiverade LoRA-adaptrar plus en talencoder. Byggmanifestet är incheckat i repositoryt bredvid vikterna, vilket är varför varje strukturellt påstående nedan är läsbart snarare än rapporterat.

• guardian-core — aLoRA, rank 16, alpha 64, endast kopplad till uppmärksamhetsprojektionerna (k_proj, o_proj, q_proj, v_proj), hämtad från Guardian Library och riktad mot skada, jailbreaking, svordomar, våld, sexuellt innehåll, social bias och oetiskt beteende. Kontrolltoken <|guardian-core|>, id 100352.

• beslut — aLoRA, rank 64, alpha 128, fäst vid alla sju projektioner inklusive MLP:n, och tränad att göra något snävare än chatt: givet ett tillstånd och en fråga med etiketterade alternativ, returnera en kalibrerad sannolikhetsfördelning över dessa etiketter i en framåtpassning. Kontrolltoken <|decision|>, id 100353.

• Tal — granite-speech-5.0-470m-turboctc, en icke-autoregressiv Conformer-CTC-kodare med 470 miljoner parametrar, endast engelska, inkopplad som en ljudinmatningsväg snarare än en andra tjänst.

Viktaritmetiken är den snyggaste siffran i utgåvan. Bas: 28 865 728 512 parametrar. Sammansatt: 29 989 814 272. Skillnaden är 1 124 085 760 parametrar, eller +3,89 %. Du skriver inte kontrolltokens själv — chattmallen infogar dem när du skickar ett adapter_name-argument, vilket innebär att kapacitetsväxling är en förfrågningsparameter i stället för en andra driftsättning.

Förhandsversionen levererades med tolv adaptrar. Släppversionen levereras med två.

Det här är beslutet som är värt att förstå, för vid första anblicken ser det ut som en regression. Förhandsgranskningscheckpointen – fortfarande på Hub, fortfarande Apache-2.0, daterad 5 maj 2026 – innehåller tolv adaptrar från tre Granite Libraries: citation, query rewrite, query clarification, hallucination detection, answerability, factuality detection, policy guardrails, factuality correction, guardian-core, uncertainty, requirement check och context attribution. Det är ett genuint användbart paket, och det är ett paket man måste resonera kring, eftersom tolv adaptrar innebär tolv anropsrecept och tolv olika utdatakontrakt.

Granite Switch 4.1 30B behåller två av dem och lägger till en talencoder. Avvägningen IBM gjorde är läsbarhet i utbyte mot täckning: den färdiga modellen är en chattmodell som också kan besvara en beslutsfråga med en sannolikhet och transkribera ljud, och det är tre saker som en anropare kan hålla i huvudet samtidigt. De andra tio adaptrarna är inte borta – de är fortfarande publicerade, fortfarande komponerbara, och kompositören i granite-switch-repositoriet kommer att bygga en checkpoint åt dig med vilken delmängd du vill, inklusive alla tolv. Det som har ändrats är vad som är påslaget som standard.

Det är en verklig kostnad, och den är värd att namnge snarare än att släta över: om du väntade på att förhandsversionens adaptrar för hallucinationsdetektering och kontextattribuering skulle nå en 1.0-checkpoint, är det inte detta. Det är en smalare modell med lägre overhead, och det är kompositionsverktygen som sluter gapet.

Beslutsadaptern är den hälften som inte är en chattmodell.

Att läsa ut en sannolikhetsfördelning ur en språkmodell är inte nytt. Att göra det i en enda framåtpassning mot en fast uppsättning alternativetiketter, med tal kalibrerade tillräckligt väl för att kunna styra på, är den del som behöver förklaras. Det dokumenterade receptet är en fast systemprompt för besluts-motorn, en Tillstånd: tur utvärderad på den frysta basen, sedan en ### BESLUT tur som presenterar frågan och alternativ med enstaka token-etiketter. Du begär logprobs för exakt dessa etikett-token-id:n och exponentierar. Kortets eget exempel returnerar något i stil med A: 0,982, B: 0,0035, C: 0,014 – och det intressanta är att dessa kom från en vanlig completion-endpoint, inte en klassificerare.

Det finns en teknisk hake som tillkännagivandet hoppar över. Mekanismen för logprob-token-id har en gräns på 128 id:n per begäran, så en beslutsfråga med fler än 128 alternativ misslyckas direkt. Den dokumenterade lösningen är att dela upp etikett-id:na i bitar om 128, skicka en begäran per bit med en identisk prompt och sammanfoga – vilket är matematiskt identiskt med ett anrop utan gräns, eftersom de returnerade logprob-värdena omfattar hela ordförrådet och varje etiketts värde därför inte beror på vilken bit som frågade efter det. En extra begäran per 128 alternativ. Det här är den typ av detalj som bara finns inuti ett kodförråd.

Det enda publicerade numret som är kopplat till adaptern är Decision Index, utgåva v0.3, offentlig snabb delmängd med 1 068 rader: Totalt 50,1, med Kunskap 32,4, Språk 58,6, Sökning 49,8, Verktyg 76,5 och Konst 26,4. Läs formen snarare än rubriken – 76,5 på Verktyg intill 26,4 på Konst är en mycket ojämn profil, och den berättar mer för dig om var det är säkert att rikta in den här adaptern än vad den övergripande siffran gör. IBM rapporterar också att servering av adaptern lokalt och bakom en värdbaserad vLLM-slutpunkt överensstämde inom cirka 0,6 poäng, vilket är en användbar rimlighetskontroll av serveringsvägen även om IBM körde båda halvorna av den.

Tal-till-text, och förbehållet som IBM skrev in i sitt eget kort

Ljudvägen kör transkriptet genom den inbäddade kodaren och fogar in det i chattkontexten i stället för ljudinnehållsdelen, så en begäran med ljud ser ut som en vanlig chat completion med en input_audio-del. Ingen extra talserver, ingen extra latensbudget.

Begränsningarna kommer alla från IBMs egen dokumentation snarare än från en skeptiker: endast engelska, utdata i gemener och utan skiljetecken, ingen styrning vid avkodning, och — den som borde få dig att sakta ner — talencodern och språkmodellen är inte tränade tillsammans. Det finns ingen tränad projektion som kopplar dem samman. En felaktig transkription kan därför ändra vad modellen, eller beslutsadaptern, svarar på, och ingenting i pipelinen kommer att flagga det. Om du driftsätter något där ett transkriptionsfel får konsekvenser, är den meningen hela din hotmodell.

Bekräftat, leverantörsrapporterat, overifierat

• Bekräftat från repositoriet — basmodellens identitet, båda adapterrankarna och deras målmoduler, kontrolltoken-ID:na, det sammansatta parameterantalet och deltat på +3,89 %, fönstret på 131 072 token, Apache-2.0-licensiering samt det fastställda supportfönstret (Transformers 5.16–5.17, vLLM 0.26–0.28, PyTorch 2.11+).

• Leverantörsrapporterat, inte reproducerat — siffrorna för Decision Index, påståendet att Granite Speech 5.0 TurboCTC är den snabbaste ASR-modellen på OpenASR-topplistan, påståendet att den sammansatta modellen förbrukar ungefär lika mycket VRAM som basen, hävdandet att Guardian-adaptern slår flera namngivna slutna beslutsmodeller på säkerhetsrelaterade uppgifter, och sidokommentaren i lanseringsinlägget att ett anpassat 3B Granite Switch-bygge spelade Doom med 60–100 beslut per sekund jämfört med rapporterade 10 per sekund. IBM säger att mer data kommer "under de kommande veckorna", vilket är ett medgivande att dagens bevisunderlag är tunt.

• Ingen har kontrollerat — allt annat. Ingen tredjepartsutvärdering, ingen post på resultattavlan, ingen oberoende mätning av latens eller genomströmning, ingen hostad IBM-slutpunkt. Repositoriet visar en handfull gillamarkeringar och, vid tidpunkten för skrivandet, i praktiken inga nedladdningar. Två dagar gammalt och till stor del oläst.

Var detta befinner sig i en stack

Granite Switch 4.1 30B är en historia om egen drift. Kortet listar Hugging Face Transformers och vLLM, anger ett snävt versionsfönster, och checkpunkten körs på båda utan konvertering. Det finns ingen hanterad slutpunkt, så det praktiska första steget är en GPU och en container.

För att vara ärlig om resten: ingen Granite-modell finns i OrcaRouter-katalogen i dag, så om du vill ha den här checkpointen är vägen IBM:s release och din egen hårdvara. Det plattformen däremot ger dig är det omgivande beslutet — över 200 modeller bakom en enda nyckel med automatisk failover, leverantörens listpris som förs vidare med 0 % påslag — vilket spelar störst roll i precis den här situationen. En två dagar gammal checkpoint utan oberoende utvärdering är en kandidat, inte en sittande modell, och det billiga med en kandidat är att behålla den bredvid modellen som redan är i produktion och jämföra utifrån din egen trafik i stället för att koppla om en produktionsväg runt den.

Den öppna frågan

Satsningen bakom Granite Switch är att komposition slår skala för en specifik typ av arbete – applikationer som svarar, beslutar och transkriberar, där tre modeller innebär tre driftsättningar, tre latenser och tre räkningar. Att dela en KV-cache mellan adaptrar och betala 3,89 % för det är ett genuint ovanligt stycke ingenjörskonst, och det är den delen av den här lanseringen som fortfarande kommer att spela roll om ett år.

Det som inte är avgjort är huruvida det sammansatta svaret är bra. Den publicerade profilen för decision adapter är ojämn, talspåret är enbart engelskt och inte samtränat, och modellen är två dagar gammal utan någon oberoende körning bakom sig. Läs byggmanifestet, sätt ihop din egen delmängd och benchmarka decision adapter mot din egen etikettuppsättning innan du litar på någons 50,1.