LLM-Benchmarks: Leaderboards verstehen (MMLU, Arena, SWE-bench)

#Warum Benchmarks zählen (und Sie täuschen)

Ein LLM-Benchmark ist ein Satz von Fragen, deren Antworten bekannt sind und die einem Modell gestellt werden, um zu zählen, wie viele es richtig beantwortet. Das Ergebnis ist ein Score – ein Prozentsatz, eine Elo-Platzierung, eine Lösungsquote. Das ist die einzige gemeinsame Sprache, mit der sich zwei Modelle vergleichen lassen, ohne sie selbst stundenlang zu testen, und deshalb nutzen sie alle.

Das Problem ist nicht das Prinzip, sondern die Diskrepanz zwischen dem, was der Score aussagt, und dem, was Sie hineinlesen. Ein Modell, das bei MMLU 90 % erreicht, ist nicht „zu 90 % intelligent“: Es beantwortet 90 % der Fragen eines Multiple-Choice-Tests zu akademischem Wissen richtig. Das sagt nichts darüber aus, ob es Ihre Anweisungen befolgen, korrektes Französisch schreiben, Halluzinationen in Ihrem Fachgebiet vermeiden oder ein Gespräch über zehn Gesprächsrunden führen kann. Ein Benchmark misst eine eng begrenzte Fähigkeit unter Laborbedingungen.

Benchmarks lassen sich in drei große Kategorien einteilen, die unterschiedliche Dinge messen und sich nicht auf dieselbe Weise manipulieren lassen: akademische Benchmarks (Multiple-Choice-Fragen zu Wissen und Schlussfolgern), Benchmarks für reale Aufgaben (einen echten Bug beheben, Tools nutzen) und Arenen für menschliche Präferenzen (Menschen stimmen über die beste Antwort ab). Wir gehen sie der Reihe nach durch.

#Akademische Benchmark-Tests: MMLU, GPQA, MATH

Das ist die klassische Benchmark-Familie, deren Ergebnistabellen auf den Seiten zur Veröffentlichung von Modellen zu sehen sind. Diese Benchmarks bestehen aus Fragen mit überprüfbaren Antworten, häufig Multiple-Choice-Fragen, und werden automatisch bewertet. Ihre Stärke ist die Reproduzierbarkeit; ihre Schwäche ist, dass sie leicht gesättigt und kontaminiert werden können.

MMLU

Massive Multitask Language Understanding: ~14.000 Multiple-Choice-Fragen aus 57 Fachgebieten (Recht, Medizin, Geschichte, Mathematik usw.). Der am häufigsten zitierte Wissensbenchmark. Heute weitgehend gesättigt: Gute Modelle übertreffen 88–90 %, die Unterschiede zwischen ihnen liegen im Rauschen.

MMLU-Pro

Anspruchsvollere Version von MMLU: 10 statt 4 Antwortmöglichkeiten, neu ausgewählte Fragen für einen höheren Schwierigkeitsgrad und mehr erforderliches logisches Schlussfolgern. Sie wurde eigens entwickelt, weil MMLU die führenden Modelle nicht mehr voneinander unterscheiden konnte.

GPQA (Diamond)

„Google-Proof Q&A“: Fragen auf Promotionsniveau in Biologie, Physik und Chemie, die so konzipiert sind, dass eine Google-Suche nicht ausreicht. Die Teilmenge „Diamond“ ist die schwierigste. Ein guter Indikator für wissenschaftliches Schlussfolgern auf höchstem Niveau.

MATH / AIME

Mathematikaufgaben (MATH: Oberstufen- und Wettbewerbsniveau; AIME: amerikanische Mathematikolympiaden). Eine einzige numerische Antwort, daher leicht zu bewerten. Zu einem Kennzeichen von „Reasoning“-Modellen geworden, die in mehreren Schritten nachdenken.

IFEval

Misst die Fähigkeit, überprüfbare Anweisungen zu BEFOLGEN („antworte mit genau 3 Aufzählungspunkten“, „verwende nicht den Buchstaben e“). Oft aufschlussreicher für den tatsächlichen Gebrauch als ein Multiple-Choice-Test zum Wissen.

