Granite Switch 4.1 8B: Ein 8B-Checkpoint, der chattet, entscheidet und transkribiert

Acht Milliarden dreihundertachtzig Millionen Parameter gehen hinein. Acht Milliarden siebenhundertsechsundsiebzig Millionen kommen heraus. Diese 4,72 % sind der ganze Unterschied zwischen IBMs Basismodell und Granite Switch 4.1 8B, und sie ist die interessanteste Zahl im Release, denn in diesem Bruchteil stecken ein Sicherheitsklassifikator, eine Entscheidungsmaschine und ein Spracherkenner – alle antworten von einem einzigen Endpunkt aus, alle lesen und schreiben denselben KV-Cache, den das Basismodell ohnehin aufgebaut hätte.

Die Gewichte landeten am 14. Oktober 2026 auf Hugging Face. IBMs eigener Launch-Blog, Granite Switch 4.1: Chat, Entscheidungen und Sprache von einem einzigen Endpunkt, folgte am 15. Oktober, was man gleich zu Beginn klar sagen sollte: Dies ist kein leiser Drop, den jemand auf einem Mirror gefunden hat. Es ist eine angekündigte Veröffentlichung, die zum Zeitpunkt des Schreibens ungefähr zwei Tage alt ist, und die Version der Geschichte, auf die es ankommt, ist nicht „was hat IBM behauptet“, sondern „was kann man tatsächlich anhand des Checkpoints, der gerade jetzt auf dem Hub liegt, verifizieren“. Diese beiden Dinge sind nicht dasselbe, und dieser Beitrag hält sie auseinander.

Was der Checkpoint tatsächlich enthält

Granite Switch ist keine neue Architektur. Es ist eine Komposition: ein eingefrorenes Basismodell, eine Reihe von Low-Rank-Adaptern, die pro Token ein- und ausgeschaltet werden können, und – in diesem speziellen Build – ein Encoder, der für Audio angeschraubt wurde. Der Composer lebt im granite-switch-Repository, und das Build-Manifest für diesen Checkpoint ist neben den Gewichten eingecheckt, was bedeutet, dass jede strukturelle Behauptung unten direkt vom Hub ablesbar ist, statt aus einer Pressemitteilung übernommen zu sein.

Die Basis ist Granite 4.1 8B — dichtes Decoder-only, gruppierte Query-Attention mit 32 Query-Heads gegenüber 8 Key/Value-Heads, SwiGLU, RMSNorm, ein Kontextfenster von 131.072 Token und ein Vokabular von 100.352 Token. Der zusammengesetzte Checkpoint erbt all das und fügt zwei aktivierte LoRA-Adapter hinzu:

• guardian-core — Rang 16, Alpha 64, ausschließlich an die Attention-Projektionen angehängt (k_proj, o_proj, q_proj, v_proj), aus dem Guardian Library-Release übernommen und beschrieben als Erkennung von Schaden, Jailbreaking, Vulgärsprache, Gewalt, sexuellen Inhalten, sozialer Voreingenommenheit und unethischem Verhalten.

• Entscheidung — Rang 64, Alpha 128, an alle sieben Projektionen angehängt, einschließlich des MLP (down_proj, gate_proj, up_proj), und darauf trainiert, etwas Engeres und Seltsameres zu tun: bei einem Zustand und einer Frage mit beschrifteten Optionen in einem einzigen Vorwärtsdurchlauf eine kalibrierte Wahrscheinlichkeitsverteilung über diese Optionslabels zurückgeben.

Beide werden durch Steuerungs-Token aktiviert — <|guardian-core|> und <|decision|> — welche die Chat-Vorlage für dich einfügt, wenn du ein adapter_name-Argument übergibst. Du schreibst die Token nicht selbst, und dieses Detail ist wichtiger, als es aussieht: Es bedeutet, dass die Adapter-Auswahl ein Request-Parameter ist, kein zweites Modell, das bereitgestellt werden muss.

Warum ist das Parameter-Delta so klein?

Die Arithmetik ist die Geschichte. Das Basismodell hat 8.380.551.168 Parameter. Das zusammengesetzte Modell hat 8.776.400.896. Das sind +395,8 Millionen bzw. +4,72 % für zwei Adapter. Der Grund, warum die Zahl so niedrig bleibt, ist eine Designentscheidung namens KV-Cache-Normalisierung: Jeder Adapter sieht den Key/Value-Cache des Basismodells, anstatt einen eigenen zu pflegen. In einem herkömmlichen Multi-Adapter-Setup ist jeder zusätzliche Adapter ein zweiter Satz Attention-Zustand, und die Speicherrechnung wächst mit der Anzahl der Adapter, zwischen denen man wechselt. Hier ist das nicht so. IBMs Behauptung im Launch-Post ist, dass das zusammengesetzte Modell „ungefähr so viel VRAM auf einer GPU belegt wie das Basismodell allein“, und obwohl das noch niemand außerhalb von IBM gemessen hat, ist das Gewichts-Delta von 4,72 % damit konsistent – und anders als die VRAM-Behauptung ist das Gewichts-Delta einfach eine Zahl in einem Manifest, das man lesen kann.

