Nvidia brengt aanpasbaar opensource-AI-model uit dat op één gpu draait - update2

Nvidia brengt een opensource-AI-model uit dat aanpasbaar is en lokaal draait op een enkele gpu. De mogelijke aanpassingen die gebruikers en ontwikkelaars kunnen maken, zijn voor het trainen van Nemotron 3.5 Lightning. Daarmee krijgt het bijvoorbeeld een eigen schrijfwijze of programmeerstijl.

Nemotron 3.5 Lightning is gratis beschikbaar op AI-platformen als Hugging Face, ModelScope, OpenRouter en bij Nvidia zelf. Het draait lokaal op computers met Nvidia-hardware. De gpu-maker noemt de eigen RTX-pc's en DGX Spark-workstations, maar ook AI-systemen van producenten als Acer, ASUS, Dell, GIGABYTE, HP, Lenovo, MSI en Supermicro. Het AI-model kan ook opschalen voor gebruik op servers in datacenters en cloudomgevingen.

Nvidia stelt dat zijn nieuwe AI-model dankzij de aanpassingsmogelijkheden en toegang tot lokale apps, bestanden en andere tools gepersonaliseerde AI-agents mogelijk maakt. Deze agents kunnen gebruikers helpen met hun e-mails en agenda's, dagelijkse smarthometaken en lokaal programmeerwerk.

Sneller, beter

Nemotron 3.5 Lightning is volgens Nvidia tot wel vier keer sneller in het genereren van tokens dan 'open modellen in zijn klasse'. Ook zou het nieuwe AI-model 30 procent sneller zijn in het uitvoeren van taken. Het bedrijf specificeert in het persbericht niet met welke AI-modellen het zijn nieuwe openweight-AI-model vergelijkt. In een technische blogpost noemt Nvidia onder meer Qwen3.6-35B en Gemma 4 26B.

Nvidia vermeldt niet wat de minimale vereisten zijn, zoals gpu-geheugen, om het nieuwe Lightning AI-model te draaien. In documentatie, technische blogposts, YouTube-video's, repositories op GitHub en informatie op andere plekken noemt de gpu-maker wel de RTX 5090-videokaart, die 32GB geheugen heeft. AI-softwareplatform Ollama noemt 23GB en 25GB voor verschillende uitvoeringen van Nemotron 3.5 Lightning.

Update, 19.16 uur – Toegevoegd dat onduidelijk is hoeveel gpu-geheugen Nemotron 3.5 Lightning vereist.

Update, 13 aug, 13.03 uur – Nvidia antwoordt op vragen van Tweakers dat de minimale vereiste voor gpu-geheugen '24GB bij NVFP4' is. NVFP4 is een eigen, geoptimaliseerd dataformaat van Nvidia voor AI-berekeningen.

Nemotron 3.5 Lightning, positionering Beeld: Nvidia
Nemotron 3.5 Lightning, positionering Beeld: Nvidia

Door Jasper Bakker

Nieuwsredacteur

11-08-2026 • 17:37

94

Reacties (94)

Sorteer op:

Weergave:

Hoeveel GB vram heb je dan nodig dus? Wordt mij niet heel duidelijk
De vergelijking met Qwen3.6-35B en Gemma 4 26B doet mij vermoeden dat het minimum 24 GB of 32GB zal zijn, afhankelijk van de kwantisaties van het model en de context. Ter vergelijking: Met NVFP4 voor het model en FP8 voor de context neemt Gemma 4 26B zo'n 17GB à 20 GB in.
Dus met andere woorden: Nvidia was waarschijnlijk van plan om rond deze tijd al de RTX 50 Super kaarten op de markt te hebben, want momenteel heeft Nvidia geen betaalbare kaarten met 24 GB VRAM om deze modellen op te draaien, en met de 50 Super series zouden ze tenminste de 5070 Ti hebben.
De RAM hoeft volgens mij niet exclusief van de GPU te komen, maar kan ook gecombineerd worden met de overige RAM in het systeem. Maar ik geloof best dat hun productplanning wat deukjes heeft opgelopen. 😅
Het hoeft niet, maar erg fijn werkt systeemgeheugen ook niet. De snelheid kakt heel snel in als je dat gaat doen.
Als je een goede iGPU hebt, met (voor standaard ram) relatief snel geheugen, gaat dit best vlot draaien omdat er maar 3B parameters actief zijn omdat het een MoE model is. Dit model is juist gemaakt voor gedeeld systeem geheugen, want het is een MoE. Dence is voor dGPU's omdat die alle parameters in het geheugen stoppen.
Dat is de grap. In theorie is dat heel misschien zo, maar als je ook maar enigszins snel wil redeneren, dan zal je toch zo veel mogelijk parameters in het geheugen van de kaart willen laden. Daarnaast geld dat de besparing niet opgaat voor de context, en dat is waar je met dit model toch echt veel mee wil doen. Dus nee, dit model is in de verste verte niet geschikt om op een iGPU te draaien.

[Reactie gewijzigd door ocf81 op 11 augustus 2026 22:59]

