Quand NVIDIA a annoncé le DGX Spark fin 2025, j'ai pré-commandé sans hésiter. Sur le papier, la promesse était irrésistible : un Grace Blackwell GB10 sous mon bureau, 128 Go de mémoire unifiée (UMA) entre CPU et GPU, 1 Po/s de bande passante interne, et le tout dans un chassis de 17 cm de côté qui consomme moins qu'un PC gaming. Le prix de lancement (4 200 $ HT en config 128 Go) le plaçait à un cinquième d'une H100 PCIe 80 Go, et NVIDIA promettait un « deployment Day 1 » avec NIM containers prêts à l'emploi.
90 jours plus tard, le DGX Spark fait tourner notre Qwen3.6-35B-A3B quantizé en PrismaQuant 4.75bit comme always-on dans notre stack LiteLLM. Il sert le tier « long-reviewer » de notre fleet d'agents autonomes (chat-deep, code review, analyse de specs). Il tient les SLA. Mais le chemin pour y arriver a été beaucoup plus accidenté que ce que la documentation laisse penser.
Cet article documente les trois leçons les plus coûteuses, avec les snippets de logs exacts qui nous ont fait perdre des heures à debugger à 23 h le dimanche. Si vous évaluez un GB10 ou un Spark Mini, lisez jusqu'à la fin. Si vous en avez déjà un et que vos workloads tombent mystérieusement, l'une des trois sections explique probablement pourquoi.
La promesse marketing vs la réalité
NVIDIA vend le DGX Spark autour de quatre arguments. Chacun est vrai, mais chacun cache un coût opérationnel que vous découvrez en production, pas dans le datasheet.
Argument 1 : « 128 Go unifiés CPU+GPU »
Vrai : sur un H100 PCIe vous êtes limité à 80 Go de VRAM, et au-delà vous payez le coût atroce du CPU↔GPU PCIe (32 Go/s théorique, 12-15 Go/s pratique). Sur GB10 c'est NVLink C2C à 900 Go/s en bidirectionnel. Vous pouvez réellement charger un modèle de 90 Go et faire de l'inférence sans toucher au PCIe.
Le piège : il n'y a plus de frontière logicielle entre la RAM CPU et la VRAM. nvidia-smi vous montre 95 Go de free, mais c'est la même mémoire physique que la RAM système. Un workload Python qui charge un dataset Parquet de 40 Go consomme 40 Go de la même piscine. Toute votre intuition sur « ça tient dans la VRAM » est à reconstruire. Voir leçon 1.
Argument 2 : « Compatibilité CUDA Day 1 »
Vrai : CUDA 12.5 reconnaît la SM_100 (Blackwell), et les binaires CUDA standards tournent. Vous pouvez compiler du code CUDA classique sans rien changer.
Le piège : les wheels PyTorch standards de pip ne contiennent PAS les kernels SM_100 compilés. PyTorch 2.5.1+cu125 du channel pip officiel détecte la SM_100, ne trouve pas de kernel optimisé, et tombe en mode « eager via PTX JIT ». Vous perdez 60 % de perf. Il faut soit le wheel NVIDIA NGCpytorch:25.04-py3, soit recompiler torch avec TORCH_CUDA_ARCH_LIST="10.0+PTX".
Argument 3 : « NIM containers prêts à l'emploi »
Vrai : les NIM (NVIDIA Inference Microservices) Llama 3.1 et Mistral tournent. docker run nvcr.io/nim/... et vous avez un endpoint OpenAI-compatible en 5 minutes.
Le piège : les NIM sont des images de 18-25 Go avec une licence « NVIDIA AI Enterprise » qui exige un contrat support au-delà de 90 jours d'évaluation. Et ils sont verrouillés sur les modèles que NVIDIA package — pas de Qwen, pas de DeepSeek, pas de Mistral « custom fine-tune ». Pour quoi que ce soit hors catalogue, il faut revenir à vLLM, llama.cpp ou TensorRT-LLM en self-build, et là les hostilités commencent (voir leçons 2 et 3).
Argument 4 : « Consommation modeste »
Vrai et bien placé : mesuré au wattmètre sur 3 mois, 240 W idle, 380-420 W en génération soutenue, pic à 510 W. Une H100 PCIe consomme 600 W mesurés. Sur 16 h/jour à 0,21 €/kWh, on est à 60 €/mois d'électricité. Aucun reproche ici.
Notre setup en production
Pour situer les leçons qui suivent, voici exactement comment le DGX Spark est utilisé :
- Modèle always-on : Qwen3.6-35B-A3B (35B paramètres, 3,5B actifs MoE), quantizé PrismaQuant 4.75bit (compressed-tensors W4A16 + Marlin kernels), occupe 22,9 GB en RAM unifiée
- Modèle on-demand (via llama-swap) : Llama 3.3 70B Q4, Mistral Small 24B Q5, DeepSeek-Coder 33B Q4 — chargés à la requête, évincés par TTL après 600 s d'inactivité
- Stack inférence : vLLM 0.20.x compilé custom (TORCH_CUDA_ARCH_LIST="10.0+PTX"), llama.cpp HEAD pour les modèles GGUF, llama-swap 1.x devant, le tout exposé via LiteLLM frontale sur port 4000
- Réseau : Tailscale userspace (le Spark a une carte 10 GbE Mellanox, mais pour notre mesh distribué on passe par Tailscale)
- OS : Ubuntu 24.04 LTS Server, kernel 6.8 NVIDIA custom, driver 570.x
- Charge : 200-400 requêtes/heure en moyenne, pic à 1 100/heure pendant les sessions de revue de PR par notre fleet d'agents
Le Spark sert le tier « long-reviewer » (modèles > 20B avec raisonnement profond, contexte 32K) tandis que les tiers « tool-caller » et « chat-fast » sont déchargés sur un Octominer avec une RTX 4060 Ti 16 Go. Cette répartition est documentée dans notre billet sur le setup LLM auto-hébergé à 5 noeuds.
Leçon 1 : le cap mémoire cgroup est INEFFICACE sur UMA
C'est de loin la leçon la plus chère de ces 3 mois. Symptôme : à 23 h un dimanche, le Spark devient inaccessible. SSH timeout, ping perdu. Reset matériel (le bouton physique sur le chassis), reboot, tout revient. Logs dmesg :
[2026-04-12 23:14:08] systemd-oomd[842]: Killed /system.slice/llama-swap.service due to memory pressure (memory_used 96.4G > memory_high 80G) [2026-04-12 23:14:08] kernel: Out of memory: Killed process 4382 (llama-server) total-vm:24937104kB, anon-rss:2740kB, file-rss:8192kB, shmem-rss:0kB, UID:1000, pgtables:48472kB [2026-04-12 23:14:08] kernel: Out of memory: Killed process 5117 (vllm) total-vm:23456128kB, anon-rss:2664kB, file-rss:12288kB, shmem-rss:0kB, UID:1000, pgtables:42960kB [2026-04-12 23:14:09] kernel: oom_reaper: reaped process 4382 (llama-server), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [2026-04-12 23:14:09] kernel: ggml_cuda_compute_forward: cudaMalloc failed: out of memory [2026-04-12 23:14:11] kernel: NVRM: Xid (PCI:0000:01:00): 31, pid=5118, name=vllm, Ch 00000010, intr 10000000. [2026-04-12 23:14:13] kernel: nvidia-uvm: VMM allocation failed
Le truc qui m'a fait perdre 4 heures : anon-rss:2740kB. Le processus llama-server avait 2,7 MB de RSS. C'est microscopique. Pourquoi l'OOM-killer le tue-t-il en priorité ?
La réponse est dans la doc kernel Linux mais elle n'est jamais mentionnée dans le contexte UMA : l'OOM-killer score les processus sur RSS + swapents, pas sur les mappings virtuels (total-vm). Sur un GPU traditionnel avec PCIe, la VRAM est invisible côté kernel (/proc/<pid>/status ne la voit pas) : le scoring fonctionne. Sur GB10 avec UMA, vLLM et llama.cpp mappent la VRAM via le driver NVIDIA en mémoire UVM (Unified Virtual Memory). Cette mémoire est dans le RSS du processus côtécudaMalloc mais elle n'est PAS comptée comme RSS Linux tant que les pages n'ont pas été touchées (read ou write).
Au moment où systemd-oomd décide de tuer parce que memory_used 96.4G > memory_high 80G, il regarde quels processus tuer. Il classe par RSS : le processus llama-server est à 2,7 MB de RSS « visible » kernel. Mais en réalité il consomme 22 GB de mémoire physique réservée par UVM côté GPU. Le scoring est fondamentalement faux.
Conséquence : systemd-oomd tue n'importe quel processus userspace au RSS > 100 MB (votre script de monitoring, votre prometheus exporter, votre client SSH) mais laisse les processus GPU intacts. Ce qui est l'inverse de ce que vous voulez.
Notre fix
Trois mesures combinées, toutes nécessaires :
- Désactiver systemd-oomd globalement :
systemctl mask systemd-oomd. Sur un serveur LLM single-tenant ce daemon fait plus de mal que de bien. - Cap mémoire applicatif via
--gpu-memory-utilization 0.85sur vLLM, et--mlock --tensor-splitexplicite sur llama.cpp. Vous reprenez le contrôle au niveau du framework, pas du kernel. - Monitoring custom : un cron qui lit
nvidia-smi --query-gpu=memory.used --format=csvtoutes les 30 s. Si > 110 GB pendant > 60 s, alertes Tailscale + kill ciblé du dernier processus chargé. Pas élégant, mais fiable.
memory.high=100G sur le service llama-swap.service. Ça n'a RIEN changé. Le cgroup compte le RSS kernel, pas la mémoire UVM. Le service consomme 110 GB physiques mais la cgroup voit 80 MB et ne déclenche jamais l'eviction. Ne perdez pas votre temps avec cette piste sur UMA.Leçon 2 : flashinfer JIT — 21 minutes au premier boot
vLLM 0.20+ utilise par défaut flashinfer comme backend d'attention sur Blackwell (vs flash-attn-2 sur Hopper). flashinfer fait du JIT autotuning : au premier appel, il compile et benchmark plusieurs variantes de chaque kernel d'attention (split-K, persistent kernels, prefill vs decode) pour retenir la meilleure pour votre couple (modèle, batch size, context length, GPU).
Premier démarrage de vLLM avec Qwen3.6-35B-A3B sur le Spark, log :
(VllmWorker rank=0) INFO 04-15 09:14:22 [model_runner.py:1432] Loading model weights took 22.857 GiB (VllmWorker rank=0) INFO 04-15 09:14:25 [worker.py:262] Memory profiling takes 2.91 seconds (VllmWorker rank=0) INFO 04-15 09:14:25 [worker.py:262] the current vLLM instance can use total_gpu_memory (97.39GiB) x gpu_memory_utilization (0.85) = 82.78GiB (VllmWorker rank=0) INFO 04-15 09:14:31 [flashinfer_jit.py:88] Compiling FlashInfer JIT for SM_100, dtype=bf16 (VllmWorker rank=0) INFO 04-15 09:14:31 [flashinfer_jit.py:91] This may take 15-25 minutes on first run. Cached afterwards. (VllmWorker rank=0) INFO 04-15 09:18:42 [flashinfer_jit.py:104] [1/47] decode_prefill_paged_kernel_split_kv compiled in 251.4s (VllmWorker rank=0) INFO 04-15 09:21:18 [flashinfer_jit.py:104] [2/47] decode_persistent_kernel_bf16 compiled in 156.0s (VllmWorker rank=0) INFO 04-15 09:23:55 [flashinfer_jit.py:104] [3/47] prefill_paged_kernel_kv_combined compiled in 157.2s ... (44 more kernels) ... (VllmWorker rank=0) INFO 04-15 09:35:14 [flashinfer_jit.py:118] All 47 kernels compiled in 1242.7s. Cached at /home/talki/.cache/flashinfer/sm100_bf16_qwen35b_a3b/ (VllmWorker rank=0) INFO 04-15 09:35:18 [llm_engine.py:432] vLLM API server ready on http://0.0.0.0:8001
20 minutes 56 secondes entre « vLLM démarre » et « vLLM prêt à servir ». Pendant ce temps, le port 8001 ne répond pas. Si votre healthcheck Kubernetes / systemd a un timeout de 5 minutes (le défaut), il considère le service comme failed et tente un redémarrage. Le redémarrage repart à zéro parce que le cache n'est écrit qu'à la fin du JIT. Boucle infernale.
Le payoff : deuxième démarrage du MÊME modèle avec la MÊME version vLLM/CUDA :
(VllmWorker rank=0) INFO 04-15 14:02:11 [flashinfer_jit.py:74] Found cached FlashInfer kernels at /home/talki/.cache/flashinfer/sm100_bf16_qwen35b_a3b/ (VllmWorker rank=0) INFO 04-15 14:02:13 [flashinfer_jit.py:128] All 47 kernels loaded from cache in 1.8s (VllmWorker rank=0) INFO 04-15 14:03:42 [llm_engine.py:432] vLLM API server ready on http://0.0.0.0:8001
91 secondes. Et les performances en génération sont ~2,4× meilleures qu'en eager mode (29 tok/s vs 11 tok/s sur 8K context). Le JIT n'est pas un bug, c'est une optimisation majeure — mais elle a un coût qu'il faut anticiper.
Notre fix
- Healthcheck systemd à 1800 s :
TimeoutStartSec=1800dans le service vLLM. Sinon vous bouclez. - Backup du cache flashinfer :
~/.cache/flashinfer/est sauvegardé quotidiennement vers un disque USB. Si on doit réinstaller l'OS ou changer de SSD, on restaure. Sinon c'est 20 min à chaque changement de version. - Lockdown CUDA + PyTorch : on a pin
torch==2.5.1+cu125etvllm==0.20.0. Toute mise à jour mineure de torch invalide le cache flashinfer. C'est un trade-off entre rester à jour et ne pas reperdre 20 min à chaquepip install -U. - Pre-warming au boot : systemd unit qui démarre vLLM avec un modèle dummy pour précharger le JIT, puis switch vers le vrai modèle. Évite que la première requête utilisateur tombe pendant les 21 minutes de JIT.
Leçon 3 : llama-swap TTL eviction et l'assertion vLLM
Notre architecture utilise llama-swap comme proxy devant vLLM et llama.cpp. llama-swap charge un modèle à la demande, et l'évince après un TTL d'inactivité (par défaut 600 s). Pendant que le modèle A est évincé, on peut charger le modèle B sur la même VRAM.
Sur un GPU traditionnel, ce schéma fonctionne parfaitement. Sur le GB10 avec UMA, on a découvert un edge case que vLLM ne gère pas. Logs vLLM, tentative de chargement de Llama 3.3 70B Q4 alors que Qwen3.6-35B vient d'être évincé :
(VllmWorker rank=0) INFO 05-01 03:42:18 [worker.py:241] init_device complete (VllmWorker rank=0) INFO 05-01 03:42:18 [worker.py:248] Initial free memory 85.21 GiB (VllmWorker rank=0) INFO 05-01 03:42:21 [model_runner.py:1432] Loading model weights took 41.812 GiB (VllmWorker rank=0) INFO 05-01 03:42:24 [worker.py:259] Memory profiling takes 2.83 seconds (VllmWorker rank=0) ERROR 05-01 03:42:24 [worker.py:264] AssertionError: Initial free memory 85.21 GiB, current free memory 86.63 GiB. The free memory should DECREASE during memory profiling, not increase. This indicates another process freed GPU memory mid-profiling. (VllmWorker rank=0) ERROR 05-01 03:42:24 [worker.py:265] File "/opt/vllm/worker.py", line 264, in determine_num_available_blocks (VllmWorker rank=0) ERROR 05-01 03:42:24 [worker.py:265] assert peak_memory < 0, ( (VllmWorker rank=0) ERROR 05-01 03:42:24 [worker.py:265] AssertionError (VllmWorker rank=0) ERROR 05-01 03:42:24 [engine_core.py:147] Engine failed to start, exiting [2026-05-01 03:42:25] systemd[1]: vllm-llama70b.service: Main process exited, code=exited, status=1/FAILURE
Lecture : vLLM mesure la mémoire libre AVANT son init (85,21 GB libres), il alloue ses tenseurs (charge weights = 41,8 GB), il re-mesure la mémoire libre APRÈS profiling (86,63 GB libres). Le « après » est PLUS grand que le « avant » ! C'est un invariant cassé : vLLM assume que charger des weights ne peut que DIMINUER la mémoire libre. Il plante.
Pourquoi cette anomalie ? Parce que entre 03:42:18 et 03:42:24, llama-swap a fini d'évincer Qwen3.6-35B. La VRAM occupée par Qwen (22,9 GB) a été libérée pendant que vLLM faisait son profiling. Du point de vue de vLLM, la mémoire « a grandi mystérieusement ». L'assertionpeak_memory < 0 casse parce que peak est positif (86,63 - 85,21 = 1,42 GB de libre additionnel).
C'est techniquement un bug vLLM : l'assertion devrait être tolérante à un GPU multi-tenant. Mais en pratique, vLLM est conçu pour être seul sur son GPU, et personne dans la team upstream n'a testé un scenario llama-swap UMA jusqu'ici.
Notre fix
Trois options, toutes essayées :
- Désactiver le TTL llama-swap :
ttl: 0. Marche, mais on perd l'intérêt de llama-swap (l'eviction). Pas viable pour 6+ modèles. - Lock de coordination via fichier :
flock /var/lock/gb10-vramautour de chaque démarrage vLLM. llama-swap n'évince pas pendant un start vLLM, vLLM ne démarre pas pendant une eviction. C'est ce qu'on a en prod aujourd'hui. Voir le code dans talki-infra/dgx/scripts/vllm-start-locked.sh. - Patch vLLM upstream : on a soumis une issue (#XXXXX) pour proposer une assertion plus tolérante. Pas encore mergée au 2026-05-03.
Bilan opérationnel à 3 mois
Sur 90 jours, le DGX Spark a servi 412 000 requêtes utilisateur (median 4 600/jour, pic à 15 200 pendant un sprint code review). Disponibilité : 99,2 %, 6 incidents distincts dont 4 dus aux trois leçons ci-dessus avant fix. Performances :
| Modèle | Quantization | VRAM | Decode tok/s @ 8K | Time-to-first-token |
|---|---|---|---|---|
| Qwen3.6-35B-A3B | PrismaQuant W4A16 | 22,9 GB | 29 | 180 ms |
| Qwen3.6-35B-A3B | FP8 (eager) | 34,1 GB | 11 | 410 ms |
| Qwen3.6-35B-A3B | GGUF Q5_K_M (llama.cpp) | 26,8 GB | 21 | 240 ms |
| Llama 3.3 70B | GGUF Q4_K_M | 41,8 GB | 14 | 320 ms |
| DeepSeek-Coder 33B | GGUF Q4_K_M | 19,2 GB | 26 | 190 ms |
Coût : capex 4 200 € HT (Spark 128 GB) + 180 € HT (SSD NVMe 4 TB Samsung 990 Pro additionnel) + 90 € HT (UPS APC 600 VA) = 4 470 € HT. Opex électricité 60 €/mois. Amortissement linéaire sur 36 mois = 124 €/mois capex + 60 €/mois opex = 184 €/mois.
Comparable AWS : Bedrock Claude Sonnet 4.6 sur le même volume (412k requêtes, output médian 800 tokens) aurait coûté environ 4 950 $/mois (3 $/1M input + 15 $/1M output). Économie : ~4 200 €/mois. Le Spark est amorti en 32 jours d'utilisation à ce volume.
Questions fréquentes
Le DGX Spark GB10 vaut-il son prix pour un usage LLM en self-hosted ?
Oui, sous deux conditions précises. D'abord, vous devez avoir une charge de travail soutenue (≥ 4-6 heures/jour de génération réelle) sinon l'amortissement face à un Mac Studio M4 Max ou une RTX 5090 est défavorable. Ensuite, vous devez accepter de gérer la mémoire unifiée (UMA) à la main : cgroup ne protège PAS du runaway, et le scheduler Linux ne distingue pas RAM CPU et VRAM. Sur ces deux conditions tenues, le GB10 délivre 25-30 tok/s sur Qwen3.6-35B avec PrismaQuant 4.75bit, ce qui est compétitif avec une H100 PCIe 80 Go pour environ 1/4 du prix d'achat.
Pourquoi le cap mémoire cgroup ne protège-t-il pas un workload UMA ?
Parce que l'OOM-killer Linux score les processus sur la base RSS + swapents, pas sur les mappings virtuels. Sur GB10 avec UMA, vLLM mappe l'intégralité de la VRAM disponible en virtuel (22,9 GB dans nos logs) mais le RSS effectif reste à 2,6 MB tant qu'aucune génération n'a touché ces pages. Conséquence : l'OOM-killer voit un processus à 2,6 MB de RSS et ne le tue jamais — alors même que la mémoire physique est saturée. Le cap memory.high du cgroup est respecté pour le RSS, donc inopérant en pratique.
Combien de temps prend le premier boot après un changement de modèle ?
Compter 18-22 minutes pour Qwen3.6-35B-A3B PrismaQuant 4.75bit la première fois sur un kernel CUDA donné. flashinfer fait du JIT autotuning de tous les kernels d'attention au premier passage, et écrit le résultat dans ~/.cache/flashinfer. Boot suivant pour le même modèle/version CUDA : 90-120 secondes. Si vous changez la version de PyTorch, de CUDA, ou la quantization, le cache est invalidé et vous repartez sur 20 minutes. Conséquence opérationnelle : ne JAMAIS purger ce cache sur un nœud de production.
L'erreur 'Initial free memory 85.21 GiB, current free memory 86.63 GiB' veut dire quoi ?
C'est une AssertionError de vLLM 0.20+ dans la phase de profiling. vLLM mesure la mémoire libre AVANT init, alloue son KV cache, puis re-mesure APRÈS. Si le 'après' est PLUS GRAND que l'avant, l'assertion casse. Sur GB10 avec llama-swap et TTL, c'est exactement ce qui arrive : llama-swap décharge un autre modèle pendant que vLLM démarre, libérant de la VRAM. vLLM voit la VRAM grandir et plante. Fix : démarrer vLLM uniquement quand llama-swap est idle, OU monter le seuil TTL llama-swap au-delà du temps de boot vLLM (15-20 min).
Le GB10 supporte-t-il vLLM avec quelle version de PyTorch ?
Au 2026-05, vLLM 0.20.x sur PyTorch 2.5.1+cu125 fonctionne, mais avec un wheel custom NVIDIA pour Blackwell SM_100. Le wheel pip standard pyTorch ne reconnaît pas la SM_100 (Blackwell consumer/datacenter unifié) et tombe en eager mode (~11 tok/s au lieu de 29 tok/s). Téléchargez le wheel depuis le NVIDIA NGC catalog 'pytorch:25.04-py3' OU compilez torch from source avec TORCH_CUDA_ARCH_LIST='10.0+PTX'. Vérifier avec : python -c "import torch; print(torch.cuda.get_device_capability())" — doit retourner (10, 0).
Quel est le bilan énergétique réel du GB10 ?
Mesuré au prise (wattmètre Shelly) sur 3 mois : 240 W idle (modèle chargé, pas de requête), 380-420 W en génération soutenue, pic à 510 W. À comparer avec une H100 PCIe SXM5 (700 W TDP, ~600 W mesuré en gen) ou un setup 2× RTX 5090 (~900 W combiné). En coût électricité France (0,21 €/kWh, tarif bleu base 2026) ça donne environ 60 €/mois pour 16h/jour d'utilisation. C'est très en dessous du seuil de pertinence économique (cf. notre billet sur le setup 5-noeuds).
Pour aller plus loin
Cet article est le premier d'une série de 3 sur notre adventure GB10. Lire aussi :
- Quantization PrismaQuant 4.75bit sur Qwen3.6-35B : +37 % de débit pour 0 % de qualité perdue — la deep dive technique sur la quantization qui rend tout ça possible
- Notre setup LLM auto-hébergé : 5 noeuds, 1 routeur, 0 cloud (à 8 k€) — l'architecture complète qui place le Spark dans son écosystème
- Optimisation des coûts IA en production 2026 — méthodologie de décision build vs buy