Zum Hauptinhalt springen
Die reine Parameteranzahl verrät Ihnen nicht, ob ein Modell gut ist. Ein 7B-Modell, das mit den richtigen Daten trainiert wurde, kann bei Programmieraufgaben ein nachlässiges 13B-Modell übertreffen, und ein gut abgestimmtes 8B-Modell kann ein 70B-Modell beim Befolgen von Anweisungen schlagen. Ohne eine Möglichkeit, die Fähigkeiten zu messen, raten Sie nur. Evaluationsbenchmarks – „Evals“ – sind standardisierte Tests, die Ihnen vergleichbare Zahlen über verschiedene Modelle hinweg liefern. Sie sind unvollkommen, manchmal irreführend und gelegentlich manipulierbar, aber sie sind das beste verfügbare Werkzeug, um Modelle zu vergleichen, bevor Sie Hardware für eines davon bereitstellen. Diese Seite erklärt, was die wichtigsten Benchmarks messen, wie man ihre Scores liest und welche für Ihren Anwendungsfall tatsächlich relevant sind.

​
Warum Evals existieren

Sie können ein Modell nicht allein anhand seiner Parameteranzahl, der Größe der Trainingsdaten oder seiner Architektur beurteilen. Diese Zahlen beschreiben die Kapazität – was das Modell theoretisch tun könnte – nicht die Fähigkeit, was es tatsächlich tut, wenn Sie ihm einen Prompt geben. Benchmarks existieren, um diese Lücke zu schließen. Ein guter Benchmark:
  • Standardisiert den Vergleich – jedes Modell beantwortet dieselben Fragen unter denselben Bedingungen.
  • Zeigt Stärken und Schwächen auf – ein Modell, das bei Mathematik gut abschneidet, kann bei Code mittelmäßig sein.
  • Verfolgt den Fortschritt – Sie können sehen, ob eine neue Modellgeneration tatsächlich verbessert wurde oder nur größer geworden ist.
Aber jeder Benchmark hat blinde Flecken. Ein hoher MMLU-Score garantiert nicht, dass das Modell gute E-Mails schreibt. Ein niedriger HumanEval-Score bedeutet nicht, dass das Modell Ihnen nicht beim Debuggen helfen kann. Benchmarks sind ein Ausgangspunkt, kein Urteil.

​
Die Benchmark-Landschaft

Hier sind die wichtigsten Benchmarks, die Sie auf Modellkarten und Bestenlisten finden werden:
MMLU (Massive Multitask Language Understanding) ist der am häufigsten zitierte Benchmark. Er deckt 57 Fächer aus STEM, Geisteswissenschaften und Sozialwissenschaften auf High-School- bis Berufsebene ab. Jede Frage ist Multiple-Choice mit 4 Optionen. Ein Score von 70 bedeutet, dass das Modell 70% dieser Fragen richtig beantwortet. MMLU ist nützlich als breites Fähigkeits-Signal, testet aber keine offene Generierung, Kreativität oder das Befolgen von Anweisungen. Die meisten Modellkarten berichten den 5-Shot-Score.
Diese 2 Benchmarks messen die Code-Generierung. HumanEval hat 164 handgeschriebene Python-Probleme, bei denen das Modell eine Funktion aus einem Docstring generiert, dann werden Tests ausgeführt, um die Korrektheit zu überprüfen. MBPP ist größer (~1000 Probleme), deckt aber einfachere algorithmische Aufgaben ab. Beide berichten pass@1 – den Prozentsatz der Probleme, die beim ersten Versuch korrekt gelöst wurden. Sie sind gut zum Vergleich der Programmierfähigkeit, decken aber nur einen schmalen Ausschnitt der realen Programmierung ab.
MT-Bench bewertet die Konversationsqualität durch 80 mehrstufige Prompts, die von GPT-4 oder menschlichen Richtern auf einer 1–10-Skala bewertet werden. Chatbot Arena (LMSYS) ist anders: Es stellt 2 anonyme Modelle gegeneinander und lässt die Nutzer abstimmen, was eine ELO-Rangliste wie bei Schachratings erzeugt. Arena-Scores spiegeln die Präferenzen realer Nutzer wider, aktualisieren sich aber langsam und bevorzugen Modelle, die polierte, selbstbewusst klingende Antworten produzieren, gegenüber Modellen, die korrekt, aber knapp sind.
SWE-Bench testet, ob ein Modell echte GitHub-Issues end-to-end lösen kann: das Issue lesen, den Bug in einer großen Codebasis finden und einen korrekten Pull Request generieren. Top-Modelle lösen 30–50% der Issues im verifizierten Subset. Dies ist der Benchmark, der der tatsächlichen Softwareentwicklungsarbeit am nächsten kommt, aber er ist extrem schwierig und die Ergebnisse variieren stark je nach Sprache und Framework.
LiveBench aktualisiert seinen Testsatz monatlich mit neuen Daten, was ihn resistent gegen Benchmark-Kontamination macht – Modelle können keine Antworten auswendig gelernt haben, die sie während des Trainings nicht gesehen haben. Es deckt Mathematik, Programmierung, Schlussfolgern, Sprache, Datenanalyse und das Befolgen von Anweisungen ab. Es ist neuer als MMLU oder HumanEval, wird aber zunehmend als vertrauenswürdigeres Signal zitiert.