Wat je zegt klopt gewoon niet. Ik draai heel erg capabele MoE modellen, vooral Qwen 3.6 32B A3B, ontzettend snel op mijn Strix halo, en zelfs erg vlot op mijn 6 jaar oude Ryzen met iGPU AM4 systeem. Zelfs op de 6 jaar oude ryzen haalt hij 9 t/s. En op de Stix halo zit ik rond de 40 t/s.
En ondanks dat je bij de MoE versie van Qwen 3.6 maar 3B parameters actief zijn (ze staan overigens wel allemaal in het geheugen) hoort de MoE versie van Qwen bij de top van zijn klasse, en zijn de prestaties bijna gelijk met het 27B dense model, waar je wel een dGPU voor nodig hebt.
Ik zou me even in MoE modellen verdiepen.
Ik weet wel waar ik het over heb. Daarom zei ik ook dat het in theorie wel klopt, maar in de praktijk niet. Want in de praktijk is het nog steeds zo dat het inladen van de diverse experts veel tijd kost. 9 tokens per seconde is dan ook niks om over naar huis te schrijven. En als je hetzelfde model op een 9700 of 5090 zou draaien dan zou je dat ook gelijk terugzien in de prestaties, omdat het gewoon wel een verschil maakt.
9 tokens per seconde is dan ook niks om over naar huis te schrijven.
Ik geef die extreme situatie met een zes jaar oude Ryzen op AM4 alleen als voorbeeld.
En als je hetzelfde model op een 9700 of 5090 zou draaien dan zou je dat ook gelijk terugzien in de prestaties, omdat het gewoon wel een verschil maakt.
En ja, je kunt een MoE-model op een dGPU draaien, maar dat zou in de meeste gevallen een beetje onlogisch zijn. Op een dGPU draai je juist eerder een dense model. Een dGPU heeft over het algemeen relatief weinig, maar wel zeer snel VRAM. Daardoor kun je beter een kleiner dense model gebruiken waarbij alle parameters actief zijn. De geheugenbandbreedte en GPU-rekenkracht zijn daar immers ruim voldoende voor.

MoE-modellen komen juist veel beter tot hun recht op systemen met een iGPU en veel gedeeld RAM. Je hebt daar veel meer geheugen beschikbaar, maar dat geheugen is aanzienlijk langzamer. Het totale model kan daardoor groter zijn, omdat er genoeg RAM is, terwijl per token maar een relatief klein deel van de parameters actief hoeft te zijn. Dat sluit veel beter aan bij de lagere GPU-rekenkracht en geheugenbandbreedte.

En ja, ik gaf mijn oude Ryzen bewust als extreem voorbeeld om duidelijk te maken dat wat je zei niet klopte. Maar zulke MoE-modellen draaien natuurlijk fantastisch op bijvoorbeeld Strix Halo en Intel Core Ultra X-systemen. Daar halen ze tientallen tokens per seconde met een geheugenbandbreedte die maar een fractie is van die van een gemiddelde dGPU.

Als ik op mijn Strix Halo een dense model zoals Qwen 3.6 27B draai, is het niet vooruit te branden. Dat kan zelfs langzamer draaien dan een MoE-model op mijn veel oudere Ryzen-systeem. Maar zodra ik op diezelfde Strix Halo een geschikt MoE-model draai, vliegt het.
Hij weet in de praktijk wat beter waar hij het over heeft imo, en bij mij in het gesprek zatje er ook naast met die context size memory behoefte...
Tja, terwijl je in de discussie waar je aan refereert van niks weet geef je hier een juryrapport af. Heel geloofwaardig.... (niet dus)
Ik heb dan ook helemaal geen behoefte om binnen jouw beperkte contextvermogen te willen passen. Hoopte echter dat er nog net een "snap dat je dit onderwerp leuk vind en wilt mee praten, maar stop met kletskouzen want je creert verwarring en onnodige discussies en twijfels bij mensen die echt wel weten waar ze zelf mee bezig zijn" bij paste...
Oh echt waar? Ik ga gelukkig zelf over wat ik zeg en doe. :w
Niemand beweert dan ook anders, maar men kan altijd hopen dat men wat van een ander aanneemt ten goede van de groep 😜
Eens. Ik draai divere MoE modellen op m'n Ryzen 7 8900G met 64 GB RAM. O.a. bartowski Kwaipilot_KAT-Coder-V2.5-Dev-Q4_K_L.gguf 18 t/s is een erg resources efficiënt en wat mij betreft m'n beste model voor C programmeren. En m'n RAM en SoC blijven goed koel met dit model.

[Reactie gewijzigd door blackSP op 12 augustus 2026 11:45]

Waarom zouden ze betaalbaar moeten zijn? Er is een gigantische vraag. Met betaalbaar snijden ze zichzelf alleen maar in de vingers.
Das niet waar dat er een gigantische vraag is wat ze zo onbetaalbaar maakt. Er is gewone vraag, maar er is amper aanbod. Er is niets voor niets momenteel een proces bezig om samsung en zijn 2 mede-schurk-collega's te laten kappen met deze prijzen- en beschikbaarheidsmonopolie op geheugen.
Je beweert serieus dat er op dit moment geen grote vraag is? Ok…
Ja dat had ik beter kunnen verwoorden: Geen andere vraag dan anders vanuit de consument.

