Modelle benchmarken

Ein Benchmark misst, wie gut ein Modell eine festgelegte Aufgabe löst – Geschwindigkeit, Speicherbedarf, Antwortqualität und Zuverlässigkeit. Das Problem: Eine Benchmark-Zahl allein sagt fast nichts. Sie ist immer das Produkt aus Modell + Harness + Datum + Test-Set, und jeder dieser Hebel kann das Ergebnis verstellen.

Stichtag dieses Artikels: 2026-07-20. Live-Benchmarks (LMArena, SWE-bench-Leaderboard) ändern sich täglich – alle Tabellen hier sind Snapshots und müssen periodisch erneuert werden.

Im Lehrgang gehört dieser Begriff zur Phase lokale AI, Datenkontrolle, Modellgrenzen und Automatisierung. Er ist nicht als isolierte Definition gedacht, sondern als Baustein, den du später in echten Fällen wiedererkennst. Wenn du ganz neu einsteigst, musst du zuerst drei Dinge können: den Zweck in eigenen Worten erklären, die Grenze des Begriffs nennen und sagen, woran du in der Praxis erkennst, dass er gerade relevant ist.

Merksatz: Modelle benchmarken liefert keine Gesamtrangliste „das beste Modell", sondern Antworten auf die Frage: Passt dieses Modell, mit diesem Harness, an diesem Stichtag, für meine konkrete Aufgabe?

Du prüfst ein Modell immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Bevor du irgendwelche Benchmark-Zahlen vergleichst, kläre vier Punkte:

Aufgabe: Welche Aufgabe soll das Modell wirklich lösen (z. B. Python-Code reparieren, deutsche Texte zusammenfassen, SQL generieren)?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst ein Modell immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Bevor du irgendwelche Benchmark-Zahlen vergleichst, kläre vier Punkte:
Harness: In welcher Umgebung wird gemessen? Dasselbe Modell in zwei Harnesses kann sehr verschieden abschneiden.
Stichtag: Wann wurde gemessen? Eine Zahl von 2025 kann heute veraltet sein.
Eigene Suite: Hast du eigene Testfälle aus deiner echten Arbeit, anstatt nur öffentliche Benchmarks zu vertrauen?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst ein Modell immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Bevor du irgendwelche Benchmark-Zahlen vergleichst, kläre vier Punkte:

Als Anfänger arbeitest du mit dieser Prüfliste. Das Ziel ist nicht, sofort Experte zu sein, sondern den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Nimm eine öffentliche Benchmark-Zahl (z. B. „Modell X erreicht 80% auf SWE-bench") und notiere in zwei Sätzen: Wer hat gemessen, mit welchem Harness, an welchem Datum? Wenn du das nicht beantworten kannst, ist die Zahl nicht verwendbar.

Vorher solltest du LLM-Grundlagen und AI-Hardware für lokale Modelle verstanden haben.

Auf Level 2 geht es um die Mechanismen, die Benchmarks vertrauenswürdig oder täuschend machen. Wer diese Punkte nicht kennt, liest Benchmark-Tabellen falsch.

1. Kontamination (Data Contamination)

Wenn Aufgaben oder Lösungen einer Benchmark im Trainingsdaten des Modells enthalten waren, sind die Ergebnisse wertlos – das Modell „weiß" die Antwort, statt sie zu lösen. OpenAI hat SWE-bench Verified 2026 offiziell als kontaminiert eingestuft und evaluiert es nicht mehr (Quelle: LLM-20). Auch das Hugging Face Open LLM Leaderboard wurde deshalb eingestellt (LLM-25). Überblick: LLM-26.

2. Statisch vs. erneuert

Statisch (fester Satz Aufgaben, z. B. SWE-bench Verified, MMLU): anfällig für Kontamination, sobald der Satz bekannt ist.
Erneuert (z. B. LiveBench, LiveCodeBench): neue Aufgaben regelmäßig, schwerer zu kontaminieren. Bevorzugen für aktuelle Vergleiche.

3. Modell vs. Agent/Harness

Das ist der wichtigste Punkt überhaupt. SWE-bench Verified misst nicht „das Modell", sondern Modell + Scaffolding/Harness. Die Epoch-AI-Analyse (LLM-28) zeigt: Ein Teil der Punktzahl kommt aus dem Werkzeug, das das Modell umgibt, nicht aus dem Modell selbst.

Konkretes Beispiel Claude Opus 4.5 (LLM-04, Stand 2025-11-24):

Herstellerangabe Anthropic: 80,9% SWE-bench Verified – im Anthropic-eigenen Harness.
Leaderboard (unabhängig): 76,80% SWE-bench Verified – im Standard-Harness mini-SWE-agent v2.0.0 (swebench.com, Stand 2026, Zugriff 2026-07-20).

Die Differenz von über 4 Punkten entsteht nicht durch das Modell, sondern durch den Harness. Eine Scaffolding-Analyse (LLM-29, 2026-06) fand Harness-bedingte Differenzen bis zu 28 Punkte. Deshalb sind SWE-bench-Scaffolds nicht direkt zwischen Herstellern vergleichbar – jeder misst im eigenen Werkzeug.

Analog bei Gemini 3 Pro (LLM-06): 76% Herstellerangabe Google vs. 69,60% Leaderboard. Gleicher Effekt: Harness-Unterschied.

4. pass@1 vs. pass@k

pass@1: Eine Lösung, ein Versuch – entspricht der realen Nutzung in der Produktion.
pass@k (k=5, 10 …): Mehrere Lösungen generieren, eine davon stimmt. Sieht beeindruckend aus, ist aber eine andere Aussage (LLM-27). Verwechsle die beiden nie beim Vergleich.

5. Self-Reported vs. unabhängig gemessen

Herstellerangaben sind Selektion: Sie werden im günstigsten Harness, mit der besten Sampling-Strategie und oft ohne Kontamination-Prüfung erhoben. Behandle Herstellerzahlen immer als „Herstellerangabe, eigener Harness" – nicht als Fakt. Beispiel GPT-5.2: 80% SWE-bench Verified (LLM-02) ist eine reine Herstellerangabe im OpenAI-eigenen Harness.

6. Test-Time-Compute

Ein Modell darf „nachdenken" (Reasoning, Tool-Use, mehrere Versuche) und dabei mehr Rechenzeit verbrauchen. Mehr Compute verbessert oft die Punktzahl – ohne dass das Modell selbst besser ist. Beim Vergleich muss das Compute-Budget gleich sein (LLM-27).

7. ELO / Arena-Grenzen

LMArena sammelt menschliche Präferenzen zu Chat-Antworten und errechnet einen ELO-Wert. Nützlich für „wie das Modell im Chat ankommt", aber: subjektiv, sprachlich verzerrt (viel Englisch), und innerhalb der Top 10 liegen oft nur etwa 20 ELO-Punkte – eine klare Rangfolge „das beste Modell" ist daraus nicht ableitbar (LLM-23).

8. Composite-Scores (Intelligence Index)

Artificial Analysis Intelligence Index V2 fasst mehrere Benchmarks zu einer Zahl zusammen. Praktisch, aber immer eine Redaktion – prüfe, welche Benchmarks eingehen und wie gewichtet wird (LLM-24).

9. Warum die eigene Aufgabensuite nötig ist

Öffentliche Benchmarks sind ein Stichproben-Indikator, kein Beweis für deinen Fall. Wenn du Python-Code mit einer internen Bibliothek reparieren willst, misst SWE-bench (Open-Source-Repositories) eine andere Welt. Bau eine kleine eigene Suite aus echten Aufgaben – 20–50 Fälle reichen für einen ersten Realitätscheck. Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Snapshot SWE-bench Verified (Stand 2026, Zugriff 2026-07-20)

Modell	Herstellerangabe	Leaderboard (`mini-SWE-agent`)	Hinweis
Claude Opus 4.5	80,9% (Anthropic-Harness)	76,80%	LLM-04
Gemini 3 Pro	76% (Google-Harness)	69,60%	LLM-06
GPT-5.6	nicht verfügbar	nicht verfügbar	Aktuelles Closed-Modell; keine gleichartige unabhängige Messung in dieser Tabelle
Gemini 3.1 Pro	nicht verfügbar	nicht verfügbar	Aktuelles Closed-Modell; Hersteller- und unabhängige Messung getrennt ausweisen
GLM-5.2	nicht verfügbar	nicht verfügbar	Aktuelles Modell; unabhängige Messung nicht verfügbar
MiniMax M3	nicht verfügbar	nicht verfügbar	Aktuelles Modell; unabhängige Messung nicht verfügbar
DeepSeek V3.2	–	70,0%	LLM-10

Snapshot-Warnung: Die Leaderboard-Werte ändern sich täglich. Herstellerangaben sind Selektion.

Verwandte Begriffe für die Vertiefung: AI-Hardware für lokale Modelle, Quantisierung lokaler Modelle, LLM-Grundlagen.

Auf Expertenniveau geht es darum, Benchmarks nicht zu überschätzen und Saturierungseffekte zu erkennen.

Warum alte saturierte Benchmarks keine aktuelle Frontier-Rangliste beweisen

Sobald eine Benchmark „saturiert" ist – fast alle Frontier-Modelle liegen eng beieinander nahe der 100% – verliert sie Trennkraft. MMLU und der ursprüngliche Open LLM Leaderboard sind Beispiele: Sie trennen nicht mehr zwischen aktuellen Top-Modellen. Wer heute aus einem saturierten Benchmark eine Rangliste „das beste Modell" ableitet, überschreitet die Aussagekraft der Daten.

Praxisfallen

Herstellerzahl = Fakt: Eine Herstellerangabe ist eine Selektion, kein unabhängiger Befund. Immer Harness und Datum prüfen.
Apples-to-Oranges: Verschiedene Harnesses, Sampling-Strategien und Compute-Budgets in einer Tabelle vermischen.
Snapshot als Ewigkeit: Eine Zahl von vor 6 Monaten für „das beste Modell heute" halten, obwohl Live-Benchmarks sich täglich bewegen.
Kontamination ignoriert: Eine statische Benchmark verwenden, ohne zu prüfen, ob sie kontaminiert ist.
Eine Zahl für alles: SWE-bench misst Software-Engineering. Es sagt nichts über Zusammenfassen, Übersetzen oder Reasoning in deinem Anwendungsfall.
Hype-Auswahl: Ein Modell nach viralen Rankings wählen, nicht nach Datenlage, Hardware, Lizenz, Latenz und eigener Qualitätsmessung.
Lokale Verarbeitung = sicher: Lokal heißt nicht automatisch datenschutzsicher – Logs, Plugins, Downloads, Benutzerrechte bleiben relevant.

Goldstandard

Du kannst einem Laien erklären, warum eine Benchmark-Zahl allein nichts beweist; den Harness-Effekt am Claude-Opus-4.5-Beispiel (80,9% vs. 76,80%) nachvollziehbar zeigen; eine eigene Mini-Suite aus realen Aufgaben bauen; Grenzen sauber benennen; und deine Entscheidung mit Quelle, Harness und Datum dokumentieren.