Kolibri vs Granite 4.2 3B: Een 78B-sparsiteitsweddenschap, en het 3B-model dat weigert hetzelfde spel te spelen

Zet Kolibri en Granite 4.2 3B naast elkaar en de eerste eerlijke observatie is dat dit geen eerlijke strijd is, en niet in de richting die je zou verwachten. Kolibri is het 78,1 miljard parameters tellende mixture-of-expertsmodel van Aleph Alpha, uitgebracht op 3 oktober 2026, dat per token 3,46 miljard parameters activeert. Granite 4.2 3B is het ongeveer drie miljard parameters tellende dichte redeneermodel van IBM, waarvan de gewichten op 7 augustus 2026 op Hugging Face verschenen, met de modelkaart en technische blog die op 25 augustus volgden. De ene heeft zesentwintig keer zoveel totale parameters als de andere. De reden dat ze in dezelfde beslissing thuishoren, is dat beide Apache 2.0 zijn, beide tekst-only zijn, beide ontworpen zijn voor self-hosting, en beide op dezelfde koper zijn gericht: een team dat documentintelligentie wil op hardware die het zelf beheert, met de herkomst om een inkoopbeoordeling te doorstaan. De interessante vraag is niet welke beter is. Het is wat het parameterbudget dat zesentwintig keer zo groot is daadwerkelijk oplevert, en wat het kost om dat te dragen.

De mismatch, eenvoudig gesteld

Granite 4.2 3B is een zelfstandig dense model dat is nagetraind op basis van Granite-4.1-3B-Base, onderdeel van de Granite 4.2-familie die IBM tot en met augustus uitbracht. Het heeft 40 lagen met grouped-query attention, een native context van 128K die IBM in een vijfde pre-trainingfase uitbreidt naar 512K, en drie denkmodi per query: standaard volledig denken, een low-effort-pad en een non-thinking-pad. IBM's modelkaart is ongewoon openhartig over wat de 3B niet is. Anders dan de 8B- en 30B-modellen in dezelfde familie, sloeg het bewust het gespecialiseerde agentische reinforcement-learningblok over dat is getraind in SWE-agent-, terminal- en zoekomgevingen. Daarom vermeldt IBM er helemaal geen SWE-bench-cijfer voor en positioneert het model als een redeneerspecialist in plaats van een agent.

Kolibri gaat op elke as precies de andere kant op. Vijftig lagen, allemaal mixture-of-experts, 384 experts per laag met één gedeelde en zes gerouteerde, en een sparsityratio van ongeveer 22,6 op 1. De context is native 262.144 tokens, gevalideerd tot 1.048.576, waarbij de kaart aanraadt om voor latentiegevoelig werk op of onder 262.144 te blijven. Vier niveaus van reasoning-inspanning. Tool calling in Hermes-stijl met een vLLM-parser die in dezelfde repository als de gewichten wordt meegeleverd. En een voetafdruk van ongeveer 78 GB in FP8, waarbij de minimale configuratie volgens de kaart twee A100 80 GB-kaarten, twee H100 SXM5's, één H200, één B200 of één B300 is.

• Parameters — Kolibri: 78.103.074.560 totaal, 3.457.573.120 actief per token. Granite 4.2 3B: ongeveer 3B dense, alle parameters actief bij elke token.

• Context — Kolibri: 16.384 getraind, 65.536 mid-getraind, 262.144 native, 1.048.576 gevalideerd. Granite 4.2 3B: 128K native, uitgebreid naar 512K.

• Denkmodi — Kolibri: geen, laag, gemiddeld, hoog, ingesteld via het chatsjabloon. Granite 4.2 3B: volledig, low-effort en niet-denkend, per query.

• Tool calling — Kolibri: Hermes-stijl, met een meegeleverde parser. Granite 4.2 3B: ja, maar niet het agentic-RL-getrainde pad dat zijn grotere broers en zussen kregen.

• Talen — Kolibri: Duits en Engels, per ontwerp en niets anders. Granite 4.2 3B: Engels-eerst, met IBM's bredere meertalige training erachter.

• Voetafdruk — Kolibri: ongeveer 78 GB in FP8, minimaal twee GPU's. Granite 4.2 3B: ruwweg 6–8 GB in bfloat16, onder 2 GB gekwantiseerd, laptopklasse.

• Licentie — beide Apache 2.0, beide zonder een aanvullend beding voor acceptabel gebruik of een drempel voor maandelijks actieve gebruikers.

