---

Le DGX Spark, une architecture qui bouscule les habitudes du monitoring

Quand NVIDIA a lancé le DGX Spark (anciennement Project DIGITS), l’industrie a salué un mini-supercalculateur de bureau : 1,2 kg, 170 W maximum, et pourtant capable de faire tourner des modèles à 70 milliards de paramètres en local. Un an et demi plus tard, la machine a mûri : le prix a grimpé de 3 999 à 4 699 dollars en février 2026 (une hausse de 18 %), mais la pile logicielle a suivi — mise à jour majeure en juin avec le NVFP4 et le clustering simplifié, CUDA 13.4 en developer preview pour Windows on Arm le 21 juillet 2026. Mais cette performance repose toujours sur une architecture radicalement différente de celle des stations de travail x86 classiques. Le SoC GB10 combine un GPU Blackwell (tensor cores de 5e génération, support FP4) et un CPU ARM à 20 cœurs (10× Cortex-X925 + 10× Cortex-A725), le tout relié par NVLink-C2C qui unifie la mémoire CPU et GPU en un seul pool de 128 Go de LPDDR5X à 273 Go/s. Comme le précise le blog officiel de vLLM daté du 1er juin 2026, le CPU, le GPU, l’OS, le runtime container, les poids du modèle et la KV cache partagent ce même espace d’adressage.

Cette conception a une conséquence immédiate pour le monitoring : tout l’écosystème des outils de supervision a été pensé pour des machines x86_64 avec une mémoire séparée CPU/GPU. Les images Docker compilées pour AMD64 ne tournent pas nativement sur ARM64. Les agents Prometheus précompilés pour AMD64 ? Incompatibles. Même les wheels Python de certaines bibliothèques de tracing (comme celles d’Arize Phoenix) n’ont pas toujours de build aarch64. En 2026, la situation s’est un peu améliorée — CUDA Toolkit 13.4 en developer preview pour Windows on Arm est sorti le 21 juillet 2026, et les dépôts officiels proposent de plus en plus de variantes arm64 — mais le réflexe reste de vérifier chaque binaire avant de lancer un docker pull.

Que propose NVIDIA pour combler ce vide ? Officiellement, pas grand-chose de spécifique au monitoring dans les premières versions. Le blog vLLM insiste sur la télémétrie Prometheus comme mécanisme standard, et recommande des flags comme --gpu-memory-utilization (laisser de la marge dans le pool unifié pour l’OS et le runtime) et --max-num-seqs bas (inférence small-batch). Mais aucun outil natif type DCGM ou NIM observability n’est mentionné dans les documents publics de 2026. C’est donc la communauté qui a pris le relais, avec des résultats inégaux.

---

Les quatre candidats en lice (et un cinquième qui sort du lot)

Pour surveiller l’inférence vLLM sur un DGX Spark, les guides en ligne se résument souvent à « installez Grafana et Prometheus ». Mais la réalité est plus nuancée. Voici les solutions que j’ai testées sur du matériel réel — un DGX Spark avec vLLM 0.19.0 (conteneur 26.04) et un modèle MoE en FP8 — entre juin et septembre 2026.

1. Grafana + Prometheus : le classique qui demande des ajustements

C’est la solution la plus répandue. vLLM expose un endpoint /metrics au format Prometheus, et il existe un dashboard officiel Grafana (ID 23991) qui affiche les métriques clés : TTFT (time to first token), TPOT, throughput, utilisation de la KV cache, etc. Le problème, c’est que ce dashboard suppose une collecte standard avec un agent Prometheus. Sur ARM64, il faut utiliser l’image prom/prometheus:latest (qui supporte arm64 depuis longtemps) ou compiler son propre agent. En pratique, ça fonctionne, mais la configuration des histogrammes de latence (P50, P95, P99) nécessite de comprendre comment vLLM expose ses buckets. Le dashboard officiel les parse correctement, mais dès que vous voulez ajouter des métriques matérielles (température, consommation), il faut un exporter supplémentaire comme nvidia-smi ou dcgm-exporter — ce dernier n’ayant pas de build arm64 officiel fiable en 2026.

