Kolibri vs Granite 4.2 3B: En satsning på 78B-sparsitet, och 3B-modellen som vägrar spela samma spel

Ställ Kolibri och Granite 4.2 3B bredvid varandra och den första ärliga iakttagelsen är att detta inte är en rättvis kamp, och inte i den riktning man skulle kunna anta. Kolibri är Aleph Alphas mixture-of-experts-modell med 78,1 miljarder parametrar, släppt den 3 oktober 2026, som aktiverar 3,46 miljarder parametrar per token. Granite 4.2 3B är IBMs täta resonemangsmodell med ungefär tre miljarder parametrar, vars vikter nådde Hugging Face den 7 augusti 2026, med modellkortet och den tekniska bloggen som följde den 25 augusti. Den ena har tjugosex gånger fler parametrar än den andra totalt sett. Anledningen till att de hör hemma i samma beslut är att båda är Apache 2.0, båda hanterar enbart text, båda är avsedda för självhosting och båda riktade sig mot samma köpare: ett team som vill ha dokumentintelligens på hårdvara som det kontrollerar, med den proveniens som krävs för att klara en upphandlingsgranskning. Den intressanta frågan är inte vilken av dem som är bättre. Det är vad parameterbudgeten på tjugosex gånger faktiskt köper, och vad den kostar att bära.

Diskrepansen, uttryckt klart

Granite 4.2 3B är en fristående dense-modell som eftertränats från Granite-4.1-3B-Base, en del av Granite 4.2-familjen som IBM släppte fram till augusti. Den har 40 lager med grouped-query attention, en inbyggd kontext på 128K som IBM utökar till 512K i en femte förträningsfas, och tre tankelägen per fråga: fullt tänkande som standard, en låginnsatsväg och en icke-tänkande väg. IBMs modellkort är ovanligt uppriktigt om vad 3B inte är. Till skillnad från sina syskon på 8B och 30B hoppade den medvetet över det specialiserade agentiska förstärkningsinlärningsblocket som tränats i SWE-agent-, terminal- och sökmiljöer, vilket är anledningen till att IBM inte listar någon SWE-bench-siffra för den överhuvudtaget och framställer modellen som en specialist på resonemang snarare än en agent.

Kolibri går i motsatt riktning på varje axel. Femtio lager, vart och ett av dem mixture-of-experts, 384 experter per lager med en delad och sex routade, och en sparsitetskvot på ungefär 22,6 till 1. Dess kontext är inbyggt 262 144 tokens, validerat upp till 1 048 576, och kortet rekommenderar att du håller dig på eller under 262 144 för latenskänsligt arbete. Fyra nivåer för resonemangsansträngning. Hermes-liknande verktygsanrop med en vLLM-parser som levereras i samma repository som vikterna. Och ett fotavtryck på ungefär 78 GB i FP8, där kortets minimikonfiguration är två A100 80 GB-kort, två H100 SXM5, en H200, en B200 eller en B300.

• Parametrar – Kolibri: 78 103 074 560 totalt, 3 457 573 120 aktiva per token. Granite 4.2 3B: cirka 3B tät modell, alla parametrar aktiva vid varje token.

• Kontext — Kolibri: 16 384 tränad, 65 536 mellantränad, 262 144 nativ, 1 048 576 validerad. Granite 4.2 3B: 128K nativ, utökad till 512K.

• Tankelägen — Kolibri: inget, låg, medel, hög, ställs in via chattmallen. Granite 4.2 3B: fullt, låg ansträngning och icke-tänkande, per fråga.

• Verktygsanrop — Kolibri: i Hermes-stil, med en medföljande parser. Granite 4.2 3B: ja, men inte den agentiskt RL-tränade vägen som dess större syskon fick.

• Språk — Kolibri: tyska och engelska, avsiktligt och inget annat. Granite 4.2 3B: engelska i första hand, med IBMs bredare flerspråkiga träning bakom sig.

• Fotavtryck — Kolibri: cirka 78 GB i FP8, minst två GPU:er. Granite 4.2 3B: ungefär 6–8 GB i bfloat16, under 2 GB kvantiserat, laptopklass.

