Er is een moment dat bijna iedereen met een moderne USB-stick wel eens meemaakt, waarop de werkelijkheid ineens het marketingverhaal onderbreekt.

Je sluit een splinternieuwe USB-stick aan. De verpakking belooft razendsnelle prestaties. Misschien zegt de website dat hij 300MB/s kan schrijven. Misschien liet een reviewer benchmark-screenshots zien die bewijzen hoe snel hij is. Alles ziet er indrukwekkend uit.

Daarna kopieer je een grote map naar de stick.

In het begin schiet de overdracht vooruit, precies zoals beloofd. De voortgangsbalk vliegt. Windows meldt ongelooflijke schrijfsnelheden. Je begint bijna te denken dat opslagtechnologie eindelijk zover is dat kleine USB-sticks zich gedragen als mini-supercomputers.

Dan gebeurt er iets vreemds.

De snelheid stort in.

Wat begon met 300MB/s wordt ineens 80MB/s. Daarna 45MB/s. Soms zelfs nog lager. De voortgangsbalk kruipt vooruit en nu staar je naar “18 minuten resterend”, terwijl je je afvraagt wat er is gebeurd met de wonderstick die je net hebt gekocht.

In ons eerdere artikel, Waarom je elke “beste USB-stick”-lijst eigenlijk moet negeren, hadden we het erover dat de meeste USB-benchmarkartikelen zich sterk richten op korte pieksnelheden, terwijl ze het diepere gedrag van het apparaat zelf negeren. Dat artikel was het bredere argument. Dit artikel is de technische uitleg daaronder.

Want zodra je begrijpt hoe BOT en UASP werken, hoe NAND-cache zich gedraagt en hoe moderne USB-controllers langdurige schrijfacties beheren, zie je sneller waarom veel claims van “300MB/s” maar een deel van het verhaal vertellen.

Piek­snelheid en aanhoudende snelheid zijn niet hetzelfde

De meeste USB-sticks gebruiken tegenwoordig een vorm van cache om het eerste deel van een schrijfactie veel sneller te laten lijken dan de stick tijdens een lange overdracht werkelijk kan volhouden.

Moderne NAND-flashgeheugen is vaak gebaseerd op TLC- of QLC-technologie. Die geheugentypen zijn uitstekend voor capaciteit en kosten, maar ze zijn niet altijd geweldig in het continu schrijven van grote hoeveelheden data. Om die beperking te omzeilen gebruiken veel sticks een tijdelijk hogesnelheidsgebied dat vaak pseudo-SLC-cache wordt genoemd.

Denk aan die cache als de balie vooraan in een druk verzendkantoor. In het begin worden pakketten snel op de balie gezet en voelt alles vlot. Maar als de achterkamer die pakketten niet in hetzelfde tempo kan verwerken, raakt de balie uiteindelijk vol. Zodra dat gebeurt, vertraagt de hele operatie tot de snelheid van de achterkamer.

Dat is wat er in veel USB-sticks gebeurt. Het eerste deel van de overdracht gaat naar snelle cache. Zodra de cache vol raakt, moet de controller rechtstreeks naar langzamere NAND schrijven of beginnen met het wegschrijven van gecachte data naar langetermijnopslag, terwijl er nog steeds nieuwe data vanaf de computer binnenkomt.

Op dat moment verschijnt de echte aanhoudende schrijfsnelheid.

Het USB-protocol speelt ook een rol

Nu voegen we nog een laag toe, want het flashgeheugen is niet het enige dat de prestaties bepaalt.

Ook de manier waarop het USB-apparaat met de computer communiceert is belangrijk. Twee veelgebruikte transportmethoden zijn BOT en UASP. De namen klinken niet bepaald vriendelijk, maar het verschil is belangrijk.

BOT staat voor Bulk-Only Transport. Het is de oudere methode die door veel traditionele USB-sticks wordt gebruikt. BOT werkt heel rechttoe rechtaan: de computer stuurt één opdracht, wacht tot die opdracht klaar is en stuurt daarna de volgende opdracht.

Dat is eenvoudig en compatibel, maar niet bijzonder efficiënt.

UASP staat voor USB Attached SCSI Protocol. UASP is nieuwer en efficiënter omdat het command queuing en parallelle opdrachtverwerking ondersteunt. In plaats van te wachten tot één taak volledig klaar is voordat de volgende begint, houdt UASP de opslagpijplijn veel soepeler in beweging.

Als BOT een eenbaansweg met stopborden is, dan lijkt UASP meer op een meerbaansweg met betere doorstroming. Beide wegen kunnen naar dezelfde bestemming leiden, maar de ene verspilt minder tijd tussen bewegingen.

BOT kan prestaties afremmen

Met BOT besteedt het opslagapparaat meer tijd aan wachten tussen opdrachten. Die extra wachttijd maakt misschien niet veel uit voor een goedkope USB 2.0-stick die kleine bestanden verplaatst, maar wordt duidelijker zichtbaar zodra het opslagmedium sneller wordt.

Dat geldt vooral bij gemengde workloads, willekeurige bestandsoverdrachten en grotere langdurige bewerkingen waarbij de controller veel verzoeken efficiënt moet beheren. BOT kan niet bijzonder goed omgaan met dat soort verkeer, omdat het is gebouwd voor een oudere opslagwereld.

Dat betekent niet dat BOT kapot is. Het betekent simpelweg dat BOT beperkt is. Het werkt, maar het is niet de meest efficiënte manier om data door een modern USB-opslagapparaat met hoge snelheid te verplaatsen.

UASP helpt, maar lost niet alles op

UASP verbetert de communicat kant van het verhaal. Het verlaagt de latency, ondersteunt betere opdrachtverwerking en kan de overhead tussen de computer en het opslagapparaat verminderen. Dat is een van de redenen waarom veel externe USB-SSD’s veel sneller en soepeler aanvoelen dan gewone USB-sticks.

Maar UASP is geen magie.

Als de NAND in de stick traag is, als de controller zwak is, als de cache klein is of als het apparaat snel oververhit raakt, kan UASP die hardware niet veranderen in iets wat het niet is.

Een beter transportprotocol helpt data efficiënter bij de controller te komen. Het verandert niet de fysieke grenzen van het NAND-geheugen zodra de controller de data echt moet wegschrijven.

Dat is het subtiele punt dat veel snelheidsclaims missen. Een stick kan een snelle interface ondersteunen en toch slecht gedrag vertonen bij aanhoudend schrijven nadat de cache is uitgeput.

Waarom de eerste 20 seconden misleidend kunnen zijn

Een korte benchmark laat de stick vaak op zijn best mogelijke moment zien. De stick is leeg. De cache is beschikbaar. De controller is koel. Garbage collection is nog niet agressief geworden. De test gebruikt misschien grote sequentiële blokken waardoor het apparaat schoon en efficiënt lijkt.

Dat is niet hetzelfde als het kopiëren van 80GB aan videobestanden, een map vol gemengde documenten of een compleet software-image naar de stick.

Tijdens een lange overdracht gebeuren er meerdere dingen tegelijk. De cache raakt vol. De controller begint data intern opnieuw te organiseren. De schrijfsnelheid van de NAND wordt de echte limiet. Warmte kan zich opbouwen. Firmwarebeslissingen worden zichtbaarder. Als de stick is gebouwd rond lage kosten in plaats van aanhoudende prestaties, wordt de daling duidelijk.

Daarom kan een “300MB/s”-USB-stick die snelheid technisch gezien halen en zich tijdens een echte workload toch niet gedragen als een stick van 300MB/s.

Waarom dit belangrijker is dan benchmark-screenshots

Voor casual gebruik is het verschil misschien alleen irritant. Iemand kopieert vakantiefoto’s of een paar PDF’s, wacht wat langer en gaat verder.

In professionele omgevingen telt het verschil zwaarder. Als je USB-sticks dupliceert, software distribueert, media voor veldupdates voorbereidt, data registreert of grote imagebestanden verplaatst, wordt de aanhoudende schrijfsnelheid de echte maatstaf van het apparaat.

Een stick die indrukwekkend lijkt in een korte benchmark kan slecht presteren wanneer hij dezelfde schrijfactie honderden keren moet herhalen. Daar worden zwakke NAND, kleine cache, slecht controllerontwerp en thermische beperkingen onmogelijk om te verbergen.

Dit is ook waarom professionele USB-workflows meestal kijken naar het volledige gedrag van het apparaat, niet alleen naar het getal op de verpakking. Snelheid is een deel van het verhaal, maar niet het hele verhaal.

De betere vraag om te stellen

De betere vraag is niet simpelweg: “Hoe snel is deze USB-stick?”

De betere vraag is: “Hoe lang kan deze USB-stick die snelheid vasthouden?”

Die ene verandering in formulering verplaatst de discussie van marketing naar engineering. Het dwingt je na te denken over NAND-type, controllerontwerp, cachegrootte, thermisch gedrag, transportprotocol, firmwarekwaliteit en de workload die wordt getest.

Piek­snelheid laat zien wat de stick onder makkelijke omstandigheden kan doen. Aanhoudende snelheid laat zien waar de stick werkelijk van gemaakt is.

Is het je opgevallen?

De afbeelding die voor dit artikel is gebruikt, bewijst stilletjes het hele punt.

De verpakking van de USB-stick adverteert schrijfsnelheden tot 400MB/s, terwijl de daadwerkelijke aanhoudende overdracht die tijdens het kopiëren van een groot bestand wordt getoond dichter bij 125MB/s ligt. Dat verschil is niet per se fraude of valse reclame. Het is de kloof tussen piekprestaties en aanhoudend gedrag in de echte wereld.

USB-stickmarketing leunt nog steeds zwaar op eenvoudige snelheidsgetallen, omdat eenvoudige getallen makkelijk te drukken, makkelijk te vergelijken en makkelijk te verkopen zijn.

Maar echte USB-prestaties zijn gelaagder dan dat.

BOT versus UASP doet ertoe. Cachegedrag doet ertoe. NAND-kwaliteit doet ertoe. Controllerontwerp doet ertoe. Testen op aanhoudende schrijfsnelheid doet ertoe. Voor meer context hierover kun je ook ons artikel lezen over waarom sommige USB-apparaten BOT gebruiken en andere UASP.

Zodra je die lagen begrijpt, begint één claim van “300MB/s” minder op een definitief antwoord te lijken en meer op het begin van een betere vraag.

Want bij moderne USB-opslag zit het echte verschil tussen producten niet altijd in hoe snel ze tien seconden lang presteren. Het zit in hoe intelligent ze zich gedragen zodra de makkelijke omstandigheden verdwijnen.

Als je de eerdere delen in deze serie hebt gevolgd, heb je waarschijnlijk gemerkt dat er langzaam een patroon zichtbaar wordt.

