GPU für LLM-Inferenz: Speicher, Durchsatz, Kosten

Die meisten Fehler bei der GPU-Dimensionierung für die Inferenz großer Sprachmodelle passieren, bevor überhaupt Hardware bestellt wird. Ein Team wählt ein Modell, findet eine GPU mit genug Speicher, um es zu laden, und hält die Aufgabe für erledigt.

Das Laden des Modells ist nur die erste Einschränkung. Die Kapazität für Inferenz wird von drei Faktoren gemeinsam bestimmt: Speicher für die Gewichte, Speicher für den Attention-Cache jeder aktiven Anfrage und die Rate, mit der die GPU unter dem zugesagten Latenzziel Tokens erzeugen kann.

Beginnen Sie mit dem Workload, nicht mit der GPU

Bevor Sie Beschleuniger vergleichen, halten Sie schriftlich fest, was der Dienst leisten muss.

• Modell und Präzision. Parameterzahl, Architektur (Layer, Attention Heads, Key/Value Heads, Head-Dimension) und die Präzision, mit der Sie bereit sind, das Modell zu betreiben.
• Kontextlängen. Die typische Zahl und das 95. Perzentil der Eingabe-Tokens pro Anfrage sowie die typische und die maximale Ausgabelänge.
• Traffic-Profil. Anfragen pro Sekunde in der Stunde mit der höchsten Last, nicht im Tagesdurchschnitt, und wie steil die Spitzen ausfallen.
• Latenzziele. Time to First Token (wie lange es dauert, bis der Nutzer etwas sieht) und Zeit pro Ausgabe-Token (wie schnell der Text danach gestreamt wird).
• Isolation und Standort. Ob Prompts und Ausgaben eine bestimmte Umgebung oder ein bestimmtes Land verlassen dürfen, was geteilte Kapazität unabhängig vom Preis ausschließen kann.

Interaktiver Chat, Retrieval-gestützte Suche, Dokumentzusammenfassung und Offline-Batch-Scoring können dasselbe Modell mit völlig unterschiedlichem Hardwarebedarf betreiben. Ein Zusammenfassungsjob mit 8.000 Eingabe-Tokens und einer Antwort von 200 Tokens belastet andere Teile des Systems als ein Chat-Assistent mit 1.000 Eingabe-Tokens und 600 Ausgabe-Tokens.

Speicher, Teil eins: die Modellgewichte

Multiplizieren Sie die Parameterzahl mit den Bytes pro Parameter für die Präzision, mit der Sie das Modell betreiben. Die gängigen Faustregeln sind 2 Bytes pro Parameter in FP16 oder BF16, 1 Byte in INT8 oder FP8 und etwa 0,5 Bytes in 4-Bit-Formaten, zuzüglich eines kleinen Anteils für die Quantisierungsskalen.

• 8B Parameter. Etwa 16 GB in FP16, 8 GB in INT8, 4 bis 5 GB in INT4.
• 70B Parameter. Etwa 140 GB in FP16, 70 GB in INT8, 35 bis 40 GB in INT4.
• Parameter der 400B-Klasse. Etwa 800 GB in FP16, 400 GB in INT8, 200 bis 230 GB in INT4. Das bedeutet selbst quantisiert einen Node mit mehreren GPUs.

CUDA-Kontext, Aktivierungspuffer, Kommunikationspuffer für Tensor-Parallelität und Fragmentierung belegen typischerweise mehrere Gigabyte pro GPU. Serving-Engines wie vLLM lassen Sie den Anteil des GPU-Speichers festlegen, den sie belegen dürfen; ein Planungswert von 85 bis 90 Prozent des physischen Speichers als nutzbar ist ein vernünftiger Ausgangspunkt.

8-Bit-Gewichte werden breit eingesetzt und zeigen bei den meisten Aufgaben nur geringe messbare Verluste. 4-Bit-Gewichte halbieren den Speicherbedarf noch einmal, können aber Reasoning, Code und mehrsprachige Ausgaben deutlicher verschlechtern. Evaluieren Sie daher mit Ihren eigenen Prompts, bevor Sie Kapazität darauf aufbauen.

Speicher, Teil zwei: Der KV cache bestimmt die Nebenläufigkeit

Während der Generierung behält jede Anfrage die Attention-Keys und -Values für jedes Token, das sie gesehen hat. Dieser KV cache wächst mit der Kontextlänge und der Zahl gleichzeitiger Anfragen und belegt auf einem ausgelasteten Server oft mehr Speicher als die Gewichte.

