Nemotron 3.5 Embed 1B BF16: análisis de capacidades, límites y coste

Qué hace el modelo exacto

Nemotron 3.5 Embed 1B BF16 es un modelo de embeddings de 1,55 mil millones de parámetros desarrollado por NVIDIA para la recuperación de documentos multimodal y multilingüe. A diferencia de sus predecesores puramente textuales, este modelo acepta como entrada documentos en forma de imagen, texto o una combinación de ambos, mientras que las consultas de búsqueda se limitan exclusivamente a texto.

La arquitectura combina un codificador visual Pixtral, inicializado a partir de Ministral-3-3B-Instruct-2512-BF16, con un modelo de lenguaje inicializado desde Nemotron-3-Embed-1B-BF16. Durante el proceso de destilación desde el modelo maestro Nemotron-3.5-Embed-8B-BF16, la componente de lenguaje se mantuvo congelada, lo que significa que el espacio de embeddings textual es idéntico al de Nemotron 3 Embed 1B, pero con la adición de capacidades de recuperación visual.

La distinción entre entradas documentales y consultas define el uso previsto del modelo: una consulta se representa solo mediante texto, mientras que el documento recuperable puede aportar información textual, visual o de ambos tipos. Por ello, el componente visual amplía la clase de documentos que se pueden indexar, pero no convierte la búsqueda en una interacción con consultas de imagen. El modelo produce representaciones vectoriales para comparar consultas con documentos dentro de un sistema de recuperación.

El número de parámetros cambia según se cuenten o no las capas de embedding. La cifra total de 1,55 mil millones incluye esas capas; la cifra de 1.286 mil millones se refiere a los parámetros de inferencia y las excluye. La dimensión de salida indicada es 2048, con opciones dinámicas entre 128 y 2048. Esa flexibilidad permite elegir la longitud del vector, aunque la información aquí descrita no establece qué dimensión ofrece el mejor resultado para cada conjunto de datos o tarea.

El contexto máximo de 32.768 tokens se reparte entre el texto y la representación de las imágenes. En consecuencia, la capacidad total no equivale a 32.768 tokens de texto más una cantidad adicional para las imágenes: ambos tipos de entrada compiten por el mismo límite. La ficha también distingue la evaluación lingüística de las modalidades: informa de 34 idiomas de texto y 18 idiomas de imagen evaluados, sin que esas cifras impliquen un rendimiento idéntico para todos los idiomas.

Capacidades y ejemplos por tarea

El modelo está diseñado para flujos de trabajo de RAG (Retrieval-Augmented Generation) y búsqueda semántica donde los documentos no son solo texto plano, sino páginas de PDF, infografías o tablas escaneadas. La capacidad de procesar directamente la imagen de la página permite capturar información estructural y visual que se perdería en una extracción OCR tradicional.

Para las consultas, el modelo utiliza un prefijo 'query:' y para los documentos un prefijo 'passage:'. Esta distinción es crucial para el rendimiento, ya que el modelo fue entrenado para tratar de manera asimétrica la intención de búsqueda frente al contenido del documento. Las imágenes se procesan con un lado mayor de 1.120 píxeles por defecto, ampliable hasta 1.540 píxeles, lo que afecta directamente al consumo de tokens del contexto.

En un flujo de recuperación, los documentos se convierten en embeddings y una consulta textual se representa de forma compatible para localizar los documentos más pertinentes. Los prefijos «query:» y «passage:» señalan al modelo cuál de esos dos papeles cumple cada texto. No son etiquetas intercambiables: la preparación de consultas y documentos sigue la asimetría para la que se entrenó el sistema. Omitir o cambiar esos prefijos puede apartar la entrada del formato mostrado, por lo que conviene conservarlos al reproducir el ejemplo.

La entrada visual permite representar la página como imagen en lugar de depender exclusivamente de una transcripción OCR previa. Esto puede conservar relaciones de disposición, como la proximidad entre elementos o su organización dentro de una tabla, que una extracción de texto podría no reflejar. Esa capacidad no significa que el modelo interprete toda página sin errores ni que sustituya cualquier proceso de extracción: describe una vía de entrada para recuperar documentos que contienen información visual y textual.

El tamaño de imagen predeterminado usa un lado mayor de 1.120 píxeles y puede ampliarse hasta 1.540. Una imagen de mayor tamaño puede requerir más tokens de imagen y, por tanto, dejar menos espacio del contexto compartido para el texto asociado. El ajuste de resolución plantea así un intercambio entre el detalle visual que entra en el modelo y el margen disponible para otros contenidos; el valor máximo permitido no garantiza por sí solo mejores resultados de recuperación.

El código separa la carga del procesador y del modelo, la codificación de una consulta de texto y la codificación de un documento con texto e imagen. En el ejemplo, «query:» acompaña la consulta y «passage:» el contenido documental; la imagen se pasa como argumento aparte. La ruta de imagen del fragmento es ilustrativa, y el dispositivo CUDA y la implementación de atención especificados forman parte de esa configuración concreta, no de una garantía de compatibilidad con cualquier equipo o instalación.

