ARM64-Kompatibilität von Abhängigkeiten separat prüfen
Softwarepakete und Container-Images müssen ARM64 unterstützen. x86-Programme lassen sich nicht nativ ausführen. DGX Spark wird nicht mit Windows angeboten.
Erster Schritt nach der Bereitstellung
Erste Anmeldung: SSH oder RDP nach Abruf der Zugangsdaten im Dashboard
TcpNode DGX Spark wird per SSH mit NVIDIA DGX OS verbunden. Nach der Bereitstellung zuerst die Maschinendetails im Dashboard prüfen und dann mit der angegebenen IP und den Zugangsdaten verbinden.
Dieser Leitfaden beschreibt zuerst den Zugang zu DGX OS und die Prüfung der Umgebung. Hinweise zu SSH, RDP und mehreren IPs bei Dedicated Servern folgen weiter unten.
Von der Bestellung zur Entwicklungsumgebung
Die erste DGX-Anmeldung anhand der Bereitstellungsdaten durchführen
Zahlung und Bereitstellung sind getrennte Schritte. Nach Erhalt der Bereitstellungs-E-Mail mit dem zur Bestellung gehörenden Konto im Dashboard anmelden. Maßgeblich für die Verbindung sind die Angaben in den Maschinendetails.
-
Mietbestellung konfigurieren
Auf der TcpNode-Bestellseite für DGX die Mietdauer angeben und die Bestätigungen zu Architektur, Betriebssystem und Datenverarbeitung nach Mietende lesen und auswählen.
-
Zahlung abschließen
Im Checkout eine der tatsächlich aufgeführten Zahlungsmethoden auswählen und die Bestellung bezahlen.
-
Bereitstellungs-E-Mail prüfen
Die Benachrichtigung zur Bereitstellung im Konto-Postfach öffnen und die zugehörige Bestellung überprüfen.
-
Maschinendetails öffnen
Im TcpNode-Dashboard anmelden, die betreffende Maschine öffnen und IP sowie Zugangsdaten abrufen.
-
Erste Anmeldung per SSH
Die Verbindungsdaten aus den Maschinendetails im lokalen SSH-Client eingeben und eine Verbindung zu DGX OS herstellen.
Für Zugangsdaten sind die Maschinendetails der Bestellung maßgeblich
Die E-Mail bestätigt die Bereitstellung; die Verbindungsdaten sind im Dashboard hinterlegt. Bei mehreren Bestellungen zuerst Maschinenname und Bestelldaten abgleichen und anschließend die Adresse kopieren. Benutzername, Passwort oder Verbindungseinstellungen einer anderen Maschine nicht mit der aktuellen Adresse kombinieren.
- Zieladresse
- In den Maschinendetails angegebene IPv4-Adresse
- Anmeldekennung
- Für diese Maschine angegebener Benutzername und Authentifizierungsdaten
- Verbindungseinstellungen
- Maßgeblich sind die in den Bereitstellungsdaten angegebenen Einstellungen
SSH-Verbindung und CUDA-Prüfung
Bei der ersten Anmeldung bei DGX OS zuerst Architektur und Toolchain prüfen
NVIDIA DGX OS basiert auf Ubuntu 24.04, läuft auf ARM64 und enthält CUDA sowie den NVIDIA-AI-Software-Stack. DGX Spark bietet 1 Gbps ohne Datenlimit und 1 feste IPv4-Adresse; die Verbindung erfolgt per SSH.
SSH-Ziel mit den bereitgestellten Daten angeben
Im folgenden Befehl sind LOGIN_USER und SERVER_IP Variablennamen für den im Dashboard angegebenen Anmeldenamen und die IP-Adresse. Variablen vor der Ausführung im lokalen Terminal festlegen. Das Passwort nur bei der Authentifizierungsaufforderung des Clients eingeben, nicht in Befehle oder Support-Tickets schreiben.
Wenn die Bereitstellungsdaten separate Verbindungseinstellungen enthalten, diese auch im Client eintragen. Bei der ersten Verbindung die angezeigte Host-Identität erst bestätigen, nachdem Zieladresse und Bestellung abgeglichen wurden.
Lokaler SSH-Client
ssh "${LOGIN_USER}@${SERVER_IP}"Nicht ausführen, solange die Variablen nicht gesetzt sind. Das Beispiel enthält weder einen vorgegebenen Benutzernamen noch ein Passwort oder einen Verbindungsport.
Umgebung auf dem Server protokollieren, bevor Abhängigkeiten installiert werden
Nach erfolgreicher Verbindung Systemarchitektur, GPU und CUDA-Compiler nacheinander prüfen.uname -m prüft, ob die Umgebung ARM64 verwendet;nvidia-smi zeigt GPU- und Treiberinformationen an;nvcc --version zeigt die Version des CUDA-Compilers an.
Die CUDA-kompatible Version in den Treiberinformationen und die Compiler-Version sind unterschiedliche Angaben. Die Entwicklungsumgebung lässt sich nicht anhand nur eines dieser Werte beurteilen. Bei Python-Paketen und Container-Images außerdem prüfen, ob ARM64-Builds verfügbar sind und welche CUDA-Version das Projekt voraussetzt.
Nach der Anmeldung bei DGX OS ausführen
uname -m
nvidia-smi
nvcc --versionDie vollständige Ausgabe zur Fehlersuche aufbewahren. Bei fehlendem Befehl oder einer Fehlermeldung zunächst den Fehler dokumentieren, statt durch wiederholte Treiberinstallationen den ursprünglichen Zustand zu verändern.
Modelle und Experimente selbst bereitstellen
Es sind keine Modelle vorinstalliert. Modellgewichte, Projektabhängigkeiten und Experimentdaten müssen selbst heruntergeladen werden. Root-Rechte ermöglichen die Installation weiterer Entwicklungstools.
Vorgehen bei Verbindungsproblemen
Zugangs- und Umgebungsfehler getrennt untersuchen
Eine fehlgeschlagene SSH-Verbindung und ein Fehler beim Ausführen eines CUDA-Programms erfordern unterschiedliche Diagnoseinformationen. Im TcpNode-Support-Ticket den letzten erfolgreichen Schritt beschreiben, statt nur „funktioniert nicht“ anzugeben.
Verbindungs-Timeout oder Verbindung abgelehnt
Ziel-IP, Bereitstellungsdaten und lokales Netzwerk prüfen. Den vollständigen Fehler des Clients dokumentieren und angeben, ob die Authentifizierungsaufforderung bereits angezeigt wurde. Solange keine Verbindung besteht, zunächst keine Änderungen an der CUDA-Umgebung auf dem Server vornehmen.
VerbindungsaufbauAuthentifizierung fehlgeschlagen
Anmeldekennung und Authentifizierungsdaten in den Maschinendetails erneut prüfen und auf mitkopierte Leerzeichen achten. Im Support-Ticket die verwendete Authentifizierungsmethode nennen, aber weder Passwort noch privaten Schlüssel oder Bestätigungscode beifügen.
Anmeldedaten prüfenCUDA-Befehl schlägt nach der Anmeldung fehl
Ausgaben der Architektur- und GPU-Prüfung, Compiler-Version sowie des fehlgeschlagenen Befehls beifügen. Angeben, ob ein neuer Treiber installiert, die Toolchain gewechselt oder eine nicht ARM64-kompatible Abhängigkeit verwendet wurde.
Umgebung prüfenNotzugang und Systemaktionen über das Dashboard
Die browserbasierte grafische Sitzung im Dashboard dient nur als Notzugang, wenn SSH oder RDP nicht erreichbar ist, und ersetzt keine reguläre Fernverbindung. DGX Spark verfügt nicht über BMC/IPMI. Ein erzwungener Neustart oder eine Neuinstallation des Systems wird über ein Support-Ticket im TcpNode-Dashboard angefragt.
Im Support-Ticket Bestellnummer, Originalfehlermeldung, betroffenen Schritt, letzte Änderungen und bereits durchgeführte Prüfungen angeben. Zugangsdaten in Screenshots unkenntlich machen. Modellgewichte, Code und Protokolle selbst sichern und benötigte Daten vor Mietende übertragen; nach Ablauf der Mietzeit werden die Daten gelöscht.
Verbindung zu AMD Dedicated Servern
Bei Dedicated Servern SSH oder RDP passend zum installierten Betriebssystem verwenden
Nach der Bereitstellung eines TcpNode AMD Dedicated Servers IP-Adresse und Zugangsdaten ebenfalls in den Maschinendetails im Dashboard abrufen. Linux, FreeBSD und Proxmox VE verwenden SSH; Windows Server verwendet RDP. Die folgenden Einstellungen gelten nur für Dedicated Server.
Linux, FreeBSD und Proxmox VE
Im SSH-Client die Ziel-IP, den Benutzernamen und die Authentifizierungsdaten aus den Maschinendetails eintragen. Der oben gezeigte SSH-Befehl gilt ebenfalls; die Variablen müssen jedoch durch die Bereitstellungsdaten dieses Dedicated Servers ersetzt werden.
Nach der ersten Anmeldung prüfen, ob das installierte Betriebssystem mit der Bestellung übereinstimmt. Anschließend Netzwerk, Speicher und Software konfigurieren. Bei Proxmox VE die Verwaltung des Hostsystems nicht mit Konten und Adressen innerhalb virtueller Maschinen verwechseln.
SSH-Zugang
Windows Server per Remotedesktop
Den lokalen RDP-Client öffnen und die IP aus den Maschinendetails in das Feld für den Zielcomputer eintragen. Das Benutzerkonto gemäß Bereitstellungsdaten angeben und die Zugangsdaten bei der Authentifizierungsaufforderung eingeben.
Als Systemsprache ist die bei der Bestellung ausgewählte Sprache eingerichtet: Englisch, traditionelles Chinesisch oder vereinfachtes Chinesisch. Nach der Verbindung zuerst Betriebssystem und Sprache prüfen und anschließend die Geschäftsanwendungen konfigurieren. Die Anzeigesprache des lokalen Clients ändert nicht die Systemsprache des Servers.
RDP-Zugang
Bei mehreren IPv4-Adressen für die erste Verbindung die erste Adresse der Liste verwenden
Dedicated Server enthalten standardmäßig 1 dedizierte IPv4-Adresse. Auch bei zusätzlichen IPv4-Adressen in der Bestellung für SSH und RDP zunächst die erste Adresse der Zuweisungsliste verwenden. Weitere Adressen müssen im Betriebssystem selbst konfiguriert werden; sie sollten nicht ohne Prüfung als Ziel für die erste Anmeldung verwendet werden. Vor Änderungen eine funktionierende Verbindung beibehalten, um einen Verlust des Zugangs durch fehlerhafte Netzwerkeinstellungen zu vermeiden.
Datenträgerkonfiguration und Fernzugriff getrennt prüfen
Die 2×1TB NVMe-Laufwerke im Dedicated Server sind direkt angeschlossen und verfügen über kein Hardware-RAID. Zusätzlich gebuchte Laufwerke sind ebenfalls einzeln direkt angeschlossen. Eine erfolgreiche SSH- oder RDP-Anmeldung bedeutet nicht, dass Datenredundanz eingerichtet ist. Software-RAID, ZFS-Spiegelung und separate Backups müssen selbst geplant werden.
Probleme mit Dedicated Servern ebenfalls per Dashboard-Ticket melden
Bestellung, erste IPv4-Adresse, installiertes Betriebssystem, vollständige SSH- oder RDP-Fehlermeldung sowie letzte Änderungen an Firewall, Netzwerk oder Konto angeben. TcpNode ist für Hardware und Netzwerk zuständig; Betriebssystemkonfiguration, Software und Datensicherung liegen in eigener Verantwortung. Vor einem erzwungenen Neustart oder einer Neuinstallation den aktuellen Fehler und gegebenenfalls zu erhaltende Daten beschreiben.
Verbindungsdaten anhand der zugehörigen Bestellung prüfen
Zugangsdaten in den TcpNode-Maschinendetails abrufen. Wenn die Verbindung weiterhin nicht möglich ist, die Originalfehlermeldung und bereits geprüfte Schritte in einem Support-Ticket angeben.