• Licens — båda Apache 2.0, båda utan ett tillägg om godtagbar användning eller en tröskel för månatligt aktiva användare.

• Servering — Kolibri: vLLM-pluginen aleph-alpha-inference eller den publicerade containeravbilden. Granite 4.2 3B: vLLM, SGLang, Transformers, GGUF och Ollama under granite4.2:3b.

Vad de extra 75 miljarder parametrarna köper

Tre saker, och det är värt att vara noggrann med vilka av dem som är etablerade och vilka som är påstådda.

Det första är tyska. Detta är den skarpaste verkliga skillnaden mellan de två modellerna, och det är inte en rad i ett benchmark. Aleph Alpha byggde Kolibri kring en tysk-engelsk tvåspråkig korpus, med ett mål på ungefär 20 procent tyska i en förträningskörning på 20 biljoner token, och slutade med en tysk pool på 2,4 biljoner token, varav 80 procent hade kuraterats eller genererats av labbet självt. Kortet förklarar varför det krävde arbete: deduplicerade öppna tyska dataset tillhandahöll bara 390 miljarder token, en storleksordning för lite, så labbet ställde om ett Common Crawl-filter specifikt för tyska och omformulerade befintliga tyska dokument till uppslagsverksposter, dialog och passager. Det är filterdetaljen man ska minnas. En standardpipeline för språkdata tar bort dokument med för många långa ord, och tysk förvaltningsprosa överskrider rutinmässigt den engelska gränsen för genomsnittlig ordlängd – så standardinställningar raderar tyst det register som offentlig förvaltning skriver i. IBM byggde inte Granite för den korpusen. Granite 4.2 3B kommer att klara tyska; den utformades inte kring tyskt juridiskt och administrativt register, och ingen leaderboard kommer att visa dig skillnaden.

Det andra är lång kontext som klarar verkliga dokument. Granites 512K-tak är genuint stort, men de två modellerna nådde dit på olika sätt, och Kolibris positionsdesign är det mer konventionella argumentet för lång kontext. Se IBM:s RULER-siffror – 67,52 vid 64K och 55,30 vid 128K i 4.2-familjens publicerade material – som den ärliga redovisningen av hur mycket hämtningskvaliteten försämras fram till 128K, och kom ihåg att Kolibri inte har någon motsvarande publicerad försämringskurva alls.

Den tredje är rå utrymme för resonemang, och det är här det ärliga svaret är "inte så mycket som parameterkvoten antyder". Kolibris träningspipeline gav den en förträning på 20 biljoner tokens på 768 NVIDIA B200 under 21 dagar, och Aleph Alphas egen jämförelsetabell, med Kolibri på hög resonemangsansträngning, placerar den på 75,5 i engelskt genomsnitt och 70,8 i tyskt genomsnitt i en jämförelse av fjorton modeller – där den förlorar mot en dense modell med 27 miljarder parametrar från Alibaba på de flesta rader. Granite 4.2 3B:s främsta påståenden är dess egna: AIME 2025 på 78,33, GPQA på 54,80, LiveCodeBench v6 på 69,71 och MMLU-Pro på 67,84, alla rapporterade av IBM och inte reproducerade. Olika sviter, olika utvärderingsramverk, olika leverantörer. Det finns inget tal från samma utvärderingsramverk för den här kombinationen någonstans, och vi tänker inte hitta på ett.

Där var och en faktiskt vinner

Kör Granite 4.2 3B om begränsningen är själva maskinen. Vid 6–8 GB i bfloat16, eller under 2 GB kvantiserat, får den plats på en bärbar dator, en enda arbetsstations-GPU eller en luftgapad maskin som aldrig kommer att se två H100:or. Den kan köras via fem olika körtidsmiljöer, inklusive Ollama och GGUF, vilket spelar roll när målet för driftsättningen är någon annans bärbara dator snarare än ditt eget rack. Dess modellkort är ovanligt trovärdigt just för att IBM skrev ned vad man utelämnade. En leverantör som avstår från att hävda SWE-bench-resultat för en 3B säger dig var modellen tar slut.

