NightRun zet een pc om in een AI-runtime die direct vanaf USB opstart

NightRun brengt de lokale uitvoering van taalmodellen naar een veel nauwer firmware-domein dan het traditionele bureaublad. Het start rechtstreeks vanaf een USB-stick via UEFI, laadt het volledige model in RAM en voert inferentie uit op de CPU zonder Linux, Windows, conventioneel kernel of netwerktopologie. Het is niet bedoeld als vervanging van Ollama of llama.cpp voor alledaags gebruik, maar als een gespecialiseerde machine waarin vrijwel alle software tussen firmware en het grote taalmodel verdwijnt.

De technische kern van NightRun in 30 seconden

• NightRun is een EFI-applicatie no_std geschreven in Rust die op UEFI Boot Services blijft draaien.
• Laadt volledig gemoduleerde gekwantiseerde modellen van 1,3 tot 2,4 GB in RAM en blokkeert daarna verdere toegang tot opslag.
• Voert inferentie uitsluitend uit op CPU met AVX2 op x86_64 en NEON op Raspberry Pi 5.
• Implementeert Llama 3.2, Qwen3 en Granite 4.1 dense, met validatie ten opzichte van llama.cpp.
• Bevat geen conventionele kernel, gebruikersprocessen, services, shell, browser of TCP/IP-stack.

De werking op UEFI is cruciaal. NightRun is niet bare metal in strikte zin. Het roept geen ExitBootServices(), waardoor de firmware-services gedurende de sessie beschikbaar blijven. UEFI biedt de functies voor scherm, toetsenbord, opslag en het starten van verschillende CPU-kernen.

Dit is een bewuste keuze. Het ontwikkelen van eigen controllers voor USB-HID, xHCI, opslag, grafisch apparaat en de complexiteit van duizenden moederbboards zou het project veel meer doen lijken op een besturingssysteem.

NightRun gebruikt de firmware als platformlaag en bouwt daarbovenop een eigen modelloader, inferentiemotor, geheugbeheer, tokenizer, grafische interface en multi-kern uitvoering.

Van BOOTX64.EFI tot eerste token zonder kernel te starten

Op een x86_64 PC voert de firmware direct BOOTX64.EFI uit. Op de Raspberry Pi 5 is dat BOOTAA64.EFI.

Vanaf daar begint een zeer andere reeks stappen dan bij een gebruikelijke lokale AI-installatie:

1. NightRun activeert de noodzakelijke SIMD-modus van de CPU.
2. Initialiseert framebuffer en toetsenbord.
3. Start beschikbare kernen via UEFI MP-services.
4. Detecteert het geheugen.
5. Laadt het volledige model in RAM.
6. Verifieert de integriteit tijdens het lezen.
7. Sluit de toegang tot opslag achteraf af.
8. Initialiseert tokenizer en conversationsjabloon.
9. Reserveert KV-cache en werkgeheugen.
10. Start de chat interface.

De runtime maakt gebruik van UEFI Graphics Output Protocol (GOP) om toegang te krijgen tot het framebuffer en tekent de eigen interface. Er is geen compositor, Linux-terminal of grafische server onderliggend.

Hetzelfde geldt voor het toetsenbord. NightRun gebruikt de firmware-voorzieningen voor USB-invoer, terwijl de tekstbewerking, geschiedenis en chatinterface door het eigen systeem worden geregeld.

Deze architectuur verklaart waarom het niet voldoende is om het simpelweg als “Ollama zonder internet” te bestempelen.

Het model wordt één keer geladen en opslag verdwijnt uit de uitvoering

Een andere kernverschil zit in de manier waarop NightRun met het model omgaat.

De installer neemt een compatibel GGUF-bestand, onderzoekt de architectuur en converteert het naar het eigen .nrm-formaat. Dit containerformaat is specifiek ontworpen zodat tensors rechtstreeks vanuit het geladen geheugen kunnen worden gebruikt.

Tijdens de opstart leest NightRun het bestand in blokken en berekent tegelijkertijd de CRC-32-controles, waardoor een extra volledige controlepass overbodig wordt.