In het eerste artikel bespraken we hoe NAND-flash niet verdwijnt, maar juist onderdeel wordt van een veel grotere AI-geheugenhiërarchie. Daarna keken we naar High Bandwidth Memory (HBM) en waarom moderne GPU’s afhankelijk zijn van data die fysiek dichter bij de processor staat. Vervolgens gingen we verder met Storage Class Memory, High Bandwidth Flash, de beperkingen van DRAM-schaalbaarheid en uiteindelijk waarom zelfs traditionele harde schijven nog steeds belangrijk blijven, omdat AI-infrastructuur op een schaal werkt die de meeste mensen behoorlijk onderschatten.

Op het eerste gezicht lijken dat misschien losse onderwerpen.

Dat zijn ze niet.

Ze zijn allemaal symptomen van dezelfde onderliggende druk: AI-systemen worstelen niet langer vooral met rekenkracht. Ze worstelen met hoe efficiënt ze data kunnen verplaatsen.

Die verschuiving verandert bijna alles aan de manier waarop infrastructuur wordt ontworpen.

Decennialang volgde computing een vrij stabiel model. Opslag bewaarde de data, geheugen zette die klaar en processors haalden op wat ze nodig hadden. Naarmate processors sneller werden, probeerde het systeem ze simpelweg efficiënter te voeden met betere bussen, grotere caches en snellere geheugentechnologieën.

AI heeft de schaal van het probleem veranderd.

Moderne GPU-clusters kunnen informatie met zo’n enorme snelheid verwerken dat het verplaatsen van data binnen het systeem zelf een van de grootste knelpunten in de hele architectuur is geworden. In sommige omgevingen is de processor zelf niet langer het trage onderdeel. De vertraging ontstaat doordat de juiste data niet snel en consistent genoeg bij de processor komt om die volledig bezig te houden.

Dat besef duwt de industrie stilletjes in een nieuwe richting.

In plaats van steeds grotere hoeveelheden data voortdurend heen en weer door het systeem te sturen, begint AI-infrastructuur delen van de rekenkracht dichter te plaatsen bij waar de data al staat.

En zodra je begrijpt waarom dat gebeurt, beginnen veel van de eerdere artikelen in deze serie veel duidelijker in elkaar te passen.

AI begint tegen een muur van dataverplaatsing aan te lopen

Een van de belangrijkste ideeën uit het eerdere HBM-artikel was dat moderne AI-systemen vaak niet vertragen omdat de processor te weinig rekenvermogen heeft, maar omdat het systeem de data niet snel genoeg kan aanleveren om de processor bezig te houden.

Dat probleem wordt veel serieuzer zodra AI-workloads zich uitbreiden over volledige racks en clusters.

Een moderne AI-accelerator kan verbazingwekkende hoeveelheden informatie parallel verwerken. Het probleem is dat datasets niet langer klein genoeg zijn om volledig binnen de snelste geheugenlagen te passen. Zelfs met HBM en grote hoeveelheden DRAM moeten enorme datavolumes nog steeds reizen via interconnects, bussen, fabrics, opslaglagen en netwerkinfrastructuur.

Die beweging heeft een prijs.

Dat zie je terug als latency, maar dat is slechts een deel van het verhaal. Je ziet het ook terug als stroomverbruik, warmte, koelbehoefte, congestie, synchronisatievertragingen en stilstaande rekencycli. Zoals we in het DRAM-deel bespraken, worden zelfs kleine vertragingen verrassend duur zodra duizenden GPU’s tegelijk aan het werk zijn. Een korte pauze vermenigvuldigd over een groot AI-cluster kan een enorme hoeveelheid verloren benutting betekenen.

Dat verandert de technische prioriteiten.

Jarenlang werd infrastructuur grotendeels ontworpen rond het maximaliseren van rekenprestaties. AI-systemen dwingen engineers nu om minstens zo zwaar na te denken over datalokaliteit, dus waar informatie fysiek staat ten opzichte van de processor die die informatie probeert te gebruiken.

Simpel gezegd: afstand doet er nu veel meer toe dan vroeger.

GPU’s werden zo snel dat de rest van het systeem begon achter te lopen

Een van de vreemde dingen aan AI-infrastructuur is dat vooruitgang op één gebied vaak zwakke plekken ergens anders blootlegt.

Naarmate GPU’s sneller werden, werd geheugenbandbreedte het knelpunt. Dat leidde tot HBM. Toen de capaciteitsbeperkingen van HBM duidelijker werden, begon de industrie tussenlagen zoals Storage Class Memory te introduceren. Toen DRAM-schaalbaarheid duurder en fysiek lastiger werd, begonnen systemen zwaarder op NAND te leunen, terwijl tegelijk concepten zoals High Bandwidth Flash werden onderzocht.

En terwijl AI-datasets bleven groeien richting petabytes en exabytes, bleven harde schijven stilletjes essentieel, omdat de economie van het opslaan van zoveel informatie simpelweg niet op een andere manier kon werken.

Elk artikel in deze serie wees eigenlijk vanuit een andere hoek naar dezelfde conclusie.

De oude aanname dat rekenkracht hier zit en opslag daar, begint uit elkaar te vallen. De reden is vrij eenvoudig: GPU’s kunnen data tegenwoordig sneller verwerken dan traditionele architecturen die data comfortabel kunnen aanleveren.

Dat zorgt voor een situatie waarin enorme hoeveelheden systeemactiviteit simpelweg worden besteed aan het vervoeren van informatie van de ene plek naar de andere. In praktische termen beginnen sommige AI-omgevingen minder op pure rekenproblemen te lijken en meer op logistieke problemen.

De industrie begon een andere vraag te stellen

Lange tijd richtte innovatie in opslag zich vooral op het sneller maken van opslagapparaten. Snellere SSD’s, snellere interfaces, snellere NAND en snellere controllers deden er allemaal toe, en dat doen ze vandaag nog steeds.

Maar AI-workloads begonnen een dieper probleem daaronder bloot te leggen.

Op een gegeven moment begonnen engineers te beseffen dat het probleem niet altijd de snelheid van het opslagapparaat zelf was. Het probleem was het herhaaldelijk heen en weer verplaatsen van enorme hoeveelheden data door het hele systeem.

Dat subtiele onderscheid is belangrijk, want zodra het probleem dataverplaatsing wordt in plaats van eenvoudige opslagsnelheid, begint de oplossing ook te veranderen.

In plaats van eindeloos te vragen hoe opslag sneller kan worden gemaakt, begon de industrie te vragen hoe ver de data überhaupt moet reizen.

Die vraag beïnvloedt nu bijna elk onderdeel van modern AI-infrastructuurontwerp.

Rekenkracht dichter brengen bij waar de data al staat

Hier begint de architectuur te verschuiven.

In plaats van opslag te behandelen als een volledig passieve laag die alleen maar op verzoeken wacht, beginnen nieuwere systemen bepaalde taken dichter bij de data zelf uit te voeren. Niet per se volledige GPU-verwerking, maar lokale bewerkingen die onnodige verplaatsing door de rest van het systeem verminderen.

Sommige systemen voeren nu filtering, indexering, zoekbewerkingen, compressie, voorbereiding voor ophalen en dataorganisatie dichter bij de opslaglaag uit, voordat de informatie ooit de primaire rekenmachines bereikt.

Het doel is niet om GPU’s te elimineren of snel geheugen te vervangen. Het doel is verspilling verminderen.

Als het systeem kan voorkomen dat enorme hoeveelheden onnodige data door de infrastructuur worden vervoerd, wordt het hele platform efficiënter. Dit is een van de redenen waarom de grens tussen rekenkracht en opslag begint te vervagen.

Opslag gedraagt zich niet langer als een volledig inactieve bestemming onderaan de hiërarchie. Het wordt actiever betrokken bij hoe data wordt voorbereid, klaargezet, gefilterd en stroomopwaarts wordt aangeleverd.

Als je terugdenkt aan het eerdere artikel over High Bandwidth Flash, is deze richting heel logisch. Dat artikel liet zien hoe NAND zelf richting meer geheugengedrag werd geduwd. Dit artikel trekt hetzelfde idee nog een stap verder door te laten zien hoe de omliggende architectuur zich ook aanpast rond de kosten van dataverplaatsing.

De magazijnanalogie begint er anders uit te zien

De magazijnanalogie die we in deze serie hebben gebruikt, werkt hier nog steeds, maar het magazijn zelf is gaan veranderen omdat de workload binnen dat magazijn is veranderd.

In de eerdere delen was de indeling vrij overzichtelijk. HBM stelde het laadperron voor waar de volgende pallet al klaarstond naast de werknemers. DRAM was de actieve werkvloer waar het directe sorteren en verwerken plaatsvond. Storage Class Memory werd de voorbereidingsruimte net achter het laadperron, terwijl NAND de hoofdstellingen verder achterin het magazijn vertegenwoordigde. Harde schijven verzorgden de diepere bulkopslag waar langetermijnvoorraad stond, omdat capaciteit belangrijker was dan directe toegangssnelheid.

Dat model blijft in grote lijnen overeind, maar AI-systemen beginnen inefficiënties bloot te leggen in hoeveel beweging er tussen die gebieden plaatsvindt.

Stel je een magazijn voor waar werknemers meer tijd kwijt zijn aan het heen en weer rijden met heftrucks door het gebouw dan aan het daadwerkelijk verwerken van voorraad. Eerst reageert het management door snellere heftrucks te kopen, de gangpaden breder te maken en de laadperrons te verbeteren. Die upgrades helpen een tijdje, maar uiteindelijk bereikt de operatie een punt waarop het transport zelf het probleem wordt. De vertragingen worden niet langer veroorzaakt door trage werknemers of onvoldoende apparatuur. De vertragingen komen door de enorme hoeveelheid beweging die nodig is om de workflow draaiende te houden.

Dat is steeds vaker waar grote AI-systemen tegenaan lopen.

Het probleem is niet meer alleen hoe snel data kan worden verwerkt zodra die bij de GPU aankomt. Het probleem is hoeveel infrastructuurinspanning wordt besteed aan het steeds opnieuw vervoeren van die data door het systeem.

Dus in plaats van transport eindeloos te optimaliseren, begint de indeling te veranderen. Kleine werkstations verschijnen dichter bij de stellingen zelf. Bepaalde sorteertaken gebeuren lokaal. Filtering gebeurt lokaal. Datavoorbereiding begint dichter plaats te vinden bij waar de informatie al staat, waardoor het systeem minder vaak enorme hoeveelheden materiaal heen en weer door de volledige operatie hoeft te verplaatsen.

Die verschuiving is in feite wat AI-infrastructuur op architectuurniveau begint te doen. Het doel is niet om opslag in een processor te veranderen of centrale rekenkracht volledig te elimineren. Het doel is onnodige beweging verminderen, omdat op AI-schaal zelfs kleine inefficiënties verrassend duur worden zodra ze worden vermenigvuldigd over duizenden accelerators die tegelijk draaien.

AI-infrastructuur wordt uit noodzaak meer gedistribueerd

Een van de interessantere gevolgen van deze verschuiving is dat AI-infrastructuur veel meer gedistribueerd begint te worden dan traditionele computeromgevingen ooit nodig hadden.