Ik doelde er op dat het niet zo is dat particulieren massaal de vraag hebben verhoogd. Maar ze kiezen er voor ons niet meer te verkopen voor de normale prijs omdat ze allemaal afspraken maken voor de vraag van techgigsnten voor hun toekomstige hardware in toekomstige datacenters die allemaal nog gebouwd moeten worden en die vele hogere prijzen over elkaar heen bieden. Als ze consumenten dat geheugen op dit moment wel gunnen zijn wij als kleine groep particulieren echt niet in staat om zo'm toekomstige datacenter in de droogte te zetten kwa geheugen. Nu niet en in de toekomst niet.

Het is voluit een keuze van de big bad 3 om er nu de hoofdprijs voor te vragen en de beschikbaarheid laag te houden voor consumenten.

(Nu ik meer koffie op heb denk ik dat ik te veel af geef op de geheugenmakers, gezien een partij als Nvidia er nog tussen zit bij consumenten en zij enorm bankieren op die gpu behoefte momenteel van datacenters. Buiten de toekomstige chipmakers in deze markt kiezen zij er ook wel voor om hun off-the-shelf blackwells nu in mindere mate aan te bieden aan consumenten zolang ze nog kunnen scoren op DC-boeren. Ik laat de reactie staan omdat ik het al had gepost en die geheugenprijzen vooral gebasseerd zijn op toekomstige bestellingen en een onnodige schaarste op dit moment)

[Reactie gewijzigd door jackyallstar op 12 augustus 2026 09:06]

Dat valt hier niet per se uit op te maken. De ontwikkelcycli van modellen zijn vele malen korter dan die van grafische kaarten, en als je meer context wil kost dat ook meer geheugen. Ik heb wat beter naar de parameters van het model gekeken, en 32GB lijkt me nu waarschijnlijker, omdat de contextomvang 1M is.
Dit is een MoE model, dit draai je in de praktijk niet op een dGPU maar op een iGPU, zoals de DGX Spark (Of andere apu zoals Strix Halo, Ryzen versie met een G, of de nieuwere Intel® Core™ Ultra X)
Ik weet niet waar je het vandaan hebt, maar de Spark is geen CPU met een iGPU in de traditionele zin van het woord. Het is een GPU die toevallig een CPU eraan geplakt heeft met een loeisnelle verbinding. De chiplets zijn dan ook aan elkaar geplakt om dat voor elkaar te krijgen. Strix Halo poogt min of meer hetzelfde, maar is al veel minder snel qua verbinding met de CPU. De andere oplossingen die je noemt zijn nagenoeg kansloos als het om inferentie gaat.
Zowel de Spark als de Strix halo, zijn gewoon iGPU's. Hoewel ze wat krachtiger zijn, is het nog steeds iets totaal anders dan een dGPU.

Ik zou me echt wat beter verdiepen in de materie. Bijvoorbeeld geheugenbandbreedte's van Sparc en Strix Halo, liggen voor gedeeld geheugen wellicht hoger dan de gemiddelde normale RAM, maar alsnog totaal niet in de buurt van een dGPU. Dus daarom zijn MoE modellen hier zo geschikt voor.

Inference heeft vooral geheugenbandbreedte nodig. Als je veel actieve parameters hebt, heb je veel geheugen bandbreedte nodig. Daarom, is MoE voor de iGPU met relatief lage geheugenbandbreedte, en Dense voor een dGPU met hoge geheugenbandbreedte.
De andere oplossingen die je noemt zijn nagenoeg kansloos als het om inferentie gaat.
Ik draai hier Qwen 3.6 32B A3B op een 6 jaar oude Ryzen 7 5700G met 64GiB ram, met een best trage iGPU op 9 t/s.

[Reactie gewijzigd door Emielio op 11 augustus 2026 23:09]

Je haalt even twee dingen uit elkaar: een Strix Halo of een GB10 is niet te vergelijken met wat men doorgaans als iGPU betitelt. Ik zie het dan ook als een andere klasse die nog een naam moet krijgen die de lading goed dekt. De GB10 is een CPU met een dGPU erop gelijmd, maar dan met LPDDR5 geheugen in plaats van GDDR6 of beter. De geheugenbandbreedte is bij deze processoren echt een paar slagen beter dan die van een iGPU of APU op een moederbord met voetje, en dat is wat het verschil maakt. De inferentiesnelheid schaalt zo ongeveer lineair met de geheugensnelheid. Wat je op een iGPU of APU aan prestaties krijgt is gewoon niet heel indrukwekkend als je het vergelijkt met de prestaties van een dGPU. Dat je het aan de praat krijgt betekent niet dat het werkbaar is.

