Glimpse vs Kolibri: Två sätt att köpa mer beräkningskraft per token

E​lorian G​limpse och K​olibri är två svar på samma ekonomiska fråga – hur får man mer kapacitet per beräkningsenhet – och de ligger i motsatta ändar av den. G​limpse, som släpptes av E​lorian den 16 oktober 2026, köper sin kapacitet vid inferenstid: den kör en första genomgång av ett klipp i ungefär 8 bilder per sekund och lägger sedan extra beräkningskraft på att återskanna en vald nio tiondels sekund i cirka 14 bilder per sekund innan den svarar. K​olibri, som släpptes av A​leph Alpha den 3 oktober 2026, köper sin kapacitet vid arkitekturtid: 78,1 miljarder totala parametrar, varav endast omkring 3,46 miljarder är aktiva per token, så nästan varje parameter i modellen är en du aldrig betalar för att utvärdera.

De två är inte utbytbara, och anledningen är inte kvalitet. Den ena är en hostad förhandsversion utan vikter, utan publicerat parameterantal och utan publicerat kontextfönster. Den andra är en nedladdning under Apache 2.0 vars modellkort anger antalet experter, attention-schemat, de numeriska formaten, tokenizerns språktäckning och den exakta elräkningen för dess träningskörning. Att jämföra dem är egentligen en jämförelse av två strategier, och den intressanta frågan är vilken strategi som överlever kontakten med din arbetsbelastning.

Ett förhållande på 22 mot 1 jämfört med ett förhållande som ingen publicerade

Kolibri är en gles mixture-of-experts-modell, och glesheten är extrem även enligt dagens standard. Femtio lager, vart och ett av dem en mixture of experts, 384 experter per lager, varav en är delad och sex är routade. Det motsvarar ett förhållande mellan totalt antal och aktiva på ungefär 22,6 mot 1 – en modell som rymmer 78 miljarder parametrar men utvärderar omkring 3,5 miljarder av dem för varje given token. Aleph Alpha varvar detta i ett 4-mot-1-mönster med group-query-attention-block, vilket är det som håller den inbyggda kontexten på 262 144 token överkomlig: en väg på en miljon token är validerad, och KV-cachen hålls i FP8 för att den långa änden av det fönstret ska rymmas i minnet i stället för i ett kalkylblad.

Valen av numeriska format avslöjas i en utsträckning som är ovanlig. Vikterna är FP8 i 128×128-block. KV-cachen är FP8. Inbäddningar, språkmodellshuvudet, normaliseringslagren och routern förblir i bfloat16 — de delar där kvantiseringsskador skulle visa sig i routingbeslut snarare än i förluster. Fyra ansträngningsnivåer exponeras. Verktygsanrop följer Hermes-formatet med en vLLM-parser, vilket innebär att det passar in i en befintlig agentstack i stället för att kräva en skräddarsydd integration.

G​limpse publicerar inget av det. Inget parameterantal. Ingen expertstruktur att tala om, inget kontextfönster, inget kvantiseringsschema, ingen namngiven basmodell – bara frasen "eftertränad på en basmodell med öppna vikter", som inte säger vilken. Vad den i stället publicerar är spåret: en första genomgång vid ungefär 8 bildrutor per sekund, en tentativ avläsning, en återgång till 0,9 sekunder av klippet vid omkring 14 bildrutor per sekund, och i ett andra exempel en fönsterkant som spåras från omkring 2,2 sekunder in i ett klipp tills den nästan stannar vid 5,13 sekunder.

Båda dessa är upplysningar om beräkningskraft. K​olibris är ett uttalande om vart beräkningskraften tar vägen när modellen laddas. G​limpses är ett uttalande om vart beräkningskraften tar vägen medan modellen tänker. Endast en av dem kommer med en siffra.

De publicerade bladen, sida vid sida

• Storlek — Kolibri: 78,103,074,560 parametrar totalt, 3,457,573,120 aktiva. Glimpse: inte publicerad, med "avsevärt mindre och billigare än de frontier-system som den jämför sig mot" som det enda uttalande om storlek som Elorian gör.

• Tillgång — Apache 2.0-vikter för K​olibri, nedladdningsbara och möjliga att hosta själv. Inga för G​limpse, som endast är API och chatt med en kostnadsfri registrering.

• Kontext — 262 144 tokens inbyggt för K​olibri, med 1 048 576 validerade. Inte publicerat för G​limpse, vilket är den mer besvärande luckan eftersom dess främsta förmåga är att läsa video.

