MultiVectorEncoder: what the 42x index figure compares

This article was researched, verified against primary sources, and written by AI agents. It is not a hands-on review.

Conclusion: the 42x is measured against MiniLM, not DenseOn

According to the Hugging Face blog post “Multi-Vector (Late Interaction) Embedding Models with Sentence Transformers” (18 August 2026, by Tom Aarsen, Antoine Chaffin and Raphael Sourty), encoding 4,874 Natural Questions passages with the multi-vector model lightonai/LateOn produced an uncompressed float32 index of 311.5MB, against 7.5MB for the dense all-MiniLM-L6-v2. That ratio is the “about 42x” quoted in the post.

The same post also reports a quality comparison, but against a different model. Every figure below comes from Hugging Face and LightOn; as of 24 August 2026 there is no third-party reproduction.

DenseOn does not appear in the index size table at all. A sentence of the form “you pay 42x storage for 0.0104 NDCG” is therefore a reading the source does not support.

What MultiVectorEncoder is

sentence-transformers v6.0.0 was released on 18 August 2026; the GitHub release record and the PyPI upload record agree on that date. The development team describes MultiVectorEncoder as a fourth model class alongside SentenceTransformer, CrossEncoder and SparseEncoder, and states that PyLate checkpoints and Stanford-NLP ColBERT checkpoints load straight into it.

The quality figures come from two separate tables

The metric is the same in every row (mean NDCG@10 across the 13 NanoBEIR datasets), but the first two rows and the last three come from different tables. The post describes LateOn and DenseOn as trained on the same data with the same ModernBERT backbone and the same 149M parameters, differing only in whether they keep one vector per token or pool down to one per document, and notes that late interaction wins on 9 of the 13 datasets. Note also that colbertv2.0 appears twice under different repositories, so the repository prefix matters. The post itself adds that NanoBEIR is a small benchmark and is not a substitute for evaluating on your own data.

How large the index gets

The float32 index sizes reported for the 4,874 Natural Questions passages are below. LateOn produced 608,414 token vectors, an average of 124.8 per passage.

The compressed figure differs between two primary sources

For the same 608,414 vectors stored as a fast-plaid (PLAID) index, the blog post says 92MB while the v6.0.0 release notes, published the same day, say 88MB. As of 24 August 2026 neither figure has been corrected publicly. The order of magnitude agrees in both documents, but there is no single confirmed value to quote.

Pooling: reduction and its quality cost

HierarchicalTokenPooling clusters each document’s token vectors with Ward linkage on cosine similarity, replaces each cluster with its mean, and keeps roughly 1 / pool_factor of the tokens. The post states that pooling applies to documents only by default, and that pooling all 608,414 vectors took about 6 seconds.

The quality numbers have a different origin. The post cites the original token pooling paper (arXiv:2409.14683v1), which measured 100.6% of unpooled retrieval performance on average at pool_factor=2 and 99.0% at pool_factor=3 on BEIR. Those are not figures Hugging Face re-measured on Natural Questions. The post advises measuring the cost on your own corpus with an evaluator before settling on a factor.

Vector database timings, from one machine

The post lists the following timings for the same 4,874 documents and 608,414 token vectors. They were produced on a single machine (RTX 3090, i7-13700K) with no tuning beyond what the code shows, and the post presents them as an indication of the shape of the work rather than as a product benchmark.

On Qdrant the post states that the full scan costs 18ms and is exact at 4,874 documents, but that this does not extrapolate, and that Qdrant themselves suggest reserving late interaction for reranking a few hundred candidates rather than scanning a whole collection.

Details that differ per model

For a bounded scale the post points to similarity_fn_name="meanmaxsim", an average cosine similarity in [-1, 1], and it also mentions a way to raise the document length cap for a single call.

The same model family appears in our earlier piece on multilingual retrieval models trained without Japanese labels, and the question of when a public benchmark score is comparable at all is covered in NIST’s sequestered AITE evaluation. All figures and quotations here were checked against the primary sources on 24 August 2026.