NVIDIA: Nemotron 3.5 Lightning (free)

NVIDIA Nemotron 3.5 Lightning est un modèle de langage destiné au raisonnement, à la conversation et aux procédures d’agents spécialisés. Il compte 30 milliards de paramètres au total, dont 3 milliards de paramètres actifs, et utilise une architecture hybride qui entrelace des couches Mamba-2, de mélange d’experts et d’attention. Des couches Multi-Token Prediction ajoutent des signaux d’entraînement pour les tokens futurs et prennent en charge les méthodes optimisées de génération du modèle. Le modèle traite du texte et produit du texte, notamment des explications, du code et des réponses fondées sur les documents fournis.

Le fabricant décrit des applications dans les agents conversationnels, la génération augmentée par récupération, le suivi d’instructions et les agents. Pour une réponse issue d’une base de connaissances, fournissez la question et les passages pertinents avec des étiquettes de source stables. Demandez au modèle de répondre à partir de ces passages, d’identifier celui qui étaye chaque affirmation importante et d’indiquer ce qui reste inconnu. Par exemple : « À l’aide de ces articles d’assistance, expliquez la différence entre les deux méthodes d’installation et présentez les prérequis, les étapes et les vérifications de chacune. » Gardez visible tout prérequis manquant plutôt que d’inciter le modèle à l’inventer.

Pour un travail de programmation, fournissez le code pertinent, le comportement attendu et l’échec observé. Une demande pratique vise une révision ciblée et une explication des cas concernés. Si un agent relié à des outils exécute une vérification, renvoyez sa sortie réelle avant de demander la modification suivante. L’entraînement du modèle comprend le code, l’utilisation d’outils en plusieurs étapes et les tâches à sortie structurée, mais le livrable terminé doit toujours correspondre à l’exigence d’origine. Demandez le code révisé, la raison de chaque modification substantielle et les observations nécessaires pour établir que le problème est résolu.

Le fabricant documente une réflexion activée par défaut et un mode de réponse directe dans lequel le gabarit de conversation désactive la réflexion. Le mode de raisonnement est utile pour une tâche comportant plusieurs conditions dépendantes ; une réponse directe peut convenir à une transformation ou à une extraction simple. Le fabricant recommande une température de 1.0 et un top-p de 0.95 dans ses exemples clients. Considérez-les comme des réglages de la méthode du fabricant et choisissez explicitement la structure de la réponse finale : une explication concise, un tableau comparatif ou une réponse suivie de ses éléments justificatifs, par exemple.

Le modèle prend en charge un contexte pouvant atteindre un million de tokens. Les méthodes de déploiement BF16 publiées distinguent également cette capacité du modèle des configurations utilisant une fenêtre de 256K pour respecter des contraintes de mémoire. Préparez les documents longs en fonction de la fenêtre de travail applicable, en préservant leur structure et en laissant de la place pour la réponse. Un contexte long est surtout utile lorsque la consigne précise la relation à rechercher : contradictions entre documents, dépendances entre fichiers source ou preuves étayant une conclusion. Il ne justifie pas l’inclusion d’un historique sans rapport ni l’hypothèse qu’une réponse finale puisse occuper toute la fenêtre.

L’anglais et les langages de programmation constituent les priorités principales ; l’espagnol, le français, l’allemand, l’italien et le japonais sont également cités. Indiquez la langue de sortie requise et conservez les noms, les identifiants et les termes cités des sources lorsque leur graphie compte. Pour des documents multilingues, précisez s’il faut traduire, résumer ou comparer les contenus ; ces demandes produisent des livrables différents. Demandez que les termes incertains soient signalés, afin qu’une traduction fluide ne modifie pas silencieusement un sens technique.

NVIDIA publie une version de référence BF16 principalement destinée à la personnalisation et à la recherche en pleine précision, ainsi qu’une version NVFP4 séparée avec des méthodes d’inférence optimisées. Cette distinction compte lorsque vous comparez des consignes de déploiement : une configuration matérielle ou un résultat de débit propre à une version ne décrit pas automatiquement l’autre. Le nom du modèle identifie la famille Lightning, tandis que le point de contrôle exact et la configuration de service déterminent la méthode. Distinguez les capacités du modèle des performances et des hypothèses de mémoire propres à une méthode.

Pour le travail avec des outils, fournissez des descriptions claires des fonctions et renvoyez le résultat réel de chaque étape exécutée. Une opération proposée ne devient une preuve exploitable qu’après son exécution par l’application qui l’entoure et l’enregistrement de ce qui s’est passé. Demandez à la réponse finale de distinguer les observations issues des sources, les conclusions déduites et les vérifications inachevées. Lorsqu’un calcul, une commande ou un passage récupéré contredit le résultat prévu, utilisez cette contradiction pour réviser la conclusion plutôt que de produire un résumé soigné d’une hypothèse non vérifiée.