NVIDIA DGX Station GB300: welche offenen Modelle in 252 GB HBM3e laufen und was ausweicht

Welche offenen Modelle auf der DGX Station GB300 laufen

Offene Modelle mit bis zu rund 190 GiB Gewichten laufen auf der DGX Station GB300 vollständig in ihren 252 GB HBM3e, mit Platz für den KV-Cache. Dazu gehören gpt-oss-120b, Llama 3.3 70B in FP8, Qwen3.8-Flash-Next und GLM-5.3-Flash in NVFP4 sowie DeepSeek-V4-Flash-0731. Größere Modelle wie Beam-1.0 oder Kimi-K2.6 laden nur mit einem Teil der Gewichte in den 496 GB LPDDR5X der Grace-CPU, die rund ein Achtzehntel der Bandbreite liefern, und generieren deshalb mehrfach langsamer.

NVIDIAs Produktseite, gelesen am 24. Oktober 2026, nennt „252 GB HBM3e ECC | 7.1 TB/s“ für die GPU, „496 GB LPDDR5X ECC | 396 GB/s“ für die CPU und 900 GB/s für NVLink-C2C zwischen beiden und sagt, das System unterstütze „models up to 1 trillion parameters“. Die Spezifikationen, die Angabe von 784 GB aus dem Jahr 2025 und die Alternativen, die wir bauen, stehen in unserem Artikel DGX Station GB300: Spezifikationen und Alternativen. Diese Seite geht Modell für Modell vor.

Wie viel der 252 GB ein Modell nutzen kann

Unsere Regel für Nutzer je Karte nimmt 90 Prozent des Speichers, den der Treiber meldet, und zieht 3 GiB für Aktivierungen und Laufzeit ab. NVIDIA hat nicht veröffentlicht, was nvidia-smi für die GPU der Station meldet, wir planen deshalb mit 252 GB, also 234,7 GiB, als gemeldetem Wert. Für HBM ist das vorsichtig: Eine H200 NVL mit 141 GB im Datenblatt meldet 140,4 GiB. Das ergibt 0,9 × 234,7 − 3 = 208,2 GiB für Gewichte und Cache. NVIDIAs SGLang-Playbook für die Station startet den Server mit --mem-fraction-static 0.85, einem ähnlichen Anteil.

Die 496 GB LPDDR5X gehören nicht zu diesem Wert. Sie tragen das Betriebssystem, die Prozesse der Engine und alles, was die Engine gezielt dort ablegt. Die GPU erreicht diesen Speicher kohärent über NVLink-C2C, aber mit höchstens den 396 GB/s, die der Speicher selbst liefert.

Modelle, die im HBM3e bleiben

Die Tabelle führt aktuelle offene Modelle auf, deren Gewichte in die 208,2 GiB passen und Platz für Cache lassen. Die Größen sind die Safetensors-Dateien auf Hugging Face.

Dateilisten auf Hugging Face, gelesen am 24. Oktober 2026: Summe der Safetensors-Dateien oder die Repository-Summe, wo die Liste geblättert ist (Nemotron 3.5 Super VL, DeepSeek-V4-Flash-0731). Cache-Rest nach unserer Regel für Nutzer je Karte mit 208,2 GiB nutzbar.

Bei gpt-oss-120b belegt jedes Gespräch mit 32.768 Token 1,125 GiB 16-Bit-Cache, 147,4 GiB reichen also für rund 131 gleichzeitig. Llama 3.3 70B in FP8 hält 56 Gespräche mit 8K bei 16-Bit-Cache und 112 mit FP8-Cache, gegenüber 12 mit FP8-Cache auf einer RTX PRO 6000 Server Edition. Den Cache je Gespräch der Modelle mit hybrider Attention rechnen unsere Leitfäden je Modell aus: GLM-5.3-Flash auf vier RTX PRO 6000 Server Edition, Qwen3.8-Flash-Next auf zwei GPUs und DeepSeek-Hardware.

Von Qwen3.8-Flash-Next gibt es zwei NVFP4-Versionen. NVIDIAs Repository hat 132,6 GB, davon 53,7 GB in einer Datei, die laut Namen die FP8-Gewichte der MTP-Schichten und der N-Gramm-Embeddings enthält; die Version von Inferact hat 182,4 GB, und sie ist der Checkpoint, den NVIDIAs vLLM-Playbook für die Station herunterlädt. GLM-5.3-Flash in NVFP4 passt mit 17,7 GiB für den Cache, genug für Entwicklung und wenige Nutzer, nicht für eine Abteilung.

Gezählt sind Anfragen, die im selben Moment mit voller Länge laufen. Eine Station mit gpt-oss-120b bedient ein Team mit weit mehr als 131 Personen, weil nur wenige davon in derselben Sekunde generieren. Wir legen Stations und GPU-Server nach Modell und Lastspitze aus; teilen Sie uns Checkpoint und geplanten Kontext mit, und unser Team antwortet mit den Speicherwerten dafür.

Tempo, solange die Gewichte im HBM3e liegen

