TensorRT Edge-LLM termine le benchmark agentique MLPerf Edge 6,4 fois plus vite sur Jetson AGX Thor

NVIDIA affirme que TensorRT Edge-LLM a exécuté Qwen3.6-27B 6,4 fois plus vite sur Jetson AGX Thor, mettant en avant les gains liés au cache et à la quantification pour les agents en périphérie.

AI News

NVIDIA indique que son runtime TensorRT Edge-LLM a terminé le benchmark MLPerf Inference v6.1 Edge Agentic en 24 minutes et 36 secondes sur un seul Jetson AGX Thor Developer Kit. Cela représente une vitesse 6,4 fois supérieure à l’exécution de référence llama.cpp publiée pour le même benchmark sur la même plate-forme, selon le blog développeur de NVIDIA.

Ce résultat est important car le test mesure plus que la vitesse d’une réponse ponctuelle. Il rejoue des conversations d’agents d’ingénierie logicielle dans lesquelles un modèle génère des appels d’outils, reçoit des résultats et poursuit des contextes de plus en plus longs. La soumission de NVIDIA a exécuté Qwen3.6-27B à 52,33 tokens par seconde et a terminé les 1 007 tours générés dans la charge de travail de performance.

Les chiffres sont des résultats rapportés par le fournisseur à partir de la propre soumission de NVIDIA et ne doivent pas être considérés comme une comparaison indépendante de toutes les piles d’inférence en périphérie. Ils montrent néanmoins comment des optimisations au niveau du runtime peuvent changer l’économie d’exécuter des agents IA multi-étapes sur du matériel local plutôt que d’envoyer chaque interaction vers un centre de données cloud.

Ce que le test MLPerf a mesuré

Le benchmark MLPerf Edge Agentic évalue un endpoint de modèle compatible OpenAI dans des phases de performance et de précision. Sa charge de travail de performance contient 20 conversations enregistrées et 1 007 tours générés. À mesure que chaque agent reçoit les résultats d’outils et poursuit son raisonnement, le contexte atteint environ 23 500 tokens.

Cette structure crée un goulot d’étranglement différent de celui d’un test de chatbot classique. Un agent traite à plusieurs reprises une grande partie de la même conversation, tout en devant produire rapidement des appels de fonction valides. Recalculer l’historique complet à chaque tour peut rendre les trajectoires longues de plus en plus coûteuses, en particulier sur un appareil dont la bande passante mémoire et la puissance sont limitées.

La phase de précision utilise des prompts issus du Berkeley Function Calling Leaderboard, ou BFCL, avec des requêtes à un seul tour et le raisonnement désactivé. Elle vérifie si le modèle sélectionne la fonction appropriée, fournit des arguments valides ou refuse correctement d’appeler un outil. NVIDIA indique que sa soumission a tourné en mode SingleStream sur un Jetson AGX Thor Developer Kit avec 128 Go de mémoire unifiée, en mode d’alimentation MAXN de la plate-forme.

L’ingénierie derrière le résultat de NVIDIA

NVIDIA attribue le résultat à plusieurs optimisations dans TensorRT Edge-LLM plutôt qu’à une seule caractéristique matérielle. Le modèle Qwen3.6-27B soumis utilisait NVFP4 pour les poids et les activations, y compris la tête du modèle de langue, ainsi que FP8 pour son cache clé-valeur, ou KV cache.

NVFP4 est un format flottant sur quatre bits pris en charge par le GPU Blackwell dans Jetson AGX Thor. Des représentations de précision plus faible réduisent la quantité de données que les kernels doivent déplacer à travers la mémoire, un élément important pour le décodage à faible batch, que NVIDIA décrit comme fortement contraint par la bande passante DRAM sur les plates-formes edge. La représentation plus compacte laisse également davantage de mémoire unifiée de l’appareil pour le contexte, l’état de décodage spéculatif et d’autres tâches applicatives.

Le runtime a aussi réutilisé l’état de conversation mis en cache entre les tours. NVIDIA affirme qu’environ 96 % des tokens de prompt ont été servis depuis le cache chaud sur l’ensemble de la trajectoire de l’agent. Au lieu de préremplir les 13,6 millions de tokens de prompt rencontrés pendant le benchmark, le système n’a prérempli qu’environ 0,5 million de tokens de nouveaux suffixes de conversation.

Cette optimisation est particulièrement pertinente pour les charges de travail d’agents. Chaque nouveau tour contient la majeure partie de la conversation précédente, plus un résultat d’outil ou une réponse du modèle. TensorRT Edge-LLM identifie les préfixes de prompt réutilisables et restaure les pages d’attention mises en cache. Parce que Qwen3.6 utilise une architecture de modèle hybride, NVIDIA indique que le runtime restaure également l’état récurrent et l’état partiel des pages KV nécessaires pour poursuivre correctement l’exécution.

Pour la génération de tokens, NVIDIA a utilisé la prédiction multi-token basée sur des arbres. La configuration utilisait un arbre de vérification à huit étapes, top-two, 16 nœuds, et a apporté une amélioration d’environ 40 % du décodage par rapport à la prédiction multi-token linéaire pour la charge de travail de fonction-calling, selon l’entreprise.

Preuves, comparaison et limites

La comparaison centrale oppose la soumission TensorRT Edge-LLM de NVIDIA à l’exécution de référence llama.cpp publiée via l’exemple MLCommons Edge Agentic. Les deux exécutions utilisaient Qwen3.6-27B sur Jetson AGX Thor, mais la référence utilisait une quantification Q4_K_M, tandis que la soumission de NVIDIA utilisait NVFP4 et d’autres techniques de runtime.