Die Größe pro Token beträgt: 2 (ein Key und ein Value) mal die Zahl der Layer, mal die Zahl der Key/Value-Heads, mal die Head-Dimension, mal Bytes pro Element. Für ein typisches Modell der 70B-Klasse mit Grouped-Query Attention (80 Layer, 8 Key/Value-Heads, Head-Dimension 128) in FP16 sind das 2 x 80 x 8 x 128 x 2 Bytes, etwa 320 KB pro Token.

Bei 320 KB pro Token belegt eine Anfrage mit 4.000 Tokens Kontext etwa 1,3 GB. Fünfzig solcher Anfragen benötigen etwa 65 GB, fast so viel wie die INT8-Gewichte selbst.

• Seitenweise Allokation. Engines, die den Cache in kleinen Blöcken allokieren (Paged Attention), reservieren nur Speicher für Tokens, die tatsächlich existieren. Sie können also mit dem durchschnittlichen statt dem maximalen Kontext planen, mit einer Reserve für lange Anfragen.
• Cache-Quantisierung. Wird der KV cache in FP8 gespeichert, halbiert sich sein Platzbedarf ungefähr und die Zahl der Sequenzen, die hineinpassen, verdoppelt sich, meist bei moderatem Qualitätsverlust, der getestet werden sollte.
• Prefix Caching. Wenn viele Anfragen einen langen System-Prompt oder ein Dokument teilen, spart die Wiederverwendung der gecachten Keys und Values sowohl Speicher als auch Prefill-Rechenleistung.
• Kontextgrenzen. Den maximalen Kontext pro Anfrage zu begrenzen ist oft der günstigste Kapazitätshebel überhaupt, weil eine Handvoll sehr langer Anfragen alle anderen ausbremsen kann.

Durchsatz, Latenz und Batching

Inferenz hat zwei Phasen mit unterschiedlichen Engpässen. Prefill verarbeitet den gesamten Prompt auf einmal und ist durch die Rechenleistung begrenzt; eine brauchbare Näherung sind 2 Gleitkommaoperationen pro Parameter und Token, sodass ein 70B-Modell für jedes Eingabe-Token etwa 140 GFLOP benötigt. Decode erzeugt anschließend pro Anfrage ein Token nach dem anderen und ist durch die Speicherbandbreite begrenzt, weil jeder Schritt die Gewichte und den KV cache der Anfrage aus dem GPU-Speicher liest.

Daraus ergibt sich eine einfache Obergrenze für die Geschwindigkeit eines einzelnen Streams: Speicherbandbreite geteilt durch die pro Token gelesenen Bytes. Ein Modell mit 70 GB INT8-Gewichten, verteilt auf zwei GPUs mit je etwa 2 TB/s, kann die vollständigen Gewichte höchstens rund 57-mal pro Sekunde lesen. Eine einzelne Anfrage kann auf diesem Setup also nicht schneller als etwa 57 Tokens pro Sekunde streamen, und in der Praxis liegt der Wert darunter.

Batching macht Inferenz wirtschaftlich. Continuous Batching, inzwischen Standard in Engines wie vLLM und Triton-basierten Stacks, nimmt neue Anfragen bei jedem Schritt in den laufenden Batch auf, statt zu warten, bis ein Batch abgeschlossen ist. Der Gesamtdurchsatz steigt mit der Batchgröße steil an, bis der KV cache voll ist oder die Rechenleistung zum Engpass wird.

Der Preis des Batchings ist Latenz. Kapazitätsplanung ist daher eine Abwägung: Wählen Sie den größten Batch, der Ihre Ziele für die Zeit bis zum ersten Token und die Zeit pro Ausgabe-Token beim 95. Perzentil noch erfüllt, und dimensionieren Sie die Flotte nach dem Durchsatz, den Sie an diesem Punkt messen, nicht nach dem Spitzendurchsatz in einem Benchmark-Diagramm.

Parallelität aus dem Datenverkehr abschätzen

Die Parallelität, also die Zahl der gleichzeitig laufenden Anfragen, ist das, was KV cache und Batch-Plätze verbraucht. Sie lässt sich mit Littles Gesetz abschätzen: Die durchschnittliche Parallelität entspricht der Ankunftsrate multipliziert mit der durchschnittlichen Zeit, die jede Anfrage im System verbringt.

