---

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 — et son histoire s’est singulièrement compliquée.

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.

Mais l’automne 2026 a rebattu les cartes côté catalogue. Le 2 octobre 2026, NVIDIA a discrètement ajouté une variante 64 Go du DGX Spark, commercialisée à partir du 23 octobre 2026 à 4 999 dollars — soit le même prix que la version 128 Go à son lancement en 2025, et même 1 000 dollars de plus que ce tarif initial selon plusieurs observateurs. Dans le même mouvement, la version 128 Go a vu son prix grimper au-delà des 6 000 dollars sur le marché, conséquence directe de la flambée des cours de la LPDDR5. Autrement dit : moins de mémoire, plus cher. Une décision qui a fait couler beaucoup d’encre et qui change radicalement la donne pour quiconque veut monitorer un modèle volumineux.

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). Sur la page officielle TRT-LLM for Inference, NVIDIA documente bien une pile TensorRT-LLM pour la Spark, mais l’observabilité temps réel reste le parent pauvre. 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 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é — un point d’autant plus critique depuis l’arrivée de la variante 64 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. Spark-Stack et le spark-dashboard de Niklas Frick : les surprises spécifiques au Spark

Au milieu de ces solutions généralistes, deux projets open source sortent du lot parce qu’ils ont été conçus pour le DGX Spark.

Le premier, Spark-Stack, est un dashboard de monitoring d’inférence LLM local taillé pour la machine. Le second, le « Spark Dashboard » de Niklas Frick (disponible sur GitHub), 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-Stack, 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. Et sur la variante 64 Go, la marge d’erreur est deux fois plus mince.

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) consomme plusieurs gigaoctets de RAM et une part notable du CPU ARM. Sur une Spark 128 Go, c’est absorbable ; sur une Spark 64 Go, cela peut suffire à faire basculer le système en swap et à dégrader l’inférence.

Un cas extrême documenté : un rapport GitHub du 26 septembre 2026 décrit une perte totale de réactivité de l’hôte (« whole-host loss ») lors d’une inférence MiniMax H3 FL2VA en 864×480 sur un DGX Spark GB10/aarch64 — après des exécutions réussies plus légères. Le monitoring ne l’a pas prédit, mais c’est précisément le genre d’incident où un dashboard matériel (température, puissance, mémoire) aurait pu alerter avant la chute. Un argument de plus pour ne pas se contenter des seules métriques vLLM.

---

Ce que le monitoring doit surveiller en priorité sur une Spark

Après des mois de tests, une hiérarchie des métriques se dégage, propre à l’architecture GB10.

1. L’utilisation de la mémoire unifiée. C’est LA métrique critique. Contrairement à une station x86 où la VRAM est un silo séparé, ici tout partage 128 Go (ou 64 Go). Un dashboard doit afficher en permanence : mémoire totale, poids du modèle, KV cache, et « reste pour l’OS + runtime ». Si le reste tombe sous ~8 Go, l’instabilité guette.

2. La KV cache. vLLM expose vllm:num_prefix_cached_tokens et vllm:num_cached_tokens. Sur un cluster de deux Spark en tensor parallel, la communauté a mesuré un pool de cache KV partagé de 1 105 096 tokens (août 2026) — un chiffre qui n’a de sens que si le dashboard sait agréger les deux nœuds.

3. Le TTFT et le TPOT. Le prefill est le point fort de la Spark : sur deux nœuds en vLLM FP8, on mesure environ 1 785 tokens/s de prefill (août 2026), contre 410 tokens/s en single-node avec llama.cpp (ds4.c, IQ2_XXS). Le dashboard doit distinguer clairement prefill et decode, sinon les chiffres sont illisibles.

4. La température et la puissance. À 170 W maximum, la Spark est économe, mais un MoE en FP8 soutenu peut la pousser dans ses retranchements. NVML fournit ces données ; tous les dashboards ne les exploitent pas.

