Un ou deux DGX Sparks — quand procéder à un échelonnement et comment le configurer

Un seul DGX Spark peut gérer les modèles qui tiennent dans son espace mémoire unifié de 128 GB. Deux Sparks reliés par un lien QSFP de 200 Go/s permettent d’exécuter certains modèles distribués ne pouvant tenir sur un seul nœud de 1. Toutefois, cette connexion réseau supplémentaire entraîne une surcharge de coordination ; il convient donc de mesurer le débit et la latence dans votre environnement réel plutôt que de supposer un gain de 2 fois.

Verdict rapide

Taille du modèle	1 Spark	2 Étincelles	Remarques
≤35B modèles MoE	Oui	Surdimensionné	Fonctionne sans problème à une vitesse de 47 à 120 jetons par seconde
70B dense	Oui, mais avec contraintes	Meilleur	Une seule instance Spark supporte de 5 à 10 utilisateurs simultanés
120B MoE	Oui	Meilleur	Compatible avec NVFP4, toutefois la mémoire est limitée
DeepSeek-V4-Flash-0731	Non	Testé par la communauté	Environ 162 à 167 Go de poids avant le cache KV ; il convient de revalider 0731
405B dense en précision flottante FP8	Non	Non	Environ 405 Go de poids avant toute surcharge d’exécution.
460B nombre de poids équivalents à la précision dense sur 4 bits	Non	Très serré	Environ 230 Go de poids bruts avant toute surcharge de formatage, d’exécution ou de cache KV.
700B en précision de 4 bits	Non	Non	Environ 350 Go de poids bruts avant toute surcharge

Quand un seul 1 Spark suffit

Un unique DGX Spark doté de 128 Go constitue le choix idéal dans les cas suivants :

Votre modèle se prête à une quantification raisonnable. Les modèles denses pouvant atteindre 70B Go en format NVFP4 (soit environ 35 Go) ou les modèles MoE jusqu’à 120B Go en NVFP4 (environ 60 Go) se chargent sur un seul nœud tout en laissant de la marge pour le cache KV.
Vous servez 1 à 5 utilisateurs simultanés. L’inférence sur un seul Spark gère les charges de travail d’équipes réduites avec des modèles MoE de 35B Go. Pour les modèles denses de 70B Go, prévoyez au maximum 5 à 10 utilisateurs.
La latence prime sur la taille brute du modèle. Un seul Spark élimine les surcharges liées à la communication inter-nœuds induites par le parallélisme tensoriel. Pour un modèle MoE de 35B Go, le déploiement sur un seul nœud assure une vitesse de traitement de 47 à 50 jetons/seconde, suffisante pour les agents de codage en temps réel et les chatbots.
Vous voulez une exploitation simple. 1 machine, 1 moteur d’exécution, 1 point de défaillance. Aucune configuration réseau, aucun lancement distribué, aucun débogage NCCL.

Consultez le tableau de compatibilité des modèles DGX Spark pour obtenir la liste complète des modèles adaptés.

Quand il vous faut plusieurs 2 Sparks

Ajoutez un second Spark si l’une des conditions suivantes s’applique :

Votre modèle quantifié dépasse 128 Go mais reste en dessous de 256 Go une fois les éléments de runtime et le cache KV pris en compte. DeepSeek-V4-Flash-0731 en est un exemple, avec un seuil de poids minimal officiellement défini à 162–167 GB Go.
Vous avez besoin d’une capacité de cache KV accrue ou d’une meilleure gestion de la concurrence pour un modèle déjà validé en déploiement distribué. Le parallélisme tensoriel permet de répartir la charge mémoire, mais n’assure pas nécessairement une augmentation proportionnelle du débit.
Vous êtes prêt à évaluer les performances du runtime en réseau. La surcharge de communication ainsi que l’architecture du modèle influencent le résultat final.

Un modèle dense 405B en précision FP8 nécessite environ 405 GB uniquement pour ses poids. Ce volume ne tient pas dans la mémoire combinée de 2 Sparks, soit 256 GB. Pour consulter les résultats d’essais concernant un itinéraire DeepSeek à 2 Spark et les recommandations d’utilisation, rendez-vous sur Tableau de bord matériel local Flash V4 DeepSeek.

Configuration du lien QSFP à 200 Gbps

Deux unités DGX Sparks se connectent directement via un 200 Gb/s câble QSFP, sans besoin de commutateur. NVIDIA propose un guide officiel intitulé « Connect Two Sparks Playbook » détaillant cette configuration.