Een MoE model maakt het mogelijk om de lagen makkelijker apart van elkaar te gebruiken. Dat betekent dus een kleinere actieve geheugenafdruk. Die is nog steeds even afhankelijk van de geheugensnelheid. En de resultaten laten ook zien waar het steken laat vallen. MoE modellen scoren relatief lager op de nauwkeurigheid.

Ik heb overigens het hele scala al zelf aan den lijve ondervonden. Van inferentie op de CPU tot meerdere kaarten tegelijk. Ik weet zeer goed waar ik het over heb. Echt werkbare inferentie vergt ook een deftige snelheid. Negen token per seconde is dat niet, en al helemaal niet met een context die relevante hoeveelheden informatie moet vasthouden. Als je nul context heb, dan merk je dat niet zo. Maar bij een context van enigszins representatieve omvang (>30k) gaat dat heel snel merkbaar worden.

[edit]
Wellicht is het interessant om in Ervaringen met zelf gehoste AI assistenten je ervaringen m.b.t MoE te delen. Op zich ben ik wel benieuwd hoe je dan precies het verschil met dGPU's wil duiden als het gaat om het behalen van dezelfde nauwkeurigheid en snelheid. Want een mix van experts model is geen panacea. Er zijn duidelijke bezwaren bij dat soort modellen. Die kleinere activatieomvang zorgt er ook voor dat het model niet zo nauwkeurig is. Om appels met appels te vergelijken moet je dan wel een model van vergelijkbare nauwkeurigheid er tegenover zetten.

[Reactie gewijzigd door ocf81 op 11 augustus 2026 23:42]

Ik zie het dan ook als een andere klasse
Dat kan je wel "vinden". Maar de realiteit is dat het gewoon iGPU's zijn, alleen hele sterke. De Ryzen G versies van 6 jaar geleden werden destijds ook als een andere klasse beschouwd, en als je kijkt naar Apple silicon zijn dat ook ontzettend sterke iGPU's. Maar het blijven gewoon iGPU's ondanks je mening. iGPU is iGPU, ook als die krachtig is. Waar trek je anders de grens. De grenzen van snelheden van iGPU's worden al 10 jaar elke keer verlegd.
GB10 is een CPU met een dGPU erop gelijmd
Dat zijn alle Ryzens G, Apple silicon, en de nieuwe Intel Core Ultra X apu's ook.
De geheugenbandbreedte is bij deze processoren echt een paar slagen beter dan die van een iGPU of APU op een moederbord met voetje, en dat is wat het verschil maakt.
Nee dat is slechts een verdubbeling of hooguit verdrievoudiging. Terwijl naar een dGPU 10 tot 20 voudige geheugensnelheden hebben.
Vergelijk maar eens de geheugenbandbreedte van een simpele doorsnee CPU, die van de Sparc/StrixHalo en dan die van de 5090.
Ik heb overigens het hele scala al zelf aan den lijve ondervonden. Van inferentie op de CPU tot meerdere kaarten tegelijk.
Ik heb zelf vooral ervaring met inference op CPU tot iGPU, en dan dus sinds anderhalf jaar Mac Mini M4 Pro (ook sterke iGPU) en daarna Strix halo. (Binnenkort komt daar de Intel Core Ultra X bij, die MoE modellen ook best vlot zal draaien)

Jij met dGPU's. Ik ga er dan toch vanuit dat jij liever dense modellen draait of niet? Want je hebt Dgpu's?
Maar je snapt dan toch ook dat ik op mijn Strix Halo liever een MoE draai? En dat 40 tot 50 t/s voor een Qwen MoE thinking model toch gewoon werkbaar is. En jij weet toch ook dat hoewel een MoE model minder acuraat is dan een Dense model dat Qwen 3.6 32B A3B (een MoE model) op dit moment samen met de 27B dense het meest capabele is in zijn klasse?
Ik moet je op zich gelijk geven dat het wel wat in de bandbreedte scheelt als je op parameterbasis gaat vergelijken. Het gaat (mij) uiteindelijk om de resultaten en bruikbaarheid.
Als je een relevante nauwkeurigheid wil, dan is een iGPU of AI processor zoals de GB10 of Strix Halo* nog steeds veruit minder performant. Ik heb daarom inderdaad een sterke voorkeur voor modellen met hoge dichtheid op een dGPU. Dat het dan nog net werkt op een iGPU of een AI processor, is dan een leuke bijkomstigheid, maar niet de definiërende factor in hoe ik naar een model kijk.

* Het zijn toch echt andere beestjes, de opstelling, helemaal bij de GB10, is toch fundamenteel anders qua interne verbindingen en dat maakt een hele andere manier van verwerken mogelijk. Net alsof een Matrox Millennium een 3D accelerator kaart zou zijn, technisch kon ie het, maar het was gewoon niet hetzelfde. Zo'n kenmerkend verschil in opzet is, ondanks de gedeelde geschiedenis toch een punt waar de wegen scheiden.

[Reactie gewijzigd door ocf81 op 12 augustus 2026 00:26]

Er is natuurlijk ook nog een L4. Die is speciaal bedoeld voor AI inference met kleine modellen.