Wenn der Spitzen-Traffic 5 Anfragen pro Sekunde beträgt und jede Anfrage vom Eingang bis zum letzten Token 14 Sekunden dauert (etwa 1 Sekunde Warteschlange und Prefill plus 400 Ausgabe-Tokens bei 30 Tokens pro Sekunde), hält das System etwa 70 Anfragen gleichzeitig. Multiplizieren Sie das mit der durchschnittlichen Zahl der pro Anfrage gehaltenen Tokens und der KV-Größe pro Token, und Sie erhalten den Cache-Speicher, den die Spitzenlast erfordert.

• Mit der Spitze rechnen, nicht mit dem Durchschnitt. Interaktiver Traffic liegt in der Stunde mit der höchsten Last häufig beim Zwei- bis Vierfachen seines Tagesdurchschnitts.
• Die Ausgabelänge im Blick behalten. Die Parallelität wächst mit der Dauer, die Anfragen offen bleiben, und Ausgabe-Tokens sind der langsame Teil. Eine Verdopplung der durchschnittlichen Ausgabelänge verdoppelt die Parallelität daher ungefähr.
• Retries und Agenten einrechnen. Agenten mit Tool-Aufrufen und automatische Wiederholungen können pro Nutzeraktion mehrere Modellaufrufe auslösen und so die effektive Ankunftsrate vervielfachen.

Ein durchgerechnetes Beispiel

Betrachten Sie einen internen Assistenten auf Basis eines Modells der 70B-Klasse mit Grouped-Query Attention, betrieben mit Gewichten in INT8 und einem KV cache in FP16. Die Spitzenlast beträgt 5 Anfragen pro Sekunde. Anfragen umfassen im Schnitt 2.000 Eingabe-Tokens und 400 Ausgabe-Tokens. Die Ziele lauten unter 1,5 Sekunden bis zum ersten Token und mindestens 25 Tokens pro Sekunde Streaming im 95. Perzentil. Die vorgesehene Hardware sind GPUs mit 80 GB und jeweils rund 2 TB/s Speicherbandbreite.

• Gewichte. 70B Parameter mit je 1 Byte ergeben etwa 70 GB. Eine GPU mit 80 GB kann das nicht zusätzlich zu einem sinnvollen Cache aufnehmen, daher ist die kleinste Einheit zwei GPUs mit Tensor-Parallelität: 160 GB physisch, etwa 144 GB nutzbar bei 90 Prozent.
• Cache-Budget. 144 GB abzüglich 70 GB Gewichte lassen etwa 74 GB für den KV cache.
• Cache-Bedarf. Nach Littles Gesetz etwa 70 gleichzeitige Anfragen. Jede hält an ihrem Ende rund 2.400 Tokens, bei 320 KB pro Token etwa 0,8 GB, sodass der Spitzenbedarf bei etwa 55 GB liegt. Das passt, mit etwa 25 Prozent Reserve.
• Decode-Geschwindigkeit. Jeder Schritt liest etwa 35 GB Gewichte pro GPU plus den Cache-Anteil dieser GPU, in der Spitze etwa 27 GB. Bei 2 TB/s sind das rund 31 ms pro Schritt vor Overhead, also etwa 30 Tokens pro Sekunde pro Stream und insgesamt etwa 2.000 Ausgabe-Tokens pro Sekunde. Das sind genau die 2.000 Tokens pro Sekunde, die die Spitze erfordert, ohne jede Reserve.
• Prefill-Last. 5 Anfragen x 2.000 Tokens ergeben 10.000 Eingabe-Tokens pro Sekunde, etwa 1,4 PFLOP/s an Rechenarbeit. Das konkurriert mit dem Decode um dieselben GPUs und drückt das Streaming bei Lastspitzen unter den Zielwert.

Das Ergebnis: Ein Replikat mit zwei GPUs fasst Modell und Cache, hat aber in der Spitze keine Durchsatzreserve und keine Redundanz. Zwei Replikate, insgesamt vier GPUs hinter einem Load Balancer, halbieren ungefähr die Last pro Replikat, halten die Latenz bei Lastspitzen im Zielbereich und erlauben es, in ruhigeren Stunden ein Replikat für Wartungsarbeiten zu leeren.

Auslastung, horizontale Skalierung und Kosten pro Million Tokens

Die von Monitoring-Tools gemeldete prozentuale GPU-Auslastung kann täuschen, denn eine GPU, die für einen Batch der Größe eins Speicher liest, wirkt voll ausgelastet, leistet aber wenig Nützliches. Verfolgen Sie stattdessen die Metriken, die der Kapazität entsprechen: erzeugte Tokens pro Sekunde, Belegung des KV cache, wartende Anfragen in der Queue und Latenzperzentile für die Zeit bis zum ersten Token und die Zeit pro Ausgabe-Token.