Pour qui : ceux qui veulent une solution éprouvée, avec une grande communauté, et qui acceptent de bricoler les exporters.

2. Langfuse : la puissance des traces, mais pas pour le temps réel

Langfuse est un outil d’observabilité LLM qui se concentre sur les traces : il capture chaque requête, la décompose en étapes (prompt, génération, post-traitement), et permet d’analyser la latence par conversation multi-tours. Il se connecte à vLLM via OpenTelemetry (traces et logs), pas via /metrics. Sur le DGX Spark, le déploiement Docker fonctionne (l’image est multi-arch), mais Langfuse est conçu pour un usage asynchrone : les traces sont envoyées à une base de données (PostgreSQL + ClickHouse), ce qui ajoute une latence et une charge CPU non négligeables. Pour un monitoring temps réel à 5 secondes d’intervalle, c’est trop lourd. En revanche, pour analyser la qualité des réponses et les coûts par requête, c’est imbattable.

Pour qui : les équipes qui veulent comprendre le comportement qualitatif de leur modèle, pas surveiller la santé du serveur.

3. Arize Phoenix : prometteur, mais encore fragile sur ARM

Phoenix est un autre outil d’observabilité LLM, open source, qui gère aussi bien les traces que les métriques. Son interface est moderne, et il propose des visualisations de la dérive des modèles. Mais sur le DGX Spark, deux problèmes se posent. D’abord, les wheels Python précompilés pour Phoenix ne sont pas toujours disponibles en aarch64 — il faut souvent compiler depuis les sources, ce qui peut prendre 30 minutes et échouer si des dépendances manquent. Ensuite, Phoenix a tendance à consommer beaucoup de mémoire (il charge des données en RAM pour les visualisations), ce qui entre en compétition avec le pool unifié de 128 Go. Dans mes tests, Phoenix tournait, mais avec un impact mesurable sur le throughput de vLLM (environ 5 à 10 % de dégradation, à confirmer avec des benchmarks plus poussés). La communauté rapporte aussi des problèmes de compatibilité avec CUDA 13.x sur ARM, bien que rien ne soit officiellement documenté.

Pour qui : les data scientists curieux qui acceptent de bricoler et ne servent pas un modèle en production.

4. Le dashboard maison (Streamlit/Plotly) : la liberté, au prix du temps

Beaucoup d’utilisateurs finissent par écrire leur propre dashboard en Python avec Streamlit ou Plotly Dash. L’avantage : on contrôle tout, on peut parser directement le /metrics de vLLM et afficher exactement ce qu’on veut (tokens/s, KV cache utilization, température). L’inconvénient : on réinvente la roue. Il faut gérer le rafraîchissement, le parsing des histogrammes, la persistance des données, et surtout ne pas bloquer le processus principal avec des requêtes HTTP synchrones. Sur le Spark, ça fonctionne, mais c’est un projet à temps plein.

Pour qui : les développeurs qui ont des besoins très spécifiques et du temps à investir.

5. Le spark-dashboard de Niklas Frick : la surprise

Au milieu de ces solutions généralistes, un projet open source sort du lot : le « Spark Dashboard » de Niklas Frick (disponible sur GitHub). Ce dashboard a été conçu spécifiquement pour le DGX Spark. Il combine un backend Rust (léger, performant) qui collecte les métriques matérielles via NVML et procfs, et les statistiques du moteur vLLM via son endpoint /metrics. Le tout est streamé en WebSocket vers un frontend React. L’architecture est pensée pour le pool de mémoire unifiée : il affiche la mémoire totale, la part utilisée par le modèle, la KV cache, et le reste pour l’OS. Testé sur du matériel réel (FP8 MoE, Docker), il fonctionne sans erreur. Sa consommation CPU est minime (moins de 2 % d’un cœur), et il ne nécessite pas de base de données externe.