De aanname dat dit voor hobbyisten bedoeld is lijkt me ongefundeerd. De aanname dat de AI tak zich laat leiden door de consumententak is dat al helemaal.
Ik zie eigenlijk de afgelopen weken en maanden een voorzichtige verschuiving weg van gecentraliseerde generieke generative AI modellen in de cloud, met meer AI gebruik lokaal, on-premise en edge compute.
Op huggingface zie ik een 5090 als compatible hardware in de tabel, dus ik vermoed dat het nu minstens 24GB zal zijn.
Minimaal 16GB vram voor zover ik kan achterhalen. Gezien de sizing zou 24GB+ ideaal zijn. Verder hebben ze het over H100 en DGX hardware en daar draait het prima onder.
Ik ben erg benieuwd mijn arc kaart kan niet echt speterende modellen kwijt in 12Gb. ik denk dat dit meer een DGX dingentje wordt.
30B x 0.65 = 19,5

Dus zeg maar ongeveer 20GB
Ligt er aan welke variant je pakt en in welk type geheugen je get wil draaien, het model zelf is 1GB-64GB, afhankelijk van hoe uitgekleed het model exact is.

Als je alleen het expert gedeelte wil draaien in VRAM, zal dat 1/10e zijn van het geheel, plus je context window. De rest zal dan in je RAM moeten, of als je echt engelengeduld hent, op een SSD...
Het is een MoE model met 30B parameters, waarvan 3B actief. Downloads zie ik afhankelijk van de quant, tussen de 25 en de 35. Dus ga maar even uit van 32GiB voor een lagere (Q4) quant.
Maar dit is dus wel op een iGPU te draaien omdat het een MoE model zijn waarbij er maar 3B parameters actief zijn en dus niet teveel GPU kracht en vram bandbreedte nodig is. Dit draait dus perfect op een recente ryzen, met iGPU, en 64GiB gedeeld RAM geheugen.

Een dense model gebruikt alle parameters tegelijk en past daardoor goed bij een dGPU met snelle VRAM. Een MoE-model activeert per token slechts enkele experts en werkt daarom efficiënt op een iGPU met veel gedeeld RAM.

Verder, als ik naar het leaderboard kijk: https://artificialanalysis.ai/leaderboards/models
Dan scoort dit model nog een stuk lager dan Qwen 3.6 MoE van vergelijkbare grootte. En dat terwijl Qwen deze week 3.8 gaat uitbrengen in open weights, die nog veel beter gaat scoren. Dus ze lopen in de praktijk wel mijlenver achter op o.a. Qwen.
Het model is geoptimaliseerd voor Blackwell GPU's door gebruik te maken van NVFP4, daardoor gebruikt het minder geheugen dan op oudere NVIDIA GPU's of GPU's van AMD, Intel of Apple.

Hier is het model iets meer dan 19GB: https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4/tree/main

Een taalmodel heeft ook ruimte nodig voor de context - dat is je vraag en het antwoord, gemeten in tokens - en gebruik je typisch een key-value cache, zodat eerdere deel-antwoorden hergebruikt worden in plaats van opnieuw berekend.

In het ideale geval als vuistregel heb je een GPU nodig met ongeveer 2x de grote van het opgeslagen model als VRAM (bijvoorbeeld een 56GB model => 105GB VRAM).

Het model zal dus soepel draaien op een RTX 5090, DGX Spark, Surface RTX Spark, alle RTX Spark laptops, en de RTX Pro 5000, RTX Pro 6000 en DGX Station. En in je data center op B200 en B300. Zonder kv-cache ook op een RTX Pro 4000.

Heb je geen Blackwell maar meerdere RTX 4090 dan heb je 2x zoveel VRAM nodig. Heb je RTX 3090 kaarten of ouder dan heb je 4x zo veel VRAM nodig. In je data centrum geldt hetzelfde, de Hopper en Ampère architectuur hebben 2x of 4x meer geheugen nodig dan Blackwell om dit model te draaien.

Hoe komt dat? NVFP4 maakt gebruik van 4-bits floating point berekeningen, de oudere hardware doet die berekeningen in 8 bits of zelfs 16 bits geheugen.

De oudere architectuur gebruikt dus ook veel meer stroom voor het draaien van dit model en andere moderne AI-modellen.

Hierbij ook linkjes naar de twee andere modellen die genoemd worden in het Tweakers artikel, ook met NVFP4 Blackwell optimalisatie, zodat je ze ook zelf kunt vergelijken:Heb je twee DGX Spark kastjes of echt een groot GPU systeem kijk ook naar https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731

[Reactie gewijzigd door djwice op 11 augustus 2026 23:57]

