DGX Spark ist die richtige Wahl für die lokale Entwicklung, das Prototyping und Experimente eines einzelnen Spezialisten; DGX Station eignet sich, wenn deutlich mehr Speicher, größere Modelle oder eine gemeinsam genutzte Rechenressource für ein kleines Team benötigt werden; ein rackmontiertes DGX-System ist erforderlich, wenn künstliche Intelligenz zu einem dauerhaft verfügbaren Dienst mit parallelen Nutzern und Anforderungen an Verfügbarkeit, Fehlertoleranz, Monitoring und Skalierbarkeit wird. Die Grenze zwischen Desktop-KI und Rechenzentrum wird nicht durch die Parameterzahl des Modells oder die Spitzenleistung in Petaflops bestimmt, sondern durch die Verantwortung für das Ergebnis: Wenn der Ausfall eines einzelnen Geräts den Betrieb für Kunden oder einen Geschäftsprozess beeinträchtigt, reicht eine einzelne Workstation nicht mehr aus.
In diesem Artikel wird der Begriff DGX Server als allgemeine Bezeichnung für rackmontierte NVIDIA-DGX-Systeme und die darum aufgebaute Infrastruktur verwendet. Er ist nicht der Name eines eigenständigen Modells. Als aktuelles Beispiel der Serverklasse dient DGX B300. Die technischen Daten entsprechen dem Stand von Juli 2026.
NVIDIA DGX servers
Drei Systemklassen — drei Betriebsmodelle
DGX Spark gehört in der Regel einem einzelnen Entwickler, der damit Modelle testet, Prototypen erstellt und eine künftige Architektur bewertet. Ein Ausfall unterbricht die persönliche Arbeit, legt jedoch keinen externen Dienst still.
DGX Station kann als leistungsstarker persönlicher Rechner oder als gemeinsam genutzter Knoten für ein kleines Team eingesetzt werden. Serverfunktionen für die Verwaltung ermöglichen die Aufstellung in einem separaten Raum, physisch bleibt es jedoch ein einzelnes System und damit ein Single Point of Failure.
Ein rackmontiertes DGX-System ist von Anfang an für ein Rechenzentrum sowie die Anbindung an gemeinsame Netzwerke, Speicher, Monitoring und Scheduler ausgelegt. Hohe Verfügbarkeit entsteht erst durch mehrere Knoten und die sie umgebende Infrastruktur.
DGX Spark, DGX Station und Rack-DGX: die wichtigsten Unterschiede
| Kriterium | DGX Spark | DGX Station | Rack-DGX |
|---|---|---|---|
| Hauptaufgabe | Persönliche Entwicklung | Anspruchsvolle lokale Workloads und gemeinsam genutzte Teamressource | KI-Plattform für den Produktivbetrieb |
| Nutzer | Ein Hauptnutzer | Ein Spezialist oder ein kleines Team | Mehrere Teams und Dienste |
| Typische Workloads | Prototypen, lokale Ausführung, parametereffizientes Fine-Tuning | Große Modelle, lange Kontexte, Forschung | Inferenz unter Last, Training, gemeinsame Dienste |
| Aufstellungsort | Arbeitsplatz | Büro, Labor oder separater Raum | Dafür ausgelegtes Rechenzentrum |
| Verwaltung | Überwiegend lokal | BMC, Redfish und GPU-Monitoring | Zentralisierte Verwaltung von Knoten und Cluster |
| Skalierung | Ein oder zwei Systeme | Bis zu zwei verbundene Station-Systeme | Mehrere Server und Racks |
| Fehlertoleranz | Nicht vorgesehen | Eine Ausfalldomäne | Über mehrere Knoten hinweg ausgelegt |
| Auswahlkriterium | Geschwindigkeit persönlicher Iterationen | Modellkapazität und gemeinsamer Zugriff | SLA, Last und Wachstum |
Die Spitzenleistung dieser Systeme lässt sich nicht direkt in Token pro Sekunde umrechnen. Die tatsächliche Geschwindigkeit hängt von Architektur und Präzision des Modells, Kontextlänge, Batchgröße der Anfragen, Parallelisierung und Softwareumgebung ab.
DGX Spark: ein persönliches System, kein Miniatur-Rechenzentrum
Offizielles Bild von DGX Spark.
Bildquelle: NVIDIA
DGX Spark basiert auf dem GB10 Grace Blackwell Superchip mit einem Arm-Prozessor mit 20 Kernen. Das System verfügt über 128 GB kohärenten LPDDR5X-Speicher, ein 4-TB-NVMe-Laufwerk, einen ConnectX-7-Adapter, 10-Gbit/s-Netzwerk und ein 240-W-Netzteil. NVIDIA gibt an, dass es bis zu 1 Petaflop FP4-Rechenleistung erreicht, Modelle mit bis zu 200 Milliarden Parametern unterstützt und das Fine-Tuning von Modellen mit bis zu 70 Milliarden Parametern ermöglicht. Zwei Systeme lassen sich für Experimente mit Modellen mit bis zu 405 Milliarden Parametern verbinden.
Diese Grenzwerte bedeuten nicht für jedes Modell dieselbe Geschwindigkeit. Dass sich die Gewichte laden lassen, garantiert noch keine komfortable Generierung bei langem Kontext oder mehreren Nutzern.
Wofür Spark geeignet ist
- lokale Entwicklung von Anwendungen und KI-Agenten;
- Inferenz für den persönlichen Gebrauch;
- Prototyping einer Dokumentensuche;
- Experimente mit Quantisierung und LoRA;
- Tests von Containern und Bibliotheken;
- Verarbeitung vertraulicher Daten;
- Vorbereitung eines Projekts für die Migration in die Cloud oder ein Rechenzentrum.
Spark beschleunigt persönliche Iterationen, doch seine 128 GB LPDDR5X dürfen nicht mit serverseitigem HBM gleichgesetzt werden. Neben den Gewichten belegen auch Kontext-Cache, Arbeitspuffer, Aktivierungen und das Betriebssystem Speicher. Ein Modell kann daher erfolgreich geladen werden, bei langem Kontext oder mehreren Nutzern aber zu langsam reagieren.
Spark verwendet Arm. Die NVIDIA-Werkzeuge unterstützen diese Architektur, eigene Erweiterungen und ältere Container können jedoch ausschließlich für x86 erstellt worden sein. Das muss vor einer Migration berücksichtigt werden.
Was die Verbindung zweier Spark-Systeme bringt
Zwei Systeme sind für Experimente mit größeren Modellen und verteilter Ausführung nützlich. Die Kommunikation läuft jedoch über ein externes Netzwerk, wodurch Latenzen, Abhängigkeiten von der Parallelisierungsstrategie und eine komplexere Diagnose entstehen.
Dies bleibt eine Forschungskonfiguration und ist kein direkter Ersatz für einen Multi-GPU-Server. In einem Rack-System sind die Beschleuniger über eine spezialisierte interne Fabric verbunden, während zwei Spark-Geräte eigenständige Computer bleiben.
DGX Station: Workstation und persönliche Cloud
DGX Station auf Basis von GB300 Grace Blackwell Ultra bietet 252 GB HBM3e auf der GPU-Seite und 496 GB LPDDR5X auf der CPU-Seite, insgesamt also 748 GB kohärenten Speicher. NVIDIA nennt bis zu 20 Petaflops FP4-Rechenleistung, Unterstützung für Modelle mit bis zu einer Billion Parametern, einen ConnectX-8-Adapter mit bis zu 800 Gbit/s, sieben MIG-Instanzen, BMC, Redfish und NVIDIA Data Center GPU Manager. Die Gesamtleistungsaufnahme des Systems erreicht 1.600 W.
Auch die Angabe von 748 GB muss erläutert werden. Das System stellt einen einheitlichen kohärenten Adressraum bereit, doch die 252 GB HBM3e und die 496 GB CPU-Speicher besitzen unterschiedliche Bandbreiten. Es handelt sich nicht um 748 GB gleich schnellen GPU-Speicher.
Wann Station Spark deutlich überlegen ist
Station wird benötigt, wenn Modell und Kontext nicht in 128 GB passen, das Fine-Tuning mehr Arbeitsspeicher erfordert, große Datensätze verarbeitet werden oder ein kleines Team ein System gemeinsam nutzt.
Bis zu sieben MIG-Instanzen ermöglichen es, den Beschleuniger auf mehrere Workloads aufzuteilen. Jede Instanz erhält einen Anteil an Rechenressourcen, Cache und HBM. Beispielsweise kann ein Spezialist ein Modell ausführen, ein zweiter Daten analysieren und ein dritter eine aktualisierte Softwareumgebung testen.
MIG fasst Ressourcen jedoch nicht zu einem größeren Beschleuniger zusammen. Die Technologie teilt eine physische GPU in isolierte Partitionen; sie beschleunigt keine einzelne Aufgabe, indem alle unabhängigen Instanzen gebündelt werden.
Warum Station als persönliche Cloud bezeichnet wird
Station kann in einem separaten Raum aufgestellt und als gemeinsam genutzter Serverknoten eingesetzt werden. BMC, Redfish und DCGM stellen Fernverwaltung und Metriken bereit, während das Team Ressourcen aufteilen, eine gemeinsame Modellsammlung nutzen und Aufträge in eine Warteschlange stellen kann.
Vom Zugriffsmodell her handelt es sich um eine kleine interne Cloud-Ressource. Das System kann ohne angeschlossenen Monitor betrieben werden, während Nutzer Berechnungen aus der Ferne starten.
Warum es dennoch kein Rechenzentrum ist
MIG isoliert Nutzer innerhalb eines Beschleunigers, doch jede Partition hängt vom selben Gehäuse, derselben Stromversorgung und demselben Softwareknoten ab. Ein Update oder Hardwarefehler stoppt sämtliche Workloads.
Eine einzelne Station bietet nicht automatisch:
- Weiterleitung von Anfragen an einen Standby-Knoten;
- Updates ohne dienstweiten Ausfall;
- gleichbleibende Leistung bei Lastspitzen;
- fehlertoleranten gemeinsamen Speicher;
- unabhängige Skalierung mehrerer Dienste;
- Redundanz für Modelle und Anwendungszustände.
DGX Station kann als Server dienen, ersetzt aber keinen Cluster und schafft für sich allein keine Hochverfügbarkeit.
Auch zwei verbundene Station-Systeme bleiben zwei Knoten. Für eine dauerhaft laufende Anwendung sind ein externer Load Balancer, gemeinsamer Speicher, die Synchronisierung der Konfiguration und eine Anwendungslogik erforderlich, die den Verlust eines Systems verkraftet.
Was sich beim Wechsel zu einem Rack-DGX ändert
Offizielle Vorderansicht des NVIDIA DGX B300 mit montierter Frontblende.
Bildquelle: NVIDIA DOCS
DGX B300 verdeutlicht die Größenordnung des Unterschieds. Sein 10U-Gehäuse enthält acht Blackwell-Ultra-SXM-Beschleuniger mit insgesamt 2,1 TB GPU-Speicher. Zwei NVLink-Switches liefern eine aggregierte Bandbreite von bis zu 14,4 TB/s zwischen den Beschleunigern. Für externe Verbindungen stehen ConnectX-8 mit bis zu 800 Gbit/s und eine BlueField-3-DPU zur Verfügung. Die geschätzte Leistungsaufnahme eines Systems liegt bei rund 14 kW.
Es handelt sich nicht lediglich um eine schnellere Station. Ein Rack-DGX ist ausgelegt für:
- zentralisierte Nutzung durch mehrere Teams;
- groß angelegtes und verteiltes Training;
- vollständiges oder ressourcenintensives Fine-Tuning;
- umfangreiche Batchverarbeitung;
- Bereitstellung mehrerer Modelle;
- produktive Inferenz mit parallelen Anfragen;
- dauerhaft laufende Agenten und Unternehmens-KI-Dienste;
- Anbindung an gemeinsame Speicher- und Verwaltungsnetze.
Im DGX B300 sind die Beschleuniger über die NVLink-Fabric verbunden. Bei Modellen, die auf mehrere GPUs verteilt sind, unterscheidet sich dies grundlegend von der Kommunikation zwischen separaten Desktop-Systemen über ein externes Netzwerk.
Hochgeschwindigkeitsverbindungen werden nicht nur für das Training benötigt. Auch bei der Inferenz kann ein großes Modell auf mehrere Beschleuniger verteilt werden. Wenn Modellpartitionen fortlaufend Aktivierungen austauschen, wirken sich Latenz und Bandbreite der Verbindung unmittelbar auf die Gesamtleistung aus.
Die Serverklasse wird durch mehr als nur die GPU bestimmt
Ein Rack-System ergänzt Hardwareverwaltung, Diagnose, Enterprise-Monitoring, Scheduler, Quoten, zentralisierte Updates und Verbindungen zu getrennten Verwaltungs-, Speicher- und Rechennetzen.
Ein einzelner DGX B300 bleibt jedoch ein Single Point of Failure, wenn alle Anfragen an ihn geleitet werden. Acht GPUs in einem Gehäuse erhöhen die Leistung, schützen die Anwendung aber nicht vor einem Serverausfall, einem Fehler des Betriebssystems oder einer Wartungsunterbrechung.
Ein DGX-Server ist noch kein Rechenzentrum
Außerhalb des Gehäuses benötigt ein Server Stromversorgung, Kühlung, Netzwerk, Speicher und ein Betriebskonzept. Erst diese umgebende Infrastruktur macht aus einem Rechenknoten eine produktive Plattform.
Für DGX B300 beschreibt NVIDIA ein Rack mit zwei Systemen, das im Durchschnitt etwa 30 kW und in der Spitze bis zu 39,4 kW verbraucht. Eine dichte Konfiguration mit vier Systemen benötigt durchschnittlich rund 58 kW und in der Spitze bis zu 76 kW. Die Dokumentation behandelt außerdem dreiphasige Stromversorgung, Redundanz, Bodenlast, Wartungsgänge, Verkabelung, Leckageerkennung und Kühlung.
Das Projekt erfordert außerdem redundante Stromversorgung und Kühlung, Verwaltungs- und Rechennetze, gemeinsamen Speicher, eine Modell-Registry, einen GPU-Scheduler, Load Balancer, zentralisierte Metriken und Protokolle, Zugriffskontrolle, Backups und eine automatisierte Bereitstellung.
Eine alternative Infrastruktur muss nicht auf ein vorkonfiguriertes DGX-System beschränkt sein. Unternehmen können universelle Dell-PowerEdge-Server der 17. Generationin Betracht ziehen, bei denen Beschleuniger, Prozessoren, Speicher und Netzwerk passend zum Workload konfiguriert werden.
Für Systeme mit PCIe-GPUs sind außerdem AMD-EPYC-Server aufgrund ihrer hohen Zahl an PCIe-Lanes gefragt, ebenso wie Intel-Xeon-Server, wenn die Infrastruktur bereits auf dieser Plattform standardisiert ist.
Ein vorkonfiguriertes DGX vereinfacht die Kompatibilität von Komponenten und Software-Stack. Ein OEM-Server bietet mehr Freiheit bei der Auswahl der Konfiguration. In beiden Fällen entsteht Fehlertoleranz durch eine Architektur mit mehreren Knoten und nicht durch die Hardwaremarke.
DGX System, BasePOD und SuperPOD sind nicht dasselbe
Ein einzelnes DGX System ist ein Rechenknoten. DGX BasePOD ist eine Referenzarchitektur, um mehrere Systeme mit Netzwerk, Speicher und Verwaltung zu kombinieren.
DGX SuperPOD ist eine skalierbare Rechenzentrumsplattform, in der Rechenknoten, InfiniBand und Ethernet, Verwaltungsserver, Software und Speicher als einheitliches System konzipiert werden. Die NVIDIA-Dokumentation beschreibt SuperPOD ausdrücklich als Kombination aus DGX-Systemen, Netzwerk-Fabrics, Verwaltungsknoten und Speicher und nicht lediglich als mit GPUs gefüllte Racks.
Nach dem ersten Server ist nicht mehr die einzelne Maschine das eigentliche Planungsobjekt. Datenpfade, die Zahl der Netzwerkports, Speicherbandbreite, Redundanz der Verwaltungsdienste und das Verhalten der Anwendungen beim Verlust eines Knotens müssen berechnet werden.
SuperPOD ist nicht für jedes Projekt erforderlich. Zwischen einer einzelnen Workstation und einer groß angelegten Installation liegen viele Zwischenstufen: mehrere GPU-Server, ein kleiner Cluster, in einem Rechenzentrum untergebrachte Hardware oder eine Kombination aus lokalen Ressourcen und Cloud-Diensten.
Es ist nachvollziehbar, nur so viel wie nötig zu investieren. Eine Station mit BMC ist im Grunde ein Server und reicht in manchen Fällen aus, aber nicht in allen.
Wann Station nicht mehr ausreicht
| Veränderung im Projekt | Einschränkung einer einzelnen Station | Was die Serverinfrastruktur ergänzt |
|---|---|---|
| Kunden nutzen das Modell dauerhaft | Der Ausfall eines Knotens stoppt den Dienst | Mehrere Instanzen und Lastverteilung |
| Die Zahl paralleler Anfragen wächst | Warteschlangen und Latenz nehmen zu | Horizontale Skalierung |
| Mehrere Teams arbeiten gleichzeitig | Nutzer konkurrieren um eine GPU | Ressourcenpools, Quoten und Prioritäten |
| Verschiedene Modelle werden gleichzeitig benötigt | Speicher und Rechenleistung werden fragmentiert | Routing und unabhängige Skalierung |
| Updates dürfen keinen Ausfall verursachen | Die gesamte Station muss angehalten werden | Schrittweise Aktualisierung der Knoten |
| SLA-Anforderungen entstehen | Ein Gehäuse bleibt ein Single Point of Failure | Redundanz und automatisches Failover |
| Das Volumen von Daten und Artefakten wächst | Lokale Laufwerke reichen nicht aus | Gemeinsamer Speicher und eine Modell-Registry |
| Kontinuierliche Beobachtbarkeit ist erforderlich | Die Telemetrie eines Knotens zeigt nicht den gesamten Dienst | Einheitliche Metriken, Protokolle und Warnmeldungen |
Desktop-KI endet dort, wo die Ausgabe des Modells zu einer Verpflichtung gegenüber anderen Menschen oder Geschäftssystemen wird. Ein kleines Modell kann einen Servercluster erfordern, wenn es rund um die Uhr von Tausenden Nutzern aufgerufen wird. Umgekehrt kann ein Modell mit Hunderten Milliarden Parametern eine Forschungslast auf Station bleiben, wenn nur ein Spezialist damit arbeitet und Ausfallzeiten akzeptabel sind.
Der Übergang wird in der Regel durch fünf Veränderungen ausgelöst:
- Ausfallzeiten verursachen Kosten. Ein Systemausfall beeinträchtigt Vertrieb, Kundensupport, Produktion oder interne Abläufe.
- Der Workload wird unvorhersehbar. Ein Knoten bewältigt den durchschnittlichen Datenstrom, hält Lastspitzen jedoch nicht stand.
- Die Ressourcenverantwortung verteilt sich. Teams benötigen Quoten, Prioritäten und Isolation.
- Updates können nicht mehr für alle gleichzeitig durchgeführt werden. Der Datenverkehr muss zwischen Versionen umgeschaltet werden.
- Das Modell wird Teil einer Anwendung. Beobachtet werden muss der vollständige Anfragepfad und nicht nur die GPU-Auslastung.
Welche Klasse zu verschiedenen Workloads passt
Lokale Entwicklung und RAG
Spark eignet sich für häufige Experimente mit Code, Prompts, Quantisierung und einem begrenzten Dokumentenindex.
Station wird benötigt, wenn Modell, Kontext oder Datensatz nicht in 128 GB passen oder eine ganze Abteilung die Ressource gemeinsam nutzt. Für die lokale Unternehmenssuche kann sie eine praktische Zwischenlösung sein.
Ein Serverpool wird erforderlich, wenn die Suche viele Nutzer bedient, unterschiedliche Zugriffsrechte auf Dokumente berücksichtigt und ohne gemeinsames Wartungsfenster laufen muss. In diesem Fall müssen neben dem Modell auch die Vektordatenbank, der Abruf der Quelldokumente und die Anwendungsschnittstelle skaliert werden.
Fine-Tuning
LoRA und andere parametereffiziente Verfahren eignen sich für Spark oder Station bei Modellen mittlerer Größe. Sie verändern einen vergleichsweise kleinen Anteil der Parameter und benötigen keinen Speicher für einen vollständigen Satz trainierbarer Gewichte und Optimiererzustände.
Vollständiges Fine-Tuning benötigt Speicher für Gewichte, Gradienten, Optimiererzustände, Aktivierungen und Daten. Der Arbeitsbedarf kann ein Vielfaches der Dateigröße des fertigen Modells betragen.
Wird ein Workload auf mehrere GPUs verteilt, werden NVLink, das externe Netzwerk und die Speichergeschwindigkeit entscheidend. Wenn Beschleuniger auf Daten oder Synchronisierung warten und dadurch untätig bleiben, wird ihre Spitzenleistung nicht genutzt.
Inferenz und KI-Agenten
Für einen einzelnen Nutzer sind Modellkapazität und Antwortzeit entscheidend. Ein produktiver Dienst muss zusätzlich parallele Anfragen, Latenz, Warteschlangen, mehrere Modellversionen und die Wiederherstellung nach einem Ausfall steuern.
Ein persönlicher Agent kann auf Spark laufen, ein Agent für eine Abteilung auf Station. Ein Multi-Agenten-System, das mit Unternehmensanwendungen verbunden ist, erfordert einen serverseitigen Betrieb: Speicherung des Zustands, Zugriffskontrolle, Wiederholungen fehlgeschlagener Vorgänge und Beobachtbarkeit des gesamten Prozesses.
Das Sprachmodell selbst kann dabei weiterhin eine moderate Größe haben. Die Infrastruktur wird nicht nur durch den Rechenbedarf komplexer, sondern auch durch die Anzahl der Werkzeuge, die Dauer der Aufgaben, die gespeicherte Historie und die Kosten einer fehlerhaften Aktion.
Warum die Speicherkapazität nur ein Teil der Berechnung ist
Bei der Inferenz belegen nicht nur die Gewichte Speicher, sondern auch der Kontext-Cache, der mit der Zahl der Dialoge und der Länge ihrer Historie wächst. Beim Fine-Tuning kommen Aktivierungen, Gradienten und Optimiererzustände hinzu. Quantisierung verkleinert die Gewichte, beseitigt die übrigen Speicheranforderungen jedoch nicht und kann Qualität sowie Geschwindigkeit beeinflussen.
Lokaler NVMe-Speicher ist für das aktive Modell praktisch, ein Team benötigt jedoch einen gemeinsamen Katalog, Versionierung, Zugriffsrechte, Backups und einen schnellen Datentransfer zwischen Knoten. In produktiven Umgebungen werden aktiver Datenspeicher, Objektarchiv, Modell-Registry und Backups üblicherweise getrennt.
Auch das Netzwerk besteht aus mehreren Ebenen:
- Nutzerzugriff auf die Anwendung;
- Hardwareverwaltung;
- Kommunikation zwischen Rechenknoten;
- Abruf von Modellen und Datensätzen;
- Übertragung von Metriken und Protokollen.
Das Vorhandensein von ConnectX im Gehäuse schafft ohne geeignete Switches, Kabel, Topologie und Software noch keine Cluster-Fabric.
Wirtschaftlichkeit: Der Systempreis ist nicht der einzige Kostenfaktor
Für die Entwicklung sind Wartezeit auf den Beschleuniger, Geschwindigkeit der Experimente, Datenspeicherung und Personalkosten wichtig. Bei einem produktiven Dienst zählen Kosten pro Anfrage, GPU-Auslastung, Latenz, Reservekapazität, Strom, Kühlung, Netzwerk, Support und Verluste durch Nichtverfügbarkeit.
Spark wird zur falschen Ersparnis, wenn mehrere Spezialisten täglich darauf warten, dass die Ressource frei wird. Ein Cluster ist unwirtschaftlich, wenn er dauerhaft ungenutzt bleibt. Station ist häufig die Zwischenstufe: Sie beseitigt den Speichermangel und ermöglicht gemeinsamen Zugriff, ohne ein vollständiges Rechenzentrumsprojekt zu erfordern.
Auch das Lastprofil muss berücksichtigt werden. Interaktive Entwicklung erzeugt meist unregelmäßige Spitzen: Ein Spezialist startet ein Experiment, bewertet das Ergebnis und ändert den Code. Produktive Inferenz kann kontinuierlich laufen, ihre Last hängt jedoch von Tageszeit und Nutzeraktivität ab.
Die Cloud eignet sich für gelegentliche große Trainingsläufe und Lastspitzen, während dauerhafte und vorhersehbare Workloads eigener Hardware zugewiesen werden können. Ein hybrides Modell erfordert portable Container und einen Speicher, der von der Rechenumgebung unabhängig ist.
Wie ein Projekt von Spark über Station zu einer Serverplattform wechselt
Persönlicher Prototyp
Der Entwickler testet das Modell und die Anwendungsarchitektur. Bereits in dieser Phase werden Containerisierung, eine reproduzierbare Umgebung sowie Messungen von Speicherverbrauch und Latenz benötigt. Daten und Zustand sollten nicht fest an das lokale Laufwerk von Spark gebunden sein.
Gemeinsam genutzte Teamressource
Sobald mehrere Nutzer hinzukommen, wird der Workload auf Station oder einen anderen leistungsstarken Knoten verlagert. Ergänzt werden Fernzugriff, eine Auftragswarteschlange, GPU-Partitionierung, eine gemeinsame Modellsammlung und Betriebsmetriken.
In dieser Phase zeigt sich, wie häufig sich Nutzer gegenseitig beeinträchtigen, ob die MIG-Isolation ausreicht und ob das gesamte System für Updates angehalten werden kann.
Produktiver Dienst
Im Rechenzentrum wird die Anwendung auf mehreren Knoten bereitgestellt, Rechenleistung und Speicher werden getrennt und Lastverteilung, Versionsverwaltung sowie automatische Wiederherstellung werden ergänzt.
Spark und Station verwenden Arm-Prozessoren, während DGX B300 Intel Xeon nutzt. Container müssen daher für mehrere Architekturen erstellt und binäre Erweiterungen separat getestet werden. Der einheitliche NVIDIA-Stack erleichtert die Migration von Modellen, garantiert jedoch nicht die Kompatibilität des gesamten benutzerdefinierten Codes.
Gemessen werden sollte der vollständige Anfragepfad: Datenabruf, Suche, Vorbereitung des Kontexts, Modellausführung und Speicherung des Ergebnisses. Eine schnellere Generierung hilft nicht, wenn die Hauptverzögerung im Speicher entsteht.
Häufige Fehler beim Vergleich von DGX-Systemen
- Anzunehmen, dass ein geladenes Modell bereits akzeptabel läuft. Es kann in den Speicher passen, aber dennoch zu langsam reagieren oder parallele Anfragen nicht bewältigen.
- 128, 748 und 2.100 GB als dieselbe Art von Speicher zu behandeln. Spark verwendet LPDDR5X, Station kombiniert HBM3e mit CPU-seitigem LPDDR5X und die Angabe für DGX B300 bezieht sich auf den Speicher von acht GPUs.
- MIG mit Fehlertoleranz gleichzusetzen. MIG isoliert Nutzerressourcen, doch beim Ausfall des physischen Knotens stoppen alle Partitionen.
- Zwei Desktop-Systeme als direkten Ersatz für einen Multi-GPU-Server zu betrachten. Ein verteilter Workload hängt vom Netzwerk ab und verursacht zusätzliche Latenz.
- Ein System anhand der FP4-Spitzenwerte auszuwählen. Diese Werte zeigen nicht die Geschwindigkeit eines konkreten Modells bei der erforderlichen Präzision, Kontextlänge und Last.
- Anzunehmen, dass eine lokale Bereitstellung automatisch sicher ist. Ohne Updates, Zugriffskontrollen, Verschlüsselung und Protokollierung birgt auch ein lokales System Risiken.
- Einen Server zu kaufen, ohne die umgebende Infrastruktur zu kalkulieren. Ein Rack-DGX kann Aufrüstungen bei Stromversorgung, Kühlung, Netzwerk und Speicher erfordern.
Welche Lösung wählen
DGX Spark eignet sich für einen Spezialisten oder einen kleinen Forschungs-Workload, wenn lokaler Betrieb, schnelle Iterationen und die Möglichkeit wichtig sind, große Modelle ohne dauerhafte Abhängigkeit von der Cloud auszuführen.
DGX Station wird benötigt, wenn Modelle, Kontext oder Daten nicht mehr auf Spark passen und die Rechenressource von einem Experten oder einem kleinen Team genutzt wird. Sie bietet serverseitige Verwaltung und Ressourcenpartitionierung, bleibt jedoch ein einzelner Knoten.
Ein Rack-DGX oder ein Cluster aus GPU-Servern wird notwendig, wenn das Modell zu einem Dienst wird: Es gibt parallele Nutzer, SLAs, mehrere Teams, unabhängige Skalierung, zentralisierten Speicher und Monitoring, und ein Single Point of Failure ist nicht mehr akzeptabel.
Ein Rechenzentrum beginnt nicht mit der achten GPU oder einer bestimmten Parameterzahl. Es beginnt dort, wo es nicht mehr genügt, Rechenleistung lediglich bereitzustellen — diese Kapazität muss zuverlässig, sicher und vorhersehbar betrieben werden.
Inhaltsverzeichnis:
