Bei einem GPU-Server lässt sich der notwendige System-RAM nicht allein aus der Anzahl der Grafikkarten ableiten. Entscheidend sind der gesamte GPU-Speicher, die Größe von Modellen und Datensätzen, die Datenvorverarbeitung sowie mögliche CPU-Offloading-Verfahren. Als belastbarer Ausgangspunkt gilt: Rechne zuerst den gemeinsamen Grundbedarf des Servers aus und addiere anschließend den RAM-Bedarf je gleichzeitig laufender GPU-Aufgabe. Eine starre Vorgabe wie 128 GB pro GPU kann dagegen sowohl unnötig teuer als auch deutlich zu knapp sein.
Die brauchbare Faustregel richtet sich nach dem GPU-Speicher
Das Verhältnis zum GPU-VRAM ist für die Planung aussagekräftiger als die GPU-Anzahl allein. Zwei GPUs mit jeweils 24 GB Grafikspeicher stellen andere Anforderungen als zwei Beschleuniger mit jeweils 80 GB, selbst wenn auf beiden Servern dieselbe Softwareklasse eingesetzt wird.
Für eine erste Angebotsbewertung kannst du mit folgenden Orientierungsbereichen arbeiten. Sie sind keine garantierten Mindestwerte, sondern Startpunkte für die anschließende Lastprüfung:
- Schlanke Inferenz: ungefähr das Ein- bis Zweifache des gesamten GPU-VRAM als System-RAM, sofern Modell und Laufzeitumgebung weitgehend in den GPU-Speicher passen.
- Training mit Datenvorverarbeitung: häufig etwa das Zwei- bis Vierfache des gesamten GPU-VRAM, wenn mehrere Datenlader, Caches und größere Arbeitspuffer parallel aktiv sind.
- CPU-Offloading oder sehr große Modelle: der Bedarf kann über diesen Bereich hinausgehen, weil Gewichte, Optimierungszustände oder Zwischenergebnisse bewusst in den System-RAM ausgelagert werden.
- Rendering und Transcoding: nicht pauschal über das VRAM-Verhältnis dimensionieren. Anzahl und Größe paralleler Aufträge, Frame-Puffer, Quelldateien und CPU-basierte Verarbeitungsschritte bestimmen hier den Host-RAM stärker.
Bei vier GPUs mit jeweils 24 GB beträgt der gesamte GPU-VRAM 96 GB. Ein Verhältnis von 2:1 ergäbe 192 GB System-RAM. Dieser Wert ist noch keine fertige Empfehlung: Betriebssystem, Dienste und gemeinsam genutzte Komponenten benötigen zusätzlich Speicher, während manche Anwendungen Datenpuffer zwischen den GPU-Prozessen teilen können.
Grundbedarf und GPU-Anteil getrennt berechnen
Ein sinnvoller Rechenweg trennt den festen Speicherbedarf des Hosts von den parallel entstehenden Arbeitslasten. So bleibt sichtbar, ob eine weitere GPU tatsächlich denselben zusätzlichen RAM benötigt oder ob ein Teil der Daten nur einmal im Server vorgehalten wird.
Für die Planung kann folgende Formel verwendet werden:
Benötigter System-RAM = Grundbedarf des Hosts + gemeinsam genutzte Daten + (RAM je GPU-Prozess × Anzahl gleichzeitig aktiver GPU-Prozesse) + Reserve
Alle Größen werden in GB angegeben. Der Grundbedarf umfasst Betriebssystem, Treiber, Überwachung und dauerhaft laufende Dienste. Gemeinsam genutzte Daten werden nur einmal angesetzt. Der Prozessanteil enthält dagegen Speicher, der für jede parallel arbeitende GPU oder jeden Worker erneut belegt wird.
Ein rein hypothetisches Szenario zeigt den Unterschied: Ein Server benötigt 16 GB für Host und Dienste, hält einen gemeinsamen Datencache von 80 GB und startet vier Worker mit jeweils 20 GB RAM-Bedarf. Als Reserve werden 20 Prozent auf den bereits ermittelten Bedarf aufgeschlagen.
Zwischensumme = 16 GB + 80 GB + (20 GB × 4) = 176 GB
Reserve = 176 GB × 0,20 = 35,2 GB
Planungswert = 176 GB + 35,2 GB = 211,2 GB
In diesem Beispiel muss die angebotene Speicherausstattung mindestens oberhalb von 211,2 GB liegen. Eine verfügbare Ausbaustufe von 256 GB böte ausreichend Abstand. Viermal pauschal 128 GB anzusetzen und dadurch 512 GB zu buchen, wäre bei diesem Lastprofil nicht begründet.
Wann viel RAM pro GPU tatsächlich gebraucht wird
Großer System-RAM ist dann wertvoll, wenn die CPU-Seite aktiv an der Datenbereitstellung oder Speicherverwaltung beteiligt ist. Die folgenden Lastmerkmale erhöhen den Bedarf besonders deutlich.
Modellgewichte und Zustände liegen teilweise im Host-Speicher
Passt ein Modell nicht vollständig in den GPU-VRAM, können bestimmte Laufzeitumgebungen Teile davon in den System-RAM auslagern. Beim Training kommen je nach Verfahren weitere Zustände hinzu, etwa Gradienten und Optimierungsdaten. Der Host-Speicher ist dabei kein gleichwertiger Ersatz für VRAM: Übertragungen zwischen RAM und GPU können die Verarbeitung bremsen. Mehr RAM verhindert in diesem Fall zwar einen Speicherabbruch, beseitigt aber nicht automatisch den Datentransfer als Engpass.
Die Datenpipeline arbeitet weit voraus
Mehrere CPU-Worker können Trainingsdaten parallel laden, entpacken, dekodieren und transformieren. Große Warteschlangen und vorab geladene Batches belegen dabei System-RAM, obwohl die eigentliche Berechnung auf den GPUs stattfindet. Verdoppelt sich die Zahl der GPUs, werden oft auch mehr Datenlader eingesetzt. Der Speicherbedarf steigt dann mit der Parallelität, aber nicht zwingend exakt proportional zur GPU-Anzahl.
Mehrere Nutzer teilen sich denselben GPU-Server
Bei getrennten Containern, virtuellen Maschinen oder unabhängigen Aufträgen werden Laufzeitumgebungen, Bibliotheken und Caches möglicherweise mehrfach geladen. Vier kleine Einzelaufträge können deshalb mehr Host-RAM beanspruchen als ein verteilter Auftrag über vier GPUs. Für die Auswahl zählt in diesem Fall die Zahl gleichzeitig aktiver Umgebungen und nicht nur die Zahl der Beschleuniger.
Datensätze oder Indizes sollen im RAM bleiben
Ein In-Memory-Datensatz, ein Vektorindex oder ein großer Cache kann den GPU-bezogenen Bedarf deutlich übersteigen. Dieser Speicheranteil gehört in der Rechnung zu den gemeinsam genutzten Daten. Ihn gleichmäßig durch die GPU-Anzahl zu teilen, eignet sich zwar für eine Kostenkennzahl, darf aber nicht mit dem technisch notwendigen RAM je GPU-Prozess verwechselt werden.
Wann eine hohe RAM-Ausstattung kaum Mehrleistung bringt
Freier Arbeitsspeicher beschleunigt eine GPU nicht von selbst. Wenn Modell, Batch und Laufzeitpuffer in den GPU-VRAM passen, die Daten schnell genug vom lokalen Speicher nachgeladen werden und der Host dauerhaft viel ungenutzten RAM zeigt, führt die nächste Speicherstufe meist nicht zu einer höheren GPU-Auslastung.
Eine teure RAM-Konfiguration ist besonders kritisch zu hinterfragen, wenn der Anbieter mit einer großen Kapazität wirbt, aber wesentliche Eigenschaften offenbleiben:
- Ist der Speicher für den Server garantiert oder wird er in einer virtualisierten Umgebung geteilt?
- Handelt es sich um ECC-RAM, der Speicherfehler erkennen und je nach Implementierung korrigieren kann?
- Ist die angegebene Kapazität vollständig nutzbar oder für Hypervisor und Plattform teilweise reserviert?
- Kann der Tarif später erweitert werden, oder verlangt mehr RAM einen vollständigen Serverwechsel?
- Passen Speicherkanäle und Bestückung zur eingesetzten CPU-Plattform, oder wird Kapazität zulasten der Speicherbandbreite bereitgestellt?
Die letzte Frage ist für datenintensive CPU-Vorverarbeitung relevant. Eine hohe Kapazität mit ungünstiger Speicherbestückung kann weniger hilfreich sein als eine kleinere, zur Plattform passende Konfiguration. Ohne belastbare Hardwareangaben lässt sich aus der GB-Zahl allein kein Leistungsvorteil ableiten.
Mit Messwerten vom Startwert zur passenden Größe
Eine Faustregel liefert eine Bestellgröße für den ersten Test, nicht den endgültigen Beweis. Für eine belastbare Dimensionierung muss die geplante Spitzenlast mit derselben Zahl paralleler Worker, ähnlichen Datensätzen und der vorgesehenen Batch-Größe ausgeführt werden.
- Erfasse den höchsten belegten System-RAM während einer vollständigen Arbeitsphase, nicht nur direkt nach dem Programmstart.
- Prüfe parallel, ob Auslagerungsspeicher genutzt wird, Prozesse wegen Speichermangels beendet werden oder Datenlader ihre Warteschlangen verkleinern müssen.
- Vergleiche die RAM-Spitze mit der GPU-Auslastung. Niedrige GPU-Auslastung bei vollem RAM kann auf eine überlastete Datenpipeline hinweisen; niedrige GPU-Auslastung bei viel freiem RAM hat wahrscheinlich eine andere Ursache.
- Plane Reserve für Lastspitzen, Treiber- und Softwareänderungen sowie einen zusätzlichen Auftrag ein, sofern dieser im normalen Betrieb realistisch ist.
- Wähle die nächste tatsächlich angebotene Speicherausstattung oberhalb des ermittelten Planungswertes.
Die Reserve sollte nicht blind als großer Pauschalaufschlag gewählt werden. Eine gut bekannte, gleichförmige Inferenzlast benötigt weniger Unsicherheitspuffer als wechselnde Trainingsaufträge mehrerer Nutzer. Entscheidend ist, welche Abweichung vom Testbetrieb der Server abfangen soll.
Den Mehrpreis pro nutzbarer Arbeitslast bewerten
Beim Preisvergleich ist der Aufpreis für RAM nur sinnvoll interpretierbar, wenn GPU-Typ, GPU-Anzahl, Prozessor, Vertragszeitraum und Verwaltungsmodell gleich bleiben. Der Preis pro GB kann eine Speicheroption beschreiben, sagt aber wenig darüber aus, ob die zusätzliche Kapazität einen weiteren Auftrag ermöglicht.
Die wirtschaftlichere Kennzahl lautet daher:
RAM-Aufpreis je zusätzlichem Parallelauftrag = monatlicher RAM-Aufpreis ÷ Zahl der dadurch zusätzlich möglichen Parallelaufträge
Angenommen, eine größere Speicherausstattung kostet in einem hypothetischen Angebot 120 Euro mehr pro Monat und ermöglicht nach einem Lasttest zwei zusätzliche parallele Worker. Dann beträgt der Aufpreis 120 Euro ÷ 2 = 60 Euro je zusätzlichem Worker und Monat. Ermöglicht dieselbe Erweiterung keinen weiteren Worker und verkürzt auch keine Verarbeitung, ist der Aufpreis für diese Last nicht durch Mehrleistung gedeckt.
Vor der Bestellung sollten auf der Tarif- oder Angebotsseite außerdem Grundpreis, RAM-Aufpreis, Einrichtungsgebühr, Abrechnungszeitraum und regulärer Folgepreis getrennt geprüft werden. Bei einem dedizierten GPU-Server ist zudem wichtig, ob die Speichererweiterung dauerhaft gebunden ist oder später ohne Plattformwechsel angepasst werden kann.
Eine klare Entscheidung für das passende RAM-Verhältnis
Für eine überwiegend GPU-residente Inferenz ist das Ein- bis Zweifache des gesamten GPU-VRAM ein vernünftiger Prüfstart. Training mit paralleler Vorverarbeitung beginnt eher beim Zwei- bis Vierfachen. Offloading, große In-Memory-Datenbestände und viele voneinander getrennte Nutzerumgebungen verlangen eine eigene Bedarfsrechnung und können deutlich darüber liegen.
Liegt noch keine Messung vor, sollte ein Angebot nicht allein wegen besonders vieler GB bevorzugt werden. Schätze Grundbedarf, gemeinsame Daten und den vervielfachten Prozessanteil getrennt, addiere eine begründete Reserve und prüfe anschließend die nächsthöhere verfügbare Ausbaustufe. So wird System-RAM als Bestandteil der tatsächlichen Arbeitslast bewertet und nicht als isolierte Werbekennzahl.
Häufige Fragen zur RAM-Planung bei GPU-Servern
Ändert GPU-Passthrough den benötigten System-RAM?
GPU-Passthrough verringert den Speicherbedarf der virtuellen Maschine nicht automatisch. Jede VM benötigt eigenen Arbeitsspeicher für Betriebssystem, Treiber und Anwendung. Zusätzlich bleibt RAM für Host beziehungsweise Hypervisor erforderlich. Bei mehreren VMs muss dieser feste Bedarf deshalb mehrfach eingeplant werden.
Muss der gesamte Datensatz in den Arbeitsspeicher passen?
Nein. Viele Datenpipelines lesen nur die jeweils benötigten Batches vom lokalen Speicher. Ein vollständiger RAM-Cache kann Zugriffe beschleunigen, ist aber nur sinnvoll, wenn wiederholtes Einlesen tatsächlich den Durchsatz begrenzt. Bei einmalig durchlaufenen oder sehr großen Datensätzen kann schneller lokaler NVMe-Speicher wirtschaftlicher sein als genügend RAM für den kompletten Datenbestand.
Kann Swap fehlenden System-RAM bei GPU-Aufgaben ersetzen?
Swap kann kurze Lastspitzen abfangen, ist aber kein gleichwertiger Ersatz für physischen RAM. Werden aktive Modellteile, Worker oder Datenpuffer regelmäßig ausgelagert, steigen Latenz und Laufzeit oft deutlich. Dauerhafte Swap-Nutzung unter Normalbetrieb ist daher ein Signal, die RAM-Ausstattung oder die Parallelität der Prozesse anzupassen.
