Wie viele Nutzer eine RTX PRO 6000 Blackwell bedient und wie Sie es ausrechnen

Nutzer pro GPU bedeutet gleichzeitige Anfragen

Nach unserer Regel für Nutzer je Karte hält eine RTX PRO 6000 bei deklariertem 8K-Kontext 6 gleichzeitige Sitzungen voller Länge mit Llama 3.3 70B in FP8, 25 mit Qwen3-32B in FP8 und 68 mit einem 8B-Modell in BF16, jeweils mit 16-Bit-KV-Cache; ein FP8-KV-Cache verdoppelt jede dieser Zahlen ungefähr, beim 70B-Modell auf 12. vLLM gibt die Zahl für Ihr eigenes Modell beim Start aus. Die Frage wird meist als Personalzahl gestellt, etwa ob eine Karte für vierhundert Mitarbeiter reicht. Eine GPU bedient Sequenzen: Anfragen, die im KV-Cache liegen und für die in diesem Moment Token erzeugt werden. Hundert Menschen mit einem Assistenten im Browser-Tab sind hundert untätige Sitzungen und eine sehr viel kleinere Zahl gleichzeitiger Generierungen. Wir haben kein veröffentlichtes Verhältnis zwischen beiden gefunden. Protokollieren Sie am Gateway die Anfragen in Bearbeitung und nehmen Sie die Spitze der Hauptgeschäftsstunde; diese Spitze ist die Nutzerzahl für die Auslegung.

Auch die veröffentlichten Zahlen von NVIDIA und MLPerf® beantworten die Frage nicht. NVIDIAs absolute LLM-Zahlen für die Karte sind Werte zum maximalen Durchsatz der Server Edition in der Performance-Übersicht zu TensorRT-LLM, gemessen mit der eigenen Engine, zum Beispiel Qwen3-30B-A3B in FP4 auf einer GPU mit 9.938 Ausgabe-Token pro Sekunde und GPU bei 1.000 Token Eingabe und 1.000 Token Ausgabe. Wir haben bei NVIDIA keine Zahl je Nutzer gefunden. Die Seite zur Inferenzleistung enthält zwar einen Abschnitt mit der Überschrift RTX PRO 6000 Blackwell Server Edition, aber jedes Modell darin ist Bildverarbeitung, Bild- oder Videoerzeugung, gemessen in Bildern oder Samples pro Sekunde oder in Videos pro Minute. NVIDIAs übrige LLM-Aussagen sind relativ, etwa bis zum Fünffachen einer L40S, ohne Präzision, ohne Batch-Größe und ohne Sequenzlänge. MLPerf® Inference v6.0 vom April 2026 enthält von MLCommons verifizierte Ergebnisse für diese GPU, aber es sind Durchsätze ganzer Server mit mehreren GPUs unter den Latenzgrenzen des Benchmarks. Die neuere Runde v6.1 vom 16. September 2026 enthält kein interaktives Llama-2-70B-Ergebnis für die Karte, daher bleibt die interaktive Zahl hier bei v6.0. Bei Llama 2 70B im Szenario Interactive, das 450 ms bis zum ersten Token und 40 ms je Ausgabe-Token im 99. Perzentil erlaubt, erreichte ein System mit acht Karten der Server Edition 6.238,12 Token pro Sekunde mit FP4-Gewichten (Eintrag 6.0-0004).

MLPerf® Inference v6.0 Datacenter, Closed Division, Kategorie Available, Llama 2 70B (llama2-70b-99), Szenario Interactive, Eintrag 6.0-0004, abgerufen von mlcommons.org am 24. September 2026. Ergebnis von der MLCommons Association verifiziert. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

vLLM liefert eine bessere Grundlage, weil es die Nebenläufigkeit, die es auf Ihrer Karte tragen kann, berechnet und beim Start ausgibt. Die beiden Zeilen sehen so aus; die Werte zeigen nur das Format und gehören zu keiner der unten ausgelegten Konfigurationen:

INFO 07-23 13:56:04 [kv_cache_utils.py:775] GPU KV cache size: 643,232 tokens INFO 07-23 13:56:04 [kv_cache_utils.py:779] Maximum concurrency for 40,960 tokens per request: 15.70x

Der erste Wert ist die Zahl der Token, die gleichzeitig in den KV-Cache passen. Der zweite gibt an, wie viele Anfragen gleichzeitig bedient werden können, wenn jede die genannte Zahl an Token braucht; bei einem Modell mit voller Attention in jeder Schicht ist er der erste Wert geteilt durch die Token je Anfrage: 643.232 / 40.960 = 15,70. Unser Leitfaden zu den Zeilen KV-Cache-Größe und Maximum concurrency in vLLM erklärt, wie vLLM sie berechnet und welche Flags sie verändern. Auf Ihrer eigenen Karte abgelesen, ersetzen diese beiden Werte für die Auslegung jeden fremden Benchmark.

Das Speicherbudget: 96 GB minus die Gewichte

In den 96 GB liegen die Gewichte, die feststehen, sobald Modell und Quantisierung gewählt sind, und der KV-Cache, der mit jedem zugelassenen Nutzer wächst, dazu einige GB für Aktivierungen, CUDA-Graphen und den Overhead des Frameworks. Weil die Gewichte feststehen, ist es der KV-Cache, der die Nebenläufigkeit begrenzt.

Gewichte sind Parameter mal Byte je Parameter: zwei für BF16, eines für FP8 und für NVFP4 ein halbes Byte plus ein FP8-Skalierungsfaktor je 16 Gewichte, wobei Embeddings und Ausgabeschicht in FP8- wie in NVFP4-Checkpoints meist in BF16 bleiben. NVIDIAs NVFP4-Checkpoint von Llama 3.3 70B, mit derselben Architektur wie 3.1 70B, hat 42,7 GB, etwa 0,61 Byte je Parameter. In BF16, FP8 und NVFP4 sind es bei Llama 3.1 8B 16,1, 9,1 (NVIDIAs FP8-Checkpoint) und nach unserer Rechnung etwa 6,0 GB. Bei Qwen3-32B sind es 65,6, 34,3 (Qwens FP8-Checkpoint) und 20,7 GB (NVIDIAs NVFP4-Checkpoint). Llama 3.1 70B hat in BF16 141,2 GB, was nicht passt, in FP8 etwa 72,7 und in NVFP4 etwa 42,7 (NVIDIAs Checkpoints von Llama 3.3 70B). NVIDIAs NIM-Supportmatrix führt die RTX PRO 6000 Server Edition mit Stand Oktober 2026 unter den verifizierten GPUs für Llama 3.3 70B, mit Profilen für BF16, FP8 und NVFP4 von TP1 bis TP8, die sie keiner bestimmten GPU zuordnet; TP ist die Zahl der Karten, auf die das Modell aufgeteilt wird. Nach den Gewichten allein passen FP8 und NVFP4 auf eine Karte, und BF16 braucht zwei.

Der KV-Cache entscheidet, wie viele Nutzer hineinpassen; seine Größe beträgt:

KV-Bytes = 2 × Schichten × kv_heads × head_dim × Byte_je_Element × seq_len × Batch

Die führende 2 sind Key und Value; kv_heads ist die Zahl der Key-Value-Köpfe, nicht der Query-Köpfe; head_dim die Dimension je Kopf; Byte_je_Element 2 bei einem FP16- oder BF16-Cache und 1 bei einem FP8-Cache; seq_len die Token, die für diese Anfrage gehalten werden; Batch die gleichzeitig liegenden Sequenzen.