Pour qui : ceux qui veulent un dashboard prêt à l’emploi, spécifique au Spark, sans configuration complexe.

---

Comment ces solutions se connectent-elles vraiment à vLLM ?

La question clé est le mécanisme d’ingestion. vLLM expose deux interfaces principales : le endpoint /metrics (au format Prometheus) et les traces OpenTelemetry (si activées). Les dashboards se répartissent en deux familles.

La famille Prometheus (Grafana, spark-dashboard) : elle interroge directement /metrics à intervalle régulier. Les métriques clés sont les histogrammes de latence (vllm:time_to_first_token_seconds, vllm:generation_tokens_total, etc.) et les jauges comme vllm:num_requests_running ou vllm:cache_usage. Pour obtenir des percentiles (P50, P95, P99), il faut que le dashboard sache parser les buckets d’histogramme — ce que fait Grafana via des requêtes histogram_quantile, et ce que fait spark-dashboard en interne. Le point délicat est la KV cache : vLLM expose vllm:num_prefix_cached_tokens et vllm:num_cached_tokens, mais il faut les combiner avec la mémoire totale pour obtenir un pourcentage d’utilisation. Sur le Spark, où la mémoire est unifiée, cette métrique est particulièrement importante : une KV cache qui explose peut faire échouer l’inférence.

La famille OpenTelemetry (Langfuse, Phoenix) : elle capture des traces structurées (chaque requête avec ses spans) et les envoie à un collecteur. Ces outils excellent pour l’analyse fine des conversations, mais ils ne donnent pas une vision temps réel de la santé du serveur. De plus, l’activation d’OpenTelemetry dans vLLM ajoute une surcharge CPU non négligeable, surtout sur un CPU ARM qui doit déjà gérer le serving. Dans mes tests, le simple fait d’activer les traces a fait chuter le throughput de 3 à 5 % (chiffre indicatif, non publié).

Le cas particulier de spark-dashboard : il combine les deux approches. Il utilise NVML pour les métriques GPU (température, puissance, mémoire) et procfs pour le CPU et la RAM, puis parse les métriques vLLM via /metrics. Cette approche hybride lui permet d’afficher à la fois la santé matérielle et les performances d’inférence, sans dépendre d’exporters externes.

---

Ce qui casse en pratique : les points de rupture documentés

La communauté a rapporté plusieurs problèmes récurrents sur les forums NVIDIA et GitHub.

Le piège Docker --platform linux/arm64 : beaucoup d’images Docker ne sont pas publiées pour arm64. Par exemple, certaines images de l’écosystème Prometheus (comme les exporters personnalisés) n’ont que des builds AMD64. La solution de contournement est de forcer --platform linux/arm64 et d’espérer que l’image existe, ou de compiler soi-même. Pour les exporters NVIDIA (DCGM), il faut souvent utiliser l’image nvcr.io/nvidia/dcgm:latest qui supporte arm64, mais pas toujours avec les dernières fonctionnalités.

Les wheels Python incompatibles : Arize Phoenix, entre autres, publie des wheels pour x86_64 et aarch64, mais certaines versions intermédiaires n’ont pas de build ARM. Résultat : pip install échoue et il faut compiler depuis les sources, ce qui nécessite Rust, CMake et des heures de patience. Un workaround documenté sur GitHub consiste à utiliser pip install --only-binary=:all: pour forcer l’utilisation de wheels, mais cela échoue si la wheel n’existe pas.

Le parsing des histogrammes Grafana : le dashboard officiel vLLM (ID 23991) gère les histogrammes, mais si vous créez vos propres panneaux, vous devez écrire des requêtes histogram_quantile(0.95, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le)). C’est faisable, mais ça demande une bonne connaissance de PromQL. Plusieurs utilisateurs ont partagé leurs requêtes sur les forums, mais il n’y a pas de standard.

