What is NVIDIA Nemotron 3.5 Embed 8B?
Nemotron-3.5-Embed-8B-BF16 is an 8.38-billion-parameter embedding model provided by NVIDIA. Unlike a conversational language model, it does not write answers or complete prompts. Its job is to convert queries and documents into numerical representations called embeddings, or vectors. Texts with related meaning are placed near one another in this vector space, allowing a search system to retrieve relevant material by semantic similarity rather than exact keyword matching.
The model is designed specifically for multimodal document retrieval. It can represent ordinary text, document images, or a combination of text and an image. This is useful when important information is contained in a table, chart, infographic, datasheet, scanned page, or engineering schematic that a text-only extraction pipeline may not capture reliably.
NVIDIA positions the model for semantic search, retrieval-augmented generation (RAG), agentic retrieval, visual document search, and enterprise question-answering systems. The checkpoint is available through Hugging Face, and NVIDIA also offers access through a NIM endpoint.
How the model processes documents
A typical retrieval pipeline uses the model twice. During indexing, a document or document page is converted into an embedding and stored in a vector database. When a user submits a text question, the question is converted into another embedding. The system then searches for document vectors that are closest to the query vector and passes the retrieved evidence to a separate generative model if a written answer is required.
Nemotron-3.5-Embed-8B-BF16 supports text-only queries. Document representations can contain text, an RGB image, or both text and an image. This asymmetric design matters: the model is intended to let a user ask a text question and retrieve visually rich documents, rather than to perform unrestricted image-to-image or image-query search.
Images normally use a longest edge of 1,120 pixels, with support for increasing the longest edge to 1,540 pixels. Image preprocessing, batching, GPU hardware, and the serving framework can affect both latency and throughput.
Verified specifications and supported modalities
| Specification | Details |
|---|---|
| Provider | NVIDIA |
| Model | Nemotron-3.5-Embed-8B-BF16 |
| Model type | Multimodal embedding model |
| Parameters | 8.38 billion |
| Maximum context | 32,768 tokens, including text and image tokens |
| Default embedding output | One L2-normalized vector with 4,096 dimensions per input |
| Reduced embedding sizes | Supports truncation to sizes such as 1,024 or 512 dimensions, followed by re-normalization |
| Text input | Supported |
| Image input | RGB document images supported |
| Audio and video input | Not supported |
| Generated text, images, audio, or video | Not supported |
| Output limit | No generative output-token limit; the native output is an embedding vector |
The 32,768-token context limit applies to the combined representation of text and image content. It should not be interpreted as a maximum answer length, because the model does not generate prose. Its output is a fixed-size embedding representation, with 4,096 dimensions by default.
Architecture and model lineage
The model combines a vision encoder initialized from Ministral-3-8B-Instruct-2512-BF16 with a language-model component initialized from NVIDIA's Nemotron-3-Embed-8B-BF16. NVIDIA states that the language component remains frozen while the vision encoder and multimodal projector add visual document retrieval capability.
According to NVIDIA, the preserved text component means that text embeddings are identical to those produced by the corresponding Nemotron 3 Embed model. This can be useful for an organization that already has a text-retrieval index and wants to extend its system to visual documents without changing the behavior of text embeddings. The claim concerns the model's text-embedding behavior; it does not mean that existing text indexes automatically contain image-based evidence.
Main strengths for enterprise retrieval
- Visual document coverage: tables, charts, infographics, datasheets, and schematics can be represented alongside ordinary text.
- Shared retrieval space: a text query can retrieve text passages as well as image or image-text document representations.
- Multilingual scope: NVIDIA describes evaluation across 34 languages for text retrieval and 18 languages in visual retrieval benchmarks.
- High-dimensional default output: 4,096 normalized dimensions provide a detailed representation for systems that can support larger vectors.
- Flexible storage trade-off: vectors can be truncated to smaller dimensions such as 1,024 or 512, provided they are re-normalized before similarity search.
- Deployment options: the model can be used through NVIDIA NIM, Hugging Face Transformers, Sentence Transformers, and vLLM workflows.
These strengths make the model particularly relevant when retrieval quality depends on the visual layout or content of a page, not only on text extracted by optical character recognition or PDF parsers.
Limitations and trade-offs
Nemotron-3.5-Embed-8B-BF16 is not a general-purpose assistant. It cannot directly explain a retrieved chart, answer a question in natural language, call tools, or perform visual question answering by itself. A complete application normally combines it with document processing, a vector database, and a separate generative model.
Queries are text-only according to the supplied model information. Image inputs are intended for document representations, so teams needing image-based queries should verify whether a different model or an additional retrieval stage is required. The model also does not provide audio or video capabilities.
Its 8.38-billion-parameter size and multimodal processing requirements may make it more demanding to serve than a smaller text-only embedding model. The supplied editorial assessment rates its relative speed at 6 out of 10 and cost at 6 out of 10. These are editorial scores, not NVIDIA benchmark results or published pricing metrics. Actual performance will depend on hardware, batching, image resolution, concurrency, and the selected serving stack.
Reduced vector dimensions can lower storage and search costs, but truncation changes the representation. NVIDIA's guidance in the supplied research requires re-normalizing truncated vectors before similarity search. Teams should validate retrieval quality at the chosen dimension rather than assuming that a smaller vector will behave identically to the full 4,096-dimensional output.
Pricing and availability
The model is available as an open checkpoint under NVIDIA's OpenMDW License Agreement, version 1.1, and through an NVIDIA NIM endpoint. The supplied research identifies a free NVIDIA trial endpoint but does not provide an official recurring per-token price for self-hosted use. Self-hosting therefore has no stated vendor per-token price in the available information, although organizations still incur infrastructure and operational costs.
Commercial users should review the OpenMDW-1.1 license before deployment, redistribution, or modification. Availability through a checkpoint and a hosted NIM endpoint provides deployment flexibility, but the operational, licensing, and cost implications differ between those choices.
Reasoning, coding, and tool support
This model does not reason in the conversational sense, generate code, or use external tools. Its role is to calculate embeddings that another application can use for retrieval. The supplied editorial scores assign reasoning and coding scores of 1 out of 10, reflecting that the model is not designed for those tasks rather than indicating a failure of its intended embedding function.
It also does not expose conversational streaming, function calling, structured text output, or web search as model capabilities. If an application needs an agent to plan actions, call databases, browse the web, or produce JSON responses, those responsibilities must be handled by other components.
Best use cases
- Enterprise PDF search where pages contain both prose and visual information.
- Multimodal RAG over reports, technical manuals, financial documents, and product documentation.
- Retrieval of charts, tables, infographics, datasheets, and engineering schematics.
- Multilingual semantic search across mixed text and visual document collections.
- Agent memory and evidence retrieval where an agent needs to locate supporting documents before taking an action.
- Domain-specific retrieval systems that can use NVIDIA's fine-tuning recipes for adaptation to specialized relevance requirements.
When to choose this model
Choose Nemotron-3.5-Embed-8B-BF16 when retrieval quality over visual documents is more important than using the smallest or simplest embedding service. It is a strong fit for organizations whose source material includes pages that lose meaning when reduced to plain extracted text, and for teams that need multilingual retrieval across a broad document collection.
A smaller text-only embedding model may be more appropriate when all documents are clean text, the application has strict latency or infrastructure constraints, or vector storage must be minimized. A generative multimodal model is more appropriate when the system must directly interpret an image, explain a chart, or answer a visual question. In that architecture, Nemotron-3.5-Embed-8B-BF16 can still serve as the retrieval stage, while a separate model performs generation and reasoning.
For existing Nemotron text-embedding deployments, the preserved text behavior described by NVIDIA may make this model worth evaluating as an extension for visual documents. However, teams should test end-to-end retrieval quality, image preprocessing, serving throughput, vector-database cost, and licensing requirements on their own data before migrating a production index.