EvalScope: Evaluierung und Lasttest für LLMs, VLMs und Agenten in einem Werkzeug

Ein Befehl, drei Prüfziele: Fähigkeit, Durchsatz, Agentenverhalten

Die meisten Evaluierungswerkzeuge beantworten genau eine Frage: Wie gut löst ein Modell einen Benchmark? EvalScope stellt daneben zwei weitere Fragen, die im Betrieb oft wichtiger sind. Erstens: Wie verhält sich der Dienst unter Last, gemessen an TTFT und TPOT? Zweitens: Wie verhält sich ein Agent über mehrere Gesprächsrunden, wenn Werkzeuge aufgerufen und Sandboxen gestartet werden? Das README positioniert das Projekt als ein Werkzeug für alle drei. Die Zielgruppe sind damit nicht Forschende, die eine einzelne Zahl für ein Paper brauchen, sondern Plattform- und Modellteams, die einen Endpunkt betreiben und sowohl Qualität als auch Latenz belegen müssen. Der Einzeiler aus dem README zeigt die Richtung: pip install evalscope, dann evalscope eval mit --model, --api-url, --api-key, --eval-type openai_api, --datasets gsm8k und --limit 5. Wer diese Parameter setzt, evaluiert einen laufenden Dienst, kein lokales Gewichtsverzeichnis.

Datensatz, Adapter, Backend: die drei Schichten im Aufruf

Der Aufruf zerfällt sichtbar in drei Entscheidungen. --datasets wählt den Benchmark, --eval-type bestimmt den Adapter, über den das Modell angesprochen wird, und --api-url sowie --api-key verweisen auf den Endpunkt. Für multimodale Modelle nennt das Änderungsprotokoll eigene Adapterklassen wie AudioLanguageAdapter und einen vereinheitlichten FunctionCallAdapter, der Werkzeugaufrufe über mehrere Anbieter hinweg gleich behandelt. Wer nicht selbst auswerten will, kann laut README Backends wie OpenCompass, VLMEvalKit oder RAGEval einbinden, das Projekt tritt also an mehreren Stellen als Verteiler auf. Der Agent-Modus geht weiter: Benchmarks laufen in einer mehrstufigen AgentLoop mit austauschbaren Strategien, Werkzeugen und Docker-Sandbox, und pro Stichprobe wird ein Agent Trace aufgezeichnet, der im Dashboard sichtbar ist. Diese Trace-Aufzeichnung ist der eigentliche Unterschied zu Auswertungsskripten, die nur die Endantwort speichern. Ob ein Agent gescheitert ist, weil das Modell falsch argumentierte oder weil ein Werkzeugaufruf fehlschlug, lässt sich damit trennen, sofern die Zuordnung von Aufruf und Ergebnis korrekt gruppiert wird. Genau dort hat das Projekt laut Änderungsprotokoll im August 2026 nachgebessert.

Reproduzierbarkeit: veröffentlichte Evaluierungsversionen statt gleitender Datensätze

Ein unterschätztes Problem bei Benchmark-Auswertungen ist, dass sich Datensätze ändern, während die Zahl in der Tabelle gleich bleibt. Version 1.11.0 führt nach Angaben des Änderungsprotokolls veröffentlichte Evaluierungsversionen ein, um Ergebnisse reproduzierbar zu machen, und behandelt unvollständige Läufe explizit. Das ist eine Designentscheidung mit Kosten: Wer auf eine feste Version pinnt, bekommt vergleichbare Zahlen, verliert aber automatisch neue Aufgabenstellungen. Wer nicht pinnt, kann Ergebnisse nicht über Monate vergleichen. EvalScope zwingt hier nicht zur einen oder anderen Seite, macht die Wahl aber sichtbar. Ergänzend nennt das Protokoll ein --duration-Zeitbudget für alle Benchmark-Modi, mit dem sich Läufe hart begrenzen lassen. Für nächtliche CI-Jobs ist das nützlicher als eine Stichprobengrenze, weil die Laufzeit nicht von der Antwortlänge des Modells abhängt.

Lasttests mit Agentenverkehr statt synthetischer Einzelanfragen

Die Inferenz-Performance-Messung unterstützt laut README TTFT und TPOT, also die Zeit bis zum ersten Token und die Zeit pro Ausgabetoken. Interessanter als die Metriken ist die Herkunft der Anfragen. Seit Mai 2026 gibt es drei Datensatz-Plugins (trie_agentic_coding, trie_code_qa, trie_office_work), die echte mehrstufige Agenten-Traces abspielen, mit Token-Obergrenzen pro Runde und simulierter Latenz für Werkzeugaufrufe. Das ist ein anderer Lasttest als das übliche Senden identischer Prompts. Ein Dienst, der unter gleichförmiger Last stabil bleibt, kann bei stark schwankender Kontextlänge und zwischengeschalteten Wartezeiten einbrechen. Wer diese Plugins nutzt, muss allerdings echte Traces als Eingabe haben. Ohne sie bleibt nur der generische Modus, und das Perf-Modul unterstützt laut Protokoll seit Juni 2026 eine einheitliche Option --data-source sowie parallelisierte Anfrageerzeugung. Die Parallelisierung ist zugleich die Fehlerquelle: Ohne Kontrolle der Nebenläufigkeit misst man die eigene Lastgenerierung und nicht den Dienst.

