{"id":1770,"date":"2026-07-15T19:34:25","date_gmt":"2026-07-15T17:34:25","guid":{"rendered":"https:\/\/vittrup-graversen.dk\/?p=1770"},"modified":"2026-07-15T19:34:26","modified_gmt":"2026-07-15T17:34:26","slug":"colibri-og-glm-5-2-744b-paa-laptop-er-stadig-kun-en-langsom-demo","status":"publish","type":"post","link":"https:\/\/vittrup-graversen.dk\/index.php\/2026\/07\/15\/colibri-og-glm-5-2-744b-paa-laptop-er-stadig-kun-en-langsom-demo\/","title":{"rendered":"Colibr\u00ec og GLM-5.2: 744B p\u00e5 laptop er stadig kun en langsom demo"},"content":{"rendered":"\n

Colibr\u00ec er en af de demoer, der nemt bliver l\u00e6st forkert. Ja, den kan starte GLM-5.2, en model p\u00e5 744 milliarder parametre, p\u00e5 en almindelig maskine med omkring 25 GB RAM. Nej, det betyder ikke, at vi nu bare kan k\u00f8re frontier-st\u00f8rrelse modeller p\u00e5 laptops og kalde det lokal AI.<\/p>\n\n\n\n

Det interessante er, hvordan runtime-laget snyder sig uden om det \u00e5benlyse hukommelsesproblem. Colibr\u00ec viser, at store Mixture-of-Experts-modeller kan deles op, s\u00e5 noget ligger i RAM, mens resten hentes fra disk efter behov. Det er teknisk sp\u00e6ndende. Det er ogs\u00e5 langsomt nok til, at man skal passe p\u00e5 med konklusionerne.<\/p>\n\n\n\n

Tricket er MoE, ikke magi<\/h2>\n\n\n\n

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\u00e5 op til 1M tokens.<\/p>\n\n\n\n

Colibr\u00ec bruger den egenskab ret aggressivt. De t\u00e6tte v\u00e6gte, embeddings og f\u00e6lles eksperter ligger i RAM. De mange routed experts ligger i en int4-container p\u00e5 omkring 370 GB og bliver hentet fra disken, n\u00e5r routeren v\u00e6lger dem. Hugging Face-repoet for v\u00e6gtene n\u00e6vner Linux eller WSL2, gcc med OpenMP, AVX2, mindst 16 GB RAM og cirka 400 GB fri disk-plads.<\/p>\n\n\n\n

Det er ikke en generel opskrift p\u00e5 billig lokal AI. Det er en konkret m\u00e5de at udnytte modellens form p\u00e5. Hvis kun en del af modellen bruges for hvert token, beh\u00f8ver hele modellen ikke ligge i den hurtigste hukommelse hele tiden. Noget kan ligge p\u00e5 disk. Noget kan caches. Noget kan accepteres som langsomt, hvis m\u00e5let er at bevise, at det overhovedet kan lade sig g\u00f8re.<\/p>\n\n\n\n

25 GB RAM siger ikke meget uden hastigheden<\/h2>\n\n\n\n

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

Det er fint til en demo. Det er ikke fint til en assistent, man faktisk skal arbejde med. En svartekst p\u00e5 200 tokens kan tage minutter p\u00e5 den bedste rapporterede ops\u00e6tning og over en halv time p\u00e5 referenceops\u00e6tningen. S\u00e5 ja, modellen kan k\u00f8re. Men hvis man sidder og venter p\u00e5 hvert svar, er det ikke et produktivt v\u00e6rkt\u00f8j.<\/p>\n\n\n\n

Flaskehalsen er heller ikke mystisk. SSD-producenter s\u00e6lger sekventielle l\u00e6setal, fordi de ser flotte ud. Colibr\u00ec skal lave mange sm\u00e5 opslag i en stor ekspertfil. N\u00e5r hvert token kr\u00e6ver spredte l\u00e6sninger p\u00e5 tv\u00e6rs af en container p\u00e5 flere hundrede gigabyte, betyder random read, page cache og genbrug af de samme eksperter mere end tallet p\u00e5 pakken.<\/p>\n\n\n\n

Det er runtime-laget, der er nyheden<\/h2>\n\n\n\n

For danske udviklere og arkitekter er Colibr\u00ec bedst l\u00e6st som et stykke systemdesign. Det flytter diskussionen v\u00e6k fra parameterantal som statussymbol og over p\u00e5 adgangsstier, cache, hukommelsesb\u00e5ndbredde og storage-layout. Det er der, lokal LLM-drift enten bliver brugbar eller d\u00f8r i ventetid.<\/p>\n\n\n\n

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

Det passer med udviklingen i de \u00e5bne modeller. Jeg skrev for nylig om GLM-5.2 som open-weight pres p\u00e5 frontiermodellerne<\/a>. Colibr\u00ec l\u00e6gger et runtime-lag ovenp\u00e5 den historie: n\u00e5r v\u00e6gtene er \u00e5bne, kan folk ogs\u00e5 eksperimentere med, hvordan de bliver k\u00f8rt. Og i artiklen om private LLM-endpoints<\/a> var pointen netop, at enterprise-AI langsomt flytter fra rene API-kald til infrastruktur, man selv skal styre.<\/p>\n\n\n\n

Der er ogs\u00e5 en sikkerhedsvinkel. GLM-5.2 kommer fra kinesiske Z.ai. Det g\u00f8r ikke modellen ubrugelig, men det g\u00f8r provenance, supply chain, tr\u00e6ningsdata og politisk afh\u00e6ngighed relevante. \u00c5bne v\u00e6gte fjerner ikke behovet for at vide, hvor modellen kommer fra, hvad den m\u00e5 se, og hvordan runtime-k\u00e6den er bygget.<\/p>\n\n\n\n

Mit take<\/h2>\n\n\n\n

Colibr\u00ec er v\u00e6rd at f\u00f8lge, fordi projektet g\u00f8r en abstrakt diskussion konkret. Store modeller kan splittes op og hentes fra disk p\u00e5 nye m\u00e5der. Men fysikken forsvinder ikke. Hvis du bygger lokal LLM-infrastruktur i 2026, skal du m\u00e5le tokens pr. sekund, latency, RAM-forbrug, diskm\u00f8nstre og cache-hit-rate. Ikke kun benchmarkscore og modelst\u00f8rrelse.<\/p>\n\n\n\n

For de fleste teams vil en mindre model, der svarer hurtigt og stabilt, sl\u00e5 en enorm model, der teknisk set kan k\u00f8re, men f\u00f8les som en fjernskriver med prestige. Colibr\u00ec \u00e6ndrer ikke den prioritering. Den g\u00f8r bare gr\u00e6nsen mellem “umuligt” og “muligt, men irriterende langsomt” tydeligere.<\/p>\n\n\n\n

Kilder<\/h2>\n\n\n\n