TcpNode DGX Spark se connecte à NVIDIA DGX OS via SSH. Après la livraison, vérifiez les détails de la machine dans la console, puis utilisez l’adresse et les identifiants correspondants pour établir la connexion.
Cette page présente d’abord la connexion à DGX OS et la vérification de l’environnement. Les instructions SSH, RDP et multi-adresses pour les serveurs dédiés figurent plus bas.
Le paiement et la livraison sont deux étapes distinctes. Après réception de l’e-mail de livraison, connectez-vous à la console avec le compte associé à la commande. Les informations de connexion précises sont indiquées dans les détails de la machine.
Sur la page de commande TcpNode DGX, indiquez la durée de location, puis lisez et cochez les confirmations relatives à l’architecture, au système et au traitement des données à l’échéance.
Sur la page de paiement, choisissez l’un des moyens de paiement indiqués et procédez au règlement.
Consultez la notification de livraison dans la boîte de réception du compte et vérifiez la commande correspondante.
Connectez-vous à la console TcpNode, ouvrez la machine concernée et consultez son adresse IP et ses identifiants.
Renseignez les informations de connexion des détails de la machine dans un client SSH local pour accéder à DGX OS.
L’e-mail confirme la livraison, tandis que la console fournit les informations de connexion. Si plusieurs commandes sont en cours, vérifiez d’abord le nom de la machine et l’historique des commandes, puis copiez l’adresse. Ne mélangez pas le nom d’utilisateur, le mot de passe ou les paramètres d’une autre machine avec l’adresse utilisée.
NVIDIA DGX OS repose sur Ubuntu 24.04, fonctionne sur ARM64 et inclut CUDA ainsi que la pile logicielle NVIDIA AI. DGX Spark fournit une connexion 1 Gbit/s sans limite de trafic et 1 adresse IPv4 fixe. Le protocole de connexion est SSH.
Dans la commande ci-dessous, LOGIN_USER et SERVER_IP sont des variables qui correspondent respectivement au nom d’utilisateur et à l’adresse IP indiqués dans la console. Définissez ces variables dans le terminal local avant d’exécuter la commande. Saisissez le mot de passe uniquement lorsque le client le demande lors de l’authentification, jamais dans la commande ou le ticket d’assistance.
Si les informations de livraison indiquent des paramètres de connexion distincts, renseignez-les également dans le client. Lors de la première connexion, vérifiez que l’adresse cible correspond bien à la commande avant de répondre à l’invite d’identité de l’hôte.
Client SSH local
ssh "${LOGIN_USER}@${SERVER_IP}"Ne lancez pas la commande si les variables n’ont pas été définies. Cet exemple ne présuppose aucun nom d’utilisateur, mot de passe ni port de connexion.
Une fois connecté, vérifiez successivement l’architecture du système, le GPU et le compilateur CUDA. uname -m permet de vérifier l’environnement ARM64, nvidia-smi affiche les informations sur le GPU et le pilote, et nvcc --version indique la version du compilateur CUDA.
La version de CUDA compatible indiquée par le pilote et la version du compilateur sont deux informations distinctes. Une seule ne suffit pas à déterminer si l’environnement de développement convient. Avant de déployer des paquets Python ou des conteneurs, vérifiez également la disponibilité d’une version ARM64 et la version de CUDA requise par le projet.
À exécuter après la connexion à DGX OS
uname -m
nvidia-smi
nvcc --versionConservez la sortie d’origine pour faciliter le diagnostic. Si une commande est introuvable ou renvoie une erreur, notez-la sans tenter de la masquer en réinstallant plusieurs fois le pilote.
Les paquets et les images de conteneurs doivent prendre en charge ARM64. Les programmes x86 ne peuvent pas s’exécuter directement comme des programmes natifs. DGX Spark ne fournit pas de système Windows.
Aucun modèle n’est préinstallé. Les modèles, dépendances de projet et données d’expérimentation sont à télécharger par le locataire. Les droits root permettent d’installer les autres outils de développement.
Un échec de connexion SSH et un échec d’exécution d’un programme CUDA ne nécessitent pas les mêmes informations de diagnostic. Dans un ticket TcpNode, indiquez la dernière étape réussie plutôt que de vous limiter à « impossible à utiliser ».
Vérifiez l’adresse IP cible, les informations de livraison et le réseau local. Joignez le message d’erreur complet du client et indiquez si l’invite d’authentification est apparue. Tant que la connexion n’est pas établie, ne modifiez pas l’environnement CUDA distant.
ConnexionVérifiez à nouveau l’identifiant et les informations d’authentification dans les détails de la machine, et assurez-vous qu’aucun espace ne s’est glissé lors de la copie. Le ticket peut préciser la méthode d’authentification utilisée, mais ne joignez ni mot de passe, ni clé privée, ni code de vérification.
IdentifiantsJoignez les résultats des vérifications de l’architecture, du GPU et de la version du compilateur, ainsi que la sortie de la commande en échec. Indiquez si un nouveau pilote a été installé, si la chaîne d’outils a été modifiée ou si une dépendance sans prise en charge ARM64 a été utilisée.
EnvironnementLa session graphique dans le navigateur de la console sert uniquement d’accès de dépannage lorsque SSH ou RDP est indisponible. Elle ne remplace pas les connexions à distance habituelles. DGX Spark ne dispose pas de BMC / IPMI. Les redémarrages forcés et les réinstallations du système sont traités via un ticket dans la console TcpNode.
Dans le ticket, indiquez la commande concernée, le message d’erreur exact, l’étape à laquelle le problème est survenu, les dernières modifications et les vérifications déjà effectuées. Masquez les identifiants sur les captures d’écran. Sauvegardez les modèles, le code et les journaux, et transférez les données à conserver avant la fin de la location. Les données sont supprimées à son échéance.
Après la livraison d’un serveur dédié AMD TcpNode, l’adresse et les identifiants sont également disponibles dans les détails de la machine, dans la console. Linux, FreeBSD et Proxmox VE utilisent SSH ; Windows Server utilise RDP. Les instructions ci-dessous concernent uniquement les serveurs dédiés.
Dans le client SSH, renseignez l’adresse IP cible, le nom d’utilisateur et les informations d’authentification figurant dans les détails de la machine. La commande SSH présentée plus haut convient également, à condition de remplacer les variables par les informations de livraison de ce serveur dédié.
Après la première connexion, vérifiez que le système installé correspond à la commande, puis configurez le réseau, le stockage et les logiciels. Pour Proxmox VE, ne confondez pas les comptes et les adresses du système hôte avec ceux des machines virtuelles.
Ouvrez un client RDP local, saisissez l’adresse IP indiquée dans les détails de la machine dans le champ de l’ordinateur cible, puis renseignez le compte et les identifiants conformément aux informations de livraison.
La langue du système est celle choisie lors de la commande : anglais, chinois traditionnel ou chinois simplifié. Après la connexion, vérifiez le système et sa langue avant de configurer les logiciels métier. La langue d’affichage du client local ne modifie pas celle du système distant.
Chaque serveur dédié est fourni avec 1 adresse IPv4 dédiée. Si la commande comprend des adresses IPv4 supplémentaires, SSH et RDP utilisent toujours la première adresse de la liste attribuée. Les autres adresses doivent être configurées dans le système d’exploitation et ne doivent pas remplacer arbitrairement celle de la première connexion. Avant toute configuration, conservez une connexion fonctionnelle afin d’éviter de perdre l’accès après une modification réseau incorrecte.
Les disques 2×1TB NVMe des serveurs dédiés sont connectés directement, sans RAID matériel. Les disques supplémentaires en option sont également connectés séparément. Une connexion SSH ou RDP réussie ne garantit pas la redondance des données. La configuration d’un RAID logiciel, d’un miroir ZFS et de sauvegardes séparées incombe au locataire.
Indiquez la commande concernée, la première adresse IPv4, le système installé, le message d’erreur SSH ou RDP exact, ainsi que les dernières modifications apportées au pare-feu, au réseau ou aux comptes. TcpNode prend en charge le matériel et le réseau ; la configuration du système, les logiciels et les sauvegardes des données relèvent du locataire. Avant un redémarrage forcé ou une réinstallation, précisez le problème rencontré et les données à conserver.
Consultez les identifiants dans les détails de la machine TcpNode. Si la connexion échoue toujours, joignez le message d’erreur exact et les vérifications déjà effectuées dans un ticket.