Der Entscheidungsadapter ist die interessante Hälfte

Das Auslesen einer Wahrscheinlichkeitsverteilung aus einem Sprachmodell ist nicht neu; es in einem einzigen Vorwärtsdurchlauf mit einem festen Vokabular von Optionslabels durchzuführen und dabei Zahlen zu erhalten, die ausreichend kalibriert sind, um darauf zu handeln, ist der Teil, den es zu verstehen lohnt. Das Aufrufrezept ist in der Karte dokumentiert: ein fester System-Prompt für die Entscheidungs-Engine, ein State:-Turn, der auf der eingefrorenen Basis ausgewertet wird, dann ein ### DECISION-Turn, der die Frage und Optionen mit Single-Token-Labels präsentiert. Dann bitten Sie den Server um die Logprobs genau dieser Label-Token-IDs — vLLM stellt dies über logprob_token_ids bereit — und exponenzieren. Das dokumentierte Beispiel liefert etwa A: 0.982, B: 0.0035, C: 0.014.

Hier gibt es eine echte technische Feinheit, die die Marketingversion dieses Releases auslässt. vLLM begrenzt logprob_token_ids auf 128 IDs pro Anfrage. Wenn Ihre Entscheidungsfrage mehr als 128 Optionen hat, erhalten Sie einen HTTP 400, und die Lösung besteht darin, die Label-IDs in Blöcke von 128 aufzuteilen, eine Anfrage pro Block mit identischem Prompt zu stellen und zu verketten – denn die zurückgegebenen Logprobs beziehen sich auf das gesamte Vokabular, der Wert jedes Labels ist unabhängig davon, welcher Chunk ihn angefordert hat, sodass eine einzelne Softmax über die vollständige Label-Menge mathematisch identisch mit einem ungekappten Aufruf ist. Das ist eine zusätzliche Anfrage pro 128 Optionen. Es ist ein wirklich nützliches Detail, und es ist genau die Art von Sache, die es nur im Repo gibt.

Die einzige veröffentlichte Zahl zu diesem Adapter ist der Decision Index (JEV), Edition v0.3, öffentliches Fast-Subset mit 1.068 Zeilen: Gesamt 42,9, Wissen 29,1, Sprache 48,9, Retrieval 49,8, Werkzeuge 59,8, Kunst 18,0. Betrachten Sie das als Anbieterangabe, denn genau das ist es: IBM hat es durchgeführt und veröffentlicht, und kein Dritter hat es reproduziert. Es lohnt sich außerdem, eher das Profil als die Schlagzeile zu lesen — 59,8 bei Werkzeugen neben 18,0 bei Kunst ist ein sehr unausgewogenes Profil, und die Modellkarte selbst warnt, dass es sich bei den Optionswahrscheinlichkeiten in Domänen, für die der Adapter nicht trainiert wurde, um „ein Prior zur Entscheidungsfindung, keine zertifizierte Klassifikation“ handelt.

Speech-to-Text ist real – und enger gefasst, als die Schlagzeile suggeriert.

Der Audio-Pfad bettet Granite Speech 5.0 TurboCTC ein, einen nicht-autoregressiven Conformer-CTC-Encoder mit 470 Mio. Parametern, und transkribiert eingehendes Audio, bevor das Transkript anstelle des Audio-Inhaltsteils in den Chat-Kontext eingefügt wird. Ein Aufruf ändert die Form der Anfrage nicht: Es ist ein input_audio-Inhaltsteil bei einer normalen Chat-Vervollständigung, und die Transkription läuft auf demselben Endpunkt wie Chat und Entscheidungen, sodass kein zweiter Sprachserver bereitgestellt werden muss.

Die Einschränkungen, alle aus IBMs eigener Modellkarte und nicht von einem Kritiker: Der Encoder ist ausschließlich für Englisch ausgelegt, seine Ausgabe ist in Kleinbuchstaben und ohne Interpunktion, es gibt keine Steuerung zur Dekodierzeit, und — der Punkt, der Sie stoppen sollte — der Sprach-Encoder und das LLM sind nicht gemeinsam trainiert. Es gibt keine trainierte Projektion, die sie koppelt. Eine Fehltranskription kann daher unbemerkt verändern, worauf das Modell oder ein Adapter reagiert. Wenn Sie irgendetwas bauen, bei dem ein Transkriptionsfehler Konsequenzen hat, ist dieser Satz die gesamte Sicherheitsüberprüfung.

