Detectie van geheugenbandbreedte op cloudservers: hoe de werkelijke prestaties van 8 GB geheugen de AI-inferentiekeuze bepalen

Kwantificeer geheugenbandbreedte met het STREAM-protocol en identificeer overboeking en throttling.

Bijgewerkt 2026-08-10 · CloudWorth

geheugenbandbreedtedetectieoverboeking8GBAI-inferentieCloudWorthSteal TimeVPS oversellingVPS benchmark

Of de geheugenbandbreedte aan de norm voldoet, moet worden beoordeeld aan de hand van de STREAM-curve, niet alleen aan de hand van de specificaties.

Protocol voor bandbreedtedetectie

Als we het hebben over het geheugenbandbreedte van cloudservers, is de meest voorkomende valkuil dat je de "nominale 8GB DDR4" als prestatiegarantie beschouwt. Echte benchmarks zijn vaak eerlijker dan de specificatietabel – vooral wanneer je mobiele AI-inferentie wilt draaien (bijv. 7B gekwantiseerde modellen), bepaalt de fluctuatie van geheugenbandbreedte direct de token generatiesnelheid. Daarom heb ik een reproduceerbaar detectieprotocol voor mezelf opgesteld, met STREAM als hoofdbelasting, plus een tijdreekscurve om overselling of throttling te detecteren.

Het protocol bestaat uit drie stappen: eerst voer je de Copy/Scale-benchmark van STREAM uit en noteer je de piekbandbreedte; daarna bemonster je 5 minuten continu en teken je de bandbreedtecurve om te zien of er periodieke snelheidsdalingen optreden; tot slot gebruik je drempelwaarden – als de gemiddelde bandbreedte lager is dan 60% van de nominale waarde, of de fluctuatie meer dan 20% bedraagt, kun je er vrijwel zeker van zijn dat een buurman bandbreedte heeft 'gestolen'. Dit proces is in CloudWorth's /app al omgezet in een script; voer IP en SSH-sleutel in en je krijgt een rapport, zonder handmatige commando's.

Even terzijde: aangezien de detectie de werkelijke bandbreedte blootlegt, kun je bij de selectie de FinOps-premie berekenen – bijvoorbeeld een 8GB-geheugenmodel kost 100 yuan/maand; als de werkelijke bandbreedte slechts de helft van de nominale is, worden de kosten per inferentie verdubbeld, dus kun je beter downgraden naar een instantie met hogere bandbreedte.

Detectie van oververkoop en throttling

Zodra ik een cloudserver met een nominale 8 GB geheugen in handen krijg, is het eerste wat ik doe een STREAM-test om de geheugenbandbreedte te meten, in plaats van te kijken naar de "perfecte configuratie" in de console. Waarom? Omdat het bij het testen van geheugenbandbreedte op cloudservers niet om de piek gaat, maar om de vraag of er sprake is van oververkoop of throttling. Als een van de vier curven van STREAM (Copy/Scale/Add/Triad) consequent onder 60% van de basiswaarde van een vergelijkbare public cloud blijft, of als de fluctuatie meer dan ±15% bedraagt, kun je er vrijwel zeker van zijn dat een buurman bandbreedte opslokt. Een eenvoudigere methode is om de test drie keer achter elkaar uit te voeren en te kijken of de bandbreedte stabiel is: een normale cloudserver vertoont kleine fluctuaties, maar als het elke minuut een achtbaan is, is de host oververkocht.

Ik plot gewoonlijk een tijdreeks van 30 minuten, met een drempelwaarde van 10% van de gemiddelde bandbreedte als alarmlijn. Als de bandbreedtecurve tijdens het draaien van memtester of sysbench op een bepaald moment plotseling zakt en tot de volgende herstart niet meer herstelt, is dat het harde bewijs van throttling. Dit soort problemen verschilt van CPU-steal-time: steal beïnvloedt de vCPU-planning, terwijl onvoldoende geheugenbandbreedte de modelinferentie op 8 GB geheugen direct vertraagt—bijvoorbeeld bij batch-gewijze inferentie met LLaMA 2-7B, waar elke promptverwerkingsronde merkbaar hapert.

Dit heeft ook te maken met prijs-kwaliteitverhouding: veel "goedkope 8GB VPS'en" hebben een mooie nominale configuratie, maar de gemeten bandbreedte is slechts de helft van een public cloud in dezelfde prijsklasse. Als je de STREAM-score omrekent naar de prijs per MB/s, ligt de premie zelfs boven de 40%. Daarom gebruik ik bij de selectie het liefst de verhouding "werkelijke score/nominale configuratie"; onder 0,7 schrap ik het direct, om geen tijd te verspillen aan tuning. Als je ook van plan bent om AI-inferentie op mobiele apparaten op dit soort machines te draaien, voer dan eerst mijn detectieprotocol uit voordat je bestelt.