• Serveren — Kolibri: de aleph-alpha-inference vLLM-plugin of de gepubliceerde containerimage. Granite 4.2 3B: vLLM, SGLang, Transformers, GGUF en Ollama onder granite4.2:3b.

Wat de extra 75 miljard parameters opleveren

Drie dingen, en het is de moeite waard om precies te zijn over welke daarvan vaststaan en welke worden beweerd.

De eerste is Duits. Dit is het scherpste echte verschil tussen de twee modellen, en het is geen benchmarkrij. Aleph Alpha bouwde Kolibri rond een tweetalig Duits-Engels corpus, met als doel ongeveer 20 procent Duits in een pre-trainingrun van 20 biljoen tokens, en eindigde met een Duitse pool van 2,4 biljoen tokens, waarvan 80 procent door het lab zelf was gecureerd of gegenereerd. De modelkaart legt uit waarom dat werk kostte: gededupliceerde open Duitse datasets leverden slechts 390 miljard tokens, een orde van grootte te weinig, dus het lab stemde een Common Crawl-filter opnieuw af, specifiek voor het Duits, en herformuleerde bestaande Duitse documenten tot encyclopedieartikelen, dialoog en passages. Het filterdetail is wat je moet onthouden. Een standaard pijplijn voor taaldata laat documenten met te veel lange woorden vallen, en het Duitse bestuurlijke proza overschrijdt stelselmatig de Engelse grens voor gemiddelde woordlengte — dus standaardinstellingen verwijderen stilletjes het register waarin het openbaar bestuur schrijft. IBM bouwde Granite niet voor dat corpus. Granite 4.2 3B zal met Duits omgaan; het is niet ontworpen rond het Duitse juridische en bestuurlijke register, en geen enkele ranglijst zal je het verschil laten zien.

Het tweede is een lange context die echte documenten doorstaat. Het plafond van 512K van Granite is werkelijk groot, maar de twee modellen bereikten dat op verschillende manieren, en het positionele ontwerp van Kolibri is het meer conventionele argument voor lange context. Beschouw de RULER-cijfers van IBM — 67,52 bij 64K en 55,30 bij 128K in het gepubliceerde materiaal van de 4.2-familie — als de eerlijke onthulling van hoeveel de retrievalkwaliteit tegen 128K afneemt, en onthoud dat Kolibri helemaal geen equivalente gepubliceerde degradatiecurve heeft.

De derde is ruwe redeneerruimte, en hier is het eerlijke antwoord "niet zoveel als de parameterverhouding suggereert". Kolibri's trainingspijplijn leverde het een pre-trainingrun van 20 biljoen tokens op 768 NVIDIA B200's gedurende 21 dagen op, en Aleph Alpha's eigen vergelijkingstabel, met Kolibri op redeneerinspanning hoog, plaatst het op 75,5 op het Engelse gemiddelde en 70,8 op het Duitse gemiddelde van een vergelijking van veertien modellen — waar het op de meeste rijen verliest van een dense model met 27 miljard parameters van Alibaba. De kopclaims van Granite 4.2 3B zijn de zijne: AIME 2025 op 78,33, GPQA op 54,80, LiveCodeBench v6 op 69,71 en MMLU-Pro op 67,84, allemaal door IBM gerapporteerd en niet gereproduceerd. Verschillende suites, verschillende harnassen, verschillende leveranciers. Er is nergens een getal uit hetzelfde harnas voor deze combinatie, en we gaan er geen verzinnen.

Waar elk van hen daadwerkelijk wint

Draai Granite 4.2 3B als je beperking de machine is. Met 6–8 GB in bfloat16, of onder 2 GB gekwantiseerd, past het op een laptop, een enkele workstation-GPU of een air-gapped edge-box die nooit twee H100's zal zien. Het draait via vijf verschillende runtimes, waaronder Ollama en GGUF, wat van belang is wanneer het deploymentdoel de laptop van iemand anders is in plaats van je eigen rack. En de modelkaart ervan is ongewoon betrouwbaar, juist omdat IBM heeft opgeschreven wat het wegliet. Een leverancier die weigert SWE-bench-resultaten voor een 3B te claimen, vertelt je waar het model stopt.