​
Wie man eine Benchmark-Tabelle liest

Scores sehen autoritativ aus, brauchen aber Kontext, um nützlich zu sein.

​
Was die Zahlen bedeuten

Die meisten Benchmarks berichten einen Score von 0 bis 100, was der Prozentsatz der Fragen ist, die das Modell korrekt beantwortet hat. Ein MMLU-Score von 70 bedeutet, dass das Modell 70% der Multiple-Choice-Fragen auf College-Niveau richtig beantwortet. ELO-Ratings (verwendet von Chatbot Arena) sind anders – es sind relative Rankings, bei denen eine 100-Punkte-Lücke bedeutet, dass das höher bewertete Modell in etwa 64% der direkten Duells gewinnt.

​
Fehlermarge

Ein Unterschied von 1–2 Punkten bei einem einzelnen Benchmark ist Rauschen. Scoring-Methodik, Prompt-Formatierung und sogar Variationen des Zufallssamens können Scores um diesen Betrag verschieben. Wenn Modell A 72 und Modell B 74 auf MMLU erzielt, behandeln Sie sie als gleichwertig und schauen Sie sich einen Benchmark an, der die spezifische Fähigkeit testet, die Sie interessieren.

​
Kontamination

Benchmark-Kontamination tritt auf, wenn Testfragen in die Trainingsdaten eines Modells gelangen. Das Modell erzielt künstlich hohe Scores, weil es die Antworten bereits gesehen hat. Dies ist ein wachsendes Problem, da Benchmarks weit verbreitet werden. LiveBench und einige neuere Benchmarks bekämpfen dies, indem sie ihre Testsätze regelmäßig aktualisieren.
Wenn der Benchmark-Score eines Modells im Vergleich zu seiner Leistung in der realen Welt verdächtig hoch erscheint, ist Kontamination eine wahrscheinliche Erklärung. Überprüfen Sie, ob der Benchmark vor dem Trainings-Cutoff-Datum des Modells veröffentlicht wurde.

​
Cherry-Picking

Beurteilen Sie niemals ein Modell anhand eines einzelnen Benchmarks. Verleger heben manchmal den 1 Score hervor, bei dem ihr Modell am besten aussieht, während sie schwächere Ergebnisse verschweigen. Suchen Sie nach einer Reihe von Benchmarks, die verschiedene Fähigkeiten abdecken – Wissen, Code, Mathematik, Befolgen von Anweisungen – bevor Sie Schlussfolgerungen ziehen.

​
Welche Benchmarks für Ihren Anwendungsfall relevant sind

Nicht jeder Benchmark ist für jede Aufgabe relevant. Konzentrieren Sie sich auf diejenigen, die testen, was Sie tatsächlich benötigen:

Coding-Assistent

Schauen Sie auf: HumanEval, MBPP, SWE-Bench. Diese messen direkt die Code-Generierung und Softwareentwicklung. Ignorieren Sie MMLU für diese Entscheidung – ein Modell kann bei Trivia hohe Scores erzielen und trotzdem schlechten Code schreiben.

Chatbot und allgemeine Konversation

Schauen Sie auf: MT-Bench, Chatbot Arena ELO, IFEval. Konversationsqualität ist subjektiv, daher sind von Menschen bewertete Benchmarks am wichtigsten. IFEval fügt ein Maß dafür hinzu, ob das Modell Formatierungs- und Einschränkungsanweisungen zuverlässig befolgt.

