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. Niemand veröffentlicht ein Verhältnis zwischen beiden, 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. NVIDIA hat für keine Edition dieser Karte eine absolute LLM-Zahl in Token pro Sekunde veröffentlicht. Die Seite zur Inferenzleistung trägt zwar einen Abschnitt mit der Überschrift RTX PRO 6000 Blackwell Server Edition, aber jedes Modell darin ist Bildverarbeitung oder Bilderzeugung, gemessen in Bildern oder Samples pro Sekunde. Die einzigen offiziellen LLM-Aussagen sind relativ: bis zum Fünffachen einer L40S, das 5,6-Fache bei Llama 3 70B, beides ohne Präzision, ohne Batch-Größe und ohne Sequenzlänge. MLPerf Inference v5.1 enthält keine von MLCommons verifizierte Einreichung für diese GPU, und Ciscos Werte für acht Karten aus jener Runde sind Eigenangaben, nur als Diagramme veröffentlicht, und Cisco selbst schreibt, MLCommons habe sie nicht verifiziert.

Jede selbstsichere Behauptung, eine RTX PRO 6000 leiste N Token pro Sekunde, führt also auf das Blog eines Vermieters zurück, und wir wiederholen keine davon mit einer Einschränkung daneben. 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

Die erste Zeile nennt die Token, die gleichzeitig in den KV-Cache passen; die zweite, wie viele Anfragen gleichzeitig bedient werden können, wenn jede die genannte Zahl an Token braucht, und sie ist schlicht die erste geteilt durch die Token je Anfrage: 643.232 / 40.960 = 15,70. Lesen Sie sie 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, ein halbes Byte für NVFP4. Llama 3.1 8B sind 16,1, 8,0 und 4,0 GB; Qwen3-32B 65,6, 32,8 und 16,4 GB; Llama 3.1 70B 141,2 GB in BF16, was nicht passt, 70,6 in FP8 und 35,3 in NVFP4. 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 96 GiB mal vLLMs Voreinstellung von 0,9 für gpu_memory_utilization, also 86,4 GiB, abzüglich rund 3 GiB Overhead, abzüglich der Gewichte.

Budget: 96 GiB × 0,9, abzüglich rund 3 GiB Overhead, abzüglich der Gewichte. 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 65,8 GiB Gewichte; 86,4 minus 65,8 minus 3 lassen 17,6 GiB; jede 8K-Sitzung kostet bei 320 KiB je Token 2,5 GiB; 17,6 geteilt durch 2,5 ergibt 7. Sieben gleichzeitige Gespräche voller Länge aus einer Karte, vierzehn mit einem FP8-Cache, zwanzig 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 sind 70,6 GB Gewichte, und 1.597 geteilt durch 70,6 sind etwa 22 Dekodierschritte pro Sekunde für einen einzelnen Nutzer ohne Batching, vor jedem Effizienzverlust. In NVFP4 halbieren sich die Gewichte, und die Grenze verdoppelt sich ungefähr auf etwa 45. 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? Brysbaerts Meta-Analyse von 190 Studien 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. Die Branche liefert gegen rund 50 Token pro Sekunde und Nutzer und eine Zeit bis zum ersten Token von höchstens 250 ms, weil Nutzer überfliegen und abbrechen und weil Reasoning-Modelle Denk-Token ausgeben, die niemand liest.

Batching: Gesamtdurchsatz gegen Latenz je Nutzer

Zwischen den beiden Obergrenzen sitzt der Scheduler, und der Hebel ist die Batch-Größe. NVIDIAs eigene Beschreibung: Bei niedriger Nebenläufigkeit sind Latenz und Durchsatz niedrig; bei hoher Nebenläufigkeit bedient Batching mehr Anfragen effizient und kostet Latenz. 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 eine B200 sowohl als Maschine mit 60.000 Token pro Sekunde als auch als Maschine mit 1.000 Token pro Sekunde, 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.

NVIDIAs NIM-Referenzarchitektur veröffentlicht durchaus Nebenläufigkeiten, aber auf einer H100 NVL: 137 Nutzer auf Llama 3.1 8B in FP8, 278 bei gemischter Last, nahe 1.000 ms bis zum ersten Token. Diese Karte trägt HBM3 mit weit höherer Bandbreite als GDDR7, das ist also eine Form und keine Ersatzzahl.

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, weil sie eine GPU ist; 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 ein All-Reduce 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. Wie hoch diese Steuer auf dieser Karte ist, veröffentlicht niemand: Die Richtung ist dokumentiert, die Größe nicht.

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. Entscheiden Sie hier die Quantisierung: 141,2, 70,6 und 35,3 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. 96 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 beiden Zeilen. 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 250 ms 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 ungefähr verdreifacht. 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