Nemotron 3.5 Embed 1B BF16 : analyse des capacités, limites et coûts

Ce que fait le modèle exact

Nemotron 3.5 Embed 1B BF16 est un modèle d'embeddings de 1,55 milliard de paramètres développé par NVIDIA pour la récupération de documents multimodale et multilingue. Contrairement à ses prédécesseurs purement textuels, ce modèle accepte en entrée des documents sous forme d'image, de texte ou d'une combinaison des deux, tandis que les requêtes de recherche sont limitées exclusivement au texte.

L'architecture combine un encodeur visuel Pixtral, initialisé à partir de Ministral-3-3B-Instruct-2512-BF16, avec un modèle de langage initialisé depuis Nemotron-3-Embed-1B-BF16. Lors du processus de distillation depuis le modèle maître Nemotron-3.5-Embed-8B-BF16, la composante de langage a été maintenue figée, ce qui signifie que l'espace d'embeddings textuel est identique à celui de Nemotron 3 Embed 1B, mais avec l'ajout de capacités de récupération visuelle.

La distinction entre les entrées documentaires et les requêtes définit l'usage prévu du modèle : une requête est représentée uniquement par du texte, tandis que le document récupérable peut fournir des informations textuelles, visuelles ou des deux types. Par conséquent, le composant visuel élargit la classe de documents pouvant être indexés, mais ne transforme pas la recherche en une interaction avec des requêtes d'image. Le modèle produit des représentations vectorielles pour comparer les requêtes aux documents au sein d'un système de récupération.

Le nombre de paramètres varie selon que les couches d'embedding soient comptées ou non. Le chiffre total de 1,55 milliard inclut ces couches ; le chiffre de 1,286 milliard se réfère aux paramètres d'inférence et les exclut. La dimension de sortie indiquée est de 2048, avec des options dynamiques entre 128 et 2048. Cette flexibilité permet de choisir la longueur du vecteur, bien que les informations décrites ici n'établissent pas quelle dimension offre le meilleur résultat pour chaque ensemble de données ou tâche.

Le contexte maximal de 32 768 jetons est réparti entre le texte et la représentation des images. Par conséquent, la capacité totale n'équivaut pas à 32 768 jetons de texte plus une quantité supplémentaire pour les images : les deux types d'entrée concourent pour la même limite. La fiche distingue également l'évaluation linguistique des modalités : elle informe de 34 langues de texte et 18 langues d'image évaluées, sans que ces chiffres impliquent une performance identique pour toutes les langues.

Capacités et exemples par tâche

Le modèle est conçu pour les flux de travail RAG (Retrieval-Augmented Generation) et la recherche sémantique où les documents ne sont pas seulement du texte brut, mais des pages PDF, des infographies ou des tableaux scannés. La capacité de traiter directement l'image de la page permet de capturer des informations structurelles et visuelles qui seraient perdues lors d'une extraction OCR traditionnelle.

Pour les requêtes, le modèle utilise un préfixe 'query:' et pour les documents un préfixe 'passage:'. Cette distinction est cruciale pour les performances, car le modèle a été entraîné pour traiter de manière asymétrique l'intention de recherche par rapport au contenu du document. Les images sont traitées avec un côté le plus long de 1 120 pixels par défaut, extensible jusqu'à 1 540 pixels, ce qui affecte directement la consommation de jetons du contexte.

Dans un flux de récupération, les documents sont convertis en embeddings et une requête textuelle est représentée de manière compatible pour localiser les documents les plus pertinents. Les préfixes « query: » et « passage: » indiquent au modèle quel rôle chaque texte remplit parmi ces deux. Ils ne sont pas des étiquettes interchangeables : la préparation des requêtes et des documents suit l'asymétrie pour laquelle le système a été entraîné. Omettre ou modifier ces préfixes peut écarter l'entrée du format montré, il convient donc de les conserver lors de la reproduction de l'exemple.

