H Company veröffentlicht NeoMME, eine Open-Source-Multimodal-Encoder-Familie

Forscher von H Company veröffentlichten NeoMME am 3. September 2026, eine Familie von multimodalen und mehrsprachigen Encodern mit 260 M‑ bzw. 800 M‑Parametern, die von Grund auf trainiert und unter der Apache‑2.0‑Lizenz veröffentlicht wurden. Feinabgestimmte Retrieval‑Varianten liegen laut Team auf der Modellgrößen‑Pareto‑Front des ViDoRe‑v3‑Benchmarks für visuelle Dokumenten‑Retrieval.

Laut dem Release‑Post werden viele aktuelle Visual‑Document‑Retriever aus vortrainierten generativen Vision‑Language‑Modellen adaptiert, bei denen ein separat vortrainierter Vision‑Encoder visuelle Merkmale erzeugt, die ein Projektor in den Eingaberaum eines kausalen Sprachmodells überführt. Retrieval, Klassifikation und Token‑Labeling erzeugen keinen Text autoregressiv, schreiben die Autoren, sodass diese Aufgaben keinen kausalen Decoder oder dessen Parameter‑ und Rechen‑Overhead benötigen. NeoMME verarbeitet stattdessen Text‑Tokens und rohe Bild‑Patches durch einen gemeinsamen bidirektionalen Transformer und basiert nicht auf einem bestehenden vortrainierten Vision‑Tower, Text‑Encoder oder Text‑Decoder.

Der Beitrag stellt das Design gegenüber zwei früheren Encoder‑Ansätzen: ModernBERT, das Effizienzverbesserungen für bidirektionale Text‑Encoder brachte, und ModernVBERT, das einen ModernBERT‑ähnlichen Text‑Encoder für die visuelle Dokumenten‑Retrieval einsetzte und dabei einen separaten vortrainierten SigLIP2‑Vision‑Tower beibehielt. Die Autoren schreiben, dass sie den Overhead vermeiden wollten, der entsteht, wenn Komponenten eines Vision‑Language‑Modells in einen Encoder integriert werden.

Architektur und von Grund auf neu trainiertes Pre‑Training

Beide NeoMME‑Größen teilen dieselbe Architektur. Texteingaben verwenden faktorisierte Token‑Einbettungen, während Bilder in ein Raster aus nicht‑überlappenden 32 × 32‑Patches aufgeteilt und mit einem kleinen mehrlagigen Perzeptron projiziert werden; beide gelangen anschließend in denselben Transformer‑Encoder. Bilder behalten ihr Seitenverhältnis und ihre Größe bei, sodass das Modell mehr Tokens für eine hochauflösende, informationsdichte Dokumentenseite verwenden kann als für ein kleineres Bild. Die Kontextlänge beträgt 16 384 Tokens, ausreichend für bis zu zwei Standard‑3840 × 2160‑4K‑UHD‑Bilder. Die meisten Schichten nutzen symmetrische Sliding‑Window‑Attention, während jede sechste Schicht und die letzte Schicht globale Attention einsetzen. Der Stack enthält zudem Grouped‑Query‑Attention, Query‑Key‑Normalisierung, Gated‑Attention, 2D‑Rotary‑Position‑Embeddings und squared‑ReLU‑MLPs. Für Text trainierte das Team von Grund auf einen BPE‑Tokenizer mit einem Vokabular von 131 072 Tokens auf mehrsprachigem Text, Code, Mathematik und maschinell erzeugten Bild‑Transkripten.

NeoMME wird von Grund auf als diskreter maskierter Diffusions‑Text‑Denoiser vortrainiert. Für rein textbasierte Beispiele wird eine Korruptionsrate gleichmäßig zwischen 0 und 1 gezogen, und jedes geeignete Text‑Token wird unabhängig mit dieser Rate maskiert. Multimodale Beispiele verwenden Korruptionsraten zwischen 0,3 und 1, wobei die Bild‑Patches sichtbar bleiben, während das Modell den maskierten Text rekonstruiert; die Autoren schreiben, dass starkes Maskieren das Modell zwingt, bildbasierte Beschreibungen zu lernen, anstatt sich auf rein sprachliche Abkürzungen zu verlassen. Das Pre‑Training kombiniert mehrsprachigen Text, Code, Mathematik, natürliche Bilder und Dokumenten‑Bilder, und jedes Modell verarbeitet etwa 524 Milliarden gepackte Eingabe‑Tokens, darunter 290 Milliarden aus rein textbasierten Beispielen. Da dieses Text‑Budget im Vergleich zu ModernBERTs 2 Billionen Trainings‑Tokens klein ist, schreiben die Autoren, dass sie den NorMuon‑Optimizer gewählt haben, um die Dateneffizienz zu steigern.

Retrieval‑Feinabstimmung und Benchmark‑Ergebnisse

Um das Backbone für eine nachgelagerte Aufgabe zu bewerten, feinteilte das Team es für die visuelle Dokumenten‑Retrieval mithilfe der von ColPali eingeführten Seiten‑Bild‑Methodik. Anstatt extrahierte Text‑Chunks abzurufen, rankt NeoMME‑Retriever Screenshots von Dokumentenseiten, um die OCR‑Vorverarbeitung zu umgehen und Layout, Diagramme, Tabellen sowie Typografie zu erhalten. Der Retriever fügt dem Backbone zwei gemeinsam trainierte Köpfe hinzu: einen dichten Kopf, der versteckte Zustände mittels Mittelwert‑Pooling in einen normalisierten Vektor überführt, und einen Late‑Interaction‑Kopf, der jedes Text‑Token oder Bild‑Patch in einen 128‑dimensionalen normalisierten Vektor projiziert und feinkörnige Übereinstimmungen zwischen Abfrage‑Tokens und Bild‑Regionen bewahrt. Ein Forward‑Pass liefert beide Repräsentationen. Die Autoren empfehlen generell Late‑Interaction‑Embeddings sowie eine Pipeline aus dicker Retrieval gefolgt von Late‑Interaction‑Reranking für sehr große Korpora.

