Nemotron 3.5 Embed 8B BF16: capacidades, benchmarks y límites de despliegue

Qué hace Nemotron 3.5 Embed 8B BF16

Nemotron-3.5-Embed-8B-BF16 es un modelo de embeddings de NVIDIA orientado a recuperar documentos a partir de consultas. No genera respuestas conversacionales: convierte una consulta textual y documentos de texto, imágenes o una combinación de ambos en vectores que un sistema de búsqueda puede comparar. El flujo habitual consiste en indexar los documentos, guardar sus vectores junto al contenido original y calcular el vector de cada consulta para localizar elementos relevantes.

El checkpoint no genera texto conversacional: transforma consultas textuales y documentos de texto, imagen o ambos en vectores para recuperación. Sus ejemplos de Transformers, Sentence Transformers y vLLM producen vectores de 4.096 dimensiones, con normalización L2. La matriz del producto Embedding NIM lista 2.048 para la fila del modelo 8B; no debe asumirse que esa configuración describa la salida nativa de los ejemplos del checkpoint. Antes de crear el índice hay que comprobar la dimensión efectiva del endpoint o runtime utilizado.

La distinción entre el checkpoint y el runtime importa en la práctica. Una base vectorial normalmente requiere que los vectores almacenados y los de las consultas tengan dimensiones compatibles. También conviene mantener iguales la preparación de las entradas, los prefijos de tarea y la normalización: si esos elementos cambian entre la indexación y la búsqueda, una comparación directa puede dejar de ser válida.

Cómo procesa texto e imágenes

El modelo crea representaciones vectoriales de consultas y documentos para tareas de recuperación semántica. Los documentos pueden consistir en texto, imágenes de páginas o contenido combinado. Esta última opción permite representar elementos visuales de documentos —por ejemplo, tablas, gráficos e infografías— junto con el texto que los acompaña, sin convertir el sistema en un generador de respuestas.

La ficha indica que la consulta se introduce como texto y que los documentos pueden incluir texto, una imagen o ambos. En los ejemplos, el modelo aplica un prefijo de tarea distinto: «query:» para las consultas y «passage:» para los documentos. Mantener esa convención y el mismo runtime en la indexación y en la búsqueda ayuda a evitar comparaciones incompatibles.

La ficha también describe una torre de lenguaje basada en Nemotron-3-Embed-8B que se mantuvo congelada durante el ajuste multimodal. NVIDIA afirma que los dos modelos comparten el espacio de embeddings de texto y generan embeddings textuales idénticos. Esa compatibilidad se refiere al texto bajo las condiciones descritas para el checkpoint; no autoriza a mezclar vectores de distintas dimensiones o configuraciones sin comprobarlos. La integración debe mantener coherentes el modelo, la preparación de consultas y documentos, la normalización y la dimensión del índice.

El checkpoint admite entradas de hasta 32.768 tokens, según su ficha. El procesamiento de imágenes utiliza por defecto un límite de lado mayor de 1.120 píxeles y puede configurarse hasta 1.540. Los límites de longitud y resolución describen capacidades de entrada, no una garantía de que todos los documentos largos o visualmente densos se recuperen correctamente.

Qué muestran los benchmarks publicados

La ficha de NVIDIA presenta resultados en ViDoRe V3 y MIRACL-VISION, dos benchmarks de recuperación visual. La métrica informada es NDCG@10. La ficha describe ViDoRe V3 como una evaluación de recuperación de documentos visuales y MIRACL-VISION como un conjunto de recuperación visual multilingüe. Estos resultados describen las pruebas indicadas por NVIDIA, no una medición universal del rendimiento en cualquier corpus.

En las cifras publicadas, Nemotron-3.5-Embed-8B-BF16 obtiene 60,39 en ViDoRe V3 para imagen, 60,65 para texto y 61,47 para imagen y texto. En MIRACL-VISION para imagen obtiene 72,64. La ficha también publica resultados para Nemotron-3.5-Embed-1B-BF16 y Qwen3-VL-Embedding-8B. Las puntuaciones permiten comparar esos modelos dentro de las condiciones de la evaluación, pero no predicen directamente la calidad de recuperación en una colección propia.

