NVIDIA DGX Station GB300 im Team: wie viele gleichzeitige Nutzer und wie man sie abschätzt

Wie viele Nutzer eine DGX Station GB300 bedient, nach den veröffentlichten Dokumenten

Wie viele Nutzer eine NVIDIA DGX Station GB300 bedient, ist in keinem öffentlichen Dokument gemessen, das wir gelesen haben. NVIDIAs Blog vom 21. Oktober 2026 schreibt, das System könne „serve 30+ users at speeds comparable to those provided by cloud models“, und nennt weder Modellvariante noch Engine, Kontextlänge oder Token-Rate. Dokumentiert sind die sieben MIG-Instanzen der GPU und ihr Speicher: Nach unserer Sizing-Regel nehmen 208,2 GiB der 252 GB HBM3e Gewichte und KV-Cache auf. Daraus folgt eine Zahl gleichzeitiger Gespräche, die in den Speicher passen, und keine Aussage über ihr Tempo.

Diese Seite behandelt die gemeinsame Nutzung einer Station. Welche Modelle passen, steht in unserem Artikel dazu, welche offenen Modelle auf der DGX Station GB300 laufen, die Spezifikationen in DGX Station GB300: Spezifikationen und Alternativen.

Was NVIDIA und die Hersteller zu Teams und Nutzern sagen

NVIDIA positioniert die Station auf zwei Arten, als „an individual desktop for one user“ oder als „a centralized compute node for multiple team members“. Die Aussagen mit einer Zahl sind diese.

NVIDIAs Produktseite zur DGX Station (Seitenmetadaten vom 4. November 2026) und NVIDIAs Blog „Bringing the Spark to Europe: Local Intelligence Powers Next Wave of Agents“ vom 21. Oktober 2026; die Seiten von Dell, Supermicro und HP zu ihren Versionen; alle gelesen am 12. November 2026.

Der Blogsatz nennt „advanced models like GLM 5.3“ und sonst nichts. Ein zweiter Satz dort, „On DGX Station, GLM 5.3 Flash gets up to 1.2x higher throughput“, nennt keinen Vergleichswert. Zu diesem Modell sagt unsere veröffentlichte Speichertabelle: NVIDIAs NVFP4-Checkpoint von GLM-5.3-Flash belegt 190,5 GiB und lässt nach unserer Regel 17,7 GiB des HBM3e für den Cache. Ob der Blog diesen Checkpoint meint, einen anderen oder einen Cache im Speicher des Prozessors, ist nicht angegeben; die Zahl 30 lässt sich mit veröffentlichten Daten deshalb nicht prüfen.

In den am 12. November 2026 gelesenen Dokumenten gibt es keine öffentliche Mehrnutzer-Messung dieses Systems. NVIDIA veröffentlicht für die Station weder Token-Raten noch einen Test mit gleichzeitigen Nutzern, nicht auf der Produktseite, im Datenblatt, im Entwicklungsleitfaden, in den Playbooks oder im Blog. Das ergänzende Diskussionspapier von MLCommons zu MLPerf® Inference v6.1 nennt keine DGX Station; die Ergebnistabelle selbst war für uns nicht lesbar. Auch unsere Seiten enthalten keine Messung.

Drei Wege, wie ein Team eine DGX Station teilt

• Ein Modelldienst für alle. Eine Serving-Engine wie vLLM oder SGLang lädt ein oder mehrere Modelle auf die ganze GPU und fasst die Anfragen aller Nutzer zu Batches zusammen. NVIDIAs Entwicklungsleitfaden führt die „NVIDIA Container Runtime for Docker“ als enthalten und vLLM 26.03 sowie SGLang 26.03 als getestet auf. In diesem Modus ist ein Nutzer eine laufende Anfrage, und die Grenzen sind der Speicher für den KV-Cache und der Durchsatz der GPU.
• MIG-Instanzen. Die GPU wird in bis zu sieben isolierte Instanzen geteilt, jede mit eigenem Anteil an Speicher und Rechenleistung, für Entwickler oder für mehrere kleine Dienste nebeneinander.
• Konten und Fernzugriff. Das Betriebssystem ist ein Image mit Ubuntu 24.04, und Konten darauf sind gewöhnliche Linux-Administration. NVIDIA veröffentlicht für dieses System kein Kapitel zur Nutzerverwaltung; der „DGX Station User Guide“ auf der Dokumentationsseite beschreibt das System von 2017 mit vier Tesla V100 und gilt hier nicht.