HLE (Humanity's Last Exam)

Ein neuer und bewusst extremer Benchmark: Expertenfragen aus mehreren Fachgebieten, die so konzipiert sind, dass sie noch lange schwierig bleiben. Selbst die besten Modelle kommen hier bislang nicht über niedrige Werte hinaus, weshalb sich der Benchmark 2026 gut eignet, um Leistungsunterschiede sichtbar zu machen.

#Benchmark-Tests für echte Aufgaben: SWE-bench und Agenten

Diese Familie ist jünger und viel schwerer zu manipulieren, weil sie keine Fragen stellt: Sie verlangt die Erledigung einer vollständigen Aufgabe, deren Ergebnis objektiv überprüfbar ist. Ein echtes GitHub-Ticket lösen, eine Testsuite erfolgreich durchlaufen lassen, durch ein Code-Repository navigieren. Darauf gehen wir in unserem speziellen Leitfaden zu Code-Benchmarks ausführlich ein; hier das Wichtigste.

SWE-bench Verified

Eine Teilmenge von 500 echten GitHub-Problemen (Issues + erwarteter Patch), die OpenAI manuell als lösbar und klar spezifiziert validiert hat. Das Modell muss einen Patch erzeugen, mit dem die Tests des Repositorys bestanden werden. Das ist zum maßgeblichen Standard für Programmieraufgaben unter realen Bedingungen geworden, deutlich aussagekräftiger als HumanEval (heute bei 96–98 % gesättigt).

SWE-bench (full / Lite)

Die vollständige Version (~2.300 Aufgaben) und eine abgespeckte Version für schnelle Iterationen. Die veröffentlichten Punktzahlen hängen sehr stark vom „Harness“ ab (dem Agenten, der das Modell orchestriert): Dasselbe Modell kann je nach den eingesetzten Tools 15 Punkte hinzugewinnen.

Tau-bench / agentbasiert

Benchmarks für Agenten, die über mehrere Interaktionsrunden hinweg Tools nutzen (Funktionsaufrufe, APIs, Einhaltung von Geschäftsregeln). Sie messen die Zuverlässigkeit beim Einsatz als „Assistent, der handelt“, nicht nur als Assistent, der antwortet.

LiveCodeBench

Kontinuierlich gesammelte Aufgaben aus Programmierwettbewerben mit Veröffentlichungsdatum. Für die Bewertung lassen sich ausschließlich Aufgaben berücksichtigen, die nach dem Trainingsdatum eines Modells veröffentlicht wurden — ein direktes Gegenmittel gegen Datenkontamination.

#LMArena: die Rangliste nach menschlichen Präferenzen

LMArena (ehemals „Chatbot Arena“ von LMSYS) funktioniert anders: Zwei anonyme Modelle beantworten dieselbe Frage eines echten Nutzers, der für die bessere Antwort stimmt. Aus Millionen solcher Duelle wird ein Elo-Wert berechnet (dasselbe System wie im Schach). Dieser Benchmark kommt der Frage „Welches Modell bevorzugen die Menschen tatsächlich?“ am nächsten.

Das, was es gut messen kann

Die wahrgenommene Qualität in offenen Gesprächen: Ton, Struktur, Gesamtnutzen und die Fähigkeit, eine angenehme Antwort zu geben. Das korreliert stark mit der Zufriedenheit bei der tatsächlichen Nutzung.

Was damit schlecht gemessen wird

Die sachliche Richtigkeit. Abstimmende belohnen oft lange, gut formatierte und selbstsichere Antworten – selbst wenn sie falsch sind. Ein „schmeichelndes“ Modell kann in der Rangliste aufsteigen, ohne genauer zu sein.

Elo ist kein Prozentsatz

Ein Abstand von 10–20 Elo-Punkten ist statistisches Rauschen. Achten Sie immer auf das angezeigte Konfidenzintervall: Zwei Modelle können „gleichauf“ liegen, selbst wenn sie nicht in derselben Tabellenzeile stehen.

Die Teilranglisten

LMArena bietet Kategorien (Code, Mathematik, lange Antworten, kontrollierter Stil). Die Teilrangliste „hard prompts“ oder „style control“ ist oft aussagekräftiger als die Gesamtrangliste, die alles vermischt.

#Falle Nr. 1: Datenverunreinigung

Kontamination liegt vor, wenn die Fragen eines Benchmarks (oder ihre Antworten) absichtlich oder unabsichtlich in die Trainingsdaten des Modells gelangen. Das Modell schlussfolgert dann nicht mehr, sondern gibt Gelerntes wieder. Öffentliche Benchmarks kursieren im Web, auf GitHub und auf Hugging Face — dadurch landen sie zwangsläufig in den Korpora für das Vortraining. Das Ergebnis ist ein aufgeblähter Score, der nichts über die Leistung bei neuen Fragen aussagt.

Das ist die Achillesferse aller statischen und öffentlichen Benchmarks. Je älter und bekannter ein Benchmark ist, desto höher ist das Risiko. Einige Anzeichen, die Sie alarmieren sollten:

Unterschied zwischen Versionen

Ein Modell, das bei MMLU hervorragend abschneidet, bei MMLU-Pro aber einbricht (gleiche Fachgebiete, neue Fragen), deutet eher auf Auswendiglernen als auf Verständnis hin.

Ungewöhnlich hoher Score für die Modellgröße

Ein kleines 7B-Modell, das 70B-Modelle auf EINEM bestimmten Benchmark und nur auf diesem schlägt: Vorsicht, oft steckt gezieltes Training („benchmaxxing“) auf diesem Testdatensatz dahinter.

Datierte Benchmarks

„Live“-Evaluierungen (LiveCodeBench, Fragen mit Zeitstempel) umgehen das Problem: Bewertet wird nur, was nach dem Stichtag für die Trainingsdaten des Modells liegt.

Verdächtige Gedächtnislücken

Einige Tests fügen Canary-Varianten („canary strings“) oder Umformulierungen ein, um das Wiedergeben auswendig gelernter Inhalte zu erkennen. Ein großer Unterschied zwischen der ursprünglichen und der umformulierten Frage verrät eine Kontamination.

#Fallstrick Nr. 2: Sättigung

Ein Benchmark ist gesättigt, wenn die besten Modelle so hohe Ergebnisse erzielen, dass er sie nicht mehr voneinander unterscheidet. Wenn alle bei 96–99 % liegen, sind die verbleibenden 3 Prozentpunkte eher Messrauschen durch mehrdeutige Fragen oder fehlerhafte Kennzeichnungen als ein tatsächlicher Unterschied in den Fähigkeiten. HumanEval (Code) und MMLU (Wissen) sind typische Beispiele: Sie waren sehr nützlich, eignen sich aber nicht mehr dazu, die Modelle an der Spitze der Rangliste zu unterscheiden.

Deshalb erscheinen ständig neue, anspruchsvollere Benchmarks: MMLU-Pro ersetzt MMLU, GPQA Diamond und HLE übernehmen die Bewertung des logischen Schlussfolgerns, SWE-bench Verified ersetzt HumanEval für Code. Ein Benchmark hat eine begrenzte Nutzungsdauer; sobald das durchschnittliche Leistungsniveau eine bestimmte Grenze überschreitet, müssen Sie ihn aus Ihren Entscheidungskriterien streichen.

#Ein Leaderboard lesen, ohne sich täuschen zu lassen

Hier ist die Methode, die Sie bei jeder Ergebnistabelle anwenden sollten, ob sie nun aus einer Mitteilung zu einem Modell oder einer öffentlichen Rangliste stammt.

1. 01
   Prüfen Sie, wer die Ergebnisse veröffentlicht

   Ein Diagramm in der Ankündigung eines Modells ist Marketing: Dafür werden günstige Benchmarks und ein vorteilhaftes Testverfahren ausgewählt (Cherry-Picking). Ein neutrales Leaderboard eines Drittanbieters (Open LLM Leaderboard, LMArena, die offizielle SWE-bench-Seite) ist deutlich zuverlässiger als eine Präsentationsfolie zur Markteinführung.
2. 02
   Prüfen Sie das Protokoll

   0-Shot oder Few-Shot? Mit Chain-of-Thought? Mit welchem Test-Harness für agentische Aufgaben? Zwei Scores sind nur vergleichbar, wenn die Methode identisch ist. Ein Sternchen mit dem Hinweis „self-reported“ (selbst angegeben) ist weniger wert als ein von einem Dritten reproduzierter Score.
3. 03
   Prüfen Sie die Konfidenzintervalle

   Auf LMArena ist ein Elo-Unterschied von weniger als etwa 15 Punkten Rauschen. Bei Benchmarks mit kleiner Stichprobe (GPQA Diamond, 198 Fragen) verändern bereits eine Handvoll richtiger Antworten den Score um mehrere Punkte. Eine Rangliste ohne Fehlermarge sollte mit Vorsicht betrachtet werden.
4. 04
   Kombinieren Sie mehrere Benchmarkergebnisse

   Entscheiden Sie niemals anhand einer einzigen Zahl. Ein solides Modell schneidet in einer Reihe unterschiedlicher Tests gut ab, nicht nur mit einem einzelnen Spitzenwert. Ein isolierter, ungewöhnlicher Spitzenwert deutet eher auf eine gezielte Optimierung hin.
5. 05
   Gewichten Sie nach IHREM Einsatzzweck

   Programmieren Sie? Schauen Sie sich SWE-bench und LiveCodeBench an, nicht MMLU. Nutzen Sie Französisch? Keiner dieser Benchmarks ist auf Französisch – suchen Sie nach französischsprachigen Evaluierungen oder testen Sie selbst. Geht es um Gespräche? Dann hat LMArena Vorrang. Das „im Durchschnitt“ beste Modell ist nicht unbedingt das beste für Sie.

#Ein lokales Modell anhand Ihrer eigenen Aufgaben bewerten

Die logische Schlussfolgerung aus allem bisher Gesagten: Der zuverlässigste Benchmark für Sie ist Ihr eigener. Er kann nicht kontaminiert werden (Ihre Fragen stehen nicht im Web), er ist nie ausgereizt (Sie kalibrieren ihn anhand Ihrer schwierigen Fälle), und er misst genau das, was Sie benötigen. Eine aufwendige Infrastruktur ist nicht nötig: Etwa zwanzig repräsentative Beispiele reichen aus, um zu entscheiden, welches von zwei Modellen besser abschneidet.

1. 01
   Stellen Sie einen kleinen Testsatz zusammen

   Sammeln Sie 15 bis 30 Prompts aus Ihren tatsächlichen Anwendungsfällen (zu verfassende E-Mails, Extraktionen, Fragen zu Ihren Dokumenten, Codeabschnitte). Notieren Sie für jeden Prompt, was eine gute Antwort enthalten muss. Halten Sie diesen Testsatz privat und unverändert, um die Modelle über die Zeit zu vergleichen.
2. 02
   Installieren Sie die zu vergleichenden Modelle

   Laden Sie mit Ollama die infrage kommenden Modelle herunter. Ollama stellt unter http://localhost:11434 eine OpenAI-kompatible API bereit, mit der sich die Aufrufe automatisieren lassen.
3. 03
   Automatisieren Sie die Modellaufrufe

   Ein kleines Skript durchläuft Ihre Prompts und speichert die Antworten jedes Modells nebeneinander in einer Datei, damit Sie sie anschließend in Ruhe vergleichen können, ohne sich vom Namen des Modells beeinflussen zu lassen.
4. 04
   Bewerten Sie blind

   Lesen Sie die Antworten erneut, ohne zu wissen, welches Modell welche Antwort erzeugt hat (mischen Sie die Reihenfolge). Bewerten Sie sie anhand Ihrer eigenen Kriterien: Genauigkeit, Einhaltung der Anweisung, Qualität des Französischen, keine erfundenen Inhalte. Das ist Ihre persönliche „Arena“.
5. 05
   Messen Sie auch die tatsächlichen Kosten

   Qualität ist nicht alles: Notieren Sie die Geschwindigkeit (Tokens/Sekunde) und den VRAM-Verbrauch. Ein 14B-Modell in Q4_K_M (~9 GB), das in den Speicher Ihrer RTX 4070 passt und schnell antwortet, kann einem theoretisch „besseren“ 70B-Modell (~40 GB) überlegen sein, das bei Ihnen praktisch nicht nutzbar ist.

# Récupérer deux candidats via Ollama
ollama pull qwen3:14b
ollama pull gemma3:12b

# Vérifier qu'ils répondent (API locale sur le port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:14b",
  "prompt": "Résume ce texte en 3 puces : ...",
  "stream": false
}'