Was bestätigt ist, was vom Anbieter angegeben wird, was niemand geprüft hat

• Aus dem Repository bestätigt — Identität des Basismodells und Layer-Anzahl, die beiden Adapter-Ranks und ihre Zielmodule, die Control-Token-IDs, die zusammengesetzte Parameteranzahl, das Fenster von 131.072 Token, die Apache-2.0-Lizenzierung sowie die dokumentierten vLLM- und Transformers-Versionen, die die Model Card verlangt.

• Vom Anbieter angegeben, nicht reproduziert — die Decision-Index-Werte, die Behauptung, dass Granite Speech 5.0 TurboCTC das schnellste ASR-Modell auf der OpenASR-Bestenliste sei, die Aussage „derselbe VRAM wie das Basismodell“ und die beiläufige Bemerkung im Launch-Post, dass ein maßgeschneidertes 3B-Granite-Switch-Modell Doom mit 60–100 Entscheidungen pro Sekunde spiele, gegenüber berichteten 10 pro Sekunde bei einem geschlossenen Entscheidungsmodell. IBM sagt, es werde „in den kommenden Wochen“ weitere Daten veröffentlichen, was ein Eingeständnis ist, dass die derzeitige Beweislage dünn ist.

• Niemand hat es überprüft — alles andere. Es gibt keine unabhängige Bewertung, keinen Eintrag in einem Leaderboard eines Drittanbieters, keine gehostete API von IBM und keine veröffentlichte Latenz- oder Durchsatzmessung von irgendjemandem, der nicht IBM ist. Das Hub-Repo zeigt ein paar Dutzend Downloads und eine Handvoll Likes: Dieses Modell ist zwei Tage alt und weitgehend ungelesen.

Was der Betrieb kostet und wo OrcaRouter passt

Granite Switch 4.1 8B ist derzeit eine Self-Host-Story. Die Karte listet HuggingFace Transformers und vLLM als Backends auf, legt ein ziemlich enges Support-Fenster fest (Transformers 5.16–5.17, vLLM 0.26–0.28), und der Checkpoint funktioniert mit beiden ohne Codeänderungen. Es gibt keinen verwalteten Endpunkt, auf den man zeigen kann, was für die meisten Teams eine GPU und einen Container vor der ersten Anfrage bedeutet.

Um beim Rest ehrlich zu sein: Granite Switch ist heute nicht im OrcaRouter-Katalog, und ebenso wenig irgendein anderes Granite-Modell — wenn Sie also diesen Checkpoint wollen, läuft der Weg über die Veröffentlichung des Anbieters selbst und Ihre eigene Hardware, nicht über uns. Was OrcaRouter Ihnen gibt, ist die Entscheidung drumherum. Die Plattform routet mehr als 200 Modelle hinter einem einzigen Schlüssel mit automatischem Failover, und reicht den Listenpreis des Anbieters mit 0 % Aufschlag durch, sodass, wenn ein Modell, das Sie gerade benchmarken, dann doch einen gehosteten Endpunkt erhält, der Vergleich mit dem Platzhirsch auf Ihrem eigenen Traffic eine Konfigurationsänderung statt eines zweiten Vertrags ist. Das zählt genau in dieser Situation am meisten: Ein zwei Tage alter Checkpoint ohne unabhängige Bewertung ist ein Kandidat, kein Platzhirsch, und das Günstigste, was man mit einem Kandidaten tun kann, ist, ihn in einem Direktvergleich zu belassen, statt einen Produktionspfad um ihn herum neu zu verdrahten.

Die offene Frage

Granite Switch 4.1 8B ist eine Wette darauf, dass Komposition bei einer bestimmten Klasse von Arbeit mehr zählt als Skalierung: Anwendungen, die antworten, entscheiden und transkribieren müssen, bei denen drei Modelle zu betreiben drei Deployments, drei Latenzen und drei Rechnungen bedeutet. Die Ingenieursleistung, die diese Wette günstig macht – gemeinsam genutzter KV-Cache, Adapter-Umschaltung pro Token, im Chat-Template aufgelöste Steuer-Tokens –, ist wirklich ungewöhnlich, und sie ist der Teil dieses Releases, der auch in einem Jahr noch relevant sein wird.

Was noch nicht geklärt ist, ist, ob die zusammengesetzte Antwort gut ist. Das veröffentlichte Profil des Entscheidungsadapters ist unausgewogen, der Sprachpfad ist ausschließlich englischsprachig und nicht gemeinsam trainiert, und das Ganze ist zwei Tage alt, ohne dass ein unabhängiger Durchlauf dahintersteht. Lies das Build-Manifest, führe den Compose-Befehl selbst aus und benchmarke den Entscheidungsadapter anhand deines eigenen Labelsets, bevor du irgendwem seine 42,9 glaubst.