Brancher le câble QSFP

Raccordez le câble QSFP à 200 Gb/s aux ports QSFP de chaque DGX Spark. Il s’agit d’une connexion directe point à point qui ne passe pas par votre commutateur réseau.

Vérifier le lien

Sur les deux Sparks, assurez-vous que le lien fonctionne à pleine vitesse :

ip link show

Recherchez l’interface QSFP affichant l’état UP. Vérifiez également la vitesse :

ethtool <qsfp-interface> | grep Speed

Vous devriez observer la valeur 200000Mb/s, soit 200 Gb/s.

Configurer les adresses IP

Attribuez des adresses IP statiques dans le sous-réseau du lien QSFP. Sur le Spark A :

sudo ip addr add 10.0.0.1/24 dev <qsfp-interface>

Sur le Spark B :

sudo ip addr add 10.0.0.2/24 dev <qsfp-interface>

Vérifier la connectivité :

ping 10.0.0.2   # from Spark A
ping 10.0.0.1   # from Spark B

Définir les variables d’environnement NCCL

La bibliothèque NCCL (NVIDIA Collective Communications Library) gère la communication entre GPU sur plusieurs nœuds. Il convient de définir ces variables sur les deux Sparks avant de lancer vLLM :

export NCCL_SOCKET_IFNAME=<qsfp-interface>
export NCCL_IB_DISABLE=0
export NCCL_NET_GDR_LEVEL=2

Ces paramètres indiquent à NCCL d’utiliser le lien QSFP pour la communication et d’activer GPU Direct RDMA afin de minimiser la latence.

Parallélisme tensoriel entre 2 Sparks

vLLM prend en charge le parallélisme tensoriel distribué : chaque Spark conserve une partie des poids du modèle et échange des données via le lien QSFP lors de l’inférence.

Lancer un modèle distribué

Sur le Spark A (nœud principal), démarrez vLLM en mode distribué :

vllm serve <your-distributed-model> \
  --tensor-parallel-size 2 \
  --quantization fp8 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192 \
  --distributed-executor-backend ray

vLLM utilise Ray pour coordonner les deux Sparks. Le Spark A charge la moitié des fragments du modèle, tandis que le Spark B en charge l’autre moitié ; ils se synchronisent ensuite via NCCL sur le lien QSFP.

Le parallélisme tensoriel constitue la stratégie idéale pour deux Sparks. Le parallélisme par pipeline (répartition séquentielle des couches) engendre des pertes de calcul dues aux « bulles de pipeline » sur de petits clusters. Le parallélisme tensoriel répartit quant à lui le calcul de chaque couche entre les deux GPU, optimisant ainsi l’utilisation des ressources dans les configurations à 2 nœuds.

Exemples de modèles adaptés à 2 Sparks

Modèle	Quantification	Seuil minimal des poids	Configuration	Points à vérifier
DeepSeek-V4-Flash-0731	Poids fusionnés/GGUF publiés	Environ 162 à 167 Go	Procédure testée par la communauté ; il convient de revalider 0731	Cache KV, appels d’outils et débit global
70B dense	NVFP4	~35 Go	`--tensor-parallel-size 2`	Comparez le débit et la concurrence avec 1 Spark
120B MoE	NVFP4	~60 Go	`--tensor-parallel-size 2`	Marge de mémoire pour le cache KV et surcharge réseau

Parallélisme de pipeline (quand l’utiliser)

Le parallélisme de pipeline attribue des couches différentes à chaque Spark. Cette configuration est plus simple à mettre en œuvre, mais moins efficace pour 2 nœuds, car le second Spark reste inactif tandis que le premier traite les premières couches de chaque jeton. N’utilisez le parallélisme de pipeline que dans les cas suivants :

L’architecture du modèle ne prend pas en charge le parallélisme tensoriel.
Vous reliez plus de 2 Sparks et souhaitez réduire la surcharge de communication à chaque étape.

vllm serve <model> \
  --pipeline-parallel-size 2 \
  --tensor-parallel-size 1

Exigences réseau entre les Sparks

Le connecteur QSFP a été conçu spécifiquement pour cette configuration, mais le trajet réseau influence grandement les performances :

