Skip to main content
DGX Spark intègre 128 Go de mémoire unifiée partagée entre le processeur Grace et le GPU Blackwell. Cette capacité suffit pour héberger des modèles denses d’environ 70B Go en quantification à 4 bits, ainsi que des modèles MoE comptant jusqu’à 120B paramètres au total en format NVFP4. Toutefois, tous les modèles ne s’adaptent pas à chaque niveau de quantification, et certains environnements d’exécution ne respectent pas de la même manière cette organisation de la mémoire. Cette page décrit ce qui fonctionne, ce qui fonctionne avec des restrictions, et ce qui ne convient absolument pas.

​
Verdict rapide

Un seul DGX Spark peut exécuter des modèles denses d’une taille maximale d’environ 70B Go en quantification Q4, ainsi que des modèles MoE comptant jusqu’à 120B paramètres au total en format NVFP4. Les modèles MoE sont plus adaptés, car seule une partie de leurs paramètres s’active par jeton, ce qui permet d’obtenir un débit plus élevé avec la même quantité de mémoire.

​
Comment la mémoire de 128 Go est utilisée

Le DGX Spark ne dispose pas de VRAM dédiée. Le processeur Grace et le GPU Blackwell partagent un même pool de mémoire de 128 Go via un interconnect à 273 Go/s. Lorsqu’on charge un modèle, plusieurs éléments 3 utilisent ce pool de mémoire :
  1. Les poids du modèle — c’est le coût fixe le plus important, dépendant du nombre de paramètres et du niveau de quantification.
  2. Le cache KV — sa taille augmente en fonction de la longueur du contexte et du nombre de requêtes simultanées. Consultez la page Réglage de la mémoire sur DGX Spark pour les calculs de dimensionnement.
  3. Les surcharges système et CUDA — elles représentent généralement entre 4 et 8 Go pour le système d’exploitation DGX, le runtime CUDA et les graphes CUDA de vLLM.
Après déduction de ces besoins systémiques, il reste donc environ 115 à 120 Go disponibles pour les poids du modèle et le cache KV.
DeepSeek-V4-Flash-0731 ne tient pas sur un seul 1 Spark. Les 2 Sparks offrent suffisamment de mémoire cumulée pour fragmenter le 162–167 GB floor de poids publié, toutefois les preuves concernant le déploiement sur deux Sparks ont été validées par la communauté et requièrent une 0731 revalidation. Commencez par le contexte 32K–128K puis consultez DeepSeek V4 Flash et matériel local avant de configurer un cluster.

​
Compatibilité avec les modèles denses

Les modèles denses activent chacun de leurs paramètres pour chaque token. Par conséquent, la mémoire nécessaire aux poids et la charge de calcul augmentent de manière linéaire en fonction du nombre de paramètres — un modèle denses 70B exige environ deux fois plus de mémoire et deux fois plus d’opérations FLOPs qu’un modèle denses 35B. Sur DGX Spark, les modèles denses fonctionnent jusqu’à 70B avec une quantification de 4 bits, mais la concurrence se trouve limitée par la pression exercée sur le cache KV.
Le modèle Qwen3-32B présente d’importantes variations de performances (9 contre 44 tok/s) selon les benchmarks communautaires exécutés sur le même matériel. Ces différences proviennent des paramètres de flash attention et du moteur de quantification. Il convient de tester votre configuration spécifique avant de choisir un mode de déploiement.
Un modèle dense 70B utilisant NVFP4 nécessite environ 35 Go pour ses poids, mais chaque utilisateur simultané ajoute une charge supplémentaire liée au cache KV. Selon les retours de la communauté, la capacité d’accueil simultané est limitée à 5-10 utilisateurs avant que le système ne devienne instable. Pour des charges de travail multi-utilisateurs 70B, il est conseillé de recourir à deux unités DGX Spark.

​
Réserves concernant les modèles denses dans le cadre de la mémoire unifiée

  • ChatGPT-OSS-20B sur Ollama indique une utilisation de la GPU de 89%, mais présente une latence inacceptable. La communauté recommande de passer à vLLM ou SGLang pour ce modèle.
  • Qwen3.6-27B at NVFP4 is estimated to achieve 40–55 tok/s for a single user, based on similar dense models in the 27–32B range. The wide spread reflects differences in quantization backend and flash attention settings. With ~14–15 GB for weights, you have ample room for long context on a single Spark.
  • 70B dense models work but are the practical ceiling for dense architectures on a single Spark. The KV cache per concurrent request is the bottleneck, not weight memory.
  • Pour les modèles denses dépassant la capacité de 70B, il est indispensable de disposer d’un cluster composé de deux Spark. Consultez Une ou deux unités DGX Spark.

