Kolibri vs. Granite 4.2 3B: Eine 78B-Sparsity-Wette und das 3B-Modell, das sich weigert, dasselbe Spiel zu spielen

Stellen Sie Kolibri und Granite 4.2 3B nebeneinander, und die erste ehrliche Beobachtung ist, dass dies kein fairer Kampf ist – und nicht in die Richtung, die man vermuten würde. Kolibri ist Aleph Alphas Mixture-of-Experts-Modell mit 78,1 Milliarden Parametern, veröffentlicht am 3. Oktober 2026, das pro Token 3,46 Milliarden Parameter aktiviert. Granite 4.2 3B ist IBMs dichtes Reasoning-Modell mit ungefähr drei Milliarden Parametern, dessen Gewichte am 7. August 2026 auf Hugging Face veröffentlicht wurden, wobei die Modellkarte und der technische Blog am 25. August folgten. Das eine hat 26-mal so viele Gesamtparameter wie das andere. Der Grund, warum sie in dieselbe Entscheidung gehören, ist, dass beide unter Apache 2.0 stehen, beide reine Textmodelle sind, beide von Grund auf für Self-Hosting ausgelegt sind und beide auf denselben Käufer abzielten: ein Team, das Dokumentenintelligenz auf Hardware will, die es selbst kontrolliert, mit der Provenienz, um eine Beschaffungsprüfung zu überstehen. Die interessante Frage ist nicht, welches besser ist. Sie lautet, was das 26-fache Parameterbudget tatsächlich bringt und was es kostet, dieses Gewicht mit sich zu tragen.

Die Diskrepanz, klar ausgedrückt

Granite 4.2 3B ist ein eigenständiges dichtes Modell, das von Granite-4.1-3B-Base nachtrainiert wurde und zur Granite-4.2-Familie gehört, die IBM bis August ausgeliefert hat. Es hat 40 Schichten mit Grouped-Query-Attention, einen nativen Kontext von 128K, den IBM in einer fünften Vor trainierungsphase auf 512K erweitert, sowie drei Denkmodi pro Anfrage: standardmäßig vollständiges Denken, einen Pfad mit geringem Aufwand und einen Pfad ohne Denken. IBMs Modellkarte ist ungewöhnlich offen darüber, was das 3B nicht ist. Anders als seine Geschwister mit 8B und 30B ließ es den spezialisierten agentischen Reinforcement-Learning-Block bewusst aus, der in SWE-agent-, Terminal- und Suchumgebungen trainiert wurde, weshalb IBM für dieses Modell überhaupt keine SWE-bench-Zahl aufführt und es als Reasoning-Spezialisten statt als Agenten darstellt.

Kolibri geht bei jeder Achse den entgegengesetzten Weg. Fünfzig Schichten, jede einzelne davon Mixture-of-Experts, 384 Experten pro Schicht, davon einer geteilt und sechs geroutet, und ein Sparsitätsverhältnis von etwa 22,6 zu 1. Der Kontext umfasst nativ 262.144 Tokens, validiert bis 1.048.576, wobei die Modellkarte empfiehlt, für latenzempfindliche Arbeiten bei 262.144 oder darunter zu bleiben. Vier Stufen für den Reasoning-Aufwand. Hermes-artiges Tool-Calling mit einem vLLM-Parser, der im selben Repository wie die Gewichte ausgeliefert wird. Und einen Speicherbedarf von rund 78 GB in FP8, wobei die Mindestkonfiguration der Modellkarte zwei A100-80-GB-Karten, zwei H100 SXM5, eine H200, eine B200 oder eine B300 umfasst.

• Parameter — Kolibri: 78.103.074.560 insgesamt, 3.457.573.120 aktiv pro Token. Granite 4.2 3B: ungefähr 3B dicht, alle Parameter bei jedem Token aktiv.

• Kontext — Kolibri: 16.384 trainiert, 65.536 mitteltrainiert, 262.144 nativ, 1.048.576 validiert. Granite 4.2 3B: 128K nativ, auf 512K erweitert.

• Denkmodi — Kolibri: keiner, niedrig, mittel, hoch, über die Chat-Vorlage festgelegt. Granite 4.2 3B: vollständig, aufwandsarm und ohne Denken, pro Abfrage.

• Tool-Calling — Kolibri: im Hermes-Stil, mit einem mitgelieferten Parser. Granite 4.2 3B: ja, aber nicht den agentic-RL-trainierten Pfad, den seine größeren Geschwister bekommen haben.

• Sprachen — Kolibri: Deutsch und Englisch, von vornherein und nichts anderes. Granite 4.2 3B: Englisch zuerst, mit IBMs breiterem mehrsprachigem Training dahinter.

• Footprint — Kolibri: etwa 78 GB in FP8, mindestens zwei GPUs. Granite 4.2 3B: rund 6–8 GB in bfloat16, unter 2 GB quantisiert, Laptop-Klasse.

• Lizenz — beide Apache 2.0, beide ohne eine Zusatzklausel zur akzeptablen Nutzung oder eine Schwelle für monatlich aktive Nutzer.

