Nemotron 3.5: When Document Search Needs Page Images

On October 20, 2026 NVIDIA published three retrieval models on Hugging Face, Nemotron 3.5 Embed 8B, Embed 1B and Rerank 8B, and on October 21 described them alongside a 631-million-parameter document parser in a launch post. The common idea is visual document retrieval: instead of extracting text from a PDF and embedding the text, the embedding model takes the rendered page image, or the image plus its text, and produces one vector that a plain text query can be matched against. The reranker then scores each query and candidate page together, image included, to put the right evidence first.

That is a different thing from image generation, and the word "image" in the model cards invites confusion: these models read pages, they do not draw them. It is also a different thing from a general upgrade to search. Most document corpora are mostly text, and for those the pipeline in our hybrid search reference still applies unchanged. Visual retrieval earns its place where text extraction fails, and extraction fails in three specific ways: it loses what a chart conveys, it separates table values from their headers and reading order, and it finds nothing at all in a scan with no text layer.

This post uses the Nemotron 3.5 family to explain which of those failures each layer of a document pipeline addresses: visual embeddings at indexing time, a multimodal reranker at query time, and a parser that produces structure for everything downstream of search. It reads the cards for what they specify, labels NVIDIA's benchmarks as NVIDIA's, and ends with a decision grid for a team deciding whether to touch a working text pipeline at all.

The three Hugging Face cards share a release date of October 20, 2026, a licence, and an input contract, and differ in size and role. The two embedding models are bi-encoders: they turn each document and each query into a vector separately, so a corpus can be indexed once and searched cheaply. The reranker is a cross-encoder: it reads one query and one candidate document together and returns a raw relevance logit, which is more accurate and far more expensive per document, so it runs only over the shortlist the embedding search returns. Parse is not a retrieval model at all; it converts page images into Markdown, HTML tables and structured blocks with their positions and reading order.

An example of the three jobs in one pipeline. A compliance team indexes ten years of supplier audit reports, half of them scanned. Embed 1B vectorises every page as an image overnight. At query time a question about a specific control pulls fifty candidate pages by vector similarity; Rerank 8B reorders them so the page with the relevant table comes first; Parse turns that one page into a table the answer can cite by row. Each model does a job the others cannot, and a team can adopt one without the others.

The failure case is treating the family as a single upgrade switch. The 8B and 1B embedding models produce vectors of different lengths in different spaces; an index built with one cannot be queried with the other. The reranker's lift depends on the candidate set it is handed, and the parser's output is only useful if something downstream consumes structure. Buying all four for a corpus that is clean text with a working search stack adds cost at three layers and fixes a failure the corpus does not have.

NVIDIA's launch post names the failures plainly in its section on Parse: a PDF's embedded text can lose reading order, separate table values from their headers, and omit what a chart conveys, and a scanned or image-based PDF may have no usable text layer at all. Those are the conditions under which a text-only index returns the wrong page or no page, and they are worth stating as symptoms, because a team usually meets them as complaints before it meets them as architecture.

An example of each. A finance analyst asks for "the quarter where gross margin dipped below thirty percent"; the answer is a bar in a chart with no caption and no number in the text, so the text index has nothing to match. A procurement agent asks for a supplier's lead time; the extracted text has the value in one paragraph and the column header three paragraphs away, so the chunk that matches the query does not contain the number. A claims team searches a decade of faxed forms; the PDFs are images, the text layer is empty, and the index is empty with it.

The failure case on the other side is assuming every corpus has these problems. A knowledge base of Markdown runbooks, a ticket archive, a contract repository that was born digital with clean tables: these have reading order, headers next to values and a full text layer. For them the symptom a user reports is poor ranking or missing synonyms, which is a text-retrieval problem with text-retrieval fixes. The diagnosis step in our guide to reranking versus re-indexing applies before any decision about page images.

The Embed 8B card sets the contract. For documents the model accepts an image, text, or image plus text; for queries it accepts text only. The default image longest edge is 1,120 pixels and can be raised to 1,540, and the maximum context is 32,768 tokens, which the vLLM notes make explicit includes image tokens. Each input becomes one 4,096-dimensional vector, mean-pooled and L2-normalised, and the card says the vector can be truncated from the end, to 1,024 or 512 dimensions for example, and remain effective if normalised again. The 1B model follows the same rules at 2,048 dimensions, and was distilled from the 8B.