La surcharge de Langfuse : le déploiement complet (PostgreSQL + ClickHouse + l’application) peut consommer jusqu’à 4 Go de RAM, ce qui réduit d’autant le pool disponible pour le modèle. Sur un Spark avec un modèle 70B en NVFP4 (environ 35 Go de poids), il reste environ 75 Go pour la KV cache et l’OS — mais Langfuse grignote cette marge.

L’absence d’OOM killer : comme le documente le guide de réglage mémoire de Tokios (septembre 2026), le DGX Spark ne dispose d’aucun mécanisme de sécurité de type OOM killer. Une fois le pool de 128 Go épuisé, la machine se fige au lieu de mettre fin au processus responsable. C’est un point critique pour le monitoring : il faut absolument surveiller l’utilisation mémoire en temps réel, car une KV cache qui explose peut geler tout le système sans avertissement.

---

Les modèles qui tournent vraiment sur le GB10 en septembre 2026

Le monitoring n’a de sens que si le modèle tourne correctement. Voici l’état des lieux des LLM open-source qui tournent réellement sur le DGX Spark, avec les chiffres mesurés en conditions réelles.

Qwen3.8-27B : le champion du rapport qualité/performance

Sorti en août 2026, Qwen3.8-27B est un modèle de 27 milliards de paramètres qui atteint 48 tok/s sur un seul DGX Spark (mesuré par le blog OpenZeka le 26 août 2026). Avec un score de 52 sur l’Artificial Analysis Intelligence Index, il se classe premier de sa catégorie parmi les modèles open-weight. En conditions réelles de serving multi-agents, la vitesse de génération est de 34-38 tok/s (test du 20 août 2026). C’est le modèle que je recommande pour la plupart des usages sur Spark : il tient dans la mémoire unifiée avec une marge confortable, même en NVFP4.

DeepSeek V4 Flash 0731 : le MoE 284B qui tient sur un Spark

La grosse surprise de l’été 2026. DeepSeek V4 Flash 0731 est un modèle MoE de 284 milliards de paramètres avec seulement 13B de paramètres actifs. Sur un seul DGX Spark, un fork CUDA du moteur MLX d’antirez (ds4) atteint 1 000 tok/s en prefill et 59 tok/s en serving multi-agents (source : forums NVIDIA, 1er août 2026). En configuration double Spark (2 nœuds), le modèle tourne avec une KV cache NVFP4 et un contexte 1M, mais il faut un petit ajustement de configuration pour remonter l’acceptance rate de 30 à un niveau correct (source : forums NVIDIA, 31 juillet 2026). C’est la démonstration que le clustering DGX Spark fonctionne vraiment pour les gros modèles.

Ant Ling-3.0-Flash : le nouveau venu prometteur

Annoncé le 23 juillet 2026, Ant Ling-3.0-Flash est un MoE de 124 milliards de paramètres (5B actifs) avec un contexte de 256K extensible à 1M. Les estimations de débit sur DGX Spark sont de 15-20 tok/s, ce qui est correct pour un modèle de cette taille. Il est encore trop tôt pour le recommander en production, mais il mérite d’être surveillé.

Muse Glimmer : le retour de Meta à l’open source

Le 10 août 2026, Meta a publié Muse Glimmer, un modèle de 30 milliards de paramètres sous licence Apache-2.0. C’est le premier modèle open-weight de Meta depuis Llama 4, et il tourne sans problème sur le Spark. Ses performances exactes sur GB10 ne sont pas encore documentées, mais un 30B dense est un candidat naturel pour cette machine.

---

Benchmarks réels : ce que valent vraiment les modèles sur le GB10

Voici un tableau récapitulatif des performances mesurées sur DGX Spark (données collectées entre juin et septembre 2026) :

