Wie viele GPUs braucht ein LLM für 140 Nutzer? (2026)

Pexon Consulting | 8 Min. Lesezeit | 14.07.2026

TL;DR

Für 140 gleichzeitige Nutzer auf einem Modell der 30B-Klasse reichen zwei RTX PRO 6000 (je 96 GB). Die Nutzerzahl hängt nicht am Modellgewicht, sondern am KV-Cache: Kontextlänge mal aktive Anfragen bestimmt den VRAM-Bedarf. Pexon Consulting (80 Mitarbeiter, Microsoft Partner) dimensioniert und betreibt solche Stacks. Bei langem Kontext kippt die Rechnung schnell.

Die Frage ist falsch gestellt

Die kurze Antwort auf „wie viele GPUs für 140 Nutzer“: Es kommt auf die Kontextlänge an, nicht auf die Nutzerzahl allein. Wir bekommen die Frage fast wöchentlich, und fast immer fehlt in ihr die wichtigste Angabe.

140 Nutzer, die kurze Fragen an einen FAQ-Bot stellen, brauchen einen Bruchteil der Hardware von 140 Nutzern, die 50-seitige Verträge zusammenfassen lassen. Der Unterschied liegt im KV-Cache, dem Zwischenspeicher, den das Modell für jede laufende Anfrage vorhält. Und der wächst mit der Kontextlänge, nicht mit dem Modell.

Unsere klare Ansage: Bevor irgendjemand eine GPU-Zahl nennt, müssen drei Zahlen auf dem Tisch liegen. Modellgröße, durchschnittliche Kontextlänge und Zahl der gleichzeitig aktiven Anfragen. Ohne die ist jede GPU-Empfehlung geraten.

Der VRAM-Bedarf hat zwei Posten

Der Speicher einer GPU teilt sich für LLM-Inferenz in zwei Blöcke: die Modellgewichte und den KV-Cache. Die Gewichte sind ein fixer Sockel. Der KV-Cache ist der variable Teil, der mit jeder Anfrage wächst.

Die Modellgewichte ergeben sich aus Parameterzahl mal Bytes pro Parameter. Ein 30B-Modell in FP8 (ein Byte pro Parameter) belegt rund 30 GB. Dasselbe Modell in FP16 wären 60 GB. Genau deshalb quantisieren wir für Inferenz fast immer auf FP8 oder auf das neuere NVFP4, das die Blackwell-Generation (RTX PRO 6000, H200-Nachfolger) nativ unterstützt.

Der KV-Cache ist der Posten, den die meisten unterschätzen. Er berechnet sich pro Token und wird mit der Sequenzlänge und der Zahl der parallelen Anfragen multipliziert:

KV-Cache pro Token = 2 x num_kv_heads x head_dim x num_layers x bytes

Faustregel aus Benchmarks (FP8, GQA-Modell):
  8B-Modell:   ~64 KB pro Token
  30B-Modell:  ~150 KB pro Token
  70B-Modell:  ~320 KB pro Token

Gesamt-KV = KV pro Token x aktive Tokens x gleichzeitige Anfragen

Die Zahlen sind Näherungen und hängen von der Modell-Architektur ab, vor allem von Grouped-Query-Attention und der Kopf-Zahl. Aber die Größenordnung stimmt, und sie reicht für die Kapazitätsplanung.

Die Rechnung für 140 Nutzer

Rechnen wir den konkreten Fall durch: ein Modell der 30B-Klasse, 140 gleichzeitig aktive Nutzer, durchschnittlich 4.000 Token aktiver Kontext pro Anfrage. Das ist ein realistischer interner Wissens-Assistent.

Modellgewichte (30B, FP8):        30 GB
KV-Cache: 150 KB x 4.000 x 140 =  ~84 GB
Zwischensumme:                    ~114 GB
+ 30 % Headroom (Fragmentierung): ~148 GB

114 GB plus Reserve passen nicht auf eine einzelne RTX PRO 6000 mit 96 GB. Zwei Karten mit zusammen 192 GB tragen die Last mit komfortablem Puffer. Das deckt sich mit unserer Referenz-Konfiguration: ein 30B-Modell für rund 150 Nutzer läuft bei uns auf zwei RTX PRO 6000 für etwa 3.000 Euro externe Hardware-Kosten im Monat (Stand Juli 2026, Preise indikativ und nachfrageabhängig, bitte tagesaktuell anfragen).

Jetzt der Hebel, der alles verändert: dieselben 140 Nutzer bei 32.000 Token Kontext statt 4.000. Der KV-Cache steigt auf das Achtfache, rund 670 GB. Aus zwei Karten werden acht. Kontextlänge ist der teuerste Schalter im ganzen System, und niemand redet darüber.

Warum die Serving-Engine die Nutzerzahl verdoppelt

Dieselbe Hardware trägt völlig unterschiedliche Nutzerzahlen, je nach Serving-Engine. Das ist kein Detail, sondern der Faktor zwischen 16 und 150 gleichzeitigen Nutzern auf fast identischer Hardware.

Eine naive Implementierung reserviert den KV-Cache-Speicher pro Anfrage im Voraus und verschwendet damit den Großteil. vLLM (v0.x, rund 83.000 GitHub-Sterne, Stand Juni 2026) nutzt PagedAttention und teilt freien Speicher dynamisch auf. Der Unterschied in der Praxis: PagedAttention trennt 8 gleichzeitige Nutzer von 24 auf identischer Hardware, wie Benchmarks zeigen. Auf Blackwell-GPUs erreicht vLLM bei einem 70B-Modell mit NVFP4-Quantisierung über 8.000 Token pro Sekunde aggregiert.

Wir setzen für Produktions-Deployments fast durchgängig auf vLLM statt auf Ollama. Ollama (rund 176.000 GitHub-Sterne) ist hervorragend für die lokale Entwicklung und den Einzelnutzer, bricht aber unter echter Nebenläufigkeit ein. Für 140 Nutzer ist das keine Geschmacksfrage. Die Details zum Vergleich stehen im Beitrag zu SGLang und vLLM als Inference Engines.

Ein minimaler vLLM-Start für unseren 30B-Fall sieht so aus:

# Zwei-GPU-Setup, FP8-Quantisierung, OpenAI-kompatibler Endpunkt
vllm serve Qwen/Qwen3-30B 
  --tensor-parallel-size 2 
  --quantization fp8 
  --max-model-len 8192 
  --gpu-memory-utilization 0.90 
  --port 8000

Die drei Zahlen, die du vorher brauchst

Gutes LLM GPU Sizing beginnt mit drei Zahlen, nicht mit einer Hardware-Liste. Bevor wir eine GPU-Zahl nennen, klären wir immer dieselben drei Punkte. Wer sie kennt, kann das Sizing selbst grob überschlagen.

Erstens die Modellgröße in Milliarden Parametern und die Quantisierung. Das gibt den fixen VRAM-Sockel. Ein 8B-Modell reicht für Klassifikation und einfache Extraktion, ein 30B-Modell für einen guten Assistenten, ein 70B- oder Vision-Modell für anspruchsvolle Dokumenten-Aufgaben.

Zweitens die durchschnittliche und die maximale Kontextlänge. Das ist der größte Hebel auf den KV-Cache. Plane nicht mit dem Durchschnitt, sondern mit der 90-Prozent-Spitze, sonst kippt das System unter Last.

Drittens die Zahl der gleichzeitig aktiven Anfragen, nicht der registrierten Nutzer. Von 140 Mitarbeitern sind selten mehr als 20 bis 30 im selben Sekundenbereich aktiv. Genau diese Differenz zwischen Nutzern und aktiver Nebenläufigkeit entscheidet, ob zwei Karten reichen oder vier nötig sind.

Häufig gestellte Fragen

Wie viele GPUs braucht ein LLM für 140 gleichzeitige Nutzer?

Beim LLM GPU Sizing reichen für ein Modell der 30B-Klasse bei moderater Kontextlänge von rund 4.000 Token zwei RTX PRO 6000 mit je 96 GB. Bei langem Kontext von 32.000 Token steigt der Bedarf auf das Vier- bis Achtfache. Die Nutzerzahl allein bestimmt die GPU-Zahl nicht, entscheidend ist die Kontextlänge mal die gleichzeitig aktiven Anfragen.

Was kostet ein GPU-Server für 140 Nutzer im Monat?

Als grobe Indikation liegen zwei RTX PRO 6000 für ein 30B-Modell bei rund 3.000 Euro externer Hardware-Kosten im Monat. Ein großes Vision-Modell auf vier H200 liegt bei etwa 17.000 Euro. Diese Preise schwanken stark und sind nachfrageabhängig, sie sollten tagesaktuell angefragt werden. Für den Selbstbetrieb kommt ein Aufschlag für Personal und Betrieb dazu.

Warum reicht eine GPU nicht für ein großes Modell?

Weil Modellgewichte und KV-Cache zusammen den verfügbaren VRAM sprengen. Ein 70B-Modell belegt in FP8 allein rund 70 GB, dazu kommt der KV-Cache für jede laufende Anfrage. Sobald die Summe die 96 GB einer einzelnen Karte übersteigt, verteilt Tensor-Parallelismus das Modell auf mehrere GPUs.

Wie hilft Quantisierung beim GPU-Sizing?

Quantisierung senkt die Bytes pro Parameter. Von FP16 auf FP8 halbiert sich der Speicherbedarf der Gewichte, von FP16 auf NVFP4 viertelt er sich. Für die meisten Enterprise-Aufgaben ist der Qualitätsverlust bei FP8 vernachlässigbar. Das ist der günstigste Weg, mehr Nutzer auf dieselbe Hardware zu bringen.

Was ist der Unterschied zwischen registrierten und aktiven Nutzern beim Sizing?

Registrierte Nutzer sind alle, die Zugriff haben. Aktive Nutzer sind die, die im selben Moment eine Anfrage laufen haben. Von 140 registrierten Mitarbeitern sind meist nur 20 bis 30 gleichzeitig aktiv. Der KV-Cache wird nur für die aktiven Anfragen belegt, deshalb dimensionieren wir auf die Spitze der Nebenläufigkeit, nicht auf die Gesamtzahl.

Nächster Schritt

Wenn du deine drei Zahlen kennst, überschlagen wir das Sizing in einem kurzen Termin und sagen dir, ob zwei Karten reichen oder ob dein Kontext-Profil mehr braucht.

Verwandte Themen