Die Zahl der Köpfe in dieser Formel wird leicht falsch eingesetzt. NVIDIAs Blog zur Inferenzoptimierung schreibt die Formel als „2 * (num_layers) * (num_heads * dim_head) * precision_in_bytes“. Wer num_heads als die Zahl der Attention-Köpfe liest, überschätzt das Ergebnis um das ganze Verhältnis der Grouped-Query-Attention. Llama 3.1 70B hat 64 Query-Köpfe und 8 Key-Value-Köpfe: Mit 64 gerechnet ergeben sich 2.560 KiB je Token gegenüber den richtigen 320 KiB, eine achtfache Überschätzung der größten Variablen im Budget. vLLM nennt sie num_kv_heads, in der config.json heißt sie num_key_value_heads.

Die Dimension je Kopf ist in allen drei Fällen 128. Die Llama-Werte stammen aus Metas Llama-3-Paper, Tabelle 3, Qwen3-32B aus der eigenen config.json. KV pro Token gilt für einen FP16- oder BF16-Cache; ein FP8-Cache halbiert jede Zahl.

Grouped-Query-Attention macht Serving auf einer einzigen Karte praktikabel: Ohne sie braucht ein 70B-Modell 20 GiB je 8K-Sitzung statt 2,5. Das Budget geht von den 95,6 GiB aus, die der Treiber meldet (nvidia-smi, FB Memory Total); laut NVIDIAs vPC Sizing Guide, aktualisiert am 19. August 2026, ist das ECC der Blackwell-Generation in den GDDR7-Speicher eingebaut, immer aktiv und verringert den nutzbaren VRAM nicht. Wir planen mit 0,9 für gpu_memory_utilization, vLLMs Voreinstellung bis Release 0.19 (0,92 seit 0.20.0 vom April 2026), was 86,0 GiB ergibt; davon ziehen wir rund 3 GiB Overhead und die Gewichte ab.

Budget: 95,6 GiB × 0,9, abzüglich rund 3 GiB Overhead, abzüglich der Gewichte der veröffentlichten Checkpoints, die Embeddings und Ausgabeschicht in BF16 halten. Sitzungen sind gleichzeitige Anfragen, die jede einen vollen 8K-Kontext mit einem FP16-KV-Cache halten; die zweite Zahl ist dieselbe Rechnung mit einem FP8-KV-Cache.

Nehmen Sie als Beispiel die Zeile Llama 3.3 70B in FP8 (Llama 3.1 und 3.3 70B haben die Architektur aus der Tabelle oben gemeinsam). Die Gewichte haben in NVIDIAs Checkpoint 67,7 GiB; 86,0 minus 67,7 minus 3 lassen 15,3 GiB; jede 8K-Sitzung braucht bei 320 KiB je Token 2,5 GiB; 15,3 geteilt durch 2,5 ergibt 6. Auf einer Karte haben also sechs gleichzeitige Gespräche voller Länge Platz, zwölf mit einem FP8-Cache und siebzehn mit NVFP4-Gewichten. Den größten einzelnen Einfluss auf die Nebenläufigkeit hat die Quantisierung der Gewichte.

Den zweitgrößten Einfluss hat die Kontextlänge. Bei deklarierten 32K lässt dieselbe Rechnung 17 Sitzungen für das 8B-Modell in BF16 und 1 für das 70B in FP8; eine einzige 70B-Sitzung mit 128K kostet 40 GiB FP16-KV, mehr als dieses ganze Budget.

Ein FP8-KV-Cache, in vLLM kv_cache_dtype="fp8_e4m3", halbiert jede KV-Zahl. Seit Release 0.32.0 vom 18. Oktober 2026 betreibt vLLM auf SM12x-Karten wie dieser auch einen NVFP4-KV-Cache; veröffentlichte Genauigkeitswerte dazu gibt es noch wenige, unsere Seite zum NVFP4-KV-Cache auf der RTX PRO 6000 Server Edition sammelt sie, die Tabellen hier planen daher mit FP8. Die Sitzungszahlen sind eine Untergrenze: PagedAttention belegt Blöcke nach Bedarf, sodass Sitzungen, die ihren deklarierten Kontext nie füllen, weniger Speicher brauchen.

