Wie viele Menschen eine RTX PRO 6000 Blackwell wirklich bedient und wie Sie es selbst ausrechnen

Wie viele Nutzer ist keine Kopfzahl

Die Frage kommt meist als Personalzahl: vierhundert Mitarbeiter, eine Karte, reicht das. Eine GPU kennt keine Mitarbeiter. Sie hält Sequenzen, also Anfragen, die im KV-Cache liegen und für die in diesem Augenblick 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, und wir erfinden keines: Protokollieren Sie am Gateway die Anfragen in Bearbeitung und nehmen Sie die Spitze der Hauptgeschäftsstunde. Das ist die einzige Nutzerzahl, die in die Rechnung eingeht.

Jetzt der unangenehme Teil, gleich zu Beginn. 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 trägt 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: Bei Llama 2 70B im Szenario Interactive, das 450 ms bis zum ersten Token und danach 40 ms je Token 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.

Eine Zahl in Token pro Sekunde je Nutzer hat für diese Karte also keine NVIDIA-Quelle, und ein Wert zum maximalen Durchsatz, gemessen mit NVIDIAs eigener Engine, ist keine solche Zahl. Das Fehlen ist der Befund, und der Ersatz ist besser: vLLM berechnet die Nebenläufigkeit, die es tragen kann, und druckt sie beim Start.

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 nennt die Token, die gleichzeitig in den KV-Cache passen; der zweite, wie viele Anfragen gleichzeitig bedient werden können, wenn jede die genannte Zahl an Token braucht, und bei einem Modell mit voller Attention in jeder Schicht ist er schlicht der erste geteilt durch die Token je Anfrage: 643.232 / 40.960 = 15,70. Neuere Releases wie vLLM 0.30 vom September 2026 drucken beide Werte in einer Zeile. Lesen Sie ihn auf Ihrer Karte, und Sie brauchen niemandes Benchmark.

Das Speicherbudget: 96 GB minus die Gewichte

Zwei Dinge verbrauchen die 96 GB: die Gewichte, fest 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 sich nicht bewegen, ist es der KV-Cache, der die Nebenläufigkeit deckelt.

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. Llama 3.1 8B sind 16,1, 9,1 (NVIDIAs FP8-Checkpoint) und nach unserer Rechnung etwa 6,0 GB; Qwen3-32B 65,6, 34,3 (Qwens FP8-Checkpoint) und 20,7 GB (NVIDIAs NVFP4-Checkpoint); Llama 3.1 70B 141,2 GB in BF16, was nicht passt, etwa 72,7 in FP8 und etwa 42,7 in NVFP4 (NVIDIAs Checkpoints von Llama 3.3 70B). NVIDIAs NIM-Supportmatrix bestätigt die Grenze: 70B läuft mit TP1 in FP8 und NVFP4, BF16 nur mit TP4 und TP8, und „BF16 TP2 mit oder ohne LoRA wird auf der NVIDIA RTX PRO 6000 Blackwell Server Edition nicht unterstützt“.

Am KV-Cache wird die Auslegung gewonnen oder verloren:

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.

Hier liegt die Falle. NVIDIAs Blog zur Inferenzoptimierung schreibt die Formel als „2 * (num_layers) * (num_heads * dim_head) * precision_in_bytes“. Lesen Sie num_heads als die Zahl der Attention-Köpfe, und Sie liegen um das ganze Verhältnis der Grouped-Query-Attention daneben. 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 ist der Grund, warum Serving auf einer einzelnen Karte überhaupt funktioniert: Ohne sie kostet ein 70B-Modell 20 GiB je 8K-Sitzung statt 2,5. Das Budget sind die 95,6 GiB, die der Treiber meldet, mal 0,9 für gpu_memory_utilization (vLLMs Voreinstellung bis Release 0.19; 0,92 seit 0.20.0 vom April 2026), der Wert, mit dem wir planen, also 86,0 GiB, abzüglich rund 3 GiB Overhead, abzüglich der Gewichte.

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.

Verfolgen Sie eine Zeile. Llama 3.1 70B in FP8 sind 67,7 GiB Gewichte in NVIDIAs Checkpoint; 86,0 minus 67,7 minus 3 lassen 15,3 GiB; jede 8K-Sitzung kostet bei 320 KiB je Token 2,5 GiB; 15,3 geteilt durch 2,5 ergibt 6. Sechs gleichzeitige Gespräche voller Länge aus einer Karte, zwölf mit einem FP8-Cache, siebzehn mit NVFP4-Gewichten. Die Quantisierung der Gewichte ist der größte einzelne Hebel auf die Nebenläufigkeit.

Die Kontextlänge ist der zweite Hebel, und sie ist brutal. 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. Und lesen Sie die Zählungen als Untergrenze, nicht als Obergrenze: PagedAttention belegt Blöcke nach Bedarf, Sitzungen, die ihren deklarierten Kontext nie füllen, kosten weniger.

Die Bandbreite setzt die Obergrenze, und welche Bandbreite zählt

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. Den Speichertakt teilen sie sich nicht.

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 ist die Karte, die in ein Rack geht, und sie ist die mit dem langsameren Speicher. Die meisten Spezifikationstabellen unter diesem Produktnamen nennen 1.792 GB/s, den Wert der Workstation und der Max-Q, rund 11 Prozent höher; in eine Serverauslegung übernommen überschätzt er den Decode-Durchsatz um rund 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.

Wie schnell muss es sein? 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, 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 danach höchstens 40 ms je Token, also 25 Token pro Sekunde je Nutzer.

Batching: Gesamtdurchsatz gegen Latenz je Nutzer