L'entrée visuelle permet de représenter la page comme une image au lieu de dépendre exclusivement d'une transcription OCR préalable. Cela peut préserver des relations de disposition, telles que la proximité entre les éléments ou leur organisation au sein d'un tableau, qu'une extraction de texte pourrait ne pas refléter. Cette capacité ne signifie pas que le modèle interprète toute page sans erreurs ni qu'il remplace tout processus d'extraction : elle décrit une voie d'entrée pour récupérer des documents contenant des informations visuelles et textuelles.

La taille d'image par défaut utilise un côté le plus long de 1 120 pixels et peut être étendue jusqu'à 1 540 pixels. Une image de plus grande taille peut nécessiter plus de jetons d'image et, par conséquent, laisser moins d'espace du contexte partagé pour le texte associé. Le réglage de la résolution pose ainsi un compromis entre le détail visuel entrant dans le modèle et la marge disponible pour d'autres contenus ; la valeur maximale autorisée ne garantit pas à elle seule de meilleurs résultats de récupération.

Le code sépare le chargement du processeur et du modèle, l'encodage d'une requête textuelle et l'encodage d'un document avec texte et image. Dans l'exemple, « query: » accompagne la requête et « passage: » le contenu documentaire ; l'image est passée comme argument séparé. Le chemin d'image du fragment est illustratif, et le dispositif CUDA et l'implémentation d'attention spécifiés font partie de cette configuration concrète, non d'une garantie de compatibilité avec n'importe quel équipement ou installation.

Benchmarks et méthodologie publiée

NVIDIA rapporte des résultats sur deux benchmarks principaux : ViDoRe V3 pour la récupération de documents visuels et MIRACL-VISION pour la récupération visuelle multilingue. La métrique utilisée est NDCG@10, qui évalue la qualité de la récupération des 10 documents les plus pertinents.

Il est important de noter que ces résultats sont fournis par le fournisseur et n'ont pas été reproduits de manière indépendante par des tiers au moment de la rédaction de cette analyse. Les résultats montrent que le modèle de 1B surpasse les modèles de 2B d'autres familles dans plusieurs catégories, bien que le modèle de 8B de la même famille de NVIDIA obtienne des scores légèrement supérieurs.

NDCG@10 résume la position et la pertinence des résultats récupérés parmi les dix premiers : un score plus élevé indique un meilleur classement selon cette métrique et l'ensemble évalué. Il n'exprime pas à lui seul la latence, la consommation de mémoire ni la performance sur un corpus différent. Les quatre colonnes de ViDoRe V3 séparent les entrées d'image, de texte et d'image avec texte, tandis que la colonne de MIRACL-VISION présentée ici correspond à l'image.

Dans les résultats publiés, le modèle 1B obtient 58,02 pour l'image, 57,80 pour le texte et 58,82 pour l'image plus texte en ViDoRe V3 ; en MIRACL-VISION image, il atteint 68,93. Face à Qwen3-VL-Embedding-2B, ses scores sont supérieurs dans les quatre colonnes du tableau. Face à Qwen3-VL-Embedding-8B, ils sont supérieurs en texte, image plus texte et MIRACL-VISION, mais pas en ViDoRe V3 image. Le modèle Nemotron 3.5 Embed 8B obtient des chiffres supérieurs à la variante 1B dans les quatre mesures présentées. Ces comparaisons se limitent aux scores rapportés pour ces benchmarks.

Les résultats proviennent de la fiche du fournisseur et ne comptent pas de reproduction indépendante indiquée dans l'analyse. Par conséquent, les chiffres décrivent la performance publiée sous la méthodologie de ces benchmarks, non une garantie que le même ordre se maintienne avec d'autres données, configurations ou critères d'évaluation. NDCG@10 sert à comparer la qualité du classement dans l'ensemble mesuré, mais ne détermine pas à lui seul quel modèle sera le plus approprié dans une installation concrète.

Prix et exigences de déploiement

