NVIDIA DGX Spark · 23 October 2026

vLLM sur DGX Spark en 2026 : le guide de terrain pour passer de « ça tourne » à « ça sert

Sur une DGX Spark, faire bavarder un modèle est un jeu d’enfant. Le faire encaisser des dizaines de requêtes simultanées, avec un cache KV qui ne déborde pas et un débit qui ne s’effondre pas au troisième utilisateur, c’est une autre histoire. En cette fin 2026, vLLM est devenu la pièce maîtresse de ce passage — et voici comment le régler sans se brûler les ailes sur le GB10.

Le vrai saut qualitatif : du notebook au serveur

Il y a une forme de naïveté heureuse dans les premiers jours d’une DGX Spark. On débarque avec ses 128 Go de mémoire unifiée, on tire une image Docker, on lance un llama.cpp ou un Ollama, et le miracle se produit : un modèle de 70 milliards de paramètres répond en français dans le terminal. Pendant une semaine, on se croit propriétaire d’un mini-datacenter. Puis un ami demande à tester, puis deux, puis un script d’agent lance cinq requêtes en parallèle — et là, tout s’écroule. Le débit single-stream s’effondre, les temps de première réponse explosent, le cache KV sature.

C’est exactement le fossé que vLLM est venu combler. Le moteur né au Sky Computing Lab de l’UC Berkeley n’est pas un énième wrapper autour de Hugging Face : c’est un moteur d’inférence pensé dès l’origine pour le serving concurrent, avec plus de 2000 contributeurs et le support de plus de 200 architectures de modèles. Sur une machine comme la DGX Spark, dont l’architecture mémoire est radicalement différente de celle d’un H100, son comportement change du tout au tout — et c’est précisément ce que ce guide veut disséquer.

Car en 2026, la question n’est plus « est-ce que ça tourne ? ». Elle est devenue : « combien de requêtes par seconde, à quelle latence, et avec quel modèle ? ». Et pour y répondre sur GB10, il faut comprendre ce que vLLM fait sous le capot, comment il compose avec les 128 Go unifiés, et où se situent les vrais pièges.

PagedAttention, continuous batching : ce qui se joue vraiment

Deux mécanismes structurent vLLM, et tous deux prennent une saveur particulière sur Grace Blackwell.

PagedAttention d’abord. Dans un moteur naïf, le cache KV de chaque requête est alloué en un bloc contigu, dimensionné pour la pire longueur de contexte possible. Résultat : une fragmentation massive et une mémoire gaspillée. PagedAttention emprunte l’idée à la mémoire virtuelle des systèmes d’exploitation : le cache KV est découpé en blocs de taille fixe, alloués à la demande et référencés par une table de pages. Sur une carte H100 dotée de 80 Go de HBM, cela permet de faire tenir beaucoup plus de requêtes simultanées. Sur une DGX Spark, où le pool mémoire est partagé entre CPU, GPU, OS, runtime conteneur, poids du modèle et cache KV, ce même mécanisme devient une question de survie : chaque gigaoctet gaspillé est un gigaoctet qui manque au modèle.

Le continuous batching ensuite — avec ses déclinaisons que sont le chunked prefill et le prefix caching. L’idée : au lieu de traiter les requêtes par lots statiques (attendre que tout le monde ait fini avant d’accepter de nouveaux arrivants), le scheduler de vLLM injecte et retire des requêtes à chaque pas de décodage. Le prefix caching, lui, permet de réutiliser le cache KV d’un préfixe commun — précieux quand un agent envoie dix fois le même prompt système. Le moteur expose par ailleurs un serveur API compatible OpenAI, ainsi qu’Anthropic Messages API et gRPC, ce qui facilite l’intégration dans des piles existantes.

Ce que la documentation officielle ne détaille pas — et c’est une limite qu’il faut assumer — c’est le fonctionnement interne fin du block manager et les politiques exactes de préemption (swap versus recompute). Les sources publiques restent discrètes sur ces algorithmes. Ce que l’on sait avec certitude, en revanche, c’est que vLLM supporte des kernels d’attention variés (FlashAttention, FlashInfer, TRTLLM-GEN, FlashMLA, Triton) et le décodage spéculatif (n-gram, suffix, EAGLE, DFlash), ainsi qu’une large palette de quantifications : FP8, MXFP8/MXFP4, NVFP4, INT8/INT4, GPTQ/AWQ, GGUF, compressed-tensors, ModelOpt, TorchAO.

