Mit einem AI Cube starten und bei Bedarf erweitern? Der AI Cube ist als einzelner produktiver Einstieg ausgelegt. Für mehr Nutzer oder größere Modelle verbinden und konfigurieren wir einen zweiten AI Cube gezielt für den tatsächlichen Workload. AI Cube und Ausbaupfade ansehen
GB10-Systeme lassen sich über ConnectX-7 direkt miteinander verbinden. Daraus entstehen zwei unterschiedliche Architekturen: mehrere Modellendpunkte für mehr parallele Anfragen oder ein über mehrere Knoten verteiltes Modell. Wer beides als „Cluster“ bezeichnet, übersieht unterschiedliche Ziele und Engpässe.
Hardwarebasis
Jeder AI Cube auf GB10-Basis besitzt 128 GB Unified Memory, 10-GbE und zwei QSFP-Anschlüsse an der ConnectX-7-NIC. NVIDIA dokumentiert bis zu 200 Gbit/s je QSFP-Port und empfiehlt geeignete, geprüfte Kabel. Die Schnittstellen arbeiten als Ethernet; sie bilden keinen gemeinsamen Speicherbus zwischen den Systemen.
Bei zwei Geräten ist eine direkte Kabelverbindung möglich. Für DGX Spark unterstützt der NVIDIA Sync Cluster Assistant auch drei direkt verkabelte Systeme sowie bis zu vier Systeme mit Switch. Der AI Cube basiert auf dem ASUS Ascent GX10; ASUS gibt dafür höchstens zwei Geräte im Cluster an. Topologien mit drei oder vier Knoten beziehen sich deshalb auf DGX Spark und andere OEM-Systeme wie den Acer Veriton GN100; für AI Cubes kommen sie nur nach individueller Prüfung in Frage. Größere oder davon abweichende Topologien benötigen ein eigenes Netzwerkdesign. Verkabelung, Firmware, MTU, Adressierung und Netzwerktopologie müssen dokumentiert werden.
Variante A: mehr unabhängige Anfragen
Jeder AI Cube lädt ein eigenes Modell und beantwortet eigene Anfragen. Ein Load Balancer verteilt neue Sessions oder API-Aufrufe auf verfügbare Endpunkte.
Vorteile:
- hoher Gesamtdurchsatz bei vielen unabhängigen Chats;
- Modelle können je Knoten unterschiedlich sein;
- Wartung eines Modellendpunkts kann geplant erfolgen;
- Fehler bleiben eher auf einen Knoten begrenzt.
Zu klären bleibt, wo Open WebUI, Datenbank, Wissensspeicher und Sessionzustand laufen. Ein doppelter Inferenzserver allein ist noch keine hochverfügbare Plattform.
Variante B: ein Modell über mehrere Systeme
Wenn ein Modell einschließlich KV-Cache nicht sinnvoll auf einen Knoten passt, kann eine unterstützte Runtime Gewichte und Berechnungen verteilen. Die Knoten tauschen dabei Zwischenergebnisse über ConnectX-7 aus. Latenz und Durchsatz hängen dann stark von Modellarchitektur, Parallelisierungsverfahren, Runtime und Netzwerk ab.
Zwei Geräte ergeben nicht einen einzelnen Rechner mit 256 GB frei adressierbarem Speicher. Sie stellen je 128 GB bereit, die verteilte Software koordiniert. Deshalb muss das genaue Modellartefakt getestet werden.
Direkte Verbindung von zwei Knoten
Ein belastbarer Aufbau umfasst:
- identische oder kompatible Betriebssystem-, Treiber- und Firmwarestände;
- ein geprüftes QSFP-Kabel an den vorgesehenen ConnectX-7-Ports;
- eindeutige IP-Adressen auf den sichtbaren Netzwerkinterfaces;
- Konnektivitäts- und Durchsatztest vor dem Modellstart;
- Runtime-Konfiguration für Tensor-, Pipeline- oder Request-Parallelität;
- Messung mit repräsentativem Kontext und gleichzeitigen Anfragen;
- Monitoring für Knoten, Netzwerk, Modell und Warteschlange.
NVIDIAs Anleitung weist darauf hin, dass ein physischer Port aufgrund der internen Topologie als mehrere Linux-Interfaces erscheinen kann. Die Zuordnung sollte nicht aus Interface-Namen geraten, sondern anhand der dokumentierten Porttabelle geprüft werden.
Was NVIDIA Sync übernimmt - und was nicht
Der NVIDIA Sync Cluster Assistant erkennt die Geräte, erstellt die unterstützte ConnectX-7-Topologie, setzt die Netzwerkkonfiguration, prüft Links und richtet SSH zwischen den Knoten ein. Damit ist die Kommunikationsbasis hergestellt.
Nicht enthalten sind Modellverteilung, NCCL- oder vLLM-Konfiguration, Container-Orchestrierung, Load Balancing und Hochverfügbarkeit. Für Ende Oktober 2026 hat NVIDIA den NVIDIA Sync Model Launcher angekündigt, der ausgewählte Modelle auf einem einzelnen System oder einem Cluster herunterladen und starten soll. Bis er verfügbar und für den eigenen Workload geprüft ist, bleibt die Modellbereitstellung eine eigene Aufgabe; auch danach ersetzt er weder Load Balancing noch Hochverfügbarkeit. Diese Schicht muss weiterhin passend zum Modell und zum Betriebsziel aufgebaut und getestet werden. Ein erfolgreicher Netzwerktest ist deshalb noch kein erfolgreicher Inferenzcluster.
Entscheidungsmatrix
| Ziel | Sinnvoller erster Ansatz |
|---|---|
| mehr gleichzeitige Nutzer | unabhängige Modellendpunkte und Load Balancing |
| größeres einzelnes Modell | verteilte Inferenz mit exaktem Modelltest |
| mehrere Fachmodelle | Modelle auf Knoten trennen und gezielt routen |
| zugesicherte Verfügbarkeit | gesamte Plattform redundant planen |
| drei Knoten | bei DGX Spark von NVIDIA Sync direkt verkabelbar; für AI Cubes (ASUS GX10, max. zwei laut ASUS) nur nach individueller Prüfung |
| vier Knoten | bei DGX Spark und unterstützten OEM-Systemen mit Switch; für AI Cubes nur nach individueller Prüfung |
| mehr als vier Knoten | individuelles Netzwerk- und Orchestrierungsdesign erforderlich |
WZ-IT-Ausbaupfad
Beim AI Cube wird zunächst ein lokaler Workload sauber eingerichtet und gemessen. Wächst die Nutzung, ergänzen wir einen zweiten AI Cube für Durchsatz oder verteilte Modelle. Wenn Rackmount, redundante Netzteile, mehrere diskrete GPUs oder andere Verfügbarkeitsanforderungen benötigt werden, ist AI Cube Custom beziehungsweise ein GPU-Server der passendere Weg.
Vor dem Ausbau sollten sowohl das Nutzungs- und Lastprofil als auch das konkrete Modellartefakt für 128 GB feststehen. Sonst wird Hardware verbunden, bevor das eigentliche Kapazitätsproblem definiert ist.
