Nemotron 3.5 Lightning, le modèle IA de NVIDIA pensé pour faire tourner les agents à grande échelle

Cela ne signifie pas que l’intégralité du modèle disparaît du stockage ou de la mémoire. En revanche, le calcul nécessaire à chaque génération peut être réduit. Lightning est fourni en formats BF16 et NVFP4. NVIDIA décrit également une architecture hybride réunissant traitement de type Mamba ou espace d’état, attention et experts routés.

La place de Lightning dans un agent à deux niveaux

Le scénario le plus cohérent n’est pas de faire de Lightning un chatbot isolé, mais de l’intégrer dans une pile de modèles spécialisés :

1. Un modèle de raisonnement plus puissant interprète la demande et construit le plan.
2. Lightning exécute les étapes répétitives sur les outils, les documents ou les données structurées.
3. Le grand modèle reprend la main en cas d’exception, d’incertitude ou de décision complexe.

NVIDIA oppose notamment Lightning à Nemotron 3 Ultra, un modèle MoE de 550 milliards de paramètres au total et 55 milliards de paramètres actifs, destiné au raisonnement avancé et à l’orchestration.

Cette séparation des rôles est le véritable angle du produit : Lightning n’essaie pas d’être le modèle le plus intelligent du système, mais celui qui peut traiter rapidement les milliers d’étapes ordinaires d’un agent toujours actif.

NeMo Switchyard, la pièce qui organise le routage

Une telle architecture nécessite de choisir le bon modèle pour chaque étape. C’est le rôle de NeMo Switchyard, le SDK de routage de NVIDIA conçu pour fonctionner avec différents fournisseurs.

L’outil permet de représenter les requêtes, de définir les modèles disponibles et de gérer les appels vers le fournisseur ou l’identifiant de modèle sélectionné. En pratique, une application peut donc envoyer les opérations prévisibles à Lightning et réserver un modèle plus coûteux aux demandes qui nécessitent davantage de capacités.

Le routage devient alors aussi important que le modèle lui-même. Un agent bien conçu ne pose pas systématiquement toutes ses questions au même endpoint : il distribue le travail en fonction de la difficulté, de la latence acceptable et du coût.

Contexte long et options de déploiement

Lightning est annoncé avec une capacité de contexte pouvant atteindre 1 million de tokens. Cette caractéristique peut intéresser les agents qui conservent un état sur une longue durée, parcourent de volumineux documents ou réutilisent un important historique de tâche. La capacité réellement exploitable dépendra toutefois de la configuration et de la pile de service utilisée.

Le checkpoint NVFP4 est destiné à l’inférence et s’appuie sur des noyaux NVIDIA spécialisés pour plusieurs générations de GPU compatibles. NVIDIA indique des possibilités de déploiement dans les infrastructures locales, les stations de travail, les centres de données et le cloud. Le modèle est également proposé via Hugging Face et différents services hébergés.

AWS indique pour sa part que Nemotron 3.5 Lightning est disponible dans SageMaker JumpStart, avec un déploiement possible depuis la console SageMaker ou le SDK Python. La documentation NIM de NVIDIA propose une autre voie, sous la forme d’un conteneur nécessitant notamment un système Ubuntu 22.04 LTS ou ultérieur, CUDA 12.9 ou plus récent, un pilote 580 ou ultérieur et Docker.

Il faut néanmoins rester prudent avec l’expression « mono-GPU ». La faisabilité dépend du GPU utilisé, de la mémoire disponible, de la longueur du contexte, de la quantification, de la taille des lots et du logiciel de service. Un checkpoint quantifié rend le déploiement plus accessible, mais ne garantit pas les mêmes résultats sur tous les ordinateurs portables ou de bureau.

Les promesses de vitesse doivent être lues avec précaution

NVIDIA et AWS annoncent jusqu’à quatre fois plus de débit et jusqu’à 30 % de réduction du temps d’exécution pour certains workloads d’agents. Ces chiffres sont des revendications liées à des scénarios ciblés ; ils ne constituent ni une mesure universelle de l’intelligence du modèle ni une garantie de performance en production.

Les résultats peuvent varier selon :

• le modèle utilisé comme référence ;
• la génération et la mémoire du GPU ;
• la taille des lots et le niveau de concurrence ;
• la longueur des prompts et du contexte ;
• la latence des outils et du réseau ;
• les paramètres de décodage ;
• le taux d’erreur acceptable pour la tâche.

Un test sérieux devra donc mesurer le workflow complet : précision des extractions, fiabilité des appels d’outils, respect des formats structurés, nombre de reprises et durée totale d’exécution. Le nombre de tokens générés par seconde ne suffit pas à juger la valeur d’un agent.

Un prix attractif, mais qui dépend du fournisseur

Le coût d’hébergement peut rendre Lightning intéressant pour les inférences à fort volume. DeepInfra l’affiche à 0,05 dollar par million de tokens en entrée et 0,20 dollar par million de tokens en sortie, avec une facturation à l’usage et sans infrastructure GPU à administrer.

Ces tarifs ne sont pas une propriété permanente du modèle. Les fournisseurs peuvent appliquer des prix différents selon la route, la précision, la mise en cache et les conditions de service. Pour comparer Lightning à un modèle plus grand, il faut donc calculer le coût total du workflow : appels d’outils, reprises, routage et requêtes finalement envoyées au modèle de raisonnement.

Verdict : un accélérateur de workflow, pas un remplaçant universel

Nemotron 3.5 Lightning se comprend mieux comme un modèle d’exécution rapide et personnalisable. Il est particulièrement adapté aux applications qui génèrent de nombreux appels similaires et dont les tâches peuvent être contraintes, spécialisées ou affinées après entraînement.

Il n’est pas présenté comme un substitut universel à un modèle d’orchestration de grande taille. La planification complexe, le jugement incertain et les décisions dont le coût d’erreur est élevé peuvent toujours nécessiter Nemotron 3 Ultra ou un autre modèle de pointe.

La conclusion est donc assez simple : Lightning a surtout du sens comme couche basse latence d’une architecture d’agents à plusieurs modèles. Ses 30 milliards de paramètres totaux, ses quelque 3 milliards de paramètres actifs, ses matériaux ouverts, son option d’inférence quantifiée et ses multiples voies de déploiement sont conçus pour rendre le travail courant des agents plus rapide et moins coûteux. Les gains annoncés sont prometteurs, mais devront être vérifiés sur chaque workflow avant toute généralisation en production.