CPU, RAM und Storage für einen KI-Server mit 4 GPUs: CPU-Kerne pro GPU, Arbeitsspeicher vs. VRAM, NVMe oder NAS

CPU, RAM und Storage für 4 GPUs: die veröffentlichten Verhältnisse

Ein KI-Server mit 4 GPUs braucht mindestens 24 physische CPU-Kerne, Arbeitsspeicher (System-RAM) von mindestens dem Doppelten seines gesamten GPU-Speichers und ein NVMe-Laufwerk mit 1 TB oder mehr je CPU-Sockel. Das sind die Ausgangswerte in NVIDIAs Konfigurationsleitfaden für NVIDIA-Certified Systems, zuletzt aktualisiert am 30. September 2026. Für vier RTX PRO 6000 Server Edition mit 96 GB bedeutet das 768 GB RAM, für vier H200 NVL mit 141 GB 1.128 GB. NVIDIA stellt diese Werte als Ausgangspunkt dar, der an den Workload anzupassen ist, und seine Referenzarchitektur und die DGX-Systeme setzen die Verhältnisse anders an.

NVIDIA-Certified Systems Configuration Guide (30. September 2026); NVIDIA Enterprise Reference Architecture for RTX PRO AI Factory, Komponenten, geschrieben für einen RTX PRO Server mit acht GPUs (18. Mai 2026); Benutzerhandbuch DGX H100/H200 (26. Januar 2026) und Benutzerhandbuch DGX B300 (5. Oktober 2026); Intels Spezifikation des Xeon 6776P (64 Kerne). GPU-Speicher des DGX B300: 2,3 TB im Benutzerhandbuch, 2,1 TB auf der Produktseite. Die DGX-Werte je GPU sind unsere Division durch acht.

Beide DGX-Systeme sind SXM-Systeme mit acht GPUs für Training und Inferenz, ein PCIe-Server mit vier Karten liegt also am unteren Ende jeder Spalte.

Arbeitsspeicher vs. VRAM: was jeder Speicher hält

VRAM, der Speicher auf der GPU, hält, womit die GPU rechnet: die Modellgewichte, den KV-Cache der aktiven Gespräche und die Aktivierungen. Der Arbeitsspeicher des Systems hält alles darum herum. Auf einem LLM-Server sind das das Betriebssystem, die Prozesse der Serving-Engine, die Modelldateien auf dem Weg zu den Karten und Transferpuffer; bei einem RAG-Server kommen die Vektordatenbank, der Dokumentparser und das Gateway hinzu. Den GPU-Speicher je Modell und Nutzerzahl dimensioniert unser Artikel KI-Server kaufen: was Sie vor dem Angebot festlegen.

vLLM bildet safetensors-Gewichte standardmäßig per Memory-Mapping ab, die Dateien laufen also durch den Page Cache von Linux. Solange freier Speicher es zulässt, bleiben sie dort, und ein Neustart oder eine zweite Kopie desselben Modells auf der nächsten Karte kann sie aus dem RAM lesen statt vom Datenträger oder über das Netzwerk.

In der vLLM-Dokumentation, Stand Oktober 2026, legen zwei Einstellungen GPU-Daten gezielt in den Systemspeicher. --cpu-offload-gb reserviert die angegebene Zahl an GiB je GPU für Modellgewichte; das ist ein Notbehelf für ein Modell, das nicht auf die Karten passt, und keine Zielgröße für die Dimensionierung. --kv-offloading-size legt einen Puffer in GiB für KV-Cache-Blöcke fest, summiert über alle Tensor-Parallel-Ranks, damit zurückkehrende Gespräche ihren Cache im RAM finden, statt ihn neu zu berechnen. Wann sich das lohnt, behandelt unser Artikel zur Auslagerung des KV-Cache in CPU-Speicher und NVMe; hier zählt der Puffer zum RAM-Budget.

Wie viele CPU-Kerne pro GPU

Die Serving-Engine setzt die Untergrenze. vLLMs Tuning-Leitfaden zählt einen API-Server-Prozess, einen Engine-Core-Prozess und einen Worker-Prozess je GPU, ein Server mit N GPUs braucht also mindestens 2 + N physische Kerne. Für datenparalleles Serving gibt der Leitfaden das Minimum als A + DP + N an, plus eins, wenn DP größer als eins ist, wobei A die Zahl der API-Server ist (standardmäßig gleich DP) und N die Gesamtzahl der GPUs. Vier datenparallele Kopien auf vier Karten brauchen deshalb 13 physische Kerne, oder 10 mit einem API-Server. Vier getrennte Instanzen hinter einem Load Balancer brauchen 12. Der Leitfaden warnt: „Eine Unterversorgung mit CPU-Kernen ist eine häufige Ursache für Leistungseinbußen, insbesondere in virtualisierten Umgebungen.“

NVIDIAs Werte lassen Platz für den Rest des Hosts. Der Leitfaden für zertifizierte Systeme verlangt sechs physische Kerne je GPU, 24 für vier Karten. Die RTX-PRO-Referenzarchitektur, geschrieben für einen Server mit acht GPUs, verlangt sieben je GPU, zwei weitere je GPU für das Betriebssystem oder die Virtualisierung und zwei je MIG-Instanz; vier Karten kommen damit auf 36 Kerne, auf Bare Metal oder in virtuellen Maschinen, noch vor jeder MIG-Partitionierung. Die zusätzlichen Kerne bedienen Tokenisierung, Dokumentparsing für RAG, die Vektordatenbank, Monitoring-Agenten und beim Fine-Tuning die Worker des Data Loaders.

PCIe-Lanes und Speicherkanäle: ein Sockel oder zwei

Vier GPUs mit Gen5 x16 belegen 64 PCIe-Lanes. Ein Prozessor der Serie AMD EPYC 9005 hat 128, ein Sockel allein hat also auch die Lanes für vier NVMe-Laufwerke mit x4 und zwei Netzwerkkarten mit x16, insgesamt 112 Lanes. NVIDIAs RTX-PRO-Referenzarchitektur akzeptiert einen CPU-Sockel als Minimum, während der Leitfaden für zertifizierte Systeme von zwei ausgeht. In einem EPYC-Server mit zwei Sockeln verbindet ein Teil der Lanes jedes Prozessors die beiden Sockel, und AMD nennt insgesamt bis zu 160 Lanes für Geräte; der Artikel wie viele GPUs in einen Server passen erklärt das Lane-Budget für größere Aufbauten.

Ein zweiter Sockel bringt weitere Speicherkanäle und Platz, um Geräte neben jedem Prozessor anzuordnen. Jeder EPYC-9005-Sockel hat bis zu 12 DDR5-6400-Kanäle, und die Referenzarchitektur verlangt mindestens ein DIMM in jedem Kanal, gleichmäßig über die Sockel verteilt. Zwei Sockel ergeben 24 Kanäle; 24 DIMMs mit 32 GB ergeben damit 768 GB und 24 mit 64 GB 1.536 GB. NVIDIAs Untergrenze von 128 GB je GPU, 512 GB für vier Karten, füllt mit 32-GB-Modulen nur 16 der 24 Kanäle. NVIDIAs Leitfaden verlangt außerdem, die GPUs gleichmäßig über Sockel und Root Ports zu verteilen, und „Netzwerkkarten und NVMe-Laufwerke“ sollen „am selben PCIe-Switch oder Root Complex wie die GPUs“ sitzen. In einem Server mit vier Karten bedeutet das zwei GPUs, eine Netzwerkkarte und die Datenlaufwerke neben jedem Prozessor, sodass eine GPU ihre Daten liest, ohne die Verbindung zwischen den Sockeln zu durchlaufen.

Lokales NVMe oder NAS für Modellgewichte und Datensätze

Lokale Laufwerke halten, was die Karten gerade nutzen; ein NAS oder eine NFS-Freigabe hält, was mehrere Server nutzen oder was den Ausfall eines Servers überstehen muss.

Die Untergrenzen sind unsere Rechnung aus den Verbindungsraten: Eine Gen5-x16-Verbindung überträgt etwa 64 GB/s je Richtung, x4 also etwa 16 GB/s; Leitungsraten von 25 und 100 GbE geteilt durch acht. Der Overhead von Laufwerk und Dateisystem verlängert diese Zeiten. Checkpoint: NVIDIAs Llama 3.3 70B FP8 auf Hugging Face.

Ziehen vier Server gleichzeitig einen Checkpoint, teilen sie sich den Uplink des NAS; Inferenzserver halten die Modelle, die sie bereitstellen, deshalb auf lokalem NVMe und holen neue Versionen aus dem Repository. Fine-Tuning liest seinen Datensatz wiederholt und schreibt große Checkpoints, es braucht also eine lokale Scratch-Ebene.

NVIDIAs GPUDirect Storage liest per DMA vom Storage in den GPU-Speicher und „vermeidet einen Bounce-Buffer über die CPU“. Die vLLM-Dokumentation beschreibt einen darauf aufbauenden Lader für Gewichte, die Bibliothek fastsafetensors.

NVIDIAs DGX H200 legt sein Betriebssystem auf zwei NVMe-Laufwerke mit 1,92 TB in RAID 1 und seine acht Datenlaufwerke mit 3,84 TB in RAID 0, gekennzeichnet als Datencache. Dieselbe Aufteilung passt zu einem Server mit 4 GPUs, wobei der Cache Kopien hält, deren Originale auf dem gemeinsamen Storage liegen. Ist die lokale Modellablage die einzige Kopie, legen Sie sie auf RAID 1 oder RAID 10 und halten Sie eine Kopie mit Prüfsummen außerhalb des Servers, wie unter Backup eines KI-Servers beschrieben.

Wir bauen KI-Server mit Scratch-, Modell- und Index-Ebenen auf NVMe-Laufwerken für Rechenzentren. Beschreiben Sie im Formular unten, wo Ihre Modelle und Datensätze heute liegen, und wir legen die lokalen Ebenen und die Netzwerkanbindung an Ihren Storage aus.