Na het voltooien van dit proces blijven de gewichten in RAM opgeslagen.

Het runtime legt vervolgens een regel op: elke latere poging tot lezen uit opslag resulteert in een fout. De inferentie consulteert geen USB of microSD meer.

Daarnaast wordt alle benodigde geheugen vooraf gereserveerd.

Het ontwerp bevat regio’s voor gewichten, KV-cache, prefill-werkgeheugen, decode-temp en grafische buffers. Een functie berekent vooraf de benodigde geheugengrootte, en als er niet genoeg RAM is, faalt de opstart voordat de conversatie kan beginnen.

De gebuikte generatiecyclus produceert volgens de documentatie geen heap-allocaties.

De praktijkgerichte consequentie is dat de RAM omvang bepaalt welke modellen kunnen draaien.

Een Llama 3.2 1B van 1,3 GB vereist een machine met ongeveer 4 GB RAM. Voor Llama 3.2 3B en Granite 4.1 3B is dat circa 6 GB, en voor Qwen3 4B circa 8 GB.

CPU-inferentie met direct gebruikte gekwantiseerde gewichten

NightRun ondersteunt momenteel geen GPU.

De motor is gericht op gekwantificeerde inferentie op CPU, waarbij de gewichten zonder eerst een volledige kopie in FP32 te decomprimeren direct worden gebruikt.

Op x86_64 implementeert het specifieke kernels voor AVX2, FMA en F16C. Op ARM gebruikt het NEON, met een route gebaseerd op sdot voor compatibele processoren zoals de Cortex-A76 van Raspberry Pi 5.

De QUANTisaties omvatten Q8_0, Q4_K en Q6_K, naast enkele tensors in F32.

Een opvallende eigenschap van het project is dat Q4_K_M niet betekent dat alle tensors in Q4_K staan. Een model kan een mix van Q4_K, Q6_K en F32 gebruiken afhankelijk van de tensor. NightRun behoudt deze quantisaties tijdens conversie.

Het prefill proces verwerkt tot 64 tokens per keer, terwijl het decode token-voor-token werkt.

Dit is relevant omdat beide fasen verschillende profielen hebben. Het initiële proces kan gewichten hergebruiken tussen tokens, terwijl tijdens interactief genereren de prestaties sterk afhankelijk zijn van geheugentoegangssnelheid.

NightRun onderkent ook dat de aandachtmechanisme van transformers de gegenereerde output vertraagt naarmate de context groter wordt, doordat de KV-cache groter moet worden doorzocht.

Llama, Qwen en Granite, maar geen willekeurig GGUF

NightRun streeft niet naar universele compatibiliteit.

De standaard ondersteunt momenteel drie families: Llama 3.2, Qwen3 en Granite 4.1 in hun standaard transformer-architectuur.

Hibridvarianten van Granite, zoals SSM/MoE, worden expliciet afgewezen tijdens de conversie. Het toevoegen van een nieuwe architectuur vereist de implementatie en validatie van de uitvoering, niet simpelweg het toevoegen van een naam.

Hier zit een aanzienlijke technische uitdaging achter.

Qwen3 bijvoorbeeld gebruikt een andere RoPE-ruimte, RMSNorm-normalisatie voor Q/K en een andere aandachtbreedte dan Llama. NightRun implementeert deze verschillen rechtstreeks in plaats van ze te laten resulteren in een generieke laag.

Ook de tokenizer wordt op een vergelijkbare manier behandeld.

De conversatiesjablonen worden token-voor-token vergeleken met apply_chat_template van Hugging Face, en er zijn tests om te voorkomen dat gebruikersinvoer per ongeluk wordt geïnterpreteerd als control tokens.

De correctiereferentie is llama.cpp

Een van de meest intrigerende technische aspecten van het project is de poging om te controleren of het verwijderen van zoveel lagen de uitkomst van het model niet beïnvloedt.

NightRun gebruikt llama.cpp als referentie voor greedy-generatie.

Voor de ondersteunde families dienen wijzigingen in de motor de token-voor-token generatie te behouden ten opzichte van de referentie. Scalar kernels worden gebruikt om de vector-implementaties voor AVX2 en NEON te verifiëren.

Het project controleert tevens dat de batch-prefill dezelfde logits en KV-cache produceert als het sequentieel verwerken van tokens.

Dit garandeert niet dat NightRun foutvrij is, maar geeft wel een reproduceerbare methode om afwijkingen op te sporen in een bijna vanaf nul opgebouwde inferentiemotor.

Het project waakt er ook voor om niet de snelle verleiding te volgen: garandeert niet dat het overall sneller is dan llama.cpp.

De gepubliceerde benchmarks tonen circa 20 tokens per seconde tijdens de decode van Llama 3.2 1B op QEMU/KVM met acht cores en AVX2. Granite 4.1 3B haalt circa 13-14 tokens/sec, en Qwen3 4B ongeveer 10-11.

Op de Raspberry Pi 5 bereikte Granite 4.1 3B 3 tokens per seconde in de gepubliceerde test, hoewel die meting voorafging aan de nieuwe sdot-kernels.

De documentatie schat dat de decode-snelheid onder bepaalde omstandigheden vergelijkbaar kan zijn met llama.cpp, terwijl de prefill tussen 1,15 en 1,4 keer trager uitvalt.

Het doel is niet om records te breken. De kernvraag is: waar kan het model draaien?

Geen TCP/IP: isolatie is geïntegreerd in de architectuur

Een machine met Ollama kan ook fysiek losgekoppeld worden van internet. Praktisch biedt dat een uitstekende isolatie, mits goed geconfigureerd.

NightRun neemt een nog radicalere keuze: er is geen netwerkstack binnen de runtime.

Geen browser, geen daemons, automatische updates, telemetrie of processen die per ongeluk een TCP-verbinding kunnen openen omdat de software daarvoor niet aanwezig is.

Dit vermindert de actieve softwarelaag bij een sessie aanzienlijk, maar maakt het apparaat niet automatisch ondoordringbaar.

UEFI blijft wel onderdeel van de vertrouwensketen. Ook het model, de gegenereerde output, het systeem waarmee het voorbereid is, en de eigen code van NightRun zijn belangrijke aspecten voor de beveiliging.

Daarom is het project vooral interessant vanuit systeemarchitectuur-oogpunt, meer dan als een absolute beveiligingsclaim.

Een AI-project dat ook met AI werd gebouwd

NightRun heeft nog een opmerkelijke eigenschap: de ontwikkelaars melden dat het grootste deel van de code met Claude Code en het Fable 5-model geschreven is.

Dat is opvallend vanwege het soort software dat ontwikkeld wordt.

Het betreft geen reguliere webapplicatie. De repository bevat code voor UEFI, binaire formaten, SIMD, geheugenbeheer, tokenisatie, gekwantificeerde inferentie, framebuffer en een installer die direct naar opslag schrijft.

Daarom hechten de makers veel belang aan validatie via referentie-implementaties, vergelijking met llama.cpp, parser-tests en installercontroles.

NightRun blijft voorlopig experimenteel. Het vereist UEFI, Secure Boot uitgeschakeld, modellen die geheel passen in RAM, en een redelijk moderne CPU voor interactiviteit. De hardware-ondersteuning voor x86_64 is nog beperkt en firmware-implementaties kunnen verschillen, wat incompatibiliteit kan veroorzaken.

Toch biedt het technologische vraagstukken over de toekomst van lokale AI.

Waar men vroeger vooral probeerde om elke keer een LLM makkelijker binnen het OS te laten draaien, gaat NightRun de andere richting uit: het verwijderen van conventioneel OS en het tijdelijk omvormen van de computer tot een dedicated appliance voor het model.

Het resultaat is niet bedoeld om de gebruiksvriendelijkheid van Ollama te evenaren. Het is een ander soort systeem: een inferentieruntime die vanaf USB start, gewichten in RAM laadt, en zonder schijf of netwerk werkt.

Voor privacy-onderzoeken, geïsoleerde systemen en edge computing kan dat juist veel interessanter zijn dan enkele extra tokens per seconde.

Bron: Nieuws over kunstmatige intelligentie