Een Q4_K_M quantised GGUF voor gebruik in bijvoorbeeld Llama.cpp is ongeveer 25.4 gb (https://huggingface.co/ggml-org/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-GGUF/tree/main) - vertaalt niet helemaal 1 op 1 naar VRAM, maar komt aardig in de buurt. Dat is natuurlijk ook zonder context. Afhankelijk van je KV quantization (@llama.cpp: turboquant when?!) zou ik niet rekenen op meer dan 16k context ruimte op een 5090.

Nvidia noemt in hun model page op hugging face (https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4) overigens:

> 1× DGX Spark (GB10) or 1× H100

Dat is technisch misschien 1 GPU, maar een H100 is niet bepaald een consumenten kaart, ook al past het technisch op een 5090.

Echter: Er zijn maar 3 miljard actieve parameters vs 30 miljard totaal. Dat maakt het model waarschijnlijk relatief geschikt om met off-loading te werken. Je hebt dan wel veel werkgeheugen nodig want alles wat niet in je VRAM staat, zit dan in je werkgeheugen. Hoe goed en snel dat in de praktijk gaat zijn zal de tijd nog even moeten leren, maar het bied wel mogelijkheden. En als je 22.5 gig (theoretisch) in je reguliere RAM kwijt kan dan is er ineens ook met een kleine kaart best wat leuks te doen.

Vaak is een 30 B schaal model overigens nog wel te draaien op een 24 GB kaart mits je kleinere context accepteert en goed quantised op zowel model als KV cache, maar voor dit niveau modellen is 32 GB wel heel erg aan te raden, voor mij was het een behoorlijke verademing om te upgraden.

[Reactie gewijzigd door Drider314 op 11 augustus 2026 23:00]

Er staat dat het model "aanpasbaar" is, lijkt mij toch duidelijk dat je het dus zo kan aanpassen dat er geen minimum geheugen is? Binnen realistische moderne hoeveelheiden natuurlijk. Of mis ik iets fundamenteels in mijn begrip van dit soort modellen?
NVIDIA Nemotron 3.5 Lightning is een open 30B mixture-of-experts (MoE) model met 3B active parameters en is 25GB groot.

nemotron-3.5-lightning
Wat een rare tekstkeuze 'één GPU'? Qwen en Gemma kunnen ook prima 1 GPU draaien, je gaat alleen offloaden naar CPU (en geheugen) en je tokens/sec zakt in elkaar. Daarbij is 'één GPU' nog eens breed getrokken, wil je deze volledig op GPU draaien moet je alsnog tegen de 30GB geheugen op je GPU hebben, en dat clubje is niet bijzonder groot.
meeste mensen kunnen Qwen3.5 ook gewoon draaien op één GPU... wel 8B int4 en dat is niet echt een helder licht.
Uiteraard, maar dat zal wel gezien worden als 'andere klasse' (ik draai zelf Ministral 14B ook volledig op de GPU).
Qwen 27b Q4 haal je denk ik op 16gb 4080. Die draai ik zelf op 24gb 3090 met 50 tok/sec en dat is wel een redelijk licht
Onder KI-enthousiastelingen zal, als het om videogeheugen gaat, er toch een andere weging zijn dan onder degenen die hun systeem vooral voor spellen hebben gebouwd. Dit model is toch echt meer gericht op de eerste van de twee populaties.
Ja en dan staat er in het grafiekje een 80GB H100... 1 kaart van 40k eur :+
Idd het draai op 1 gpu dus ook mijn oude intel740 met 256 mb ram.

Snel zal het niet zijn maar draaien waarschijnlijk wel.
Is er een technische reden voor dat dit niet op AMD-kaarten draait? Ik vind vendor lock-in niet echt bij de spirit van open-source passen.
Technisch lijkt me niets in de weg te zitten om deze via LM studio op een W7900, maar of die zo snel is als de Nvidia varianten... dat denk ik niet.
Als het past, want ik zie dat de kleinste versie NVFP4 vereist. De BF16 versie past niet in de 48GB van een W7900, dat begint bij ca 70GB.
Waarschijnlijk omdat het gebaseerd is op CUDA.

Inmiddels wat verder naar gekeken en de delen die nu dan CUDA praten kun je wel porten naar bijvoorbeeld OpenCL of ROCm zodat het op any / AMD GPU goed kan werken.

[Reactie gewijzigd door VHware op 11 augustus 2026 18:07]

ROCm werkt alleen op nieuwere AMD-kaarten. GFX103x (rdna2 en ouder, min 4 jaar oud) zijn niet ondersteund onder windows en alleen gedeeltelijk onder linux. Cuda gewoon op een nvidia 2050.

OpenCL is minder geschikt voor deze toepassingen. Vulcan al iets beter.

(voor de kenners:qwen3.635ba3b op 8vram32intern @amd rtx6600 met 40-120 tps decoding en 20-30 tps thinking. Ben nog aan het optimaliseren)
Ja: Technische reden is dat je onder amd ofwel het rocM-platform gebruikt (meer lockin dan cuda), ofwel vulcan (denk oudere amd-kaarten). Cuda draait (hoewel slecht) theoretisch ook op amd gpu of zelfs x64 cpu.

Nvidia heeft door een andere achritectuur en eerdere instap in LLM's op consumentenkaarten al vroeg een enorme voorsprong genomen. AMD loopt simpelweg achter de feiten aan.

Nvidia heeft op haar blackwell-kaarten weer meer specialisatie toegevoegd om nog sneller te kunnen draaien. Maar uiteindelijk is geheugen de bottleneck. En deze kaarten gaan gewoon weer wat effectiever met geheugen om zodra deze nieuwe technieken worden gebruikt.

Het is geen vendor lock-in. Niets staat een fabrikant in de weg vergelijkbare technieken te gebruiken. De specifiek nvidia-eigen technieken halen het uiteindelijk toch niet.
Het is geen vendor lock-in.
Jawel, want het draait (zonder aanpassing) alleen op Nvidia-kaarten. Terwijl elk andere lokaal LLM voor desktop GPU's ook (beter?) draait op AMD.
Niets staat een fabrikant in de weg vergelijkbare technieken te gebruiken.
Niets staat Nvidia in de weg om dit model ook goed werkend te krijgen op AMD. Of een port van een 3e ontwikkelaar op te nemen in dit 'open-source' project.
Geef me de GGUF en ik draai het model hier lokaal op amd-only.

Sneaky gaat dit om een model (verzameling 'weights' / vectoren) en een stukje computationele techniek erachter. Die techniek is lock-in. Het model niet.
Is er ook zo iets voor AMD videokaarten om het lokaal te draaien (en dat het toch wel vlot werkt)?
Het kost wel een beetje geld om het aan de praat te krijgen op AMD, maar het lijkt me niet onmogelijk. de NVFP4 versie is alleen te gebruiken met nVidia hardware het omkatten van de NVFP4 kwantisatie is lastig, maar zou in de toekomst wellicht kunnen als iemand daarvoor de trainingsarbeid verricht. Dan blijft dus de BF16 versie over. Die heeft naar schatting zo'n 70GB aan videogeheugen nodig bij een context van ca 250k. Met een enkele kaart gaat het alleen werken als je op de een of andere manier een Instict kaart werkend krijgt, bijvoorbeeld een MI250 via een OAM adapterkaart. Maar met twee W7900's of met vier W6800's, W7800's, V620's of R9700's zou het misschien wel kunnen. Je begint dus bij ca €2k aan GPU's als je de oudere kaarten koopt (vier keer v620), maar het dubbele tot het drievoudige daarvan is waarschijnlijker.

[Reactie gewijzigd door ocf81 op 11 augustus 2026 20:59]

Ja. Ik draai puur amd en heb redelijke tps.

amd rtx 6600 / 8gb vram, genoeg cpu, 32gb intern. Ik focus me nu op qwen 3.6 35b a3b (MoE, MPT). Nu via kobold.ccp krijg ik 120+ understanding tps en 20+ thinking. Ik moet nog handmatig aan de gang met optimalisaties :)