NVIDIAs Blog vom 21. Oktober 2026 kündigt einen weiteren Weg an: „NVIDIA Cloud Functions is coming in early access to Linux-based DGX Station.“ Teams tragen lokale Modell-Endpunkte in einen gemeinsamen Katalog ein, sodass gilt: „teammates can use shared models without direct machine access“. Das ist die Ankündigung eines Early Access. NVIDIAs Brev-Playbook vom 21. September 2026 registriert die Station als verwaltete GPU-Umgebung für eine Brev-Organisation und behandelt die Isolation zwischen Nutzern nicht.

MIG auf der DGX Station mit bis zu sieben Instanzen

Laut NVIDIAs Produktseite lässt sich die GPU „into as many as seven instances“ aufteilen, für „local development with multiple users“, jede isoliert mit eigenem Speicher, Cache und eigenen Rechenkernen. NVIDIAs MIG User Guide führt für die GB300 mit 252 GB diese Profile auf.

NVIDIA MIG User Guide, Tabelle „GPU Instance Profiles on GB300“ (Seite vom 13. Oktober 2026), gelesen am 12. November 2026; „Rechenanteil“ ist NVIDIAs Anteil der SMs. Der Leitfaden führt außerdem 1g.31gb+me auf, eine Instanz mit Media-Erweiterungen.

Sieben Instanzen 1g.31gb belegen sieben Achtel des GPU-Speichers, nach unserer Schätzung aus NVIDIAs Anteilen, und jede hat ein Siebtel der Rechenleistung. Nach der Nenngröße liegt eine solche Instanz nahe an einer Karte mit 32 GB, eine Instanz mit 63 GB bei etwa dem Doppelten. NVIDIA veröffentlicht keinen Wert für den Speicher, den der Treiber je Instanz meldet; wir nennen deshalb kein Budget dafür. Dell macht aus der Grenze die Aussage, seine Version „serves up to seven developers“; NVIDIA selbst nennt für MIG keine Zahl von Entwicklern.

MIG auf der Station braucht Linux, CUDA 13 und einen Treiber des Zweigs R595 ab 595.58.03, nach der Seite des Leitfadens vom 4. November 2026. Grafik-APIs werden im MIG-Modus nicht unterstützt, außer mit den Profilen „+gfx“, und CUDA IPC funktioniert nicht über Instanzen hinweg. NVIDIAs MIG-Playbook für die Station schaltet den Modus mit nvidia-smi -mig 1 ein und vermerkt, dass das Ein- oder Ausschalten alle Workloads auf der GPU betrifft. Die Profilnamen in seinen Beispielen (1g.34gb, 2g.67gb, 7g.269gb) passen nicht zur Tabelle des User Guide für die GPU mit 252 GB; lassen Sie sich die Profile des gelieferten Systems mit nvidia-smi mig -lgip anzeigen. Ob eine MIG-Instanz die 496 GB LPDDR5X am Prozessor nutzen kann, sagt kein Dokument.

Der MIG-Modus ist eine Entscheidung für die ganze GPU. Ein Modell, das die vollen 252 GB braucht, nutzt die ganze GPU, und dann gibt es keine Instanzen für andere. Herstellerversionen der Station liefern wir projektbezogen, auf Wunsch mit eingerichteten Instanzen; nennen Sie uns, wie viele Entwickler eine isolierte Instanz brauchen und wie groß ihre Modelle sind, wir antworten innerhalb eines Werktages.

Gleichzeitige Nutzer aus Speicher und Durchsatz abschätzen