5. Le débit agrégé en cluster. Sur deux Spark en TP=2 avec DeepSeek-V4-Flash FP8, on atteint environ 350 tokens/s agrégés à concurrence 32, et ~41 tokens/s en single-stream (août 2026). Un dashboard mono-nœud ne verra que la moitié de l’histoire.

---

Le contexte 2026 : pourquoi le monitoring est devenu stratégique

Le monitoring n’est plus un luxe d’ingénieur. Trois évolutions de l’automne 2026 l’ont rendu indispensable.

La segmentation 64 Go / 128 Go. Depuis le 23 octobre 2026, deux Spark coexistent : 64 Go à 4 999 $ et 128 Go à plus de 6 000 $. Sur la version 64 Go, la marge mémoire est si mince que le monitoring en temps réel devient une question de survie opérationnelle — un dashboard qui n’affiche pas la pression mémoire est inutile.

Le virage agentique. Microsoft a fait de Windows 11 26H2 (disponible depuis fin septembre 2026) la plateforme de l’« Intelligence Hybride », avec des agents IA locaux capables de tourner sur du matériel comme la Spark. Or, un agent qui enchaîne les appels d’outils génère des rafales de requêtes imprévisibles. Sans monitoring, impossible de savoir si la latence perçue vient du modèle, du KV cache saturé ou d’un goulot CPU.

Les benchmarks agentiques. Le 29 septembre 2026, Artificial Analysis a publié AA-AgentPerf-Local, un outil open source qui mesure la vitesse d’exécution des agents IA sur laptops et stations de travail, avec des résultats de lancement pour le DGX Spark, le Ryzen AI Halo, le MacBook Pro (M5 Pro) et la RTX 5090 sur quatre modèles open weight. C’est une avancée : enfin une méthodologie reproductible pour comparer. Mais un benchmark ponctuel ne remplace pas un dashboard permanent — il vous dit où vous en êtes, pas où vous allez.

---

Les modèles qui tournent, et ce que ça implique pour le monitoring

Le monitoring n’a de sens que rapporté aux modèles réellement servis. En octobre 2026, la short-list sur GB10 s’est stabilisée.

DeepSeek V4 Flash reste la référence MoE pour la Spark : ~14 tokens/s en single-stream avec le runtime ds4 (IQ2_XXS, août 2026), ~41 tokens/s en single-stream sur deux nœuds en vLLM FP8, et ~350 tokens/s agrégés à concurrence 32. C’est le modèle qui justifie le plus un dashboard cluster.

Qwen3.8-27B (sorti en août 2026) tourne à 34-38 tokens/s sur une Spark (20 août 2026). C’est le modèle « quotidien » de beaucoup de propriétaires, et celui pour lequel un dashboard mono-nœud suffit.

Xiaomi MiMo-V2.6 (Pro, Flash, 9B), publié sous licence MIT le 22-23 septembre 2026, est présenté comme l’un des modèles open source les plus économes à déployer — à condition d’avoir le matériel. Sur une Spark, il ouvre la voie à des configurations multi-agents où le monitoring du débit agrégé devient central.

Les modèles Meta : Llama 4 Scout et Maverick restent les seuls grands modèles open weight de Meta, mais leur position s’est effondrée — sur l’Intelligence Index v4.3.2 d’octobre 2026, Maverick score 9,99 et Scout 8,08, près du bas du classement open weights, loin derrière MiMo-V2.6-Pro (46,32) ou GLM 5.3 Flash (41,81). Meta a depuis pivoté vers Muse Spark (closed-weight) et Muse Glimmer (30B, Apache-2.0, 10 août 2026). Pour le monitoring, cela signifie que les charges de travail se déplacent vers des MoE efficaces — plus sensibles à la pression KV cache qu’un dense classique.

---

Clusters : le monitoring change d’échelle

