Nemotron 3.5 Embed 1B BF16: análise de capacidades, limites e custo

O que o modelo exato faz

O Nemotron 3.5 Embed 1B BF16 é um modelo de embeddings com 1,55 bilhão de parâmetros desenvolvido pela NVIDIA para recuperação de documentos multimodal e multilíngue. Diferentemente de seus predecessores puramente textuais, este modelo aceita documentos na forma de imagem, texto ou uma combinação de ambos como entrada, enquanto as consultas de busca são limitadas exclusivamente a texto.

A arquitetura combina um codificador visual Pixtral, inicializado a partir do Ministral-3-3B-Instruct-2512-BF16, com um modelo de linguagem inicializado a partir do Nemotron-3-Embed-1B-BF16. Durante o processo de destilação a partir do modelo mestre Nemotron-3.5-Embed-8B-BF16, o componente de linguagem foi mantido congelado. Isso significa que o espaço de embeddings textual é idêntico ao do Nemotron 3 Embed 1B, mas com a adição de capacidades de recuperação visual.

A separação entre documentos e consultas define a função de cada entrada no sistema. O documento pode reunir texto e imagem, mas a consulta permanece textual; assim, a capacidade visual amplia os tipos de conteúdo que podem ser indexados sem transformar a busca numa pesquisa feita a partir de imagens. O modelo gera vetores que permitem comparar uma consulta com os documentos representados no índice, mas a pertinência encontrada depende também do corpus e da configuração do processo de recuperação.

As cifras de parâmetros descrevem contagens diferentes, não duas estimativas concorrentes do mesmo conjunto. O total de 1,55 bilhão inclui as camadas de embedding, enquanto os 1.286 bilhão correspondem aos parâmetros considerados na inferência e excluem essas camadas. A dimensão de saída indicada é 2048, com opções dinâmicas de 128 a 2048. Essa possibilidade permite escolher o tamanho do vetor, mas não estabelece qual dimensão será melhor para uma tarefa ou conjunto de dados específicos.

O limite de 32.768 tokens é compartilhado entre texto e imagem. Portanto, não representa 32.768 tokens de texto aos quais se acrescenta espaço independente para conteúdo visual: os dois tipos de entrada utilizam o mesmo orçamento de contexto. A tabela também distingue 34 idiomas de texto avaliados e 18 idiomas de imagem avaliados. Essas contagens descrevem o escopo informado para as avaliações, sem significar que o desempenho seja idêntico entre idiomas ou modalidades.

Capacidades e exemplos por tarefa

O modelo é projetado para fluxos de trabalho de RAG (Retrieval-Augmented Generation) e busca semântica onde os documentos não são apenas texto plano, mas páginas de PDF, infográficos ou tabelas digitalizadas. A capacidade de processar diretamente a imagem da página permite capturar informações estruturais e visuais que seriam perdidas em uma extração OCR tradicional.

Para as consultas, o modelo utiliza o prefixo 'query:' e para os documentos o prefixo 'passage:'. Essa distinção é crucial para o desempenho, pois o modelo foi treinado para tratar de forma assimétrica a intenção de busca em relação ao conteúdo do documento. As imagens são processadas com um lado maior de 1.120 pixels por padrão, ampliado até 1.540 pixels, o que afeta diretamente o consumo de tokens do contexto.

Num fluxo de recuperação, o sistema transforma os documentos em embeddings e representa uma consulta textual para localizar conteúdos pertinentes. Os prefixos «query:» e «passage:» indicam ao modelo se o texto está sendo usado como consulta ou como documento. Como o treinamento considera esses papéis de maneira assimétrica, os prefixos não são rótulos intercambiáveis. Preservá-los ao preparar as entradas mantém o formato demonstrado, embora isso, por si só, não garanta a qualidade dos resultados.

A entrada de imagem permite representar diretamente uma página, em vez de depender apenas de uma transcrição OCR produzida antes da busca. Isso pode conservar relações visuais, como a disposição de elementos e a organização de uma tabela, que uma extração textual talvez não represente. A possibilidade descreve uma forma de fornecer documentos ao modelo; não significa que toda página será interpretada sem erros nem que qualquer etapa de extração de texto se torne desnecessária.

O processamento usa, por padrão, uma imagem cujo lado maior mede 1.120 pixels, com possibilidade de ampliação até 1.540 pixels. Uma imagem maior pode consumir mais tokens de imagem e deixar menos espaço no contexto comum para o texto associado. A escolha da resolução envolve, portanto, uma troca entre o detalhe visual fornecido e a capacidade restante para outros conteúdos. Usar a resolução máxima permitida não assegura, por si só, melhor recuperação.

O exemplo separa a preparação do processador e do modelo da codificação da consulta textual e do documento com texto e imagem. «query:» acompanha a consulta; «passage:» identifica o conteúdo documental, cuja imagem é passada como argumento separado. O endereço da imagem serve como exemplo, e CUDA e Flash Attention 2 fazem parte daquela configuração específica. O fragmento não demonstra compatibilidade com qualquer equipamento ou instalação, nem garante que a execução produza resultados corretos em todos os ambientes.