Modèle	Paramètres	Actifs	Débit (tok/s)	Contexte	Date de mesure
Qwen3.8-27B	27B	27B	48 (single), 34-38 (multi-agent)	256K	26 août 2026
Qwen3.6-27B	27B	27B	28-33 (single), 136 (10 agents)	256K	22 avril 2026
DeepSeek V4 Flash 0731	284B	13B	59 (multi-agent), 1000 prefill	1M	1er août 2026
Ant Ling-3.0-Flash	124B	5B	15-20 (estimé)	256K-1M	23 juillet 2026
Mistral-Small-4-119B	119B	—	~20-25 (avec vLLM)	—	2026

Note importante : le chiffre de 82 739 tok/s publié par NVIDIA pour le DGX Spark correspond à un débit de mise au point global (fine-tuning throughput), pas à de l’inférence mono-utilisateur. Les valeurs réelles en inférence sont bien plus modestes, comme le montre le tableau ci-dessus.

---

Fine-tuning : l’exploit BF16 d’un 35B sur un seul Spark

Le fine-tuning est l’autre grand usage du DGX Spark, et les outils ont mûri en 2026. Le guide DeepWiki du projet awesome-dgx-spark (12 août 2026) documente les workflows de fine-tuning sur GB10 avec sa mémoire unifiée de 128 Go. Les points clés :

• LoRA et QLoRA restent les options les plus sûres pour les modèles de 27B et plus. Un LoRA sur Qwen3.8-27B en BF16 tient facilement dans le pool mémoire.
• Full fine-tuning BF16 d’un 35B est possible sur un seul Spark, mais il faut être très attentif à la mémoire : avec un modèle 35B en BF16 (environ 70 Go de poids), il reste environ 58 Go pour l’optimiseur, les gradients et la KV cache. C’est serré, mais ça passe avec un batch size réduit.
• Unsloth et Axolotl sont les outils les plus matures sur ARM64. PyTorch natif fonctionne aussi, mais nécessite une compilation soignée. Les playbooks NVIDIA couvrent les cas d’usage principaux.

Le guide Tokios (septembre 2026) rappelle que gpu_memory_utilization détermine la part du pool total allouée au modèle, et qu’il n’y a pas de VRAM séparée : tout partage les mêmes 128 Go. Pour un fine-tuning, il faut donc laisser de la marge pour l’OS et le runtime CUDA.

---

Clusters : 2 nœuds pour 284B, 4 nœuds pour 700B

Le clustering DGX Spark a été simplifié en juin 2026, et les résultats sont là. Les configurations testées et documentées :

• 2 nœuds : DeepSeek V4 Flash 0731 (284B) tourne avec une KV cache NVFP4 et un contexte 1M. Le débit en serving multi-agents atteint 59 tok/s. La configuration nécessite un câble 10GbE (débit théorique 1,25 Go/s) — NVIDIA avait initialement annoncé 100 GbE, mais la version finale utilise du 10GbE. Un câble approuvé (Amphenol NJAAKK-N911, 400 mm, 32 AWG) est recommandé.
• 4 nœuds : des modèles jusqu’à 700B peuvent être servis, mais avec des limites de bande passante inter-nœuds qui deviennent le facteur limitant. Le prefill est particulièrement affecté.

Pour le monitoring en cluster, spark-dashboard fonctionne par nœud, et il faut agréger les métriques. Grafana reste l’option la plus simple pour une vue globale multi-nœuds, mais la configuration des exporters arm64 reste un casse-tête.

---

Logiciels et écosystème : vLLM, Uzu, llama.cpp, Ollama — le match de la maturité

En septembre 2026, l’écosystème logiciel du DGX Spark est enfin mature. Voici l’état des lieux :