Le modèle est disponible publiquement sur Hugging Face sous la licence OpenMDW 1.1, ce qui permet son utilisation commerciale sous réserve des termes de cette licence. Il n'existe pas d'API officielle de NVIDIA pour ce modèle spécifique, par conséquent le coût principal est l'infrastructure GPU nécessaire à son exécution.

Pour le déploiement, NVIDIA recommande des GPU des architectures Ampere, Hopper ou Blackwell. La configuration optimisée pour le checkpoint BF16 utilise la précision FP16 lors de l'inférence, bien que le checkpoint soit stocké en BF16. Le modèle nécessite un minimum de 8 cœurs CPU et prend en charge le Multi-Instance GPU (MIG) dans certaines configurations matérielles.

La licence OpenMDW 1.1 conditionne l'usage commercial à ses termes ; la disponibilité publique du checkpoint n'élimine pas la nécessité de les respecter. Le modèle est téléchargé pour s'exécuter sur une infrastructure propre, et la dépense signalée se concentre sur les ressources GPU nécessaires à l'inférence. Aucune API officielle hébergée par NVIDIA n'est indiquée pour ce modèle spécifique, de sorte qu'il n'y a pas ici de tarif officiel par requête permettant de comparer directement le coût avec des services d'API.

Les recommandations de matériel et le tableau des configurations décrivent une compatibilité optimisée sur les GPU énumérés, non un résultat vérifié pour n'importe quel accélérateur. La documentation prend en compte les architectures Ampere, Hopper et Blackwell ; les lignes spécifient FP16 pour les configurations standard et NVFP4 en plus de FP16 pour GB200. La précision stockée dans le checkpoint et celle utilisée pendant l'inférence sont des concepts distincts : le checkpoint indiqué est BF16, tandis que la configuration optimisée décrite emploie FP16 pour l'inférence.

L'exigence d'au moins huit cœurs CPU et le support de Multi-Instance GPU doivent être lus conjointement avec les conditions de la configuration de déploiement. MIG n'apparaît comme compatible que dans certaines configurations de matériel, non comme une fonction disponible de manière uniforme sur tous les GPU du tableau. De même, une liste de configurations optimisées n'établit pas le comportement, la performance ni les exigences de mémoire sur des équipements qui n'y figurent pas.

Limites, sécurité et alternatives

La principale limite est le contexte maximal de 32 768 jetons, partagé entre le texte et les jetons d'image. Si une image haute résolution consomme la majeure partie de ce contexte, l'espace disponible pour le texte est considérablement réduit. De plus, le modèle ne garantit pas la récupération du document correct pour une requête donnée, il doit donc être intégré dans un pipeline RAG avec des étapes de reranking.

En matière de sécurité, NVIDIA avertit que les développeurs doivent vérifier les droits des images d'entrée et prendre en compte les risques de biais et de confidentialité. Le modèle n'inclut pas de mécanismes spécifiques d'atténuation des biais, son utilisation dans des contextes sensibles nécessite donc une évaluation supplémentaire.

La limite partagée de contexte affecte la préparation de chaque document, en particulier lorsqu'une image haute résolution accompagne du texte. Si les jetons d'image occupent une grande partie du maximum, il reste moins de capacité pour le texte ; réduire le contenu textuel ou ajuster la résolution peut modifier la composition de l'entrée, mais ne garantit pas que le document correct apparaisse parmi les résultats. La récupération reste une étape probabiliste et le modèle n'offre pas de garantie de réussite pour chaque requête.

Le reranking remplit une fonction distincte de la génération initiale des embeddings : une étape ultérieure réordonne un ensemble de candidats pour améliorer leur priorité estimée. L'incorporer peut faire partie d'un pipeline RAG, mais ne transforme pas le résultat en infaillible ni ne remplace les tests avec des documents et des requêtes représentatifs. La performance de l'ensemble dépend également de la manière dont le corpus est préparé et de la manière dont la récupération est évaluée, de sorte que le score du modèle ne suffit pas à certifier le comportement de toute l'application.

Les risques indiqués pour les images incluent les droits d'utilisation, la confidentialité et les biais possibles dans les résultats. Le modèle n'incorpore pas de mécanismes spécifiques d'atténuation des biais selon la description, de sorte que la révision de l'usage et des résultats incombe à ceux qui le déploient. L'évaluation supplémentaire dans des contextes sensibles n'équivaut pas à une certification de sécurité : elle permet d'examiner les risques pertinents avant de décider si le système est approprié pour un usage déterminé.

La compatibilité logicielle fait également partie du déploiement. L'avertissement identifie un risque concret lors de la combinaison de Flash Attention 2 avec des versions de Transformers antérieures à 5.20.0 pendant le traitement d'images : des erreurs CUDA ou des sorties incorrectes peuvent apparaître. La recommandation d'utiliser transformers==5.20.0 se réfère aux exemples de Transformers et Sentence Transformers. Mettre à jour la bibliothèque réduit ce problème décrit, mais ne garantit pas que toutes les erreurs d'installation, de mémoire ou de compatibilité de l'environnement disparaissent.

Critères pratiques de choix

Le choix de Nemotron 3.5 Embed 1B BF16 par rapport à d'autres options dépend de plusieurs facteurs. Si le corpus de documents inclut une proportion significative d'images, de tableaux ou d'infographies, ce modèle offre un avantage clair par rapport aux modèles d'embeddings purement textuels. Sa taille de 1B de paramètres le rend plus efficace en termes de latence et de coût GPU que le modèle de 8B, avec une perte de performance modérée.

Pour les équipes qui utilisent déjà Nemotron 3 Embed 1B pour le texte, la migration vers la version 3.5 est directe dans l'espace d'embeddings textuel, ce qui facilite l'intégration. Cependant, si l'usage est exclusivement textuel et que le budget GPU est limité, il pourrait être envisagé de conserver le modèle précédent ou d'explorer des alternatives de tiers avec des prix d'API plus bas.

L'avantage d'incorporer des images dépend de la composition réelle du corpus. Si une partie pertinente des documents contient des tableaux, des infographies ou d'autres éléments visuels, l'entrée multimodale peut représenter des aspects qu'un modèle exclusivement textuel ne reçoit pas directement. Si le corpus est principalement textuel, cette capacité supplémentaire peut apporter moins de valeur, et le choix doit s'appuyer sur des tests avec des requêtes et des documents propres plutôt que de supposer qu'une modalité plus large améliore automatiquement toute recherche.

La comparaison entre les variantes 1B et 8B doit considérer deux dimensions distinctes : les scores publiés et les ressources d'exécution. Dans les benchmarks inclus, la variante 8B atteint des scores supérieurs dans toutes les colonnes montrées, tandis que la variante 1B a moins de paramètres. La taille réduite peut réduire les besoins de calcul, mais ne permet pas de déduire une latence ou un coût concrets sans les mesurer sur le matériel et la configuration choisis. La perte de performance décrite comme modérée correspond à ces comparaisons publiées, non à une garantie pour chaque tâche.

La continuité de l'espace d'embeddings textuel avec Nemotron 3 Embed 1B est attribuée au fait que le composant linguistique a été maintenu figé pendant la distillation. Cette continuité facilite l'envisager une migration pour les équipes qui utilisent déjà le modèle précédent, mais n'élimine pas la nécessité de vérifier le comportement du système complet. L'incorporation de documents visuels, le format d'entrée, l'infrastructure et les étapes de récupération peuvent affecter l'intégration même si la représentation textuelle conserve cette relation.

Le processus d'adoption peut transformer les critères généraux en une comparaison contrôlée : caractériser la proportion de documents avec images, confirmer quel GPU est disponible et mesurer la latence et le coût d'inférence dans cette configuration. Les tests avec des données propres permettent de vérifier si les scores publiés se traduisent en résultats utiles pour le corpus concret. La comparaison avec les alternatives et l'évaluation du reranking complètent la décision ; aucun chiffre isolé de paramètres ou de benchmark ne remplace ces mesures.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.