Jedes neue Token liest die aktiven Gewichte einmal, deshalb setzt die Bandbreite des Speichers, der sie hält, eine Obergrenze für eine Anfrage. Bei 7,1 TB/s kommt Llama 3.3 70B in FP8 mit rund 70,6 GB je Token auf höchstens rund 100 Token pro Sekunde, in NVFP4 mit rund 40,6 GB auf rund 175. gpt-oss-120b liest rund 5 GB je Token, seine Obergrenze liegt damit über 1.400. Das sind nach unserer Schätzung Obergrenzen; bei Mixture-of-Experts-Modellen liest ein Batch mehr Experten als eine einzelne Anfrage.

Zum Vergleich: Eine RTX PRO 6000 Server Edition mit 1.597 GB/s gibt demselben 70B-Modell in NVFP4 eine Obergrenze von rund 39 Token pro Sekunde. NVIDIAs Spezifikationstabelle nennt für die Station 20 PFLOPS FP4, mit dem Hinweis, dass Tensor-Core-Werte ohne gegenteilige Angabe mit Sparsity gelten. Die Blackwell-Ultra-GPU rechnet NVFP4 und FP8 nativ, NVFP4-Checkpoints sind darauf also die naheliegende Wahl.

Modelle, die in den LPDDR5X ausweichen

Ein Modell mit mehr als rund 190 GiB lädt trotzdem, aber die Engine muss einen Teil der Gewichte im Speicher der CPU ablegen. Die Tabelle nimmt an, dass 178 GiB Gewichte im HBM3e bleiben und dort 30 GiB für den Cache frei lassen; der Rest liegt im LPDDR5X.

Repository-Summen auf Hugging Face, gelesen am 24. Oktober 2026; Metas Model Card zu Muse Spark Open verlangt „a GPU with at least 700GB of VRAM for NVFP4“. Obergrenze gegenüber allen Gewichten im HBM3e nach unserer Rechnung, unter der Annahme, dass jedes Token seine Gewichte im selben Verhältnis aus beiden Stufen liest.

Die Rechnung: Ein Token, das den Anteil h seiner Gewichte aus HBM3e und l aus LPDDR5X liest, braucht h ÷ 7,1 + l ÷ 0,396 Zeiteinheiten, gegenüber 1 ÷ 7,1 mit allem im HBM3e. LPDDR5X ist 17,9-mal langsamer, mit 35 Prozent ausgelagert dauert das Token also 0,65 + 0,35 × 17,9 = 6,9-mal so lang. Schon 10 Prozent im LPDDR5X machen das 2,7-Fache. Bei Kimi-K2.6 mit 32B aktiven Parametern je Token und 1T insgesamt belegten Experten 376 GiB der 462 GiB LPDDR5X, für Betriebssystem und Engine blieben rund 86 GiB.

Wie eine Engine die Aufteilung vornimmt, ist entscheidend. vLLM dokumentiert --cpu-offload-gb, „the space in GiB to offload to CPU“, mit einem Zero-Copy-Backend über UVA, und getrennt davon --kv-offloading-size für KV-Cache im CPU-Speicher. Die Model Card von Kimi-K2.6 empfiehlt vLLM, SGLang und KTransformers; wie KTransformers Experten im CPU-Speicher hält, beschreibt unser Leitfaden zum MoE-Offload mit KTransformers. NVIDIAs Playbooks für vLLM und SGLang auf der Station beschreiben die Hardware nur als „Large HBM + Grace DRAM“ und sagen nichts zum Auslagern, und veröffentlichte Token-Raten für ein Modell über beide Stufen haben wir nicht gefunden. Testen Sie das geplante Modell mit der geplanten Engine, bevor Sie dafür kaufen.

Software auf der GB300: SM103, Arm und NVIDIAs Playbooks

NVIDIA nennt „Ubuntu with NVIDIA AI Developer Tools“ als Betriebssystem mit vorinstallierten CUDA-X-Bibliotheken, und die Grace-CPU ist eine Arm-CPU. vLLM 0.32.0 vom 18. Oktober veröffentlicht Wheels für CUDA 13.0 und 12.9 für x86_64 und arm64. NVIDIAs Playbook-Bibliothek für die Station enthält „Serve LLMs with vLLM on One Device“, aktualisiert am 19. Oktober 2026, das Inferact/Qwen3.8-Flash-Next-NVFP4 aus dem Image vllm/vllm-openai:qwen38-flash-next startet, und „Serve LLMs with SGLang“, aktualisiert am 31. Juli 2026.

Das SGLang-Playbook ergänzt drei Hinweise für die Station: „Add --ipc host and --cap-add SYS_NICE“, „--gpus all uses the GB300 when it is the only GPU“ und „Use --attention-backend flashinfer (required on GB300 / SM103)“. Seine Modellliste nennt DeepSeek-V4-Flash ein „Large local MoE for high-memory hardware platforms“ und ergänzt --quantization modelopt_fp4 für NVFP4-Checkpoints. Ein weiteres Playbook quantisiert Modelle mit NVIDIA Model Optimizer nach NVFP4. Zu NIM sagt NVIDIAs Produktseite, gelesen am 24. Oktober 2026, weiterhin, die Unterstützung sei „planned in June“, die Unterstützung im Production Branch sei für Oktober geplant.

