Speicherbandbreitentest für Cloud-Server: Wie die tatsächliche Leistung von 8 GB RAM die KI-Inferenz-Auswahl antreibt

Quantifizieren Sie die Speicherbandbreite mit dem STREAM-Protokoll und erkennen Sie Überbuchung und Drosselung.

Aktualisiert 2026-08-10 · CloudWorth

SpeicherbandbreiteTestÜberbuchung8 GBKI-InferenzCloudWorthSteal TimeVPS OversellingVPS Benchmark

Ob die Speicherbandbreite ausreicht, muss anhand der STREAM-Kurve beurteilt werden, nicht nur anhand der Nennwerte.

Bandbreiten-Erkennungsprotokoll

Wenn es um die Speicherbandbreite von Cloud-Servern geht, ist der häufigste Fehler, die „nominellen 8 GB DDR4“ als Leistungsgarantie zu betrachten. Echte Benchmarks sind oft ehrlicher als die Spezifikationen – insbesondere wenn Sie mobile KI-Inferenz (z. B. quantisierte 7B-Modelle) ausführen möchten, bestimmt die Schwankung der Speicherbandbreite direkt die Token-Erzeugungsgeschwindigkeit. Deshalb habe ich mir ein reproduzierbares Erkennungsprotokoll überlegt, das mit STREAM als Hauptlast arbeitet und eine Zeitreihenkurve hinzufügt, um Überbuchung oder Drosselung zu erkennen.

Das Protokoll besteht aus drei Schritten: Zuerst führen Sie die Copy/Scale-Benchmarks von STREAM aus und notieren die Spitzenbandbreite. Dann sammeln Sie 5 Minuten lang kontinuierlich Proben, zeichnen die Bandbreitenkurve und beobachten, ob periodische Geschwindigkeitseinbrüche auftreten. Schließlich beurteilen Sie anhand von Schwellenwerten: Wenn die durchschnittliche Bandbreite unter 60 % der Nennwerte liegt oder die Schwankung mehr als 20 % beträgt, können Sie im Grunde davon ausgehen, dass ein Nachbar Bandbreite „stiehlt“. Dieser Prozess ist in der CloudWorth /app bereits als Skript umgesetzt – Sie geben IP und SSH-Schlüssel ein und erhalten einen Bericht, ohne Befehle manuell eingeben zu müssen.

Nebenbei bemerkt: Da die Erkennung die tatsächliche Bandbreite offenlegt, können Sie bei der Auswahl den FinOps-Prämienrate berechnen – z. B. kostet eine Instanz mit 8 GB RAM 100 Yuan/Monat. Wenn die tatsächliche Bandbreite nur die Hälfte der Nennwerte beträgt, verdoppeln sich die Kosten pro Inferenz. Dann ist es besser, die Konfiguration zu reduzieren und eine Instanz mit höherer Bandbreite zu wählen.

Erkennung von Überverkauf und Drosselung

Ich habe einen Cloud-Server mit 8 GB RAM bekommen und als Erstes messe ich die Speicherbandbreite mit STREAM, statt auf die "volle Ausstattung" in der Konsole zu schauen. Warum? Weil es bei der Speicherbandbreite von Cloud-Servern nicht auf den Spitzenwert ankommt, sondern darauf, ob es Überverkauf oder Drosselung gibt. Wenn bei STREAM eine der Kurven für Copy/Scale/Add/Triad dauerhaft unter 60 % des Referenzwerts einer gleichwertigen Public Cloud liegt oder um mehr als ±15 % schwankt, kann man den Verdacht hegen, dass der Nachbar die Bandbreite abzweigt. Ein einfacherer Weg ist, drei Messungen nacheinander durchzuführen und zu prüfen, ob die Bandbreite stabil ist: Bei normalen Cloud-Instanzen weichen die Ergebnisse nur leicht ab, aber wenn sie jede Minute wie eine Achterbahnfahrt schwanken, ist der Host überbucht.