• Horizontal skalieren, wenn sich Warteschlangen bilden. Anhaltende Warteschlangen in der Spitze oder eine KV-cache-Belegung über etwa 90 Prozent mit verdrängten Anfragen bedeuten, dass das Replikat voll ist.
• Horizontal skalieren, wenn die Latenz abdriftet. Nähert sich das 95. Perzentil der Zeit pro Ausgabe-Token dem Zielwert, während der Durchsatz stagniert, ist der Batch für das Replikat zu groß.
• Stattdessen vertikal skalieren, wenn das Modell nicht passt. Mehr Speicher pro GPU oder mehr GPUs pro Replikat helfen, wenn Gewichte und Mindest-Cache nicht hineinpassen oder lange Kontexte dominieren.
• N+1 beibehalten. Ein wichtiger Dienst sollte den Ausfall eines Replikats unter Spitzenlast überstehen. Das bestimmt die Zahl der Replikate meist stärker als der reine Durchsatz.

Die Kosten pro Million Tokens ergeben sich direkt aus diesen Zahlen: Teilen Sie die stündlichen Kosten der Flotte durch die Millionen Tokens, die sie pro Stunde erzeugt. Bei rein hypothetischen 2,50 $ pro GPU-Stunde kostet das Beispiel mit vier GPUs 10 $ pro Stunde. Bei voller Spitzenausgabe von 2.000 Tokens pro Sekunde erzeugt es 7,2 Millionen Ausgabe-Tokens pro Stunde, etwa 1,40 $ pro Million. Liegt die durchschnittliche Last über den Tag bei 30 Prozent der Spitze, erzeugt dieselbe Flotte etwa 2,2 Millionen Tokens pro Stunde, und die effektiven Kosten steigen auf etwa 4,60 $ pro Million.

Die Auslastung bestimmt die Stückkosten stärker als der Stundenpreis. Workloads, die sich verschieben lassen, etwa Batch-Zusammenfassungen, das Nachberechnen von Embeddings oder Evaluierungsläufe, können ungenutzte Stunden auf interaktiver Kapazität füllen und die Mischkosten senken.

Checkliste für die Kapazitätsplanung

• Parameter, Layer, Key/Value-Heads und Head-Dimension dokumentieren.
• Legen Sie die Präzision für Gewichte und KV cache fest. Testen Sie die Qualität mit eigenen Prompts.
• Berechnen Sie Gewichtsspeicher und Mindestzahl an GPUs pro Replikat. 10 bis 15 Prozent Reserve für Overhead.
• Bytes des KV cache pro Token und Restbudget nach den Gewichten berechnen.
• Messen oder schätzen Sie Spitzen-RPS sowie durchschnittliche Ein- und Ausgabe-Tokens.
• Mit Littles Gesetz Spitzenparallelität und nötigen Cache abschätzen.
• Legen Sie p95-Ziele für die Zeit bis zum ersten Token und die Zeit pro Ausgabe-Token fest.
• Benchmarken Sie die Engine bei Zielparallelität. Halten Sie die dauerhaften Tokens/s pro Replikat fest.
• Replikate nach Spitzendurchsatz mit Reserve bemessen, plus eines für N+1.
• Begrenzen Sie Kontext und Ausgabe pro Anfrage. Prefix Caching für wiederholte Prompts.
• Skalieren Sie nach Queue-Tiefe, Cache-Belegung und Latenz, nicht nur nach GPU-Auslastung.
• Berechnen Sie die Kosten pro Million Tokens in Spitze und Durchschnitt. Batch in lastarmen Stunden.
• Klären Sie, wo Prompts, Ausgaben und Gewichte liegen dürfen, dann wählen Sie den Standort.

Wie Vonahost unterstützen kann

Vonahost bietet GPU-Kapazität pro Projekt an, wobei GPU-Modell, Anzahl und Lieferzeit schriftlich bestätigt werden, und unterstützt private Deployments, bei denen Daten und Modelle in der Umgebung des Kunden bleiben. Die Deployments nutzen Standardwerkzeuge wie PyTorch, vLLM, Triton und Kubernetes, sodass sich die oben beschriebene Dimensionierungsmethode direkt auf einen Benchmark mit der angebotenen Hardware übertragen lässt.

Jedes Angebot von Vonahost nennt Konfiguration, Standort, Verantwortlichkeiten und Monatspreis in US-Dollar, und Kunden wählen das Land, in dem jeder Server läuft.