Wachten op data, in beeld
Een cloud-API-roundtrip is ongeveer honderdvijftig miljoen keer trager dan CPU-cache. Zo'n getal zegt weinig — tot u het ziet. Elke zichtbare laag beweegt hieronder met dezelfde tijdsvermenigvuldiger. Daardoor blijven de onderlinge verhoudingen behouden: een HDD beweegt aantoonbaar veel langzamer dan netwerkopslag. De werkelijke waarden staan er altijd bij.
Zo leest u dit: de langzaamste gekozen laag legt bij 1× één traject af in ongeveer 25 seconden. Alle andere zichtbare lagen gebruiken exact dezelfde tijdsvermenigvuldiger; de verhouding tussen hun bewegingen is dus gelijk aan de verhouding tussen hun toegangstijden. Zeer snelle lagen worden bewust als lichtstreep getoond, omdat afzonderlijke overgangen dan niet meer te volgen zijn. De amber regels en tellers tonen de reële verhouding en orde van grootte.
Latentie is de stilte vóór het antwoord
Bandbreedte zegt hoeveel data er stroomt zodra de overdracht loopt. Latentie is het wachten daarvoor. Bij kleine, willekeurige leesbewerkingen — databases, virtualisatie, interactieve applicaties — is juist dat wachten bepalend. Een CPU kan niet rekenen aan data die nog niet binnen is; trage opslag laat dure processors en licenties wachten.
Voor AI speelt dit dubbel: trainingsdatasets en RAG-indexen willen snelle, willekeurige toegang, terwijl back-ups en archieven best op trage, goedkope media mogen. De kunst is elke workload op de juiste laag te leggen.
Waarom geheugenbalans zoveel uitmaakt
Server-CPU's lezen geheugen via parallelle kanalen — moderne platformen hebben er acht tot twaalf per socket. Vult u maar de helft van de kanalen, dan halveert u de geheugenbandbreedte, hoeveel RAM er ook in zit. Voor AI-workloads en databases is dat verschil direct voelbaar: de GPU of CPU wacht op data.
De regels zijn eenvoudig maar worden vaak over het hoofd gezien: vul alle kanalen gelijk, gebruik identieke modules per kanaal, en houd bij dual-socket systemen de verdeling over beide CPU's (NUMA) in balans. Een "goedkope" configuratie met half gevuld geheugen is in de praktijk vaak de duurste keuze.
De lagen op een rij
Representatieve orden van grootte. Werkelijke waarden variëren met hardware, queue depth, cache-status, protocol en systeemontwerp.
| Technologie | Toegangstijd | T.o.v. cache | Typische capaciteit | Typische rol |
|---|---|---|---|---|
| CPU-cache | ~1 ns | 1× | enkele MB | Directe CPU-toegang |
| DDR5 RAM | ~15 ns | 15× | tientallen tot honderden GB | Werkgeheugen |
| NVMe SSD | ~15 µs | 15.000× | 1–30 TB | Databases, AI-datasets, virtualisatie |
| Netwerk-opslag (NAS/iSCSI) | ~250 µs | 250.000× | 10 TB – meerdere PB | Gedeelde bestanden, scale-out storage |
| SAS 7K HDD | ~12 ms | 12.000.000× | 4–24 TB | Bulk, archief, back-up |
| Cloud-API roundtrip | ~150 ms | 150.000.000× | onbeperkt | Externe AI-API's via internet |
Praktische conclusie: een HDD is uitstekend voor back-ups en archief — werkloads die sequentieel en zelden lezen. Maar leg een database of AI-dataset op diezelfde schijf en iedere willekeurige leesbewerking kost duizenden keren meer wachttijd dan nodig. Het disktype kiezen is dus geen kostenkwestie alleen; het bepaalt hoe effectief alles eromheen werkt.
Verdenkt u een opslag- of geheugenknelpunt?
We meten de werkelijke I/O-pad in uw omgeving en rekenen door wat een andere verdeling over de lagen oplevert — vaak zonder nieuwe hardware.
Plan een kennismaking