Oudere architecturen gingen ervan uit dat het belangrijkste werk vooral op centrale rekenlocaties zou plaatsvinden, terwijl opslag grotendeels passief bleef en gescheiden was van de verwerkingslaag. Dat model werkte decennialang redelijk goed, omdat de hoeveelheid data die door het systeem bewoog nog beheersbaar was ten opzichte van de snelheid van de processors die die data verbruikten.

AI verandert de schaal van de vergelijking volledig.

De hoeveelheid informatie die wordt verwerkt, opnieuw bekeken, klaargezet, gecachet, geïndexeerd en opgehaald is nu zo groot dat centrale verplaatsing zelf inefficiënties begint te veroorzaken. In plaats van dat rekenkracht simpelweg naar beneden reikt in opslag wanneer er iets nodig is, proberen systemen nuttige data steeds vaker dichter te positioneren bij waar die waarschijnlijk als volgende wordt gebruikt.

Dat is een deel van de reden waarom technologieën zoals vectordatabases, gedistribueerde inferentiesystemen, retrieval-lagen, lokale caching en near-data processing zoveel aandacht beginnen te krijgen. Op het eerste gezicht lijken dit misschien losse technologieën die niet-gerelateerde problemen oplossen, maar daaronder reageren ze allemaal op dezelfde druk. De industrie probeert te verminderen hoe vaak enorme hoeveelheden informatie lange afstanden door de infrastructuur moeten afleggen voordat zinvol werk kan beginnen.

Zoals je waarschijnlijk in deze serie hebt gemerkt, wordt de geheugenhiërarchie zelf geleidelijk minder rigide dan vroeger. De nette scheiding tussen “rekenkracht hier” en “opslag daar” begint zachter te worden, omdat AI-workloads systemen belonen die data fysiek dichter houden bij waar verwerking plaatsvindt.

Die trend zal waarschijnlijk doorgaan, omdat de economie van grootschalige AI steeds meer efficiëntie in verplaatsing beloont, net zo goed als ruwe rekenkracht.

De geheugenhiërarchie begint in elkaar over te lopen

Een van de stillere thema’s onder elk deel van deze serie is de geleidelijke erosie van de oude grenzen tussen geheugen, opslag en rekenkracht.

In het HBM-artikel keken we naar hoe geheugen fysiek dichter bij de processor zelf werd geplaatst, omdat zelfs traditionele DRAM-plaatsing vertragingen begon te veroorzaken die op AI-schaal groot genoeg waren om ertoe te doen. In het deel over Storage Class Memory verschoof de aandacht naar het verminderen van de scherpe overgang tussen snel geheugen en tragere persistente opslag. High Bandwidth Flash duwde NAND naar een actievere rol binnen het werkende datapad, terwijl het DRAM-artikel liet zien waarom het simpelweg eindeloos opschalen van traditioneel geheugen zowel economisch als fysiek moeilijk wordt.

Nu duwt dit artikel diezelfde ontwikkeling nog een stap verder door te laten zien hoe de architectuur zelf zich aanpast rond de kosten van dataverplaatsing.

Wat dit bijzonder interessant maakt, is dat geen van deze technologieën elkaar echt vervangt. De industrie heeft NAND niet opgegeven toen HBM arriveerde. Ze heeft DRAM niet vervangen alleen omdat Storage Class Memory verscheen. Ook harde schijven blijven diep relevant, ondanks decennia aan voorspellingen dat solid-state opslag ze volledig zou wegvagen.

In plaats daarvan wordt het systeem gelaagder, gespecialiseerder en bewuster van waar data fysiek bestaat ten opzichte van de rekenmiddelen die die data proberen te gebruiken.

Dat onderscheid is belangrijk, omdat het verandert hoe we over de toekomst van AI-infrastructuur moeten nadenken. De evolutie gebeurt niet omdat één doorbraaktechnologie plotseling alles heeft opgelost. De evolutie gebeurt omdat de workload zelf de industrie dwong om opnieuw te organiseren hoe elke laag meedoet aan het efficiënt voeden van informatie richting de rekenkant.

Als je een stap terug doet en naar het grotere geheel kijkt, wordt het patroon veel makkelijker te zien. Elke grote verschuiving die we in deze serie hebben besproken, wijst uiteindelijk naar hetzelfde doel: minder tijd, energie en infrastructuuroverhead besteden aan het simpelweg verplaatsen van informatie van de ene plek naar de andere.

De toekomst kan meer afhangen van dataplacement dan van ruwe rekenkracht

Heel lang mat de technologie-industrie vooruitgang vooral aan de hand van ruwe rekenkracht. Snellere processors, grotere accelerators, meer cores en meer parallelisme werden gezien als de belangrijkste signalen van vooruitgang, omdat betere rekenprestaties bij de meeste traditionele workloads meestal het hele systeem verbeterden.

AI dwingt een genuanceerder gesprek af.

Zodra processors snel genoeg worden, verschuift de grotere uitdaging van het kunnen uitvoeren van bewerkingen naar het consequent genoeg voeden van die processors met nuttige data om dure stilstand te voorkomen. Die subtiele verandering beïnvloedt nu bijna elke grote architectuurbeslissing binnen moderne AI-infrastructuur.

Het interessante is dat de oplossing niet langer simpelweg bestaat uit snellere opslagapparaten bouwen of grotere geheugenpools los van elkaar maken. In plaats daarvan richt de industrie zich steeds meer op waar data zich in het systeem bevindt, hoe vaak die beweegt en hoe slim de architectuur onnodig transport kan beperken voordat rekenmiddelen überhaupt betrokken raken.

Daarom is nabijheid zo’n terugkerend thema geworden in elk artikel van deze serie. HBM bracht geheugen fysiek dichter bij de GPU. Storage Class Memory verkleinde de kloof tussen geheugen en opslag. High Bandwidth Flash probeerde NAND actiever te laten deelnemen aan de geheugenhiërarchie. Gedistribueerde opslagsystemen en near-data-processing-architecturen proberen nu te verminderen hoeveel beweging er binnen de infrastructuur zelf plaatsvindt.

Al deze ontwikkelingen reageren op hetzelfde inzicht.

Op AI-schaal wordt data efficiënt verplaatsen bijna net zo belangrijk als de data verwerken zodra die aankomt.

En dat kan uiteindelijk een van de bepalende architectuurverschuivingen van het hele AI-tijdperk worden.

---

Serie over AI-geheugeninfrastructuur

Dit artikel maakt deel uit van onze lopende serie over hoe AI-infrastructuur de relatie tussen geheugen, opslag en rekenkracht opnieuw vormgeeft. Als je hier in de discussie instapt, bieden de eerdere delen de basis om te begrijpen waarom deze verschuiving plaatsvindt.

Deel één:
NAND verdwijnt niet, maar AI-servers zijn tegenwoordig afhankelijk van meer dan alleen flash

Deel twee:
Wat is High Bandwidth Memory (HBM) en waarom AI ervan afhankelijk is?

Deel drie:
Storage Class Memory uitgelegd: de ontbrekende laag tussen DRAM en NAND

Deel vier:
High Bandwidth Flash: kan NAND zich eindelijk als geheugen gedragen?

Deel vijf:
Waarom DRAM alleen niet langer kan meekomen met AI

Deel zes:
Waarom harde schijven nog steeds belangrijk zijn voor AI-infrastructuur

Deel zeven:
Waarom AI rekenkracht dichter bij opslag brengt

Wanneer de meeste mensen over AI-infrastructuur horen, gaat het gesprek meestal over GPU’s, High Bandwidth Memory (HBM) of ultrasnelle solid-state opslag. De aanname is dat kunstmatige intelligentie volledig draait op hypermoderne hardware, waar alles wordt gemeten in nanoseconden en terabytes per seconde.

Die aanname is niet verkeerd, maar wel onvolledig.

De werkelijkheid is dat moderne AI-systemen nog steeds sterk afhankelijk zijn van een van de oudste technologieën in het datacenter: de mechanische harde schijf.

Dat klinkt misschien vreemd, zeker omdat we eerder al hebben besproken hoe AI-servers zich verplaatsen voorbij traditioneel flashgeheugen in ons artikel: NAND verdwijnt niet, maar AI-servers zijn tegenwoordig afhankelijk van meer dan alleen flash. We hebben ook bekeken waarom technologieën zoals High Bandwidth Memory (HBM) essentieel worden om AI-systemen snel genoeg van data te voorzien en zo GPU-knelpunten te voorkomen.

Maar er is nog een andere kant van dit verhaal die veel minder aandacht krijgt: pure schaal.

AI heeft niet alleen snelle opslag nodig. AI heeft een bijna onvoorstelbare hoeveelheid opslag nodig.

En harde schijven zijn nog steeds de enige technologie die die capaciteit kan leveren tegen een prijs die de industrie realistisch kan dragen.

De opslaghiërarchie van AI begrijpen

De eenvoudigste manier om moderne AI-infrastructuur te begrijpen, is door niet langer aan één enkele computer te denken, maar aan een volledige logistieke operatie.

HBM werkt als het laadperron waar data met ongelooflijke snelheid wordt verplaatst. DRAM functioneert als de actieve werkruimte waar informatie voortdurend wordt bewerkt. NAND-flash gedraagt zich meer als nabijgelegen stellingen, waar snelle toegang nog steeds belangrijk is, maar langdurige opslag ook begint mee te tellen.

Harde schijven zijn echter het magazijn.

Niet het meest opvallende deel van de operatie. Ook niet het snelste deel. Maar absoluut het grootste.

Technologie	Typische capaciteit	Belangrijkste kracht	Belangrijkste AI-rol
HBM	80GB–192GB	Extreme bandbreedte	Actieve GPU-berekening
DRAM	Honderden GB’s	Lage latency	Werkgeheugen
NAND SSD	Meerdere TB’s	Snelle persistente opslag	Dataset-staging en caching
Harde schijven	Petabytes tot exabytes	Capaciteitsefficiëntie	Bulkopslag en archieven

Dat onderscheid is belangrijk, omdat AI-trainingssystemen data verbruiken op een schaal die de meeste mensen bij normaal computergebruik nooit tegenkomen.

Een consumentenlaptop kan misschien een paar terabytes aan data opslaan. Zelfs een high-end workstation komt vaak niet verder dan tientallen terabytes. AI-infrastructuur werkt meerdere ordes van grootte daarboven.

Waar een consumentenlaptop in terabytes denkt, denken AI-clusters in exabytes.

Eén enkele exabyte is gelijk aan één miljoen terabytes.

Als een moderne enterprise harde schijf 30TB opslaat, zijn er nog steeds meer dan 33.000 harde schijven nodig om één enkele exabyte aan ruwe opslagcapaciteit te bouwen.

Grote AI-operators bouwen niet één exabyte. Ze bouwen meerdere exabytes, verspreid over regio’s, redundantielagen, trainingsomgevingen, back-upsystemen en archiefopslag.

Het exabyteprobleem

Het trainen van een groot taalmodel kan petabytes aan tekst, afbeeldingen, video, telemetrie, checkpoints en opgeslagen trainingsstatussen omvatten. Zodra die datasets zijn verzameld, worden ze zelden verwijderd. Ze blijven groeien naarmate modellen opnieuw worden getraind, verfijnd en uitgebreid.

