runNburn kjører en 222 GiB modell på en Mac med 64 GiB minne

Samme modell, samme Mac, to motorer: llama.cpp brukte 156,4 sekunder fra prosessen startet til svaret var ferdig. runNburn brukte 28,6. Testen er dokumentert i repoets egen benchmark-seksjon, og modellen var GLM-5.2 i UD-IQ2_M, en GGUF delt i seks filer med 222,18 GiB vekter, kjørt på en Apple M5 Pro med 64 GiB delt minne.

runNburn er en Rust-runtime fra coderredlab som ble lagt ut 18. juli under Apache-2.0. Premisset er at GGUF-fila er sannheten: vektene blir liggende mmap-et på disk, og runtimen holder et tak på hvor mye som til enhver tid er resident i vertsminnet. For en sparsom MoE-modell betyr det at bare ekspertene som faktisk trengs strømmes inn gjennom en avgrenset side-cache. Uten flagg leser runNburn tilgjengelig RAM, setter av en fjerdedel til operativsystem, KV-cache og andre prosesser, og bruker resten som arbeidssett.

«Poenget er at den kjører i det hele tatt, med forutsigbart minnebruk, i stedet for å bli avvist eller drept av OOM.» — runNburn-dokumentasjonen

Prosjektet er ærlig om at dette koster tid. På en Linux-maskin med Ryzen 9 5950X, 64 GB RAM og et RTX 3090 ble den samme 222-gigabyte-modellen kjørt med et hardt tak på 32 GiB. Median prefill for åtte tokens tok 42,44 sekunder og dekoding av ti tokens 26,05 sekunder, altså rundt 2,6 sekunder per token, mens toppforbruket holdt seg på 28,6 GiB. Målingene ble gjort 30. juli, og alle tre kjøringene ga token-identisk output.

Sammenligningen mot llama.cpp har også en forklaring som hører med: llama.cpp klarte ikke å fordele modellen selv. Både automatisk tilpasning og forsøk på full Metal-kjøring endte i minnefeil på Metal-kommandobufferen, så referansekjøringen brukte ett GPU-lag. Benchmarken dekoder bare åtte tokens og tester repeterbarhet, ikke svarkvalitet.

Runtimen kjenner igjen arkitekturer for Llama- og Phi-modeller, Gemma og Gemma 4, dense-, hybrid- og MoE-varianter av Qwen2 og Qwen3.5, Nemotron-H MoE, HY3 sparse MoE og GLM-DSA. Serveren snakker et utsnitt av OpenAI-APIet, med både chat/completions og responses, streaming, verktøykall og strukturert output, så en eksisterende klient kan peke rett på den. Det som bevisst er utelatt er like viktig: kontinuerlig batching, isolasjon mellom brukere og distribuert servering er ikke mål. Dette er én maskin med én eier.

Merk at prosjektet er før 1.0. CPU er standardveien, CUDA og Metal er under aktiv utvikling, og Vulkan, OpenCL og MediaTek er eksperimentelle. Ti stjerner på GitHub sier at dette ennå er tidlig.

Hva bør du gjøre?

1. Test med en modell som faktisk er større enn minnet ditt. På en modell som passer i RAM gir runNburn ingen gevinst, og da er llama.cpp fortsatt det trygge valget.
2. Sett taket selv med --ram-budget hvis du kjører andre tjenester på maskinen. Automatikken reserverer en fjerdedel av RAM, og det holder ikke alltid.
3. Regn med sekunder per token, ikke tokens per sekund, når arbeidssettet ligger på NVMe. Det egner seg til batch-jobber og lange kall, ikke til interaktiv chat.