OpenCompass: Evaluationsplattform für LLMs mit über 100 Datensätzen

Welches Problem OpenCompass löst und für wen

Ein einzelnes Modell gegen einen einzelnen Benchmark zu testen ist überschaubar. Sobald aber mehrere Modelle gegen mehrere Datensätze laufen sollen und die Ergebnisse vergleichbar bleiben müssen, entsteht Aufwand, der nichts mit dem Modell zu tun hat. Genau dort setzt OpenCompass an. Das Projekt beschreibt sich selbst als Evaluationsplattform, die eine breite Modellpalette (die README nennt unter anderem Llama3, Mistral, InternLM2, GPT-4, Qwen, GLM und Claude) über mehr als 100 Datensätze führt. Die Zielgruppe sind damit weniger Einzelpersonen, die einmalig einen Score brauchen, sondern Arbeitsgruppen, die wiederkehrend Modellvarianten gegeneinander stellen. Dazu passt, dass das Repository Konfigurationsdateien für Datensätze, Modelle und Summarizer mitbringt und nicht nur ein einzelnes Skript. Wer Evaluationsergebnisse über Wochen hinweg nachvollziehbar halten muss, gewinnt durch diese Struktur. Wer dagegen nur wissen will, ob ein lokal laufendes Modell eine Handvoll Aufgaben besteht, zahlt den Preis der Struktur ohne den Nutzen.

Konfiguration als zentrale Abstraktion

OpenCompass arbeitet konfigurationsgetrieben. Datensätze, Modelle und Auswertungslogik liegen als getrennte Konfigurationsdateien vor und werden zur Laufzeit zusammengeführt. Die README weist ausdrücklich darauf hin, dass mit Version 0.4.0 alle AMOTIC-Konfigurationsdateien, die zuvor in ./configs/datasets, ./configs/models und ./configs/summarizers lagen, in das opencompass-Paket verschoben wurden. Das ist mehr als eine Aufräumaktion. Es bedeutet, dass die Konfigurationen nun mit der Bibliothek ausgeliefert und versioniert werden. Der Vorteil: Ein Update des Pakets bringt neue Datensatzdefinitionen mit. Der Nachteil: Eigene Anpassungen an diesen Dateien kollidieren potenziell mit dem nächsten Release, und Referenzen auf die alten Pfade brechen. Wer OpenCompass produktiv einsetzt, sollte eigene Konfigurationen außerhalb des Pakets halten und nur die mitgelieferten Definitionen referenzieren. Die README formuliert die Empfehlung knapp: Nutzer sollen ihre Konfigurationsreferenzen an die strukturelle Änderung anpassen.

Inferenz, Auswertung und der Weg durch die Pipeline

Die Pipeline trennt Inferenz und Auswertung. Der GenInferencer erzeugt Modellausgaben, ein Evaluator bewertet sie anschließend. Diese Trennung ist praktisch, weil teure Inferenz nur einmal laufen muss, auch wenn mehrere Metriken auf denselben Ausgaben rechnen. Seit dem Release vom 27. Juli 2026 unterstützt GenInferencer Multi-Round-Inferenz, und der Datensatz Multi-IF prüft mehrstufiges Instruction-Following. Die zugehörige Konfiguration liegt laut Release Notes unter opencompass/configs/datasets/MultiIF/MultiIF_gen.py. Für Auswertungen, die nicht rein regelbasiert sind, gibt es den GenericLLMEvaluator für LLM-as-judge und seit April 2025 den CascadeEvaluator, der mehrere Evaluatoren nacheinander schaltet. Das ist der Punkt, an dem die Plattform über einfache Score-Berechnung hinausgeht: Eine Kaskade kann erst einen billigen Regelcheck laufen lassen und nur die strittigen Fälle an ein Richtermodell weiterreichen. Die Dokumentation dazu liegt in docs/en/advanced_guides/llm_judge.md. Wer diese Kaskade nutzt, sollte sich bewusst sein, dass die Qualität der Gesamtauswertung dann an der Qualität des Richtermodells hängt, nicht mehr an der Metrik.

Installation und erste Schritte