La mémoire unifiée : le vrai sujet du GB10

C’est ici que tout se joue, et c’est ici que les réflexes pris sur H100 ou A100 deviennent contre-productifs.

Sur une DGX Spark, le SoC GB10 Grace Blackwell (architecture sm_121, « consumer Blackwell ») réunit CPU et GPU autour d’un pool mémoire unifié de 128 Go. Il n’y a pas de HBM séparée, pas de copie explicite host→device à orchestrer : tout le monde — OS, runtime conteneur, poids du modèle, cache KV — puise dans la même réserve. Le blog officiel de vLLM sur la DGX Spark insiste sur ce point : il faut régler --gpu-memory-utilization avec une marge, et garder --max-num-seqs bas, en privilégiant un petit batch plutôt qu’une haute concurrence.

Le corollaire, c’est que les repères de bande passante changent complètement. Un H100 s’appuie sur de la HBM3 à très haut débit ; la DGX Spark, elle, se contente d’une LPDDR5X dont le débit de décodage est cité à 273 Go/s dans les guides de terrain publiés en 2026. Cette asymétrie explique pourquoi le décodage — l’étape autoregressive, gourmande en bande passante — est le goulot d’étranglement principal sur GB10, bien plus que le prefill.

Autre différence structurante : l’absence de NVLink. Sur une grappe de H100, la communication inter-GPU passe par des liens dédiés à très haute bande passante. Sur deux DGX Spark, il faut composer avec les interconnexions réseau disponibles, ce qui rend le tensor parallelism (TP=2) plus coûteux en synchronisation. C’est précisément pourquoi les recettes communautaires recommandent souvent de commencer en mono-puce, et de n’envisager le cluster qu’une fois le serveur mono-modèle stabilisé.

Enfin, le comportement du KV cache offload sur mémoire unifiée reste, à ce jour, mal documenté publiquement. La logique voudrait que l’absence de frontière CPU/GPU rende certains mécanismes de swap moins pertinents — mais aucune source indépendante ne vient confirmer ou infirmer cette intuition. Prudence, donc : sur GB10, mieux vaut dimensionner le cache KV pour qu’il tienne, plutôt que de compter sur un débordement gracieux.

Configurer vLLM sur GB10 : les flags qui comptent

Voici la configuration de terrain, celle qui ressort des recettes communautaires et du blog officiel. Elle n’a rien de magique, mais chaque paramètre répond à une contrainte matérielle précise.

Le blog officiel de vLLM sur la DGX Spark mentionne explicitement les kernels NVFP4, les CUDA graphs par défaut, l’async scheduling et le MTP speculative decoding comme leviers de performance, avec une recette testée pour Nemotron-3-Super via une image Docker compatible OpenAI. C’est un point de départ solide — mais il faut garder en tête que ce blog est éditorial et promotionnel : il émane du projet lui-même.

Côté quantifications, la matrice est large : FP8, MXFP8/MXFP4, NVFP4, INT8/INT4, GPTQ/AWQ, GGUF, compressed-tensors, ModelOpt, TorchAO. Sur GB10, la question n’est pas « laquelle est supportée » (elles le sont toutes ou presque) mais « laquelle laisse assez de place au cache KV ». Un modèle 70B en FP8 occupe déjà une part considérable des 128 Go ; en AWQ 4 bits, il respire, et le cache KV peut grandir.

Côté logiciel, vLLM propose des builds Stable et Nightly, requiert Python 3.10+ (3.12+ recommandé) et recommande uv. Le site officiel revendique la compatibilité avec toutes les versions CUDA 13.x (13.0 – 13.1) — une affirmation qui, à notre connaissance, n’a pas été recoupée par une source indépendante, et qu’il convient donc de prendre pour ce qu’elle est : une revendication du projet.

Les pièges spécifiques au GB10

Trois écueils reviennent systématiquement chez les utilisateurs de DGX Spark qui passent à vLLM.

Le premier est le surdimensionnement du contexte. Sur H100, allouer 128k de contexte ne coûte « que » de la mémoire HBM, abondante et rapide. Sur GB10, chaque token de contexte supplémentaire rogne le pool partagé. La règle de terrain : calibrer --max-model-len sur l’usage réel. Un agent qui travaille sur des documents de 8k tokens n’a que faire d’un contexte de 128k.