Benchmarks y metodología publicada

NVIDIA reporta resultados en dos benchmarks principales: ViDoRe V3 para recuperación de documentos visuales y MIRACL-VISION para recuperación visual multilingüe. La métrica utilizada es NDCG@10, que evalúa la calidad de la recuperación de los 10 documentos más relevantes.

Es importante destacar que estos resultados son proporcionados por el proveedor y no han sido reproducidos de forma independiente por terceros en el momento de la redacción de este análisis. Los resultados muestran que el modelo de 1B supera a modelos de 2B de otras familias en varias categorías, aunque el modelo de 8B de la misma familia de NVIDIA obtiene puntuaciones ligeramente superiores.

NDCG@10 resume la posición y relevancia de los resultados recuperados dentro de los diez primeros puestos: una puntuación mayor indica una ordenación mejor según esa métrica y el conjunto evaluado. No expresa por sí sola la latencia, el consumo de memoria ni el rendimiento en un corpus distinto. Las cuatro columnas de ViDoRe V3 separan entradas de imagen, texto e imagen junto con texto, mientras que la columna de MIRACL-VISION presentada aquí corresponde a imagen.

En los resultados publicados, el modelo 1B obtiene 58.02 para imagen, 57.80 para texto y 58.82 para imagen más texto en ViDoRe V3; en MIRACL-VISION de imagen alcanza 68.93. Frente a Qwen3-VL-Embedding-2B, sus puntuaciones son superiores en las cuatro columnas de la tabla. Frente a Qwen3-VL-Embedding-8B, son superiores en texto, imagen más texto y MIRACL-VISION, pero no en ViDoRe V3 de imagen. El modelo Nemotron 3.5 Embed 8B obtiene cifras mayores que la variante 1B en las cuatro medidas presentadas. Estas comparaciones se limitan a las puntuaciones reportadas para esos benchmarks.

Los resultados proceden de la ficha del proveedor y no cuentan con reproducción independiente indicada en el análisis. Por ello, las cifras describen el desempeño publicado bajo la metodología de esos benchmarks, no una garantía de que el mismo orden se mantenga con otros datos, configuraciones o criterios de evaluación. NDCG@10 sirve para comparar calidad de ordenación en el conjunto medido, pero no determina por sí sola cuál modelo será más conveniente en una instalación concreta.

Precio y requisitos de despliegue

El modelo está disponible de forma pública en Hugging Face bajo la licencia OpenMDW 1.1, lo que permite su uso comercial sujeto a los términos de dicha licencia. No existe una API oficial de NVIDIA para este modelo específico, por lo que el coste principal es la infraestructura de GPU necesaria para su ejecución.

Para el despliegue, NVIDIA recomienda GPUs de las arquitecturas Ampere, Hopper o Blackwell. La configuración optimizada para el checkpoint BF16 utiliza precisión FP16 en la inferencia, aunque el checkpoint se almacena en BF16. El modelo requiere un mínimo de 8 núcleos de CPU y soporta Multi-Instance GPU (MIG) en ciertas configuraciones de hardware.

La licencia OpenMDW 1.1 condiciona el uso comercial a sus términos; la disponibilidad pública del checkpoint no elimina la necesidad de respetarlos. El modelo se descarga para ejecutarse en infraestructura propia, y el gasto señalado se concentra en los recursos de GPU necesarios para la inferencia. No se indica una API oficial alojada por NVIDIA para este modelo específico, de modo que no hay aquí una tarifa oficial por solicitud que permita comparar directamente el coste con servicios de API.

Las recomendaciones de hardware y la tabla de configuraciones describen compatibilidad optimizada en las GPU enumeradas, no un resultado comprobado para cualquier acelerador. La documentación contempla las arquitecturas Ampere, Hopper y Blackwell; las filas especifican FP16 para las configuraciones estándar y NVFP4 además de FP16 para GB200. La precisión almacenada en el checkpoint y la usada durante la inferencia son conceptos distintos: el checkpoint indicado es BF16, mientras que la configuración optimizada descrita emplea FP16 para inferencia.

El requisito de al menos ocho núcleos de CPU y el soporte de Multi-Instance GPU se deben leer junto con las condiciones de la configuración de despliegue. MIG solo figura como compatible en ciertas configuraciones de hardware, no como una función disponible de manera uniforme en todas las GPU de la tabla. Asimismo, una lista de configuraciones optimizadas no establece el comportamiento, el rendimiento ni los requisitos de memoria en equipos que no aparecen en ella.

Limitaciones, seguridad y alternativas

La principal limitación es el contexto máximo de 32.768 tokens, que se comparte entre el texto y los tokens de imagen. Si una imagen de alta resolución consume la mayor parte de este contexto, el espacio disponible para el texto se reduce significativamente. Además, el modelo no garantiza la recuperación del documento correcto para una consulta dada, por lo que debe integrarse en un pipeline de RAG con etapas de reranking.

