Für ein kleineres 7B-Modell kann eine einzelne GPU mit ausreichend Speicher genügen. Wer für größere Modelle einen GPU Server mieten möchte, muss dagegen mit deutlich höheren Hardware-Anforderungen rechnen: Ein Modell der 70B-Klasse kann bereits mehrere Beschleuniger oder eine aggressive Quantisierung erfordern. Unter Production-Last kommt zum Speicherbedarf für die Modellgewichte zusätzlich Speicher für den KV Cache und weitere Inferenzoperationen hinzu.
Die Frage „Welche GPU brauche ich für eine LLM?“ sollte deshalb anhand von vier Parametern beantwortet werden: Modellgröße, Präzision der Gewichte, Kontextlänge und erwartete parallele Last.
Warum die Anzahl der Parameter den Speicherbedarf bestimmt
Bezeichnungen wie 7B, 13B, 32B oder 70B geben die ungefähre Anzahl der Modellparameter in Milliarden an. Jeder dieser Parameter muss während der Inferenz im Speicher gehalten werden.
Vereinfacht lässt sich der Speicherbedarf allein für die Gewichte mit folgender Formel abschätzen:
Memory ≈ Parameters × Bytes per parameter
Bei FP16 oder BF16 werden ungefähr 2 Byte pro Parameter benötigt. Die Gewichte eines 7B-Modells belegen daher etwa 14 GB, bei 32B sind es rund 64 GB und bei 70B etwa 140 GB.
Bei einer 8-Bit-Darstellung reduziert sich der ungefähre Speicherbedarf etwa um die Hälfte: 7B benötigt rund 7 GB, 70B etwa 70 GB. Bei einer 4-Bit-Quantisierung beträgt die theoretische Größe der Gewichte ungefähr 3,5 beziehungsweise 35 GB.
Dies ist lediglich eine grundlegende Schätzung. Der tatsächliche VRAM-Verbrauch liegt aufgrund von Metadaten, KV Cache, Besonderheiten des Modellformats und des verwendeten Inference Frameworks höher. Eine GPU sollte daher nicht mit einer Speicherkapazität gewählt werden, die exakt der berechneten Größe der Modellgewichte entspricht.
Quantisierung: Wie sich ein großes Modell in weniger VRAM unterbringen lässt
Bei der Quantisierung wird die Präzision der Darstellung der Modellgewichte reduziert. Anstelle von FP16/BF16 können FP8, INT8, INT4 und verschiedene spezialisierte Formate verwendet werden.
Der wichtigste praktische Vorteil ist der geringere Speicherbedarf. Ein 70B-Modell in FP16 benötigt beispielsweise rund 140 GB allein für die Gewichte und passt damit nicht auf eine einzelne GPU mit 80–96 GB VRAM. Nach einer 8- oder 4-Bit-Quantisierung sinken die Anforderungen erheblich.
Eine kleinere Modellrepräsentation bedeutet jedoch nicht, dass Performance und Qualität vollständig unverändert bleiben. Das Ergebnis hängt vom Modell, von der Quantisierungsmethode, der Hardware und der verwendeten Inference Engine ab.
Quantisierung erfüllt daher zwei unterschiedliche Aufgaben:
- Sie ermöglicht den Betrieb eines Modells auf einer GPU mit weniger VRAM.
- Sie schafft mehr verfügbaren Speicher für Kontext und parallele Anfragen.
Für einen lokalen Assistenten oder ein internes Tool kann ein 4-Bit-Modell eine sinnvolle Lösung sein. Bei Production-Systemen, bei denen Qualität, Throughput und vorhersehbare Performance wichtig sind, muss die konkrete Kombination aus Modell, Format und Hardware getestet werden.
Warum VRAM nicht nur für die Modellgewichte benötigt wird
Nach dem Laden des Modells wird der freie GPU-Speicher nicht ausschließlich für Berechnungen verwendet. Bei der autoregressiven Inferenz spielt der KV Cache eine wesentliche Rolle. Er speichert die Keys und Values des Attention-Mechanismus für bereits verarbeitete Tokens.
Je länger der Kontext und je mehr Sequenzen gleichzeitig verarbeitet werden, desto mehr Speicher benötigt der KV Cache.
Das bedeutet, dass zwei Server mit demselben Modell völlig unterschiedliche VRAM-Anforderungen haben können. Ein lokaler Chatbot mit einem einzelnen Nutzer und einem Kontext von 4K Tokens erzeugt eine deutlich geringere Last als eine API, die gleichzeitig Dutzende Anfragen mit langen Kontexten verarbeitet.
Nach der Berechnung des Speicherbedarfs für die Modellgewichte muss deshalb zusätzlicher Speicher eingeplant werden für:
- KV Cache;
- Zwischenberechnungen;
- Inference Framework;
- parallele Anfragen.
Für Production Inference sollte der VRAM-Bedarf anhand des tatsächlichen Anfrageprofils und nicht allein anhand der Größe der Modelldatei berechnet werden.
7B–8B: Eine GPU für die meisten Szenarien
Modelle dieser Klasse sind für den Betrieb einer eigenen Inferenzumgebung am einfachsten zugänglich.
In FP16/BF16 belegen allein die Modellgewichte ungefähr 14–16 GB. In der Praxis ermöglicht eine GPU mit 24 GB VRAM bereits den Betrieb vieler Modelle dieser Größe mit zusätzlicher Speicherreserve für die Inferenz. Die verfügbare Kontextlänge und Concurrency hängen jedoch von der Modellarchitektur und dem Software Stack ab.
Durch Quantisierung lassen sich die Anforderungen weiter reduzieren. 8-Bit- oder 4-Bit-Varianten können auf GPUs mit weniger Speicher betrieben werden, sofern das gewählte Framework und der Beschleuniger das entsprechende Format unterstützen.
Bei einem Production-Service ist zusätzlicher VRAM nicht nur für das Modell selbst nützlich. Er ermöglicht einen größeren KV Cache und die Verarbeitung einer höheren Zahl gleichzeitiger Anfragen.
Die minimale Konfiguration, auf der ein Modell gestartet werden kann, und die optimale Konfiguration für Production sind daher zwei unterschiedliche Dinge.
13B–14B: Der VRAM-Bedarf steigt deutlich
Bei einem Modell mit etwa 13–14 Milliarden Parametern werden in FP16/BF16 bereits ungefähr 26–28 GB allein für die Modellgewichte benötigt. Eine einzelne GPU mit 24 GB VRAM reicht für eine solche Konfiguration ohne Quantisierung nicht mehr aus.
Mögliche Lösungen sind eine GPU mit mehr VRAM, Quantisierung oder die Verteilung des Modells auf mehrere Beschleuniger.
Bei 8-Bit-Gewichten sinkt der Richtwert auf etwa 13–14 GB und bei 4-Bit auf rund 7 GB, jeweils ohne zusätzlichen Speicherbedarf. Dadurch werden Modelle dieser Klasse deutlich besser für Single-GPU-Inferenz zugänglich.
Bei der Entscheidung zwischen 7B und 14B sollte jedoch nicht nur berücksichtigt werden, ob das Modell in den Speicher passt. Ein größeres Modell benötigt für jedes generierte Token mehr Rechenleistung. Die gleiche Menge an VRAM bedeutet daher nicht automatisch die gleiche Inferenzgeschwindigkeit.
30B–32B: Die Grenze für Single-GPU hängt vom Modellformat ab
Ein Modell der 32B-Klasse benötigt in FP16/BF16 ungefähr 64 GB für die Gewichte. Eine solche Konfiguration ist bereits auf GPUs mit großer Speicherkapazität oder auf ein Multi-GPU-Setup ausgerichtet.
Bei 8-Bit sinkt der Speicherbedarf der Gewichte auf etwa 32 GB, bei 4-Bit auf rund 16 GB. Theoretisch lässt sich ein quantisiertes Modell damit auf einer einzelnen GPU unterbringen, doch die Speicherkapazität ist nur die erste Einschränkung.
Für Production müssen zusätzlich Throughput, Größe des KV Cache und die Anzahl der Nutzer berücksichtigt werden. Eine Konfiguration, auf der ein 32B-Modell erfolgreich läuft, kann für die erforderliche Anzahl von Anfragen dennoch zu langsam sein.
Auf dieser Ebene ist es besonders wichtig, zwischen „Das Modell passt in den VRAM“ und „Der Server liefert die erforderliche Performance“ zu unterscheiden.
70B: Wann Multi-GPU erforderlich wird
Bei einem 70B-Modell belegen die Gewichte ungefähr 140 GB in FP16/BF16, rund 70 GB bei 8-Bit und theoretisch etwa 35 GB bei einer 4-Bit-Darstellung. Hinzu kommt der Speicherbedarf für den KV Cache und die Inference Engine.
Daher erfordert FP16/BF16-Inferenz in der Regel eine Verteilung des Modells auf mehrere GPUs. Quantisierung reduziert den VRAM-Bedarf erheblich und kann es in bestimmten Konfigurationen ermöglichen, ein 70B-Modell auf einem einzelnen Beschleuniger mit großer Speicherkapazität unterzubringen.
Die Möglichkeit, ein Modell zu laden, und die Möglichkeit, es effizient in Production einzusetzen, sind jedoch zwei unterschiedliche Dinge. Wenn die Modellgewichte fast den gesamten VRAM belegen, bleibt weniger Speicher für KV Cache, lange Kontexte und parallele Anfragen. Deshalb können auch für ein quantisiertes Modell mehrere GPUs erforderlich sein.
Wie ein Modell auf mehrere GPUs verteilt wird
Wenn eine LLM nicht auf einen einzelnen Beschleuniger passt oder dessen Performance nicht ausreicht, können die Berechnungen auf mehrere GPUs verteilt werden.
Ein verbreiteter Ansatz ist Tensor Parallelism, bei dem einzelne Berechnungen innerhalb des Modells parallel auf mehreren Beschleunigern ausgeführt werden.
Bei einer solchen Konfiguration ist nicht nur die Leistung der GPUs entscheidend, sondern auch die Geschwindigkeit des Datenaustauschs zwischen ihnen. Bei der Planung des Servers müssen deshalb die PCIe-Topologie und verfügbare High-Speed-Interconnects berücksichtigt werden. Mehrere leistungsfähige GPUs sorgen nicht zwangsläufig für einen proportionalen Performance-Zuwachs, wenn der Datenaustausch zwischen ihnen zum Bottleneck wird.
Wird die Inferenz auf mehrere Server verteilt, gewinnen zusätzlich die Netzwerkbandbreite und die Latenz zwischen den Nodes an Bedeutung.
CPU, RAM und Storage: Was außer der GPU benötigt wird
Bei GPU-Inferenz entfällt der größte Teil der Rechenlast auf die Beschleuniger. Die übrigen Komponenten des Servers beeinflussen jedoch ebenfalls die Performance des Systems.
Die CPU übernimmt das Betriebssystem, die API, Tokenization, Preprocessing und weitere Prozesse. Ihre Leistung muss ausreichen, damit die Vorbereitung der Anfragen die GPUs nicht ausbremst.
System-RAM wird für das Laden des Modells, die Inference Engine und begleitende Services benötigt. Bei CPU Offloading steigt der Arbeitsspeicherbedarf zusätzlich.
Der Storage muss ein schnelles Laden großer Modelldateien ermöglichen. Für solche Systeme sind NVMe-SSDs in der Regel die bevorzugte Lösung, insbesondere wenn mehrere LLMs auf dem Server gespeichert werden oder Modelle häufig neu geladen werden.
Nachdem das Modell in den VRAM geladen wurde, hat die Geschwindigkeit des Systemlaufwerks einen deutlich geringeren direkten Einfluss auf die Token-Generierung.
Wie viel Speicher Modelle von 7B bis 70B benötigen
Für eine erste Einschätzung kann zunächst nur der Speicherbedarf für die Modellgewichte berechnet werden. Diese Werte stellen keine Mindestanforderungen an den VRAM dar: Für die tatsächliche Inferenz ist zusätzlicher Speicher erforderlich.
Als Richtwerte gelten:
- 7B: etwa 14 GB in FP16/BF16, 7 GB bei 8-Bit und 3,5 GB bei 4-Bit;
- 14B: etwa 28 GB in FP16/BF16, 14 GB bei 8-Bit und 7 GB bei 4-Bit;
- 32B: etwa 64 GB in FP16/BF16, 32 GB bei 8-Bit und 16 GB bei 4-Bit;
- 70B: etwa 140 GB in FP16/BF16, 70 GB bei 8-Bit und 35 GB bei 4-Bit.
Dabei handelt es sich ausschließlich um die Größe der Modellgewichte in einer vereinfachten Berechnung. Zusätzlich muss VRAM für KV Cache, Runtime und weitere Operationen eingeplant werden. Je länger der Kontext und je höher die Concurrency, desto größer muss diese Reserve sein.
Ein 32B-Modell im 4-Bit-Format benötigt theoretisch etwa 16 GB für seine Gewichte. Das bedeutet jedoch nicht, dass eine GPU mit 16 GB VRAM für einen vollwertigen Betrieb ausreicht. Ebenso sollte ein 70B-Modell in 4-Bit nicht automatisch als „Modell für eine GPU mit 35 GB“ betrachtet werden.
Was außer Tokens per Second gemessen werden sollte
Die Anzahl der generierten Tokens pro Sekunde ist eine wichtige, aber nicht die einzige Kennzahl für die Performance einer LLM.
Für Production Inference sollten zusätzlich folgende Werte gemessen werden:
- TTFT (Time to First Token) – die Zeit vom Absenden der Anfrage bis zum Erscheinen des ersten Tokens der Antwort;
- TPOT (Time per Output Token) – die Zeit für die Generierung der nachfolgenden Tokens;
- Throughput – die Menge an Anfragen oder Tokens, die das System pro Zeiteinheit verarbeiten kann;
- Concurrency – die Anzahl der gleichzeitig verarbeiteten Anfragen;
- Gesamtlatenz – die Zeit für die Bearbeitung einer Anfrage vom Start bis zum Abschluss.
Eine Konfiguration kann für einen einzelnen Nutzer sehr schnell Antworten generieren, bei einer steigenden Zahl paralleler Anfragen jedoch deutlich an Performance verlieren. Benchmarks sollten deshalb mit Prompt- und Output-Längen sowie einer Concurrency durchgeführt werden, die möglichst nah an der tatsächlichen Last des zukünftigen Services liegen.
Warum Single-User- und Production-Szenarien unterschiedliche Konfigurationen erfordern
Für einen lokalen LLM-Assistenten reicht es häufig aus, wenn das Modell in den VRAM passt und eine akzeptable Generierungsgeschwindigkeit erreicht. Durch Quantisierung lassen sich die Hardware-Anforderungen erheblich reduzieren.
In Production ändern sich die Anforderungen. Eine einzelne Modellinstanz muss zahlreiche Anfragen verarbeiten, Batching nutzen und auch bei steigender Last akzeptable TTFT- und Throughput-Werte beibehalten.
Besonders deutlich wird dies bei großen Modellen. Wenn beispielsweise die Gewichte eines quantisierten 70B-Modells einen erheblichen Teil des verfügbaren VRAM belegen, bleibt weniger Speicher für den KV Cache. Dadurch wird entweder die Kontextlänge oder die Anzahl gleichzeitig verarbeitbarer Sequenzen begrenzt.
Ein Production-Server wird deshalb nicht für die minimale Konfiguration ausgelegt, auf der das Modell gerade noch läuft, sondern für die erforderliche Performance des Services.