Benchmarks e metodologia publicada

A NVIDIA relata resultados em dois benchmarks principais: ViDoRe V3 para recuperação de documentos visuais e MIRACL-VISION para recuperação visual multilíngue. A métrica utilizada é NDCG@10, que avalia a qualidade da recuperação dos 10 documentos mais relevantes.

É importante destacar que esses resultados são fornecidos pelo fornecedor e não foram reproduzidos de forma independente por terceiros. Os resultados mostram que o modelo de 1B supera modelos de 2B de outras famílias em várias categorias, embora o modelo de 8B da mesma família da NVIDIA obtenha pontuações ligeiramente superiores.

NDCG@10 resume a qualidade da ordenação dos dez primeiros resultados segundo a relevância definida no benchmark; uma pontuação mais alta indica uma ordenação melhor nessa métrica e naquele conjunto avaliado. O indicador não mede diretamente latência ou consumo de memória e não determina o desempenho num corpus diferente. As colunas de ViDoRe V3 separam entradas de imagem, texto e imagem combinada com texto; a coluna de MIRACL-VISION apresentada na tabela corresponde à modalidade de imagem.

Na tabela, o modelo 1B obtém 58.02 para imagem, 57.80 para texto e 58.82 para imagem e texto em ViDoRe V3, além de 68.93 em MIRACL-VISION de imagem. Em comparação com Qwen3-VL-Embedding-2B, supera as quatro pontuações apresentadas. Frente a Qwen3-VL-Embedding-8B, tem resultados superiores em texto, imagem mais texto e MIRACL-VISION, mas fica abaixo em ViDoRe V3 de imagem. A variante Nemotron 3.5 Embed 8B apresenta pontuações maiores que a variante 1B nas quatro colunas. Essas comparações dizem respeito aos resultados publicados para esses benchmarks, sem estabelecer uma hierarquia universal para outras tarefas.

As pontuações são atribuídas à ficha do fornecedor, e a análise não indica reprodução independente dos resultados. Elas descrevem o desempenho publicado sob as condições dos benchmarks, não uma garantia de que a mesma ordem se mantenha com outros dados, configurações ou critérios de avaliação. NDCG@10 ajuda a comparar a ordenação dos resultados no conjunto medido, mas não basta para determinar qual modelo será mais adequado a uma implantação concreta.

Preço e requisitos de implantação

O modelo está disponível publicamente no Hugging Face sob a licença OpenMDW 1.1, o que permite seu uso comercial sujeito aos termos dessa licença. Não existe uma API oficial da NVIDIA para este modelo específico, portanto, o custo principal é a infraestrutura de GPU necessária para sua execução.

Para a implantação, a NVIDIA recomenda GPUs das arquiteturas Ampere, Hopper ou Blackwell. A configuração otimizada para o checkpoint BF16 utiliza precisão FP16 na inferência, embora o checkpoint seja armazenado em BF16. O modelo requer um mínimo de 8 núcleos de CPU e suporta Multi-Instance GPU (MIG) em certas configurações de hardware.

A licença OpenMDW 1.1 condiciona o uso comercial aos seus termos; a disponibilidade pública do checkpoint não dispensa o cumprimento dessas condições. O modelo pode ser executado em infraestrutura própria, e o principal custo apontado é o dos recursos de GPU necessários à inferência. Não há uma API oficial da NVIDIA indicada para este modelo específico, por isso não há uma tarifa oficial por solicitação que permita comparar diretamente esse custo com o de serviços de API.

As recomendações de hardware e a tabela descrevem configurações otimizadas para as GPUs listadas, não resultados comprovados para qualquer acelerador. A documentação contempla as arquiteturas Ampere, Hopper e Blackwell; as configurações padrão listadas usam FP16, enquanto a GB200 inclui NVFP4 e FP16. A precisão em que o checkpoint é armazenado e aquela usada na inferência são distintas: o checkpoint indicado é BF16, mas a configuração otimizada descrita utiliza FP16 durante a inferência.

O requisito de pelo menos oito núcleos de CPU e o suporte a Multi-Instance GPU devem ser entendidos no contexto da configuração de implantação. A compatibilidade com MIG é indicada apenas para certas configurações de hardware, não como recurso uniforme em todas as GPUs da tabela. Da mesma forma, a lista de configurações otimizadas não estabelece desempenho, requisitos de memória ou comportamento em equipamentos que não aparecem nela.

Limitações, segurança e alternativas

A principal limitação é o contexto máximo de 32.768 tokens, que é compartilhado entre o texto e os tokens de imagem. Se uma imagem de alta resolução consumir a maior parte desse contexto, o espaço disponível para o texto será significativamente reduzido. Além disso, o modelo não garante a recuperação do documento correto para uma consulta dada, portanto, deve ser integrado em um pipeline de RAG com etapas de reranking.