NVIDIA indique que l’exécution llama.cpp a pris deux heures et 37 minutes pour terminer la même charge de travail. Le résultat TensorRT Edge-LLM a pris 24 minutes et 36 secondes. La différence reflète donc l’ensemble de la pile logicielle, les choix de quantification, la gestion du cache et la stratégie de décodage — et pas simplement une mesure directe d’un format de modèle par rapport à un autre.

Le benchmark n’établit pas non plus que le système sera 6,4 fois plus rapide dans toutes les applications d’agents. Les résultats peuvent varier selon l’architecture du modèle, la longueur du contexte, les schémas d’appels d’outils, la qualité de la quantification, les réglages de puissance et la quantité de travail parallèle. Le gain d’environ 40 % de NVIDIA en prédiction multi-token est également une affirmation spécifique à la charge de travail, liée à la configuration de function-calling rapportée.

Les éléments disponibles sont les plus solides sur le temps d’achèvement et les tokens par seconde dans ce benchmark défini. Ils sont plus faibles concernant la fiabilité en production, la consommation d’énergie, le comportement thermique lors de déploiements prolongés et les compromis de précision dans des tâches d’agent plus larges. NVIDIA indique que les développeurs peuvent examiner la branche TensorRT Edge-LLM release/0.9.1-mlpinf, utiliser son checkpoint calibré Qwen3.6-27B NVFP4 et consulter l’exemple MLCommons pour les détails de configuration, mais ces éléments ne constituent pas en eux-mêmes une preuve indépendante d’adoption.

Pourquoi ce résultat compte pour les créateurs d’IA en périphérie

Pour les développeurs qui intègrent des agents IA dans des véhicules, des robots, des équipements industriels ou d’autres systèmes embarqués, ce résultat soulève une question pratique de déploiement : quelle part du contexte répété d’un agent peut être conservée localement et réutilisée ? La réutilisation du cache peut réduire le travail de préremplissage sans modifier le flux de conversation de l’application, tandis que la prédiction multi-token cible la phase de génération qui suit les réponses des outils.

Les économies de mémoire peuvent être aussi importantes que la vitesse brute. Un modèle de 27 milliards de paramètres fonctionnant dans un format de faible précision a toujours besoin d’espace pour de longs contextes, l’état du runtime et la logique applicative. L’utilisation par NVIDIA de 128 Go de mémoire unifiée suggère que les déploiements edge pourraient de plus en plus être conçus autour de l’empreinte combinée du modèle et de l’agent, et non du modèle seul.

Pour les acheteurs en entreprise, le benchmark indique que l’inférence locale d’agents devient plus viable pour les flux de travail où la latence, la connectivité ou le contrôle des données comptent. Il ne supprime pas la nécessité d’évaluer la consommation électrique, la précision du modèle, la fiabilité des appels d’outils, les processus de mise à jour et les contrôles de sécurité dans l’environnement cible. Un benchmark plus rapide n’est utile que si l’agent peut prendre des décisions correctes et fonctionner de manière cohérente dans des contraintes matérielles réelles.

Ce résultat accentue aussi la pression concurrentielle sur les runtimes alternatifs. L’avantage de TensorRT Edge-LLM ici vient de la coordination étroite entre le logiciel NVIDIA et le matériel Blackwell. Les développeurs utilisant d’autres accélérateurs devront disposer d’un support comparable pour les kernels de faible précision, l’état de contexte persistant et le décodage spéculatif ou basé sur des arbres s’ils veulent des performances similaires sur de longues trajectoires d’agents.

Ce qu’il faut surveiller ensuite

Les prochains signaux utiles seront des reproductions indépendantes du résultat MLPerf, en particulier des comparaisons qui rapportent la consommation d’énergie, les limites thermiques et la précision en plus du temps d’achèvement. Il sera également important de voir si la réutilisation du cache reste efficace sur des charges de travail avec un contexte moins répétitif ou des sorties d’outils plus variées.

Les développeurs devraient surveiller la branche de publication TensorRT Edge-LLM et l’exemple MLCommons Edge Agentic pour des mises à jour du support modèle, des instructions de compilation et des soumissions matérielles supplémentaires. Des tests plus larges de Qwen3.6-27B NVFP4 aideront à clarifier si les performances rapportées sont pratiques pour des agents de production ou limitées aux trajectoires enregistrées du benchmark.

Enfin, des preuves provenant de véhicules, de robots et de systèmes industriels déployés offriraient un test plus solide de l’approche. Ces environnements introduisent une connectivité intermittente, des budgets de puissance stricts, des entrées de capteurs, des exigences de sécurité et des mises à jour logicielles que le benchmark actuel ne capture pas entièrement.

Point de vue de Creati.ai

Le résultat de NVIDIA s’interprète mieux comme une démonstration système : les performances des agents en périphérie dépendent autant de l’évitement du travail répétitif que de l’augmentation de la vitesse brute de génération. La combinaison de NVFP4, du cache KV FP8, de la réutilisation d’état et du décodage basé sur des arbres traite les coûts spécifiques créés par les conversations longues utilisant des outils.

Le chiffre de 6,4x est convaincant dans la configuration MLPerf rapportée, mais la conclusion plus large est plus mesurée. Pour les créateurs d’IA, la vraie question est de savoir si ces optimisations survivent à différents modèles, outils, enveloppes de puissance et exigences de précision du monde réel. Si c’est le cas, les déploiements locaux d’agents pourraient passer de démonstrations isolées à des architectures de production plus crédibles.

Publicités