• Språk — tyska och engelska för K​olibri, vilket A​leph Alpha presenterar som ett designbeslut snarare än en begränsning. G​limpse publicerar ingen språktäckning alls.

• Pris — 0,60 USD per miljon indatatoken och 3,00 USD per miljon utdatatoken för G​limpse — och mekanismen innebär att det är i utdatatoken som omskanningen dyker upp, så spåret är kvittot. K​olibri har ingen prislista, eftersom kostnaden är hårdvaran.

• Oberoende utvärdering — i praktiken ingen för någon av dem. Ingen av dem har en testrigg från tredje part som reproducerar dess siffror, och båda uppsättningarna av publicerade siffror är leverantörens egna.

Träningskörningen som A​leph Alpha publicerade i sin helhet

Det är här K​olibri skiljer sig från nästan varje release i år, och det är värt att gå igenom eftersom det berättar vad glesheten kostade att bygga.

Förträningskorpusen bestod av 20 biljoner tokens, uppdelade på ungefär 62,5 % engelska, 23,9 % tyska och 13,6 % kod. Mellanträningen tillförde ytterligare 3,44 biljoner token, och en långkontextfas bidrog med 201 miljarder. Körningen använde 768 NVIDIA B200-acceleratorer över 96 HGX-noder, tog 21 dagar och 511 timmar i väggklockstid och förbrukade cirka 392 000 GPU-timmar — 6,4×10²³ flyttalsoperationer, med en energibudget på ungefär 9,5×10² megawattimmar.

De siffrorna är det ärliga priset för en modell med 3,46 miljarder aktiva parametrar som beter sig som något mycket större. De är också omöjliga att upprepa för alla utanför ett välfinansierat labb, och det är just argumentet för öppna vikter: träningskostnaden betalas en gång av företaget som publicerar modellkortet, och alla nedströms får artefakten för nedladdningens pris.

Föregångaren är lärorik. K​olibri Origin hade 30,6 miljarder parametrar, varav 3,27 miljarder aktiva, en kontext på 65 536 token och 7,51 biljoner träningstoken — och den släpptes aldrig. Den publicerade modellen är inte ett första försök; den är den andra, och gapet mellan dem är ungefär gapet mellan en prototyp och en produkt.

Det finns inget jämförbart för G​limpse. E​lorian säger bara att modellen eftertränades av ett litet team med några hundra GPU:er. Det anges ingen basmodell, inget antal tokens, ingen databeskrivning, ingen redovisning av beräkningskraft. Det är en legitim skillnad mellan att publicera en checkpoint och att leverera en endpoint – man redovisar vad man lämnar över – men det innebär att de två lanseringarna inte kan jämföras ekonomiskt bortom prislistan, eftersom bara en av dem publicerade sina kostnader.

Den tomma cellen för parameterantal

Här ligger fällan i den här jämförelsen, och den går i Glimpses riktning.

Det är lätt att läsa de 3,46 miljarder aktiva parametrarna i K​olibri och dra slutsatsen att G​limpse – hostad, billig per token, inriktad på en smal förmåga – måste vara liten, eller måste vara billig att köra, eller måste vara en finjustering av något blygsamt. Inget av det följer. Antalet parametrar i G​limpse har aldrig publicerats. Dess kontextfönster har aldrig publicerats. Dess basmodell har aldrig namngetts. Det enda storlekspåståendet i lanseringsinlägget är jämförande och okvantifierat. När beteendet inte avslöjar storlek, och den här modellens beteende är ett samplingsschema snarare än en arkitektur, skulle antalet parametrar kunna vara nästan vad som helst, och inget som publicerats skulle motsäga det.

Så cellen för parameterantal förblir tom, och varje siffra som någon anger för Glimpses storlek den här månaden är en uppskattning utklädd till en specifikation. Detsamma gäller för övrigt åt andra hållet: Kolibris kvot på 22,6 till 1 säger dig inte vad dess inferenskostnad blir på din hårdvara, eftersom FP8-vikter i 128×128-block behöver specifikt acceleratorstöd för att vara en vinst snarare än ett konverteringssteg.

Vad varje strategi misslyckas med

Kolibris begränsning är språktäckning, och den är avsiktlig. Tyska och engelska, inget annat. För ett europeiskt företag med tyskspråkig trafik är det en fördel — träningsmixen är viktad mot ett språk som de flesta öppna modeller behandlar som ett avrundningsfel. För alla andra är det ett definitivt nej, och inget kontextfönster, hur stort det än är, kompenserar för det.

