NVIDIA publie Nemotron 3.5 Bolt E4B : 4 Go et 133 tokens par seconde sur RTX 5070

NVIDIA a publié les poids de Nemotron 3.5 Bolt E4B, le plus compact de la gamme Nemotron 3.5, conçu pour tourner en local sur les cartes graphiques GeForce RTX, les cartes Jetson et les mini-PC Spark. Quantifié en 4 bits, il occupe environ 4 Go de mémoire, produit 133 tokens par seconde sur une RTX 5070 et affiche le premier token en 548 ms. Cette sortie intervient un peu plus d'une semaine après l'annonce du modèle multimodal Nemotron 3.5 Super VL et de sa version compressée Bolt de 74 Md de paramètres. NVIDIA avait alors promis aussi un petit modèle : il est désormais en accès libre.

Non pas une compression du grand modèle, mais un affinage de

Gemma

E4B n'a pas la même origine que le Bolt de grande taille. La version à 74 Md de paramètres est issue de la compression de Super VL. Le petit modèle, lui, repose sur Gemma 4 E4B de Google : NVIDIA l'a affiné par apprentissage par renforcement pour le suivi d'instructions, l'appel d'outils en plusieurs étapes et le dialogue.

Le modèle compte 8 Md de paramètres au total, mais 4 Md travaillent sur chaque token. Le contexte atteint 64 000 tokens et 35 langues sont prises en charge. Le raisonnement peut être activé ou désactivé, et sa longueur limitée pour gagner en vitesse. Pour l'utilisateur d'un modèle local, c'est un levier important : la chaîne de raisonnement consomme des tokens et du temps, et sur un matériel modeste, il est souvent plus judicieux de la raccourcir.

Ce que montrent les mesures, et où le modèle perd

Selon NVIDIA, Bolt E4B est en moyenne 40 % meilleur que le précédent Nemotron 3 Nano 4B et consomme jusqu'à 80 % de tokens en moins par réponse. Il devance presque partout Gemma 4 E4B, son modèle parent. Tous ces chiffres proviennent de mesures de l'entreprise elle-même ; aucune vérification indépendante n'existe pour l'instant.

Qwen3.5 4B reste plus performant. Pour l'usage d'outils sur Tau2-Bench (benchmark de dialogues agentiques avec appel de fonctions), il obtient 61,7 contre 52,3 pour le nouveau venu. En contexte long sur RULER (série de tâches de recherche et d'exploitation d'informations dans un long texte), l'écart est tout aussi net : 95,4 contre 85,8. Si vous avez besoin d'un tool calling fiable ou du traitement de longs documents sur un petit modèle, le choix de Bolt E4B n'a rien d'évident.

La vitesse dépend fortement du matériel. Sur la carte Jetson Orin Nano, il faut attendre 5,8 secondes le premier token, puis le débit est de 15,5 tokens par seconde. C'est des dizaines de fois plus lent qu'un démarrage sur RTX 5070 en termes de latence, et près de neuf fois plus lent en débit. Pour un assistant interactif sur Orin Nano, un tel temps de réponse peut s'avérer juste.

Modèles brouillons DFlash et prise en charge dans les runtimes

Avec les poids en BF16 et GGUF, NVIDIA a publié des modèles auxiliaires distincts, des brouillons conçus selon la méthode DFlash. Ils proposent d'un coup plusieurs tokens suivants, que le modèle principal vérifie. D'après NVIDIA, cela apporte jusqu'à 21 % de vitesse supplémentaire. Avec cette approche, la qualité des réponses reste déterminée par le modèle principal, et le gain vient de la vérification en parallèle.

Le modèle est déjà pris en charge dans llama.cpp, Ollama, LM Studio, vLLM et SGLang : il peut donc tourner aussi bien sur un portable que dans une pile serveur, sans adaptation spécifique. La licence est OpenMDW 1.1. Les poids sont accompagnés d'un billet de blog et d'un rapport technique.

Pour les praticiens, la conclusion est la suivante. Bolt E4B semble un bon candidat pour les applications sur RTX et Spark qui exigent une réponse rapide, du multilinguisme et un raisonnement contrôlable, avec seulement 4 Go de mémoire. Pour les scénarios à chaînes agentiques lourdes ou à contexte long, mieux vaut d'abord tester le modèle sur vos propres tâches et le comparer à Qwen3.5 4B. Quant au Jetson Orin Nano, vérifiez la latence réelle avant toute mise en production.