Exigence	Spécification	Raison
Vitesse de liaison	200 Gb/s minimum	Le parallélisme tensoriel échange des tenseurs d’activation à chaque couche ; la bande passante constitue alors un goulot d’étranglement
Latence	Inférieure à une microseconde (via liaison QSFP directe)	Chaque jeton nécessite plusieurs opérations d’agrégation globale ; la latence s’accumule ainsi
Topologie	Connexion directe point à point	Il convient d’éviter les bascules entre plusieurs Sparks ; chaque transition entraîne une augmentation de la latence.
Protocole	RoCE ou liaison QSFP native	NCCL recourt à RDMA lorsque cela est possible afin d’assurer des transferts GPU à GPU sans copie.

Ne pas utiliser de commutateur Ethernet standard entre deux Sparks pour le parallélisme tensoriel. Un commutateur 10 gigabits Ethernet voire 100 gigabits Ethernet ajoute de la latence, ce qui crée un goulot d’étranglement lors de la phase de décodage. La configuration validée et recommandée est la liaison QSFP directe à 200 gigabits par seconde.

Analyse coût-bénéfice

Facteur	1 Spark	2 Sparks
Coût matériel	1x DGX Spark	2x DGX Spark et câble QSFP
Puissance	~240 watts	~480 watts
Complexité de la configuration	Faible (un seul hôte)	Moyenne (réseau + déploiement distribué de vLLM)
Taille maximale du modèle	Limitée par 128 gigaoctets de mémoire	Limitée par 256 gigaoctets de mémoire combinée, la surcharge d’exécution et l’interconnexion
Concurrence maximale (70B)	5-10 utilisateurs	10-20 utilisateurs
Débit de traitement	Mesurez les performances de votre environnement d’exécution	Comparez ces mesures à un niveau de référence obtenu avec un connecteur 1-Spark
Domaine de défaillance	Point unique de défaillance	2 points ; tous les deux sont nécessaires pour les modèles distribués

Moment où l’ajout d’un second connecteur Spark devient rentable

Il vous faut un modèle distribué accompagné d’un plan précis concernant le poids et le cache KV. Par exemple, le connecteur DeepSeek-V4-Flash-0731 requiert 2 nœuds et s’installe d’emblée en tant que configuration validée par la communauté.
Vous servez une équipe utilisant un modèle dont le déploiement distribué augmente suffisamment le débit ou la capacité de traitement pour justifier l’acquisition d’un second connecteur.
Vous exécutez des charges de travail sensibles à la latence sur des modèles 120B. La marge supplémentaire offerte par deux connecteurs Spark pour le cache KV permet d’utiliser des contextes plus longs ou de desservir davantage d’utilisateurs sans risque de saturation mémoire.

Cas où cela ne s’applique pas

Votre modèle ne dépasse pas la taille de 70B et votre équipe reste peu nombreuse. Un seul connecteur Spark assure déjà un débit de 47 à 50 jetons par seconde sur un modèle MoE 35B, soit une vitesse supérieure à celle de la frappe humaine. Un second connecteur ne ferait qu’accroître les coûts et la complexité sans apporter d’amélioration tangible pour les utilisateurs.
Vous pouvez exécuter des modèles MoE qui s’adaptent déjà à ce système. Le GLM-4.5-Air, le Qwen3.5-122B ainsi que le Nemotron-3-Super-120B s’intègrent tous sur un seul Spark sous NVFP4. Les répartir sur deux nœuds entraînerait un surcoût de communication qui pourrait annuler les avantages du parallélisme.

Configurez un cluster 2-Spark

Connectez et vérifiez le lien QSFP

Suivez les étapes décrites dans le guide de configuration du lien à 200 Gbit/s. Vérifiez que la vitesse du lien atteint 200 Gbit/s et effectuez un test de ping bidirectionnel sur les deux Sparks.

Installez vLLM sur les deux Sparks

Les deux nœuds doivent disposer d’installations vLLM identiques. Suivez le guide vLLM sur DGX Spark sur chaque unité.

pip install vllm

Installez Ray sur les deux Sparks

vLLM utilise Ray pour la coordination distribuée :

pip install ray

Démarrez le nœud principal Ray sur le Spark A :

ray start --head --port=6379

Associez le Spark B au cluster Ray :

ray start --address=10.0.0.1:6379

Vérifiez que les deux nœuds sont bien présents :

ray status

Définissez les variables d’environnement NCCL sur les deux Sparks