Em termos de segurança, a NVIDIA alerta que os desenvolvedores devem verificar os direitos das imagens de entrada e considerar os riscos de viés e privacidade. O modelo não inclui mecanismos específicos de mitigação de viés, portanto, seu uso em contextos sensíveis requer uma avaliação adicional.

O contexto compartilhado afeta a preparação de cada documento, sobretudo quando uma imagem de alta resolução acompanha o texto. Se os tokens de imagem ocuparem grande parte do limite, sobrará menos capacidade para o texto. Reduzir o texto ou ajustar a resolução altera a composição da entrada, mas não garante que o documento correto apareça entre os resultados. A recuperação continua probabilística: o modelo não assegura um acerto para cada consulta.

O reranking tem uma função diferente da geração inicial de embeddings: uma etapa posterior reordena um conjunto de candidatos para ajustar sua prioridade estimada. Essa etapa pode integrar um pipeline de RAG, mas não torna os resultados infalíveis nem substitui testes com documentos e consultas representativos. O comportamento do sistema também depende da preparação do corpus e da forma de avaliar a recuperação; por isso, uma pontuação do modelo não certifica o desempenho da aplicação inteira.

Os riscos mencionados para as imagens abrangem direitos de uso, privacidade e possíveis vieses nos resultados. A descrição do modelo não indica mecanismos específicos de mitigação de viés, de modo que os responsáveis pela implantação precisam avaliar o uso e os resultados. Essa avaliação adicional em contextos sensíveis não equivale a uma certificação de segurança: serve para examinar riscos relevantes antes de decidir se o sistema é apropriado para determinado uso.

A compatibilidade do software também afeta a implantação. O aviso aponta um risco concreto ao combinar Flash Attention 2 com versões de Transformers anteriores à 5.20.0 durante o processamento de imagens: podem ocorrer erros de CUDA ou saídas incorretas. A recomendação de usar transformers==5.20.0 refere-se aos exemplos de Transformers e Sentence Transformers. Atualizar a biblioteca responde ao problema descrito, mas não garante a eliminação de todos os erros de instalação, memória ou compatibilidade do ambiente.

Critérios práticos de escolha

A escolha do Nemotron 3.5 Embed 1B BF16 em relação a outras opções depende de vários fatores. Se o corpus de documentos incluir uma proporção significativa de imagens, tabelas ou infográficos, este modelo oferece uma vantagem clara sobre os modelos de embeddings puramente textuais. Seu tamanho de 1B de parâmetros o torna mais eficiente em termos de latência e custo de GPU do que o modelo de 8B, com uma perda de desempenho moderada.

Para equipes que já utilizam o Nemotron 3 Embed 1B para texto, a migração para a versão 3.5 é direta no espaço de embeddings textual, o que facilita a integração. No entanto, se o uso for exclusivamente textual e o orçamento de GPU for limitado, pode-se considerar manter o modelo anterior ou explorar alternativas de terceiros com preços de API mais baixos.

O benefício de incluir imagens depende da composição efetiva do corpus. Quando uma parte relevante dos documentos contém tabelas, infográficos ou outros elementos visuais, a entrada multimodal pode representar aspectos que um modelo exclusivamente textual não recebe diretamente. Num corpus composto sobretudo por texto, essa capacidade pode ter menor valor. Testes com as próprias consultas e documentos ajudam a avaliar sua utilidade, sem pressupor que aceitar mais modalidades melhore automaticamente qualquer busca.

A comparação entre as variantes 1B e 8B envolve tanto as pontuações publicadas quanto os recursos de execução. Nos benchmarks apresentados, a variante 8B obtém pontuações superiores em todas as colunas, enquanto a 1B tem menos parâmetros. O tamanho menor pode reduzir as necessidades de computação, mas não permite deduzir uma latência ou um custo específicos sem medições no hardware e na configuração escolhidos. A perda de desempenho descrita como moderada refere-se às comparações publicadas, não a uma garantia para cada tarefa.

A continuidade do espaço de embeddings textual em relação ao Nemotron 3 Embed 1B é atribuída ao congelamento do componente de linguagem durante a destilação. Essa relação pode facilitar uma migração para equipes que já usam o modelo anterior, mas não elimina a necessidade de avaliar o sistema completo. A inclusão de documentos visuais, o formato das entradas, a infraestrutura e as etapas de recuperação ainda podem afetar a integração.

O processo de adoção pode transformar os critérios gerais numa comparação prática: estimar a proporção de documentos com imagens, confirmar a GPU disponível e medir latência e custo de inferência na configuração prevista. Testar dados próprios permite verificar se os resultados publicados se traduzem em desempenho útil para o corpus em questão. A comparação com alternativas e a avaliação do reranking complementam a decisão; nenhuma cifra isolada de parâmetros ou benchmark substitui essas medições.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.