Unsere Methode ist die aus unserem Artikel dazu, wie viele Nutzer eine RTX PRO 6000 bedient, angewendet auf die Station.

1. Zählen Sie die laufenden Anfragen. Eine GPU bedient die Anfragen, für die in diesem Moment Token erzeugt werden; protokollieren Sie diese am Gateway und nehmen Sie die Spitze der Hauptlaststunde.
2. Nehmen Sie den nutzbaren Speicher: das 0,9-Fache des Speichers, den der Treiber meldet, abzüglich 3 GiB. NVIDIA hat den gemeldeten Wert für die Station nicht veröffentlicht; wir planen deshalb mit 252 GB, also 234,7 GiB, und erhalten 208,2 GiB.
3. Ziehen Sie die Gewichte des Checkpoints ab, den Sie laden werden.
4. Teilen Sie den Rest durch den KV-Cache eines Gesprächs beim deklarierten Kontext. Für Llama 3.3 70B sind das 2,5 GiB je 8.192 Token mit 16-Bit-Cache und 1,25 GiB mit FP8-Cache.
5. Starten Sie die Engine und lesen Sie ihr Log: vLLM gibt beim Start „GPU KV cache size“ und „Maximum concurrency“ aus. Messen Sie dann unter dieser Last die Zeit bis zum ersten Token und die Rate je Nutzer.

unsere Schätzungen nach der Regel oben mit 208,2 GiB nutzbarem Speicher, aus unserem Artikel zu den Modellen auf der DGX Station GB300 (Dateigrößen von Hugging Face, gelesen am 24. Oktober 2026; in den letzten beiden Zeilen NVIDIAs NVFP4-Checkpoints). „Hier nicht berechnet“: Den Cache je Gespräch dieser Modelle mit hybrider Attention rechnen die dort verlinkten Modell-Leitfäden aus.

Das sind nach unserer Schätzung Gespräche, die bei vollem Kontext in den Speicher passen. Die Zahlen sind eine Untergrenze, weil Gespräche, die ihren Kontext nie füllen, weniger belegen, und sie sagen nichts über das Tempo. Die Bandbreite des HBM3e setzt eine Obergrenze für eine Anfrage, nach unserer Schätzung rund 100 Token pro Sekunde für Llama 3.3 70B in FP8. Wie sich diese Rate verteilt, wenn viele Gespräche gleichzeitig laufen, bis zu den 112 der Tabelle, zeigt kein öffentlicher Test der Station. Zwei Richtwerte helfen, eine eigene Messung einzuordnen: Stilles Lesen mit 238 Wörtern pro Minute entspricht etwa 5,3 Token pro Sekunde, und das Szenario Interactive von MLPerf Inference v6.0 für Llama 2 70B erlaubt 40 ms je Token, also 25 Token pro Sekunde je Nutzer.

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.

Beschäftigte und laufende Anfragen sind verschiedene Größen. Nach den Beispielwerten unseres Leitfadens Privater ChatGPT-Server nach Unternehmens­größe erzeugen 100 Beschäftigte in der Spitze der Hauptlaststunde rund vier laufende Anfragen: 40 Prozent der Beschäftigten in dieser Stunde aktiv, je sechs Anfragen pro Stunde, 30 Sekunden je Anfrage und ein Spitzenfaktor von zwei. Das sind Beispielwerte, die ein Pilot durch die Zahlen aus den eigenen Gateway-Logs ersetzt. Über diese Methode hinaus nennen wir für die Station keine Nutzerzahl. Stations und GPU-Server legen wir aus diesen Angaben aus; schicken Sie uns Checkpoint, Kontextlänge und Ihre Spitze laufender Anfragen, wir antworten mit der Speicherrechnung dazu.

Arbeitslasten, die zu einer geteilten Station passen