Im ViDoRe‑v3‑Benchmark berichtet der Beitrag von einem nDCG@10 von 0,523 für NeoMME‑Retriever‑260M, dem höchsten Ergebnis unter den evaluierten Modellen mit strikt weniger als 800 M‑Parametern und nur 0,002 hinter ColQwen2.5, bei etwa 14‑mal weniger Parametern. NeoMME‑Retriever‑800M erreicht 0,556, nur 0,009 hinter dem ähnlich großen Vultron Retriever Flash, und beide Modelle liegen auf der Modellgrößen‑Pareto‑Front des Benchmarks. Die Vergleichstabelle des Beitrags kennzeichnet die Konkurrenzwerte als aus MTEB stammend und die NeoMME‑Werte als eigene Evaluierungen des Teams. Auf den älteren ViDoRe‑v1‑ und v2‑Benchmarks, die nDCG@5 verwenden, berichtet der Beitrag, dass das 260 M‑Modell ColModernVBERT sowie das doppelt größere ColSmol‑500M übertrifft, während das 800 M‑Modell ColPali v1.3 mit 3,6‑mal weniger Parametern übertrifft.

Die Model‑Card für NeoMME‑260M‑Retriever listet 263 M‑Parameter, eine versteckte Größe von 1 024, BF16‑Gewichte und 1 024‑dimensionale dichte Embeddings mit Matryoshka‑Trunkierungs‑Punkten bei 128, 256, 512 und 1 024 Dimensionen sowie den 128‑dimensionalen Multi‑Vector‑Ausgang auf. Die Karte berichtet zudem Text‑Retrieval‑Ergebnisse auf BEIR‑15, wobei der 260 M‑Retriever 0,4881 nDCG@10 mit Late‑Interaction erzielt und das 800 M‑Modell 0,5126 erreicht.

Kompression, Indexierungs‑Durchsatz und Verfügbarkeit

Da der Speicherbedarf von Late‑Interaction linear mit der Anzahl der Embedding‑Vektoren skaliert, sind hochauflösende Seiten teuer zu indexieren: Eine 2048 × 2048‑Seite erzeugt mit NeoMME‑Retriever 4 200 Vektoren, etwa 2,1 MB in Float32, und der Beitrag berichtet einen gemessenen Durchschnitt von etwa 1,5 MB pro Dokument über ViDoRe v3. Das Team kombinierte hierarchisches Token‑Pooling, das ähnliche Dokumenten‑Vektoren clustert und den Mittelwert jedes Clusters speichert, mit asymmetrischer Quantisierung, die Dokument‑Embeddings mit Int8‑ oder Binär‑Präzision speichert, während Abfrage‑Embeddings on‑the‑fly in höherer Präzision bleiben. Auf ViDoRe v3 berichtet der Beitrag, dass ein Pooling‑Faktor von 10 mit Int8‑Abfragen und -Dokumenten den Speicher auf 39 kB pro Seite reduziert (eine 39‑fache Verringerung), wobei mehr als 99 % des Basis‑nDCG@10 erhalten bleiben. Eine aggressivere Einstellung, Pooling‑Faktor 8 mit Int8‑Abfragen und binären Dokumenten, nutzt 6 kB pro Seite, 255‑mal kleiner, und bewahrt mehr als 95 % der Retrieval‑Qualität.

Das Team maß zudem den Kodierungs‑Durchsatz mit vorverarbeiteten Bild‑Tensoren, wobei die Batch‑Größen für jedes Modell und jede Bildgröße separat kalibriert wurden. Bei einem 2048 × 2048‑Eingang auf einer NVIDIA L40S‑GPU kodiert NeoMME‑Retriever‑260M etwa 51 Seiten pro Sekunde, fast doppelt so schnell wie die 26 Seiten pro Sekunde von ColModernVBERT, und der Beitrag berichtet, dass beide NeoMME‑Retriever‑Größen bei kleineren Eingangs‑Auflösungen schneller sind als die anderen verglichenen Modelle.

Alle NeoMME‑Checkpoints werden unter der Apache‑2.0‑Lizenz veröffentlicht und mit einer Day‑Zero‑Implementierung in Hugging Face Transformers bereitgestellt; ein Demo für visuell‑erweitertes Retrieval‑generiertes Ergebnis ist als Hugging Face Space verfügbar. Für das Fine‑Tuning stellt das Team separate dichte und Late‑Interaction‑Checkpoints bereit, die mit Sentence Transformers v6 kompatibel sind, welche derzeit einen Retrieval‑Kopf pro Modell unterstützt; das gleichzeitige Training beider Köpfe erfordert die Klasse NeoMMEForRetrieval mit einem benutzerdefinierten Trainer.

Der begleitende technische Bericht von Aurélien Lac und Tony Wu wurde am 31. August 2026 bei arXiv in der Kategorie Information Retrieval eingereicht. In den Danksagungen des Beitrags beschreiben die Autoren NeoMME als ein Nebenprojekt, das mit begrenzter Zeit und Rechenleistung entwickelt wurde, und danken H Company für die Unterstützung der Arbeit sowie die Bereitstellung der für das Training genutzten Rechenressourcen.