• Serving — Kolibri: das aleph-alpha-inference vLLM-Plugin oder das veröffentlichte Container-Image. Granite 4.2 3B: vLLM, SGLang, Transformers, GGUF und Ollama unter granite4.2:3b.

Was die zusätzlichen 75 Milliarden Parameter bringen

Drei Dinge – es lohnt sich, genau zu unterscheiden, welche davon gesichert und welche behauptet sind.

Der erste Punkt ist Deutsch. Dies ist der deutlichste reale Unterschied zwischen den beiden Modellen, und er ist keine Benchmark-Zeile. Aleph Alpha baute Kolibri um ein zweisprachiges deutsch-englisches Korpus herum auf, mit dem Ziel, in einem Pre-Training-Durchlauf mit 20 Billionen Tokens ungefähr 20 Prozent Deutsch zu erreichen, und landete bei einem deutschen Pool von 2,4 Billionen Tokens, von denen das Labor 80 Prozent selbst kuratiert oder generiert hatte. Die Modellkarte erklärt, warum das Arbeit erforderte: Deduplizierte offene deutsche Datensätze lieferten nur 390 Milliarden Tokens – eine Größenordnung zu wenig –, also stimmte das Labor einen Filter für Common Crawl speziell auf Deutsch neu ab und formulierte bestehende deutsche Dokumente zu Enzyklopädie-Einträgen, Dialogen und Passagen um. Das Filterdetail ist der Punkt, den man sich merken sollte. Eine Standard-Pipeline für Sprachdaten verwirft Dokumente mit zu vielen langen Wörtern, und deutsche Verwaltungssprache überschreitet regelmäßig die englische Grenze für die durchschnittliche Wortlänge – daher löschen Standardeinstellungen still und leise das Register, in dem die öffentliche Verwaltung schreibt. IBM hat Granite nicht für dieses Korpus gebaut. Granite 4.2 3B wird mit Deutsch zurechtkommen; es wurde nicht auf das deutsche Rechts- und Verwaltungsregister hin ausgelegt, und kein Leaderboard wird Ihnen den Unterschied verraten.

Das Zweite ist langer Kontext, der echten Dokumenten standhält. Granites 512K-Obergrenze ist wirklich groß, doch die beiden Modelle sind auf unterschiedliche Weise dorthin gelangt, und Kolibris Positionsdesign ist das konventionellere Langkontext-Argument. Betrachten Sie IBMs RULER-Zahlen — 67,52 bei 64K und 55,30 bei 128K im veröffentlichten Material der 4.2-Familie — als die ehrliche Offenlegung dessen, wie stark die Retrieval-Qualität bis 128K nachlässt, und denken Sie daran, dass Kolibri überhaupt keine entsprechende veröffentlichte Verschlechterungskurve hat.

Der dritte Punkt ist rohe Reasoning-Reserve, und hier ist die ehrliche Antwort „nicht so viel, wie das Parameterverhältnis nahelegt“. Kolibris Trainingspipeline verschaffte ihm einen Pre-Training-Lauf über 20 Billionen Token auf 768 NVIDIA B200s über 21 Tage hinweg, und Aleph Alphas eigene Vergleichstabelle, mit Kolibri bei hohem Reasoning-Aufwand, weist es mit 75,5 im englischen Durchschnitt und 70,8 im deutschen Durchschnitt eines Vergleichs von vierzehn Modellen aus — wo es in den meisten Zeilen gegen ein dichtes Modell mit 27 Milliarden Parametern von Alibaba verliert. Die Schlagzeilen-Angaben von Granite 4.2 3B sind seine eigenen: AIME 2025 mit 78,33, GPQA mit 54,80, LiveCodeBench v6 mit 69,71 und MMLU-Pro mit 67,84, alle von IBM gemeldet und nicht reproduziert. Verschiedene Suites, verschiedene Harnesses, verschiedene Anbieter. Es gibt nirgendwo eine Zahl aus demselben Harness für diese Paarung, und wir werden keine erfinden.

Wo jedes einzelne tatsächlich gewinnt

Führe Granite 4.2 3B aus, wenn deine Einschränkung die Maschine ist. Mit 6–8 GB in bfloat16 oder unter 2 GB quantisiert passt es auf einen Laptop, eine einzelne Workstation-GPU oder eine abgeschottete Edge-Box, die niemals zwei H100s zu Gesicht bekommen wird. Es lässt sich über fünf verschiedene Runtimes betreiben, darunter Ollama und GGUF, was zählt, wenn das Bereitstellungsziel der Laptop von jemand anderem und nicht dein eigenes Rack ist. Und seine Modellkarte ist ungewöhnlich vertrauenswürdig, gerade weil IBM aufgeschrieben hat, was es weggelassen hat. Ein Anbieter, der darauf verzichtet, SWE-bench-Ergebnisse für ein 3B-Modell zu beanspruchen, sagt dir, wo die Grenzen des Modells liegen.

