VRAM-Rechner für LLM-Inferenz
Eingaben
| Parameter | 7 |
|---|---|
| Gewichtspräzision | FP16 / BF16 (16 Bit) |
| Laufzeit-Overhead | 20 % |
VRAM-Rechner für LLM-Inferenz
Schätzt aus Parameterzahl, Gewichtspräzision und Laufzeit-Overhead für KV-Cache, Aktivierungen und Fragmentierung den GPU-VRAM, der nötig ist, um ein großes Sprachmodell für die Inferenz bereitzustellen.
Eingaben
Modell
Laufzeit
Ergebnisse
Geben Sie einen Wert ein, um die Ergebnisse zu sehen.
Details
VRAM für LLM-Inferenz
Das Bereitstellen eines großen Sprachmodells beginnt mit einer schlichten Frage: Passt es auf die GPU? Die Antwort wird von den Gewichten des Modells dominiert, doch die Gewichte allein unterschätzen den Bedarf, denn ein Inferenzserver muss zusätzlich den KV-Cache, die durch jede Schicht fließenden Aktivierungen und etwas durch Fragmentierung verlorenen Speicher vorhalten. Dieser Rechner schätzt den gesamten VRAM aus drei Eingaben — der Parameterzahl, der Präzision, in der die Gewichte gespeichert sind, und einem Laufzeit-Overhead, der den Rest in einer einstellbaren Zahl bündelt.
Die Gewichte setzen die Untergrenze
Die Gewichte eines Modells sind sein größter fixer Speicherposten. Jeder Parameter wird in einer gewählten Präzision gespeichert: volle 16-Bit-Gewichte belegen je zwei Bytes, 8-Bit-Quantisierung ein Byte und 4-Bit ein halbes Byte. Eine Parameterzahl in Milliarden, bei Bit gespeichert, belegt also
W=8N⋅b GBEine Milliarde 16-Bit-Parameter sind exakt 2 GB, weshalb ein 7B-Modell allein für seine Gewichte 14 GB braucht. Die Division der Bitzahl durch acht wandelt Bit in Bytes um, und weil Parameter in Milliarden und Speicher in Gigabyte gezählt werden, passen die Einheiten direkt zusammen.
Laufzeit-Overhead hinzufügen
Die Gewichte sind nur die Untergrenze. Während der Inferenz hält der Server einen KV-Cache mit den Attention-Keys und -Values jedes Tokens im Umlauf vor, reserviert Aktivierungen, während jede Anfrage durch die Schichten läuft, und verliert etwas Speicher durch Fragmentierung. Die Summe ist
V=W⋅(1+o)wobei der Overhead ausgedrückt als Bruchteil der Gewichtsgröße ist. Der KV-Cache ist die größte und variabelste Komponente — er wächst mit der Kontextlänge und der Anzahl gleichzeitiger Anfragen — sodass der richtige Overhead stark von der Last abhängt. Zwanzig Prozent sind ein vernünftiger Ausgangspunkt für kurze Prompts bei mäßigen Batch-Größen; Serving mit langem Kontext und hohem Durchsatz kann ihn deutlich höher treiben.
Rechenbeispiel
Nehmen wir ein Modell mit 7 Milliarden Parametern, in 16-Bit-Präzision bereitgestellt, mit 20 Prozent Overhead:
WV=87×16=14 GB=14×(1+0,20)=16,8 GBDie 16,8 GB Gesamtbedarf passen bequem auf eine 24-GB-Karte, lassen auf einer 16-GB-Karte aber keinen Platz. Um dasselbe Modell auf einer kleineren GPU laufen zu lassen, würde ein Wechsel auf 8 Bit die Gewichte auf 7 GB halbieren und den Gesamtbedarf nahe 8,4 GB bringen. Der Zusammenhang zwischen Modellgröße und Präzision wird im Modellgröße aus Quantisierung berechnen weiter vertieft.
Ein Modell zum Passen bringen
Da der Speicher direkt mit den Bits pro Gewicht skaliert, ist Quantisierung der direkteste Hebel: 16 Bit auf 8 Bit halbiert den Gewichtsspeicher, 8 Bit auf 4 Bit halbiert ihn erneut, meist mit einem mäßigen und akzeptablen Verlust an Ausgabequalität. Wenn selbst ein quantisiertes Modell einen einzelnen Beschleuniger übersteigt, bleiben als Alternativen das Verteilen der Gewichte über mehrere GPUs (Sharding) oder das Auslagern eines Teils des Modells in den Systemspeicher unter hohem Geschwindigkeitsverlust. Wie viele Beschleuniger ein Modell braucht, behandelt der GPU-Anzahl für Modell berechnen. Behandeln Sie den Wert hier als Planungsschätzung und bestätigen Sie ihn an einem echten Serving-Lauf, da Framework, Kontextlänge und Batch-Größe die tatsächliche Zahl verschieben.
Häufig gestellte Fragen (FAQ)
Was deckt der Laufzeit-Overhead ab?
Über die Gewichte hinaus muss ein Inferenzserver den KV-Cache vorhalten, der die Attention-Keys und -Values für jedes Token im Umlauf speichert, die Aktivierungen, die entstehen, während jede Anfrage durch die Schichten fließt, und etwas Reserve, die durch Speicherfragmentierung verloren geht. Der KV-Cache ist der größte und variabelste Teil: Er wächst mit der Kontextlänge und der Anzahl gleichzeitiger Anfragen, sodass ein Server, der lange Prompts oder große Batches verarbeitet, weit mehr brauchen kann als die voreingestellten zwanzig Prozent vermuten lassen.
Der einzelne Overhead-Prozentsatz fasst all das in einer einstellbaren Zahl zusammen.
Wie erkenne ich, ob ein Modell auf eine bestimmte GPU passt?
Vergleichen Sie die VRAM-Gesamtschätzung mit dem Speicher des Zielbeschleunigers und lassen Sie einen Puffer für Betriebssystem und Treiber. Ein Modell mit 7 Milliarden Parametern in 16 Bit benötigt mit Overhead rund 17 GB, was auf einer 24-GB-Karte bequem passt, auf einer 16-GB-Karte aber nicht.
Übersteigt die Schätzung eine einzelne GPU, muss das Modell quantisiert, über mehrere GPUs verteilt (Sharding) oder unter hohem Geschwindigkeitsverlust teilweise in den Systemspeicher ausgelagert werden.
Wie viel Speicher spart Quantisierung?
Der Speicher skaliert direkt mit den Bits pro Gewicht, also halbiert der Wechsel von 16 Bit auf 8 Bit den Gewichtsspeicher und der Wechsel auf 4 Bit viertelt ihn. Ein Modell mit 13 Milliarden Parametern braucht in 16 Bit etwa 26 GB Gewichte, aber nur 13 GB in 8 Bit und rund 6,5 GB in 4 Bit, jeweils vor Overhead.
Geringere Präzision lässt größere Modelle auf kleinere Karten passen, mit einem mäßigen, bei 8 Bit und 4 Bit meist akzeptablen Verlust an Ausgabequalität.
Haftungsausschluss
Dies ist eine Schätzung erster Ordnung. Der tatsächliche VRAM hängt vom Serving-Framework, der Kontextlänge, der Batch-Größe und der KV-Cache-Präzision ab, hier alle in einen einzigen Overhead-Prozentsatz gefaltet. Dimensionieren Sie die Hardware mit Reserve und bestätigen Sie sie mit einer echten Last, bevor Sie sich festlegen.