Tijdens AI-training maken systemen voortdurend checkpoints aan, in feite enorme opslagmomenten van het model terwijl het leert. Als een cluster halverwege een trainingscyclus van meerdere weken uitvalt, kunnen die checkpoints het enige zijn dat voorkomt dat miljoenen dollars aan rekentijd verloren gaan.

Dat betekent dat opslaginfrastructuur niet langer alleen om snelheid draait, maar ook om het in stand houden van gigantische pools met toegankelijke data.

Hier blijven harde schijven stilletjes dominant.

In 2010 voelde een harde schijf van 2TB enorm. Enterprise-omgevingen gebruikten vaak SAS-schijven van 300GB of 600GB, en alles boven een paar terabytes werd gezien als premiumcapaciteit.

Vandaag worden enterprise harde schijven van 24TB en 30TB standaard ingezet in grote datacenters. Fabrikanten testen al schijven van meer dan 40TB met technologieën zoals HAMR (Heat-Assisted Magnetic Recording), waarmee de oppervlaktedichtheid wordt verhoogd zonder de fysieke afmetingen van de schijf zelf te vergroten.

Om die groei in perspectief te plaatsen: één modern opslagrack kan tegenwoordig meer data bevatten dan een compleet middelgroot enterprise-datacenter uit 2010.

Zo drastisch is de vraag naar opslag veranderd.

En AI is een van de belangrijkste redenen daarvoor.

AI draait op meer dan snelheid alleen

De publieke discussie rond AI richt zich meestal op GPU’s, omdat GPU’s het zichtbare werk doen. Ze genereren de antwoorden, maken de afbeeldingen en verwerken de tokens.

Opslag doet het onzichtbare werk: het bewaren van de intelligentiepijplijn zelf.

GPU’s zijn alleen nuttig als ze continu toegang hebben tot enorme hoeveelheden trainingsdata.

Die data moet ergens staan.

Niet in HBM. Niet in DRAM. En zeker niet volledig in dure NAND-opslaglagen.

Die data leeft voornamelijk op enorme infrastructuur met harde schijven.

Een modern AI-datacenter kan honderden petabytes aan opgeslagen data bevatten. Sommige hyperscale-omgevingen gaan waarschijnlijk nog veel verder richting architecturen op exabyteschaal. Alles volledig op NAND-flash opslaan zou financieel onrealistisch zijn, zelfs voor de grootste cloudproviders.

Dit is het deel dat veel mensen missen wanneer ze over AI-hardware praten.

Prestaties zijn belangrijk, maar economie is dat ook.

De industrie verkoopt graag IOPS en benchmarkcijfers, maar grote AI-implementaties worden uiteindelijk beperkt door de totale eigendomskosten.

Harde schijven blijven de laagste kosten per terabyte bieden bij grootschalige implementaties. Ze blijven ook bijzonder efficiënt voor het opslaan van koude data, gearchiveerde datasets, back-up-snapshots, modelcheckpoints en grote hoeveelheden trainingsinformatie die geen toegangstijden op nanosecondeniveau nodig hebben.

Waarom harde schijven nog steeds werken voor AI

Er is ook nog een ander misverstand dat de moeite waard is om recht te zetten: mensen gaan er vaak van uit dat harde schijven onbruikbaar traag zijn voor AI-omgevingen.

Dat is niet helemaal waar.

Eén enkele harde schijf is traag vergeleken met DRAM of NAND-flash, ja. Maar AI-datacenters werken niet met losse schijven. Ze werken met enorme storage-arrays met parallelle toegang over duizenden schijven tegelijk.

Belangrijker nog: veel AI-workloads bestaan uit sequentiële streaming van grote datasets, in plaats van kleine willekeurige transacties. Sequentiële workloads zijn juist een van de gebieden waarin moderne enterprise-arrays met harde schijven nog verrassend goed presteren.

Met andere woorden: AI-infrastructuur vraagt niet altijd: “Wat is de snelst mogelijke opslag?”

Soms vraagt het:

Wat is de snelste praktische manier om 500 petabytes op te slaan zonder het bedrijf failliet te maken?

Dat is een heel ander technisch probleem.

AI-infrastructuur wordt een gelaagd geheugenecosysteem

Dit verklaart ook waarom nieuwere technologieën in lagen aan AI-systemen worden toegevoegd, in plaats van oudere technologieën volledig te vervangen.

In ons artikel over Storage Class Memory: de ontbrekende laag tussen DRAM en NAND hebben we bekeken hoe de industrie steeds opnieuw tussenlagen creëert om snelheid, persistentie en economie in balans te brengen.

We hebben ook onderzocht hoe NAND probeert dichter bij geheugenniveauprestaties te komen in: High Bandwidth Flash: kan NAND zich eindelijk als geheugen gedragen?.

AI-infrastructuur wordt precies dat: een gelaagd geheugenecosysteem.

HBM verwerkt de directe berekeningen. DRAM beheert actieve workloads. NAND-flash vangt snelle persistente opslagtaken op. Storage-class technologieën proberen latencygaten te overbruggen. Harde schijven leveren de enorme capaciteitsbasis onder alles.

De toekomst van AI-opslag is niet dat één technologie een andere vervangt.

Het is een stapeling van meerdere technologieën, omdat geen enkel geheugentype elk probleem goed oplost.

Dat is waarschijnlijk het grootste misverstand rond AI-infrastructuur vandaag. Mensen nemen aan dat de nieuwste technologie automatisch de oudere doodmaakt.

Maar zo werkt de geschiedenis van computing zelden.

Harde schijven overleefden SSD’s omdat de wereld sneller meer data bleef produceren dan flashprijzen konden dalen. Nu versnelt AI die trend nog verder. De hoeveelheid informatie die wordt gegenereerd, bewaard, gekopieerd en opnieuw getraind explodeert zo snel dat capaciteit zelf een strategische hulpbron is geworden.

Ironisch genoeg geldt: hoe geavanceerder AI wordt, hoe belangrijker grootschalige opslaginfrastructuur daarnaast wordt.

Dat betekent dat een van de oudste technologieën in het datacenter mogelijk veel langer een cruciale rol blijft spelen in AI dan de meeste mensen hadden verwacht.

---

Waarom het kopiëren van duizenden kleine bestanden trager kan aanvoelen dan het verplaatsen van één groot filmbestand

De meeste mensen gaan ervan uit dat data kopiëren een vrij eenvoudig proces is. Je sleept bestanden van het ene venster naar het andere, kijkt hoe de voortgangsbalk langzaam over het scherm schuift, en uiteindelijk verschijnen de bestanden op het doelapparaat. Van buitenaf lijkt duplicatiehardware precies hetzelfde te doen — alleen sneller en met meer USB-poorten.

Maar intern gedragen die twee methoden zich heel verschillend.

Dat verschil wordt vooral duidelijk bij ingewikkelde mappenstructuren, softwaredistributies, technische archieven, fotocatalogi, websiteback-ups of alles wat duizenden en duizenden kleine bestanden bevat.

Dit is ook de reden waarom mensen vaak in de war raken door opslagprestaties. Een USB-stick kan snelheden van 200MB per seconde beloven. Je kopieert een groot videobestand van 20GB en de overdracht voelt ongelooflijk snel. Later verplaats je een softwareproject van 2GB met 80.000 kleine bestanden en ineens voelt de computer pijnlijk traag aan.

Dezelfde USB-stick. Dezelfde USB-poort. Minder totale data.

Wat is er dan veranderd?

Het antwoord is overhead.

Een bestandskopie is eigenlijk een lang gesprek

Wanneer de meeste mensen denken aan bestanden kopiëren, stellen ze zich voor dat de computer simpelweg data van de ene plek naar de andere verplaatst. In werkelijkheid vraagt een kopieerproces via slepen en neerzetten om veel communicatie tussen het besturingssysteem en het opslagapparaat.

Het besturingssysteem moet elk bestand afzonderlijk bekijken. Het controleert bestandsnamen, maakt mappen aan, schrijft tijdstempels, werkt allocatietabellen bij, verwerkt metadata, controleert beschikbare ruimte, opent schrijfsessies, sluit schrijfsessies en bevestigt dat elke transactie correct is afgerond.

Bij één groot bestand is die overhead relatief klein.

Bij 100.000 kleine bestanden wordt die overhead enorm.

Op een bepaald moment besteedt het systeem meer tijd aan het beheren van het kopieerproces dan aan het daadwerkelijk verplaatsen van nuttige data.

Dat is het deel dat de meeste gebruikers nooit zien.

Het paperclipprobleem

De eenvoudigste manier om dit te visualiseren is met paperclips.

Stel je voor dat je 50 pond materiaal van de ene kamer naar de andere moet verplaatsen.

Eén optie is een afgesloten doos vol paperclips dragen.

De andere optie is elke afzonderlijke paperclip met de hand één voor één verplaatsen.

Technisch gezien is het totale gewicht identiek.

Maar één methode is absurd inefficiënt, omdat de handling-overhead de hele taak gaat domineren.

Kleine bestanden veroorzaken precies hetzelfde probleem binnen een opslagsysteem. Elk piepklein bestand wordt een eigen kleine transactie. Het besturingssysteem stopt steeds opnieuw om elk afzonderlijk stukje te organiseren, catalogiseren, valideren en beheren, in plaats van één lange, ononderbroken datastroom vast te houden.

Daarom kan één videobestand van 20GB soms sneller worden overgezet dan een map van 2GB met duizenden kleine afbeeldingen, scripts, pictogrammen, cachebestanden, installers, HTML-assets en configuratiedocumenten.

Het probleem is dus niet altijd de hoeveelheid data.

Het probleem is de hoeveelheid handling.

Waarom binaire duplicatie anders werkt

Binaire duplicatie bekijkt het proces vanuit een compleet ander perspectief.

In plaats van zich te richten op bestanden en mappen, kijkt een binair duplicatieproces vaak naar de ruwe structuur van het opslagapparaat zelf. In plaats van te vragen: “Welke bestanden staan er in deze map?”, vraagt het systeem: “Welke data staat er in deze sectoren?”

Dat klinkt als een klein verschil, maar het verandert de workflow fundamenteel.

Een traditionele bestandskopie zet alleen zichtbare bestanden en mappen over via het besturingssysteem. Normaal gesproken worden low-level opslaggegevens zoals bootsectoren, partitietabellen, verborgen bestandssysteemstructuren of informatie over de apparaatindeling niet mee gekopieerd.

Daarom maakt simpelweg bestanden naar een USB-stick slepen meestal geen echte opstartbare kloon van een ander apparaat. De bestanden kunnen aanwezig zijn, maar de bootcode en de onderliggende opslagstructuur ontbreken vaak.

Een binaire kopie of IMG-uitrol werkt anders, omdat die de opslagstructuur zelf reproduceert. Afhankelijk van de duplicatiemethode kan het proces partitietabellen, bootsectoren, bestandssysteemstructuren, verborgen gebieden en de exacte indeling van het oorspronkelijke medium kopiëren.

