RAM und VRAM: Ihr Zusammenspiel im KI-Server

Die erste Frage, die Käufer zu einem KI-Server stellen, lautet „wie viele GPUs“. Die zweite: „welche CPU“. Die Frage, die tatsächlich darüber entscheidet, ob die Maschine gut arbeitet – und die in den meisten Datenblättern untergeht –, ist, wie die beiden Speichersysteme im Verhältnis zueinander dimensioniert sind. Eine 4-GPU-Maschine mit 192 GB VRAM und 32 GB Systemspeicher ist kaputt. Dieselbe Maschine mit 1 TB Systemspeicher ist für die meisten Workloads verbranntes Geld. Die richtige Antwort liegt dazwischen und hängt davon ab, was Sie wirklich betreiben.

Dieser Artikel erklärt, welche Aufgaben VRAM und Systemspeicher jeweils übernehmen, wie sie zusammenhängen, wo die Bandbreiten-Engpässe sitzen und welche Verhältnisse sich in der Praxis bewähren. Er richtet sich an Käufer und Integratoren, die eine Konfiguration auslegen – nicht an Entwickler, die CUDA-Kernels schreiben.

Was im VRAM tatsächlich liegt

Wenn ein Modell „auf der GPU geladen“ ist, liegen drei Dinge im VRAM:

1. Modellgewichte. Ein 70B-Modell belegt in FP16 140 GB, in INT8 70 GB und in INT4 – der üblichen Quantisierung für den Eigenbetrieb – je nach Quantisierungsverfahren 35–40 GB.
2. KV-Cache. Der Speicherbedarf der Attention pro Anfrage. Ein 70B-Modell mit 8K Kontext im Einzelstream benötigt 1–2 GB, bei 32K sind es 4–8 GB. Im Batch-Betrieb (10–20 gleichzeitige Anfragen) füllt dieser Cache Ihren verbleibenden VRAM – nicht die Gewichte.
3. Aktivierungen und Workspace. Zwischenergebnisse des Forward Pass, Attention-Scratch, Kernel-Workspace. Für Inferenz sind das wenige GB, beim Training deutlich mehr, weil die Aktivierungen für den Backward Pass vorgehalten werden.

Beim Training kommen Optimizer-State (Adam hält zwei FP32-Werte pro Gewicht – rund das 8-Fache der FP16-Gewichtsgröße) und Gradienten (1× Gewichtsgröße) hinzu. Genau deshalb erfordert das Training eines 70B-Modells von Grund auf Nodes mit 8× H100 oder A100 80 GB – und ist nichts, was eine Kentino-Maschine leistet. Fine-Tuning mit LoRA oder QLoRA ist eine andere Geschichte und läuft bequem auf einem Build mit 4 GPUs vom Typ 5090 oder Pro 6000 Blackwell.

Praktische Konsequenz: Die Modellgröße im VRAM ist nicht einfach „Parameter × Bytes pro Parameter“. Für den Betrieb eines 70B-Modells in INT4 mit 8K Kontext kalkulieren Sie 40 GB Gewichte + 20–40 GB KV-Cache bei realistischem Batch + 4 GB Overhead = rund 70 GB. Das passt auf eine einzelne RTX Pro 6000 Blackwell Server Edition (96 GB) oder erfordert 3–4 RTX 5090, wenn der Batch eine vernünftige Größe haben soll. „VRAM gesamt“ zählt weniger als „VRAM pro Karte und wie die Karten verbunden sind“.

VRAM-Bandbreite: die Zahl, die über die Token-Geschwindigkeit entscheidet

Die Token-Generierung eines Transformer-LLM ist bandbreiten- und nicht rechenlimitiert. Jeder erzeugte Token liest das gesamte Modell über den Speicherbus aus dem VRAM. Der TFLOPS-Wert aus dem Datenblatt ist für die Inferenz weitgehend belanglos; entscheidend sind die GB/s Speicherbandbreite.

Kentino verkauft weder H100 noch H200; sie stehen hier nur zum ehrlichen Vergleich. Sie bleiben die Bandbreiten-Könige und der Grund, warum Hyperscaler sie kaufen. Der Preisunterschied beträgt das 6- bis 10-Fache, der Bandbreitenvorsprung bei Einzelstream-Inferenz das 2-Fache. Für Workloads außerhalb der Hyperscaler-Welt geht diese Rechnung nicht zugunsten von HBM auf.