Schlussfolgern und Analyse

Schauen Sie auf: GSM8K, MATH, GPQA, ARC-Challenge, BigBench Hard. Diese testen mehrstufige Logik auf verschiedenen Schwierigkeitsstufen. GPQA ist das schwierigste – nützlich, um Frontier-Modelle von bloß guten zu trennen.

Allgemeiner Assistent

Schauen Sie auf: MMLU + MT-Bench + IFEval als Komposit. Keine einzelne Zahl erfasst die Qualität eines „allgemeinen Assistenten”. Überprüfen Sie alle 3, um ein Bild von Wissensbreite, Konversationsfähigkeit und Anweisungscompliance zu erhalten.
Wenn Sie 2 ähnliche Modelle vergleichen, überspringen Sie die Durchschnitte und schauen Sie sich den spezifischen Benchmark an, der Ihrer Aufgabe entspricht. Ein 7B-Coding-Modell und ein 7B-Chat-Modell könnten ähnliche MMLU-Scores haben, aber sehr unterschiedliche HumanEval-Ergebnisse.

​
Benchmark-Scores bei verschiedenen Quantisierungen

Benchmark-Scores werden normalerweise bei voller Präzision (FP16 oder BF16) berichtet. Wenn Sie ein quantisiertes Modell lokal ausführen, erwarten Sie eine gewisse Score-Verschlechterung.

​
Wie viel kostet die Quantisierung?

Die Auswirkung hängt vom Benchmark, der Modellgröße und dem Quantisierungslevel ab:

​
Wann die Quantisierung mehr schadet

  • Kleine Modelle verlieren mehr als große Modelle. Ein 7B-Modell, das auf Q4_K_M quantisiert ist, fällt mehr als ein 70B-Modell auf demselben Quant-Level, weil das kleinere Modell weniger Redundanz hat, um Rundungsfehler zu absorbieren.
  • Präzise Aufgaben leiden mehr. Mathematik und Code-Generierung sind empfindlicher gegenüber Gewichtspräzision als allgemeine Chats. Wenn Sie einen Coding-Assistenten ausführen, erwägen Sie Q5_K_M oder höher.
  • I-Quants können bei niedrigen Bit-Breiten helfen. Imatrix-Quantisierung (IQ4_XS, IQ3_XXS) bewahrt kritische Gewichte sorgfältiger und kann im Vergleich zu Standard-K-Quants derselben Größe 1–2 Punkte wiederherstellen.
Ein 70B-Modell bei Q4_K_M übertrifft fast immer ein 7B-Modell bei voller Präzision in den meisten Benchmarks. Die Modellgröße ist wichtiger als das Quantisierungslevel, wenn die Größenlücke groß ist.

​
Eigene Evals ausführen

Veröffentlichte Benchmarks sind ein Ausgangspunkt. Wenn Sie wissen müssen, wie ein Modell bei Ihren Aufgaben mit Ihrer Einrichtung abschneidet, führen Sie Ihre eigene Evaluation durch.

​
Wann Sie Ihre eigenen ausführen sollten

  • Sie haben einen domänenspezifischen Anwendungsfall (Recht, Medizin, Finanzen), den Standardbenchmarks nicht abdecken.
  • Sie vergleichen 2 Modelle, die bei öffentlichen Benchmarks ähnlich abschneiden.
  • Sie testen eine spezifische Quantisierung oder Feinabstimmung und möchten die tatsächliche Auswirkung messen.
  • Sie müssen validieren, dass ein Modell Ihre Randfälle handhabt, bevor Sie es bereitstellen.

​
Werkzeuge zum Ausführen von Evals

lm-evaluation-harness (von EleutherAI) ist das Standard-Open-Source-Werkzeug. Es unterstützt 60+ akademische Benchmarks out of the box und läuft gegen jedes Modell, das über llama.cpp, vLLM oder eine OpenAI-kompatible API bereitgestellt wird:
OpenAI Evals und HELM (Stanford) sind Alternativen mit verschiedenen Aufgabenbibliotheken und Berichtsformaten.

​
Eine einfache benutzerdefinierte Eval