Le clustering est devenu la vraie force cachée de la Spark. Deux nœuds en tensor parallel permettent d’atteindre 405 milliards de paramètres de taille de modèle maximale, et de partager un pool KV de plus d’un million de tokens. Mais monitorer un cluster Spark n’est pas monitorer deux Sparks indépendantes.

Les points d’attention spécifiques :

• Agrégation des métriques. Chaque nœud expose son propre /metrics. Le dashboard doit soit interroger les deux, soit passer par un Prometheus fédéré. Aucun outil « clé en main » ne le fait parfaitement aujourd’hui.
• Déséquilibre de charge. En TP=2, si un nœud rame (thermique, mémoire), le débit agrégé s’effondre sans que le nœud « sain » ne montre quoi que ce soit d’anormal. Seul un dashboard comparatif inter-nœuds révèle le problème.
• Le cas 2× Spark 64 Go. Deux nœuds 64 Go cumulent 128 Go, mais la bande passante d’interconnexion devient le facteur limitant pour les gros modèles. Le monitoring doit afficher le trafic NVLink-C2C, pas seulement les tokens/s.

---

Verdict : que choisir en octobre 2026 ?

Si vous débutez : Grafana + Prometheus avec le dashboard officiel vLLM (ID 23991), en acceptant de bricoler les exporters matériels.

Si vous voulez du prêt-à-l’emploi spécifique au Spark : Spark-Stack ou le spark-dashboard de Niklas Frick. Ce sont les seuls outils pensés pour le pool unifié, et ils affichent la répartition mémoire que les autres ignorent.

Si votre priorité est la qualité des réponses : Langfuse ou Phoenix, en acceptant la surcharge et les frictions ARM.

Si vous êtes en cluster : aucune solution ne fait tout. Il faut combiner un dashboard matériel par nœud et une agrégation Prometheus maison.

Et si vous êtes sur la nouvelle Spark 64 Go : le monitoring n’est plus optionnel. C’est votre unique moyen de savoir si le modèle tient — ou s’il est à deux requêtes de faire tomber la machine.

---

Sources

• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blog officiel NVIDIA, 2 octobre 2026
• NVIDIA lance un DGX Spark 64 Go : moins de mémoire, mais une drôle d’astuce pour dépasser le modèle 128 Go — Clubic, 2 octobre 2026
• Nvidia lance le DGX Spark en 64 Go : faut-il acheter deux petits plutôt qu’un gros ? — Frandroid, 2 octobre 2026
• Le DGX Spark Perd La Moitié De Sa Mémoire Mais Conserve Son Tarif De 4 999 Dollars — Pause Hardware, 2 octobre 2026
• DGX Spark 64 Go : NVIDIA annonce une configuration — NeoTeo, 3 octobre 2026
• AA-AgentPerf-Local: Benchmarking local AI agents on laptops and workstations — Artificial Analysis, 29 septembre 2026
• MiniMax H3 FL2VA on single DGX Spark GB10: whole-host loss during 864×480 T2V — rapport GitHub, 26 septembre 2026
• Xiaomi MiMo-V2.6 Open Source: Pro, Flash, 9B Models — eWeek, 23 septembre 2026
• Xiaomi introduces Mimo-V2.6 series open-source AI model family — SiliconANGLE, 22 septembre 2026
• Spark-Stack: A Local LLM Inference Monitoring Dashboard for NVIDIA DGX Spark — Zingnex, 2026
• TRT LLM for Inference | DGX Spark — NVIDIA Build, 2026
• Llama 4: Scout, Maverick, and Behemoth Explained — AI Made Tools, mis à jour juillet 2026
• Llama 4 Complete Guide 2026 — Codersera, rafraîchi le 5 octobre 2026
• Building Windows for hybrid intelligence — Microsoft, 7 octobre 2026
• Matériel pour l’IA locale en 2026 : DGX Spark, Mac Studio M5 Ultra, RTX 5090 et Strix Halo comparés — Context Studios, 24 septembre 2026