Unsere GPU-Server für private LLMs, darunter den Inferenzknoten mit vier Karten, legen wir nach denselben Größen aus. Nennen Sie uns Ihr Modell und den Kontext, den Sie deklarieren wollen, und wir antworten innerhalb eines Werktages mit dieser Rechnung und einer Konfiguration.

Speicherbandbreite und Geschwindigkeit je Nutzer nach Edition

Die Kapazität entscheidet, wie viele Nutzer hineinpassen; die Bandbreite entscheidet, wie schnell jeder bedient wird. Das Dekodieren liest die Gewichte bei jedem Token erneut aus dem Speicher, bei kleinen Batch-Größen ist die Rate je Nutzer also durch Bandbreite geteilt durch Gewichtsbytes begrenzt und nicht durch irgendeine FLOPS-Zahl auf dem Datenblatt. Alle drei Editionen teilen sich den GB202-Chip, 96 GB GDDR7 mit ECC und 24.064 CUDA-Kerne, aber nicht den Speichertakt.

NVIDIA-Datenblätter und Produktseiten. Lenovos Produktleitfaden nennt „Up to 1597 GB/s“ und dokumentiert eine optionale Leistungsgrenze von 450 W für die Server Edition; NVIDIAs Referenzarchitektur schreibt bis zu 1,6 TB/s je GPU.

Die Server Edition, die Karte für Rackserver, hat den langsameren Speicher. Die meisten Spezifikationstabellen unter diesem Produktnamen nennen 1.792 GB/s, den Wert der Workstation und der Max-Q, der rund 12 Prozent höher liegt; in eine Serverauslegung übernommen, überschätzt er den Decode-Durchsatz um dieselben 12 Prozent.

Die Obergrenze, die daraus folgt, ist leicht zu rechnen. Llama 3.1 70B in FP8 liest je Token etwa 70,6 GB Gewichte, und 1.597 geteilt durch 70,6 sind etwa 23 Dekodierschritte pro Sekunde für einen einzelnen Nutzer ohne Batching, vor jedem Effizienzverlust. In NVFP4 werden je Token etwa 40,6 GB gelesen, die 4-Bit-Schichten plus die Ausgabeschicht in BF16 (in der Embedding-Tabelle wird nur nachgeschlagen), und die Grenze steigt auf etwa 39. Das ist Arithmetik aus der veröffentlichten Bandbreite und der Größe der Gewichte, keine Messung, und kein reales System erreicht sie. Rechnen Sie dieselbe Division für Ihr Modell.

Die Lesegeschwindigkeit ist ein brauchbarer unterer Richtwert für die Generierungsrate, die Nutzer brauchen. Eine Meta-Analyse von 190 Lesestudien im Journal of Memory and Language von 2019 setzt das mittlere stille Lesen von Sachtexten bei 238 Wörtern pro Minute an; bei den üblichen 0,75 Wörtern je Token sind das etwa 5,3 Token pro Sekunde oder 6,7 für einen schnellen Leser. Interaktive Dienste werden deutlich schneller ausgelegt, weil Nutzer überfliegen und abbrechen und weil Reasoning-Modelle Denk-Token ausgeben, die niemand liest. Das Szenario Interactive von MLPerf® Inference v6.0 für Llama 2 70B verlangt zum Beispiel das erste Token innerhalb von 450 ms und höchstens 40 ms je Ausgabe-Token im 99. Perzentil, also 25 Token pro Sekunde je Nutzer.

Batching: Gesamtdurchsatz gegen Latenz je Nutzer

Zwischen diesen beiden Grenzen legt der Scheduler den Kompromiss fest, vor allem über die Batch-Größe. Die Konfigurationen, in denen sich keine Kennzahl mehr verbessern lässt, ohne eine andere zu verschlechtern, bilden die Pareto-Front.

