---

Le 19 octobre 2026, NVIDIA change de casquette : du vendeur de puces au fournisseur d’agents clés en main

Il faut mesurer le symbole. NVIDIA, l’entreprise fondée le 5 avril 1993 à Sunnyvale par Jensen Huang, Chris Malachowsky et Curtis Priem, devenue en trois décennies le premier fournisseur mondial de silicium pour l’IA — un chiffre d’affaires de 215,9 milliards de dollars sur l’exercice FY26 clos le 25 janvier 2026, selon les données publiques reprises par Wikipédia — a longtemps vendu du métal. Des GPU, des SoC, des cartes, des systèmes complets. Le logiciel était l’huile dans les rouages, pas le produit.

Le 19 octobre 2026, la firme de Santa Clara a franchi un cap : elle a dévoilé une nouvelle famille de modèles ouverts destinés à faire tourner des agents en entreprise et sur PC. Autrement dit, NVIDIA ne se contente plus de fournir le moteur, elle livre aussi une partie de la voiture — les poids, l’inférence, la chaîne d’outils.

Pourquoi cette date compte-t-elle spécifiquement pour les propriétaires de DGX Spark ? Parce que la Spark est, depuis son lancement, la machine que NVIDIA vend comme le poste de travail IA local : un mini-supercalculateur de bureau capable de faire tourner des modèles ouverts en local, sans cloud, sans fuite de données. Une annonce de modèles ouverts « pour agents locaux » est donc, littéralement, une annonce adressée à cette base installée.

Le paradoxe mérite d’être posé d’emblée : un fabricant de matériel qui pousse des poids ouverts, c’est un fabricant qui réduit une partie de la valeur de son propre silicium propriétaire pour mieux vendre l’écosystème complet. La stratégie n’est pas nouvelle — elle rappelle le pari de l’open source dans les années 2010 — mais elle prend ici une ampleur inédite, parce que le matériel et le logiciel sont désormais conçus ensemble.

La question centrale, celle qui doit structurer toute lecture de cette annonce, est simple : que peut-on réellement faire tourner sur un GB10 avec 64 ou 128 Go de mémoire unifiée, et à quel prix en qualité et en latence ? C’est à cette question que cet article tente de répondre, sans survendre ni sous-estimer la plateforme.

---

Ce qu’il y a vraiment dans la boîte : architectures, tailles, contextes et licences de la famille annoncée

Soyons honnêtes sur un point d’entrée : les spécifications détaillées de la famille annoncée le 19 octobre 2026 — noms exacts des modèles, tailles de paramètres, variantes dense ou MoE, fenêtre de contexte maximale, tokenizer, langues supportées — ne sont pas documentées dans les sources dont nous disposons. L’annonce elle-même est confirmée par la couverture de TechCrunch, mais ses détails techniques restent à vérifier sur les pages officielles de NVIDIA et sur Hugging Face.

Ce que l’on sait avec certitude, en revanche, c’est le contexte dans lequel cette famille s’inscrit. NVIDIA a déjà lancé « Nemotron 3.5 Lightning » et « Switchyard » pour réduire le coût des agents d’IA, selon eWeek. Les modèles ouverts NVIDIA Nemotron sont par ailleurs utilisés par des acteurs comme Commotion pour des systèmes d’exploitation IA d’entreprise. La famille du 19 octobre s’inscrit donc dans une continuité : celle d’une gamme Nemotron qui s’étoffe et se spécialise.

Méthode de vérification. Pour un déploiement sérieux, la première étape consiste à consulter directement les fiches modèles sur Hugging Face — le hub de référence — et à lire la model card officielle : elle contient la licence, la taille, le contexte, le tokenizer et les langues. C’est là, et non dans un communiqué de presse, que se joue la décision d’achat. Les licences précises (commerciale, recherche, restrictions d’usage) ne sont pas documentées dans nos sources : il faut les lire au mot près avant tout déploiement en production.

Un point de vigilance mérite d’être souligné : l’absence de benchmarks publics (MMLU, HumanEval, BFCL pour le tool-calling, SWE-bench, latence) dans les sources disponibles signifie qu’il faut se méfier des comparaisons hâtives avec Llama 4, Qwen 3, Mistral ou DeepSeek. Les modèles concurrents existent et sont matures, mais leurs chiffres précis ne sont pas non plus documentés ici. La prudence est donc de mise : ne pas conclure sur la supériorité d’une famille sur une autre sans données tierces indépendantes.

---

GB10 sous le capot : 128 Go unifiés, 273 Go/s et ConnectX-7 — la vraie fiche technique qui décide de tout