Zwischen den beiden Obergrenzen sitzt der Scheduler, und der Hebel ist die Batch-Größe. Die Konfigurationen, in denen sich keine Kennzahl mehr verbessern lässt, ohne eine andere zu verderben, sind die Pareto-Front.

Bevor Sie irgendeine Durchsatzzahl lesen, trennen Sie zwei Größen, die routinemäßig als eine gedruckt 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. Eine Zahl, die nicht sagt, ob sie aggregiert oder je Nutzer gilt, und die Nebenläufigkeit, die Sequenzlängen und die Präzision verschweigt, sagt nichts.

Und Batching tauscht nicht monoton. NVIDIAs eigener Tuning-Leitfaden zu TensorRT-LLM veröffentlicht den Durchlauf.

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 zu heben brachte 27 Prozent mehr Durchsatz zu praktisch keinen Latenzkosten. Sie von 512 auf 2.048 zu heben machte den Durchsatz schlechter, um rund 17 Prozent, und brachte bei der Latenz nichts zurück. Jenseits des Knies verlieren Sie auf beiden Achsen, und die Voreinstellung für max_batch_size in diesem Stack ist 2.048: ein Argument dafür, den Wert am eigenen Modell zu durchfahren, kein Argument gegen die Voreinstellung.

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. Beachten Sie, was fehlt: Ein 3g-Profil gibt es nicht. Die Körnung sind 24, 48 oder 96 GB und nichts dazwischen, ein Modell mit 32 GB kann also 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.

Eine Zahl gehört erschlagen, bevor sie in ein Designdokument gelangt. 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 Dichte virtueller Desktops aus kleinen Grafikprofilen, kein LLM-Serving, wo die Grenze bei zwölf liegt. Unser Beitrag zu MIG und vGPU je Karte zieht dieselbe Unterscheidung über die ganze Baureihe. Partitionierung schafft nie Kapazität: Vier Scheiben halten vier kleine Modelle, nicht mehr Nutzer eines großen.

Lizenziert wird auf zwei Arten, und die werden ständig verwechselt. 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 pro gleichzeitigem Nutzer verkauft, eine CCU-Lizenz je gleichzeitiger virtueller Maschine. 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.

Wann eine Karte nicht mehr reicht

Vier Dinge erzwingen eine zweite Karte; nur drei davon sind eine Frage der Kapazität.

1. Das Modell passt nicht. Llama 3.1 70B in BF16 sind 141,2 GB, und NVIDIAs NIM-Matrix führt es nur mit TP4 und TP8 und lehnt BF16 mit TP2 auf dieser GPU ausdrücklich ab.
2. Der Kontext ist lang. Eine einzige 70B-Sitzung mit 128K kostet 40 GiB FP16-KV; zwei davon plus FP8-Gewichte sprengen die 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. Eine zweite Karte, am besten in einem zweiten Host, ist die einzige Antwort, und sie gilt auch dann, wenn die Rechnung sagt, eine Karte reiche völlig.

Was die zweite Karte hier besonders macht: Es gibt auf keiner Edition NVLink. Lenovos Produktleitfaden schreibt schlicht Nein; NVIDIAs Spezifikationstabelle und das Architektur-Whitepaper lassen es weg, und die Referenzarchitektur beschreibt die Platzierung der GPUs rein in PCIe-Begriffen.

NVIDIAs eigene H200-Seite druckt beide Zahlen nebeneinander: NVLink mit 900 GB/s je GPU gegen PCIe Gen 5 mit 128 GB/s, ungefähr das Siebenfache. Das ist die Steuer auf jeden Austausch zwischen GPUs und der Grund, warum die Wahl des Parallelismus keine Geschmacksfrage ist. vLLMs Dokumentation ist deutlich: Haben die GPUs keine NVLink-Verbindung, nehmen Sie Pipeline-Parallelismus statt Tensor-Parallelismus, für höheren Durchsatz und weniger Kommunikationsaufwand. Tensor-Parallelismus führt in jeder Schicht zwei All-Reduce-Operationen aus; Pipeline-Parallelismus reicht Aktivierungen einmal je Stufengrenze weiter.

Die Leiter läuft also der Reihe nach. 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. Erst wenn das Modell wirklich nicht passt, teilen Sie es, und dann bevorzugt pipeline-parallel. Tensor-Parallelismus bleibt unterstützt, mit TP2-, TP4- und TP8-Profilen in der NIM-Matrix; er zahlt nur eine PCIe-Steuer. Die Richtung ist dokumentiert; veröffentlichte Messungen ihrer Größe auf dieser Karte gibt es wenige, und unser Beitrag zu PCIe und NVLink sammelt sie.

Ein Auslegungsverfahren, das Sie diese Woche durchlaufen können

Nichts davon braucht ein Labor: Ein Nachmittag und eine Karte ergeben eine Zahl, die Sie verteidigen können, weil Sie sie gemessen haben.

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 einfach 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. 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, was die Rechnung auch gesagt hat.

Die Kurzfassung: Ein Assistent der 8B-Klasse auf einer Karte bedient bei langem Kontext Dutzende gleichzeitiger Sitzungen und bei realistischem Kontext weit über hundert; ein 32B-Modell Dutzende; ein 70B-Modell in FP8 einstellige Zahlen, die NVFP4 mehr als verdoppelt. Eurokommerz liefert RTX PRO 6000 Blackwell und die Server, in die sie gehören, EU-weit: Schicken Sie uns das Modell, den deklarierten Kontext und die Spitzen-Nebenläufigkeit aus Ihren Logs, und wir liefern das Speicher-Arbeitsblatt zurück.

FAQ