Antwoord bij 32k context komt in leessnelheid op je scherm.
Wat bedoel je met 'zoiets'? Als je het over lokale AI modellen hebt; ja die zijn er al een tijdje, en de meeste zijn niet gebonden aan één specifiek merk.
Ik heb een Mac mini M1 met 16 GB ram. Zou dit model daar ook op kunnen draaien, via LM Studio bijvoorbeeld?
Ik denk van niet. In hoofdlijnen zijn twee versies vrijgegeven: een versie met NVFP4 kwantisatie en een versie BF16 kwantisatie van de parameters De eerste is exclusief voor nVidia hardware bedoeld. Er is, voor zover mij bekend is, geen apple of AMD tegenhanger van die kwantisatie. De BF16 kwantisatie heeft een stuk meer geheugen nodig. Maar zelfs als er een tegenhanger was van de NVFP4 kwantisatie zou die niet in het geheugen passen, omdat 16 GB nu eenmaal heel weinig is in KI-land. (het leven begint bij 32GB in deze contreien) En dan hebben we niet eens de maximum contextomvang in ogenschouw genomen, welke nog veel meer geheugen vraagt.
Als ik dit goed begrijp, dan is nvfp4 niet voorbehouden aan nvidia GPU's: https://ollama.com/blog/mlx-performance. In een MLX setup zou het ook op Apple M's te draaien moeten zijn.
Bedankt voor de link. Ik wist wel dat MLX voor apple bestaat, maar omdat ik verder niet met apple werk wist ik de details niet. MLX is dus een 4-bit kwantisatie. Weer wat geleerd. Maar hoe dan ook is 16 GB te weinig. 32GB lijkt me te doen bij beperkte contextomvang. Bij Apple moet er ook nog een OS in dat geheugen hè?
Als je de gguf pakt dan kan dat gewoon. Het model is alleen niet geoptimaliseerd voor jouw hardware. Zoek naar mac-eiegn optimalisaties. Zijn er van verschillende grote open modellen. Reken op rustig dubbele tokens per seconde als je pech hebt voor eenzelfde model :)
Mag hopen dat hij dan ook wat doet op wat lager dan een 5090 of niet minstens 2x een 3080 of 4080 nodig heeft om weer bij dat verrekte vram getal te komen dat die parameters überhaupt passen. En als je dan een 5090 hebt knalt alles meteen naar de 200+ tokens per sec. Er is weinig tussenin, of je kan er niets mee, of het vliegt de bocht uit zo snel. We hebben echt een middenweg nodig waarbij een videokaart met 16gb videogeheugen gewoon iets fatsoenlijks moet kunnen draaien.