Rechenbeispiel: Server mit 4 GPUs für Inferenz und Fine-Tuning

Der Inferenzserver betreibt einen Assistenten mit RAG für 500 Beschäftigte auf Qwen3-32B in FP8, eine Kopie je RTX PRO 6000 Server Edition hinter einem Load Balancer. Mit einem FP8-Cache hält jede Karte nach der Dimensionierungsregel unseres Kaufleitfadens 51 gleichzeitige Sitzungen mit vollem 8K-Kontext, 204 für den Server. Fünfhundert Personen mit Zugang erzeugen weit weniger gleichzeitige Generierungen, und die Logs der Hauptgeschäftsstunde aus einem Pilotprojekt zeigen, ob 204 genügen. Zwei Prozessoren mit je 32 Kernen decken die 12 Kerne von vier vLLM-Instanzen, die 36 der Referenzarchitektur und die RAG-Dienste ab. Mit 768 GB RAM, dem Doppelten des GPU-Speichers, ist jeder Kanal mit einem 32-GB-DIMM belegt, und es bleibt Platz für den Page Cache, den Vektorindex und einen KV-Offload-Puffer für einen Teil der Nutzer. Um alle 500 Gespräche im CPU-Speicher warm zu halten, braucht es einen Puffer von 500 GiB; für diesen Fall plant unser Leitfaden zur Auslagerung des KV-Cache deshalb etwa 1 TB, 24 DIMMs mit 48 GB.

Der Fine-Tuning-Server betreibt vier H200 NVL an einer 4-Wege-NVLink-Bridge, 564 GB GPU-Speicher, für ein vollständiges Fine-Tuning von Llama 3.3 70B mit seinen 70,6 Milliarden Parametern. Das ZeRO-Paper rechnet für Mixed-Precision-Training mit Adam 16 Byte je Parameter. Das sind 2 Byte für die 16-Bit-Gewichte, 2 für die Gradienten und 12 für die Optimiererzustände, eine FP32-Kopie der Gewichte plus Momentum und Varianz. Für dieses Modell sind das etwa 1.130 GB, doppelt so viel, wie die vier Karten fassen. DeepSpeeds ZeRO-Offload „lagert den Speicher und die Berechnung des Optimierers von der GPU auf die Host-CPU aus“. Sein Paper hält die 16-Bit-Gewichte auf den GPUs und verschiebt die FP32-Modellzustände und die 16-Bit-Gradienten in den CPU-Speicher, 14 Byte je Parameter oder hier etwa 990 GB. ZeRO Stufe 3, mit der DeepSpeed dieses Offload ebenfalls erlaubt, verteilt die 141 GB der 16-Bit-Gewichte auf die vier Karten. Nach unserer Rechnung hat auch ein fortsetzbarer Checkpoint, die 16-Bit-Gewichte plus die Optimiererzustände, etwa 990 GB. Ein LoRA-Lauf hält die Basisgewichte eingefroren und braucht einen Bruchteil dieses Speichers.

Unsere Konfiguration für die beiden Workloads oben, aufgebaut aus NVIDIAs Leitfaden und Referenzarchitektur, den CPU-Vorgaben von vLLM, AMDs Datenblatt zur EPYC 9005 und den Speicherrechnungen der Papers zu ZeRO und ZeRO-Offload; die Netzwerkzeilen folgen unserem 70B-Rechenbeispiel und NVIDIAs Leitfaden.

Der Fine-Tuning-Server bekommt mehr Kerne, weil ZeRO-Offload den Optimiererschritt auf den Prozessoren ausführt. Den Fall mit zwei Karten, einem Prozessor und mindestens dem gesamten GPU-Speicher rechnet unser Beispiel eines GPU-Servers für ein 70B-Modell durch.

Wir legen den Speicher auf den GPU-Pool aus und prüfen Rack, Strom und Luftstrom vor dem Angebot. Schicken Sie uns die Karten, die Modelle und Ihre Spitze gleichzeitiger Sitzungen über das Formular unten, und Konfiguration und Angebot folgen innerhalb eines Werktages.

Was wir liefern

Wir bauen KI-Server auf Bestellung rund um den Workload, mit Prozessoren AMD EPYC oder Intel Xeon Scalable, DDR5-ECC-Speicher, NVMe-Laufwerken für Rechenzentren für die Scratch-, Modell- und Index-Ebenen und Netzwerkkarten mit 25 bis 400G, montiert und im Burn-in getestet. Der Inferenz-Knoten auf dieser Seite beginnt bei 512 GB, NVIDIAs Untergrenze von 128 GB je GPU; der Workload oben braucht 768 GB, mit der KV-Ebene etwa 1 TB. Die Karten in diesem Artikel, die RTX PRO 6000 Server Edition und die H200 NVL mit NVLink-Bridges, gehören zu den professionellen NVIDIA-GPUs, die wir liefern, mit Herstellergarantie auf jede Komponente unter einem EU-Vertrag und auf einer Rechnung. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch.

FAQ