Kör Kolibri om korpusen är poängen och hårdvaran finns. Ett team med tyskspråkiga kontrakt, teknisk dokumentation eller administrativa handlingar, en befintlig nod med två GPU:er och ett krav på att vikterna aldrig lämnar byggnaden är exakt vad den här versionen designades för. Det inbyggda fönstret på 262 144 token, FP8-KV-cachen, de fyra ansträngningsnivåerna och Hermes-verktygsanropsvägen pekar alla mot dokumentarbetsflöden snarare än chatt. Den tvåspråkiga tokenizern är en del av samma argument: Aleph Alpha rapporterar i genomsnitt 4,90 byte per token på tysk webbtext, mot 4,35 för GPT-5 och 3,28 för Kimi K3, alla mätta av leverantören på leverantörens korpus, och fler tecken per token är en direkt effekt på inferenskostnaden snarare än en poäng. Om det håller, ackumuleras det över varje sida du bearbetar.

Den asymmetri som ingen skyltar med är data. IBM publicerade vikterna för Granite 4.2 3B och en detaljerad teknisk redogörelse för hur modellen byggdes, men inte träningsdatan. Aleph Alpha publicerade pipelinen, datans härkomst och energisiffran tillsammans med Kolibris vikter – 20 biljoner förträningstokens, 9,5×10² MWh inklusive overhead för datacentret och exklusive övervakad finjustering och förstärkningsinlärning. För ett team som måste svara på "var kommer den här modellens text ifrån" är den skillnaden inte kosmetisk.

Routningsverkligheten för båda

Ingen av modellerna finns i en hostad katalog i dag. Kolibri har ingen leverantörs-API-SKU överhuvudtaget – lanseringen är vikter plus en teknisk rapport – och Granite 4.2 3B levereras som vikter för fem runtime-stackar utan någon hostad endpoint från IBM. Båda är förslag för egen drift, och den praktiska frågan för de flesta team är inte vilken av dem man ska införa utan huruvida arbetsbelastningen motiverar att äga någon av dem.

Det är där ett routningslager förtjänar sin plats, även för modeller som det inte tillhandahåller. Vi undersökte OrcaRouter-katalogen med alla stavningsvarianter av båda modellnamnen, och varken Kolibri eller Granite 4.2 3B finns där, så vi tänker inte låtsas något annat. Vad OrcaRouter däremot ger dig är det billiga sättet att ta reda på om hårdvarubeslutet är motiverat innan du fattar det: rikta en testväg mot en liten mixture-of-experts-nivå som redan är routad – varianten Gemma 4 26B-A4B till $0.06 per miljon indatatokens och $0.33 per miljon utdatatokens, med ett fönster på 262 144 tokens – och se om din tyska dokumentarbetsbelastning verkligen behöver det som Kolibri erbjuder, på en OpenAI-kompatibel nyckel, till leverantörens listpris utan något tillägg. Om den gör det köper du GPU:erna med bevis i stället för en gissning. Om den inte gör det har du precis sparat en hårdvarubeställning.

Domen, och vad som skulle ändra den

Det här är inte en matchning med en vinnare. Kolibri och Granite 4.2 3B svarar på olika frågor vid olika prisnivåer, och den enda ärliga rangordningen är efter begränsning: om begränsningen är hårdvara är Granite 4.2 3B den enda av de två som kvalificerar sig. Om begränsningen är dokumentarbete med tyska tillsynsregister lokalt var Granite 4.2 3B aldrig med i tävlingen och Kolibri är den mer intressanta artefakten – ett legitimt open-weights-släpp på 78B, Apache 2.0, med datapipelinen och tokenizern publicerade bredvid vikterna.

Två saker skulle avgöra jämförelsen. En oberoende körning av Kolibri på en tysk dokument-QA-uppgift skulle testa det påstående som utgåvan faktiskt byggdes för att göra, eftersom ingen resultattavla för närvarande mäter det. Och en oberoende reproduktion av Granite 4.2 3B:s resonemangssiffror skulle visa om en maskin i laptopklass kan hävda sig på den delmängd av din arbetsbelastning som aldrig behövde 78 miljarder parametrar från början. Tills en av dem blir verklighet, köp utifrån begränsning, inte utifrån parameterantal.