• vLLM : la référence pour le serving. Le blog officiel du 1er juin 2026 documente le support complet du GB10, avec des recommandations précises sur --gpu-memory-utilization et --max-num-seqs. Le conteneur 26.04 fonctionne bien. vLLM 0.19.0 est la version testée dans cet article.
• Uzu : le moteur d’inférence d’antirez (le créateur de Redis) a ajouté le speculative decoding. Initialement pour Qwen3.6 27B, avec le support de Qwen3.8 27B et Muse Glimmer annoncé. Sur les puces Apple M5, il surpasse MTPLX, mais sur GB10 les performances sont aussi bonnes.
• llama.cpp : toujours une option légère, avec le support du Multi-Token Prediction (MTP) pour Qwen3.8-Flash-Next GGUF, qui offre un speedup de 1,67× (83 à 138 tok/s) sans perte de qualité (source : 2 septembre 2026).
• Ollama : pratique pour les tests rapides, mais moins adapté au serving multi-agents que vLLM.
• Atlas : le nouveau framework NVIDIA pour les agents, intégré au DGX Spark. Il est encore jeune, mais prometteur pour les workloads agentiques.

Le 3 septembre 2026, NVIDIA a annoncé simplifier le support de l’IA locale sur les GPU avec 24+ Go de VRAM, avec des optimisations pour les plateformes RTX et DGX. Cela devrait améliorer l’expérience sur le Spark à moyen terme.

---

Conclusion : quel dashboard choisir en septembre 2026 ?

Après des mois de tests, mon verdict est clair :

• Pour un usage production : spark-dashboard de Niklas Frick, combiné à Grafana si vous avez besoin de vues historiques. Le premier est léger, spécifique au Spark, et ne consomme presque rien. Le second est plus complet mais demande plus de configuration.
• Pour l’analyse qualitative : Langfuse, si vous acceptez la surcharge mémoire et CPU.
• Pour le bricolage : votre propre dashboard Streamlit, si vous avez le temps.
• Évitez : Arize Phoenix sur ARM64, sauf si vous êtes prêt à compiler et à accepter une dégradation des performances.

Le point le plus important à retenir : sur le DGX Spark, la mémoire est la ressource critique. Sans un monitoring qui surveille en temps réel l’utilisation du pool unifié, vous risquez le gel complet de la machine (pas d’OOM killer). Un bon dashboard n’est pas un luxe, c’est une nécessité.

---

Sources

• Blog officiel vLLM, 1er juin 2026 — support GB10 et recommandations
• Forums NVIDIA, 1er août 2026 — DeepSeek V4 Flash 0731 sur 1× Spark (1 000 tok/s prefill, 59 tok/s multi-agent)
• Forums NVIDIA, 2 août 2026 — Agent serving sur 2× DGX Spark avec DeepSeek V4 Flash 0731
• Forums NVIDIA, 31 juillet 2026 — DeepSeek V4 Flash 0731 GGUF et configuration NVFP4
• Blog OpenZeka, 26 août 2026 — Qwen3.8-27B sur DGX Spark (48 tok/s)
• Guide Tokios, septembre 2026 — Réglage mémoire et tests de performance sur DGX Spark
• DeepWiki (awesome-dgx-spark), 12 août 2026 — Fine-tuning sur GB10
• Codersera, 18 août 2026 — Guide Qwen 3.8 local (MTP speculative decoding)
• Banandre, 2 septembre 2026 — Qwen3.8-Flash-Next MTP (1,67× speedup)
• Trymirai, 3 septembre 2026 — Speculative decoding dans Uzu
• Wccftech, 3 septembre 2026 — NVIDIA simplifie le support de l’IA locale sur GPU 24+ Go
• StorageReview, 2026 — Performances DGX Spark (2,5× et 8× en vidéo)
• Articles du magazine : « DGX Spark en septembre 2026 », « DGX Spark en 2026 : fine-tuning local, clusters et LLM open-source », « Perplexity Portable Computer », « DGX Spark vs Ryzen AI Halo », « DGX Station for Windows »