In plaats van de omgeving bestand voor bestand opnieuw op te bouwen, reproduceert het duplicatieproces het apparaat veel directer.

Daardoor wordt de hoeveelheid administratief werk die het besturingssysteem tijdens de overdracht moet doen sterk verminderd.

Waarom IMG-bestanden en apparaatkopieën vaak sneller aanvoelen

Dit is één van de redenen waarom IMG-uitrollen en kopieën op apparaatniveau vaak verrassend snel en consistent aanvoelen.

Het systeem pauzeert niet voortdurend om duizenden kleine bestandssysteembewerkingen af te handelen. In plaats daarvan verplaatst het grote, georganiseerde blokken binaire data in een meer sequentieel proces.

Sequentiële bewerkingen zijn voor opslagapparaten meestal veel efficiënter dan sterk gefragmenteerde willekeurige schrijfactiviteit.

Dat wordt vooral merkbaar bij softwaredistributies, opstartbare omgevingen, Linux-uitrollen, embedded systemen, kioskplatforms en productieflows waarin onder de oppervlakte enorme aantallen kleine ondersteunende bestanden bestaan.

Een normale kopie via slepen en neerzetten dwingt het besturingssysteem om elk van die onderdelen afzonderlijk te verwerken. Een binair duplicatieproces omzeilt een groot deel van die overhead.

Het resultaat voelt soepeler, voorspelbaarder en vaak duidelijk sneller.

We hebben vergelijkbaar low-level USB-gedrag behandeld in ons artikel over hoe USB-kopieerbeveiliging werkt, waar controller-level bewerkingen zich heel anders gedragen dan normale bestandsgebaseerde workflows.

Waarom USB-snelheidsclaims misleidend kunnen aanvoelen

Consumenten leren meestal om opslagprestaties te zien als één eenvoudig getal.

Maar prestaties in de praktijk hangen sterk af van het type workload.

Grote sequentiële bestanden zijn eenvoudig voor opslagsystemen, omdat het apparaat één lang, ononderbroken schrijfproces kan aanhouden. Kleine gefragmenteerde bestanden zorgen juist voor constante stop-en-go-activiteit.

De drive sprint dan niet meer over een lege snelweg.

Hij rijdt door stadsverkeer met om de twintig meter een stopbord.

Dat verschil is enorm.

Het verklaart ook waarom duplicatiehardware en imaging-systemen zich vaak anders gedragen dan een normale kopieeractie op de desktop. De onderliggende methode om data te verplaatsen is simpelweg niet hetzelfde.

Dit wordt nog belangrijker in productieflows met opstartbare USB-media, waar low-level opslagstructuren net zo belangrijk zijn als de zichtbare bestanden zelf.

Het grotere plaatje

Geen van beide methoden is automatisch “beter”, omdat de twee benaderingen verschillende problemen oplossen.

Een traditionele bestandskopie is flexibel. Je kunt afzonderlijke bestanden bijwerken, mappen selectief vervangen en op een natuurlijke manier binnen het besturingssysteem werken.

Binaire duplicatie is meer gericht op exacte reproductie en workflow-efficiëntie. Die aanpak is vooral sterk wanneer consistentie belangrijk is en grote hoeveelheden gestructureerde data betrouwbaar naar veel apparaten moeten worden gerepliceerd.

De meeste mensen denken nooit over dit verschil na, omdat moderne besturingssystemen alle complexiteit verbergen achter een eenvoudige voortgangsbalk.

Maar onder dat kleine groene balkje zit een enorm verschil in hoe het opslagsysteem werkelijk aan het werk is.

En zodra je de overhead begrijpt, wordt het ineens volkomen logisch waarom het verplaatsen van één groot filmbestand moeiteloos kan voelen, terwijl het kopiëren van een kleine softwaremap vol duizenden bestanden zelfs een dure computer op de knieën kan krijgen.

Op het eerste gezicht lijken een NAND-geheugenchip en een vat ruwe olie totaal niets met elkaar te maken te hebben.

Het ene hoort bij een wereld van siliciumwafers, cleanrooms, microscopische lasers en geavanceerde chemie. Het andere komt uit boorinstallaties, pijpleidingen, tankers en raffinaderijen.

Maar wanneer olieprijzen stijgen, voelt de NAND-industrie dat verrassend snel.

Het verwarrende deel is dit: NAND-chips zelf bevatten bijna geen olie.

Dat klinkt tegenstrijdig, totdat je begrijpt hoe moderne productie van halfgeleiders eigenlijk werkt. De chip mag dan piepklein zijn, maar de industriële wereld die nodig is om hem te maken is enorm.

NAND begint met zand, niet met aardolie

NAND-geheugen wordt opgebouwd uit silicium, dat uiteindelijk afkomstig is van sterk geraffineerd kwarts en zand.

Het productieproces is lastig voor te stellen, omdat het plaatsvindt op schalen die te klein zijn voor het menselijk oog om natuurlijk te begrijpen. Een van de eenvoudigste manieren om eraan te denken is microscopisch spuitverven.

In een halfgeleiderfabriek ligt een dunne siliciumwafer in een vacuümkamer terwijl speciale gassen worden ingebracht onder zorgvuldig gecontroleerde hitte- en plasmaomstandigheden. Die gassen reageren en laten atoomdunne lagen materiaal achter op het oppervlak van de wafer.

Stel je voor dat je een oppervlak één microscopisch laagje tegelijk spuitverft, alleen moet de verf met bijna perfecte precisie over een hele wafer terechtkomen. En stel je daarna voor dat je dat proces honderden keren herhaalt.

Moderne 3D NAND is in feite een verticale wolkenkrabber van geheugencellen, laag op laag gestapeld. Daar komen termen uit de industrie zoals “200-layer NAND” of “300-layer NAND” vandaan.

Waarom doet olie er dan toe?

Olie wordt niet rechtstreeks de geheugenchip.

In plaats daarvan voedt olie het enorme industriële ecosysteem dat ervoor zorgt dat de chip überhaupt kan bestaan.

Een moderne halfgeleiderfabriek lijkt minder op een traditionele elektronicafabriek en meer op een ruimtestation op aarde. De omgeving binnenin moet elke seconde van elke dag buitengewoon goed onder controle blijven.

De lucht in een fab wordt voortdurend gefilterd en gerecirculeerd, omdat zelfs microscopische stofdeeltjes de productie kunnen verpesten. Temperaturen worden strak gecontroleerd, omdat kleine schommelingen invloed kunnen hebben op de opbrengst. Enorme vacuümsystemen verplaatsen non-stop gassen door proceskamers. Waterzuiveringssystemen produceren ultrapuur water, schoner dan wat de meeste mensen zich als drinkwater kunnen voorstellen.

Hoewel de uiteindelijke geheugenchip bijna niets weegt, strekt de infrastructuur die nodig is om hem te maken zich uit over gigantische gebouwen, industriële gasinstallaties, elektriciteitsnetten, chemische leveranciers, transportvloten en wereldwijde logistieke systemen.

Daar komt olie in beeld.

Olie beïnvloedt transportkosten, industriële chemicaliën, kunststoffen, epoxyharsen, vrachtprijzen, elektriciteitsopwekking en talloze ondersteunende systemen rond de productie van halfgeleiders. Zelfs de zwarte beschermende behuizing rond veel NAND-packages is in de ene of andere vorm terug te voeren op petrochemische materialen.

De onzichtbare infrastructuur achter een piepkleine chip

De meeste mensen kijken naar een USB-stick of SSD en zien een klein elektronisch product.

Wat ze niet zien, is de onzichtbare infrastructuur erachter. Artikelen die laten zien hoe flashgeheugen werkt verrassen mensen vaak, omdat de productieomgeving meer op een wetenschappelijk laboratorium lijkt dan op een traditionele elektronicamontagelijn.

Ze zien de cleanrooms niet die elke minuut enorme hoeveelheden lucht verplaatsen en filteren. Ze zien de chemische raffinagesystemen niet die ultrazuivere speciale gassen produceren. Ze zien de constante energievraag niet die nodig is om deze fabrieken dag en nacht stabiel te houden.

En ze zien al helemaal niet het wereldwijde transportnetwerk dat grondstoffen, wafers, controllers, substraten, afgewerkte chips en verpakte producten tussen landen verplaatst voordat het uiteindelijke apparaat ooit een winkelschap bereikt.

De fysieke hoeveelheid olie die aan één NAND-chip is gekoppeld, is eigenlijk heel klein. Eén gallon olie “maakt” niet één geheugenchip.

In werkelijkheid kan diezelfde gallon indirect transportsystemen, chemische verwerking, elektriciteitsopwekking, kunststofproductie en industriële activiteiten ondersteunen die samen helpen om duizenden NAND-apparaten te produceren.

Dat is wat halfgeleiders zo fascinerend maakt. De waarde zit niet in de grondstof zelf. De waarde komt uit de verbijsterende precisie, techniek, chemie en infrastructuur die nodig zijn om betrouwbaar geheugen op microscopische schaal te maken.

Waarom NAND-prijzen zo snel kunnen reageren

NAND gedraagt zich ook anders dan veel andere technologische producten.

Een premium smartphone of camera kan maandenlang vrij stabiel geprijsd blijven. NAND-geheugen werkt niet altijd zo. Geheugenprijzen kunnen snel bewegen, omdat de markt zich meer gedraagt als een grondstoffenmarkt dan als een markt voor luxe-elektronica.

Wanneer olieprijzen scherp stijgen, wordt verzending duurder. Chemische kosten stijgen. De bedrijfskosten van fabrieken nemen toe. Vrachtkosten lopen vrijwel direct op, vooral bij luchtvracht.

Zelfs onzekerheid alleen kan al marktdruk veroorzaken, omdat leveranciers en distributeurs voorzichtiger worden met voorraad en toekomstige kosten.

De relatie tussen olie en NAND is indirect, maar absoluut echt.

De grotere werkelijkheid

Jarenlang werden halfgeleiders vooral besproken als een puur technologisch verhaal. Kleinere transistors. Snellere chips. Meer opslagcapaciteit.

Maar moderne halfgeleiderproductie is ook een energieverhaal, een chemieverhaal en een logistiek verhaal.

NAND-geheugen wordt gemaakt van silicium, maar het draait op een wereldwijd industrieel systeem dat wordt aangedreven door elektriciteit, transport, raffinage en geavanceerde productie-infrastructuur.

Olie wordt geen NAND.

Olie voedt de wereld die NAND mogelijk maakt.

EEAT-opmerking: Dit artikel is gemaakt met AI-ondersteunde structuur en redactie, met uiteindelijke richting, technische controle en onderwerpontwikkeling door de auteur. Het doel is om complexe relaties tussen halfgeleiders en industriële infrastructuur op een praktische, lezersvriendelijke manier uit te leggen.

Zodra je echt gaat kijken naar hoe AI-systemen in elkaar zitten, kom je al snel uit bij een heel natuurlijke conclusie, en eerlijk gezegd klinkt die in eerste instantie volkomen logisch.

Als NAND voor bepaalde delen van de workload te traag is, en zelfs geavanceerde flash-architecturen nog altijd genoeg vertraging introduceren om merkbaar te zijn, dan lijkt het voor de hand liggende antwoord te zijn om gewoon meer DRAM toe te voegen. DRAM is tenslotte altijd de snelle laag geweest. Het is de plek waar actieve data leeft, het reageert snel, en al tientallen jaren is het het deel van het systeem waarop je leunt als je niet wilt dat de processor werkloos zit te wachten tot iets arriveert.

Dus de aanname is snel gemaakt: als snelheid het probleem is, vergroot dan gewoon het snelste wat je hebt.

Die logica houdt verrassend goed stand – totdat AI in beeld komt en DRAM in een rol duwt waarvoor het eigenlijk nooit echt ontworpen is. Het probleem is niet dat DRAM ineens traag is geworden, of verouderd, of op de een of andere manier minder nuttig dan vroeger. Het probleem is dat AI-workloads er veel meer van vragen dan alleen optreden als een snelle werklaag tussen compute en storage.

Voor het bredere kader achter deze verschuiving sluit dit artikel direct aan op het hoofdartikel van deze reeks: NAND verdwijnt niet, maar AI-servers zijn tegenwoordig afhankelijk van meer dan alleen flash.

DRAM is gebouwd voor snelheid, niet om het hele systeem te dragen

Het eerste dat je moet begrijpen, is dat DRAM altijd is geoptimaliseerd voor snelheid en reactievermogen, niet voor het vasthouden van enorme hoeveelheden data op grote schaal. In traditionele computing was dat onderscheid zelden een probleem, omdat de meeste workloads een vrij duidelijke scheiding hadden tussen actieve data en opgeslagen data. Het systeem hield wat het direct nodig had in geheugen, haalde de rest uit storage wanneer dat nodig was, en die overdracht werkte meestal goed genoeg dat bijna niemand er verder over nadacht.

AI verandert die balans behoorlijk drastisch. In plaats van met bescheiden stukken actieve data te werken en dan verder te gaan, hergebruiken AI-modellen grote datasets steeds opnieuw, verplaatsen ze informatie parallel en houden ze een veel groter deel van de working set binnen bereik van de compute-laag, en dat ook nog eens veel langer. Dat betekent dat DRAM niet langer alleen wordt gevraagd om de huidige taak vast te houden. Het wordt gevraagd om mee te helpen een enorme en voortdurend verschuivende massa data dichtbij te houden, omdat het systeem die vrijwel altijd in de buurt wil hebben.

Dat is een heel andere taak.

Dat is ook precies waarom technologieën boven en rond DRAM belangrijker zijn geworden. In het eerdere artikel over wat High Bandwidth Memory is en waarom AI ervan afhankelijk is, lag de focus op het extreem dicht bij de processor brengen van een kleinere hoeveelheid kritieke data, zodat de GPU gevoed blijft. Dat artikel maakt duidelijk dat nabijheid ertoe doet, maar onthult tegelijk stilletjes het volgende probleem, want zodra de working set groter wordt dan die directe laag, moet het systeem nog steeds bepalen waar al het andere moet leven.

De eerste muur is de kostprijs, en die duikt snel op

Een van de redenen waarom mensen het idee van “voeg gewoon meer DRAM toe” aantrekkelijk vinden, is dat het schoon en direct klinkt. In de praktijk wordt het echter heel snel duur. DRAM is simpelweg niet geprijsd zoals NAND, en zodra je systemen opschaalt naar AI-niveau, heb je het niet meer over een beetje extra geheugen in een server. Dan heb je het over honderden gigabytes, soms veel meer, verspreid over meerdere nodes, racks en clusters.

Vanaf dat punt voelt DRAM niet langer als een prestatie-upgrade, maar eerder als een infrastructurele last. De kostencurve loopt niet rustig op. Die stijgt snel genoeg dat het idee om DRAM te gebruiken om elk probleem rond datalokaliteit op te lossen, onder zijn eigen economische gewicht begint uiteen te vallen.

Dat is een van de redenen waarom de geheugenstack dieper wordt in plaats van eenvoudiger. De industrie beweegt niet weg van DRAM omdat het niet meer waardevol is. Ze beweegt weg van de aanname dat DRAM alleen het antwoord kan zijn op elk latencygevoelig probleem op AI-schaal.

De tweede muur is energie, en dat probleem slaapt nooit

Zelfs als de kosten makkelijker te rechtvaardigen zouden zijn, loopt DRAM nog tegen een ander probleem aan dat onmogelijk te negeren wordt zodra systemen groot genoeg worden, en dat is energieverbruik. DRAM moet constant van stroom worden voorzien om zijn toestand vast te houden. Dat hoort nu eenmaal bij de technologie. Dus hoe meer je toevoegt, hoe meer energie het systeem verbruikt alleen al om die data daar klaar te laten staan.

In kleinere omgevingen voelt die overhead misschien acceptabel. In dichte AI-systemen die continu draaien, begint het een serieus operationeel probleem te worden. Meer DRAM betekent meer stroomverbruik, meer warmte, meer koeling en meer ontwerpdruk op het hele platform. Opeens gaat de beslissing niet meer alleen over geheugencapaciteit. Dan gaat het over thermische grenzen, efficiëntie van het datacenter en de vraag of de ondersteunende infrastructuur de kosten kan dragen van zoveel actief geheugen dat dag en nacht in leven moet worden gehouden.

Dat is ook waar de rol van tussenlagen logischer begint te worden. In het vorige deel over storage class memory, de ontbrekende laag tussen DRAM en NAND, was het idee niet om DRAM te vervangen, maar om een deel van de druk ervan af te halen door een laag toe te voegen die meer data dichter bij compute houdt zonder alles in de duurste en meest energiehongerige tier te duwen.

Dan is er nog de fysieke realiteit van nabijheid

Er is nog een andere reden waarom DRAM niet oneindig goed schaalt in AI-systemen, en die heeft minder met budget te maken en meer met natuurkunde. DRAM levert zijn waarde deels doordat het relatief dicht bij de processor zit. Hoe dichter geheugen bij compute zit, hoe lager de latency meestal is en hoe responsiever het hele systeem aanvoelt. Maar nabijheid is niet iets dat je zonder gevolgen eindeloos kunt uitbreiden.

Er zijn fysieke limieten aan hoeveel geheugen je in de buurt van een CPU of GPU kunt plaatsen voordat layout-complexiteit, trace-lengte, signaalintegriteit en packagingbeperkingen tegen je beginnen te werken. Dat is precies waarom geavanceerde geheugenverpakking in de eerste plaats is ontstaan. HBM bestaat omdat traditionele plaatsing van DRAM maar tot een bepaald punt werkt, en zodra de compute-kant snel genoeg wordt, gaan die afstanden en verbindingstrajecten zwaarder meetellen dan vroeger.

Maar HBM is ook geen volledig antwoord op het capaciteitsvraagstuk. Het biedt ongelooflijke bandbreedte, maar geen onbeperkt volume. Daardoor leeft het systeem uiteindelijk in een voortdurende balans tussen wat heel dichtbij geplaatst kan worden en wat verder weg moet blijven. AI-workloads rekken dat evenwicht veel harder op dan conventionele systemen ooit hebben gedaan.

AI maakt kleine vertragingen duur

Een van de interessantere dingen aan AI-infrastructuur is dat het inefficiënties blootlegt die oudere workloads grotendeels konden verbergen. In een traditioneler systeem hoeft een kleine vertraging in datatoegang niet zo veel te betekenen. De processor wacht even, de taak is iets later klaar, en de gebruiker merkt er niets van. AI-systemen zijn veel minder vergevingsgezind, omdat ze werken met zoveel parallellisme en omdat er zoveel geld vastzit in de compute-laag.

Als een GPU niet op tijd de data krijgt die hij nodig heeft, is dat niet alleen een technisch ongemak. Het is dure idle time. Vermenigvuldig dat over veel accelerators die parallel draaien, en zelfs heel kleine vertragingen beginnen zichtbaar te worden als echte verliezen in benutting.

Daardoor verandert ook het doel. Het doel is niet simpelweg snel geheugen hebben. Het doel is om de datalevering consistent genoeg te houden, op een schaal die groot genoeg is om de duurste delen van het systeem voortdurend bezig te houden. Dat is een veel zwaardere eis, en precies daarom begint DRAM alleen onvoldoende te lijken zodra AI-infrastructuur voorbij een bepaald punt groeit.

De magazijn-analogie werkt nog steeds – ze wordt alleen groter

Als we dezelfde magazijn-analogie uit de eerdere artikelen blijven gebruiken, dan is DRAM nog steeds het laadperron. Het is de plek waar actief werk plaatsvindt, waar items worden geopend, gesorteerd en direct in gebruik worden genomen. Jarenlang werkte dat model goed, omdat de hoeveelheid activiteit op het laadperron beheersbaar was en het systeem niet eiste dat alles daar tegelijk klaarstond.

AI verandert de schaal van de operatie. Nu wordt verwacht dat het laadperron een bijna constante stroom materiaal ondersteunt, met veel meer activiteit die parallel plaatsvindt en veel minder tolerantie voor vertraging. Op een gegeven moment kan zelfs het beste laadperron niet simpelweg blijven groeien. Er is maar zoveel ruimte, maar zoveel parallelle bewegingen die efficiënt kunnen plaatsvinden, en maar zoveel voorraad die je direct op het punt van gebruik kunt houden voordat de layout zelf onderdeel van het probleem wordt.

Dus het antwoord is niet om het laadperron oneindig groter te maken. Het antwoord is om de workflow eromheen opnieuw te ontwerpen.

Daar begint de rest van de geheugenshiërarchie zijn plaats te verdienen. HBM houdt de meest tijdkritische data direct naast de processor. Storage class memory helpt de overgang tussen actief geheugen en tragere storage af te vlakken. En in het recentere artikel over waarom moderne AI-systemen zoveel geheugen verbruiken, verschoof de focus naar hoe ook de storage-kant opnieuw wordt ontworpen zodat die intelligenter kan meedoen aan het voeden van het systeem.

Geen van die lagen bestaat omdat DRAM heeft gefaald. Ze bestaan omdat AI voorbij het idee is gegroeid dat één enkele snelle laag de hele workload in zijn eentje kan dragen.

Wat dit echt betekent voor de AI-geheugenstack

De echte conclusie hier is niet dat DRAM verdwijnt, want dat is overduidelijk niet het geval. DRAM blijft een van de belangrijkste onderdelen van de hele stack. Wat verandert, is zijn rol. In plaats van de plek te zijn waar alles wat actief is hoort te leven, wordt DRAM steeds meer de plek waar de meest urgente en tijdgevoelige data leeft, terwijl andere lagen de groeiende last van schaal, kosten en capaciteit opvangen.

Dat is een subtiele verschuiving, maar wel een belangrijke. Het betekent dat AI-infrastructuur zich verwijdert van het oudere idee van een simpel tweelaags model – geheugen hier, storage daar – en opschuift naar iets veel genuanceerders, waarin verschillende technologieën elk worden ingezet voor het deel van de workload waar ze het best geschikt voor zijn.

Simpel gezegd: DRAM blijft essentieel, maar is op zichzelf niet meer genoeg. AI heeft de grootte van de working set veranderd, de snelheid van compute, de kosten van vertraging en de economie van alles dichtbij houden. Zodra al die dingen tegelijk veranderen, moet de geheugenshiërarchie mee veranderen.

Waar dit hierna naartoe leidt

Zodra je accepteert dat DRAM zich niet ver genoeg kan uitstrekken om alles vast te houden wat AI dichtbij compute wil hebben, wordt de volgende vraag vrij vanzelfsprekend. Waar leeft de rest van die data eigenlijk, vooral wanneer de hoeveelheid informatie veel te groot is om te rechtvaardigen dat je die in geheugen houdt?

Daar draait het gesprek opnieuw, en een technologie waarvan veel mensen aannemen dat die allang opzijgeschoven is, begint op een verrassend belangrijke manier weer mee te tellen. Want terwijl DRAM moeite heeft met schaal en flash nog steeds zijn eigen kosten- en latencycompromissen met zich meebrengt, blijven harde schijven iets bieden dat de rest van de stack niet makkelijk kan vervangen: praktische capaciteit op enorme schaal.

En dat is precies waarom het volgende deel van deze reeks moet kijken naar waarom harde schijven nog steeds cruciaal zijn voor AI-infrastructuur.

Kleine cellen, enorme snelheid, en toch nauwkeurig. Geen magie, maar techniek.

Op een gegeven moment zie je een USB-stick met een opgegeven snelheid van 400MB per seconde en denk je … dat kan niet echt zijn. Of in elk geval niet op een manier die ook nog nauwkeurig is.

Het voelt te snel. Te strak. Te perfect. Alsof er ergens iets moet worden opgeofferd.

Dat gevoel is niet verkeerd – het is alleen gebaseerd op hoe wij snelheid in de echte wereld begrijpen. Als mensen sneller werken, ontstaan er fouten. Als systemen zich haasten, wordt het slordig. Dus wanneer je “400MB per seconde” hoort, vertaalt je brein dat stilletjes naar: “er wordt waarschijnlijk ergens iets overgeslagen.”

Maar flashgeheugen werkt niet zoals wij denken dat het werkt.

Het eerste wat je moet begrijpen is dit: een USB-stick schrijft niet één datastroom ontzettend, ontzettend snel weg. Hij schrijft heel veel kleinere stukjes data tegelijk, verspreid over meerdere geheugengebieden die allemaal parallel werken.

Dus in plaats van één proces dat met extreme snelheid beweegt, heb je tientallen kleinere processen die allemaal in een heel gecontroleerd, heel beheersbaar tempo werken. Van buitenaf lijkt het snel, maar van binnen is het georganiseerd, verdeeld en doelbewust.

Denk aan een magazijn.

Als één persoon elke seconde 400 dozen in een vrachtwagen zou moeten laden, zou het chaos zijn. Dozen zouden vallen, verkeerd gelabeld worden of helemaal gemist worden. Dat is het mentale beeld dat de meeste mensen hebben wanneer ze “400MB per seconde” horen.

Maar dat is niet wat er gebeurt.

Stel je in plaats daarvan 40 transportbanden voor, met aan elke band medewerkers die één doos tegelijk plaatsen. Elke doos wordt gescand, gecontroleerd en correct neergezet voordat hij verdergaat. Niemand hoeft te haasten. Niemand raakt overbelast. En toch is de totale output enorm, omdat alles tegelijk gebeurt.

Zo haalt flashgeheugen hoge snelheid zonder nauwkeurigheid op te offeren.

In de USB-stick werkt een controller als een verkeersregelaar. Hij splitst binnenkomende data op in kleinere stukken en verdeelt die stukken over meerdere NAND-geheugenchips. Elke chip schrijft zijn deel zelfstandig weg, vaak parallel aan de andere chips. Het systeem is ontworpen om prestaties op te schalen door inspanning te vermenigvuldigen, niet door één enkel pad voorbij zijn limieten te duwen.

En hier wordt het nog interessanter.

Flashgeheugen is niet perfect – het corrigeert zichzelf voortdurend

Wat je gemakkelijk mist, is hoe constant dit proces eigenlijk is. Elk klein stukje data dat naar flash wordt geschreven, wordt direct gecontroleerd en zo nodig gecorrigeerd voordat het systeem verdergaat. Dit is geen eenmalig vangnet – het gebeurt continu over alle geheugengebieden tegelijk, terwijl er alweer nieuwe data wordt geschreven. Het systeem is voortdurend tegelijk aan het schrijven, verifiëren en bijsturen.

Dit is het deel dat de meeste mensen niet beseffen, en het is precies wat het hele systeem laat werken.

NAND-flashgeheugen is van zichzelf niet perfect. Op fysiek niveau betekent data opslaan dat er elektrische lading in piepkleine cellen wordt geplaatst. Die lading kan een beetje verschuiven. Schrijfacties kunnen net iets naast hun doel terechtkomen. Kleine fouten zijn niet alleen mogelijk – ze worden verwacht.

Daarom is het hele systeem om die realiteit heen gebouwd.

Elke keer dat data wordt geschreven, controleert de controller het resultaat. Als iets niet helemaal klopt, stelt hij bij en schrijft de data opnieuw. Naast de eigenlijke data wordt extra informatie opgeslagen die specifiek bedoeld is voor foutcorrectie. Wanneer de data later weer wordt gelezen, gebruikt de controller die extra informatie om onregelmatigheden direct te detecteren en meteen te corrigeren.

Op fysiek niveau is schrijven naar NAND niet één enkele handeling – het is een snelle reeks stappen. De controller past een nauwkeurige spanning toe om lading in een cel op te slaan, controleert direct of die lading is terechtgekomen waar die moest komen, en als dat niet zo is, stelt hij bij en probeert hij het opnieuw. Dat gebeurt in microseconden, en het gebeurt keer op keer totdat de data correct is geschreven.

Dit gaat zo snel dat je het nooit ziet. Maar het gebeurt voortdurend.

Met andere woorden: nauwkeurigheid komt niet voort uit perfectie. Het komt voort uit voortdurende verificatie en correctie op machinesnelheid.

Daarom kan een USB-stick data verplaatsen met honderden megabytes per seconde en toch de gegevensintegriteit behouden. Hij schrijft niet blind weg en hoopt dan maar op het beste. Hij schrijft, controleert, corrigeert en bevestigt elke stap onderweg.

Dus de volgende keer dat je een specificatie ziet zoals 400MB/sec, helpt het om dat getal anders te bekijken.

Het is niet één enkel ding dat onmogelijk snel beweegt. Het is een gecoördineerd systeem van heel veel kleinere handelingen die allemaal samenwerken, allemaal worden gecontroleerd en allemaal zijn ontworpen met de verwachting dat fouten zullen optreden – en direct worden hersteld.

Flash is niet snel omdat het haast. Het is snel omdat het vermenigvuldigt.

AI-infrastructuur heeft een manier om grenzen bloot te leggen waar de meeste systemen nooit tegenaan lopen.

In de eerdere stukken hebben we gekeken naar hoe high bandwidth memory voor AI-workloads data zo dicht mogelijk bij de GPU houdt, en hoe storage class memory tussen DRAM en NAND helpt om de kloof tussen actief geheugen en traditionele flashopslag glad te strijken. Beide lagen bestaan omdat het systeem zich niet kan veroorloven om te wachten, zelfs niet voor korte momenten, zonder efficiëntie te verliezen.

Maar er is nog een andere richting waarin de industrie zich beweegt, en die draait niet om het introduceren van een volledig nieuw type geheugen.

In plaats daarvan neemt men iets dat al bestaat, NAND-flash, en duwt men het in een rol waarvoor het oorspronkelijk niet bedoeld was.

Daar begint het idee van High Bandwidth Flash in beeld te komen.

Het probleem dat NAND nooit bedoeld was om op te lossen

NAND-flash is altijd gebouwd rond een eenvoudig idee: veel data efficiënt opslaan en die terughalen wanneer dat nodig is.

Voor de meeste workloads werkt dat model prima. Data staat in de opslag, het systeem vraagt erom, en de SSD levert die snel genoeg aan zodat bijna niemand de vertraging echt opmerkt.

AI-workloads veranderen die dynamiek.

In plaats van af en toe lezen en schrijven, trekken deze systemen voortdurend data parallel naar binnen, vaak over duizenden threads tegelijk, met heel weinig tolerantie voor inconsistentie in de levering. Het gaat niet alleen om snelheid op zichzelf, maar om het vasthouden van een constante datastroom die de rekenkant volledig benut houdt.

Daar beginnen de beperkingen van traditioneel NAND-gedrag zichtbaar te worden.

Zelfs high-performance NVMe-drives, met diepe wachtrijen en sterke throughputcijfers, werken nog steeds binnen een opslagmodel dat uitgaat van pieken in activiteit, niet van een continue, geheugenachtige stroom van toegang.

Dus de vraag wordt: wat gebeurt er als je NAND niet langer als opslag behandelt, maar het meer gaat behandelen als onderdeel van het geheugensysteem?

Wat “High Bandwidth Flash” eigenlijk betekent

High Bandwidth Flash is geen formele standaard en ook geen enkele productcategorie.

Je kunt het beter zien als een architectonische richting, en daar begint het zich ook te onderscheiden van wat we behandelden bij High Bandwidth Memory.

High Bandwidth Memory is nog steeds geheugen. Het is DRAM, gebouwd en gepositioneerd om extreem snelle toegang te leveren doordat het fysiek dicht bij de processor zit. Het hele punt van HBM is nabijheid en lagere latency, data zo dicht mogelijk bij compute brengen zodat die vrijwel direct toegankelijk is.

High Bandwidth Flash lost een ander probleem op. Het accepteert dat NAND verder weg in het systeem zit en hogere latency met zich meebrengt, en richt zich er in plaats daarvan op om veel grotere hoeveelheden data parallel te verplaatsen zodat die afstand minder zwaar weegt.

Eenvoudig gezegd: HBM gaat over geheugen sneller maken door het dichterbij te brengen. High Bandwidth Flash gaat over opslag sneller laten aanvoelen door te veranderen hoe die wordt benaderd.

Dat onderscheid is belangrijk, want het doel hier is niet om NAND in DRAM te veranderen. Het doel is om NAND bruikbaar te maken in situaties waarin traditionele opslag het systeem anders zou vertragen.

Die verschuiving gebeurt op systeemniveau, niet alleen op medianiveau.

In plaats van één enkele SSD die verzoeken op de traditionele manier afhandelt, zie je steeds vaker veel NAND-kanalen die parallel werken, controllers die ontworpen zijn voor gelijktijdigheid in plaats van alleen capaciteit, bredere datapaden via PCIe Gen5- en Gen6-interfaces, en softwarelagen die data anticiperen en klaarzetten voordat die wordt opgevraagd.

