Hoe een neuraal netwerk met 744 miljard parameters op een gewone computer draait

Wanneer je de pagina opent van een model zoals GLM-5.2 met 744 miljard parameters of Kimi K3 met 2,8 biljoen, is de eerste gedachte vrij rechtstreeks: je hebt een serverrack met een dozijn H100 GPU's nodig. Als je die resources niet bij de hand hebt, is de enige optie die overblijft betalen voor API-aanroepen.

Onlangs stuitte ik op het JustVugg/colibri-project. De auteur schreef een lichtgewicht inference-engine in pure C zonder afhankelijkheden van derden. De engine slaagt erin om massieve MoE-modellen te draaien op een gewone desktop of laptop met 24 GB RAM, waarbij gewichten rechtstreeks van een snelle SSD worden gehaald.

Wat is het trucje

De Mixture-of-Experts (MoE) architectuur is ontworpen zodat niet het hele model nodig is om één enkele token te genereren. Bijvoorbeeld, in GLM-5.2 van de 744 miljard parameters zijn er maar ongeveer 40 miljard actief. Bovendien veranderen er van token tot token maar ongeveer 11 GB aan gewichten, overeenkomstig de experts die door de router worden geselecteerd.

In plaats van te proberen 370 GB aan model in het videogeheugen te proppen, verdeelt de engine data over een opslaghiërarchie:

• Het dense deel van het model (embeddings, attention, gedeelde lagen) weegt ongeveer 9,9 GB in int4-kwantisatie en blijft permanent in RAM.
• Bijna 20.000 experts verblijven op een snelle NVMe SSD en worden op aanvraag geladen via asynchrone I/O.
• Vaak gebruikte experts nestelen zich in de LRU-cache van RAM of VRAM.

Dit werkt in wezen als een JIT-compiler, maar dan voor neurale netwerkgewichten. De engine houdt toegangsstatistieken bij, onthoudt hete takken en cached precies die experts die nodig zijn voor de huidige context.

Hoe de engine werkt

De codebase is beknopt. De kern is geschreven in C (elke modelfamilie is gescheiden in zijn eigen bestand, bijvoorbeeld c/colibri.c voor GLM) en compileert met gcc of clang met OpenMP-ondersteuning. Geen gigantische frameworks of monsterlijke runtimes. Python wordt alleen gebruikt voor eenmalige gewichtsconversie en de webinterface-wrapper.

Bij het genereren van elke token voert de engine verschillende stappen uit:

1. Berekent routing één laag vooruit via een aparte prefetch-thread. De router voorspelt de benodigde expert met ongeveer 71% nauwkeurigheid, dus schijflezingen vinden plaats parallel aan berekeningen.
2. Voegt verzoeken aan identieke experts samen tot een batch om dubbele leesoperaties te elimineren.
3. Leest de drie matrices van elke expert in één enkele pread systeemcall.
4. Slaat hit-statistieken op in een historiebestand zodat bij volgende runs hete lagen vooraf in het geheugen worden vastgezet.

Ondersteuning voor twee opslagapparaten is interessant geïmplementeerd. Als je gewichtskopieën verdeelt over twee verschillende SSD's, verdeelt de engine expertverzoeken proportioneel naar elke schijf leessnelheid. Een paar schijven met 9 GB/s en 3 GB/s versnelt het lezen met ongeveer een derde.

Voor rekenversnelling worden CUDA, Metal op Apple Silicon-chips en Vulkan ondersteund. De Vulkan-variant werkt zelfs met oudere GPU's zoals de AMD RX 580 via de RADV-driver, waarvoor de leverancier al lang geleden de ondersteuning voor de nieuwste ROCm heeft stopgezet.

Het pakket bevat een webdashboard met visualisatie van expertactiviteit. Op de Atlas-pagina kun je een 3D-kaart van duizenden experts draaien en observeren hoe verschillende groepen omgaan met code, juridische onderwerpen of vreemde talen.

Werkelijke snelheidscijfers

Er zijn geen mirakelen, dus snelheid wordt beperkt door schijfdoorvoer en beschikbaar geheugen.

De benchmarks van het project registreerden de volgende resultaten op het GLM-5.2-model:

• Een laptop met 25 GB RAM en een koude cache produceert een bescheiden 0,05-0,1 tokens per seconde. Het is langzaam, maar het model reageert zonder logische vervorming.
• Een workstation met 128 GB RAM zonder discrete GPU levert ongeveer 1,8 tokens per seconde op een opgewarmde cache.
• Een laptop met een mobiele RTX 5070 Ti versnelt tot 1,07 tokens per seconde dankzij de GPU-pipeline.
• Een server met zes RTX 5090-kaarten houdt experts volledig in het videogeheugen en toont 5,8-6,8 tokens per seconde.

Ondersteunde modellen

Naast het basis GLM-5.2 voegde de auteur ondersteuning toe voor vier andere architecturen:

• Inkling (975B) — het draaien van het dense deel in int4 vereist ongeveer 25 GB RAM en 469 GB schijfruimte.
• Kimi K3 (2.8T) — een reus van 1,6 TB, leest MXFP4-native gewichten rechtstreeks van originele shards zonder voorafgaande conversie.
• DeepSeek V4 Flash (284B) — werkt met 167 GB aan gewichten in fp4/fp8-formaat en vereist 16 tot 22 GB RAM.
• OLMoE (7B) — een compacte variant met 4 GB aan gewichten voor snelle experimenten op 8 GB RAM.

Hoe te draaien

De engine wordt gedistribueerd als voorgebouwde binaries voor Linux, macOS en Windows, of kan in een minuut uit de broncode worden gebouwd:

git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh

Na het bouwen download je gekwantiseerde gewichten voor het gewenste model van Hugging Face (bijvoorbeeld, GLM-5.2 int4 neemt ongeveer 372 GB in beslag) en start je de chat via de terminal:

COLI_MODEL=/path/to/glm52_i4 ./coli chat

Als je een lokale server wilt die compatibel is met de OpenAI API samen met het webpaneel, voer je uit:

./coli web --model /path/to/glm52_i4

Voor het starten is het de moeite waard om de geheugendistributie te controleren met ./coli plan en een snelle hardwaretest uit te voeren met ./coli tune.

Voor wie is dit project nuttig

Colibrì is waarschijnlijk niet geschikt voor productie met hoge belasting vanwege schijfleeslatentie op consumentenhardware. Echter, het is een geweldige vondst voor onderzoekers, enthousiastelingen en ontwikkelaars die de redenering van top open-source modellen lokaal willen testen zonder server-GPU's te kopen voor miljoenen roebels. De kerncode is compact en transparant, waardoor de engine handig te gebruiken is als speeltuin voor je eigen experimenten met I/O en kwantisatie.