VLMEvalKit: ein Toolkit, das 220+ Vision-Sprach-Modelle auf 80+ Benchmarks vereinheitlicht

Welches Problem die Datenaufbereitung pro Benchmark löst

Wer mehrere Vision-Sprach-Modelle vergleicht, verbringt den größten Teil der Zeit nicht mit Inferenz, sondern mit der Angleichung von Datenformaten. Jede Benchmark liefert Bilder, Fragen und Antwortoptionen anders; jedes Modell erwartet Prompts in einer eigenen Struktur. Das README beschreibt den Anspruch des Projekts als one-command evaluation of LVLMs on various benchmarks, without the heavy workload of data preparation under multiple repositories. Genau das ist der Kern: ein Repository, das die Vorbereitung übernimmt, statt sie pro Benchmark neu zu schreiben.

Die Zielgruppe sind Evaluierungsingenieure und Forschende, die Modellvergleiche reproduzieren müssen. Weniger geeignet ist das Toolkit für Anwendungsfälle, in denen ein einzelnes Modell in einer Produktionspipeline gegen einen hausinternen Datensatz geprüft wird. Dort ist der Konfigurationsrahmen des Toolkits größer als der eigentliche Messvorgang.

Generierungsbasierte Auswertung statt Log-Likelihood-Vergleich

Die zentrale Designentscheidung steht im README in einem Satz: In VLMEvalKit, we adopt generation-based evaluation for all LVLMs. Das Modell erzeugt also freien Text, und das Toolkit extrahiert daraus die Antwort. Für jede Auswertung werden laut README zwei Wege angeboten: exact matching und LLM-based answer extraction.

Das hat Folgen. Exact Matching ist billig und deterministisch, scheitert aber an Formulierungen wie der richtige Buchstabe in einem Satz statt als einzelnes Zeichen. Die LLM-basierte Extraktion fängt das auf, kostet aber zusätzliche Modellaufrufe und bringt deren eigene Fehlerquote mit. Ein Änderungseintrag vom 04.08.2025 beschreibt genau diese Verschiebung: can_infer_option und can_infer_text wurden verfeinert und leiten die Auswertung zunehmend an LLM-Choice-Extraktoren weiter, was laut Eintrag empirisch zu leichten Verbesserungen bei Multiple-Choice-Benchmarks führt. Wer zwei Läufe mit unterschiedlichen Toolkit-Versionen vergleicht, muss diesen Pfad im Blick behalten, weil sich die Extraktionslogik zwischen Releases ändern kann.

Denken, lange Antworten und abgeschnittene Zellen

Zwei Einträge vom 12.09.2025 behandeln Fehlerquellen, die erst bei neueren Modellen sichtbar werden. Modelle mit Thinking-Mode geben ihre Zwischenschritte im Antworttext aus. VLMEvalKit erlaubt dafür eine eigene split_thinking-Funktion, aktiviert über die Umgebungsvariable SPLIT_THINK=True. Standardmäßig parst die Funktion Inhalte innerhalb von <think>...</think> und legt sie unter dem Schlüssel thinking im Ausgabedatensatz ab. Für eigene Modelle lässt sich eine split_think-Funktion hinterlegen; das README verweist auf die InternVL-Implementierung als Beispiel. Das Projekt empfiehlt das ausdrücklich für Modelle mit Thinking-Mode, um die Genauigkeit der Auswertung zu sichern.

Der zweite Punkt betrifft die Ausgabe selbst. Einzelne Zellen in einer .xlsx-Datei sind auf 32.767 Zeichen begrenzt. Modelle mit sehr langen Antworten laufen in diese Grenze, und die Antwort wird still abgeschnitten. Dagegen setzt man PRED_FORMAT=tsv, womit Vorhersagen im TSV-Format gespeichert werden. Das README empfiehlt das ausdrücklich ab etwa 16k oder 32k Token Antwortlänge. Wer diesen Schalter nicht setzt und später Auswertungen auf den Rohdateien nachrechnet, arbeitet möglicherweise auf gekürzten Texten.

Verteilte Inferenz über vLLM und LMDeploy

Seit dem 24.05.2025 unterstützt das Toolkit Multi-Node-Inferenz über LMDeploy und vLLM. Die Abdeckung ist nicht deckungsgleich: LMDeploy wird laut README für die InternVL-Serie, die QwenVL-Serie und LLaMa4 genannt, vLLM für die QwenVL-Serie und LLaMa4. Aktiviert wird das über die Flags use_lmdeploy oder use_vllm in der eigenen Modellkonfiguration in vlmeval/config.py.

Das ist der Punkt, an dem sich der Aufwand verschiebt. Der Standardpfad ruft Modelle über ihre eigene Laufzeitumgebung auf, was für ein einzelnes Modell unkompliziert ist. Sobald aber mehrere Modelle auf denselben Benchmarks laufen sollen, entscheidet die Wahl zwischen vLLM, LMDeploy und dem Standardpfad darüber, wie viele Maschinen man braucht und wie lange ein Durchlauf dauert. Die Einschränkung steht implizit in der Aufzählung: Nicht jede Modellfamilie ist über beide Backends ansprechbar. Wer ein Modell außerhalb der genannten Serien evaluieren will, bleibt beim Standardpfad.

Was beim Start tatsächlich konfiguriert wird

Das README verweist für den Einstieg auf docs/en/Quickstart.md beziehungsweise die deutschsprachige Entsprechung ist dort nicht vorhanden, wohl aber die chinesische und japanische Fassung. Die konkreten Stellschrauben, die sich aus dem Material belegen lassen, sind Umgebungsvariablen und Konfigurationsdateien: SPLIT_THINK=True für Thinking-Mode-Modelle, PRED_FORMAT=tsv für lange Antworten, VLMEVALKIT_USE_MODELSCOPE zum Herunterladen von Video-Benchmarks über ModelScope, sowie die Flags use_lmdeploy und use_vllm in vlmeval/config.py.