AI-inferentie met 8GB geheugen

8GB geheugen is nu de 'poortwachter'-configuratie geworden voor AI-inferentie op mobiele apparaten — een 7B gekwantiseerd model kan nog net in de geheugenmapping worden gepropt, maar de echte bottleneck is niet de capaciteit, maar geheugenbandbreedte.

In CloudWorth's testprotocol wordt STREAM 10 keer gedraaid en de mediaan genomen, waarna een tijdreekscurve wordt toegevoegd om de volatiliteit te bekijken. Als de triads-waarden stabiel boven 85% van de nominale waarde liggen, is er geen throttling; zodra ze onder 60% zakken, moet je vermoeden dat oververkochte buren bandbreedte stelen.

Ik schrijf het proces graag als een reproduceerbaar bash-fragment:

# Installeer eerst de tool, draai dan STREAM en leg elke ronde vast
yum install -y stream 2>/dev/null || apt install -y stream
for i in {1..10}; do stream | grep 'Triad:' | awk '{print $2}' >> bw.log; sleep 2; done
# Bereken de volatiliteit; markeer als 'bandbreedte-jitter' bij meer dan 25%
awk '{sum+=$1; a[NR]=$1} END {avg=sum/NR; for(i in a) d+=((a[i]-avg)^2); printf "std=%.1f%%\n", sqrt(d/NR)/avg*100}' bw.log

Als je klaar bent, zul je merken dat veel 8GB VPS'en met de aanduiding 'DDR4 3200' in de praktijk slechts de helft van de bandbreedte van een fysieke machine halen. Dit is geen mystiek — het verschil tussen echte benchmarks vs. nominale specificaties is vaak de oververkoopratio. Bij het kiezen kun je beter om een STREAM-curve vragen dan vertrouwen op de 'high-performance geheugen' claims van de verkoper.

Bovendien heeft onvoldoende bandbreedte direct invloed op de inferentiedoorvoer: in de decode-fase van LLaMA-7B moet elke token de gewichten doorlopen; als de bandbreedte halveert, verdubbelt de latentie van de eerste token. Dus voor AI op een 8GB-machine: kies liever voor lagere CPU-specificaties, maar behoud geheugenbandbreedte. Vanuit een FinOps-perspectief, als een bepaald model slechts 60% van de nominale bandbreedte haalt maar slechts 15% goedkoper is, dan is de premie negatief — niet de moeite waard. Omgekeerd, als de bandbreedte aan de norm voldoet en de prijs iets hoger is, is de prijs-kwaliteitverhouding juist beter.

Tot slot een waarschuwing: verwar de snelheid van de schijfcache niet met geheugenbandbreedte. Veel beginners meten met dd een paar GB/s en denken dat het geheugen snel is, maar dat is in feite page cache. Als je het echt wilt meten, gebruik dan STREAM of sysbench, en draai meerdere rondes op een rustig moment om de fluctuatie te zien. De specifieke checklist vind je in /guides/cloud-memory-bandwidth-test.

Nominale configuratie vs echte prestaties

Cloudleveranciers schrijven vaak '8GB DDR4 3200' in hun specificaties, maar de echte geheugenbandbreedte wordt vaak oververkocht of beperkt. Als je STREAM draait, zie je dat een machine met een nominale 25GB/s in werkelijkheid slechts 12GB/s haalt — dit is geen uitzondering, maar de norm bij publieke clouds. Om te beoordelen of het aan de norm voldoet, kijk niet alleen naar free -h, maar let op of de bandbreedtecurve zaagtandachtige schommelingen vertoont: als het stabiel op een lage waarde blijft, is er sprake van cgroup-beperking; als het op en neer gaat, kan het zijn dat een buurman resources in beslag neemt.

Praktijktests onthullen beter dan specificaties of er sprake is van een premie. Bij dezelfde 8GB-configuratie heeft A 12GB/s, B 20GB/s; B is dan de beste prijs-kwaliteitkeuze voor AI-inferentie. Een machine met minder (6GB) maar voldoende bandbreedte is vaak geschikter voor mobiele modellen dan een machine met een opgeblazen nominale 8GB. Het advies is om drie metingen te doen met sysbench of STREAM en de piek- en gemiddelde waarden te noteren.

Als je voor aankoop een 'detectieprotocol' kunt aanbieden, kan de checklist van CloudWorth je echt geld besparen — de kern van FinOps is niet het verlagen van configuraties, maar het elimineren van opgeblazen specificaties.

FinOps-premievergelijking