Sie brauchen kein Framework, um domänenspezifische Qualität zu testen:
  1. Schreiben Sie 50 Fragen aus Ihrem tatsächlichen Anwendungsfall.
  2. Senden Sie jede Frage an das Modell und protokollieren Sie die Antwort.
  3. Bewerten Sie jede Antwort auf einer 1–5-Skala (oder Pass/Fail für faktische Fragen).
  4. Wiederholen Sie dies für jedes Modell, das Sie vergleichen.
50 Fragen reichen aus, um große Unterschiede zu erkennen. Verwenden Sie dieselben Fragen für jedes Modell und bewerten Sie blind (verstecken Sie, welches Modell welche Antwort produziert hat), um Verzerrungen zu vermeiden.

​
Wann Sie veröffentlichten Scores vertrauen sollten

Vertrauen Sie veröffentlichten Benchmark-Scores, wenn:
  • Der Modellverleger eine Historie ehrlicher Berichterstattung hat (Meta, Google, Mistral, Qwen, Anthropic).
  • Mehrere unabhängige Quellen ähnliche Zahlen bestätigen.
  • Der Benchmark nach dem Trainings-Cutoff des Modells veröffentlicht wurde (reduziert das Kontaminationsrisiko).
Führen Sie Ihre eigene Eval durch, wenn:
  • Sie eine Drittanbieter-Quantisierung verwenden und überprüfen möchten, ob sie die Qualität nicht signifikant verschlechtert hat.
  • Ihre Aufgabe eng genug ist, dass allgemeine Benchmarks nicht zutreffen.
  • Sie eine Produktionsentscheidung treffen und mehr Vertrauen als eine Bestenlistennummer benötigen.

​
Warnsignale in der Benchmark-Berichterstattung

Nicht jeder Benchmark-Anspruch ist vertrauenswürdig. Achten Sie auf diese Muster:
  • Keine Quantisierung offengelegt. „Unser Modell erzielt 78 auf MMLU” – bei welcher Präzision? Wenn sie es nicht sagen, berichten sie möglicherweise Vollpräzision-Scores für ein Modell, das die meisten Nutzer quantisiert ausführen werden.
  • Nur den besten Benchmark berichten. Eine Modellseite, die 1 Score hervorhebt und andere weglässt, betreibt Cherry-Picking. Suchen Sie nach einer vollständigen Benchmark-Tabelle.
  • Vergleich verschiedener Modellgrößen. „Unser 7B-Modell schlägt ein 70B-Modell bei X” – ja, bei einem engen Benchmark, der die Trainingsdaten des 7B begünstigt. Dies ist kein fairer Vergleich.
  • Kontaminierte Benchmarks ohne Offenlegung. Wenn die Trainingsdaten eines Modells wahrscheinlich den Testsatz des Benchmarks enthielten und der Verleger dies nicht anspricht, behandeln Sie den Score skeptisch.
  • „Schlägt GPT-4 bei…” Fast immer bei einem engen, günstigen Benchmark. GPT-4 ist ein großes proprietäres Modell – es bei 1 spezifischer Aufgabe zu schlagen, bedeutet nicht, dass das Modell allgemein besser ist.
  • Keine Methodik beschrieben. Wenn der Score keine Details wie Shot-Anzahl, Prompt-Format und Bewertungsmethode enthält, können Sie ihn nicht mit anderen veröffentlichten Zahlen vergleichen.

​
Wo man Benchmark-Daten findet

Kreuzreferenzieren Sie mindestens 2 Quellen, bevor Sie einer Benchmark-Zahl vertrauen. Wenn das Open LLM Leaderboard und das eigene Papier des Modells unterschiedliche Scores berichten, untersuchen Sie, warum – es ist normalerweise ein Unterschied in den Evaluierungseinstellungen (Shot-Anzahl, Prompt-Format oder Quantisierung).

​
Tiefer einsteigen

Modellnamen lesen

Decodieren Sie Modellnamen, Quantisierungslabels und Architektur-Suffixe, bevor Sie sich Benchmarks ansehen.

Modellkarten lesen

Finden Sie die Parameter, Architektur, Kontextlänge und Lizenz, die Benchmarks nicht abdecken.

Quantisierung

Verstehen Sie, wie Quantisierung die Benchmark-Scores beeinflusst, die Sie gerade gelernt haben zu lesen.

Welches lokale Modell für welche Aufgabe?

Verwenden Sie Benchmark-Einblicke, um ein Modell auszuwählen, das auf Ihren spezifischen Anwendungsfall abgestimmt ist.