Draai Kolibri als het corpus het punt is en de hardware aanwezig is. Een team met Duitstalige contracten, technische documentatie of administratieve stukken, een bestaande node met twee GPU's, en de eis dat de gewichten nooit het gebouw verlaten, is precies voor wie deze release is ontworpen. Het native contextvenster van 262.144 tokens, de FP8-KV-cache, de vier inspanningsniveaus en het Hermes-pad voor toolaanroepen wijzen allemaal op documentworkflows in plaats van chat. De tweetalige tokenizer maakt deel uit van hetzelfde argument: Aleph Alpha rapporteert gemiddeld 4,90 bytes per token op Duitse webtekst tegenover 4,35 voor GPT-5 en 3,28 voor Kimi K3, allemaal door de leverancier gemeten op het corpus van de leverancier, en meer tekens per token is een direct effect op de inferentiekosten in plaats van een score. Als dit standhoudt, stapelt het effect zich op bij elke pagina die je verwerkt.

De asymmetrie waar niemand ruchtbaarheid aan geeft, is data. IBM publiceerde de gewichten van Granite 4.2 3B en een gedetailleerd technisch verslag van hoe het model werd gebouwd, maar niet de trainingsdata. Aleph Alpha publiceerde de pipeline, de herkomst van de data en het energiecijfer naast de gewichten van Kolibri — 20 biljoen pre-trainingtokens, 9,5×10² MWh inclusief overhead van datacenters en exclusief supervised fine-tuning en reinforcement learning. Voor een team dat moet kunnen antwoorden "waar komt de tekst van dit model vandaan", is dat verschil niet cosmetisch.

De routeringsrealiteit voor beide

Geen van beide modellen staat vandaag in een gehoste catalogus. Kolibri heeft helemaal geen API-SKU van een leverancier — de release bestaat uit gewichten plus een technisch rapport — en Granite 4.2 3B wordt geleverd als gewichten voor vijf runtime-stacks, zonder gehost endpoint van IBM. Bij beide gaat het om self-hosting, en de praktische vraag voor de meeste teams is niet welke van de twee ze moeten adopteren, maar of de workload het rechtvaardigt om een van beide in eigen beheer te nemen.

Dat is waar een routeringslaag zijn plek verdient, zelfs voor modellen die er niet in staan. We hebben de OrcaRouter-catalogus doorzocht onder elke spelling van beide modelnamen en noch Kolibri noch Granite 4.2 3B staat erin, dus we zullen niet doen alsof het anders is. Wat OrcaRouter je wél biedt, is de goedkope manier om erachter te komen of de hardwarebeslissing gerechtvaardigd is voordat je die neemt: richt een testpad op een klein mixture-of-experts-niveau dat al wordt gerouteerd — de Gemma 4 26B-A4B-variant tegen $0,06 per miljoen invoertokens en $0,33 per miljoen uitvoertokens, met een venster van 262.144 tokens — en kijk of je Duitse documentworkload echt nodig heeft wat Kolibri biedt, op één OpenAI-compatibele sleutel, tegen de lijstprijs van de provider zonder dat er iets bijkomt. Als dat zo is, koop je de GPU's met bewijs in plaats van op gevoel. Als dat niet zo is, heb je net een hardwarebestelling uitgespaard.

Het oordeel, en wat het zou veranderen

Dit is geen wedstrijd met een winnaar. Kolibri en Granite 4.2 3B beantwoorden verschillende vragen in verschillende prijsklassen, en de enige eerlijke rangschikking is op basis van de beperkende factor: als de beperking hardware is, is Granite 4.2 3B de enige van de twee die in aanmerking komt. Als de beperking het werken met Duitse documenten uit regelgevingsregisters op eigen locatie is, deed Granite 4.2 3B nooit mee en is Kolibri het interessantere artefact — een legitieme open-weights release van 78B, Apache 2.0, met de datapijplijn en tokenizer naast de weights gepubliceerd.

Twee dingen zouden de vergelijking beslechten. Een onafhankelijke run van Kolibri op een Duitse document-QA-taak zou de claim testen die de release eigenlijk moest waarmaken, aangezien geen enkel leaderboard dat momenteel meet. En een onafhankelijke reproductie van de reasoningcijfers van Granite 4.2 3B zou je vertellen of een laptopklasse-machine zich staande kan houden op het deel van je workload dat sowieso nooit 78 miljard parameters nodig had. Tot een van die twee beschikbaar is: koop op basis van beperkingen, niet op basis van het aantal parameters.