GB300 ist SM103, Compute Capability 10.3, ein anderes Ziel als die 12.0 der RTX-PRO-Blackwell-Karten. Ein Kernel oder Container für das eine belegt nichts für das andere; unser Leitfaden zur Software-Unterstützung für Blackwell RTX auf SM120 behandelt die RTX-Seite. Modelle, Retrieval und die Plattform darüber auf einer Station oder einem Server zu betreiben, gehört zu unserem Service Private AI/ML; nennen Sie uns die geplanten Modelle und die Zahl der Nutzer, und wir antworten, ob eine Station oder ein Server sie im GPU-Speicher hält.

Zwei DGX Stations für Modelle über 252 GB

NVIDIAs Playbook „Connect Two DGX Stations for Distributed Workloads“, aktualisiert am 4. September 2026, verbindet zwei Systeme mit „two ConnectX-8 (CX8) QSFP cables“ ohne Switch, jedes Kabel „an independent 400 Gb/s RoCEv2 path“. Es richtet das Netz ein und empfiehlt die Prüfung mit „NCCL, Ray, vLLM, or other distributed applications“; ein Modell oder eine Parallelisierung nennt es nicht.

Nach unserer Regel halten zwei Stations 416,5 GiB im HBM3e. Beam-1.0 in NVFP4 mit 273,8 GiB passt dann vollständig in den GPU-Speicher, mit rund 143 GiB für den Cache. Kimi-K2.6 mit 554,1 GiB passt weiterhin nicht. Die zwei Links mit 400 Gb/s übertragen zusammen rund 100 GB/s; ein über beide Stations verteiltes Modell tauscht Daten also weit langsamer aus als innerhalb einer GPU, und Pipeline-Parallelismus, der nur Aktivierungen zwischen den Hälften sendet, ist die Aufteilung, die man zuerst testen sollte.

Strom, Stromkreis und MIG

NVIDIA gibt für die DGX Station 1.600 W an; die US-Seite ergänzt „20A circuit required“, eine Angabe für nordamerikanische Stromnetze, während die europäische Seite die 1.600 W ohne Anforderung an den Stromkreis nennt. Bei 230 V sind 1.600 W nach unserer Rechnung rund 7 A; die Elektrofachkraft, die Büro oder Technikraum plant, bestätigt den Stromkreis nach den örtlichen Vorschriften, und unser Artikel zum GPU-Server im Büro behandelt Wärme und Lautstärke. Die GPU lässt sich in bis zu sieben MIG-Instanzen aufteilen, mehrere kleine Modelle oder Entwickler können sie also isoliert teilen, während ein Modell, das die vollen 252 GB braucht, die ganze GPU nutzt.

Wann ein Server mit acht Karten besser passt

Muss ein Modell über 208 GiB vollständig im GPU-Speicher bleiben, oder nutzen es viele Personen gleichzeitig, hält ein Rack-Server mehr. Acht RTX PRO 6000 Server Edition bieten nach unserer Regel 664,3 GiB, genug für Kimi-K2.6 mit 110 GiB für den Cache, wie unsere Seite zu Kimi K2.7-Code auf acht RTX PRO 6000 Server Edition für ein Modell gleicher Größe ausrechnet. Acht H200 NVL bieten 986,9 GiB in zwei NVLink-Domänen, wie unser Leitfaden zum Server mit 8× H200 NVL zeigt. Beide ziehen nach unserer Schätzung rund 6,3 kW aus dem Netz und brauchen einen Serverraum.

Die Station bleibt die bessere Wahl für einen Entwickler oder ein kleines Team, das ein großes Modell auf einer GPU mit 7,1 TB/s am Arbeitsplatz betreiben will, und für Modelle bis rund 190 GiB, die sonst über mehrere PCIe-Karten verteilt würden. Unser Vergleich DGX Station und DGX Spark stellt sie dem kleineren GB10-System gegenüber.

Was wir liefern

Die DGX Station GB300 bauen die Hersteller, die NVIDIA aufführt, und wir liefern deren Versionen projektbezogen: Bevor wir ein Angebot machen können, fragt die Distribution nach Unternehmen, Projekt und vorgesehener Nutzung, wie unser Leitfaden DGX Station GB300 in der EU kaufen erklärt. Außerdem bauen wir KI-Server auf Bestellung mit RTX PRO 6000 Server Edition oder H200 NVL, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente. Sie können beides bei uns kaufen: Unser Team legt die Konfiguration auf Ihre Arbeitslast und Ihr Budget aus und antwortet innerhalb eines Werktages. Beschreiben Sie die Modelle und das Team, das sie nutzen wird, und wir schlagen die passende Station oder den passenden Server vor.

FAQ