​
Compatibilité des modèles MoE

Les modèles MoE représentent l’équilibre idéal pour le DGX Spark. Tous les poids des experts se chargent en mémoire, mais seule une partie s’active par jeton ; ainsi on bénéficie des capacités d’un modèle volumineux avec le coût de calcul d’un modèle plus modeste.
Gemma-4-26B-A4B-it ne fonctionne pas sur DGX Spark car le paramètre gpu_memory_utilization de vLLM n’est pas respecté lors du profilage au démarrage sur la mémoire unifiée (SM121). Le système devient alors sans réponse. La solution temporaire consiste à utiliser explicitement la quantification NVFP4, mais les retours de la communauté montrent que cette correction demeure incomplète à la mi-2026. Suivez le problème #46307 sur vLLM pour obtenir les mises à jour.

​
Notes sur les performances des modèles MoE

  • Qwen3.5-35B-A3B fonctionnant sous NVFP4 atteint une vitesse de traitement de 47 à 50 jetons par seconde pour un seul utilisateur. Le délai entre la requête et la première réponse passe de 3 secondes (avec Ollama) à 0.12 secondes grâce à vLLM.
  • Qwen3.6-35B-A3B maintient une vitesse de traitement de 47 à 50 jetons par seconde avec vLLM standard pour un seul utilisateur. Grâce au moteur Atlas (en Rust/CUDA pur), il atteint jusqu’à ~120 jetons par seconde, soit 2.8x fois plus rapide que vLLM standard, et gère jusqu’à 1M jetons de contexte.
  • Qwen3.5-122B-A10B maintient une vitesse de traitement de ~30 jetons par seconde pour les tâches JSON-KIE, avec un taux d’acceptation MTP de 100% ; toutefois, il rencontre des difficultés sous une charge simultanée de 100K utilisateurs.
  • GLM-4.5-Air, doté de 106B modèles MoE et de 12B paramètres actifs, est considéré par la communauté comme le meilleur modèle pour DGX Spark. Il s’intègre parfaitement dans les contraintes mémoire du système.
GLM-4.6 (357B total / 32B active) does not fit on a single DGX Spark. At Q4-class quantization it needs ~178 GB — well over the 128 GB unified memory pool. For 128 GB hardware, use GLM-4.5-Air instead. See GLM family for the full variant comparison.

​
Comparaison des formats de quantification sur SM121

La puce graphique Blackwell intégrée à DGX Spark repose sur l’architecture SM121. Tous les formats de quantification ne sont pas supportés nativement.
NVFP4 est le paramètre par défaut recommandé pour DGX Spark. Il bénéficie d’un support natif sur le matériel SM121, permet de réduire la taille du fichier de 75% sans nuire à la qualité, et est compatible à la fois avec vLLM et le moteur Atlas. N’utilisez GGUF Q4_K_M que si vous exécutez llama.cpp ou Ollama.

​
Limites de longueur de contexte

La longueur de contexte influence directement la quantité de mémoire consommée par le cache KV, ce qui diminue les ressources disponibles pour les poids du modèle. Sur la mémoire unifiée de DGX Spark, chaque octet du cache KV provient du même pool de 128 Go qui stocke les poids, le runtime CUDA et le système d’exploitation. L’utilisation du cache KV FP8 (--kv-cache-dtype fp8) réduit ces valeurs de moitié tout en ayant un impact qualitatif inférieur à 2%, ce qui permet en pratique de doubler la quantité de contexte pouvant être traitée. Pour connaître les calculs précis concernant la taille du cache KV et les paramètres de réglage, consultez le guide de réglage de la mémoire DGX Spark.

​
Kimi K3 sur DGX Spark

