Nemotron 3.5 Embed 1B BF16: Analysis of capabilities, limits, and cost

What the exact model does

Nemotron 3.5 Embed 1B BF16 is a 1.55-billion-parameter embedding model developed by NVIDIA for multimodal and multilingual document retrieval. Unlike its purely textual predecessors, this model accepts documents as images, text, or a combination of both, while search queries are limited exclusively to text.

The architecture combines a Pixtral vision encoder, initialized from Ministral-3-3B-Instruct-2512-BF16, with a language model initialized from Nemotron-3-Embed-1B-BF16. During the distillation process from the Nemotron-3.5-Embed-8B-BF16 teacher model, the language component was kept frozen. This means the textual embedding space is identical to that of Nemotron 3 Embed 1B, but with the addition of visual retrieval capabilities.

The roles of query and document are asymmetric. The query is textual, while an indexed document can provide text, a page image or both. Visual processing therefore expands the kinds of document that can be represented; it does not turn the model into a chatbot or a system that writes the final answer. Its vectors are part of a retrieval system. Whether a relevant page is found also depends on which pages were indexed and how the results are evaluated.

The frozen language component and the added visual processing need separate interpretations. Compatibility of the text embedding space concerns text representations under the corresponding conditions. It does not establish that every existing search system improves or that every combination of text and image performs identically. An integration needs to identify how documents will be prepared and whether the resulting representations are suitable for its intended queries. Compatibility is a technical property to preserve, rather than a substitute for evaluating relevance.

Capabilities and examples by task

The model is designed for Retrieval-Augmented Generation (RAG) and semantic search workflows where documents are not just plain text, but PDF pages, infographics, or scanned tables. The ability to process page images directly allows capturing structural and visual information that would be lost in traditional OCR extraction.

For queries, the model uses a 'query:' prefix, and for documents, a 'passage:' prefix. This distinction is crucial for performance, as the model was trained to treat search intent and document content asymmetrically. Images are processed with a default longest edge of 1,120 pixels, expandable up to 1,540 pixels, which directly affects the token consumption of the context.

A page image can contain layout and visual information that is missing or represented differently in extracted OCR text. That additional input does not prove that every detail will reliably influence retrieval. Tables and infographics should therefore be tested with concrete queries and relevant pages. The prescribed query and document prefixes belong to input preparation; they do not replace checking the results. The shared context limit also matters when preparing the text and image together, because neither input has unlimited independent capacity.

Benchmarks and published methodology

NVIDIA reports results on two main benchmarks: ViDoRe V3 for visual document retrieval and MIRACL-VISION for multilingual visual retrieval. The metric used is NDCG@10, which evaluates the quality of retrieving the 10 most relevant documents.

It is important to note that these results are provided by the provider and have not been independently reproduced by third parties at the time of writing this analysis. The results show that the 1B model outperforms 2B models from other families in several categories, although the 8B model from the same NVIDIA family achieves slightly higher scores.

Benchmark results describe performance on the corresponding dataset and evaluation procedure. A higher score than a listed comparator does not establish an unrestricted advantage on other documents, languages or tasks. The modalities and benchmarks should be read separately rather than turning one column into a universal ranking. Vendor-reported results can motivate a comparison, but an independent reproduction or measurement for the team’s corpus exists only after that evaluation has actually been performed. The relevance criteria and conditions should remain visible beside the conclusion.

Pricing and deployment requirements

The model is publicly available on Hugging Face under the OpenMDW 1.1 license, which allows commercial use subject to the terms of that license. There is no official NVIDIA API for this specific model, so the main cost is the GPU infrastructure required for its execution.

For deployment, NVIDIA recommends GPUs from the Ampere, Hopper, or Blackwell architectures. The optimized configuration for the BF16 checkpoint uses FP16 precision for inference, although the checkpoint is stored in BF16. The model requires a minimum of 8 CPU cores and supports Multi-Instance GPU (MIG) in certain hardware configurations.

Available weights and permission to use them are different from the cost of operating the model. A self-hosted deployment needs compute resources and integration work even when downloading the checkpoint does not incur a usage-based API fee. Hardware compatibility and inference precision must match the chosen configuration. A memory specification alone does not determine response time or throughput under the intended load. Comparing deployment options therefore requires observations under comparable conditions as well as the applicable terms of each service or installation.

Limitations, security, and alternatives

The main limitation is the maximum context of 32,768 tokens, which is shared between text and image tokens. If a high-resolution image consumes most of this context, the space available for text is significantly reduced. Furthermore, the model does not guarantee retrieving the correct document for a given query, so it must be integrated into a RAG pipeline with reranking stages.

Regarding security, NVIDIA warns that developers must verify the rights of input images and consider bias and privacy risks. The model does not include specific bias mitigation mechanisms, so its use in sensitive contexts requires additional evaluation.

The shared context limit means text and image cannot both be expanded without constraint. The integration needs to decide which information must remain available when inputs are reduced. A request that completes technically does not show that all relevant details influenced the resulting search representation. Security is a separate question: input image rights, potential bias and privacy still need assessment. Neither a good search result nor an available model license automatically resolves those obligations, and the application must retain controls appropriate to the documents it handles.

Practical selection criteria

Choosing Nemotron 3.5 Embed 1B BF16 over other options depends on several factors. If the document corpus includes a significant proportion of images, tables, or infographics, this model offers a clear advantage over purely textual embedding models. Its 1B parameter size makes it more efficient in terms of latency and GPU cost than the 8B model, with a moderate performance loss.

For teams already using Nemotron 3 Embed 1B for text, migration to the 3.5 version is direct in the textual embedding space, facilitating integration. However, if the use is exclusively textual and the GPU budget is limited, it might be worth considering keeping the previous model or exploring third-party alternatives with lower API prices.

The smaller variant is a candidate when available GPU resources or operating cost make the larger model impractical. Whether that trade-off is acceptable must be checked with the same queries and relevance criteria. A text-only collection presents different needs from pages whose visual layout carries important information. The choice should start with the documents and required outcomes, then consider retrieval quality, runtime and operating cost together. A general size advantage does not replace evidence for the configuration that will actually be used.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.