Le deuxième est la tentation du cluster prématuré. Deux DGX Spark permettent, selon les chiffres publics, de faire tourner des modèles jusqu’à 405 milliards de paramètres — un chiffre qui fait rêver. Mais le tensor parallelism sur GB10 est pénalisé par l’absence de NVLink, et les recettes communautaires recommandent de stabiliser d’abord un serveur mono-modèle. Le cluster est une étape, pas un point de départ.

Le troisième est l’oubli du système. Le pool de 128 Go n’est pas réservé au modèle : l’OS, le runtime conteneur et les processus annexes y puisent aussi. Un --gpu-memory-utilization trop agressif se solde par des OOM inexplicables ou, pire, par un système qui devient instable. La marge n’est pas une option.

vLLM face à Ollama et llama.cpp : le match des piles

Faut-il vraiment vLLM sur une DGX Spark ? La réponse dépend de l’usage, et le tableau suivant résume les arbitrages.

Les chiffres publics de 2026 donnent la mesure de l’écart. Sur une DGX Spark unique, llama.cpp en GGUF atteint jusqu’à 67 tok/s sur un modèle 35B-A3B, et un débit single-stream d’environ 14 tok/s sur DeepSeek-V4-Flash IQ2_XXS avec un prefill de 410 t/s. En face, une configuration bi-Spark en TP=2 avec vLLM et DeepSeek-V4-Flash FP8 délivre environ 41 tok/s en single-stream, un prefill d’environ 1785 t/s et surtout un débit agrégé d’environ 350 tok/s à concurrence 32. C’est là que se joue la différence : non pas sur la vitesse d’un seul utilisateur, mais sur la capacité à encaisser la charge.

Les recettes communautaires reflètent cette maturité naissante. Le dépôt spark-dgx et le projet dgx-spark-vllm-setup — ce dernier promettant une installation vLLM en une commande — témoignent d’un écosystème qui se structure. Les guides de terrain, comme celui de SparkBench ou les benchmarks publiés par tokenstead.ai, complètent le tableau. Mais il faut le dire : la plupart de ces sources restent soit officielles (donc intéressées), soit communautaires (donc non recoupées). Les benchmarks indépendants sur GB10 restent rares, et c’est une limite honnête de l’état de l’art en cette fin 2026.

Du mono-modèle au petit cluster : le mode d’emploi

Passer d’un serveur vLLM mono-modèle à un cluster de deux Spark n’est pas une simple affaire de flag --tensor-parallel-size 2. C’est un changement d’échelle qui redistribue les contraintes.

Étape 1 — Stabiliser le mono-puce. Un serveur vLLM qui tourne 24 heures sans OOM, avec un cache KV correctement dimensionné et un débit mesuré, est le prérequis. C’est là qu’on apprend à connaître sa machine : quel modèle tient, à quelle quantification, avec quel contexte.

Étape 2 — Choisir le bon modèle pour le cluster. Les chiffres publics donnent un repère précieux : deux DGX Spark peuvent faire tourner des modèles jusqu’à 405 milliards de paramètres, avec un pool de cache KV partagé de 1 105 096 tokens dans une configuration bi-Spark. C’est cette capacité de cache qui fait la différence sur les charges concurrentes.

Étape 3 — Accepter le coût du TP=2. Sans NVLink, chaque pas de décodage implique une synchronisation entre les deux nœuds. Le débit single-stream en souffre (environ 41 tok/s contre 14 tok/s en mono-Spark sur un modèle comparable, mais avec des modèles et quantifications différents — la comparaison n’est pas stricte), mais le débit agrégé explose : environ 350 tok/s à concurrence 32.

Étape 4 — Monitorer. Sur GB10, le pool unifié rend le monitoring plus délicat : la frontière CPU/GPU n’existe pas, et un pic d’utilisation mémoire peut venir de n’importe où. Les outils de monitoring classiques doivent être adaptés.

Le contexte 2026 : une machine qui bouge

Il serait malhonnête de parler de vLLM sur DGX Spark sans mentionner que la machine elle-même a changé en 2026. Le 2 octobre 2026, NVIDIA a annoncé une version 64 Go de la DGX Spark, commercialisée à 4 999 dollars à partir du 23 octobre, tandis que le modèle 128 Go dépasse désormais les 6 000 dollars sur le marché. Cette segmentation change la donne : la version 64 Go impose des arbitrages mémoire encore plus serrés, et rend le réglage fin de vLLM d’autant plus critique.

Côté logiciel, les mises à jour de la DGX Spark se sont succédé — release de juillet 2026, puis release d’octobre 2026, documentées sur les forums développeurs de NVIDIA. Ces mises à jour incluent des évolutions du stack logiciel qui impactent directement le comportement de vLLM : drivers, CUDA, kernels.

Enfin, la concurrence s’organise. L’AMD Ryzen AI Halo 192 Go, lancé à 7 299,99 dollars chez Micro Center, revendique la capacité de charger des modèles open weight jusqu’à 300 milliards de paramètres — mais les benchmarks indépendants cités par la presse soulignent que la DGX Spark garde l’avantage en vitesse. Et les mini-PC GB10 d’Acer, livrés depuis le 8 septembre 2026 avec 128 Go de mémoire unifiée et positionnés 500 à 1 000 dollars sous le prix NVIDIA, élargissent l’écosystème. Tous ces systèmes partagent la même puce GB10 — et donc les mêmes contraintes vLLM.

Perspectives : ce qui reste à prouver

L’état de l’art en cette fin 2026 laisse plusieurs questions ouvertes, et il faut le dire clairement.

Les benchmarks indépendants manquent. La plupart des chiffres cités dans cet article proviennent soit du blog officiel de vLLM, soit de sources communautaires. Les benchmarks tiers sur GB10 restent rares. L’initiative AA-AgentPerf-Local d’Artificial Analysis, lancée le 29 septembre 2026 avec des tests sur DGX Spark, Ryzen AI Halo, MacBook Pro (M5 Pro) et RTX 5090, est un pas dans la bonne direction — mais elle ne couvre que quatre modèles open weight au lancement.

Le comportement du KV cache offload sur mémoire unifiée reste mal documenté. Aucune source publique ne décrit précisément comment vLLM gère le débordement du cache KV quand le pool unifié sature. C’est une zone d’ombre qui mériterait des travaux.

Le support CUDA 13.x est revendiqué, pas vérifié. Le site officiel affirme la compatibilité avec toutes les versions CUDA 13.x (13.0 – 13.1), mais aucune matrice de compatibilité détaillée ni notes de release ne viennent étayer cette affirmation dans les sources publiques.

Les versions précises de vLLM testées sur DGX Spark ne sont pas citées. Le blog officiel date du 1er juin 2026, mais ne mentionne pas la version du moteur utilisée. Impossible, donc, de savoir si les recettes publiées s’appliquent à la build Stable ou Nightly actuelle.

Ce que l’on peut affirmer, en revanche, c’est que vLLM est devenu la pièce centrale du serving sur GB10. La machine a trouvé son moteur ; il reste à l’écosystème à produire les mesures indépendantes qui permettront de régler finement chaque configuration. D’ici là, les recettes communautaires — spark-dgx, dgx-spark-vllm-setup — et le blog officiel restent les meilleurs points de départ. À condition de garder en tête qu’ils sont écrits par des parties prenantes.

Pour celui qui a la machine devant lui, la conclusion est simple : commencez mono-puce, dimensionnez votre contexte au plus juste, gardez --max-num-seqs bas, et ne passez au cluster que lorsque le mono-modèle tourne rond. Le reste — les kernels NVFP4, l’async scheduling, le décodage spéculatif — viendra en bonus.

Sources

• vLLM — site officiel
• vLLM — dépôt GitHub officiel
• vLLM — documentation
• vLLM — guide d’installation
• vLLM on the DGX Spark: Architecture, Configuration, and Local Deployment (blog officiel, 1er juin 2026)
• NVIDIA DGX Spark 64GB — annonce (2 octobre 2026)
• DGX Spark Software Updates — October 2026 Release (forums développeurs NVIDIA)
• DGX Spark Software Updates — July 2026 Release (forums développeurs NVIDIA)
• DGX Spark Release Notes — NVIDIA
• AA-AgentPerf-Local — Artificial Analysis (29 septembre 2026)
• SparkBench — what runs on a DGX Spark
• DGX Spark Benchmarks: Which Local Model Wins in 2026 — tokenstead.ai
• Best Local LLM Deployment Guide for DGX Spark, GB10 & 96-128 GB Edge AI
• spark-dgx — dépôt GitHub communautaire
• dgx-spark-vllm-setup — dépôt GitHub communautaire
• NVIDIA DGX Spark 64GB — MarkTechPost (2 octobre 2026)
• AMD Ryzen AI Halo 192GB — TechTimes (14 octobre 2026)
• Nvidia DGX Spark 64 Go — Génération-NT (4 octobre 2026)

Article recherché et rédigé automatiquement · Magazine Electrosens