Ich zeichne die Zeitreihe über 30 Minuten auf und setze als Alarmlinie einen Schwellenwert von 10 % der durchschnittlichen Bandbreite. Wenn die Bandbreitenkurve bei memtester oder sysbench in bestimmten Zeitfenstern plötzlich abfällt und bis zum nächsten Neustart nicht wieder ansteigt, ist das der eindeutige Beleg für eine Drosselung. Dieses Problem unterscheidet sich von CPU-Steal-Time: Steal wirkt sich auf die vCPU-Planung aus, während zu wenig Speicherbandbreite die Modellinferenz auf einem 8-GB-RAM-System direkt ausbremst – etwa wenn LLaMA 2-7B für Batch-Inferenz verwendet wird, wird die Verarbeitung jeder Eingabeaufforderung spürbar langsamer.

Das betrifft auch das Preis-Leistungs-Verhältnis: Viele "günstige 8GB VPS" sehen auf dem Papier gut aus, aber die tatsächliche Bandbreite ist nur halb so hoch wie bei einer gleich teuren Public Cloud. Wenn man den STREAM-Punktestand auf den Preis pro MB/s umrechnet, liegt der Aufschlag sogar bei über 40 %. Daher bevorzuge ich für die Auswahl das Verhältnis aus "echter Punktestand / angegebener Konfiguration" und streiche alles unter 0,7, um keine Zeit mit Optimierung zu verschwenden. Falls du planst, auf solchen Maschinen KI-Inferenz für mobile Endgeräte zu betreiben, führe zuerst mein Testprotokoll aus, bevor du bestellst.

KI-Inferenz mit 8 GB RAM

8 GB RAM sind heute die „Torwächter“-Konfiguration für KI-Inferenz auf mobilen Endgeräten – ein quantisiertes 7B-Modell passt gerade noch in den Speicher, aber der eigentliche Engpass ist nicht die Kapazität, sondern die Speicherbandbreite. Im Testprotokoll von CloudWorth wird STREAM zehnmal ausgeführt und der Median gebildet; zusätzlich wird eine Zeitreihenkurve zur Analyse der Volatilität erstellt. Wenn die Triad-Werte stabil über 85 % des Nennwerts liegen, ist keine Drosselung zu befürchten; fallen sie unter 60 %, sollte man überprüfen, ob überbuchte Nachbarn die Bandbreite abgreifen.

Ich pflege, den Prozess als reproduzierbares Bash-Snippet zu schreiben:

# Zuerst Tool installieren, dann STREAM ausführen und jede Runde protokollieren
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
# Volatilität berechnen; über 25 % als 'Bandbreiten-Jitter' markieren
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

Wenn du das durchläufst, wirst du feststellen, dass viele 8-GB-VPS mit der Angabe „DDR4 3200“ nur die Hälfte der Bandbreite einer physischen Maschine erreichen. Das ist keine Mystik – die Diskrepanz zwischen echten Benchmarks und Nennkonfiguration ist oft die Überbuchungsrate. Bei der Auswahl solltest du nicht auf die vom Anbieter angepriesenen „Hochleistungsspeicher“ hören, sondern einen STREAM-Verlauf anfordern.

Außerdem wirkt sich eine unzureichende Bandbreite direkt auf den Inferenzdurchsatz aus: In der Decode-Phase von LLaMA-7B muss jedes Token die Gewichte scannen, halbiert sich die Bandbreite, verdoppelt sich die Latenz des ersten Tokens. Für KI auf 8-GB-Maschinen gilt daher: Lieber eine schlechtere CPU, aber Hauptsache Speicherbandbreite. Aus FinOps-Sicht ist es unrentabel, wenn ein Modell nur 60 % der Nennbandbreite erreicht, aber nur 15 % günstiger ist – die Prämie ist negativ. Umgekehrt ist ein Modell, das die Bandbreite erfüllt und etwas teurer ist, preislich effizienter.

