LLaVA-OneVision-2: ein 8B-Modell mit Codec-Encoder und vollständiger Trainingskette

Welche Lücke das Projekt adressiert

Die meisten offenen multimodalen Modelle bewegen sich laut README weiterhin in einer zweidimensionalen Einzelbild-Welt. LLaVA-OneVision-2 setzt dagegen auf ein einziges 8B-Modell, das Bild, Langvideo und räumliches Verstehen ohne aufgabenspezifische Adapter abdeckt. Der Anspruch richtet sich an zwei Gruppen: Teams, die ein Modell für Video- und Dokumentverstehen feintunen wollen, und Teams, die eine vollständige Trainingskette brauchen, um Ergebnisse nachzuvollziehen statt sie zu glauben. Das Repository veröffentlicht dafür nicht nur Checkpoints, sondern auch Encoder-Gewichte, Trainingscode, Konfigurationen und Trainingslogs. Genau das ist der Unterschied zu Release-Paketen, die nur Gewichte und eine Modellkarte enthalten. Wer heute ein Video-fähiges Modell sucht und die Datenmischung oder die Trainingsschritte nicht prüfen kann, hat keine Möglichkeit, einen Qualitätsunterschied auf eine konkrete Designentscheidung zurückzuführen. LLaVA-OneVision-2 macht diese Zuordnung prinzipiell möglich, weil die Zwischenstufen mitgeliefert werden.

Codec-Patches statt gleichmäßiger Frame-Abtastung

Der technische Kern ist eine andere Auswahl der Bildausschnitte, die das Modell überhaupt zu sehen bekommt. Klassische Vision-Transformer zerlegen Videoframes in ein gleichmäßiges Patch-Raster. Die OneVision-Encoder und OneVision-Encoder-Lang arbeiten laut README stattdessen HEVC-artig: Sie bekommen einen Codec-Stream als zusätzlichen Eingabemodus neben Bild und gleichmäßig abgetastetem Video. Aus diesem Stream wählen sie bevorzugt die Patches, die viel Bewegung und viele Residuen tragen, und tasten dichte Frames dünn ab, statt dünne Frames dicht abzutasten. Die README-Grafik beschreibt den Effekt mit demselben 54-Token-Budget und einem dreifach größeren zeitlichen Bereich gegenüber gleichmäßiger Abtastung. Das ist eine Aussage des Projekts, keine unabhängig nachgeprüfte Messung, und sie hängt an der Definition des jeweiligen Benchmarks. Der Mechanismus ist trotzdem nachvollziehbar: Wer ein Token-Budget festhält, kann entweder viele Frames grob oder wenige Frames detailliert sehen. Der Codec-Pfad versucht, innerhalb dieses Budgets die informationstragenden Stellen zu priorisieren. Ob das bei ruhigen Szenen mit langsamer Kamerafahrt genauso trägt wie bei schnellen Schnitten, lässt sich aus dem Material nicht beantworten.

Vier Datensätze und was sie abdecken

Mit der Familie kommen vier Datensätze, zwei neu in Version 2, zwei aus 1.5 übernommen. LLaVA-OneVision-2-VideoCaption liefert sehr dichte Videobeschreibungen, LLaVA-OneVision-2-Spatial zielt auf räumliches Verstehen mit Tiefe, Layout und Objektbeziehungen. Aus 1.5 stammen LLaVA-OneVision-1.5-Mid-Training-85M, ein konzeptbalanciertes Mid-Training-Korpus mit 85 Millionen Beispielen, und LLaVA-OneVision-1.5-Instruct, die vollständige Instruction-Tuning-Mischung. Wer die Kette nachbauen will, muss beide Stufen fahren: erst Mid-Training, dann Instruct-Tuning. Die Bezeichnung konzeptbalanciert ist dabei ein Hinweis darauf, dass die Verteilung der Konzepte bewusst gesteuert wurde, aber das Repository nennt in der README keine Gewichtung oder Filterregel, nach der das geschieht. Wer die Datenmischung für eigene Zwecke anpassen will, muss sich durch die Trainingskonfigurationen arbeiten, weil die README die Zusammensetzung nicht offenlegt. Das ist ein wiederkehrendes Muster: Die Dateien sind da, die Erklärung, warum sie so aussehen, fehlt an mehreren Stellen.

Vom Checkout zum laufenden Training

Die README führt einen Quick Start für das 4B-Modell auf einem einzelnen Knoten. Die genauen Befehle stehen im Abschnitt Quick Start (4B, single node) des Repositories; ich gebe sie hier nicht wieder, weil das Material sie nicht im Detail zeigt. Klar benannt sind dagegen die Bezugsquellen: die Gewichte liegen unter huggingface.co/lmms-lab-encoder/LLaVA-OneVision-2-8B-Instruct, die Datensätze unter huggingface.co/datasets/mvp-lab/LLaVA-OneVision-2-Data. Für die Inferenz verweist die README auf die vLLM-Implementierung unter docs.vllm.ai im Pfad api/vllm/model_executor/models/llava_onevision2. Wer den Codec-Pfad ausprobieren will, ohne selbst zu trainieren, findet einen Hugging-Face-Space namens OneVision-Encoder-Codec-View. Das sind die konkreten Einstiegspunkte. Ein Single-Node-Setup für 4B sagt allerdings nichts über den Speicherbedarf des 8B-Modells mit langen Videosequenzen, und dazu macht die README keine Angabe. Wer die 8B-Variante auf Langvideo fahren will, muss den Bedarf selbst ermitteln.

Wie belastbar die veröffentlichten Zahlen sind