Bevor Sie irgendeine Durchsatzzahl lesen, trennen Sie zwei Größen, die regelmäßig als eine einzige Zahl angegeben werden. Durchsatz je System sind die gesamten Ausgabetoken pro Sekunde über alle gleichzeitig laufenden Anfragen; Durchsatz je Nutzer ist die Ausgabelänge geteilt durch die Gesamtlatenz. NVIDIA beschreibt einen Server DGX B200 mit acht Blackwell-GPUs sowohl als Maschine, die jedem Nutzer über 1.000 Token pro Sekunde liefert, als auch als Maschine mit 72.000 Token pro Sekunde bei Llama 4 Maverick, in zwei Konfigurationen desselben Siliziums. Vergleichbar ist eine Durchsatzzahl nur, wenn sie angibt, ob sie aggregiert oder je Nutzer gilt, und dazu die Nebenläufigkeit, die Sequenzlängen und die Präzision nennt.

Der Kompromiss verläuft auch nicht monoton, wie die Messreihe in NVIDIAs eigenem Tuning-Leitfaden zu TensorRT-LLM zeigt.

NVIDIAs Performance-Tuning-Leitfaden zu TensorRT-LLM, Llama 3.3 70B auf vier H100. Andere Hardware als die hier besprochene Karte; übertragbar ist die Form der Kurve, nicht die absoluten Werte.

Die Obergrenze von 64 auf 512 anzuheben brachte 27 Prozent mehr Durchsatz nahezu ohne Latenzkosten. Sie von 512 auf 2.048 anzuheben machte den Durchsatz schlechter, um rund 17 Prozent. Jenseits des Knies kostet eine höhere Obergrenze Durchsatz und bringt bei der Latenz keinen Gewinn. Die Voreinstellung für max_batch_size in diesem Stack ist 2.048; dieses Ergebnis macht die Voreinstellung nicht falsch, ist aber ein Grund, den Wert am eigenen Modell durchzumessen.

Eine Karte teilen: MIG, vGPU und die Lizenz

MIG funktioniert auf allen drei Editionen: NVIDIAs MIG-Leitfaden behandelt Workstation, Max-Q und Server Edition in einer Profiltabelle und bietet 1g.24gb mit vier Instanzen, 2g.48gb mit zwei und 4g.96gb mit einer. Ein 3g-Profil gibt es nicht, die Granularität ist also 24, 48 oder 96 GB ohne Zwischenstufe: Ein Modell mit 32 GB kann keine 24-GB-Scheibe nehmen und muss eine mit 48 GB belegen.

vGPU ist strenger. Die einzigen Einträge zur RTX PRO 6000 auf NVIDIAs Liste unterstützter GPUs sind die Blackwell Server Edition ab vGPU 19.0 und ihre flüssigkeitsgekühlte Variante ab 20.0; die Workstation und die Max-Q kommen darin gar nicht vor, wenn der Plan also virtuelle Maschinen vorsieht, ist die Server Edition die einzige Möglichkeit. Für Rechenlast sind die C-Profile einschlägig: ein DC-96C je Karte, zwei DC-48C, drei DC-32C, vier DC-24C, sechs DC-16C, acht DC-12C oder zwölf DC-8C mit je 8 GB. Die MIG-gestützten Varianten, die isolieren statt in Zeitscheiben zu teilen, hören bei vier auf.

Die Angabe von 48 virtuellen Maschinen je Karte sollte nur mit Vorsicht in ein Designdokument eingehen. NVIDIAs Blog zu vGPU 19.0 schreibt, diese GPUs unterstützten bis zu 48 gleichzeitige virtuelle Maschinen auf einer GPU, und erklärt die Rechnung gleich selbst: vier MIG-Instanzen mal zwölf VMs je Instanz. Das ist die Dichte virtueller Desktops aus kleinen Grafikprofilen; für LLM-Serving liegt die Grenze bei zwölf. Unser Beitrag zu MIG und vGPU je Karte trifft dieselbe Unterscheidung für die ganze Baureihe. Partitionierung schafft keine zusätzliche Kapazität: Vier Scheiben nehmen vier kleine Modelle auf, nicht mehr Nutzer eines großen Modells.

NVIDIA zählt Lizenzen für AI Enterprise und für vGPU-Desktops unterschiedlich. NVIDIA AI Enterprise, das die C-Profile für Rechenlast voraussetzen, wird pro GPU lizenziert: eine Lizenz für jede GPU im Server, auf der die Software läuft. vApps, vPC und RTX vWS werden meist pro gleichzeitigem Nutzer lizenziert, eine CCU-Lizenz je gleichzeitiger virtueller Maschine, wobei NVIDIA einige vGPU-Editionen auch pro GPU verkauft. Eine Karte, die ein Modell über eine API an 200 Menschen ausliefert, braucht also eine AI-Enterprise-Lizenz, wenn auf ihr Software aus NVIDIA AI Enterprise wie NIM läuft, weil sie eine GPU ist, und keine, wenn auf ihr eine Open-Source-Engine wie vLLM auf Bare Metal läuft; die Zählung nach gleichzeitigen Nutzern gilt für virtuelle Desktops und nicht für HTTP-Clients eines Inferenz-Endpunkts.

Wir liefern NVIDIA-AI-Enterprise-Lizenzen mit den Karten auf derselben Rechnung. Wenn Sie nicht sicher sind, ob Ihr Aufbau eine braucht, beschreiben Sie ihn im Formular unten, und wir sagen es Ihnen.

Wann eine Karte nicht mehr reicht

Vier Situationen verlangen eine zweite Karte; drei betreffen die Kapazität, eine die Verfügbarkeit.

1. Das Modell passt nicht. Llama 3.1 70B in BF16 sind 141,2 GB; auf zwei Karten aufgeteilt, bleiben nach der Rechnung oben rund 17 GiB für den Cache je Karte.
2. Der Kontext ist lang. Eine einzige 70B-Sitzung mit 128K kostet 40 GiB FP16-KV, mehr als die 15,3 GiB, die neben FP8-Gewichten bleiben; selbst mit FP8-Cache (20 GiB) braucht eine solche Sitzung NVFP4-Gewichte oder eine zweite Karte.
3. Die Nebenläufigkeit übersteigt das KV-Budget. Das ist die Rechnung oben, und die Quantisierung ist der erste Zug dagegen.
4. Verfügbarkeit. Eine Karte ist ein Single Point of Failure: Ein Treiber-Update, ein ECC-Fehler oder ein hängender Prozess legt den Dienst lahm, und MIG und vGPU teilen ihre Fehlerdomäne vollständig. Nur eine zweite Karte, am besten in einem zweiten Host, beseitigt dieses Risiko, auch wenn die Rechnung sagt, dass eine Karte reicht.

Keine Edition hat NVLink, und das ändert, wie eine zweite Karte eingesetzt wird. Lenovos Produktleitfaden führt NVLink mit „No“, NVIDIAs Product Brief zur Server Edition mit „Not supported“; in NVIDIAs Spezifikationstabelle und im Architektur-Whitepaper haben wir keinen Hinweis darauf gefunden, und die Referenzarchitektur beschreibt die Platzierung der GPUs rein in PCIe-Begriffen.