Kimi K3 ne peut pas être déployé sur aucun cluster DGX Spark réalisable. Ses 2.8 billions de paramètres au total (soit environ 50B actifs par jeton grâce à Stable LatentMoE) exigent environ 1.4 téraoctets en précision MXFP4 native. Huit nœuds DGX Spark réunis offrent 1 téraoctets, mais restent en déficit de 376 gigaoctets. NVIDIA précise que les clusters Spark peuvent compter jusqu’à 4 nœuds (512 gigaoctets), tandis que Moonshot recommande un supernœud doté de 64 accélérateurs ou plus pour K3. Pour les calculs complets, lisez l’analyse approfondie du matériel pour Kimi K3. Actuellement, les modèles compatibles avec Spark figurent dans les tableaux ci-dessus : jusqu’à ~70B modèles denses en précision Q4 et ~120B modèles MoE en précision NVFP4 sur un seul nœud. Consultez la liste des modèles à privilégier plutôt que Kimi K3 pour choisir le meilleur modèle selon le nombre de nœuds disponibles.

​
Qwen3.8 feasibility

Le modèle phare de Qwen3.8 est sorti en août 2026 sous le nom de Qwen3.8-2.4T-A95B : il s’agit d’un modèle Mixture-of-Experts doté de 2.4 billions de paramètres au total et de 95B paramètres actifs par jeton, destiné uniquement au traitement de texte, distribué sous la licence spécifique de Qwen, l’qwen3.8-max. Cette génération inclut également Qwen3.8-27B (sorti les 2026-08-14, licence Apache-2.0), un modèle visuel et linguistique dense qui peut être exécuté sur un seul nœud Spark — voyez la conclusion après les calculs de besoin en mémoire.

​
Besoins en mémoire selon la quantification

Calculs de mémoire nécessaire pour les poids (hors cache KV, graphes CUDA et surcharge système) : Même avec la quantification la plus agressive, un seul DGX Spark ne peut pas exécuter Qwen3.8-2.4T-A95B. Il s’agit d’un modèle multi-nœuds qui exige au minimum 10 Sparks en mode Q4 — voire en réalité 20+ Sparks en précision FP8 pour disposer d’une marge suffisante pour le cache KV.

​
Dimensionnement du cluster multi-nœuds

Les modèles MoE chargent tous les poids des experts en mémoire, même si seule une partie s’active par jeton. Qwen3.8-2.4T-A95B active 95B de ses 2.4T experts, mais la limite de 1.2 téraoctets à Q4 demeure incontournable. L’avantage des modèles MoE réside dans le calcul (moins de FLOPs par jeton) et non dans l’utilisation de la mémoire.

​
État du support en temps d’exécution

Qwen met à disposition des procédures de déploiement pour vLLM, SGLang et TokenSpeed en parallèle des poids 2.4T. Le support pour llama.cpp, Ollama et LM Studio n’est pas encore documenté ; l’architecture hybride Gated DeltaNet + Gated Attention du modèle exige des optimisations spécifiques avant qu’un déploiement GGUF soit envisageable.

​
Le modèle Qwen3.8 pouvant s’exécuter sur un seul Spark

Qwen3.8-27B constitue la version destinée à une seule machine : il s’agit d’un modèle visuel et linguistique dense 27B publié le 2026-08-14 sous licence Apache-2.0. Chaque version officielle occupe exactement un Spark — soit 55.6 Go de mémoire BF16, tandis que la version officielle en 30.9 Go FP8 laisse environ 90 Go sur un total de 128 Go pour le cache KV. Vous pouvez l’exécuter via vLLM ou SGLang ; aucune version GGUF ou NVFP4 n’est pour l’instant disponible. Les détails complets sur les besoins en ressources figurent sur la page du modèle Qwen3.8 ; les configurations Spark testées seront ajoutées ici dès qu’elles auront été validées.

​
GLM-5.2 feasibility

​
Il ne faut pas dimensionner les modèles MoE en se basant sur le nombre de paramètres actifs