The card's own evaluation table is the place to read the numbers, with its setup. On ViDoRe V3, a visual document retrieval benchmark across professional domains, NVIDIA reports nDCG@10 of 60.39 for image-only documents, 60.65 for text-only and 61.47 for image plus text with Embed 8B, and 58.02, 57.80 and 58.82 with Embed 1B, against 58.29, 53.69 and 57.03 for Qwen3-VL-Embedding-8B at a different image resolution setting. Two things to take from that: image plus text is the strongest input for both Nemotron sizes, and the 1B model sits within about three points of the 8B on this benchmark. The launch post's ViDoRe v3.1 leaderboard position is a separate claim we have not re-read.

The failure case is the context window. A scanned A4 page at the default edge is a fixed token cost; a long multi-page document supplied as one image, or a page at the 1,540-pixel maximum with its full extracted text appended, can exceed 32,768 tokens, and the card's serving notes say to reduce image resolution when the image tokens alone exceed the limit. Index per page, decide the edge length once for the whole corpus, and keep it fixed, because a vector from a page rendered at 1,120 pixels and one rendered at 1,540 are not the same vector.

The Rerank 8B card describes a cross-encoder with a Pixtral-based vision encoder and a bidirectional Ministral 3 language tower, derived from a Ministral 3 8B Instruct backbone; the launch post says it uses the same backbone architecture as Embed 8B. Each input is one text query paired with one document, which may be an image, text or both, and the output is a raw logit: higher means more relevant, and the card notes the value is not a probability. It serves through Transformers, PyTorch and vLLM, and its context limit is the same 32,768 tokens including image tokens, which bounds how much of a long page can be scored alongside the query.

The card's evaluation is the clearest single figure in the whole release, because it isolates the reranker's contribution. NVIDIA retrieved the top 50 candidates with Embed 1B and then reranked them. On ViDoRe V3 with image plus text inputs, Embed 1B alone scores 58.82 nDCG@10; after Rerank 8B reorders the fifty, the figure is 67.56, and the comparison reranker, Qwen3-VL-Reranker-8B, reaches 66.03 on the same candidates. The lift from reranking is close to nine points; the gap between the two rerankers is about one and a half. For a team deciding where to spend, that ordering of effects matters more than which reranker wins.

The failure case is the candidate set. A reranker can only promote pages the embedding search returned. If the chart page never made the top 50 because it was indexed as empty text, no reranker recovers it; that is the indexing failure from section three, and it needs the visual embedding, not the reranker. The launch post's claim that adding the reranker cuts agent inference tokens per query by roughly 14 percent with the 8B embedder and 13 percent with the 1B is NVIDIA's measurement on its own agent pipeline, with the model, tools and tasks fixed; it is a plausible mechanism, better evidence earlier means fewer repeated searches, and a number to reproduce on your own agent rather than to quote.

Visual embeddings find the page; they do not tell the application what is on it in a form it can compute with. That is the parser's job, and the launch post describes Nemotron 3.5 Parse, at 631 million parameters, as converting document images into machine-readable text that keeps the structure: it identifies elements, their locations and reading order, and extracts tables and charts into structured representations that come out as Markdown, HTML tables and blocks. The post also describes three processing modes, single, double and triple pass, where the extra passes revisit tables and charts, and quotes its own ParseBench scores of 72.74, 74.92 and 75.20 at 16.1, 11.2 and 10.5 pages per second on one H100.

An example of why search alone is not enough. An agent asked which products risk a stockout next quarter, the launch post's own scenario, needs demand forecasts from charts, inventory levels from tables and lead times from reports, and then has to compute with them. A reranked page image gives the agent the right page; Parse gives it the table as rows it can read and a location it can cite. Where the output feeds a text-only model, a spreadsheet, or a citation that must point at a cell, the parser is the layer doing the work. Our look at Mistral's OCR 4 covers the same job from a hosted-API angle.

The failure case is parsing everything up front because the parser exists. At ten to sixteen pages per second on one H100, a million-page archive is roughly seventeen to twenty-seven hours of processing before anyone has searched anything, and most of those pages will never be retrieved. The cheaper design embeds every page as an image, and parses on demand the handful of pages a query actually returns, or parses up front only the document classes, such as tables and forms, where structured output is known to be needed.