Auffällig ist, dass mehrere dieser Schalter über Umgebungsvariablen laufen und nicht über eine zentrale Konfigurationsdatei. Das erleichtert schnelle Experimente, erschwert aber die Reproduzierbarkeit, wenn Läufe über Skripte oder Container gesteuert werden. Wer Ergebnisse archiviert, sollte die gesetzten Variablen mit dem Kommando und der Toolkit-Version zusammen ablegen. Die letzte Veröffentlichung v0.3rc1 stammt vom 21.06.2025, davor v0.2 vom 24.03.2025 und v0.2rc1 vom 29.06.2024.

Grenzen: fremde Repositories, fremde Extraktoren

Das Toolkit vereinheitlicht die Schnittstelle, nicht die Benchmarks selbst. Die Daten stammen weiterhin aus den jeweiligen Benchmark-Repositories und werden beim ersten Lauf heruntergeladen. Ein Lauf ist damit von externen Hosts abhängig, und das README nennt mit VLMEVALKIT_USE_MODELSCOPE einen Schalter, der genau diesen Bezugspunkt für Video-Benchmarks verschiebt. Wer in einer Umgebung ohne externen Netzzugang evaluiert, muss die Daten vorab bereitstellen.

Die zweite Grenze ist die Auswertungslogik. LLM-basierte Extraktion bedeutet, dass ein weiteres Modell über die Punktzahl mitentscheidet. Das ist bei offenen Antwortformaten kaum vermeidbar, macht den Vergleich zwischen Toolkit-Versionen aber empfindlich. Die Änderung vom 04.08.2025 an can_infer_option und can_infer_text ist ein Beispiel dafür, dass sich Zahlen zwischen Releases verschieben können, ohne dass sich am evaluierten Modell etwas geändert hat. Für Ranglisten, die über Monate wachsen, ist das ein reales Problem.

Wo andere Toolkits anders ansetzen

Der Unterschied zu reinen Benchmark-Repositories liegt in der Richtung der Vereinheitlichung. Eine einzelne Benchmark wie MMMU oder Video-MME pflegt ihr eigenes Evaluierungsskript und deckt genau ein Modellinterface ab. VLMEvalKit geht den umgekehrten Weg und definiert ein gemeinsames Interface, in das 220+ Modelle und 80+ Benchmarks eingehängt werden. Der Preis dafür ist eine Abstraktionsschicht, die bei Sonderfällen im Weg stehen kann.

Der zweite Unterschied betrifft die Auswertungsmethode. Klassische VQA-Evaluierung arbeitet häufig mit Log-Likelihood-Vergleich über feste Antwortkandidaten. VLMEvalKit wählt laut README für alle Modelle den generierungsbasierten Weg. Das erlaubt offene Antwortformate und macht das Toolkit anschlussfähig an Modelle, die nur über eine Chat-API erreichbar sind, etwa Gemini, Claude oder GPT-4V, die in den Topics des Repositories genannt werden. Es bedeutet aber auch, dass man keine Wahrscheinlichkeiten über Antwortoptionen erhält, was für Kalibrierungsanalysen ein Ausschlusskriterium sein kann.

Pflege, Lizenz und der erste Prüfschritt

Das Repository ist nicht archiviert und wird aktiv gepflegt; der letzte Push liegt laut Metadaten im September 2026. Zwischen den Releases liegen teils viele Monate, während Änderungen laufend über Pull Requests einfließen. Wer eine feste Version für wiederkehrende Vergleiche braucht, sollte auf Tags wie v0.3rc1 pinnen statt dem main-Branch zu folgen, weil sich die Extraktionslogik zwischen Commits ändern kann.

Lizenziert ist das Projekt unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation unter den Bedingungen dieser Lizenz, üblicherweise einschließlich der Beibehaltung von Copyright- und Lizenzhinweisen. Zu beachten ist, dass die Lizenz nur den Code des Toolkits betrifft. Die Benchmarks, die es herunterlädt, und die Gewichte der evaluierten Modelle haben eigene Bedingungen, die man vor einem kommerziellen Einsatz getrennt prüfen muss. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, an denen man nachsehen sollte.

Der konkrete erste Schritt vor dem Einsatz ist deshalb kein Benchmark-Lauf, sondern ein Blick in vlmeval/config.py: Steht die Zielbenchmark dort, und ist das Zielmodell über den Standardpfad, use_vllm oder use_lmdeploy eingetragen? Erst danach lohnt es sich, SPLIT_THINK und PRED_FORMAT zu setzen und einen Lauf zu starten.

Redaktionelles Fazit

Sinnvoll ist VLMEvalKit für Teams, die mehrere Vision-Sprach-Modelle gegen dieselben Benchmarks vergleichen wollen oder eigene Modellklassen in eine bestehende Benchmark-Suite einhängen müssen. Wer nur ein einzelnes Modell auf einem einzelnen Datensatz prüft, trägt mehr Konfigurationsaufwand als Nutzen. Vor dem ersten Lauf sollte man im eigenen Checkout prüfen, ob die Zielbenchmark in vlmeval/config.py hinterlegt ist und ob das Modell über eine API oder über eine lokale Gewichtung angesprochen wird, weil davon die Wahl zwischen use_vllm, use_lmdeploy und dem Standardpfad abhängt. Bei Modellen mit Thinking-Mode gehört SPLIT_THINK=True gesetzt, bevor Zahlen in einen Vergleich wandern.

Offizielle Quellen

1. License: Apache-2.0
2. open-compass/VLMEvalKit on GitHub
3. Project website
4. README
5. Releases