NVIDIA heeft Dory 1.0 4B uitgebracht, een klein redeneermodel van Nemotron Labs waarvan de centrale lagen een gedeeld blok vormen, dat één, twee, drie of vier keer per token kan worden toegepast. Volgens een tutorial van MarkTechPost maakt deze werking het mogelijk om hetzelfde bestand op vier verschillende rekenniveaus te draaien, zonder hertraining.
- NVIDIA Dory 1.0 4B draait op vier rekenniveaus zonder hertraining.
- Het model gebruikt llama.cpp en een GGUF-bestand van 3,7 GB.
- Het bestand start standaard met vier loops, terwijl de modelkaart er twee aanbeveelt.
- De llama.cpp-commit moet worden vastgezet, omdat de Dory-ondersteuning nog een concept pull request is.
Elke extra passage door het blok, een zogenaamde loop, verbruikt meer rekenkracht per token zonder ook maar één extra parameter toe te voegen. De tutorial gebruikt de llama.cpp-engine en een GGUF-bestand van 3,7 GB, in Q5_K_M-kwantificatie, wat betekent dat het gecomprimeerd is om de geheugengrootte te verkleinen. De gebruikte llama.cpp-versie komt overeen met de commit die in de modelkaart van NVIDIA is vastgezet, aangezien de ondersteuning voor Dory nog een concept pull request is. De bestandsnaam wijkt af van die in de modelkaart, waar dory-q5_k_m.gguf wordt vermeld, en de tutorial raadt daarom aan om de grootte en SHA-256-hash te controleren. Het gedownloade bestand komt overeen met de controlesom die NVIDIA heeft gepubliceerd.
Een architectuur die rechtstreeks uit het bestand wordt gelezen
De header van het GGUF beschrijft de structuur van het model nog voordat het wordt geladen. Dory heeft 72 laaginvoeren, verdeeld over 16 invoerlagen, 40 recurrente lagen en 16 uitvoerlagen. Het recurrente blok vertegenwoordigt 1,84 miljard van de 3,98 miljard parameters van het model.
De header geeft ook een standaard aantal loops van 4 aan, terwijl de modelkaart er 2 aanbeveelt. Een server die zonder expliciete optie wordt gestart, werkt dus met de duurste instelling. Volgens de tutorial moet deze parameter altijd handmatig worden ingesteld.
Op basis van deze gegevens schat de tutorial de kosten van elke loop. Een token passeert het recurrente blok één keer per loop, zodat vier loops 2,51 keer de parameters van een enkele loop toepassen en 2,28 keer de gewichtsbytes lezen, waarbij deze leesoperatie de bepalende factor is voor een door geheugen beperkte decodering. De KV-cache, het geheugen dat de berekeningen van eerdere tokens bewaart, varieert afhankelijk van de gekozen modus. In de per_loop-modus gaat het van 306 MiB bij één loop naar 816 MiB bij vier loops, voor een context van 4.096 tokens. In de last_loop-modus blijft het op 306 MiB, ongeacht het aantal loops.
Metingen om de voorspellingen te verifiëren
De bijbehorende notebook controleert vervolgens deze schattingen op een draaiende server. Het meet de decodersnelheid voor elk aantal loops, test of de last_loop-cache de voorspellingen van het model verandert en vergelijkt de verdelingen van volgende tokens tussen verschillende instellingen. Het voert ook een gepaarde evaluatie uit op 30 vragen van de GSM8K-testset, een benchmark voor wiskundige problemen, waarbij het de nauwkeurigheid, de lengte van de antwoorden en de tijd per opgeloste vraag meet.
De tutorial preciseert dat de modelkaart prestaties op andere benchmarks aankondigt, zoals SWE-bench of GPQA, die in dit kader niet worden gereproduceerd, net als de context van 256K tokens en de voorpretraining in NVFP4.
De notebook is toegankelijk op GitHub, in de repository van MarkTechPost gewijd aan agent- en tutorialprojecten. De auteurs benadrukken twee punten: stel het aantal loops expliciet in, omdat het GGUF er standaard vier gebruikt, en zet de commit van de llama.cpp-fork vast, omdat de ondersteuning voor Dory nog een concept pull request is.
