NeoMME's 260M encoder lands within 0.002 of a 3.75B model on ViDoRe v3

Searching scanned pages usually means one of two bad deals: run OCR and lose the layout, or run a large vision-language model and pay for it on every page you index. NeoMME is an argument that the second deal is no longer necessary, and the numbers behind that argument are specific enough to check.

What was released

NeoMME is a family of two multimodal encoders, at 260M and 800M parameters, published on September 3, 2026 by H company. Every checkpoint is under the Apache 2.0 license and the model loads through Hugging Face Transformers, which puts it in the category of things you can actually deploy rather than read about.

Architecturally it drops the usual assembly. There is no separately pretrained vision tower and no causal decoder: a single bidirectional Transformer takes text tokens and raw 32×32 image patches through the same path. Both sizes carry a 16,384-token context, which the authors note is enough for two 4K images, and images keep their aspect ratio so a dense document page gets more tokens than a sparse photo.

The retrieval numbers

On ViDoRe v3, measured with nDCG@10, the 260M retriever reaches 0.523. ColQwen2.5, at 3.75B parameters, reaches 0.524. The comparison in the same table is more striking against similar sizes: ColModernVBERT at 250M scores 0.261 and ColSmol-256M scores 0.207. The 800M model reaches 0.556, against 0.565 for the 850M Vultron Flash and 0.430 for the 2.92B ColPali v1.3.

Throughput is the other half. At a matched 2048×2048 input on one NVIDIA L40S, the 260M model encodes about 51 pages per second, against about 26 for ColModernVBERT. Indexing cost is where retrieval projects usually die, so twice the pages per GPU-hour is not a footnote.

These are the vendor's own evaluations, with some comparison scores taken from MTEB. No independent reproduction has been published, and the throughput figures come from preprocessed tensors with batch size tuned per model, which is a favorable and clearly stated setup.

The storage problem, and their answer to it

Late-interaction retrieval stores one vector per patch, so a high-resolution page is expensive to keep. A 2048×2048 page produces 4,200 vectors, and across ViDoRe v3 the measured average is about 1.5 MB per document. That is the number that decides whether a corpus of a million pages is a project or a budget line.

Two compression methods are applied together. Hierarchical token pooling merges similar vectors, and asymmetric quantization stores documents at int8 or binary while keeping the query side at higher precision, since queries are generated on the fly and never stored. At pooling factor 10 with int8 on both sides the index drops to 39 kB per page, a 39-fold reduction, keeping more than 99% of baseline quality. Pushing to binary documents gives 6 kB per page, 255 times smaller, keeping more than 95%.