Een unified-memory mini-pc van ruwweg $2.000 tot $3.000 kan sommige zwaar gekwantiseerde 235B-klasse modellen laden die niet passen op een één enkele GPU van H100-klasse.
Dat klinkt tegenstrijdig, dus laten we de vergelijking preciseren. De dure kaart is veel sneller, maar zijn lokale GPU-geheugen is kleiner. Het kleine kastje op het bureau heeft mogelijk een grotere gedeelde pool, waardoor het model kan laden, ook al verloopt het genereren traag.
Het antwoord in één woord op de hoe-vraag is "unified memory." Het staat op het specificatieblad van veel nieuwe AI-mini-pc's en Macs als een opvallend cijfer ("128 GB unified memory"), en bijna niemand legt uit wat het eigenlijk doet. Dat is hier de taak. Aan het eind weet je wat unified memory is, waarom het een klein apparaat in staat stelt om uitvoeren een model draaien dat vroeger een serverrack nodig had, en het addertje onder het gras dat niemand in de kop zet: het draait dat model traag.
Samenvatting
- Unified memory is één fysieke geheugenpool die de CPU en geïntegreerde GPU van een chip delen, in plaats van het kleine, aparte VRAM van een losse videokaart naast je aparte systeem-RAM.
- Die gedeelde pool is groot, en de GPU heeft meestal toegang tot veel meer geheugen dan de vaste VRAM-limiet van een losse kaart, al hangt de exact bruikbare hoeveelheid af van het platform, de firmware-instellingen, het besturingssysteem en de runtime. De eerste vraag wordt dus: past deze gekwantiseerde build in het bruikbare geheugen? Een pool van 128GB kan modellen bevatten die een videokaart van 24GB of 32GB nooit zou kunnen bevatten.
- Het addertje zit in de snelheid, niet in de omvang. Unified memory verplaatst data veel langzamer dan het VRAM van een losse kaart. Het grote model draait. Het genereert alleen traag tokens. Unified memory laat je het grote model draaien, niet snel draaien.
- "Unified" is niet één ding. Apples versie is voor de gebruiker grotendeels onzichtbaar; AMD's versie biedt meer knoppen, omdat firmware- en driverinstellingen kunnen bepalen hoeveel geheugen wordt gereserveerd voor, of praktisch bruikbaar is door, de GPU. En meer geheugen betekent niet sneller.
Wat is unified memory?
Stel je twee opstellingen voor. Een losse videokaart heeft zijn eigen geheugen (VRAM) vlak naast de processor, snel maar klein. Je systeem-RAM is een tweede, aparte pool die de CPU gebruikt. Om een model op de GPU te draaien, moet de data eerst van het systeem-RAM via de PCIe-bus naar het VRAM worden gekopieerd. Twee pools, één kopieerstap.
Unified memory gooit die scheiding overboord. Het is één fysieke geheugenpool die zowel de CPU als de geïntegreerde GPU van de chip delen, waardoor de GPU vanuit de gedeelde pool kan werken in plaats van te vertrouwen op een klein, apart VRAM-blokje. Op platforms zoals Apple Silicon voorkomt dit ook de oude kopieerstap via PCIe. Apples eigen uitleg over de architectuur beschrijft het als de CPU en GPU die "over hetzelfde geheugen werken" zonder dat data via een PCIe-bus hoeft te worden gekopieerd. Eén pool. Geen kopie.
De gedeelde pool is meestal LPDDR5X-geheugen dat op het package is gesoldeerd, wat het mogelijk maakt om zowel groot als dicht bij de processor te zijn. De opvallendste voorbeelden op dit moment zijn Apple Silicon Macs, AMD's Strix Halo-systemen gebouwd rond chips zoals de Ryzen AI Max+ 395, en Nvidia's DGX Spark. AMD's Ryzen AI Halo-ontwikkelaarsplatform vermeldt 128GB LPDDR5x-geheugen bij 256GB/s, terwijl Nvidia's DGX Spark vermeldt 128GB LPDDR5x unified systeemgeheugen bij 273GB/s.
Gedeeld geheugen tussen een CPU en een geïntegreerde GPU is niet nieuw. Laptops doen dit al jaren, en het was meestal een compromis: traag geheugen, en niet veel ervan. Wat veranderde, is de capaciteit bij bruikbare bandbreedte. Zodra een gedeelde pool groot genoeg werd, rond de 128GB-klasse, en toch snel genoeg bleef om de moeite waard te zijn, overschreed het de grens waarop zeer grote open-weight modellen lokaal konden passen. Dat is het hele verhaal. De architectuur is oud; de omvang is nieuw.
Een opmerking over "vs VRAM": mensen vragen of unified memory hetzelfde is als VRAM. Niet helemaal. VRAM is toegewijd grafisch geheugen op een losse kaart, snel en apart. Unified memory is één gedeelde pool die de taak van zowel VRAM als systeem-RAM vervult. Het ruilt de rauwe snelheid van de losse kaart in voor omvang en de mogelijkheid om de kopieerstap over te slaan.
Waarom moet een model in het geheugen passen?
Voor normale in-memory inferentie moeten de gewichten van het model zich bevinden in geheugen dat de processor kan adresseren. Als het bruikbare geheugen te klein is, laadt het model niet netjes op dat apparaat. Sommige tools kunnen delen van een model uitbesteden aan CPU-geheugen of opslag, maar dat verandert het prestatieprofiel drastisch en is niet hetzelfde als het model dat comfortabel past in GPU-adresseerbaar geheugen. Capaciteit is een harde poort die voorafgaat aan elke vraag over snelheid.
Dit is de hefboom die unified memory gebruikt. Veel consumentenvideokaarten hebben 24GB VRAM of minder, en zelfs de beste losse consumentenkaarten zitten rond de 32GB. Een model met 70 miljard of 235 miljard parameters is daar veel te groot voor. Ruwe 4-bit rekenkunde voor 235B parameters begint rond 118GB, nog vóór formatoverhead, runtime-buffers en contextgeheugen. In de praktijk variëren daadwerkelijk downloadbare builds sterk: bijvoorbeeld, Ollama's Qwen3-235B-A22B Q4_K_M-build staat vermeld op 142GB, terwijl agressievere lagere-bit-kwantiseringen dichter bij het bereik kunnen komen dat een unified-memory-machine van 128GB aankan. Dus de kaart die voor de taak is gebouwd, loopt zonder ruimte voordat hij kan beginnen. (Hoe die geheugencijfers worden berekend, parameters maal bytes per gewicht plus de overhead die de bestandsgrootte verbergt, is een apart onderwerp, en het het zusterartikel over kwantisatiewiskunde doet die berekening.)
Een unified pool van 128GB verandert het antwoord op één vraag: past deze specifieke gekwantiseerde build nadat het besturingssysteem, de runtime, de KV-cache en de GPU-toewijzingslimieten hun deel hebben genomen? Voor sommige agressieve 235B-klasse kwantiseringen, ja. Daarom kan een compacte unified-memory-doos soms een model laden dat een GPU met minder VRAM niet kan. Het is niet krachtiger. Het heeft alleen meer ruimte om het model in te plaatsen.
Dat is het eerste wat de koppen goed hebben maar onverklaard laten. De poolgrootte, niet de rauwe rekenkracht, bepaalt of het model überhaupt draait.
Waarom is unified memory langzamer dan een videokaart?
Tekst één token per keer genereren wordt beperkt door geheugen bandbreedte, niet door hoe snel de processor kan rekenen. Elk token dat je produceert vereist dat de actieve gewichten van het model door de processor worden gestreamd, dus het snelheidsplafond is hoe snel het geheugen de chip kan voeden. Dit is de goed gedocumenteerde "geheugengebonden" aard van single-stream decoding, waarbij de chip het grootste deel van zijn tijd besteedt aan wachten op geheugen, niet aan rekenen.
En bandbreedte is precies waar unified memory terrein verliest. AMD's Strix Halo-pool draait op papier op 256GB/s, en onafhankelijke tests bij llm-tracker.info meten in de praktijk ongeveer 212GB/s. De DGX Spark zit op 273GB/s. Een hoogwaardige losse videokaart daarentegen verplaatst data meerdere keren sneller, zijn toegewijde VRAM is daarvoor gebouwd. Dus wanneer een model past op beide zowel een unified box als een losse kaart, genereert de losse kaart merkbaar sneller tokens. Zelfde model, zelfde resultaat, heel andere snelheid.
Voor dense modellen is een handige vuistregel:
tokens per seconde ≈ geheugenbandbreedte ÷ modelgrootte in het geheugen.
Het is richtinggevend, geen benchmark, maar het verklaart de afweging: kleinere resident gewichten of hogere bandbreedte betekent meestal sneller decoderen. Pas voor MoE-modellen de regel niet direct toe op het totale aantal parameters. Capaciteit hangt nog steeds af van de totale opgeslagen gewichten, maar de snelheid per token hangt meer af van het geactiveerde pad, routeringsoverhead, cachegedrag en implementatie.
Eén nuance, dan laat ik het erbij: een verzoek heeft twee fasen. Het lezen van je prompt (prefill) leunt op rekenkracht. Het genereren van het antwoord (decode) leunt op bandbreedte. Het trage deel dat je voelt, woorden die één voor één verschijnen, is het bandbreedte-gebonden deel.
Dus dit is de conclusie die het specificatieblad overslaat: unified memory laat je het grote model draaien, niet snel draaien. Het wint het capaciteitsargument en verliest het bandbreedteargument. Of die ruil de moeite waard is, hangt volledig af van wat je doet, en dat is een eerlijke ruil om bewust te maken, geen verrassing die je pas na aankoop ontdekt.
Is alle unified memory hetzelfde?
Nee. "Unified" beschrijft een categorie, geen enkele implementatie, en de versies verschillen op manieren die ertoe doen. Apples versie is voor de gebruiker grotendeels onzichtbaar: het geheugen wordt standaard gedeeld. AMD's Strix Halo vergt meer handmatige bemoeienis: firmware- en driverinstellingen kunnen bepalen hoeveel geheugen wordt gereserveerd voor, of praktisch bruikbaar is door, de GPU. Beide zijn unified memory. Het is niet dezelfde ervaring.
Laat me het misverstand benoemen dat dit hele onderwerp veroorzaakt, want het is het meest voorkomende: meer geheugen betekent niet snellere inferentie. Het betekent dat een grotere model kan draaien. Iemand koopt een doos van 128GB in de verwachting van snelheid, laadt een model dat ook op een losse kaart van 24GB past, en is teleurgesteld dat het langzamer draait dan die kleinere kaart deed. Beide uitspraken zijn tegelijk waar: de grote pool bevat meer, en de kleine snelle kaart draait sneller op wat ze delen. Omvang en snelheid zijn verschillende assen. Unified memory koopt je alleen de eerste.
Een praktische kink in de kabel aan AMD-zijde: hoeveel van de pool daadwerkelijk bruikbaar is voor een model, hangt af van de firmware-instelling en het besturingssysteem. AMD's Variable Graphics Memory FAQ behandelt hoe die toewijzing werkt; de korte versie is dat een doos van 128GB niet alle 128GB aan de GPU geeft, en de bruikbare hoeveelheid hangt af van de VGM-instelling, gereserveerd systeemgeheugen, het besturingssysteem en de runtime. Plan op basis van bruikbaar geheugen, niet het cijfer op de sticker.
Pro-tip: als je een machine voor lokale modellen dimensioneert, lees het specificatieblad dan als twee cijfers, niet één. Capaciteit vertelt je welke modellen passen. Bandbreedte vertelt je hoe snel ze zullen draaien als ze passen. Een doos met een enorme pool en bescheiden bandbreedte is een doos die grote modellen traag draait, wat precies is wat je wilt, zolang je dat van tevoren wist.
Er is nog één geval het vermelden waard, omdat het mensen op deze machines met grote pools in verwarring brengt: Mixture-of-Experts-modellen. Een model zoals Qwen3-235B-A22B heeft in totaal 235 miljard parameters maar activeert er per token slechts ongeveer 22 miljard. Het is verleidelijk om aan te nemen dat het dus alleen geheugen nodig heeft voor het actieve deel. Voor normale in-memory inferentie is dat niet zo. Alle 235 miljard gewichten moeten nog steeds ergens resident zijn waar de runtime bij kan, omdat elk token naar elke expert kan worden gerouteerd: alleen de rekenkracht per token wordt verminderd, niet de capaciteitsvereiste. Dat onderscheid is precies waar de grote pool van unified memory zijn waarde bewijst, en het het zusterartikel over kwantisatiewiskunde gaat na wat die cijfers precies betekenen.
Veelgestelde vragen
Is unified memory hetzelfde als VRAM?
Nee. VRAM is toegewijd, snel geheugen dat in een losse videokaart is ingebouwd, gescheiden van je systeem-RAM. Unified memory is één gedeelde pool die zowel de CPU als de GPU gebruiken, en die tegelijk de taak van VRAM en systeem-RAM vervult. Unified memory is meestal groter maar trager dan het VRAM van een losse kaart, en het slaat de stap over waarbij data tussen twee pools wordt gekopieerd.
Waarom is mijn lokale model traag, ook al past het in het geheugen?
Omdat passen en snel draaien twee verschillende dingen zijn. Of een model laadt, hangt af van de geheugencapaciteit; hoe snel het tekst genereert, hangt af van de geheugenbandbreedte. Unified memory heeft volop capaciteit maar veel lagere bandbreedte dan een losse videokaart, dus een model dat comfortabel past kan nog steeds traag tokens genereren. Voor dense modellen is de ruwe relatie tokens per seconde ≈ bandbreedte ÷ modelgrootte. Voor MoE-modellen hangt de capaciteit nog steeds af van de totale opgeslagen gewichten, maar de snelheid hangt meer af van het geactiveerde pad en de runtime-implementatie.
Heb je nog steeds een GPU nodig als je unified memory hebt?
De geïntegreerde GPU maakt al deel uit van een unified-memory-chip, dat is wat het model draait. De echte vraag is of je ook een losse GPU wilt. Veel losse kaarten geven je veel hogere bandbreedte, wat sneller genereren betekent, maar minder lokaal geheugen dan een groot unified-memory-systeem, dus ze kunnen de allergrootste modellen mogelijk niet zelfstandig bevatten. Unified memory geeft je een grote pool die grote modellen bij lagere snelheid laat passen. Wat je wilt, hangt af van modelgrootte versus snelheid.
Waarom kan een mini-pc een model draaien dat een datacenter-GPU nodig heeft?
Omdat het knelpunt bij het laden van een model de geheugencapaciteit is, en een mini-pc met een grote unified pool meer bruikbaar modelgeheugen kan hebben dan veel single-GPU-opstellingen. Een consumenten-GPU heeft mogelijk 24 tot 32GB VRAM, en een enkele datacenter-GPU van H100-klasse heeft 80 tot 94GB, terwijl sommige unified-memory-systemen gedeelde pools van 128GB adverteren. Alle gewichten van het model moeten ergens passen waar de processor bij kan; de grote gedeelde pool laat ze passen, het kleine snelle VRAM niet. De mini-pc is niet krachtiger. Hij heeft gewoon ruimte.
Passen is de winst: hoeveel het nodig heeft is de volgende vraag
De bijdrage van unified memory is één duidelijk ding: een grote, gedeelde, adresseerbare pool waarmee een klein apparaat laat passen modellen laat passen die vroeger een server vereisten. Dat is de capaciteitswinst. Het bandbreedteprobleem is de prijs, en nu kun je een specificatieblad lezen en weten welk cijfer welk gedrag bepaalt.
De natuurlijke volgende vraag is degene die dit artikel steeds doorschoof: hoeveel geheugen heeft een bepaald model daadwerkelijk nodig? Dat is rekenkunde: parameters, bytes per gewicht, het compressieniveau dat je kiest, en de contextbelasting die de bestandsgrootte verbergt. het zusterartikel over GGUF-, GPTQ-, AWQ- en EXL2-kwantisatie behandelt precies die berekening, en het is de moeite waard om te doen voordat je een doos dimensioneert of een model kiest.