Zum Schluss noch ein Hinweis: Verwechsle nicht die Geschwindigkeit des Festplatten-Caches mit Speicherbandbreite. Viele Anfänger messen mit dd einige GB/s und denken, der Speicher sei schnell, dabei handelt es sich um den Page Cache. Wenn du wirklich testen willst, verwende STREAM oder sysbench und führe in ruhigen Zeiten mehrere Läufe durch, um die Schwankungen zu beobachten. Die konkrete Checkliste findest du unter /guides/cloud-memory-bandwidth-test.

Nennkonfiguration vs. echte Benchmark-Werte

In den Spezifikationstabellen der Cloud-Anbieter steht oft „8GB DDR4 3200“, aber die tatsächliche Speicherbandbreite ist oft überbucht oder gedrosselt. Wenn du STREAM ausführst, siehst du, dass eine Maschine mit Nennwert 25GB/s tatsächlich nur 12GB/s erreicht – das ist kein Einzelfall, sondern die Norm in öffentlichen Clouds. Um zu beurteilen, ob dies dem Standard entspricht, schaue nicht nur auf free -h, sondern achte darauf, ob die Bandbreitenkurve zackige Schwankungen aufweist: Wenn sie stabil auf einem niedrigen Wert bleibt, deutet das auf eine cgroup-Drosselung hin; wenn sie schwankt, könnte es an Nachbarn liegen, die Ressourcen beanspruchen.

Reale Messungen decken Preisaufschläge besser auf als Nennwerte. Bei derselben 8GB-Konfiguration bietet Anbieter A 12GB/s, Anbieter B 20GB/s – B ist die kosteneffizientere Wahl für KI-Inferenz. Ein Modell mit reduzierter Konfiguration (6GB), aber ausreichender Bandbreite ist oft besser für mobile Modelle geeignet als eine Maschine mit nominalen 8GB, die überhöhte Werte aufweist. Es wird empfohlen, mit sysbench oder STREAM drei Stichproben durchzuführen und Spitzen- sowie Durchschnittswerte zu notieren.

Wenn vor dem Kauf ein „Probe-Protokoll“ bereitgestellt werden kann, kann dir CloudWorths Prüfliste echtes Geld sparen – Der Kern von FinOps ist nicht das Kürzen von Konfigurationen, sondern das Entfernen übertriebener Angaben.

FinOps-Prämienraten im Vergleich

Nach den ersten STREAM-Durchläufen kann man sich leicht von den „theoretischen Spitzenwerten“ der Cloud-Anbieter in die Irre führen lassen, wenn man nur die nominelle 8-GB-Speicherbandbreite betrachtet. In meinem CloudWorth-Prüfprozess teile ich die gemessenen Werte von STREAM Copy und Triad durch die nominelle Bandbreite des Tarifs, um eine „Speicherbandbreiten-Erfüllungsrate“ zu erhalten. Wenn zum Beispiel eine 8-GB-VPS nominell 20 GB/s hat, aber tatsächlich nur 8 GB/s gemessen werden, beträgt die Erfüllungsrate 40% – dann muss man überlegen: Ist es Überverkauf (Overselling), Drosselung oder greifen Nachbarn auf die Speichercontroller-Bandbreite zu?

Praktischer ist es, diese Erfüllungsrate in einen FinOps-Aufschlag umzurechnen. Zum Beispiel: Zwei Tarife mit jeweils 8 GB RAM, A kostet 30 Yuan pro Monat und hat eine gemessene Bandbreite von 12 GB/s; B kostet 45 Yuan pro Monat und hat 9 GB/s. Berechnet man die monatlichen Kosten pro GB/s Bandbreite, hat A 2,5 Yuan und B 5 Yuan – B hat eine Aufschlagsrate von satten 100%. Viele günstige VPS scheinen ein gutes Preis-Leistungs-Verhältnis zu haben, aber sobald die Speicherbandbreite gedrosselt wird, sinkt die Token-Generierungsgeschwindigkeit bei KI-Inferenz deutlich, und die Kosten pro Recheneinheit sind am Ende sogar höher.

