NVIDIA explique TensorRT Edge-LLM sur DGX Spark et publie ses propres mesures de vitesse de décodage DSpark

Un tutoriel technique de NVIDIA daté du 30 octobre 2026 décrit le prototypage local d'applications pour la périphérie avec TensorRT Edge-LLM sur un DGX Spark de 64 Go. « Edge » désigne ici les systèmes périphériques, pas un qualificatif de modèle « de pointe ». L'exemple emploie Nemotron-3.5 Lightning 30B-A3B NVFP4, un modèle uniquement textuel. L'outil trtedge télécharge ce modèle, construit un moteur TensorRT, ouvre une conversation en terminal puis sert une API locale. L'article comprend des chiffres de performance mesurés par NVIDIA ; ce média n'a pas réalisé de test indépendant et ces chiffres ne couvrent pas tous les modèles visuels, vocaux ou robotiques évoqués comme pistes possibles.

Les prérequis sont un DGX Spark doté d'une pile logicielle compatible, CUDA 13, TensorRT 10.16.1.11 ou plus récent dans la branche 10.x et Python 3.10 à 3.12. NVIDIA dit avoir testé les étapes avec TensorRT Edge-LLM 0.11.1 et TensorRT 10.16.1.11. Le tutoriel crée un environnement virtuel pouvant voir les paquets système, installe la version fixée avec son supplément server, vérifie la version de TensorRT et charge le runtime. Des liaisons Python incompatibles peuvent empêcher le démarrage ; le billet renvoie alors aux instructions d'installation de TensorRT. Les commandes concernent l'ordinateur du lecteur et n'ont pas été exécutées par ce média.

Le premier lancement de trtedge chat télécharge le modèle choisi et construit le moteur. NVIDIA estime le téléchargement initial à environ 21 Go. Les fichiers et moteurs sont placés par défaut dans un cache de l'utilisateur, et les exécutions ultérieures réutilisent les moteurs correspondant à la configuration. Le dialogue de démonstration demande la conversion de 25 °C en degrés Fahrenheit et montre 77 °F comme réponse. C'est un exemple de fonctionnement, pas une évaluation de précision sur plusieurs tâches. Après avoir quitté le dialogue, trtedge serve ouvre une API de chat compatible OpenAI sur l'adresse de boucle locale 127.0.0.1 et le port 8000. Le tutoriel vérifie d'abord que le point de santé répond ready, puis envoie une requête en flux. Cette adresse reste locale tant que l'opérateur ne change pas volontairement la configuration réseau.

Une étape facultative redémarre le serveur avec le décodage spéculatif DSpark. Un modèle de brouillon propose des jetons que le modèle principal valide en groupe ; l'exemple en configure trois. C'est une optimisation de la vitesse de génération du texte, pas une production d'électricité ni le remplacement du modèle principal. On peut régler le nombre de jetons proposés selon la charge. Le billet ne garantit pas que tous les modèles ni toutes les machines embarquées prennent en charge cette configuration. Il faut vérifier la liste des modèles et les exigences propres à la plateforme avant d'étendre les conclusions de l'essai sur Spark.

Dans son tableau pour DGX Spark 64 Go, NVIDIA rapporte la médiane du délai avant le premier jeton et la vitesse moyenne de génération. SpeedBench 1K affiche 201,0 ms et 73,3 jetons/s sans DSpark, contre 203,0 ms et 108,5 jetons/s avec. SpeedBench 2K affiche 329,5 ms et 72,8 jetons/s, contre 331,6 ms et 105,3 jetons/s. Les invites HumanEval affichent 98,1 ms et 73,4 jetons/s, contre 98,7 ms et 126,9 jetons/s. La vitesse de génération exclut le délai du premier jeton. L'augmentation du débit de décodage dans ces lignes ne signifie donc pas que la première réponse arrive plus tôt.

Les conditions de mesure sont précises : DGX OS 7.6.0 basé sur Ubuntu 24.04.4, NVFP4, mode thinking activé, lot d'une requête, un seul flux concurrent et sortie limitée à 128 jetons. Les longueurs d'entrée moyennes étaient respectivement de 1 153, 2 247 et 139 jetons. NVIDIA annonce 27,9 Go de mémoire système maximale avec DSpark, système d'exploitation compris. D'autres modèles, niveaux de concurrence, tailles de réponse ou matériels périphériques peuvent produire d'autres résultats. L'intérêt pratique est une procédure documentée de la conversation locale à l'API locale, avec une expérience optionnelle de décodage, dont les performances restent celles du banc d'essai déclaré par le fournisseur.