Das Projekt verweist für die Installation auf die Seite opencompass.readthedocs.io/en/latest/get_started/installation.html. Konkrete Installationsbefehle gibt die README nicht her, deshalb lässt sich an dieser Stelle kein Kommando aus dem Material belegen. Was sich belegen lässt, sind die Einstiegspunkte für Evaluationsbeispiele: Für den multimodalen Pfad nennt die README examples/eval_mmbench_vlmevalkit.py und examples/eval_mmmu_pro_vlmevalkit.py, für spezialisierte Modelle examples/eval_intern_s1_pro.py und examples/eval_scireasoner.py. Diese Dateien sind der praktikablere Startpunkt als die allgemeine Dokumentation, weil sie eine vollständige Konfiguration zeigen. Für die Analyse bereits vorhandener Ergebnisse gibt es tools/analyze_repeat.py, das repetitive Ausgaben und Schleifen im Modelltext erkennt. Das ist ein nützliches Werkzeug, wenn ein Modell auf einem Datensatz verdächtig hohe Werte erzielt und der Verdacht besteht, dass es die Aufgabe durch Wiederholung umgeht statt sie zu lösen. Die Lizenz ist Apache-2.0, was die Einbettung in kommerzielle Werkzeugketten grundsätzlich erlaubt; die genauen Bedingungen, insbesondere zu Patenten und zur Weitergabe von Änderungen, stehen im Lizenztext selbst und sind nicht durch die README abgedeckt.

Multimodale Erweiterung über VLMEvalKit

Seit dem 25. August 2026 integriert OpenCompass das Schwesterprojekt VLMEvalKit. Laut Release Notes ermöglicht das natives Laden multimodaler Datensätze, Inferenz über OpenAI-kompatible APIs und Auswertung mit den offiziellen VLMEvalKit-Metriken. Das ist architektonisch bemerkenswert, weil damit zwei Evaluationsstacks zusammengeführt werden, die zuvor getrennt waren. Für Nutzer bedeutet es, dass ein multimodaler Benchmark nicht mehr über einen separaten Werkzeugkasten laufen muss. Die Kehrseite: Die Abhängigkeit von VLMEvalKit-Metriken heißt, dass Änderungen an deren Definition durchschlagen. Wer Bild-Text-Modelle bewertet und die Zahlen über Zeit vergleichen will, muss beide Projekte im Blick behalten, nicht nur OpenCompass. Die Beispiele eval_mmbench_vlmevalkit.py und eval_mmmu_pro_vlmevalkit.py sind der dokumentierte Einstieg.

Modell-Backends und der Umgang mit Prompt-Formatierung

Die Modellanbindung ist breit, aber nicht einheitlich. Die Release Notes vom 28. Juli 2026 nennen Unterstützung für die OpenAI Responses API und das LiteLLM AI Gateway sowie aktualisierte Integrationen für Gemini und Anthropic auf deren aktuelle SDK-Schnittstellen. Die Implementierungen liegen unter opencompass/models/openai_response.py, opencompass/models/litellm_api.py, opencompass/models/gemini_sdk_api.py und opencompass/models/claude_sdk_api.py. Interessant ist hier der RawPromptTemplate, eingeführt am 17. März 2026. Er erlaubt es, ursprüngliche Benchmark-Prompts und strukturierte Konversationen unverändert an das Modell zu geben, ohne dass die Plattform formatierend eingreift. Das adressiert ein reales Problem: Wenn eine Evaluationspipeline Prompts umschreibt, misst man am Ende nicht mehr den Benchmark, sondern die Pipeline. Die Dokumentation dazu liegt in docs/en/notes/rawprompttemplate.md. Wer Benchmark-Zahlen mit veröffentlichten Ergebnissen vergleichen will, sollte prüfen, ob der eigene Lauf RawPromptTemplate verwendet oder die Standardformatierung.

Wo OpenCompass an Grenzen stößt

Die Plattform ist auf Durchsatz und Breite ausgelegt, nicht auf minimale Abhängigkeiten. Die Einführung von parallelen Inferencern, Task-Überwachung und Heartbeat-Mechanismen (Release Notes vom 20. März 2026, Implementierungen unter opencompass/tasks/openicl_infer_concurrent.py und opencompass/tasks/openicl_eval_watch.py) verbessert die Effizienz großer Läufe, erhöht aber die Komplexität des Fehlerbilds. Wenn ein Lauf hängt, liegt die Ursache möglicherweise nicht im Modell, sondern in der Koordination zwischen Inferenz- und Auswertungsschritten. Ein zweiter Punkt: Die Konfigurationsstruktur ist stabil genug für wiederkehrende Läufe, aber die Umstellung in Version 0.4.0 zeigt, dass sich Pfade und Paketgrenzen ändern können. Ein Projekt, das OpenCompass nur einmalig für einen Vergleich einsetzt, trägt dieses Migrationsrisiko ohne Gegenwert. Und wer ein Modell evaluieren will, dessen Schnittstelle kein OpenAI-kompatibles Format spricht und für das keine der genannten Integrationen existiert, muss eine eigene Modellklasse schreiben. Die README listet die unterstützten Backends, sagt aber nichts über den Aufwand für eigene Anbindungen.

Alternative: LM Evaluation Harness

Der naheliegende Vergleich ist das LM Evaluation Harness von EleutherAI. Der Unterschied liegt im Schwerpunkt. Das Harness ist auf standardisierte, reproduzierbare Benchmark-Ausführung mit möglichst wenigen beweglichen Teilen ausgelegt; die Konfiguration ist eng an die jeweilige Aufgabe gebunden. OpenCompass geht den umgekehrten Weg: Es stellt eine allgemeine Konfigurationsschicht bereit, in der Datensätze, Modelle und Summarizer frei kombiniert werden, und ergänzt das um LLM-as-judge, Evaluator-Kaskaden und multimodale Pfade. Wer eine einzelne, weithin bekannte Metrik auf einem Standarddatensatz braucht und die Zahl mit veröffentlichten Ergebnissen vergleichen will, ist beim Harness oft schneller am Ziel. Wer dagegen eigene Datensätze mit eigenen Auswertungsregeln in eine bestehende Pipeline einhängen will, profitiert von der Konfigurationsabstraktion. Die beiden Werkzeuge schließen sich nicht aus; sie beantworten unterschiedliche Fragen.

Wartung, Release-Kadenz und Lizenz

Die Release-Historie zeigt drei Versionen innerhalb von etwa sieben Monaten: 0.5.2 im Februar 2026, 0.5.3 im Juni 2026, 0.5.4 im August 2026. Dazu kommen laufende Funktionserweiterungen zwischen den Releases, etwa die VLMEvalKit-Integration im August. Diese Kadenz bedeutet praktisch, dass ein Team, das OpenCompass in einer CI-Pipeline betreibt, die Konfigurationsreferenzen bei jedem Minor-Update gegenprüfen sollte. Der Bruch in 0.4.0 ist der Präzedenzfall. Wer eigene Konfigurationen im Paketverzeichnis ablegt, verliert sie beim nächsten Update oder muss sie manuell zusammenführen. Die Lizenz Apache-2.0 erlaubt kommerzielle Nutzung und Modifikation; sie enthält eine ausdrückliche Patentgewährung und verlangt, dass Änderungen an den lizenzierten Dateien kenntlich gemacht werden. Das ist keine Rechtsberatung, und wer OpenCompass in ein Produkt einbettet, sollte den Lizenztext selbst prüfen, insbesondere die Klauseln zu NOTICE-Dateien und zur Weitergabe.

Redaktionelles Fazit

Wer eine reproduzierbare, konfigurationsgetriebene Evaluationspipeline für viele Modelle und Datensätze braucht und bereit ist, die Konfigurationsstruktur bei jedem Minor-Release zu prüfen, findet in OpenCompass ein passendes Werkzeug. Wer nur einen einzelnen schnellen Benchmark auf einem lokalen Modell laufen lassen will, sollte zuerst prüfen, ob der Aufwand für Modell- und Datensatzkonfiguration in einem sinnvollen Verhältnis zum Erkenntnisgewinn steht. Vor dem ersten produktiven Einsatz sind zwei Dinge zu verifizieren: ob die eigene Konfiguration die Umstellung auf die im Paket gebündelten AMOTIC-Dateien bereits berücksichtigt, und ob der verwendete Inferencer die gewünschte Multi-Turn- oder Multimodal-Unterstützung mitbringt.

Offizielle Quellen

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