NVIDIAs eigene H200-Seite nennt beide Zahlen nebeneinander: NVLink mit 900 GB/s je GPU gegen PCIe Gen 5 mit 128 GB/s, ungefähr das Siebenfache. Jeder Austausch zwischen RTX-PRO-6000-Karten läuft über die langsamere Verbindung, deshalb kommt es auf die Wahl des Parallelismus an. vLLMs Dokumentation empfiehlt innerhalb eines Knotens Tensor-Parallelismus, ergänzt aber in einem Hinweis zu ungleichmäßigen Aufteilungen, dass Pipeline-Parallelismus auf GPUs ohne NVLink höheren Durchsatz und weniger Kommunikationsaufwand bringt. Tensor-Parallelismus führt in jeder Schicht zwei All-Reduce-Operationen aus; Pipeline-Parallelismus reicht Aktivierungen einmal je Stufengrenze weiter.

Daraus ergibt sich die Reihenfolge der Schritte. Quantisieren Sie, bevor Sie skalieren: FP8 oder NVFP4 auf einer Karte schlägt BF16 über zwei Karten ohne schnelle Verbindung. Für mehr Gesamtdurchsatz betreiben Sie unabhängige Repliken, eine Instanz je Karte hinter einem Load Balancer, was den Verkehr zwischen GPUs vollständig beseitigt und die Verfügbarkeit verdoppelt. Teilen Sie das Modell nur auf, wenn es nicht passt, und bevorzugen Sie dann Pipeline-Parallelismus für den Durchsatz und Tensor-Parallelismus dort, wo die Latenz jeder Anfrage zählt. Tensor-Parallelismus bleibt unterstützt, mit TP2-, TP4- und TP8-Profilen in der NIM-Matrix, aber seine All-Reduce-Operationen laufen über PCIe und kosten Geschwindigkeit. Die Richtung dieser Kosten ist dokumentiert; veröffentlichte Messungen ihrer Größe auf dieser Karte gibt es wenige, und unser Beitrag zu PCIe und NVLink sammelt sie. Ein Server mit vier Karten, der Inferenzknoten unter unseren KI-Server-Konfigurationen, folgt derselben Rechnung: Vier Kopien von Llama 3.3 70B in FP8 halten 24 gleichzeitige 8K-Sitzungen mit 16-Bit-Cache und 48 mit FP8-Cache, und zwei Tensor-Parallel-Paare halten 78 und 156, weil jedes Paar die Gewichte nur einmal speichert. Jedes Paar synchronisiert sich in jeder Schicht über PCIe, und vLLM schaltet sein Custom All-Reduce in der Standardeinstellung bei mehr als zwei GPUs ohne NVLink ab, was zwei TP=2-Paare gegenüber einer TP=4-Kopie begünstigt; vLLM 0.30.0 (Release Notes vom 22. September 2026) hat für solche Server ein optional zuschaltbares FlashInfer-PCIe-IPC-All-Reduce ergänzt (Pull Request 53576), über dessen Gewinn bisher wenig veröffentlicht ist. Der Durchsatz bei Spitzenlast ist für diese Aufteilungen nicht gemessen; wir würden auf Ihrem Modell in einem Lasttest zwei TP=2-Instanzen gegen vier Einzelkopien und eine TP=4-Kopie testen.

Dieselbe Regel lässt sich auf ganze Server übertragen. Zwei, vier und acht Karten fassen 166,1, 332,2 und 664,3 GiB Gewichte und KV-Cache, und die Aufteilung entscheidet, wie viel davon Cache ist: Jede Kopie speichert ihre eigenen Gewichte, weniger und größere Kopien halten also mehr Gespräche, um den Preis von All-Reduce-Operationen über PCIe.

Unsere Schätzung nach der Regel für Nutzer pro Karte (0,9 × 95,6 GiB, abzüglich 3 GiB je Karte und abzüglich der Gewichte), gleichzeitige Gespräche in voller Kontextlänge, mit FP8-KV-Cache für Llama 3.3 70B, Qwen3-235B-A22B-2507 und Llama 4 Maverick und 16-Bit-Cache für gpt-oss-120b und Qwen3.8-27B, wie in unseren Leitfäden zu zwei, vier und acht Karten der Server Edition; die Werte mit acht Karten für NVFP4 und Qwen3.8-27B sind acht Einzelkopien nach derselben Rechnung. Gewichte: Llama 3.3 70B 67,7 GiB in FP8 und 39,8 GiB in NVFP4, gpt-oss-120b 60,8 GiB, Qwen3.8-27B 28,8 GiB, Qwen3-235B-A22B-2507 219,8 GiB, Llama 4 Maverick rund 417 GB.