Le DGX Spark repose sur le SoC GB10 Grace Blackwell. Les caractéristiques qui comptent pour l’inférence de LLM sont peu nombreuses mais décisives : un CPU ARM à 20 cœurs, un GPU Blackwell, et surtout une mémoire unifiée LPDDR5x de 64 ou 128 Go selon la configuration, avec une bande passante d’environ 273 Go/s. La connectivité ConnectX-7 permet d’agréger plusieurs Sparks en cluster.

Pourquoi ces chiffres décident-ils de tout ? Parce que l’inférence de LLM est, sur ce type de machine, limitée par la bande passante mémoire, pas par le compute. Le GPU Blackwell est largement surdimensionné pour le décodage token par token ; ce qui ralentit la génération, c’est le temps nécessaire pour lire les poids du modèle en mémoire à chaque token produit. Avec 273 Go/s, on peut estimer grossièrement le débit maximal théorique : un modèle de 8 milliards de paramètres quantifié en 4 bits pèse environ 4 Go, ce qui donnerait un plafond théorique de l’ordre de plusieurs dizaines de tokens par seconde — plafond que les mesures réelles ramènent toujours à la baisse à cause des surcoûts de calcul, du KV cache et de la gestion mémoire.

Les faits datés du magazine confirment cette lecture. Sur un seul DGX Spark, un modèle de type DeepSeek-V4-Flash quantifié en IQ2_XXS atteint environ 14 tokens/s en single-stream et 410 tokens/s en prefill (mesures d’août 2026). Avec llama.cpp et un modèle de type 35B-A3B en GGUF, on monte jusqu’à 67 tokens/s. Sur deux Sparks agrégés en tensor parallel avec vLLM et DeepSeek-V4-Flash en FP8, le débit single-stream passe à environ 41 tokens/s, le prefill à 1 785 tokens/s, et le débit agrégé à concurrence 32 atteint 350 tokens/s.

Ces chiffres racontent une histoire simple : la Spark est une machine de décodage modeste et de préfill correcte. Elle brille en traitement par lots et en agents concurrents, pas en génération interactive ultra-rapide d’un modèle géant.

Conséquences directes pour le choix de modèle :

• Taille : un modèle de 30 à 70 milliards de paramètres quantifié en 4 bits tient confortablement dans 128 Go, avec de la marge pour le KV cache. Un modèle de 400 milliards de paramètres nécessite deux Sparks (la limite documentée pour deux machines est de 405 milliards de paramètres).
• Quantification : plus on descend en bits, plus on gagne en débit et en capacité, mais plus on perd en qualité — surtout sur le tool-calling, très sensible aux dégradations.
• Agents concurrents : la mémoire unifiée est partagée entre poids, KV cache et contexte. Sur deux Sparks avec cache KV partagé, on peut tenir un pool de 1 105 096 tokens (août 2026), ce qui autorise plusieurs dizaines d’agents simultanés avec des contextes raisonnables.

---

FP4, FP8, GGUF, AWQ : ce que le silicium avale vraiment et ce que la qualité y perd

Le GB10, grâce à son GPU Blackwell, supporte nativement le FP4 — c’est l’un de ses arguments différenciants. Il gère aussi le FP8, l’INT4, et, via la chaîne logicielle, les formats GGUF et AWQ.

Chaque format a son écosystème :

• FP4 : exploité par TensorRT-LLM et, dans une certaine mesure, vLLM. C’est le format qui maximise le débit et minimise l’empreinte, au prix d’une dégradation de qualité qui peut être significative sur les tâches de raisonnement fin.
• FP8 : le compromis de référence. Supporté par vLLM, TensorRT-LLM et NIM. C’est le format utilisé dans les mesures de référence du magazine sur deux Sparks (DeepSeek-V4-Flash FP8).
• INT4 / AWQ : formats de quantification populaires dans l’écosystème open source, supportés par vLLM et llama.cpp.
• GGUF : le format de llama.cpp et Ollama, idéal pour le prototypage et les tests rapides. C’est lui qui permet d’atteindre 67 tokens/s sur un 35B-A3B selon les mesures d’août 2026.

Impact qualité. La quantification dégrade d’abord les capacités de raisonnement complexe et de tool-calling. Un modèle en FP4 peut sembler excellent en conversation et s’effondrer sur un appel d’outil structuré. La règle empirique : rester en FP8 ou BF16 pour les agents critiques (tool-calling, RAG sur documents sensibles), et réserver le FP4 aux tâches de génération libre ou aux scénarios à très forte concurrence où le débit prime.

---

Choisir son moteur d’inférence sur Spark : vLLM, TensorRT-LLM, Ollama, llama.cpp ou NIM — le match par cas d’usage

Le choix du moteur est aussi important que celui du modèle. Voici un comparatif argumenté des options disponibles sur DGX OS.