Als nvidia dit vergelijkt met 35b modellen ben ik echter bang dat dit weer gewoon een reclame-spotje is voor de 5090 of de dgx spark 10
Ik begrijp helemaal waar je vandaan komt, maar ik vraag me af of het wel een reële wens is. Het aantal parameters en de omvang van de context vergen nu eenmaal een bepaalde hoeveelheid geheugen. Dat maakt dus dat je gewoon altijd een sloot geheugen nodig zal hebben om er iets nuttigs mee te kunnen doen. 32GB is min of meer de ondergrens voor ook maar enigszins nuttige zaken en als je écht iets wil met de machine moet dat eigenlijk al minimaal het dubbele, zo niet het viervoudige, bedragen. Dat geheugen moet ook nog eens snel zijn omdat het enorm vaak geraadpleegd wordt, waardoor systeemgeheugen minder geschikt is. (met acht kanalen DDR5 gaat het wel, maar met minder dan dat ga je al snel tegen beperkingen aanlopen)

[Reactie gewijzigd door ocf81 op 11 augustus 2026 19:25]

Ja die geheugen behoefte is dus waarschijnlijk niet geheel in steen gegoten, omdat sommige modellen in een nvfp4 (nvidia gpu's hebben dit) versie laten zien dat er genoeg parameters onnodig in bytes worden opgeslagen terwijl ze ook kleiner kunnen opgeslagen worden en geen 8 bits nodig hebben. Volgens mij zonder accuratieverlies.

Dit laat zien dat er een optimalisatieslag te vinden is in de wijze van hoe we met die 16gb vram om gaan en wat we er mee kunnen.
Zelfs dan is 16GB niet echt praktisch. De parameters laden is maar stap één, maar om echt nuttig gebruik te kunnen maken van een model moet je ook naar de context kijken. Het model is daarvoor simpelweg te groot en voor een contextomvang van enige relevantie moet je ook een aardige hoeveelheid geheugen vrijlaten.
Het geheugengebruik gaat per modelgeneratie geen ordes van grootte schelen. De prestaties zitten hem vooral in hoe je de context opbouwt. Die context is bij dit model FP8, en zal dus ook redelijk meer geheugen innemen dan wat de parameters vereisen.
Om dat concreter te maken zou je Nemotron 3 als proxy kunnen nemen. Dan zal je zien dat je bij een kaart met 16GB aan geheugen met ca. 41k aan context al uit je geheugen loopt wanneer je NVFP4/FP8 gebruikt. 41k is eigenlijk niet heel veel als het om langer lopende taken gaat.

Ga eens spelen met de VRAM rekenmachine van ApXML, dan zal je snel genoeg merken hoe de hazen lopen.
Je bevestigd me punt alleen maar: Ook context size is volledig afhankelijk aan hoe waardeloos we nu alles maar brute forcen naar 8 bits. Die context sizes liggen nu bovenop het model welke nu gewoonweg al te veel ruimte innemen, en de context size zelf wordt ook gebruteforced naar 8bits per parameter terwijl dat helemaal niet nodig is. Op dit moment doen we heel dom alles bruteforcen en moet verfijnde verwerking naar accuratere parameter memorysizes nog ontwikkeld worden.
Je weet dat context veel gevoeliger is voor fouten als je kleinere kwantisaties gebruikt?
Ik heb het niet over compressie, ik heb het over de ruwe waarde die helemaal niet zo veel bits nodig heeft om opgeslagen te worden omdat de waarde helemaal niet zo groot is. Dat is ook het hele idee achter nvfp4 bijvoorbeeld
VRAM Requirements for Local LLMs: The Complete Guide - 2026

[Reactie gewijzigd door WeirdScience op 11 augustus 2026 18:27]

Natuurlijk een handig lijstje. Helaas wel erg bevooroordeeld naar nVidia en hier en daar ook wat onnauwkeurig, als je het mij vraagt. (bijvoorbeeld dat alle modellen die over meer dan twee kaarten moeten worden verdeeld gelijk in een cluster zouden moeten draaien, terwijl je vier kaarten in een machine kwijt kan)
En over een maand of drie is ie waarschijnlijk al weer verouderd.
Ik ben benieuwd welke GPU's het gaan worden waar dit model op kan draaien. Een top-of-the-line GPU is alsnog niet te betalen...
Dit kun je op ontzettend betaalbare hardware draaien. Gewoon een GGUF variant downloaden, en draaien op een goedkope Ryzen G (is iGPU) AM4 met 64GiB ram.
Sneller, beter
Wat dat betreft ben ik een beetje skeptisch geworden als het om Nvidia gaat, ze kunnen hele mooie grafiekjes maken, maar die moet je soms met een korreltje zout nemen.
Je kan het in theorie draaien op 1 RTX 3090. vLLM gebruikt W4A16 Fallback om NVFP4 modellen te draaien op "oudere" kaarten.

Om te kunnen reageren moet je ingelogd zijn