Du möchtest ein Sprachmodell lokal starten.
Die Modelldatei ist heruntergeladen.
Die Grafikkarte ist schnell.
Genügend Arbeitsspeicher ist ebenfalls vorhanden.
Trotzdem erscheint eine Fehlermeldung:
Out of memory
Oder das Modell läuft zwar, aber viel langsamer als erwartet.
Der Grund liegt häufig in einer Ressource, die bei klassischen PC-Käufen vergleichsweise wenig Aufmerksamkeit bekommt:
VRAM.
VRAM steht für Video Random Access Memory.
Auf Deutsch kann man vereinfacht sagen:
Grafikspeicher.
Er befindet sich auf beziehungsweise unmittelbar an der Grafikkarte und dient der GPU als schneller Arbeitsspeicher.
Bei Spielen liegen dort beispielsweise:
Texturen,
Geometriedaten,
Framebuffer
und andere Grafikdaten.
Bei künstlicher Intelligenz werden stattdessen unter anderem gespeichert:
Modellgewichte
KV-Cache
temporäre Tensoren
Zwischenergebnisse
Batch-Daten
Dadurch wird VRAM zu einer der wichtigsten Größen für lokale KI.
VRAM und RAM sind nicht dasselbe
Ein klassischer PC mit diskreter Grafikkarte besitzt zwei getrennte Speicherbereiche.
CPU
↓
System-RAM
und:
GPU
↓
VRAM
Angenommen, dein Rechner besitzt:
64 GB RAM
und:
16 GB VRAM
Dann besitzt die GPU nicht automatisch Zugriff auf einen gemeinsamen schnellen Speicherpool von:
80 GB
Das Modell kann zwar abhängig von Software und Hardware teilweise im System-RAM liegen.
Aber Daten im normalen RAM müssen über die Verbindung zwischen CPU-System und GPU übertragen beziehungsweise dort verarbeitet werden.
Das ist typischerweise deutlich langsamer als ein Modell, das vollständig im Grafikspeicher der GPU liegt.
Warum ist VRAM bei KI so entscheidend?
Ein großes Sprachmodell besitzt Milliarden trainierter Parameter.
Diese Parameter müssen während der Inferenz verfügbar sein.
Vereinfacht:
Modell
↓
Milliarden Zahlen
↓
Speicher
Wenn diese Zahlen vollständig im VRAM liegen:
GPU
↓
direkter Zugriff auf Modellgewichte
kann die GPU sie mit hoher Speicherbandbreite verarbeiten.
Passt das Modell nicht vollständig hinein:
GPU
↕
RAM
muss möglicherweise zwischen verschiedenen Speicherbereichen gearbeitet werden.
Das kann die Geschwindigkeit stark beeinträchtigen.
VRAM entscheidet deshalb zunächst über die Modellklasse
Bevor gefragt wird:
Wie schnell ist meine Grafikkarte?
muss häufig geklärt werden:
Passt das gewünschte Modell überhaupt sinnvoll darauf?
Eine extrem schnelle Grafikkarte mit:
8 GB VRAM
kann bei großen Modellen früher an eine Grenze stoßen als eine langsamere Karte mit:
24 GB VRAM
Die erste Karte kann innerhalb ihrer Speichergrenze schneller sein.
Die zweite kann aber überhaupt erst Modelle aufnehmen, die auf der ersten nicht vollständig laufen.
Kapazität und Geschwindigkeit sind zwei verschiedene Eigenschaften
Eine GPU besitzt unter anderem:
Rechenleistung
und:
VRAM-Kapazität
sowie:
Speicherbandbreite
Für lokale KI sind alle drei wichtig.
Zuerst muss das Modell in die gewünschte Speicherarchitektur passen.
Danach entscheidet die Leistung darüber, wie schnell es läuft.
Was benötigt bei einem Sprachmodell VRAM?
Die erste und größte Komponente sind häufig die Modellgewichte.
Dazu kommen weitere Bereiche.
Vereinfacht:
VRAM-Bedarf
=
Modellgewichte
+
KV-Cache
+
temporäre Laufzeitdaten
+
Batch / parallele Anfragen
+
Reserve
Deshalb reicht es nicht, einfach die Dateigröße eines Modells mit dem vorhandenen Grafikspeicher zu vergleichen.
Was sind Modellgewichte?
Unter Sprachmodelle haben wir gesehen, dass ein Modell aus sehr vielen trainierten Parametern besteht.
Beispielsweise ungefähr:
8 Milliarden Parameter
oder:
32 Milliarden Parameter
Diese Parameter sind Zahlen.
Je nachdem, mit welcher numerischen Präzision sie gespeichert werden, benötigen sie unterschiedlich viel Speicher.
Die einfachste VRAM-Rechnung
Ein grober Ausgangspunkt lautet:
Parameter
×
Bits pro Parameter
÷
8
=
Bytes für die Modellgewichte
Nehmen wir ein Modell mit:
8 Milliarden Parametern
und speichern jeden Parameter mit:
16 Bit
Dann:
8 Milliarden
×
16 Bit
÷
8
=
16 Milliarden Byte
Sehr grob also:
≈ 16 GB
allein für die Gewichte.
Ein 16-GB-Modell passt trotzdem nicht zwangsläufig auf eine 16-GB-GPU
Denn zusätzlich benötigt die Inferenz Speicher für:
KV-Cache,
Laufzeitpuffer,
temporäre Berechnungen
und weitere Daten.
Darum ist:
Modellgewichte = 15,8 GB
VRAM = 16 GB
kein komfortabler Zustand.
Ein System sollte normalerweise etwas Reserve besitzen.
Die Parameterzahl allein sagt deshalb noch wenig
Nehmen wir dasselbe 8B-Modell.
Mit 16 Bit:
ungefähr 16 GB
Mit 8 Bit:
ungefähr 8 GB
Mit 4 Bit:
ungefähr 4 GB
Das ist eine vereinfachte theoretische Rechnung.
Reale Dateien enthalten zusätzlichen Overhead und unterschiedliche Quantisierungsstrukturen.
Das Prinzip ist aber entscheidend:
Der Speicherbedarf hängt mindestens genauso von der Zahlenpräzision wie von der Parameterzahl ab.
Genau deshalb gibt es Quantisierung
Ein großes Modell wird mit einer kompakteren numerischen Darstellung gespeichert.
Vereinfacht:
16 Bit
↓
8 Bit
↓
6 Bit
↓
5 Bit
↓
4 Bit
Dadurch sinkt der benötigte Speicher erheblich.
Das ist einer der Hauptgründe, warum heute relativ große Sprachmodelle auf Consumer-Hardware betrieben werden können.
Ein grober Vergleich
Nehmen wir nur zur Veranschaulichung ein Modell mit zehn Milliarden Parametern.
Theoretisch:
FP16
≈ 20 GB
8 Bit
≈ 10 GB
4 Bit
≈ 5 GB
Noch einmal:
Das sind keine exakten Anforderungen einer konkreten Modelldatei.
Es sind Größenordnungen, um den Zusammenhang zu verstehen.
Quantisierung macht VRAM-Planung flexibler
Angenommen, deine GPU besitzt:
16 GB VRAM
Ein Modell in hoher Präzision braucht:
24 GB
Dann passt es nicht.
Eine geeignete quantisierte Variante braucht vielleicht:
9 GB
Nun bleibt sogar Raum für:
Kontext,
KV-Cache,
weitere Laufzeitdaten.
Damit kann dieselbe Hardware plötzlich eine wesentlich größere Modellklasse betreiben.
Dafür kann Quantisierung Qualität kosten
Es wäre falsch zu denken:
4 Bit
=
gleiche Modellqualität
bei einem Viertel Speicher
Man reduziert numerische Genauigkeit.
Das kann abhängig von:
Modell,
Quantisierungsverfahren,
Aufgabe
mehr oder weniger Qualitätsverlust erzeugen.
Genau deshalb bekommt Quantisierung im nächsten Schritt einen eigenen Artikel.
VRAM hängt also nicht nur vom Modellnamen ab
Die Aussage:
Modell X braucht 16 GB VRAM.
ist häufig zu ungenau.
Eigentlich müsste man fragen:
Welche Modellvariante?
Welche Quantisierung?
Welche Kontextlänge?
Welche Batchgröße?
Welche Inference Engine?
Welche Parallelität?
Erst daraus entsteht eine belastbare Größenordnung.
Was ist der KV-Cache?
Während ein Sprachmodell eine Antwort generiert, verarbeitet es bereits vorhandene Tokens.
Damit es bei jedem neuen Token nicht sämtliche vorherigen Informationen vollständig neu berechnen muss, werden bestimmte Zwischenergebnisse gespeichert.
Dieser Bereich wird KV-Cache genannt.
KV steht für:
Key
+
Value
aus dem Attention-Mechanismus des Modells.
Für das praktische Verständnis genügt:
mehr Kontext
↓
mehr KV-Cache
↓
mehr Speicherbedarf
Das Kontextfenster beeinflusst den VRAM deshalb direkt
Unter Kontextfenster haben wir beispielsweise unterschieden zwischen:
8.000 Tokens
und:
32.000 Tokens
und:
128.000 Tokens
Ein Modell kann theoretisch ein sehr großes Kontextfenster unterstützen.
Das bedeutet aber nicht, dass dieses Kontextfenster auf jeder Hardware gleichermaßen praktisch ist.
Ein Modell kann bei kurzem Kontext problemlos laufen
Zum Beispiel:
Modellgewichte
10 GB
sonstige Laufzeitdaten
1 GB
KV-Cache
2 GB
Gesamt:
13 GB
Auf:
16 GB VRAM
kein Problem.
Mit größerem Kontext verändert sich die Rechnung
Nun wächst der KV-Cache beispielsweise auf:
6 GB
Dann:
10 GB Modell
+
1 GB Laufzeit
+
6 GB KV-Cache
=
17 GB
Plötzlich reicht dieselbe Grafikkarte nicht mehr.
Die Zahlen dienen nur als konzeptionelles Beispiel.
Der entscheidende Zusammenhang lautet:
Das gleiche Modell kann je nach Kontext unterschiedliche VRAM-Anforderungen besitzen.
Lange Dokumente können daher überraschend teuer sein
Ein lokaler Chat mit:
ein paar kurzen Nachrichten
funktioniert hervorragend.
Dann lädst du:
einen umfangreichen Bericht
oder:
mehrere PDFs
in den Kontext.
Nun steigt:
Promptlänge,
Verarbeitungszeit,
Speicherbedarf.
Deshalb ist ein erfolgreicher kurzer Test noch kein Beweis dafür, dass dein späterer realer Workflow problemlos funktioniert.
RAG kann VRAM indirekt sparen
Angenommen, deine Wissensbasis umfasst:
10.000 Dokumente
Man könnte versuchen:
möglichst viel davon in den Kontext zu legen.
Das wäre ineffizient.
RAG sucht stattdessen:
Frage
↓
relevante Passagen
↓
nur diese Passagen
↓
LLM
Dadurch kann der Kontext wesentlich kleiner bleiben.
Das spart:
Rechenzeit,
Tokens
und:
KV-Cache.
Gute Softwarearchitektur kann deshalb Hardware ersetzen
Problem:
Kontext zu groß
Lösung A:
mehr VRAM kaufen
Lösung B:
besseres Retrieval
Häufig lohnt es sich, zuerst Lösung B zu prüfen.
Ein ineffizientes System einfach mit stärkerer Hardware zu kompensieren, kann unnötig teuer werden.
Mehrere gleichzeitige Nutzer benötigen ebenfalls zusätzlichen Speicher
Ein lokaler Rechner wird nur von dir genutzt.
1 Nutzer
↓
1 Kontext
Ein Server wird von zehn Mitarbeitern benutzt.
Nutzer 1
Nutzer 2
Nutzer 3
...
↓
gleichzeitige Anfragen
Nun müssen mehrere laufende Sequenzen verwaltet werden.
Damit steigt unter anderem der Speicherbedarf für die jeweiligen Kontexte.
Ein Modellserver braucht deshalb mehr Reserve als ein Einzelplatz
Wenn ein Modell auf einer 16-GB-Karte mit:
15,7 GB
gerade noch läuft, ist das vielleicht für einen einzelnen Test akzeptabel.
Für einen Server mit mehreren Nutzern ist das keine komfortable Planung.
Man braucht Raum für:
Parallelität
unterschiedliche Kontextlängen
temporäre Speicherpeaks
weitere Prozesse
Was ist Batchgröße?
Statt eine Eingabe nach der anderen zu verarbeiten, können KI-Systeme mehrere Eingaben gemeinsam verarbeiten.
Zum Beispiel:
Prompt A
Prompt B
Prompt C
Prompt D
↓
Batch
↓
GPU
Das kann den Gesamtdurchsatz erhöhen.
Es erhöht aber typischerweise auch den Speicherbedarf.
Mehr Batch bedeutet häufig mehr VRAM
Vereinfacht:
Batch 1
→ wenig Speicher
Batch 16
→ mehr Speicher
Deshalb kann dieselbe Hardware:
sehr guten Einzelchat
aber:
begrenzten Serverdurchsatz
haben.
VRAM besitzt deshalb drei typische Aufgaben
Er kann genutzt werden für:
größeres Modell
oder:
größeren Kontext
oder:
mehr Parallelität
Wer mehr VRAM besitzt, kann diese Reserve unterschiedlich einsetzen.
Das erklärt, warum Server gern mehr VRAM besitzen
Nicht immer deshalb, weil dort ein riesigeres Modell laufen soll.
Vielleicht läuft dasselbe Modell wie auf einem Desktop.
Aber:
mehr Nutzer
mehr parallele Prompts
größere Kontextreserven
benötigen zusätzlichen Speicher.
Wie viel VRAM braucht man also?
Die korrekte Antwort lautet:
Es hängt vom Modell und vom Einsatz ab.
Trotzdem sind grobe Denkklassen hilfreich.
Nicht als Garantie für ein bestimmtes Modell, sondern als Orientierung.
Rund 8 GB VRAM
Damit lassen sich insbesondere:
kleinere quantisierte Sprachmodelle
lokal sinnvoll ausprobieren.
Typische Anwendungen können sein:
einfache Chats,
Klassifikation,
kleine Automatisierungen,
Experimente.
Größere Modelle müssen gegebenenfalls stärker quantisiert oder teilweise in den System-RAM ausgelagert werden.
Rund 12 GB VRAM
Hier wird die Auswahl komfortabler.
Kleinere bis mittlere quantisierte Modelle können mehr Reserve für:
Kontext
und:
Laufzeitdaten
bekommen.
Für einen Einstieg in lokale LLMs kann das bereits sehr brauchbar sein.
Rund 16 GB VRAM
16 GB sind für lokale KI eine interessante Klasse, weil damit zahlreiche kompakte und mittelgroße quantisierte Modelle komfortabler betrieben werden können.
Zusätzlich entsteht eher Reserve für:
längeren Kontext,
weitere Modelle,
Batching.
Aber auch 16 GB sind keine universelle Grenze.
Ein bestimmtes großes Modell kann weiterhin deutlich mehr benötigen.
Rund 24 GB VRAM
24 GB öffnen eine deutlich größere Auswahl.
Hier können:
größere quantisierte Modelle,
höhere Präzision bei kleineren Modellen,
umfangreichere Kontexte
praktischer werden.
Deshalb sind GPUs mit viel VRAM bei lokalen KI-Nutzern häufig besonders interessant.
Nicht zwingend, weil sie das schnellste Gamingmodell darstellen.
Sondern weil:
24 GB
eine andere Modellklasse ermöglichen können als:
8 oder 12 GB
32 GB und darüber
Nun wird lokale KI zunehmend komfortabel für:
größere Modelle,
mehr Kontext,
mehr Parallelität.
Bei professionellen Karten existieren noch deutlich größere Speicherklassen.
Solche Systeme können interessant werden für:
Server,
Fine-Tuning,
große Modelle,
mehrere Nutzer.
48 GB und mehr
Hier befinden wir uns bereits in einer Klasse, in der zahlreiche Modelle mit wesentlich weniger aggressiver Quantisierung oder zusätzlicher Parallelitätsreserve betrieben werden können.
Allerdings steigen typischerweise:
Anschaffungskosten,
Stromverbrauch
und:
Hardwareanforderungen.
Ob sich das lohnt, hängt vom Workload ab.
Mehr VRAM sollte nicht zum Selbstzweck werden
Wenn dein reales Modell:
6 GB
benötigt und dein Kontext klein ist, bringt eine:
48-GB-GPU
für diese Aufgabe allein möglicherweise wenig zusätzlichen Nutzen.
Sie bietet Reserve.
Aber Reserve hat einen Preis.
Deshalb zuerst das kleinste ausreichende Modell suchen
Das Prinzip lautet:
Aufgabe
↓
kleinstes ausreichend gutes Modell
↓
geeignete Quantisierung
↓
realer Kontext
↓
VRAM-Bedarf
Erst dann:
Grafikkarte auswählen.
Eine praktische Überschlagsrechnung
Angenommen, du möchtest ein 14B-Modell verwenden.
Bei theoretischen 4 Bit:
14 Milliarden
×
4
÷
8
≈
7 GB
Nur Modellgewichte.
Nun kommen beispielsweise hinzu:
Quantisierungsoverhead
KV-Cache
Runtime
Reserve
Das Modell könnte daher real deutlich mehr als exakt 7 GB benötigen.
Der Wert sagt nur:
In welcher Größenordnung bewegen sich die Gewichte?
Bei 8 Bit
14 Milliarden
×
8
÷
8
≈
14 GB
Mit Laufzeitdaten wäre:
16 GB VRAM
möglicherweise bereits knapp.
Mit:
24 GB
gäbe es mehr Reserve.
Aber die exakte Antwort hängt vom konkreten Modell ab.
Bei 16 Bit
14 Milliarden
×
16
÷
8
≈
28 GB
Damit wäre allein die theoretische Gewichtskapazität bereits größer als der VRAM typischer 24-GB-Consumerkarten.
Genau hier zeigt sich die Macht der Quantisierung.
Ein größeres Beispiel mit 32B
4-Bit-Theorie:
32 Milliarden
×
4
÷
8
≈
16 GB
Das bedeutet nicht:
Ein 32B-Modell passt problemlos in 16 GB.
Denn:
Overhead,
KV-Cache,
Runtime
kommen hinzu.
Auf einer 24-GB-GPU kann eine geeignete quantisierte Variante dagegen je nach Modell und Kontext wesentlich realistischer sein.
Beispiel 70B
4-Bit-Theorie:
70 Milliarden
×
4
÷
8
≈
35 GB
Damit ist sofort klar:
24 GB Einzel-GPU
reicht für die vollständigen Gewichte in dieser vereinfachten Betrachtung nicht.
Nun gibt es mehrere Möglichkeiten.
Möglichkeit 1: Mehr VRAM auf einer GPU
Modell
↓
eine große GPU
Einfachste Architektur.
Aber entsprechende Karten können sehr teuer sein.
Möglichkeit 2: Multi-GPU
Modell
↓
├── GPU 1
└── GPU 2
Die Modellgewichte werden auf mehrere Karten verteilt.
Damit kann die Gesamtkapazität steigen.
Möglichkeit 3: GPU plus System-RAM
Modell
├── Teil im VRAM
└── Teil im RAM
Dadurch können noch größere Modelle grundsätzlich laufen.
Die Geschwindigkeit kann jedoch deutlich sinken.
Möglichkeit 4: Stärkere Quantisierung beziehungsweise kleineres Modell
Oft die eleganteste Variante.
größeres Modell
↓
zu hoher Speicherbedarf
Frage:
Brauche ich dieses Modell wirklich?
Vielleicht löst ein kleineres modernes Modell dieselbe Aufgabe ausreichend gut.
Multi-GPU-VRAM wird häufig missverstanden
Zwei Grafikkarten besitzen jeweils:
16 GB
Damit besitzt das System insgesamt:
32 GB GPU-Speicher
Aber technisch existiert weiterhin:
GPU 1
→ eigene 16 GB
GPU 2
→ eigene 16 GB
Nicht:
eine GPU
→ 32 GB
Die Inference Engine muss ein Modell bewusst verteilen.
Das kann sehr gut funktionieren
Zum Beispiel:
erste Modellschichten
→ GPU 1
weitere Modellschichten
→ GPU 2
Damit kann ein Modell betrieben werden, das auf keiner Karte allein Platz hätte.
Kommunikation kostet aber Leistung
Die Berechnung muss von einer GPU zur nächsten weitergereicht werden.
GPU 1
↓
Datenübertragung
↓
GPU 2
Diese Übertragung ist langsamer als ein Zugriff innerhalb des lokalen VRAM derselben GPU.
Deshalb entspricht:
2 × 16 GB
nicht vollständig:
1 × 32 GB
Trotzdem kann Multi-GPU äußerst sinnvoll sein
Insbesondere wenn:
eine große Einzel-GPU zu teuer ist,
bereits zwei Karten vorhanden sind,
verschiedene Modelle parallel betrieben werden sollen,
mehrere unabhängige Workloads laufen.
Zwei GPUs können auch völlig getrennt arbeiten
Beispiel:
GPU 1
→ Sprachmodell
GPU 2
→ Bildgenerierung
Oder:
GPU 1
→ interaktiver Chat
GPU 2
→ Batchjobs
Dann wird der VRAM überhaupt nicht für dasselbe Modell zusammengeführt.
Jede GPU erhält ihre eigene Aufgabe.
Das kann effizienter sein als Modellteilung
Wenn das Modell vollständig auf eine GPU passt:
Modell A
→ GPU 1
und:
Modell A
→ GPU 2
können zwei getrennte Instanzen gleichzeitig Anfragen bearbeiten.
Das erhöht den Durchsatz.
Für viele Nutzer kann das sinnvoller sein als ein Modell über beide Karten zu verteilen.
VRAM ist deshalb auch ein Schedulingproblem
Ein lokaler KI-Server kann mehrere Modelle besitzen.
Zum Beispiel:
LLM
→ 12 GB
Embeddingmodell
→ 1 GB
Reranker
→ 2 GB
Bildmodell
→ 8 GB
Auf einer 16-GB-GPU können nicht alle gleichzeitig komfortabel resident sein.
Nun braucht man eine Strategie.
Modelle können bei Bedarf geladen werden
Chat gestartet
↓
LLM laden
später:
Bildauftrag
↓
LLM entfernen
↓
Bildmodell laden
Das spart VRAM.
Aber Modellwechsel kosten Zeit.
Häufig genutzte Modelle können resident bleiben
Zum Beispiel:
GPU 1
→ LLM dauerhaft
GPU 2
→ Bild / Embeddings nach Bedarf
Bei mehreren GPUs kann man dadurch unterschiedliche Dienste sauber trennen.
VRAM beeinflusst auch Bild-KI
Nicht nur Sprachmodelle brauchen Grafikspeicher.
Auch:
Bildgenerierung,
Video-KI,
Spracherkennung,
Computer Vision
können erheblichen VRAM benötigen.
Die genaue Nutzung unterscheidet sich jedoch.
Ein Rechner, der mehrere KI-Arten bedienen soll, muss deshalb das gesamte Modellportfolio berücksichtigen.
Besonders Bild- und Videomodelle können große temporäre Speicherpeaks erzeugen
Dabei spielen beispielsweise eine Rolle:
Auflösung,
Batchgröße,
Modellarchitektur,
Generationsverfahren.
Eine GPU, die hervorragend für dein Sprachmodell reicht, kann bei hochauflösender Bild- oder Videoerzeugung anders belastet werden.
Fine-Tuning braucht wesentlich mehr Speicher als Inferenz
Das ist ein entscheidender Unterschied.
Bei Inferenz brauchst du vereinfacht:
Modellgewichte
KV-Cache
Laufzeitdaten
Beim Training beziehungsweise Fine-Tuning zusätzlich beispielsweise:
Gradienten
Aktivierungen
Optimierungszustände
Der Speicherbedarf kann dadurch massiv steigen.
„Das Modell passt auf meine GPU“ bedeutet daher nicht „ich kann es trainieren“
Du betreibst ein Modell lokal problemlos mit:
12 GB VRAM
Das vollständige Fine-Tuning desselben Modells könnte:
wesentlich mehr
erfordern.
Genau deshalb existieren Verfahren wie:
LoRA
und:
QLoRA.
LoRA reduziert den Trainingsbedarf
Anstatt sämtliche Modellparameter zu verändern:
Basismodell
↓
größtenteils unverändert
werden kleinere zusätzliche Parameter trainiert.
Dadurch sinkt der Ressourcenbedarf.
QLoRA kombiniert das mit Quantisierung
quantisiertes Basismodell
+
trainierbare Adapter
Damit werden Anpassungen auf deutlich kleinerer Hardware möglich.
Trotzdem bleibt Fine-Tuning speicherintensiver als einfache Nutzung eines quantisierten Modells.
VRAM für Inferenz und VRAM für Training getrennt planen
Wenn dein Ziel lautet:
lokaler Chat
RAG
Automatisierung
dann dimensioniere primär für Inferenz.
Wenn du zusätzlich:
Fine-Tuning
planst, muss diese Anforderung separat berücksichtigt werden.
Warum reicht normaler RAM nicht einfach?
System-RAM kann sehr groß und relativ günstig sein.
Beispielsweise:
128 GB RAM
gegen:
24 GB VRAM
Warum also nicht einfach das gesamte Modell im RAM halten?
Das ist möglich.
Der entscheidende Unterschied liegt vor allem in der Geschwindigkeit und Nähe zur Recheneinheit.
GPU-VRAM besitzt sehr hohe Speicherbandbreite
Die GPU muss bei Sprachmodellen enorme Mengen von Gewichtsdaten verarbeiten.
Je schneller diese Daten geliefert werden können, desto besser.
System-RAM ist für die CPU optimiert.
VRAM für die GPU.
Wenn die GPU ständig über eine langsamere Verbindung auf Hostdaten zugreifen muss, kann ein massiver Flaschenhals entstehen.
Deshalb ist vollständiges GPU-Offloading begehrt
Modell
↓
komplett im VRAM
↓
GPU
Wenn möglich.
Das bedeutet nicht, dass CPU-Offloading schlecht ist.
Es ist ein Werkzeug, um größere Modelle überhaupt betreiben zu können.
Offloading ist ein Kompromiss
mehr Modell im RAM
↓
weniger VRAM nötig
aber häufig:
mehr CPU-Arbeit
+
mehr Datenbewegung
↓
geringere Geschwindigkeit
Je nach Hardware kann der Unterschied erheblich sein.
Partial Offloading kann trotzdem sehr praktisch sein
Angenommen, ein Modell benötigt etwas mehr als deine GPU bietet.
Zum Beispiel:
20 GB Gesamtbedarf
GPU:
16 GB
Ein kleiner Teil kann im RAM liegen.
Vielleicht bleibt die Geschwindigkeit für deinen Anwendungsfall akzeptabel.
Damit kann eine kleinere GPU trotzdem brauchbar sein.
Aber große Offload-Anteile können sehr langsam werden
Wenn beispielsweise:
nur ein kleiner Teil des Modells
auf der GPU liegt und:
der Großteil
durch CPU und RAM verarbeitet werden muss, nähert sich die Performance stärker einer CPU-Lösung an.
Man sollte das deshalb praktisch benchmarken.
System-RAM sollte bei Offloading ausreichend groß sein
Ein Modell kann nicht:
40 GB
in den RAM auslagern, wenn dein gesamter Rechner nur:
32 GB RAM
besitzt.
Zusätzlich brauchen:
Betriebssystem,
n8n,
Datenbanken,
weitere Dienste
ebenfalls Speicher.
VRAM und RAM sollten gemeinsam dimensioniert werden
Beispiel:
24 GB VRAM
+
64 GB RAM
kann ein flexibles lokales KI-System ergeben.
Ein anderes Szenario:
8 GB VRAM
+
128 GB RAM
kann größere Modelle technisch ermöglichen, aber stärker von CPU-Offloading abhängen.
Welche Konfiguration besser ist, hängt vom Ziel ab.
Geschwindigkeit kann wichtiger sein als maximale Modellgröße
Es ist verlockend zu sagen:
Ich kann ein 70B-Modell starten.
Wenn die Generierung aber:
1 Token pro Sekunde
beträgt, ist ein interaktiver Chat möglicherweise wenig angenehm.
Ein kleineres Modell mit:
30 Tokens pro Sekunde
kann praktisch wesentlich nützlicher sein.
Deshalb sollte VRAM nicht nur zum „größten Modell, das irgendwie startet“ genutzt werden
Besser:
Qualität
+
Geschwindigkeit
+
Kontext
+
Parallelität
gemeinsam optimieren.
VRAM-Reserve erhöht Stabilität
Wenn eine Anwendung ständig bei:
99,9 % VRAM
läuft, können kleine Änderungen zu Fehlern führen.
Zum Beispiel:
längerer Prompt,
größerer Batch,
andere Engine-Version,
zusätzlicher Prozess.
Etwas Reserve macht ein System robuster.
Ein komfortables System ist besser als ein mathematisch maximiertes
Nicht:
24,0 GB VRAM
23,99 GB geplant
sondern:
ausreichende Reserve
für reale Nutzung.
Wie groß die Reserve sein sollte, hängt von Software und Workload ab.
Eine allgemeine feste Prozentzahl wäre irreführend.
VRAM-Fragmentierung kann ebenfalls eine Rolle spielen
Speicher ist nicht nur:
frei
oder:
belegt.
Programme reservieren und geben Bereiche wieder frei.
Dadurch kann es passieren, dass genügend Speicher theoretisch vorhanden scheint, eine gewünschte große zusammenhängende Allokation aber nicht problemlos möglich ist.
Das ist ein weiterer Grund, nicht auf die allerletzten Megabyte zu planen.
Mehrere Prozesse konkurrieren um denselben VRAM
Vielleicht läuft bereits:
Desktop-Compositor
oder:
Browser mit GPU-Beschleunigung
oder:
zweites KI-Modell
auf derselben Grafikkarte.
Dann steht deinem LLM weniger Speicher zur Verfügung als die auf der Verpackung angegebene Gesamtmenge.
Eine dedizierte Server-GPU hat hier Vorteile
Ein KI-Server ohne grafischen Desktop kann einen größeren Anteil seines VRAM tatsächlich für die KI nutzen.
Das macht keine zusätzlichen Gigabyte.
Aber es reduziert konkurrierende Verbraucher.
Auf dem Desktop sollte man etwas Reserve für die Anzeige einplanen
Wenn dieselbe GPU:
Monitor
und:
KI
betreibt, verbraucht die grafische Oberfläche ebenfalls Speicher.
Bei großen VRAM-Kapazitäten ist das meist relativ klein.
Bei sehr knappen Setups kann es relevant werden.
Der Betrieb ohne Monitor kann trotzdem sinnvoll sein
Ein zentraler KI-Server kann:
headless
laufen.
Andere Geräte greifen über:
Weboberfläche,
API,
n8n
darauf zu.
Dann muss die leistungsfähige GPU keine lokale Desktopoberfläche bedienen.
Wie finde ich den tatsächlichen VRAM-Verbrauch?
Die beste Methode ist:
messen.
Starte das gewünschte Modell mit:
realistischer Quantisierung,
realistischem Kontext,
realistischen Parallelitätswerten.
Dann beobachte:
VRAM-Verbrauch
GPU-Auslastung
Geschwindigkeit
Das ist wesentlich zuverlässiger als jede pauschale Internetliste.
Eine sinnvolle Testreihe
Modell laden
↓
kurzer Prompt
↓
VRAM messen
dann:
realistischer Prompt
↓
VRAM messen
dann:
maximal gewünschter Kontext
↓
VRAM messen
dann gegebenenfalls:
mehrere parallele Requests
↓
VRAM messen
Nun besitzt du echte Daten.
Der Peak ist wichtiger als der Durchschnitt
Ein Workflow nutzt normalerweise:
12 GB
aber kurzzeitig:
15,8 GB
auf einer:
16-GB-GPU
Dann ist der Peak relevant.
Nicht der Durchschnitt.
Monitoring sollte deshalb Verlauf zeigen
Nicht nur:
VRAM aktuell: 8 GB
sondern beispielsweise:
Maximum letzte Stunde:
15,2 GB
So erkennt man Lastspitzen.
VRAM-Auslastung allein zeigt aber nicht, ob ein Upgrade sinnvoll ist
Angenommen:
VRAM 99 %
aber:
Modell läuft perfekt
und:
keine OOM-Fehler.
Mehr VRAM bringt vielleicht keinen unmittelbaren Nutzen.
Anderes Szenario:
VRAM 70 %
aber:
GPU-Rechenleistung 100 %
und Anwendung zu langsam.
Dann braucht man eher:
schnellere GPU
als:
mehr Speicher.
Speicher und Rechenleistung getrennt diagnostizieren
Fall A:
Modell passt nicht
→ mehr VRAM / stärkere Quantisierung
Fall B:
Modell passt,
aber langsam
→ mehr Rechenleistung / Bandbreite
Fall C:
ein Nutzer schnell,
viele Nutzer langsam
→ mehr Serving-Kapazität
Fall D:
große Prompts führen zu OOM
→ Kontext / KV-Cache optimieren
So wird Hardwareplanung zielgerichtet.
Kontext kann begrenzt werden
Ein Modell unterstützt vielleicht theoretisch:
128k Tokens
Deine Anwendung benötigt aber maximal:
16k
Dann solltest du nicht zwangsläufig Ressourcen für 128k reservieren.
Der maximal mögliche Modellwert ist nicht automatisch die sinnvolle Serverkonfiguration.
RAG kann Kontext gezielt reduzieren
Ein Supportsystem benötigt:
relevante Antwortpassagen
nicht:
gesamte Wissensdatenbank
Das spart VRAM und verbessert häufig sogar die Qualität, weil weniger irrelevanter Text im Kontext landet.
Chunking beeinflusst damit indirekt Hardware
Zu große Chunks:
viel Kontext
Zu viele Chunks:
viel Kontext
Eine gute RAG-Pipeline liefert nur ausreichend viele relevante Abschnitte.
Hardware und Retrievalqualität hängen dadurch zusammen.
Agenten können Kontext besonders stark aufblasen
Ein KI-Agent führt vielleicht:
20 Toolaufrufe
aus.
Jedes Ergebnis landet im Verlauf.
Tool 1
↓
2.000 Tokens
Tool 2
↓
3.000 Tokens
Tool 3
↓
5.000 Tokens
Der Agentenkontext wächst.
Damit wachsen:
Rechenaufwand,
KV-Cache,
VRAM-Bedarf.
Agenten brauchen deshalb Kontextmanagement
Zum Beispiel:
alte Toolergebnisse zusammenfassen,
nur relevante Teile behalten,
Fakten strukturiert speichern,
große Ergebnisse extern referenzieren.
Das spart nicht nur Tokens.
Es spart lokale Hardwarekapazität.
n8n kann ebenfalls helfen, Daten vor dem Modell zu reduzieren
Statt:
riesiges API-Ergebnis
↓
LLM
kann n8n vorher:
filtern,
sortieren,
relevante Felder auswählen.
API
↓
Filter
↓
nur relevante Daten
↓
LLM
Weniger Input bedeutet:
weniger Kontext.
Datenbanken sollten Aggregationen selbst durchführen
Frage:
Wie hoch war der Umsatz letzten Monat?
Schlecht:
1 Million Bestellungen
↓
in LLM-Kontext
Besser:
SQL
↓
SUM()
↓
eine Zahl
↓
LLM
Das spart massiv:
Tokens,
VRAM,
Rechenzeit.
Gute Systemarchitektur ist deshalb immer auch VRAM-Optimierung.
Embeddings brauchen meist wesentlich weniger VRAM als große LLMs
Ein Embeddingmodell kann deutlich kleiner sein.
Das bedeutet:
Du musst nicht deine größte GPU permanent mit:
Embeddingberechnung
beschäftigen.
Vielleicht reicht:
CPU,
kleinere GPU
oder:
separater Worker.
Ein Reranker kann ebenfalls separat laufen
Eine RAG-Architektur könnte sein:
Embeddingmodell
→ kleine GPU / CPU
Vektordatenbank
→ RAM / CPU
Reranker
→ kleine GPU
LLM
→ große GPU
Damit wird wertvoller VRAM gezielt dort eingesetzt, wo er den größten Nutzen besitzt.
Nicht jedes Modell muss gleichzeitig geladen sein
Ein weiterer Optimierungsweg:
Embeddingmodell
↓
kurz laden
↓
Job erledigen
↓
entladen
Danach:
LLM
↓
laden beziehungsweise resident halten
Ob das sinnvoll ist, hängt von Häufigkeit und Ladezeiten ab.
Zwei kleinere GPUs können für verschiedene Rollen besser sein als eine
Beispiel:
GPU 1
16 GB
→ Textmodell
GPU 2
16 GB
→ Bildmodell / Batch
Das ergibt funktional andere Möglichkeiten als:
eine einzelne 32-GB-GPU
Auch wenn die Gesamtspeicherzahl gleich erscheint.
Eine große Einzel-GPU ist dafür einfacher für große Einzelmodelle
Wenn dein Ziel lautet:
ein Modell braucht 28 GB
ist:
1 × 32 GB
architektonisch einfacher als:
2 × 16 GB
weil keine Modellteilung zwischen Geräten erforderlich ist.
Das ist ein wichtiger Punkt beim Hardwarekauf.
Mehrere kleine GPUs eignen sich eher für Parallelität
Wenn dein Modell nur:
10 GB
benötigt, können zwei 16-GB-Karten jeweils eine eigene Instanz tragen.
GPU 1
→ Nutzergruppe A
GPU 2
→ Nutzergruppe B
Damit kann der Gesamtdurchsatz steigen.
Eine große Karte eignet sich eher für einzelne große Modelle
Sehr vereinfacht:
1 große GPU
→ größere Einzelmodelle einfacher
mehrere kleinere GPUs
→ flexible Parallelität
Beide können Modelle verteilen.
Aber die Architekturziele unterscheiden sich.
VRAM-Kauf ist deshalb auch Zukunftsplanung
Heute reicht:
8 GB
für dein aktuelles Modell.
Du möchtest später:
größeres Modell,
Bild-KI,
RAG,
mehrere Nutzer.
Dann können:
16 oder 24 GB
mehr Entwicklungsspielraum geben.
Zu viel Zukunftsreserve kann aber teuer sein
Vielleicht verwendest du auch in drei Jahren nur ein kleines Modell.
Dann war die teure VRAM-Reserve ungenutzt.
Sinnvoll ist eine Balance:
heutige Anforderungen
+
realistische Erweiterung
nicht:
jede theoretisch denkbare Zukunft
VRAM ist häufig wertvoller als zusätzliche Gaming-Leistung
Wenn zwei GPUs ähnlich viel kosten:
GPU A:
schneller
12 GB VRAM
GPU B:
etwas langsamer
24 GB VRAM
Für Gaming kann A attraktiver sein.
Für lokale LLMs kann B wesentlich interessanter sein.
Weil:
12 GB
und:
24 GB
unterschiedliche Modellgrenzen darstellen.
Deshalb sind ältere High-VRAM-GPUs manchmal für KI interessant
Eine ältere Karte kann:
weniger Rechenleistung
aber:
viel VRAM
besitzen.
Wenn ein Modell ansonsten überhaupt nicht in den Speicher einer neueren kleineren Karte passt, kann die ältere Karte trotzdem sinnvoll sein.
Dabei müssen jedoch berücksichtigt werden:
Energieeffizienz,
Softwareunterstützung,
Geschwindigkeit,
Alter der Hardware.
Nur VRAM zu vergleichen wäre ebenfalls falsch
Zwei Karten:
beide 24 GB.
Eine besitzt deutlich höhere:
Speicherbandbreite
und:
Rechenleistung.
Dann können ihre LLM-Geschwindigkeiten stark unterschiedlich sein.
VRAM beantwortet zunächst:
Passt es?
Nicht:
Wie schnell läuft es?
Eine gute Kaufentscheidung braucht beide Fragen
1. Genug VRAM?
und anschließend:
2. Genug Performance?
sowie:
3. Genug Energieeffizienz?
und:
4. Softwareunterstützung?
VRAM lässt sich bei Consumer-GPUs normalerweise nicht nachrüsten
System-RAM:
32 GB
↓
später 64 GB
oft problemlos.
VRAM:
fest auf der Grafikkarte.
Du kannst normalerweise nicht einfach:
16 GB
↓
32 GB
Speicher nachstecken.
Das macht die VRAM-Kaufentscheidung besonders wichtig.
Eine neue GPU ist das VRAM-Upgrade
Wenn später mehr VRAM benötigt wird:
neue Grafikkarte
oder:
zusätzliche Grafikkarte.
Deshalb lohnt es sich, bei KI-Systemen den VRAM etwas bewusster zu dimensionieren als bei gewöhnlichen Desktopanwendungen.
Die VRAM-Kapazität sollte zum Lebenszyklus passen
Ein Rechner wird vielleicht:
vier Jahre
verwendet.
Die Modelllandschaft verändert sich.
Mehr VRAM kann deshalb Zukunftsreserve bieten.
Aber auch Quantisierungsverfahren und kleinere Modelle verbessern sich.
Es ist nicht garantiert, dass zukünftig immer nur größere Modelle gebraucht werden.
Modellqualität wächst nicht linear mit Parameterzahl
Ein neues:
14B-Modell
kann bei bestimmten Aufgaben ein älteres:
30B-Modell
übertreffen.
Deshalb sollte man nicht versuchen, Hardware ausschließlich für möglichst hohe Parameterzahlen zu kaufen.
Die Modellarchitektur entwickelt sich ebenfalls weiter.
Eine praktische Entscheidungsregel
Wenn dein Hauptziel lautet:
lokale KI ausprobieren
dann reicht vorhandene Hardware häufig für den Anfang.
Wenn dein Ziel lautet:
bestimmtes Modell produktiv
dann:
Modell vorher testen.
Wenn dein Ziel lautet:
lokaler KI-Server für mehrere Dienste
dann:
mehr VRAM-Reserve und Parallelität einplanen.
Der beste VRAM-Test ist dein echter Workflow
Nicht:
Chatte fünf Minuten mit dem Modell.
Sondern:
echte Dokumentlängen
echte Systemprompts
echte RAG-Chunks
echte Agenten-Toolergebnisse
echte Parallelität
Dann messen.
Ein Content-Workflow kann beispielsweise viel Kontext erzeugen
Systemprompt.
Recherche.
Briefing.
Quellen.
Artikelentwurf.
Qualitätscheck.
Wenn alles in einem einzigen Kontext bleibt, kann dieser sehr groß werden.
Besser könnte sein:
Recherche
↓
strukturierte Fakten speichern
dann:
Schreibschritt
↓
nur relevante Fakten laden
Das spart Kontext und VRAM.
Workflows sollten Information zwischen Schritten strukturieren
Nicht:
alle vorherigen Texte vollständig
↓
immer wieder ins Modell
sondern:
strukturierte Zwischenergebnisse
↓
gezielt weiterreichen
Genau dafür sind strukturierte Ausgaben wertvoll.
Lokale KI zwingt zu effizienter Architektur
Bei einer Cloud-API fällt ineffiziente Nutzung oft zuerst auf der Rechnung auf.
Lokal fällt sie auf als:
GPU voll
Antwort langsam
Queue wächst
VRAM reicht nicht
Beide Modelle belohnen sauberes Systemdesign.
VRAM ist damit kein isoliertes Hardwarethema
Es verbindet:
Modellwahl
Quantisierung
Kontextfenster
RAG
Agenten
Parallelität
Hardware
Genau deshalb ist es eine zentrale Größe lokaler KI.
Was du dir über VRAM merken solltest
VRAM ist der schnelle Arbeitsspeicher einer Grafikkarte.
Bei lokalen KI-Modellen werden dort unter anderem:
Modellgewichte
KV-Cache
temporäre Laufzeitdaten
gespeichert.
Der erste grobe Speicherbedarf eines Modells lässt sich aus der Parameterzahl abschätzen:
Parameter
×
Bits pro Parameter
÷
8
Ein Modell mit:
8 Milliarden Parametern
benötigt theoretisch für die Gewichte ungefähr:
16 Bit
→ 16 GB
8 Bit
→ 8 GB
4 Bit
→ 4 GB
Reale Anforderungen liegen durch:
Quantisierungsoverhead
KV-Cache
temporäre Speicherbereiche
Runtime
darüber beziehungsweise unterscheiden sich je nach Format.
Deshalb gilt:
Dateigröße
≠
vollständiger VRAM-Bedarf
Die Quantisierung ist einer der stärksten Hebel.
weniger Bits
↓
weniger Speicher
möglicherweise verbunden mit:
Qualitätsverlust
Wie groß dieser Unterschied tatsächlich ist, behandeln wir im nächsten Artikel.
Zusätzlich beeinflusst das Kontextfenster den Speicherbedarf.
mehr Kontexttokens
↓
größerer KV-Cache
↓
mehr VRAM
Auch mehrere parallele Nutzer benötigen zusätzlichen Laufzeitspeicher.
Damit lässt sich vorhandener VRAM vereinfacht für drei Dinge einsetzen:
größeres Modell
größerer Kontext
mehr parallele Anfragen
System-RAM kann helfen, wenn ein Modell nicht vollständig in den VRAM passt.
GPU
↕
RAM
Dieses Offloading kann größere Modelle ermöglichen.
Typischerweise wird es jedoch langsamer als vollständige GPU-Inferenz.
Deshalb sind zwei Aussagen zu unterscheiden:
Das Modell läuft.
und:
Das Modell läuft schnell genug.
Auch Multi-GPU vergrößert die Möglichkeiten.
Aber:
16 GB + 16 GB
werden technisch nicht automatisch zu:
einer 32-GB-GPU
Jede Grafikkarte besitzt ihren eigenen Speicher.
Die Inference Engine muss das Modell gezielt verteilen.
Modell
↓
├── GPU 1
└── GPU 2
Das ermöglicht größere Modelle.
Es erzeugt aber zusätzlichen Kommunikationsaufwand.
Mehrere GPUs können alternativ völlig unabhängig arbeiten:
GPU 1
→ Chat
GPU 2
→ Batch
oder:
GPU 1
→ Textmodell
GPU 2
→ Bildmodell
Das kann für einen lokalen KI-Server sogar die attraktivere Architektur sein.
Für die praktische Hardwareplanung sollte deshalb nicht gefragt werden:
Wie viel VRAM braucht KI?
Sondern:
Welches Modell?
Welche Quantisierung?
Welcher Kontext?
Wie viele Nutzer?
Welche Geschwindigkeit?
Welche weiteren Modelle?
Danach lässt sich der benötigte Speicherbereich abschätzen.
Als grobe Orientierung können VRAM-Klassen unterschiedlich viel Spielraum bieten:
8 GB
→ kleinere lokale Modelle und Experimente
12–16 GB
→ zunehmend komfortable lokale LLM-Nutzung
24 GB
→ deutlich größere Modell- und Kontextauswahl
32–48 GB+
→ größere Modelle, Serverreserven und anspruchsvollere Nutzung
Diese Werte sind keine festen Modellgrenzen.
Ein 16-GB-System kann durch geeignete Quantisierung ein überraschend großes Modell verwenden.
Ein schlecht konfiguriertes Modell kann gleichzeitig auf 24 GB scheitern.
Deshalb ist die beste Methode:
realen Workflow starten
↓
VRAM messen
↓
Kontext erhöhen
↓
Parallelität testen
↓
Peak messen
Und anschließend:
erst optimieren
oder
Hardware erweitern
VRAM ist damit weniger eine abstrakte Zahl auf der Verpackung einer Grafikkarte.
Er definiert einen erheblichen Teil des Arbeitsraums, den deine lokale KI besitzt.
Je mehr davon vorhanden ist, desto flexibler kannst du zwischen:
Modellgröße,
Präzision,
Kontext
und:
Parallelität
abwägen.
Doch bevor man einfach immer mehr Grafikspeicher kauft, sollte man den wichtigsten Speicherhebel genauer verstehen:
Quantisierung.