Führen Sie Kolibri aus, wenn es auf den Korpus ankommt und die Hardware vorhanden ist. Ein Team mit deutschsprachigen Verträgen, technischer Dokumentation oder behördlichen Einreichungen, einem vorhandenen Zwei-GPU-Knoten und der Anforderung, dass die Gewichte das Gebäude nie verlassen, ist genau die Zielgruppe, für die dieses Release konzipiert wurde. Das native Fenster von 262.144 Token, der FP8-KV-Cache, die vier Aufwandsstufen und der Hermes-Tool-Aufrufpfad deuten alle auf Dokument-Workflows statt auf Chat hin. Der bilinguale Tokenizer ist Teil desselben Arguments: Aleph Alpha berichtet 4,90 durchschnittliche Bytes pro Token bei deutschem Webtext gegenüber 4,35 für GPT-5 und 3,28 für Kimi K3, alle vom Anbieter auf dessen eigenem Korpus gemessen, und mehr Zeichen pro Token sind ein direkter Inferenzkosteneffekt und keine Punktzahl. Wenn das zutrifft, summiert es sich über jede Seite, die Sie verarbeiten.

Die Asymmetrie, die niemand bewirbt, sind die Daten. IBM veröffentlichte die Gewichte von Granite 4.2 3B und eine detaillierte technische Darstellung dazu, wie das Modell entwickelt wurde, aber nicht die Trainingsdaten. Aleph Alpha veröffentlichte die Pipeline, die Datenherkunft und die Energieangabe zusammen mit Kolibris Gewichten – 20 Billionen Pre-Training-Token, 9,5×10² MWh einschließlich Rechenzentrums-Overhead und ohne überwachtes Feintuning und bestärkendes Lernen. Für ein Team, das die Frage beantworten muss, „woher der Text dieses Modells stammt“, ist dieser Unterschied nicht kosmetisch.

Die Routing-Realität für beide

Keines der beiden Modelle ist heute in einem gehosteten Katalog vertreten. Kolibri hat überhaupt keine Anbieter-API-SKU – die Veröffentlichung besteht aus Gewichten plus einem technischen Bericht –, und Granite 4.2 3B wird als Gewichte für fünf Runtime-Stacks ausgeliefert, ohne gehosteten Endpunkt von IBM. Beide sind Self-Hosting-Optionen, und die praktische Frage für die meisten Teams ist nicht, welches sie übernehmen sollen, sondern ob der Workload es rechtfertigt, eines der beiden zu betreiben.

Dort verdient sich eine Routing-Schicht ihren Platz, sogar für Modelle, die sie gar nicht führt. Wir haben den OrcaRouter-Katalog unter jeder Schreibweise beider Modellnamen durchsucht, und weder Kolibri noch Granite 4.2 3B ist dort zu finden, also werden wir nichts anderes vorgeben. Was OrcaRouter Ihnen bietet, ist der günstige Weg, herauszufinden, ob die Hardware-Entscheidung gerechtfertigt ist, bevor Sie sie treffen: Richten Sie einen Testpfad auf eine kleine Mixture-of-Experts-Stufe, die bereits geroutet wird – die Gemma 4 26B-A4B-Variante zu 0,06 $ pro Million Eingabe-Tokens und 0,33 $ pro Million Ausgabe-Tokens, mit einem Fenster von 262.144 Tokens – und prüfen Sie, ob Ihr deutsches Dokumenten-Workload tatsächlich braucht, was Kolibri bietet, auf einem OpenAI-kompatiblen Schlüssel, zum Listenpreis des Anbieters, ohne dass etwas hinzukommt. Wenn ja, kaufen Sie die GPUs mit Belegen statt aus dem Bauch heraus. Wenn nicht, haben Sie gerade eine Hardware-Bestellung eingespart.

Das Urteil – und was es ändern würde

Das ist kein Duell mit einem Sieger. Kolibri und Granite 4.2 3B beantworten unterschiedliche Fragen zu unterschiedlichen Preispunkten, und das einzig ehrliche Ranking erfolgt nach der Randbedingung: Wenn die Randbedingung Hardware ist, ist Granite 4.2 3B der einzige der beiden, der infrage kommt. Wenn die Randbedingung deutschsprachige Dokumentenarbeit im regulatorischen Register vor Ort ist, war Granite 4.2 3B nie im Rennen, und Kolibri ist das interessantere Artefakt – eine legitime Open-Weights-Veröffentlichung mit 78B, Apache 2.0, bei der Datenpipeline und Tokenizer neben den Gewichten veröffentlicht wurden.

Zwei Dinge würden den Vergleich entscheiden. Ein unabhängiger Lauf von Kolibri auf einer deutschen Dokumenten-QA-Aufgabe würde die Behauptung prüfen, für die das Release tatsächlich gebaut wurde, da derzeit keine Bestenliste sie misst. Und eine unabhängige Reproduktion der Reasoning-Zahlen von Granite 4.2 3B würde Ihnen sagen, ob ein Rechner der Laptop-Klasse bei der Teilmenge Ihrer Arbeitslast mithalten kann, die von vornherein nie 78 Milliarden Parameter gebraucht hat. Bis eines davon vorliegt, kaufen Sie nach Einschränkung, nicht nach Parameterzahl.