Bei Speicherbandbreiten-Stresstests protokolliere ich nebenbei auch pidstat und /proc/pressure/memory, um zu unterscheiden, ob es sich um einen echten physischen Bandbreitenengpass handelt oder um einen vorgetäuschten Rückgang durch CPU-Steal auf der Cloud-Plattform. Wenn du die Aufschlagsrate deines Tarifs schnell überprüfen möchtest, findest du in der CloudWorth-Checkliste vorgefertigte STREAM-Skripte und Schwellenwert-Empfehlungen. Achte nicht nur auf den nominellen Speicher – die Bandbreiten-Erfüllungsrate ist der entscheidende harte Indikator für die Auswahl bei KI-Inferenz mit 8 GB RAM.

Empfehlungen für die Migration zu kleineren Konfigurationen

Wenn du auf einem Cloud-Server mit 8 GB RAM KI-Inferenz für mobile Geräte durchführst, darfst du bei der Prüfung der Speicherbandbreite des Cloud-Servers nicht nur auf die Nennwerte schauen. Ich bin auf eine „8-GB“-Instanz gestoßen, bei der STREAM tatsächlich nur 4,2 GB/s beim Copy-Test gemessen hat, während ein Bare-Metal-Server mit derselben Konfiguration 12 GB/s erreichte – das ist kein Overselling, sondern QoS-Drosselung. Vor der Verkleinerung der Konfiguration empfiehlt es sich, mit einer Zeitreihenkurve zunächst 24 Stunden lang die Auslöseschwelle zu beobachten. Wenn z.B. bei über 6 GB/s pro Sekunde die Geschwindigkeit abfällt, bedeutet das, dass der Anbieter die Speicherbandbreite als elastische Ressource behandelt.

Die Verkleinerung der Konfiguration bedeutet nicht einfach, den RAM von 8 GB auf 4 GB zu ändern. Man muss auch die Kopplung von Speicherbandbreite und Disk-Cache-Geschwindigkeit berücksichtigen. Viele kleine VPS-Instanzen mit wenig RAM nutzen NVMe-Cache, um die IO zu stützen, aber wenn die Speicherbandbreite erst einmal begrenzt ist, nützt auch eine noch so hohe Cache-Trefferquote nichts. Ich habe mit sysbench getestet: Nach der Verkleinerung derselben Maschine fiel die Speicherbandbreite von 8 GB/s auf 3 GB/s, und die Inferenzlatenz verdoppelte sich direkt – das gesparte Geld reicht nicht, um das auszugleichen.

Hier gibt es eine Falle beim FinOps-Aufschlagsfaktor: Wenn du öffentliche Clouds und billige VPS vergleichst, schau nicht nur auf den Einzelpreis pro GB RAM. Teile den tatsächlich gemessenen STREAM-Wert durch den Preis, um den „Preis pro Bandbreite“ zu berechnen. Dann wirst du feststellen, dass viele „High-End-Konfigurationen zu niedrigen Preisen“ in Wirklichkeit extrem hohe Aufschläge haben. Vor der Migration zu einer kleineren Konfiguration solltest du die STREAM-Kurve der Zielinstanz 24 Stunden lang mit der aktuellen Instanz vergleichen. Wenn die Bandbreitenschwankung nach der Verkleinerung mehr als 30 % beträgt, empfiehlt es sich, die ursprüngliche Konfiguration beizubehalten oder den Anbieter zu wechseln.

Denk daran: Ob die Speicherbandbreite den Anforderungen entspricht, muss anhand von Kurven beurteilt werden, nicht anhand von Nennwerten. Die Verkleinerung der Konfiguration ist keine Rechenaufgabe, sondern ein Prozess der Beweissicherung. In der ersten Woche nach der Migration solltest du jeden Tag einmal STREAM ausführen und die Anzahl der ausgelösten Throttling-Vorgänge protokollieren. Wenn die Zahl 3 übersteigt, beantrage sofort eine Rückerstattung oder einen Rollback – das ist die praktische Empfehlung von CloudWorth.