export NCCL_SOCKET_IFNAME=<qsfp-interface>
export NCCL_IB_DISABLE=0
export NCCL_NET_GDR_LEVEL=2

Lancez vLLM en mode distribué sur Spark A

vllm serve <your-model> \
  --tensor-parallel-size 2 \
  --quantization fp8 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192 \
  --distributed-executor-backend ray

vLLM répartit automatiquement les fragments du modèle entre les deux clusters Spark.

Vérifiez le bon fonctionnement du service distribué

Testez le point de terminaison depuis n’importe quel cluster Spark

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<your-model>",
    "messages": [{"role": "user", "content": "Hello from two Sparks"}],
    "max_tokens": 64
  }'

Mettez en service les deux clusters via Tokios

Il est possible d’agréger plusieurs clusters Spark derrière un seul point de terminaison Tokios. Installez le connecteur sur chaque cluster, enregistrez-les séparément en tant que déploiements, puis utilisez le routage de modèles pour orienter le trafic. Dans une configuration de parallélisme tensoriel impliquant 2 clusters Spark, où vLLM s’exécute sur Spark A et coordonne les opérations avec Spark B, il suffit d’installer le connecteur sur Spark A uniquement ; le point de terminaison /v1 fourni par vLLM représente déjà l’ensemble du cluster.

# On Spark A (the vLLM head node)
curl -fsSL https://tokios.com/downloads/install/linux | sh -s -- --code TKS-XXXX-XXXX

Enregistrez ce déploiement distribué dans le tableau de bord Tokios ; les clients accéderont alors aux deux clusters via https://api.tokios.com sans avoir besoin de connaître la topologie sous-jacente.

Utilisation de vLLM sur DGX Spark

Commandes d’installation et de lancement pour une instance vLLM à nœud unique.

Compatibilité des modèles

Déterminez quels modèles peuvent être utilisés sur les clusters Spark 1 et 2.

Réglage de la mémoire

Paramètres mathématiques et de réglage du cache KV pour chaque configuration.

Cas d’utilisation de DGX Spark

Configuration complète du connecteur Tokios pour DGX Spark.

Matériel et compatibilité

Servir et connecter votre runtime

Connecter un client ou une app

Comparer

Un ou deux DGX Sparks — quand procéder à un échelonnement et comment le configurer

Verdict rapide

Quand un seul 1 Spark suffit

Quand il vous faut plusieurs 2 Sparks

Configuration du lien QSFP à 200 Gbps

Parallélisme tensoriel entre 2 Sparks

Lancer un modèle distribué

Exemples de modèles adaptés à 2 Sparks

Parallélisme de pipeline (quand l’utiliser)

Exigences réseau entre les Sparks

Analyse coût-bénéfice

Moment où l’ajout d’un second connecteur Spark devient rentable

Cas où cela ne s’applique pas

Configurez un cluster 2-Spark

Mettez en service les deux clusters via Tokios

Utilisation de vLLM sur DGX Spark

Compatibilité des modèles

Réglage de la mémoire

Cas d’utilisation de DGX Spark

​Verdict rapide

​Quand un seul 1 Spark suffit

​Quand il vous faut plusieurs 2 Sparks

​Configuration du lien QSFP à 200 Gbps

​Parallélisme tensoriel entre 2 Sparks

​Lancer un modèle distribué

​Exemples de modèles adaptés à 2 Sparks

​Parallélisme de pipeline (quand l’utiliser)

​Exigences réseau entre les Sparks

​Analyse coût-bénéfice

​Moment où l’ajout d’un second connecteur Spark devient rentable

​Cas où cela ne s’applique pas

​Configurez un cluster 2-Spark

​Mettez en service les deux clusters via Tokios

Utilisation de vLLM sur DGX Spark

Compatibilité des modèles

Réglage de la mémoire

Cas d’utilisation de DGX Spark

Verdict rapide

Quand un seul 1 Spark suffit

Quand il vous faut plusieurs 2 Sparks

Configuration du lien QSFP à 200 Gbps

Parallélisme tensoriel entre 2 Sparks

Lancer un modèle distribué

Exemples de modèles adaptés à 2 Sparks

Parallélisme de pipeline (quand l’utiliser)

Exigences réseau entre les Sparks

Analyse coût-bénéfice

Moment où l’ajout d’un second connecteur Spark devient rentable

Cas où cela ne s’applique pas

Configurez un cluster 2-Spark

Mettez en service les deux clusters via Tokios