Colibrì og GLM-5.2: 744B på laptop er stadig kun en langsom demo

Colibrì er en af de demoer, der nemt bliver læst forkert. Ja, den kan starte GLM-5.2, en model på 744 milliarder parametre, på en almindelig maskine med omkring 25 GB RAM. Nej, det betyder ikke, at vi nu bare kan køre frontier-størrelse modeller på laptops og kalde det lokal AI.

Det interessante er, hvordan runtime-laget snyder sig uden om det åbenlyse hukommelsesproblem. Colibrì viser, at store Mixture-of-Experts-modeller kan deles op, så noget ligger i RAM, mens resten hentes fra disk efter behov. Det er teknisk spændende. Det er også langsomt nok til, at man skal passe på med konklusionerne.

Tricket er MoE, ikke magi

GLM-5.2 er en Mixture-of-Experts-model. Det betyder, at modellen har mange ekspertblokke, men kun bruger en mindre del af dem for hvert token. Z.ai beskriver modellen som 744B parametre i alt, cirka 40B aktive parametre pr. token og et kontekstvindue på op til 1M tokens.

Colibrì bruger den egenskab ret aggressivt. De tætte vægte, embeddings og fælles eksperter ligger i RAM. De mange routed experts ligger i en int4-container på omkring 370 GB og bliver hentet fra disken, når routeren vælger dem. Hugging Face-repoet for vægtene nævner Linux eller WSL2, gcc med OpenMP, AVX2, mindst 16 GB RAM og cirka 400 GB fri disk-plads.

Det er ikke en generel opskrift på billig lokal AI. Det er en konkret måde at udnytte modellens form på. Hvis kun en del af modellen bruges for hvert token, behøver hele modellen ikke ligge i den hurtigste hukommelse hele tiden. Noget kan ligge på disk. Noget kan caches. Noget kan accepteres som langsomt, hvis målet er at bevise, at det overhovedet kan lade sig gøre.

25 GB RAM siger ikke meget uden hastigheden

Den svære del er hastigheden. Colibrì-forfatterens egen Reddit-post nævner omkring 0,05 til 0,1 tokens pr. sekund på en 12-core maskine med 25 GB RAM. ModelFit gennemgår tallene og peger på samme problem: selv på bedre hardware rammer man hurtigt et I/O-loft. Et rapporteret community-run på en M5 Max med hurtig intern SSD landede omkring 1,06 tokens pr. sekund.

Det er fint til en demo. Det er ikke fint til en assistent, man faktisk skal arbejde med. En svartekst på 200 tokens kan tage minutter på den bedste rapporterede opsætning og over en halv time på referenceopsætningen. Så ja, modellen kan køre. Men hvis man sidder og venter på hvert svar, er det ikke et produktivt værktøj.

Flaskehalsen er heller ikke mystisk. SSD-producenter sælger sekventielle læsetal, fordi de ser flotte ud. Colibrì skal lave mange små opslag i en stor ekspertfil. Når hvert token kræver spredte læsninger på tværs af en container på flere hundrede gigabyte, betyder random read, page cache og genbrug af de samme eksperter mere end tallet på pakken.

Det er runtime-laget, der er nyheden

For danske udviklere og arkitekter er Colibrì bedst læst som et stykke systemdesign. Det flytter diskussionen væk fra parameterantal som statussymbol og over på adgangsstier, cache, hukommelsesbåndbredde og storage-layout. Det er der, lokal LLM-drift enten bliver brugbar eller dør i ventetid.

Hvis man overvejer lokale modeller i en virksomhed, er den forkerte konklusion: “så kan vi køre 744B på laptops”. Den bedre konklusion er mere kedelig, men langt mere brugbar: modelvalg og runtime-valg hænger sammen. Quantization, MoE-routing, caching, RAM, NVMe og CPU-instruktioner er ikke detaljer efter arkitekturen. De er arkitekturen.

Det passer med udviklingen i de åbne modeller. Jeg skrev for nylig om GLM-5.2 som open-weight pres på frontiermodellerne. Colibrì lægger et runtime-lag ovenpå den historie: når vægtene er åbne, kan folk også eksperimentere med, hvordan de bliver kørt. Og i artiklen om private LLM-endpoints var pointen netop, at enterprise-AI langsomt flytter fra rene API-kald til infrastruktur, man selv skal styre.

Der er også en sikkerhedsvinkel. GLM-5.2 kommer fra kinesiske Z.ai. Det gør ikke modellen ubrugelig, men det gør provenance, supply chain, træningsdata og politisk afhængighed relevante. Åbne vægte fjerner ikke behovet for at vide, hvor modellen kommer fra, hvad den må se, og hvordan runtime-kæden er bygget.

Mit take

Colibrì er værd at følge, fordi projektet gør en abstrakt diskussion konkret. Store modeller kan splittes op og hentes fra disk på nye måder. Men fysikken forsvinder ikke. Hvis du bygger lokal LLM-infrastruktur i 2026, skal du måle tokens pr. sekund, latency, RAM-forbrug, diskmønstre og cache-hit-rate. Ikke kun benchmarkscore og modelstørrelse.

For de fleste teams vil en mindre model, der svarer hurtigt og stabilt, slå en enorm model, der teknisk set kan køre, men føles som en fjernskriver med prestige. Colibrì ændrer ikke den prioritering. Den gør bare grænsen mellem “umuligt” og “muligt, men irriterende langsomt” tydeligere.