Die README spricht von neuem Open-Source-SOTA über eine breite Benchmark-Suite. Die Zahlen selbst liegen als animierte SVG-Grafiken vor, nicht als Tabelle mit Konfigurationen pro Aufgabe. Das ist für eine Bewertung unglücklich, denn ein Vergleichswert ohne Angabe von Auflösung, Frame-Anzahl und Prompt-Format ist kaum einzuordnen. Das Projekt reagiert auf genau diesen Einwand mit einem eigenen Repository-Branch: Die Auswertungseinstellungen liegen im Branch llava-onevision2 von lmms-eval, zusammen mit Model-Wrapper, Task-Konfigurationen, Docker-Umgebung und Startskripten, getrennt für das Frames-Backend und das Codec-Backend. Das ist die richtige Antwort auf die Reproduzierbarkeitsfrage, verlagert die Arbeit aber auf den Leser. Wer die Zahlen prüfen will, muss den Branch auschecken und die dortige README lesen. Ohne diesen Schritt bleibt die SOTA-Aussage eine Behauptung des Projekts. Bemerkenswert ist immerhin, dass beide Backends getrennt aufführbar sind, was einen direkten Vergleich zwischen gleichmäßiger und Codec-basierter Abtastung erlaubt.

Grenzen und Fälle, in denen das Modell das falsche Werkzeug ist

Der Codec-Pfad setzt voraus, dass eine Videospur als Bitstrom vorliegt oder erzeugt werden kann. Für Einzelbilder, gescannte Dokumente, Diagramme und OCR bringt er keinen Vorteil, weil es dort keine Bewegung und keine Residuen gibt, aus denen sich Patches auswählen ließen. Die README listet Dokumente, OCR und Diagramme zwar als Einsatzbereich, aber der beschriebene Mechanismus greift dort nicht; das Modell fällt in diesen Fällen auf die gewöhnliche Bildverarbeitung zurück. Wer ausschließlich statische Bilder auswertet, trägt also die Komplexität eines Video-Encoders ohne Gegenwert. Ein zweiter Punkt ist die Abhängigkeit von der Codec-Qualität. Wenn die Kompression Residuen wegwirft oder die Bitrate sehr niedrig ist, verändert das die Patch-Auswahl, und die README beschreibt keine Untergrenze, ab der das Verfahren unzuverlässig wird. Drittens ist ein 8B-Modell kein kleiner Baustein. Für Aufgaben, die ein 2B- oder 3B-Modell mit ausreichender Genauigkeit löst, ist der Betrieb dieses Modells reine Verschwendung, unabhängig davon, wie gut die Benchmark-Zahlen aussehen.

Der Unterschied zu LLaVA-OneVision-1.5

Die naheliegende Alternative ist die Vorgängerversion im selben Repository, erreichbar über den Branch 1.5 und verlinkt im Inhaltsverzeichnis. Der Ansatz unterscheidet sich an einer klar benannten Stelle: 1.5 arbeitet ohne den Codec-Eingabemodus. Die Encoder OneVision-Encoder und OneVision-Encoder-Lang kamen erst im Februar 2026 hinzu, zusammen mit einem eigenen technischen Bericht unter arxiv.org/abs/2602.08683. Wer bereits 1.5 im Einsatz hat, muss also nicht wegen neuer Modellgewichte wechseln, sondern wegen der Encoder-Architektur und der beiden neuen Datensätze VideoCaption und Spatial. Der praktische Unterschied liegt in der zeitlichen Abdeckung bei festem Token-Budget: 1.5 sieht bei gleichem Budget weniger Zeitraum, dafür gleichmäßiger verteilt. Ob dieser Unterschied für den eigenen Anwendungsfall zählt, hängt davon ab, ob schnelle Bewegungen oder lange, ruhige Aufnahmen das Problem sind. Für kurze Clips mit wenigen Sekunden dürfte der Vorteil klein ausfallen, und dann ist der Wechsel schwer zu rechtfertigen. Für 1.5 existiert außerdem eine NeMo-Integration, die für 2.0 im Material nicht auftaucht.

Wartung, Upgrades und Lizenz

Das Repository steht unter Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Diese Einschätzung ersetzt keine Rechtsberatung, und sie sagt nichts über die Lizenz der Trainingsdaten: Die README benennt für die vier Datensätze keine eigenen Lizenzangaben. Wer ein Modell auf diesen Daten kommerziell einsetzen will, muss die Herkunft der 85-Millionen-Beispiele aus LLaVA-OneVision-1.5-Mid-Training-85M getrennt prüfen. Der Wartungsaufwand zeigt sich im Release-Takt: 1.5 erschien im Dezember 2025, 2.0 im August 2026, dazwischen die Encoder im Februar 2026. Wer auf 2.0 aufsetzt, sollte damit rechnen, dass die nächste Hauptversion die Encoder oder die Datenmischung erneut verändert und ein Feintuning auf der alten Basis dann nicht mehr zum aktuellen Stand passt. Der letzte Push datiert auf September 2026, das Projekt ist also aktiv und nicht archiviert. Ob die Upgrades rückwärtskompatibel sind, lässt sich aus der README nicht ableiten; sie beschreibt keine Migrationshinweise von 1.5 auf 2.0.

Redaktionelles Fazit

Sinnvoll ist das Repository für Teams, die einen 8B-Vision-Encoder mit veröffentlichter Trainingskette selbst nachbauen oder feintunen wollen und dafür GPU-Zeit einplanen. Wer nur Inferenz auf Bildern braucht, fährt mit einem kleineren, breiter getesteten Modell günstiger. Vor dem Adoptieren zuerst den Branch llava-onevision2 in lmms-eval auschecken und den dortigen Docker-Aufbau lesen, denn nur dort stehen die exakten Task-Konfigurationen und der Model-Wrapper, mit denen die berichteten Zahlen erzeugt wurden.

Offizielle Quellen

1. EvolvingLMMs-Lab/LLaVA-OneVision-2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases