Nemotron 3.5 Embed 8B BF16 : capacités, benchmarks et limites de déploiement

Ce que fait Nemotron 3.5 Embed 8B BF16

Nemotron-3.5-Embed-8B-BF16 est un modèle d’embeddings de NVIDIA conçu pour retrouver des documents à partir de requêtes. Il ne génère pas de réponses conversationnelles : il transforme une requête textuelle et des documents textuels, des images ou une combinaison des deux en vecteurs qu’un système de recherche peut comparer. Le flux habituel consiste à indexer les documents, à enregistrer leurs vecteurs avec leur contenu d’origine, puis à calculer le vecteur de chaque requête pour repérer les éléments pertinents.

Le checkpoint ne génère pas de texte conversationnel : il transforme des requêtes textuelles et des documents textuels, des images ou une combinaison des deux en vecteurs de recherche. Les exemples fournis pour Transformers, Sentence Transformers et vLLM produisent des vecteurs de 4 096 dimensions normalisés selon la norme L2. La matrice du produit Embedding NIM indique 2 048 pour la ligne du modèle 8B ; il ne faut pas supposer que cette configuration décrit la sortie native des exemples du checkpoint. Avant de créer un index, vérifiez la dimension effective du runtime ou du point d’accès utilisé.

La distinction entre le checkpoint et le runtime a des conséquences pratiques. Une base vectorielle exige généralement que les vecteurs enregistrés et ceux des requêtes aient des dimensions compatibles. Il est également utile de conserver la même préparation des entrées, les mêmes préfixes de tâche et la même normalisation lors de l’indexation et de la recherche : si ces éléments changent, la comparaison directe peut ne plus être valide.

Traitement du texte et des images

Le modèle crée des représentations vectorielles de requêtes et de documents pour les tâches de recherche sémantique. Les documents peuvent être constitués de texte, d’images de pages ou d’un contenu combinant les deux. Cette dernière option permet de représenter les éléments visuels d’un document — par exemple des tableaux, des graphiques et des infographies — avec le texte qui les accompagne, sans transformer le système en générateur de réponses.

La fiche précise que la requête est saisie sous forme de texte et que les documents peuvent contenir du texte, une image ou les deux. Dans les exemples, le modèle utilise des préfixes de tâche distincts : « query: » pour les requêtes et « passage: » pour les documents. Conserver cette convention et le même runtime lors de l’indexation et de la recherche aide à éviter les comparaisons incompatibles.

La fiche décrit également une tour de langage basée sur Nemotron-3-Embed-8B, conservée gelée pendant l’ajustement multimodal. NVIDIA indique que les deux modèles partagent le même espace d’embeddings textuels et produisent des embeddings textuels identiques. Cette compatibilité concerne le texte dans les conditions décrites pour le checkpoint ; elle ne permet pas de mélanger des vecteurs de dimensions ou de configurations différentes sans vérification. L’intégration doit conserver la cohérence entre le modèle, la préparation des requêtes et des documents, la normalisation et la dimension de l’index.

Selon sa fiche, le checkpoint accepte des entrées allant jusqu’à 32 768 tokens. Le traitement des images utilise par défaut une longueur maximale de 1 120 pixels sur le côté le plus long, réglable jusqu’à 1 540 pixels. Ces limites de longueur et de résolution décrivent les capacités d’entrée ; elles ne garantissent pas que tous les documents longs ou visuellement denses seront retrouvés correctement.

Ce que montrent les benchmarks publiés

La fiche de NVIDIA présente des résultats sur ViDoRe V3 et MIRACL-VISION, deux benchmarks de recherche visuelle. La métrique indiquée est NDCG@10. La fiche décrit ViDoRe V3 comme une évaluation de la recherche de documents visuels et MIRACL-VISION comme un ensemble de recherche visuelle multilingue. Ces résultats correspondent aux tests indiqués par NVIDIA ; ils ne mesurent pas les performances universelles du modèle sur n’importe quel corpus.

Dans les chiffres publiés, Nemotron-3.5-Embed-8B-BF16 obtient 60,39 sur ViDoRe V3 pour les images, 60,65 pour le texte et 61,47 pour l’association image et texte. Il obtient 72,64 sur MIRACL-VISION pour les images. La fiche publie également des résultats pour Nemotron-3.5-Embed-1B-BF16 et Qwen3-VL-Embedding-8B. Ces scores permettent de comparer les modèles dans les conditions de l’évaluation, mais ne prédisent pas directement la qualité de recherche sur une collection particulière.

La fiche indique que l’évaluation du texte couvrait 34 langues et celle des images 18 langues. Cette portée concerne les langues évaluées ; elle ne garantit pas une qualité équivalente pour chaque langue, dialecte ou type de document. La fiche précise que le modèle pourrait prendre en charge d’autres langues, mais celles-ci ne figurent pas dans les ensembles d’évaluation cités.

Les résultats publiés par NVIDIA décrivent les évaluations du fournisseur, et non une certification indépendante ou une garantie de performance sur d’autres corpus. Pour déterminer si le modèle convient à un cas d’usage précis, une équipe peut constituer son propre ensemble de requêtes et de documents, puis calculer des métriques de recherche à partir de jugements de pertinence. La comparaison doit conserver les mêmes conditions et distinguer ces résultats locaux des scores du fournisseur.

Exigences et configuration de déploiement

La fiche comprend des exemples d’utilisation avec Transformers, Sentence Transformers et vLLM. De son côté, la documentation du produit NeMo Retriever Embedding NIM précise les exigences logicielles, CPU et GPU de ses conteneurs et répertorie les configurations optimisées par modèle. Les exigences de NIM ne doivent pas être confondues avec celles de toutes les façons d’exécuter le checkpoint : chaque runtime peut avoir des compatibilités, des valeurs par défaut et des limites différentes.

Les configurations optimisées de Nemotron 3.5 Embed 1B dans NIM incluent des options FP16, mais ce tableau n’établit pas les combinaisons prises en charge par le checkpoint 8B. La précision d’inférence dépend du modèle, du runtime et du GPU. Le suffixe BF16 identifie le checkpoint et ne garantit pas qu’un conteneur utilise cette même précision ; vérifiez la configuration propre à la variante 8B avant son déploiement.

La matrice NIM précise que le choix des kernels et de la précision peut dépendre de l’architecture détectée et de la configuration du modèle. Une configuration de repli peut fonctionner sur certains équipements compatibles, mais la documentation ne garantit pas qu’elle offre les mêmes fonctions ou les mêmes performances qu’une configuration optimisée. La possibilité d’exécuter un modèle ne signifie pas que chaque combinaison de matériel et de précision a été validée dans toutes les conditions.

La licence OpenMDW-1.1 définit les conditions d’utilisation du checkpoint. Elle ne correspond pas à un tarif de service et ne confirme pas la disponibilité d’un point d’accès géré particulier. Le coût d’une installation propre dépend de l’infrastructure choisie, de son taux d’utilisation et de la charge d’inférence.

Limites et critères de sélection

Le modèle est conçu pour la recherche, pas pour générer du texte, et la recherche ne garantit pas que le document sélectionné soit correct ou suffisant. La fiche du modèle précise qu’il peut ne pas toujours retrouver les documents appropriés à une requête. Dans les applications où une erreur pourrait avoir des conséquences importantes, vérifiez les résultats à partir du contenu original et prévoyez des contrôles adaptés à l’usage.

La limite de 32 768 tokens ne signifie pas que tout document de cette longueur peut être traité sans perte ou retrouvé avec précision. Les entrées qui dépassent les limites du checkpoint ou du runtime doivent être gérées selon le comportement de l’implémentation concernée. Pour les documents longs, une stratégie de découpage peut être nécessaire ; les segments doivent conserver assez de contexte pour qu’une requête retrouve la section pertinente.

Pour comparer le modèle 8B à la variante 1B ou à d’autres solutions, évaluez les mêmes requêtes et documents dans des conditions équivalentes. Notez également la dimension de sortie, la latence et l’utilisation des ressources de chaque configuration. Les scores des benchmarks publiés peuvent aider à définir les comparaisons, mais ils ne remplacent pas un test sur le corpus cible et ne suffisent pas à établir qu’une variante est meilleure dans tous les cas.

Nemotron-3.5-Embed-8B-BF16 peut convenir à un système qui doit représenter des documents visuels et du texte dans un flux de recherche, à condition que l’équipe puisse déployer et valider la configuration choisie. Avant de l’intégrer à un index existant, confirmez la compatibilité des dimensions et des configurations. Si le cas d’usage concerne uniquement du texte ou si la charge d’inférence impose de limiter les ressources, comparez les solutions avec une évaluation locale au lieu de supposer qu’un modèle plus grand apportera toujours une amélioration pratique.

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.