Eine Faustregel für die Token-Generierung im Einzelstream unter INT4: tok/s ≈ Bandbreite (GB/s) / Modellgröße (GB), multipliziert mit einem Stack-Effizienzfaktor von 0.6–0.8. Ein 70B-Modell in INT4 (~40 GB) auf einer einzelnen 5090:

1790 GB/s × 0.7 / 40 GB ≈ 31 tok/s (Einzelstream, ohne Batching)

Das deckt sich mit unseren Messungen auf der Testbank. Batching hebt den Gesamtdurchsatz auf 50–100 tok/s, die Geschwindigkeit pro Stream bleibt jedoch nahe an der Bandbreitengrenze. Kein noch so großer Systemspeicher ändert an dieser Zahl etwas.

ECC-VRAM: beim Training wichtig, bei der Inferenz weniger

Die Reihe RTX Pro 6000 Blackwell führt ECC-VRAM (mit Fehlerkorrektur). Consumer-Karten (5090, 4090) nicht. Das Marketing lässt das zwingend klingen; in Wirklichkeit ist die Sache differenzierter.

ECC-VRAM erkennt und korrigiert Einzelbitfehler im laufenden Betrieb. Ohne ECC pflanzt sich ein Bitfehler fort – bei der Inferenz meist unbemerkt (ein Token fällt geringfügig anders aus), beim Training gelegentlich verheerend (NaN-Ausbreitung, Divergenz, abgestürzter Lauf).

Wann ECC zählt:

• Langlaufendes Training. Über mehrtägige Jobs hinweg macht das Speicheraufkommen einen stillen Bitfehler zu einer realen Wahrscheinlichkeit. Einen 48-Stunden-Lauf durch einen unentdeckten Fehler zu verlieren, ist weit schlimmer, als ihn korrigiert zu bekommen.
• Numerische Workloads ohne menschliche Kontrolle. Simulation, Modellierung, alles, was ohne Plausibilitätsprüfung weiterverarbeitet wird.
• Regulierte Workloads. Verlangt Ihr Compliance-Regime bitgenaue Reproduzierbarkeit, ist ECC Pflicht.

Wann ECC weitgehend Kosmetik ist:

• LLM-Inferenz im Serving-Betrieb. Die Bitfehlerrate von modernem GDDR7 ist so niedrig, dass die Auswirkung auf die Ausgabequalität unter dem Rauschen liegt. Wir betreiben Consumer-5090-Karten seit Monaten unter hoher Inferenzlast, ohne Auffälligkeiten zu sehen, die sich auf VRAM-Fehler zurückführen ließen.
• Bild- und Videogenerierung. Die wahrnehmbare Rauschschwelle schluckt einen Einzelbitfehler.
• Entwicklung und Experimente. Neustart und erneuter Lauf kosten wenig.

Ehrlich gesagt: Liegt der Schwerpunkt auf Inferenz, bezahlen Sie den Aufpreis der Pro 6000 für 96 GB VRAM und validierte Treiber – nicht für ECC. Liegt er auf Training, rechtfertigt ECC seinen Preis. Wir verkaufen beides und sagen Ihnen am Telefon dasselbe.

Systemspeicher: wie viel – und die Wahrheit über CPU-Offload

Der Systemspeicher erfüllt in einem KI-Server vier Aufgaben:

1. Er puffert das Laden des Modells von der Platte in den VRAM. Eine 70B-Modelldatei wandert von NVMe → Page Cache → Systemspeicher → VRAM. Ist der Systemspeicher kleiner als die Datei, schlägt das Laden fehl oder es kommt zum Thrashing.
2. Er trägt das Betriebssystem, den Inferenzserver (vLLM, llama.cpp, Triton) und Hilfsdienste (Vektordatenbank, Monitoring, Request-Queue).
3. Er hält Tokenizer-State, Request-Queues sowie Puffer für Vor- und Nachverarbeitung.
4. Optional beherbergt er auf die CPU ausgelagerte Layer. Diesen Punkt überschätzen viele.

CPU-Offload erlaubt es in llama.cpp und ähnlichen Runtimes, ein Modell zu betreiben, das größer als der VRAM ist: Einige Layer bleiben auf der CPU und werden pro Token durch die GPU gestreamt. Das funktioniert. In nahezu jedem realistischen Fall ist es aber auch eine Übung in Leidensfähigkeit.

Die Zahlen: Eine 5090 bietet 1.79 TB/s VRAM-Bandbreite. Eine EPYC-Genoa-Plattform mit 12 Kanälen und DDR5-4800 liefert aggregiert rund 460 GB/s. CPU-Offload ist pro Token optimistisch gerechnet 4- bis 6-mal langsamer als vollständige VRAM-Residenz – und das unter der Annahme perfekter NUMA-Lokalität und einer CPU, die nicht zugleich mit dem Serving-Overhead beschäftigt ist.