The most operationally interesting sentence in the cards is about what did not change. The language component of each 3.5 embedding model was initialised from the corresponding Nemotron 3 Embed model and kept frozen; only the vision encoder and the projector were trained. The 8B card states that the two models therefore share the same embedding space and produce identical text embeddings, and the launch post draws the conclusion: existing text embeddings and vector indexes built with Nemotron 3 Embed can be reused. For a team already on that family, this is the difference between a migration and an extension.

An example of what that enables. A team with a Nemotron 3 Embed 8B index over a million text chunks adds a scanned-document archive. Instead of re-embedding the million chunks, it embeds only the new pages as images with Embed 8B and writes them into the same index, where text queries already live. If the card's claim holds, text-to-text results are unchanged and the scans become searchable alongside them. The same holds for the 1B pair, and not across sizes: a Nemotron 3 Embed 1B index does not accept Embed 8B vectors.

The failure case is skipping the check. "Identical" is a property of the frozen weights, and the embedding a system produces also depends on the serving stack, the tokenizer version, the truncation setting and the dimension count. A team that truncated its old index to 1,024 dimensions must truncate the new vectors the same way and re-normalise, exactly as the card specifies. The method in our controlled migration guide still applies: embed a labelled sample with both models through the stack you run, compare the vectors and the rankings, and only then write into the live index.

The cards' example code assumes an NVIDIA GPU: the bfloat16 Transformers examples raise an error without CUDA, and the vLLM examples pin specific library versions and ask for a separate environment from the Transformers one. The choice between 8B and 1B is the choice between about three points of nDCG@10 on the card's benchmark and a model roughly a fifth of the size with half the vector length, which halves index storage. The launch post adds a third option for the 1B model: an NVFP4 variant it says raises throughput by 27.1 percent on a GB200, from 101.3 to 128.8 documents per second, while keeping 99.85 percent of the accuracy. Those are NVIDIA's numbers on NVIDIA's hardware.

An example of sizing. A corpus of two million pages embedded at 4,096 dimensions in 16-bit floats is roughly 16 gigabytes of vectors before any index overhead; at 2,048 dimensions it is about 8, and truncating the 8B vectors to 1,024 brings it to 4, which is the arithmetic behind the card's dynamic embedding sizes. The reranker adds no storage and all of its cost at query time, fifty pair encodings per query at up to 32,768 tokens each, which is why it belongs behind a cache and in front of only the queries that reach an agent or a person.

The failure case is planning on a hosted price that does not exist. NVIDIA's post points to Hugging Face weights, its own NIM serving path and named partners; our October 26 catalogue snapshot showed free routes for the three retrieval models on one router, which is a listing and not a price promise. Treat the models as self-hosted for budgeting, use our embedding cost calculator for the hosted alternatives, and remember that a page image costs more tokens to embed than its extracted text would.

The decision follows the symptom. If users cannot find answers that live in charts, infographics or scans, the index is missing them and the fix is at indexing time: embed pages as images, with Embed 1B for scale or 8B for the last few points, and keep the text index you have if it is on the Nemotron 3 family. If the right page is usually in the top fifty and rarely in the top five, recall is fine and ordering is not; add Rerank 8B over the shortlist and change nothing in the index. If the application needs rows, columns, reading order or a citation to a position on the page, that is Parse, applied to the pages search returns.

For a corpus that is born-digital text with a working search stack, the answer is to change nothing on the strength of this release. The failures these models address are absent, the cost is present at every layer, and the risk of a migration without a symptom is a regression nobody asked for. This is the triage our AI transformation team runs before recommending a retrieval change: find the failing queries, classify the failure, and touch only the layer that owns it.

The failure case in the decision itself is the leaderboard. The launch post reports first places on ViDoRe v3.1 for the 8B embedder and the reranker as of October 20, and NVIDIA's own figures for another multilingual benchmark differ between its own pages, which is why this post prints none of them. A rank on a public benchmark says a model is competitive; it does not say your corpus has the failure the benchmark measures. Measure the failure first, then test the model that fixes it on a sample of your own pages.