Unsere Leitfäden zu zwei, vier und acht Karten der Server Edition zeigen diese Aufteilungen je Modell, mit Stromversorgung, Gehäusen und veröffentlichten Messwerten.

Auslegungsverfahren in acht Schritten

Das Verfahren braucht eine Karte für einen Nachmittag und endet mit einer Zahl, die an Ihrem eigenen Modell gemessen ist.

1. Zählen Sie Nebenläufigkeit, keine Menschen. Protokollieren Sie eine Woche lang die Anfragen in Bearbeitung am Gateway; nehmen Sie die Spitze und das 95. Perzentil.
2. Entscheiden Sie den Kontext, den Sie deklarieren, und das ist nicht das Maximum des Modells: 8K statt geerbter 40K verfünffacht die Nebenläufigkeit.
3. Rechnen Sie die Gewichte: Parameter × Byte je Parameter, oder die Größe des Checkpoints, den Sie laden. Entscheiden Sie hier die Quantisierung: 141,2, etwa 72,7 und etwa 42,7 GB sind dasselbe 70B-Modell.
4. Rechnen Sie KV je Token: 2 × Schichten × kv_heads × head_dim × Byte, und nehmen Sie kv_heads aus num_key_value_heads und niemals aus num_attention_heads.
5. Abziehen und teilen. 95,6 GiB × 0,9, abzüglich rund 3 GiB, abzüglich der Gewichte, geteilt durch KV je Sitzung. Das ist Ihre Untergrenze.
6. Starten Sie den Server und lesen Sie das Log. Starten Sie vLLM mit diesem Modell, dieser Quantisierung und diesem deklarierten Kontext und lesen Sie die Werte GPU KV cache size und Maximum concurrency (verwenden Sie vLLM 0.31.0 oder neuer, das die in GHSA-h3rc-6mm3-gc2m beschriebene Lücke behebt, besser 0.32.0; Stand Oktober 2026). Weichen sie stark von Schritt fünf ab, ist Schritt fünf falsch.
7. Messen Sie die Latenz bei dieser Last: Zeit bis zum ersten Token und Latenz zwischen Token bei realistischen Sequenzlängen, gegen ein Ziel für das erste Token und eine Rate je Nutzer, die Sie vertreten. Durchfahren Sie die Batch-Obergrenze rund um das Knie, statt eine Voreinstellung zu übernehmen.
8. Entscheiden Sie die Verfügbarkeit getrennt. Muss der Dienst ein Treiber-Update überstehen, lautet die Antwort zwei Karten in zwei Hosts, unabhängig davon, was die Rechnung ergeben hat.

Nach unserer Regel für Nutzer je Karte reicht eine Karte mit einem 8B-Modell in BF16 für 17 Sitzungen voller Länge bei 32K und 68 bei 8K (136 mit FP8-Cache), mit Qwen3-32B in FP8 für 25 bei 8K und mit Llama 3.3 70B in FP8 für 6 oder, mit FP8-Cache, für 12; NVFP4-Gewichte heben die 70B-Werte auf 17 und 34.

Was wir liefern

Wir liefern die RTX PRO 6000 Blackwell in allen drei Editionen, mit Herstellergarantie unter einem EU-Vertrag und auf einer Rechnung, als Karten oder in nach Auftrag gebauten GPU-Servern mit zwei bis acht Karten je Knoten, dazu die Lizenzen für NVIDIA AI Enterprise, wo Ihr Aufbau sie braucht.

FAQ