La ficha señala que la evaluación de texto abarcó 34 idiomas y la de imágenes 18. Ese alcance se refiere a los idiomas evaluados, no a una garantía de calidad equivalente para cada idioma, dialecto o tipo de documento. La ficha indica que el modelo podría admitir idiomas adicionales, pero no los incluye en esos conjuntos de evaluación.

Los resultados publicados por NVIDIA describen evaluaciones del proveedor, no una certificación independiente ni una garantía de rendimiento en otros corpus. Para decidir si el modelo encaja en un caso de uso concreto, un equipo puede crear un conjunto de consultas y documentos propios y calcular métricas de recuperación con juicios de relevancia. La comparación debe mantener las mismas condiciones y distinguir esos resultados propios de las puntuaciones del proveedor.

Requisitos y configuración de despliegue

La ficha incluye ejemplos de uso con Transformers, Sentence Transformers y vLLM. La documentación del producto NeMo Retriever Embedding NIM especifica, por su parte, requisitos de software, CPU y GPU para sus contenedores y enumera las configuraciones optimizadas por modelo. Los requisitos de NIM no deben confundirse con los de cualquier forma de ejecutar el checkpoint: cada runtime puede tener compatibilidades, valores predeterminados y límites diferentes.

Las configuraciones optimizadas de Nemotron 3.5 Embed 1B en NIM incluyen opciones FP16, pero esa tabla no establece las combinaciones admitidas por el checkpoint 8B. La precisión utilizada depende del modelo, el runtime y la GPU. El sufijo BF16 identifica el checkpoint y no garantiza que un contenedor ejecute inferencia con esa misma precisión; antes de desplegar la variante 8B hay que comprobar su configuración específica.

La matriz de NIM señala que la selección de kernels y precisión puede depender de la arquitectura detectada y de la configuración del modelo. Una configuración de fallback puede ejecutarse en ciertos equipos compatibles, pero la documentación no garantiza que tenga las mismas funciones o el mismo rendimiento que una configuración optimizada. La posibilidad de ejecutar un modelo no equivale a que esa combinación de hardware y precisión esté validada en todas las condiciones.

La licencia OpenMDW-1.1 establece los términos de uso del checkpoint. No equivale a una tarifa de servicio ni confirma la disponibilidad de un endpoint gestionado concreto. El coste de una instalación propia depende de la infraestructura elegida, su utilización y la carga de inferencia.

Límites y criterios para elegirlo

El modelo está orientado a recuperación, no a generar texto, y la recuperación no garantiza que el documento seleccionado sea correcto o suficiente. La ficha del modelo advierte que puede no recuperar siempre los documentos correctos para una consulta. En aplicaciones donde un error tenga consecuencias importantes, conviene validar resultados con el contenido original y diseñar controles adecuados al uso.

El límite de 32.768 tokens no significa que cualquier documento de ese tamaño pueda procesarse sin pérdida o recuperarse con precisión. Las entradas que superen los límites del checkpoint o del runtime deben tratarse según el comportamiento concreto de la implementación. Para documentos largos, una estrategia de fragmentación puede ser necesaria; sus unidades deben conservar suficiente contexto para que una consulta encuentre la sección pertinente.

Para comparar el modelo 8B con la variante 1B u otras alternativas, evalúa las mismas consultas y documentos en condiciones equivalentes. Registra también la dimensión de salida, la latencia y el uso de recursos de cada configuración. Las puntuaciones de benchmarks publicadas pueden orientar qué comparar, pero no sustituyen una prueba en el corpus objetivo ni justifican por sí solas que una variante sea mejor para todos los casos.

Nemotron-3.5-Embed-8B-BF16 puede ser pertinente cuando el sistema necesita representar documentos visuales y texto en un flujo de recuperación, y cuando el equipo puede sostener y validar el despliegue elegido. Antes de integrarlo en un índice existente, confirma la compatibilidad de dimensiones y configuraciones. Si el caso de uso es solo texto, o la carga de inferencia exige limitar recursos, compara alternativas con una evaluación local en vez de asumir que un modelo mayor ofrece siempre una mejora práctica.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.