En cuanto a seguridad, NVIDIA advierte que los desarrolladores deben verificar los derechos de las imágenes de entrada y considerar los riesgos de sesgo y privacidad. El modelo no incluye mecanismos de mitigación de sesgo específicos, por lo que su uso en contextos sensibles requiere una evaluación adicional.

El límite compartido de contexto afecta a la preparación de cada documento, especialmente cuando una imagen de alta resolución acompaña texto. Si los tokens de imagen ocupan una parte grande del máximo, queda menos capacidad para el texto; reducir el contenido textual o ajustar la resolución puede cambiar la composición de la entrada, pero no asegura que el documento correcto aparezca entre los resultados. La recuperación sigue siendo una etapa probabilística y el modelo no ofrece una garantía de acierto para cada consulta.

El reranking cumple una función distinta de la generación inicial de embeddings: una etapa posterior vuelve a ordenar un conjunto de candidatos para mejorar su prioridad estimada. Incorporarla puede formar parte de un pipeline de RAG, pero no convierte el resultado en infalible ni sustituye las pruebas con documentos y consultas representativos. El rendimiento del conjunto depende también de cómo se prepare el corpus y de cómo se evalúe la recuperación, por lo que la puntuación del modelo no basta para certificar el comportamiento de toda la aplicación.

Los riesgos indicados para las imágenes incluyen los derechos de uso, la privacidad y los posibles sesgos en los resultados. El modelo no incorpora mecanismos específicos de mitigación del sesgo según la descripción, de modo que la revisión del uso y de los resultados corresponde a quienes lo despliegan. La evaluación adicional en contextos sensibles no equivale a una certificación de seguridad: permite examinar riesgos relevantes antes de decidir si el sistema es apropiado para un uso determinado.

La compatibilidad de software también forma parte del despliegue. El aviso identifica un riesgo concreto al combinar Flash Attention 2 con versiones de Transformers anteriores a 5.20.0 durante el procesamiento de imágenes: pueden aparecer errores de CUDA o salidas incorrectas. La recomendación de usar transformers==5.20.0 se refiere a los ejemplos de Transformers y Sentence Transformers. Actualizar la biblioteca reduce ese problema descrito, pero no garantiza que desaparezcan todos los errores de instalación, memoria o compatibilidad del entorno.

Criterios prácticos de elección

La elección de Nemotron 3.5 Embed 1B BF16 frente a otras opciones depende de varios factores. Si el corpus de documentos incluye una proporción significativa de imágenes, tablas o infografías, este modelo ofrece una ventaja clara sobre los modelos de embeddings puramente textuales. Su tamaño de 1B parámetros lo hace más eficiente en términos de latencia y coste de GPU que el modelo de 8B, con una pérdida de rendimiento moderada.

Para equipos que ya utilizan Nemotron 3 Embed 1B para texto, la migración a la versión 3.5 es directa en el espacio de embeddings textual, lo que facilita la integración. Sin embargo, si el uso es exclusivamente textual y el presupuesto de GPU es limitado, podría considerarse mantener el modelo anterior o explorar alternativas de terceros con precios de API más bajos.

La ventaja de incorporar imágenes depende de la composición real del corpus. Si una parte relevante de los documentos contiene tablas, infografías u otros elementos visuales, la entrada multimodal puede representar aspectos que un modelo exclusivamente textual no recibe directamente. Si el corpus es principalmente texto, esa capacidad adicional puede aportar menos valor, y la elección debe apoyarse en pruebas con consultas y documentos propios en vez de asumir que una modalidad más amplia mejora automáticamente cualquier búsqueda.

La comparación entre las variantes 1B y 8B debe considerar dos dimensiones distintas: las puntuaciones publicadas y los recursos de ejecución. En los benchmarks incluidos, la variante 8B logra puntuaciones mayores en todas las columnas mostradas, mientras que la variante 1B tiene menos parámetros. El tamaño menor puede reducir necesidades de cómputo, pero no permite deducir una latencia o un coste concretos sin medirlos en el hardware y la configuración elegidos. La pérdida de rendimiento descrita como moderada corresponde a esas comparaciones publicadas, no a una garantía para cada tarea.

La continuidad del espacio de embeddings textual con Nemotron 3 Embed 1B se atribuye a que la componente lingüística se mantuvo congelada durante la destilación. Esa continuidad facilita plantear una migración para equipos que ya usan el modelo anterior, pero no elimina la necesidad de comprobar el comportamiento del sistema completo. La incorporación de documentos visuales, el formato de entrada, la infraestructura y las etapas de recuperación pueden afectar la integración aunque la representación textual conserve esa relación.

El proceso de adopción puede convertir los criterios generales en una comparación controlada: caracterizar la proporción de documentos con imágenes, confirmar qué GPU está disponible y medir la latencia y el coste de inferencia en esa configuración. Las pruebas con datos propios permiten comprobar si las puntuaciones publicadas se traducen en resultados útiles para el corpus concreto. La comparación con alternativas y la evaluación del reranking completan la decisión; ninguna cifra aislada de parámetros o benchmark sustituye esas mediciones.

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.