---

DGX Spark + TensorRT Edge-LLM : la petite boîte qui veut concurrencer le cloud

Il faut se représenter la scène. Une machine de la taille d’un livre un peu épais, posée sur un bureau, avec 64 Go de mémoire unifiée, un SoC GB10 Grace Blackwell estampillé 1 PFLOP, et une promesse : faire tourner localement un modèle de 30 milliards de paramètres (3 milliards actifs, architecture MoE) sans jamais sortir de l’écosystème NVIDIA. C’est le DGX Spark, dont la déclinaison 64 Go a été officialisée le 2 octobre 2026 et commercialisée à partir du 23 octobre à 4 999 dollars — pendant que la version 128 Go grimpait au-delà des 6 000 dollars sur le marché, conséquence directe de la flambée des prix de la mémoire.

Le 30 octobre 2026, donc, NVIDIA a publié un billet détaillant un workflow en ligne de commande pour exécuter le modèle nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 sur cette machine, via un paquet Python nommé tensorrt-edgellm[server]==0.11.1. L’information a été relayée par blockchain.news, et c’est essentiellement à cette source unique — reprise d’un blog NVIDIA Developer — que nous devons l’essentiel des faits techniques cités ici. Autant le dire d’emblée : nous n’avons trouvé aucune mesure indépendante, aucun résultat MLPerf Edge, aucune donnée de consommation électrique pour corroborer les chiffres avancés. Ce texte est donc, pour partie, une lecture critique d’un discours constructeur.

Pourquoi cette annonce compte-t-elle ? Parce qu’elle déplace la frontière. Jusqu’ici, faire de l’inférence locale sur GB10 relevait d’une pratique artisanale : on installait llama.cpp ou vLLM, on téléchargeait un GGUF ou un checkpoint FP8, on lançait un serveur, et on itérait jusqu’à ce que ça tienne en mémoire. Ce workflow-là est un workflow de prototype. Ce que NVIDIA décrit le 30 octobre, c’est autre chose : un pipeline de compilation ahead-of-time, avec quantification NVFP4, build d’engines, cache, puis un runtime C++ léger exposant une API compatible OpenAI sur 127.0.0.1:8000. Et surtout, une promesse de portabilité : le même framework est présenté comme destiné à être porté vers Jetson Thor, DRIVE AGX Thor et IGX Thor. Autrement dit, on développe sur Spark, on déploie sur Thor.

Le plan de cet article : décortiquer l’architecture réelle de TensorRT Edge-LLM, examiner les trois leviers techniques qui font la différence sur GB10 (NVFP4, DSpark, mémoire unifiée), passer au crible les chiffres publiés, puis explorer ce que cela change pour le fine-tuning, le clustering, et finalement trancher : qui doit réellement adopter cette voie en 2026 ?

---

TensorRT Edge-LLM, mode d’emploi : un compilateur avant d’être un runtime

La confusion la plus répandue consiste à ranger TensorRT Edge-LLM dans la catégorie « serveur d’inférence ». C’est une erreur de catégorie. TensorRT Edge-LLM est d’abord une chaîne de compilation, et accessoirement un runtime.

Le pipeline, tel que documenté, s’articule en plusieurs étapes distinctes. D’abord le téléchargement : environ 21 Go de fichiers modèle au premier lancement. Ensuite la conversion du modèle Hugging Face vers une représentation intermédiaire, avec quantification — ici NVFP4, mais le format est présenté comme compatible avec d’autres précisions selon les cibles. Puis la calibration, étape cruciale et souvent sous-estimée : déterminer les échelles de quantification à partir d’un jeu de données représentatif. Vient le build proprement dit, où TensorRT compile un engine optimisé pour le matériel cible, avec fusion de kernels, sélection d’algorithmes et planification mémoire. Enfin, le cache : l’engine produit est stocké, et les lancements ultérieurs n’ont plus à repayer le coût de compilation.

Le runtime, lui, est un binaire C++ léger. Il charge l’engine, gère explicitement la mémoire unifiée du GB10, et ordonnance les requêtes — avec, dans la configuration testée, un batch size de 1 et une requête streaming concurrente. Il expose une API locale compatible OpenAI, ce qui permet de brancher n’importe quel client existant sans réécrire une ligne.

La différence avec TensorRT-LLM classique est structurelle. TensorRT-LLM est un framework lourd, pensé pour le datacenter : dépendances nombreuses, empreinte importante, cibles H100/H200/B200, orchestration multi-GPU. TensorRT Edge-LLM vise l’inverse : un binaire compact, des dépendances minimales, une cible mono-nœud à budget mémoire contraint, et une portabilité vers des SoC embarqués. La différence avec vLLM et llama.cpp est d’une autre nature encore : ceux-ci font du JIT — ils chargent les poids, compilent ou interprètent à la volée, et s’adaptent à ce qu’on leur donne. TensorRT Edge-LLM fait de l’AOT : tout est figé à la compilation. On perd en flexibilité, on gagne en déterminisme.

Critère	TensorRT Edge-LLM	TensorRT-LLM	vLLM	llama.cpp
Modèle d’exécution	AOT (compilation d’engines)	AOT/JIT hybride	JIT	JIT
Cible principale	Edge, mono-nœud, SoC	Datacenter, multi-GPU	Serveur GPU	CPU/GPU variés
Runtime	C++ léger	Python/C++ lourd	Python	C/C++
Quantification	NVFP4, FP8, INT4 (selon cible)	FP8, FP4, INT4/8	FP8, AWQ, GPTQ…	GGUF (K-quants, IQ…)
Portabilité embarqué	Jetson Thor, DRIVE AGX Thor, IGX Thor (annoncée)	Non	Non	Partielle
Flexibilité modèles	Limitée au support natif	Large	Très large	Très large

Ce tableau mérite un avertissement : les colonnes concurrentes sont qualitatives. Aucune donnée chiffrée de latence ou de débit comparant ces runtimes sur GB10 n’apparaît dans les sources disponibles. On ne peut donc pas écrire « Edge-LLM est 2× plus rapide que vLLM sur Spark » — ce serait inventer.

---

NVFP4, DSpark et mémoire unifiée : les trois leviers qui font la différence sur GB10

Trois mécanismes portent l’essentiel du gain annoncé. Examinons-les séparément, parce qu’ils n’ont ni la même nature ni le même risque.

NVFP4. Le format de quantification FP4 de NVIDIA divise par rapport au FP16 l’empreinte des poids et des activations, ce qui est la condition sine qua non pour faire tenir un modèle de 30 milliards de paramètres dans un budget mémoire raisonnable sur 64 Go. Mais la quantification 4 bits n’est pas gratuite : elle exige une calibration sur un jeu de données représentatif, et le risque de dégradation pèse surtout sur les tâches de raisonnement, où les activations ont une distribution large. NVIDIA ne publie pas, dans les éléments dont nous disposons, d’évaluation de qualité post-quantification sur des benchmarks de raisonnement — seulement des mesures de débit et de latence. C’est un angle mort majeur.

DSpark. Il s’agit du speculative decoding maison : le runtime génère 3 draft tokens, les vérifie en parallèle, et accepte ceux qui correspondent à la distribution du modèle cible. Le gain annoncé se situe entre 1,5 et 1,7× en tokens par seconde selon les charges. Le compromis classique du speculative decoding s’applique : on améliore le débit de génération, mais on ajoute une passe de vérification qui peut légèrement dégrader le time-to-first-token. Les chiffres publiés confirment d’ailleurs cette stabilité du TTFT plutôt qu’une amélioration.

Mémoire unifiée. C’est le point le plus intéressant techniquement. Sur GB10, CPU et GPU partagent le même espace mémoire physique. Un runtime naïf va copier les poids du CPU vers le GPU, doublant l’empreinte. Le runtime Edge-LLM, lui, gère explicitement cette mémoire unifiée pour éviter les copies. Le résultat rapporté : un pic de mémoire système de 27,9 Go pendant l’inférence avec DSpark, système d’exploitation inclus, sur une machine de 64 Go sous DGX OS 7.6.0 (Ubuntu 24.04.4 LTS). Cela laisse une marge confortable — mais il faut noter que ce chiffre agrège OS, runtime et modèle. La part imputable au seul modèle n’est pas isolée, ce qui rend toute extrapolation vers d’autres modèles hasardeuse.

Pour le fine-tuning, ces choix ont des conséquences concrètes. Un LoRA classique s’entraîne sur des poids en précision plus élevée ; fusionner un adaptateur dans un modèle quantifié NVFP4 puis recompiler un engine est possible mais impose de repasser par la chaîne de calibration et de build. QLoRA, qui quantifie le modèle de base pendant l’entraînement, est conceptuellement plus proche de cette logique — mais les sources ne documentent pas de support explicite des adaptateurs dans le workflow Edge-LLM. Prudence, donc : la compatibilité des adaptateurs n’est pas précisée.

---

Les chiffres de NVIDIA passés au crible : 73 tok/s sans DSpark, 127 tok/s avec, et après ?

Venons-en aux chiffres. Ils sont précis, cohérents en interne, et tous issus du benchmarking interne de NVIDIA sur son propre matériel et son propre logiciel. La source qui les relaie reconnaît elle-même qu’il faut les lire comme des chiffres « vendor ».

Conditions de test : NVFP4, thinking activé, batch size 1, une seule requête streaming concurrente, limite de sortie à 128 tokens, DSpark configuré avec 3 draft tokens.

Charge	DSpark OFF — TTFT médian	DSpark OFF — débit	DSpark ON — TTFT médian	DSpark ON — débit
SpeedBench 1K	201,0 ms	73,3 tok/s	203,0 ms	108,5 tok/s
SpeedBench 2K	329,5 ms	72,8 tok/s	331,6 ms	105,3 tok/s
HumanEval	98,1 ms	73,4 tok/s	98,7 ms	126,9 tok/s

Plus le pic mémoire : 27,9 Go avec DSpark, OS inclus.

Que disent vraiment ces chiffres ? D’abord, une stabilité remarquable du débit sans DSpark : entre 72,8 et 73,4 tok/s selon la charge, soit une variation inférieure à 1 %. C’est la signature d’un runtime déterministe, où la performance ne dépend pas de l’humeur d’un ordonnanceur JIT. Ensuite, un TTFT qui triple presque entre HumanEval (98 ms) et SpeedBench 2K (330 ms) : logique, le prefill croît avec la longueur du prompt. Enfin, un gain DSpark qui varie de 1,44× (2K) à 1,73× (HumanEval) — l’écart s’explique probablement par la nature des sorties générées, le code étant plus prévisible donc plus facile à spéculer.

Ce que ces chiffres ne disent pas est tout aussi important. Pas de batch supérieur à 1 : impossible de savoir comment le système se comporte sous charge concurrente, ce qui est précisément le cas d’usage d’un serveur d’agents. Pas de contexte au-delà de 2K : la dégradation mémoire sur des fenêtres longues n’est pas documentée. Pas de consommation électrique, alors que c’est un critère central pour un déploiement edge — un tok/s/W serait autrement plus informatif qu’un tok/s brut. Pas de MLPerf Edge, pas de reproduction tierce, pas de comparaison avec Llama, Qwen ou Mistral sur la même machine.

Pour situer, les repères publies par ailleurs dans notre suivi donnent un ordre de grandeur : sur un DGX Spark unique, llama.cpp atteindrait jusqu’à 67 tok/s sur un modèle 35B-A3B, et un DeepSeek-V4-Flash en IQ2_XXS tournerait autour de 14 tok/s en single-stream. Les 73 tok/s de Nemotron 3.5 Lightning en NVFP4 se situent donc dans le haut de ce qu’on peut attendre d’une Spark — mais avec un modèle différent, dans des conditions différentes, et sans mesure croisée. La prudence reste de mise.

---

Du prototype au cluster : ce que change TensorRT Edge-LLM pour le fine-tuning et l’inférence sur une ou plusieurs Spark

Passons aux scénarios réels. Trois familles d’usage se dessinent.

L’inférence locale à faible latence pour agents autonomes. C’est le cœur de cible. Un TTFT de 98 à 330 ms selon la charge, un débit de 73 à 127 tok/s, une empreinte de 27,9 Go : voilà de quoi faire tourner un agent qui enchaîne les appels d’outils sans latence rédhibitoire. La limite, encore une fois, c’est le batch=1. Un agent qui parallélise cinq sous-tâches verra ses requêtes s’ordonnancer en série.

Le RAG embarqué. Un modèle de 30B avec un contexte de 2K testé, ce n’est pas un RAG documentaire ambitieux. Les chiffres publiés ne couvrent pas les contextes longs, et c’est précisément là que la mémoire unifiée devient critique : le cache KV croît linéairement avec la longueur. Sur 64 Go, avec 27,9 Go déjà consommés, la marge existe mais n’est pas infinie.

Le traitement de flux vidéo. C’est le cas d’usage qui justifie la portabilité vers Jetson Thor. On développe sur Spark, on déploie sur Thor : le même framework, le même engine, la même API. C’est un argument d’ingénierie sérieux, même s’il n’est étayé par aucune donnée de performance sur Thor dans les sources disponibles.

Reste la question du fine-tuning et du clustering, deux sujets où la documentation manque.

Sur le fine-tuning : les sources ne précisent pas où se fait l’entraînement dans le workflow Edge-LLM, ni comment les adaptateurs LoRA/QLoRA sont fusionnés puis recompilés. On peut raisonnablement supposer un cycle entraînement → fusion → calibration → build, mais c’est une inférence de notre part, pas un fait documenté.

Sur le clustering : le débat « deux petits plutôt qu’un gros » agite la communauté depuis le lancement du 64 Go. Les repères dont nous disposons donnent deux Sparks à 405 milliards de paramètres maximum, avec un pool de cache KV partagé de 1 105 096 tokens, et un débit agrégé d’environ 350 tok/s à concurrence 32 sur DeepSeek-V4-Flash FP8 en TP=2 via vLLM. Mais ces chiffres concernent vLLM, pas Edge-LLM. Rien dans les sources n’indique que TensorRT Edge-LLM supporte le tensor parallelism multi-nœuds. C’est une limite potentielle majeure pour qui veut passer à l’échelle.

---

Les pièges de la conversion : calibration, versions, et dépendances qui piquent

Il faut être franc : ce workflow, en l’état, est un chantier.

Les versions. La stack testée aligne TensorRT Edge-LLM 0.11.1, TensorRT 10.16.1.11, CUDA 13, Python 3.10 à 3.12, sur DGX OS 7.6.0 (Ubuntu 24.04.4 LTS). Ce sont des versions très récentes, et c’est précisément le problème : la reproductibilité en souffre. Un pip install qui résout une version légèrement différente de TensorRT peut invalider un engine, casser une API, ou produire des résultats subtilement faux. Pour un déploiement en production, il faut épingler chaque version et geler l’environnement.

Le coût initial. 21 Go de téléchargement au premier lancement, plus le temps de build des engines. Ce dernier n’est pas documenté en valeur absolue, mais la compilation TensorRT d’un modèle de 30B n’est jamais instantanée. Le cache d’engines amortit ce coût — à condition que l’engine soit portable entre machines. Or ce n’est pas garanti : un engine compilé pour une version de TensorRT et un GPU donnés n’est pas nécessairement valide ailleurs. La question « mon cache est-il portable ? » doit être posée avant tout déploiement multi-nœuds.

La calibration. C’est le piège le plus insidieux. La quantification NVFP4 exige un jeu de données représentatif de la distribution réelle des entrées. Un jeu de calibration mal choisi — trop générique, ou au contraire trop étroit — dégrade silencieusement la qualité. Et cette dégradation est difficile à détecter : les benchmarks de débit ne la voient pas.

Les questions à se poser avant de se lancer. Le modèle visé est-il supporté nativement ? Existe-t-il une version NVFP4 pré-quantifiée et pré-calibrée (comme c’est le cas pour Nemotron 3.5 Lightning) ? Mon cas d’usage tolère-t-il un batch de 1 ? Mon contexte dépasse-t-il 2K ? Ai-je besoin de plusieurs modèles simultanément — auquel cas Edge-LLM, mono-modèle par engine, n’est pas l’outil ?

Les alternatives existent : vLLM pour la flexibilité et le tensor parallelism, llama.cpp pour la compatibilité GGUF et la simplicité, MLC pour l’approche compilée multi-cibles. Aucune n’offre la portabilité Thor ni le déterminisme d’Edge-LLM, mais toutes offrent une souplesse que le workflow NVIDIA n’a pas.

---

Qui doit vraiment adopter TensorRT Edge-LLM en 2026 ? Verdict nuancé

Tranchons.

Adoptez si vous déployez en production sur du matériel NVIDIA contraint — Jetson Thor, DRIVE AGX Thor, IGX Thor — et que vous avez besoin d’une latence déterministe et d’une empreinte mémoire maîtrisée. Adoptez si votre modèle est dans la liste supportée, si votre charge est mono-modèle, si votre batch reste faible, et si vous avez les compétences pour gérer une chaîne de compilation et une calibration. Adoptez, enfin, si le gain de performance justifie l’investissement : sur un déploiement edge critique ou à fort volume, l’écart entre 73 et 127 tok/s peut changer l’expérience utilisateur.

N’adoptez pas encore si vous prototyper, si vous explorez plusieurs modèles, si vous faites de la recherche, ou si vous avez besoin de batch élevé et de contextes longs. vLLM et llama.cpp restent plus flexibles, plus documentés, et bénéficient d’une communauté qui a déjà résolu la plupart des problèmes que vous allez rencontrer. N’adoptez pas non plus si vous ne pouvez pas vous permettre le verrouillage : formats propriétaires, support limité aux GPU NVIDIA, dépendance à une version précise de TensorRT.

Le point aveugle reste l’absence de benchmarks indépendants. Artificial Analysis a bien lancé le 29 septembre 2026 un outil, AA-AgentPerf-Local, qui mesure la vitesse des agents IA locaux sur DGX Spark, Ryzen AI Halo, MacBook Pro M5 Pro et RTX 5090 — mais sur quatre modèles open weight, et sans mention de TensorRT Edge-LLM. Tant que personne n’aura reproduit le workflow NVIDIA et publié des chiffres contradictoires ou confirmatoires, il faut traiter les 127 tok/s comme une promesse crédible mais non vérifiée.

---

Après le 30 octobre : ce que cette annonce change pour l’écosystème edge et les prochains mois

Deux mouvements se dessinent.

Le premier est la consolidation de l’offre logicielle NVIDIA autour du DGX Spark comme plateforme de développement edge. La logique est cohérente : on vend du GB10 pour développer, du Thor pour déployer, et un framework unique pour faire le pont. C’est une stratégie d’écosystème classique, et elle a fait ses preuves ailleurs. Le DGX Spark 64 Go à 4 999 dollars, commercialisé depuis le 23 octobre, devient la porte d’entrée d’une chaîne qui mène jusqu’aux SoC embarqués.

Le second est la pression sur les runtimes open source. Si TensorRT Edge-LLM tient ses promesses, vLLM et llama.cpp devront répondre sur le terrain du déterminisme et de l’empreinte mémoire sur GB10. On peut parier que des efforts seront faits — mais rien ne garantit qu’ils aboutiront à parité, tant la compilation AOT est structurellement avantagée pour des charges figées.

Les questions ouvertes sont nombreuses. Le support d’autres modèles — Llama, Qwen, Mistral — en NVFP4 arrivera-t-il, et à quel rythme ? Des benchmarks indépendants seront-ils publiés ? Une version 1.0 de TensorRT Edge-LLM verra-t-elle le jour, avec un support du tensor parallelism multi-nœuds ? Le portage vers Thor tiendra-t-il ses promesses de performance ?

Une chose est sûre : la compilation ahead-of-time et la quantification ne sont plus des options exotiques. Elles deviennent la norme pour l’inférence edge. Les équipes qui veulent déployer sur du matériel contraint en 2027 feraient bien de commencer à se familiariser dès maintenant avec cette chaîne — ne serait-ce que pour comprendre ce qu’elles gagnent, et ce qu’elles perdent.

---

Sources

• NVIDIA details edge AI workflow for DGX Spark and TensorRT Edge-LLM — blockchain.news
• NVIDIA Announces DGX Spark 64GB: A 1-PetaFLOP Grace Blackwell Desktop for Local AI Agents, Fine-Tuning, and Inference — MarkTechPost
• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blogs.nvidia.com
• DGX Spark Software Updates — October 2026 Release — NVIDIA Developer Forums
• DGX Spark Release Notes — NVIDIA Documentation
• OS and Component Update Guide — DGX Spark User Guide
• Nvidia lance le DGX Spark en 64 Go : faut-il acheter deux petits plutôt qu’un gros ? — Frandroid
• AA-AgentPerf-Local: Benchmarking local AI agents on laptops and workstations — Artificial Analysis
• DGX Spark Benchmarks: Which Local Model Wins in 2026 — tokenstead.ai
• Best LLM for a single DGX Spark as of Sep 2026 — Reddit r/LocalLLM