• Entwicklung für wenige Personen. Container je Entwickler auf der ganzen GPU, oder MIG-Instanzen, wo Entwickler einander nicht stören dürfen. Jede Instanz 1g.31gb hat ein Siebtel der Rechenleistung.
• Fine-Tuning-Läufe in der Warteschlange. NVIDIA positioniert die Station für Teammitglieder, die „fine-tune and run IP-specific models on-demand“. Ein Fine-Tuning-Lauf und ein Modelldienst teilen sich dieselbe GPU, solange MIG sie nicht trennt; die Läufe werden deshalb nacheinander oder außerhalb der Arbeitszeit geplant.
• Ein interner Assistent für eine Abteilung. Ein Modelldienst auf der ganzen GPU, nach der Methode oben aus der Spitze laufender Anfragen ausgelegt. Mit gpt-oss-120b hält der Speicher rund 131 Gespräche mit 32K.

Zwei Grenzen gehören in die Planung. Die Station hat eine GPU und in den Versionen von Gigabyte und Supermicro ein einzelnes Netzteil; ein Treiber-Update, ein Defekt oder ein ausgelöster Stromkreis stoppt also alle Nutzer zugleich. Und der Prozessor ist ein Arm-Prozessor: Jedes Werkzeug, das das Team installiert, braucht eine Arm64-Version, wie unser Vergleich DGX Station GB300 vs. RTX PRO 6000 Workstation ausführt. Strom, Abwärme und Lautstärke einer Station neben Arbeitsplätzen behandelt DGX Station GB300: Stromverbrauch und Kühlung im Büro.

Wann ein Server das richtige System ist

In drei Fällen passt ein Rack-Server besser.

• Der Dienst darf nicht ausfallen. Zwei Knoten, jeder für die Spitze ausgelegt, erlauben das Update des einen, während der andere bedient; siehe hochverfügbare LLM-Inferenz auf zwei Knoten.
• Viele gleichzeitige Nutzer eines mittelgroßen Modells. Kopien des Modells auf getrennten Karten wachsen mit der Kartenzahl. Nach derselben Regel hält ein 2U-Server mit vier NVIDIA RTX PRO 4500 Blackwell Server Edition (je 32 GB und ein Budget von 25,7 GiB) vier Kopien von Qwen3-14B in FP8 für 64 Gespräche mit 8K und FP8-Cache, acht Karten halten 128. Die Karte steht auf unserer Kaufseite zur RTX PRO 4500 Server Edition und in ihren technischen Daten; den Server beschreibt vier RTX PRO 4500 Server Edition in 2U.
• Ein Modell über 208 GiB, das im GPU-Speicher bleiben muss. Acht RTX PRO 6000 Server Edition halten nach unserer Regel 664,3 GiB (technische Daten).

Der Inferenz-Knoten mit vier Karten auf unserer Seite zu KI-Servern ist gebaut für „Produktive Inferenz für mehrere Teams, Multi-Model-Serving“, und den Weg von einem System zu mehreren beschreibt unser Artikel zum Skalieren privater KI-Hardware vom Piloten zum Betrieb. Sie können die Station oder den Server allein bestellen, die Einrichtung von Serving-Engine, Konten und MIG-Aufteilung allein oder beides zusammen: das System mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Was wir für ein Sizing von Ihnen brauchen

• das Modell und den Checkpoint (Präzision) sowie die Kontextlänge, die Sie deklarieren werden;
• die Spitze laufender Anfragen, oder die Zahl der Beschäftigten und die geplante Nutzung des Assistenten, wenn noch keine Logs vorliegen;
• wie das Team das System teilt: ein Modelldienst, MIG-Instanzen für Entwickler, Fine-Tuning-Läufe;
• Software, die es nur für x86 gibt;
• Unternehmen, Projekt und Verwendungszweck, nach denen die Distribution fragt, bevor wir eine Station anbieten können.

Das Formular unten erreicht uns, ebenso eine E-Mail an request@eurokommerz.at. Das erste Gespräch ist kostenlos. Unser Artikel zu den zehn Angaben einer Sizing-Anfrage für private KI erklärt jeden Punkt, und Hersteller und Bestellung stehen in DGX Station GB300 in der EU kaufen. Ein kleineres geteiltes System beschreibt ein DGX Spark für ein Team.

FAQ