Le nombre de paramètres actifs influence le calcul par jeton, mais pas la limite minimale de mémoire requise. GLM-5.2 compte 753B paramètres (selon Hugging Face, on dénombre 753,329,940,480 paramètres répartis sur 78 couches, avec 8 experts sur 256 activés par jeton, auxquels s’ajoutent 1 paramètres partagés) ; la limite minimale réelle, en termes de bits par poids, s’élève donc à exactement 4 bits.
Ce chiffre équivaut à peu près à 3 fois les 128 Go d’une seule unité DGX Spark ; ainsi, 1 unités Spark ne suffisent pas, et même 2 unités dotées de 256 Go restent en deçà des besoins pour les poids seuls. Avec 3 unités Spark, on atteint théoriquement les 384 Go requis, mais il ne reste alors que 7 GB Go sur l’ensemble du cluster pour les métadonnées de format, le système d’exploitation, les tampons d’exécution et le cache KV — ce qui rend cette configuration irréalisable en pratique. Enfin, 4 unités Spark dotées de 512 Go constituent la première configuration offrant une marge de manœuvre réelle. Pour le format FP8, il faudrait 753 GB Go rien que pour les poids, ce qui correspond à 6 unités Spark sans compter les surcharges.
Il ne faut pas supposer que le modèle GLM-5.2 peut s’exécuter sur les Sparks 1 ou 2 en mode INT4 ou FP8, car la taille du checkpoint 753B publié l’interdit. Il ne faut pas non plus promettre un contexte de 1M sur un cluster Spark 4 en se basant uniquement sur le nombre de paramètres. Il convient d’abord de vérifier les fichiers téléchargeables, la compatibilité d’exécution et l’utilisation réelle du cache KV.

​
Modèles recommandés selon le cas d’usage

Avez-vous sélectionné un modèle ? Connectez-le alors

Attribuez à votre déploiement DGX Spark un point de terminaison authentifié à l’adresse https://api.tokios.com — aucun port entrant n’est requis, et cela prend environ 5 minutes.

​
Choisir entre la vitesse et la taille du modèle

Le compromis fondamental sur DGX Spark réside entre les capacités du modèle et le débit de traitement :
  • Si la vitesse est primordiale (agents de codage, chat interactif) : optez pour un modèle MoE de 35B en format NVFP4. Vous obtiendrez ainsi un débit de 47 à 50 jetons/seconde (ou 120 jetons/seconde avec Atlas), ce qui donne une impression d’instantanéité.
  • Si la qualité est primordiale (raisonnement complexe, recherche) : choisissez le modèle le plus volumineux pouvant être chargé — Qwen3.5-122B-A10B ou GLM-4.5-Air — en acceptant un débit de 25 à 30 jetons/seconde.
  • Si la concurrence est primordiale (multiples utilisateurs simultanés) : conservez le modèle MoE de 35B et utilisez le cache KV en format FP8 afin de maximiser le nombre d’utilisateurs simultanés. Consultez le réglage de la mémoire sur DGX Spark pour les détails mathématiques.

​
Vérifiez la compatibilité sur votre système Spark

Les benchmarks communautaires offrent des indications utiles, toutefois votre version spécifique du système d’exploitation DGX, le pilote CUDA et la version de vLLM pourraient présenter des comportements différents. Effectuez ces vérifications avant de retenir un modèle :
  1. Vérifiez la quantité de mémoire disponible avant le lancement :
  2. Démarrez le modèle en utilisant des paramètres prudents :
  3. Augmentez max-model-len de manière progressive jusqu’à atteindre la taille de contexte souhaitée ou jusqu’à rencontrer des contraintes de mémoire.
  4. Surveillez le système durant l’inférence :
  5. Débit de référence :
Si le système cesse de répondre à tout moment, redémarrez-le et diminuez la valeur de gpu_memory_utilization de 0.05.

​
Mettez votre modèle à disposition via Tokios.

Une fois votre modèle opérationnel sur votre DGX Spark avec vLLM, Ollama ou llama.cpp, il suffit de le rendre accessible via un point de terminaison authentifié sans ouvrir de ports entrants. Le connecteur Tokios se connecte depuis le Spark et vous offre une API compatible OpenAI et Anthropic à l’adresse https://api.tokios.com. Consultez Transformer votre DGX Spark en point de terminaison privé pour la procédure complète, ou rendez-vous directement sur enregistrer un modèle afin d’associer l’ID de modèle amont à un nom de déploiement.

Utilisation de vLLM sur le DGX Spark.

Procédure d’installation détaillée de vLLM incluant les paramètres NVFP4 adaptés à chaque taille de modèle.

Réglage de la mémoire sur le DGX Spark.

Dimensionnement du cache KV, compromis liés aux lots et paramètres de réglage pour une capacité de 128 Go.

Un ou deux DGX Sparks ?

Quand il convient d’ajouter un second Spark pour effectuer des inférences distribuées ou gérer des modèles nécessitant plus de 1 nœuds.

Notions de quantification.

Prenez connaissance du format NVFP4, d’AWQ, de FP8 et de GGUF avant de sélectionner un format.