Dess andra begränsning är aritmetiken för långa kontexter. En väg på en miljon token har validerats, vilket är genuint stort. Men en validerad väg är inte samma sak som en oförsämrad sådan; vid dessa längder avtar nästan varje modells hämtningsnoggrannhet långt innan fönstret tar slut, och ingen publicerad utvärdering säger var K​olibris kurva böjer sig. Betrakta fönstret som kapacitet du kan allokera snarare än noggrannhet du kan förutsätta.

G​limpses begränsning har den motsatta formen: en snäv förmåga utan något runt omkring. Om frågan är vad som hände inom en bråkdel av en sekund av videomaterial, är G​limpse direkt inriktad på det. Om frågan är vad en scen antyder snarare än vad den uttrycker, hjälper inte återspolningen — på Humanity's Sixth Sense, riktmärket som E​lorian publicerade med Scale AI nio dagar innan modellen släpptes, får G​limpse 46,36 mot GPT-6 Astras 53,6, och riktmärkets egen felanalys tillskriver 94 % av de märkta felen seende och slutledning snarare än resonemang. Mer tittande är inte mer förståelse, och leverantörens egen tabell är beviset.

Det finns också en klass av problem som ingen av dem tar itu med: den där svaret måste vara ett tröskelvärde. G​limpse skriver prosa. K​olibri läser och skriver. Ingen av dem är byggd för att returnera ett kalibrerat tal per alternativ, och om det är vad pipelinen behöver är instrumentet en helt annan typ av modell.

Där ett routinglager förtjänar sin plats — och där det inte gör det

De två modellerna sitter på varsin sida om en gräns som routning kan flytta och en som den inte kan.

Den gräns den flyttar är kostnaden och motståndskraften med att blanda vägar. Ett team som kör K​olibri på sina egna acceleratorer för tyskspråkig trafik och en hostad modell för allt annat har två kodvägar, två felmoder och två uppsättningar autentiseringsuppgifter. OrcaRouter reducerar det till en enda nyckel framför över 200 modeller, med ett routing-DSL som avgör vilken begäran som går till vilken väg och automatisk redundansväxling som håller en begäran vid liv när den egenhostade vägen är mättad eller nere. Leverantörernas listpriser förs vidare utan något påslag per token, så den hostade halvan av den mixen kostar vad leverantören debiterar och följer leverantörens pris samma dag som det ändras.

Den gräns den inte flyttar är förvar, och här har K​olibri en fördel som inget routningslager kan åstadkomma. Dess vikter kan laddas ner. Om korpusen inte kan lämna byggnaden är en Apache 2.0-checkpoint den enda av dessa två som körs där data finns, och ingen utvärdering av någon av modellerna ändrar på det. Ingen av modellerna finns heller i vår katalog — K​olibri är en nedladdning och G​limpse är E​lorians eget API- och chattgränssnitt — så detta är ett uttalande om hur vi routar, inte ett anspråk på att betjäna dem.

Hur man fattar beslut utan ett gemensamt riktmärke

Det finns ingen resultattavla som rangordnar dessa två, och det beror inte på att en av dem är ny. E​lorians tabell mäter video- och bildperception mot GPT-6 Astra; A​leph Alphas kort mäter den vanliga akademiska bredden plus långkontextsretrieval. De delar ingen uppgift, så den enda jämförelse som spelar roll är mot din egen arbetsbelastning.

Tre frågor avgör saken snabbare än någon tabell.

Måste data stanna på hårdvara som du kontrollerar? Om ja, är K​olibri den enda kandidaten här, licensen är Apache 2.0, och den tysk-engelska täckningen passar antingen din driftsättning eller utesluter den omedelbart.

Är felläget tidsmässigt — objektidentitet över en ocklusion, en panorering kontra en klippning, en händelse inom ett subsekundsfönster? Om ja, är G​limpse den enda av de två modellerna vars angivna mekanism hanterar det, den kostnadsfria registreringen gör testet billigt, och spåret säger dig mer än poängen: kör dina egna klipp och kontrollera om modellen någonsin gick tillbaka till intervallet som avgjorde svaret.

Är arbetsbelastningen lång kontext men inte lång video – en dokumentkorpus, en samling inlämnade handlingar, ett revisionsspår? Om ja, är K​olibris nativa fönster på 262 144 token med en validerad väg till en miljon token det relevanta talet, och ingen av modellernas publicerade utvärderingar avgör om den överlever degraderingskurvan vid dessa längder. Det måste mätas, på dina data, innan något av besluten är säkert.

De dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och omstridd flagga.