import json, requests

OLLAMA = "http://localhost:11434/api/generate"
MODELES = ["qwen3:14b", "gemma3:12b"]

# Vos prompts réels — la clé d'une éval qui vous ressemble
prompts = [
    "Rédige un mail de relance poli à un client en retard de paiement.",
    "Extrais les dates et montants de ce texte : ...",
    "Explique la différence entre Q4_K_M et Q8_0 en 2 phrases.",
]

def interroger(modele, prompt):
    r = requests.post(OLLAMA, json={
        "model": modele, "prompt": prompt, "stream": False
    }, timeout=120)
    return r.json()["response"].strip()

resultats = []
for p in prompts:
    ligne = {"prompt": p}
    for m in MODELES:
        ligne[m] = interroger(m, p)
    resultats.append(ligne)

# À relire en aveugle, sans regarder la colonne du modèle
with open("comparaison.json", "w", encoding="utf-8") as f:
    json.dump(resultats, f, ensure_ascii=False, indent=2)
print("OK — comparaison.json généré, notez les réponses à froid.")

#Weiterführende Informationen

Diese Leitfäden vertiefen die hier behandelten Grundlagen zu spezialisierten Benchmarks und zur konkreten Auswahl eines lokalen Modells:

Detaillierte Code-Benchmarks

„HumanEval ist tot: Code-Benchmarks für LLMs im Jahr 2026 verstehen“ behandelt SWE-bench, LiveCodeBench und die Interpretation von Code-Benchmark-Ergebnissen ausführlicher – die direkte Fortsetzung dieses Leitfadens für den Entwicklungsbereich.

Quantisierung wählen

„GGUF-Quantisierung 2026: Q4_K_M gegenüber Q5_K_M gegenüber Q6_K“ zeigt, wie man den tatsächlichen Einfluss einer Quantisierung auf die Qualität messen kann – eine selbst entwickelte Evaluierung, angewendet auf einen konkreten Fall.

Vollständiger Modelltest

„Qwen 3 lokal: umfassender Test und reale Benchmarks“ veranschaulicht die Methode zur lokalen Bewertung (Tokens/s, Qualität auf Französisch, VRAM) anhand eines bestimmten Modells.