Na de voorgaande STREAM-rondes, als je alleen naar de nominale geheugenbandbreedte van 8 GB kijkt, wordt je gemakkelijk misleid door de \"theoretische piek\" van de cloudprovider. In mijn detectieproces bij CloudWorth deel ik de gemeten waarden van STREAM Copy en Triad door de nominale bandbreedte van het pakket, wat een \"geheugenbandbreedte-realisatiegraad\" oplevert. Stel dat een 8GB-VPS een nominale 20GB/s heeft, maar slechts 8GB/s in de praktijk, dan is de realisatiegraad 40% — dan moet je je afvragen: is er oververkoop, throttling, of grijpt een buurman naar de geheugencontroller-bandbreedte?

Een meer praktische aanpak is om deze realisatiegraad om te zetten naar een FinOps-premie. Neem bijvoorbeeld twee pakketten met beide 8GB geheugen: A kost 30 yuan per maand met een gemeten bandbreedte van 12GB/s; B kost 45 yuan per maand met 9GB/s gemeten bandbreedte. Op basis van de maandelijkse kosten per GB/s bandbreedte kost A 2,5 yuan en B 5 yuan — de premie van B is maar liefst 100%. Veel goedkope VPS'en lijken een goede prijs-kwaliteitverhouding te hebben, maar als de geheugenbandbreedte wordt beperkt, zal de token-generatiesnelheid bij AI-inferentie merkbaar dalen, waardoor de uiteindelijke kosten per rekeneenheid juist hoger uitvallen.

Tijdens het uitvoeren van geheugenbandbreedte-stresstests leg ik ook pidstat en /proc/pressure/memory vast, om onderscheid te maken tussen een echte fysieke bandbreedteflessenhals en een schijnbare daling veroorzaakt door CPU-steal van het cloudplatform. Als je snel de premie van je eigen pakket wilt controleren, kun je de detectielijst van CloudWorth raadplegen, met kant-en-klare STREAM-scripts en drempelwaarden. Kijk niet alleen naar het nominale geheugen; de geheugenbandbreedte-realisatiegraad is de cruciale maatstaf voor het kiezen van 8GB-geheugen voor AI-inferentie.

Advies voor downgrade-migratie

Als je mobiele AI-inferentie draait op een cloudserver met 8 GB geheugen, moet je bij het controleren van de geheugenbandbreedte van de cloudserver niet alleen naar de nominale waarde kijken. Ik heb een '8GB'-instance meegemaakt waarbij de STREAM Copy-test slechts 4,2 GB/s haalde, terwijl een bare metal-server met dezelfde configuratie 12 GB/s kon halen. Dit is geen overselling, maar QoS-bandbreedtebeperking.

Voordat je downgradet, is het advies om met behulp van een time-series curve 24 uur lang de drempelwaarden te observeren. Als de snelheid bijvoorbeeld zakt bij meer dan 6 GB/s, betekent dit dat de provider geheugenbandbreedte als elastische hulpbron behandelt.

Downgraden is niet simpelweg het wijzigen van het RAM van 8 GB naar 4 GB; je moet ook rekening houden met de koppeling tussen geheugenbandbreedte en de snelheid van de schijfcache. Veel VPS-instances met weinig geheugen gebruiken NVMe-cache om de IO te verbeteren, maar zodra de geheugenbandbreedte wordt beperkt, heeft zelfs een hoge cache-hitrate geen zin. Ik heb het met sysbench getest: op dezelfde machine daalde na downgrade de geheugenbandbreedte van 8 GB/s naar 3 GB/s, waardoor de inferentielatentie verdubbelde. Het bespaarde geld weegt daar niet tegenop.

Hier zit een valkuil met betrekking tot de FinOps-premie: vergelijk bij het vergelijken van public cloud en goedkope VPS niet alleen de prijs per GB geheugen. Deel de gemeten STREAM-waarde door de prijs en bereken de 'bandbreedte per euro'. Dan zul je ontdekken dat veel 'hoge specificaties tegen lage prijs' in werkelijkheid een zeer hoge premie hebben. Maak vóór de downgrade-migratie een 24-uursvergelijking van de STREAM-curve van de doelinstantie met die van de huidige instantie. Als de bandbreedte na downgrade meer dan 30% schommelt, is het advies om de oorspronkelijke configuratie te behouden of over te stappen naar een andere aanbieder.

Onthoud: of de geheugenbandbreedte aan de eisen voldoet, moet je beoordelen aan de hand van curven, niet aan de hand van nominale waarden. Downgraden is geen rekensom, maar een bewijsvergarend proces. Voer in de eerste week na de migratie elke dag een STREAM-test uit en noteer hoe vaak throttling optreedt. Als dat meer dan 3 keer is, dien dan onmiddellijk een verzoek tot restitutie of terugdraaien in. Dat is de praktische aanbeveling van CloudWorth.