Wann EvalScope das falsche Werkzeug ist

Der Funktionsumfang hat einen Preis. Wer nur eine Genauigkeitszahl für ein Modell braucht, installiert mit lm-evaluation-harness ein Werkzeug, das genau das tut und sonst nichts. Der Vergleich ist nicht abwertend gemeint: lm-evaluation-harness ist auf Benchmark-Ausführung und Reproduzierbarkeit fokussiert, EvalScope auf den Betrieb eines Dienstes über mehrere Prüfziele hinweg. Wer keine Agenten, keine Lasttests und kein Dashboard braucht, zahlt bei EvalScope für Abhängigkeiten, die er nicht nutzt. Ein zweiter Grenzfall: Modelle, für die kein Adapter existiert und die sich nicht hinter einer OpenAI-kompatiblen Schnittstelle betreiben lassen. --eval-type openai_api setzt voraus, dass der Dienst das Protokoll spricht. Ein Modell mit eigenem, nicht standardisiertem Inferenzpfad braucht einen eigenen Adapter, und dafür gibt es keine Abkürzung. Drittens die Docker-Sandbox im Agent-Modus: Sie ist eine Infrastrukturanforderung, kein Schalter. In Umgebungen ohne Container-Laufzeit fällt der Agent-Modus weg.

Installation, Konfiguration und der erste Lauf

Das README nennt Python ab 3.10 als Voraussetzung. Die Installation erfolgt über pip install evalscope, das Paket liegt auf PyPI. Der dokumentierte Einstieg ist ein einzelner Aufruf: evalscope eval --model your-model-name --api-url $OPENAI_API_BASE_URL --api-key $OPENAI_API_KEY --eval-type openai_api --datasets gsm8k --limit 5. Die Umgebungsvariablen für Basis-URL und Schlüssel sind Konvention, keine Pflicht, die Werte lassen sich direkt übergeben. --limit 5 begrenzt die Stichprobe und ist der schnellste Weg zu prüfen, ob Adapter und Endpunkt zusammenpassen, bevor ein vollständiger Lauf startet. Für den Perf-Teil nennt das Protokoll --data-source als einheitliche Option, für zeitlich begrenzte Läufe --duration. Ergebnisse lassen sich laut README über ein Web-Dashboard visualisieren, mit Ansichten für Modellvergleich, Berichtsübersicht und Vorhersagedetails. Der Dashboard-Startbefehl selbst steht nicht im vorliegenden Material, dafür verweist das README auf die Seite zur Visualisierung in der Dokumentation. Wer die Auswertung in eine Pipeline einbettet, sollte vorher klären, ob der Dashboard-Schritt dort überhaupt benötigt wird oder ob die Ergebnisdateien direkt weiterverarbeitet werden.

Wartung, Release-Takt und Lizenz

Der letzte Push liegt bei September 2026, die letzten drei Releases (v1.10.0, v1.11.0, v1.11.1) verteilen sich auf August 2026. Der Takt ist damit eng, und das Änderungsprotokoll listet pro Monat mehrere neue Benchmarks. Für Betreiber bedeutet das zweierlei. Erstens: Neue Benchmarks kommen schnell, der Nutzen wächst ohne eigenes Zutun. Zweitens: Wer Ergebnisse über Zeit vergleichen will, muss die Version pinnen, weil sich Adapter und Berichtssemantik zwischen Minor-Versionen ändern können. Das Protokoll nennt für v1.11.0 ausdrücklich verbesserte Berichtssemantik und einen strengeren Umgang mit unvollständigen Läufen, also Änderungen, die Zahlen verschieben können, ohne dass sich das Modell geändert hat. Zur Lizenz: Das Projekt steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Weitergabe mit den üblichen Pflichten, etwa dem Beibehalten von Copyright- und Lizenzhinweisen. Ob das Einbinden in ein eigenes Produkt oder das Veröffentlichen von Auswertungsergebnissen zusätzliche Pflichten auslöst, hängt vom konkreten Fall ab und ist eine Rechtsfrage, keine technische. Die eingebundenen Backends wie OpenCompass, VLMEvalKit oder RAGEval können eigene Lizenzen haben, die separat zu prüfen sind.

Redaktionelles Fazit

EvalScope passt zu Teams, die Modelle hinter OpenAI-kompatiblen Endpunkten regelmäßig gegen GSM8K, MMLU oder C-Eval laufen lassen und zusätzlich TTFT und TPOT messen wollen, ohne drei getrennte Werkzeuge zu betreiben. Wer nur einen einzelnen Benchmark einmalig ausführen will, greift mit lm-evaluation-harness zu einem schlankeren Werkzeug. Vor dem Rollout in eine CI-Pipeline sollte man prüfen, ob der eigene Modelltyp als eigener Adapter vorhanden ist oder über --eval-type openai_api erreichbar ist, welche Datensatz-Revision die Auswertung zieht und ob der Lizenztext der Apache-2.0-Datei im Repository mit der eigenen Weitergabe von Auswertungsergebnissen zusammenpasst.

Offizielle Quellen

1. License: Apache-2.0
2. modelscope/evalscope on GitHub
3. Project website
4. README
5. Releases