Moteur	Points forts	Points faibles	Cas d’usage idéal
vLLM	Débit élevé, PagedAttention, serving multi-agents, support FP8	Configuration mémoire délicate, moins optimisé pour FP4 que TensorRT-LLM	Agents concurrents, serving en production
TensorRT-LLM	Optimisation FP4/FP8 native, compilation poussée	Compilation longue, moins flexible, courbe d’apprentissage	Déploiement figé, performances maximales
Ollama	Simplicité extrême, GGUF, installation en une commande	Débit inférieur, moins de contrôle mémoire	Prototypage, tests rapides, assistants personnels
llama.cpp	Contrôle fin, GGUF, très bon sur CPU/GPU hybride	Configuration manuelle, pas de serving multi-agents natif	Expérimentation, modèles quantifiés agressivement
NIM	Conteneurs enterprise, garde-fous intégrés, support NVIDIA	Dépendance à l’écosystème NVIDIA, moins ouvert	Déploiement en entreprise, conformité

Les versions logicielles exactes de DGX OS, CUDA, vLLM, TensorRT-LLM, Ollama, llama.cpp et NIM ne sont pas documentées dans nos sources : il faut consulter les notes de version officielles de NVIDIA avant toute mise à jour. Un piège classique : les incompatibilités entre versions CUDA et versions de vLLM/TensorRT-LLM, qui peuvent provoquer des erreurs silencieuses ou des chutes de performance.

---

Réglages mémoire qui font la différence : gpu_memory_utilization, max_model_len, KV cache et offloading

C’est ici que se joue la différence entre un Spark qui tourne et un Spark qui rame. Sur 64 ou 128 Go de mémoire unifiée, chaque gigaoctet compte.

Calcul de l’empreinte réelle. Un modèle de 8B en FP8 pèse environ 8 Go ; en FP4, environ 4 Go. Un modèle de 30B en FP8 pèse environ 30 Go ; en FP4, environ 15 Go. Un modèle de 70B en FP8 pèse environ 70 Go ; en FP4, environ 35 Go. À cela s’ajoute le KV cache, qui croît avec la longueur du contexte et le nombre d’agents concurrents. Sur deux Sparks, le pool de cache KV partagé documenté atteint 1 105 096 tokens — c’est la marge disponible pour les contextes longs.

Paramètres critiques :

• gpu_memory_utilization : la fraction de mémoire allouée au moteur. Trop haut, on risque l’OOM ; trop bas, on perd en débit. Sur 128 Go, une valeur de 0,85 à 0,9 est un point de départ raisonnable.
• max_model_len : la longueur maximale de contexte. La réduire libère de la mémoire pour le KV cache et les agents concurrents.
• Quantification du KV cache : permet de doubler la capacité de contexte au prix d’une légère dégradation.
• Offloading CPU/GPU : à éviter sur Spark, où la mémoire est déjà unifiée ; l’offloading n’apporte pas le gain attendu et peut créer des ralentissements.

Erreurs fréquentes : OOM silencieux (le moteur démarre mais échoue à la première requête longue), swap mémoire (effondrement du débit), et sur-allocation qui empêche tout agent supplémentaire de démarrer.

---

Tool-calling, garde-fous et sandboxing : transformer un LLM local en agent fiable sur Spark

Un modèle qui parle n’est pas un agent. Un agent, c’est un modèle qui appelle des outils, lit des fichiers, interroge des bases — et qui doit le faire de manière fiable et sécurisée.

Format attendu. Les modèles NVIDIA pour agents utilisent un format de function calling structuré (JSON schema). Le parsing doit être robuste : valider les arguments, gérer les erreurs, limiter les appels en boucle.

Garde-fous indispensables :

• Validation des arguments contre un schéma strict.
• Allowlist d’outils : l’agent ne peut appeler que les outils explicitement autorisés.
• Limites de tokens par appel et par session.
• Journalisation de tous les appels pour audit.

Sandboxing. Les exécutions doivent être isolées dans des conteneurs, avec des permissions minimales. Sur Spark, cela signifie typiquement faire tourner l’agent dans un conteneur Docker avec accès restreint au système de fichiers.

Exemples de configurations concrètes :

• RAG local sur documents d’entreprise : vLLM en serving, un index vectoriel local, un outil de recherche documentaire, et un prompt système qui impose la citation des sources.
• Assistant de code avec accès fichiers : llama.cpp ou Ollama pour la simplicité, un outil de lecture/écriture de fichiers sandboxé, et des limites strictes sur les répertoires accessibles.
• Automatisation bureautique : NIM en conteneur avec garde-fous intégrés, outils d’envoi de courriels et de gestion de calendrier, allowlist stricte.

---

Un Spark ou deux ? Clusters ConnectX-7, performances attendues et benchmarks reproductibles

La question du cluster est centrale. Les mesures documentées montrent un saut qualitatif net entre un et deux Sparks :

Configuration	Débit single-stream	Prefill	Débit agrégé @ c=32	Taille max de modèle
1× DGX Spark (IQ2_XXS)	~14 tok/s	410 tok/s	non documenté	~70B (estimation)
1× DGX Spark (GGUF 35B-A3B)	jusqu’à 67 tok/s	non documenté	non documenté	~35B
2× DGX Spark (TP=2, FP8)	~41 tok/s	~1 785 tok/s	~350 tok/s	405B

Le message est clair : deux Sparks ne doublent pas le débit single-stream, mais démultiplient la capacité et le débit agrégé. C’est le passage à l’échelle des agents, pas de la latence interactive.

Benchmarks reproductibles. L’outil AA-AgentPerf-Local, publié par Artificial Analysis le 29 septembre 2026, teste la vitesse des agents IA locaux sur laptops et workstations, 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 aujourd’hui la référence la plus solide pour comparer les machines. Les forums NVIDIA et Reddit r/LocalLLaMA restent des sources complémentaires précieuses, mais à prendre avec les précautions d’usage.

Comparaison avec les concurrents. Llama 4, Qwen 3, Mistral et DeepSeek existent et sont matures, mais les benchmarks précis à taille équivalente ne sont pas documentés dans nos sources. Une donnée intéressante circule néanmoins : Qwen3.6-27B atteint 28-33 tokens/s en session unique sur DGX Spark, et 136 tokens/s avec 10 agents — ce qui illustre le comportement typique de la plateforme : modeste en single-stream, excellente en concurrence.

---

Ce que l’annonce change vraiment : ni révolution immédiate, ni coup d’épée dans l’eau

Que retenir, au fond ? L’annonce du 19 octobre 2026 apporte trois choses réelles aux propriétaires de Spark : des licences ouvertes (à vérifier au cas par cas), une intégration NIM qui simplifie le déploiement enterprise, et un tool-calling natif pensé pour les agents. C’est loin d’être anecdotique : cela signifie que la Spark cesse d’être une machine « à bricoler » pour devenir une plateforme sur laquelle on peut déployer des agents en production avec des garde-fous.

Ce que l’annonce ne résout pas, en revanche :

• La bande passante mémoire (~273 Go/s) reste le plafond structurel. Aucun modèle ouvert ne changera cela.
• La limite des 128 Go (ou 64 Go sur la version d’entrée de gamme) impose des compromis permanents sur la taille des modèles et le nombre d’agents.
• La dépendance à l’écosystème CUDA reste entière : les modèles NVIDIA sont optimisés pour le matériel NVIDIA, ce qui est à la fois une force et une contrainte.

La concurrence, elle, ne dort pas. AMD a lancé son Ryzen AI Halo 192 Go à 7 299,99 $ chez Micro Center, capable de charger des modèles de 300 milliards de paramètres — même si, selon les benchmarks indépendants, le DGX Spark conserve l’avantage en vitesse. Les modèles ouverts chinois (Qwen, DeepSeek) et européens (Mistral) continuent de progresser. Et la feuille de route logicielle de DGX OS promet des évolutions régulières.

Critères pour décider dès aujourd’hui d’un déploiement en production sur Spark :

1. Votre charge de travail est-elle dominée par la concurrence (plusieurs agents) ou par la latence interactive ? Si c’est la concurrence, la Spark est excellente.
2. Vos modèles tiennent-ils dans 128 Go avec le KV cache nécessaire ? Si non, prévoyez deux Sparks.
3. Le tool-calling est-il critique ? Dans ce cas, restez en FP8 et validez les modèles sur des benchmarks reproductibles.
4. Avez-vous besoin de garde-fous enterprise ? NIM est votre allié.

L’annonce du 19 octobre 2026 n’est ni une révolution immédiate ni un coup d’épée dans l’eau. C’est une étape : celle d’un fabricant qui apprend à vendre des agents, pas seulement des puces. Pour les propriétaires de Spark, le vrai travail commence maintenant — lire les fiches modèles, mesurer, régler, et déployer avec méthode.

---

Sources

• Nvidia launches new open models to run agents in the enterprise and on PCs — TechCrunch, 19 octobre 2026
• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blogs.nvidia.com, 2 octobre 2026
• NVIDIA 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
• The Best DGX Spark for Local AI in 2026: LLM Speed, Model Sizes, and Clusters, With Sources — pyshine.com, 1er octobre 2026
• AA-AgentPerf-Local: Benchmarking local AI agents on laptops and workstations — Artificial Analysis, 29 septembre 2026
• AMD Ryzen AI Halo 192GB Loads Models No Rival Can: DGX Spark Still Wins on Speed — TechTimes, 14 octobre 2026
• Nvidia DGX Spark 64GB Launches at $4,999: Is It Worth It? — TechRepublic
• Nvidia’s DGX Spark is getting a 64GB RAM variant to make running local models more affordable — XDA Developers
• NVIDIA — Wikipédia
• NVIDIA Drivers — nvidia.com