Alles bij elkaar genomen nemen deze veranderingen de inherente latency van NAND niet weg, maar ze verkleinen wel hoe vaak die latency de beperkende factor in het systeem wordt.

Een andere manier om over bandbreedte na te denken

Wanneer mensen “hoge bandbreedte” horen, denken ze meestal aan pure snelheid.

Maar in deze context gaat bandbreedte eigenlijk over hoeveel data er tegelijk verplaatst kan worden, en hoe consistent die verplaatsing volgehouden kan worden.

AI-workloads hebben niet alleen snelle toegang nodig, maar voorspelbare toegang op schaal.

Als een GPU-cluster data ongelijkmatig binnenhaalt, kunnen zelfs kleine variaties ervoor zorgen dat delen van het systeem stilvallen. Vermenigvuldig dat over honderden of duizenden nodes, en die inefficiënties beginnen zichtbaar te worden op manieren die lastig te negeren zijn.

High Bandwidth Flash is een poging om dat glad te strijken, niet door de eigenschappen van NAND te elimineren, maar door het te omringen met genoeg parallelisme en intelligentie zodat die eigenschappen minder zwaar wegen voor het totale systeem.

De magazijnanalogie verder doortrekken

Als we hetzelfde magazijnmodel uit de eerdere artikelen blijven gebruiken, dan is NAND altijd de hoofdopslagvloer geweest.

Dat is de plek waar alles ligt, georganiseerd in rijen en schappen, geoptimaliseerd voor dichtheid en efficiëntie in plaats van voor toegangssnelheid.

DRAM is het laadperron, waar het actieve werk gebeurt. SCM is het staginggebied er direct achter.

High Bandwidth Flash verandert hoe het magazijn werkt.

In plaats van één medewerker die de gangpaden in loopt om artikelen één voor één te pakken, heb je nu meerdere laadperrons tegelijk open, verschillende heftrucks die parallel bewegen, en artikelen die vooraf worden klaargezet op basis van wat het systeem verwacht hierna nodig te hebben.

Het magazijn zelf is fundamenteel niet veranderd, maar de manier waarop het wordt benaderd wel.

Je verandert het magazijn niet in het laadperron, je laat het magazijn zich gedragen alsof het er veel dichter bij ligt.

Hoe dit in de praktijk wordt gebouwd

Het meeste van wat High Bandwidth Flash mogelijk maakt, komt niet uit het NAND zelf, maar uit de lagen eromheen.

Controllers spelen nu een grotere rol in hoe data wordt verdeeld, met een focus op parallelle operaties over meerdere NAND-dies en kanalen in plaats van alleen het beheren van capaciteit en slijtage. Tegelijkertijd blijft de interfacebandbreedte groeien, waardoor deze systemen meer ruimte krijgen om data te verplaatsen zonder dat de bus de beperkende factor wordt.

Wat echter het grootste verschil maakt, is hoe de software met de hardware omgaat.

Data wordt niet meer alleen opgehaald op het moment dat die wordt opgevraagd. Ze wordt voorspeld, klaargezet, gecachet en georganiseerd op manieren die aansluiten bij hoe AI-workloads zich gedragen. Dat betekent toegangspatronen vooraf inschatten, vaak gebruikte data dichter bij de top van de stack houden en minimaliseren hoe vaak het systeem moet terugvallen op tragere paden.

Niets daarvan verandert NAND in echt geheugen, maar het stelt NAND wel in staat om actiever deel te nemen aan het geheugensysteem dan voorheen.

Wat het nog steeds niet is

Ondanks al deze vooruitgang is het belangrijk om de verwachtingen realistisch te houden.

High Bandwidth Flash maakt NAND niet gelijkwaardig aan DRAM. Het is nog steeds block-based, heeft nog steeds hogere latency dan welke vorm van echt geheugen ook, en blijft sterk afhankelijk van controllers en software om goed te presteren in veeleisende omgevingen.

Die beperkingen verdwijnen niet, ze worden alleen effectiever beheerd via systeemontwerp.

Waar dit past binnen AI-infrastructuur

In echte deployments duikt High Bandwidth Flash op in systemen die extreem grote datasets moeten verwerken zonder alles in dure geheugentiers te duwen.

Hoe dat er in de praktijk echt uitziet, is een systeem dat veel actiever op NAND leunt dan vroeger, niet alleen als plek waar data wordt opgeslagen, maar als onderdeel van het werkende datapad dat compute-resources op een meer continue manier voedt.

In grootschalige inference-omgevingen bijvoorbeeld overschrijden modellen en contextdata vaak wat realistisch in DRAM past. In plaats van alles geforceerd in geheugen te stoppen, vertrouwt het systeem op high-throughput toegang tot NAND, waardoor data snel genoeg kan binnenstromen dat het zich meer gedraagt als een uitbreiding van geheugen dan als traditionele opslag.

In trainingsomgevingen, waar datasets voortdurend opnieuw worden bekeken en parallel worden verwerkt, verschuift het doel naar het onderhouden van een gestage stroom in plaats van het afhandelen van losse pieken. High Bandwidth Flash ondersteunt dat door meerdere datapaden tegelijk actief te houden, waardoor de kans kleiner wordt dat één enkel verzoek een bottleneck wordt.

Zelfs in gedistribueerde NVMe-fabric-systemen blijft het idee hetzelfde. Data is verspreid over veel apparaten en nodes, maar wordt op een gecoördineerde manier benaderd waarbij throughput en beschikbaarheid belangrijker zijn dan eenvoudige opslagcapaciteit. NAND doet nog steeds dezelfde fundamentele taak, maar de manier waarop het systeem ermee omgaat is veel dynamischer dan vroeger.

Het eindresultaat is dat NAND stopt met aanvoelen als een verre laag onderaan de stack en meer begint te voelen als onderdeel van het actieve systeem, ook al bereikt het nooit helemaal de prestatie-eigenschappen van geheugen.

Waarom deze richting ertoe doet

Als je een stap terugdoet en kijkt naar wat er in al deze drie artikelen gebeurt, begint er een patroon zichtbaar te worden.

HBM brengt geheugen dichter bij compute. SCM verkleint de kloof tussen geheugen en opslag. High Bandwidth Flash schuift opslag dichter naar geheugen toe.

Alles convergeert naar hetzelfde doel: verkleinen hoe ver data moet reizen, en hoe lang het systeem erop moet wachten.

Terug naar het grotere geheel

NAND verdwijnt niet.

Als er al iets gebeurt, is het dat NAND juist belangrijker wordt, omdat de totale hoeveelheid data die deze systemen nodig hebben blijft groeien.

Wat verandert, is hoe NAND wordt gebruikt.

Het is niet langer alleen een passieve laag onderaan de stack. Het wordt omhooggetrokken, strakker geïntegreerd en gevraagd zich te gedragen op manieren die steeds meer op geheugen lijken, ook al wordt het dat nooit helemaal.

Die verschuiving is precies waar we in het oorspronkelijke stuk op wezen: de industrie heeft NAND niet vervangen, maar eromheen gebouwd.

Wat hierna komt

Vanaf hier blijft de stack zich in beide richtingen ontwikkelen.

Bovenin wordt geheugen sneller en specialistischer. Onderin wordt opslag intelligenter en meer geïntegreerd. En ergens daartussen wordt de grens tussen die twee steeds moeilijker te trekken.

In het volgende stuk kijken we naar hoe AI-systemen werkdata in real time afhandelen, en waarom concepten als context en KV-cache beginnen te beïnvloeden hoe geheugen en opslag samen worden ontworpen.

Redactionele noot

Het perspectief, de richting en de technische inkadering van dit artikel zijn door de auteur bepaald, gebaseerd op de specifieke thema’s die in het stuk worden verkend en de bredere discussie over hoe NAND binnen AI-infrastructuur dichter naar de geheugenlaag wordt geschoven.

AI is gebruikt als schrijfassistent om te helpen met ritme, zinsverloop en structurele organisatie, maar de onderwerpkeuze, vergelijkingen en uiteindelijke redactionele intentie zijn door de auteur bepaald.

De begeleidende afbeelding is ook met AI gemaakt, niet als generieke stockvisual, maar als doelgerichte illustratie om artikelspecifieke concepten weer te geven die lastig met conventionele beelden te communiceren zijn – in het bijzonder het idee dat NAND-flash zich meer gedraagt als een actieve, geheugen-aangrenzende laag binnen een moderne data-architectuur.

Alle inhoud is door de auteur beoordeeld, verfijnd en goedgekeurd vóór publicatie.

Als je hier bent gekomen omdat je een USB-stick wilde defragmenteren of TRIM wilde gebruiken op een USB-flashdrive, dan is de reden dat je vastliep heel simpel: die tools zijn niet van toepassing op USB-flashdrives zoals dat wel het geval is bij harde schijven en SSD’s.

Je bent bij dit artikel uitgekomen omdat je probeert een USB-stick te defragmenteren of TRIM toe te passen op een USB-flashdrive, en waarschijnlijk heb je al iets frustrerends gemerkt – er is geen optie om een van beide te doen. Geen instelling, geen tool, niets dat werkt zoals bij een harde schijf of SSD. Dat is geen fout, en het is ook niet iets dat ergens verborgen zit in een menu. Je kunt een USB-flashdrive simpelweg niet defragmenteren of op een betrouwbare manier TRIM gebruiken, en zodra je begrijpt hoe deze apparaten werken, wordt de reden al snel behoorlijk duidelijk.

Zodra je begint te kijken naar hoe AI-systemen daadwerkelijk data verplaatsen, merk je vrij snel dat het probleem niet alleen gaat over snellere processors of meer opslag, maar vooral over wat er tussen die lagen gebeurt en hoe vaak het systeem moet wachten.

In het vorige artikel over High Bandwidth Memory lag de nadruk op het zo dicht mogelijk bij de processor houden van data, zodat de GPU niet stil komt te staan. Dat is de bovenkant van de stack en dat is cruciaal, maar het lost maar een deel van het probleem op, omdat niet alles daar kan blijven.

Zodra de werkset groter wordt dan wat in die directe laag past, ga je weer data verplaatsen tussen DRAM en NAND, en daar begint het geheel wat onevenwichtig aan te voelen. DRAM is snel en responsief, maar duur en niet onbeperkt schaalbaar. NAND is veel praktischer qua capaciteit, maar zelfs goed flashgeheugen introduceert genoeg vertraging dat het merkbaar wordt wanneer het systeem continu onder belasting staat.

Die ruimte ertussen is waar Storage Class Memory zijn waarde begint te tonen. Niet als iets nieuws dat één van beide kanten wil vervangen, maar als een manier om de overgang soepeler te maken zodat het systeem niet voortdurend springt van heel snel naar merkbaar trager en weer terug.

Als je het bredere plaatje wilt begrijpen waarom deze lagen überhaupt ontstaan, dan sluit dit direct aan op het hoofdartikel hier: NAND verdwijnt niet, maar AI-servers zijn tegenwoordig afhankelijk van meer dan alleen flash.