Benchmarks auf einer 4×5090-Maschine mit abgestimmtem --n-gpu-layers :

• Vollständig auf der GPU (70B INT4 über 4×24 GB): 28–32 tok/s im Einzelstream.
• 80 % auf der GPU, 20 % auf der CPU: 6–9 tok/s.
• 50/50: 2–4 tok/s.

Das ist keine Meinung von Kentino, sondern schlicht das Verhältnis von DDR5- zu GDDR7-Bandbreite. Die Lösung für „das Modell passt nicht in den VRAM“ heißt mehr oder bessere GPUs – nicht Systemspeicher mit Offload. Die Ausnahme ist die Unified-Memory-Plattform AMD Ryzen AI Max 300, ein ganz anderes Kaliber und hier nicht Thema.

Kaufen Sie genug Systemspeicher zum Laden und Ausliefern, nicht zum Rechnen.

Wie viel Systemspeicher konkret

Eine bewährte Regel für KI-Builds von Kentino:

Systemspeicher ≈ 1.5 × gesamter VRAM, aufgerundet auf die nächste Standardkonfiguration.

Für einen 4-GPU-Build:

Bei 8-GPU-Builds skaliert der Speicher nicht streng linear – bleiben Sie nach Möglichkeit innerhalb der Kanäle eines Sockels. Standardmäßig setzen wir 256 GB bei 8× 5090 und 512 GB bei 8× Pro 6000 Blackwell.

Die Regel hat an den Rändern zwei Fehlerbilder:

• Unterdimensioniert: 64 GB in einer 8-GPU-Maschine. Das Modell lädt langsam, der Page Cache kann die Gewichte für einen schnellen Neustart nicht halten, und paralleles Serving samt Hilfsdiensten (pgvector, Monitoring) beginnt zu swappen.
• Überdimensioniert: 2 TB in einer 4-GPU-Inferenzmaschine. Das läuft einwandfrei, aber Sie haben €4,000–€8,000 für Speicher ausgegeben, der Luft verwaltet. Die Ausnahme: Sie hosten viele Modelle und rotieren sie zwischen VRAM und RAM – dann wirkt viel Systemspeicher als Hot Cache. Außerhalb von Forschungslaboren selten.

Den Fall „64 GB reichen“ gibt es: eine 2-GPU-Maschine, ein Modell zur Zeit, keine Parallelität, keine Hilfsdienste. Kein ernstzunehmender Server, aber eine ernstzunehmende Entwickler-Workstation.

EPYC-Kanäle: woher die Bandbreite wirklich kommt

Die Systemspeicher-Bandbreite bei AMD EPYC – der Basis nahezu all unserer 8-GPU-Server – skaliert mit der Zahl der belegten Speicherkanäle, nicht mit der DIMM-Taktrate auf dem Datenblatt. Die Kanäle liegen pro Sockel vor und werden mit einem DIMM je Kanal bestückt.

Zwei Erkenntnisse aus dieser Tabelle:

1. Belegen Sie alle zwölf Kanäle einer EPYC-Genoa-/Turin-Plattform, um die angegebene Bandbreite zu erreichen. Acht DIMMs in einem Zwölf-Kanal-System liefern die Bandbreite von acht Kanälen, nicht von zwölf. Diese Fehlkonfiguration begegnet uns im Feld ständig.
2. Die DIMM-Anzahl bestimmt die sinnvolle Mindestkapazität. 12 × 16 GB = 192 GB. 12 × 32 GB = 384 GB. Die „Sparkonfigurationen“, die nur teilweise bestücken (sechs 32-GB-DIMMs für 192 GB), verschenken die halbe Bandbreite. Tun Sie das nicht.

Zwei Sockel ergeben insgesamt 24 Kanäle; die Bandbreite verdoppelt sich in der Summe – aber nur, wenn der Workload NUMA respektiert.

NUMA: was es kostet, die Grenze zu überschreiten

Ein EPYC-Server mit zwei Sockeln besitzt zwei CPU-Dies, jedes mit eigenen Speichercontrollern, DIMM-Slots und eigenem PCIe-Root-Complex. Wer vom Speicher des einen Sockels auf die GPU des anderen zugreift, durchquert die Infinity Fabric – schnell, aber nicht so schnell wie der lokale Weg.

Grobe, aber brauchbare Zahlen:

Bei der Inferenz bleibt der NUMA-Aufschlag meist unsichtbar – sobald das Modell im VRAM liegt, ist der Verkehr zum Systemspeicher nur noch ein Rinnsal. NUMA zählt dann, wenn:

• Ein Modell geladen wird. Ein 100-GB-Ladevorgang vom falschen Node dauert spürbar länger. Binden Sie ihn mit numactl oder setzen Sie die Affinität in Ihrer Container-Runtime.
• CPU-seitige Vorverarbeitung ansteht (Tokenisierung im großen Stil, Bilddecodierung, Audio-Resampling). Ein ausgelasteter Tokenizer auf Sockel 0, dessen GPUs an Sockel 1 hängen, verliert 20–40 % Durchsatz.
• Training mit auf die CPU ausgelagertem Optimizer-State läuft (DeepSpeed Zero-Offload). NUMA-fremder State verdoppelt die Schrittzeit. Pinnen Sie alles.

Die praktische Antwort: Für Inferenzserver ist ein Sockel der Standard , sofern Sie keinen konkreten Grund für zwei haben. Zwei Sockel gibt es in unserem Programm (Kentino AI 256 Turin Dual), weil manche Workloads – gleichzeitiges Training und Inferenz, große In-Memory-Vektorspeicher, acht GPUs mit Bedarf an zwei Root-Complexes – sie tatsächlich brauchen. Die meisten nicht. Ein Single-Socket-Turin mit 12 Kanälen und 384–512 GB deckt die meisten Inferenzszenarien ab.

DDR5 RDIMM oder LRDIMM – und ECC

Serverspeicher ist 2026 durchgängig DDR5 mit ECC. Die Wahl liegt zwischen RDIMM und LRDIMM:

• RDIMM (Registered): Standard-Serverspeicher, gepufferter Kommandopfad, ECC inklusive. Sauber bis 64-GB-Module, auf manchen Plattformen bis 128 GB.
• LRDIMM (Load-Reduced): ergänzt einen Speicherpuffer, der die Buslast senkt und höhere Kapazitäten pro Kanal ermöglicht. Für Module ab 128 GB erforderlich. Etwas höhere Latenz, in realen Workloads marginal.

Kentino-Standard: 32-GB- oder 64-GB-RDIMMs mit DDR5-4800 (Genoa) oder DDR5-6000 (Turin). LRDIMM nur, wenn der Build 1 TB oder mehr verlangt – außerhalb von Training oder Multi-Modell-Hosting selten. ECC ist nicht verhandelbar: Server-DIMMs ohne ECC gibt es in den Plattformen, die wir ausliefern, schlicht nicht.

Was schiefgeht, wenn der Speicher falsch ausgelegt ist

Die typischen Fehlerbilder, grob nach Häufigkeit:

• Langsames Modell-Laden bei zu wenig RAM. Ein 70B-Modell belegt rund 40 GB auf der Platte. Mit 32 GB Systemspeicher läuft der Page Cache ins Thrashing, und aus 40 Sekunden Kaltstart werden 4 Minuten. Abhilfe: mindestens das 1.5-Fache des gesamten VRAM.
• Halbierte Bandbreite durch teilbestückte DIMM-Kanäle. Sechs DIMMs in einem Zwölf-Kanal-EPYC. CPU-gebundene Vorverarbeitung halbiert sich lautlos. Abhilfe: alle Kanäle belegen.
• NUMA-fremde Zugriffe auf Dual-Socket-Systemen mit falscher Affinität. Abhilfe: numactl --cpunodebind=0 --membind=0oder der NUMA-bewusste Modus Ihres Frameworks.
• OOM bei hohem Batch durch unterschätzten KV-Cache. Mit --gpu-memory-utilization 0.9 lässt vLLM 10 % Reserve, doch 64 gleichzeitige Anfragen bei 32K Kontext sprengen eine 24-GB-Karte trotzdem. Abhilfe: kürzerer Kontext, kleinerer Batch oder mehr VRAM.
• CPU-Offload „rettet“ den Build und ruiniert den Durchsatz. „Der Server ist langsam“ – und es stellt sich heraus, dass 30 % der Layer auf der CPU liegen, weil der VRAM knapp war. Ein Auslegungsfehler, kein Tuning-Problem. Kaufen Sie von Anfang an die richtige Anzahl GPUs.

Nichts davon ist exotisch. Alles taucht im ersten Monat nach einer Neuinstallation auf.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Computing, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen sind willkommen unter info@kentino.com.