Die Hugging Face Open LLM Leaderboard, jahrelang die erste Anlaufstelle für Modellvergleiche, wurde 2025 offiziell abgeschaltet. Wer heute wissen will, ob DeepSeek V4 Flash, Llama 4 oder Mistral für den eigenen Use Case taugt, kommt an einer unbequemen Wahrheit nicht vorbei: Öffentliche Ranglisten sind kontaminiert, veraltet oder schlicht verschwunden. Die einzige verlässliche Antwort bekommt man, indem man selbst benchmarkt. Dieses Tutorial zeigt Schritt für Schritt, wie du mit dem Open-Source-Tool lm-evaluation-harness von EleutherAI und dem kontaminationsfreien LiveBench-Framework ein eigenes, reproduzierbares Testsetup aufbaust, lokal auf deiner eigenen Hardware.

Das Problem ist real: Modelle werden zunehmend auf Trainingsdaten optimiert, die zufällig (oder absichtlich) Benchmark-Fragen enthalten. Ein Modell, das MMLU auswendig gelernt hat, sieht auf dem Papier stark aus, versagt aber bei echten Aufgaben. lm-evaluation-harness gilt laut mehreren 2026er Vergleichsartikeln weiterhin als Standard-Infrastruktur für akademische LLM-Evaluation und treibt historisch auch das (inzwischen eingestellte) Hugging Face Open LLM Leaderboard an. LiveBench wiederum aktualisiert seine Aufgaben monatlich mit frischem Material aus Mathe-Wettbewerben, arXiv-Papern und Nachrichtenartikeln, gerade um Kontamination zu vermeiden. Am Ende dieses Tutorials hast du ein funktionierendes Vergleichsprojekt für zwei Modelle, verstehst die wichtigsten Stolperfallen und weißt, wie du die Ergebnisse einordnest.

Anders als bei einem einmaligen Blick auf ein Marketing-Diagramm bekommst du mit diesem Setup eine Zahl, die zu deiner eigenen Hardware, deinem eigenen Anwendungsfall und deinem eigenen Prompt-Format passt. Das ist der entscheidende Unterschied: Ein Anbieter, der sein Modell gegen MMLU im 5-Shot-Format mit optimiertem Prompt testet, kann auf dem Papier deutlich besser aussehen als bei dir im Zero-Shot-Betrieb mit deinem tatsächlichen Systemprompt. Wer die Kontrolle über die Testbedingungen selbst übernimmt, verhindert genau diese Verzerrung.

Warum ein eigener LLM Benchmark 2026 unverzichtbar ist

Bis vor Kurzem reichte ein Blick auf öffentliche Leaderboards, um sich für ein Modell zu entscheiden. Diese Zeiten sind vorbei. Die Hugging Face Open LLM Leaderboard-Diskussion bestätigt die Einstellung des Dienstes offiziell mit den Worten „all good things come to an end” und verweist Nutzer stattdessen auf Nachfolgeprojekte wie EuroEval und verschiedene Community-Leaderboards über den OpenEvals-Suchbereich. Für Entwickler in Deutschland, Österreich und der Schweiz bedeutet das: Es gibt keine zentrale, autoritative Rangliste mehr, der man blind vertrauen kann.

Gleichzeitig erscheinen offene Modelle im Wochentakt. Wer regelmäßig zwischen DeepSeek-, Llama-, Mistral- oder Kimi-Varianten wechseln will, braucht eine Methode, um Behauptungen aus Release-Notes selbst zu überprüfen. Ein selbst gehosteter Benchmark löst gleich drei Probleme auf einmal: Er läuft auf genau der Hardware, die du auch produktiv nutzt, er testet genau die Aufgaben, die für dein Projekt relevant sind, und er bleibt reproduzierbar, wenn ein Anbieter seine Zahlen später anders darstellt. lm-evaluation-harness bringt dafür laut GitHub-Repository von EleutherAI ein „einheitliches Framework, um generative Sprachmodelle gegen eine große Zahl unterschiedlicher Evaluationsaufgaben zu testen” mit, aktuell in der aktiv gepflegten 0.4.x-Versionsreihe.

Wichtig für die Einordnung: Dieses Tutorial ersetzt keine wissenschaftliche Studie. Es zeigt dir das Handwerkszeug, mit dem du selbst belastbare, nachvollziehbare Zahlen produzierst, statt dich auf Marketing-Folien zu verlassen. Das lohnt sich besonders, wenn dein Team ein Modell für Support-Chats, Codegenerierung oder interne Wissenssuche einsetzen will und dabei Wert auf Nachvollziehbarkeit legt.

Ein weiterer Grund, der oft unterschätzt wird: Compliance und interne Dokumentationspflichten. Wenn dein Unternehmen ein KI-Modell für kundennahe Prozesse einsetzt, reicht ein Verweis auf ein fremdes Leaderboard in vielen Fällen nicht mehr aus, um die Modellwahl gegenüber Datenschutzbeauftragten, Kunden oder Aufsichtsbehörden zu begründen. Ein selbst durchgeführter, dokumentierter Test mit klaren Testbedingungen liefert genau die Nachvollziehbarkeit, die für solche internen Freigabeprozesse gebraucht wird, unabhängig davon, ob ein externer Anbieter seine eigenen Zahlen später revidiert oder ein Modell durch ein stilles Update ausgetauscht wird.

MMLU, GSM8K und Co.: Die wichtigsten Standard-Tasks im Überblick

Bevor du den ersten Befehl tippst, hilft ein kurzer Überblick, welcher Task welche Fähigkeit misst. lm-evaluation-harness bündelt Dutzende Tasks, aber ein Großteil der Vergleiche in der Praxis stützt sich auf eine Handvoll etablierter Kandidaten. Wer versteht, was ein Task tatsächlich prüft, vermeidet den häufigsten Anfängerfehler: einen einzelnen Score als Aussage über die gesamte Modellqualität misszuverstehen, obwohl er nur einen schmalen Ausschnitt abdeckt.

TaskWas er misstFormat
MMLUAllgemeinwissen über 57 Fachbereiche, von Jura bis AstronomieMultiple-Choice
GSM8KMehrschrittiges mathematisches Denken in TextformFreitext mit exakter Zahlenantwort
HellaSwagAlltagslogik und plausible Fortsetzung von SituationenMultiple-Choice
ARC-Easy / ARC-ChallengeNaturwissenschaftliches Schlussfolgern auf SchulniveauMultiple-Choice
TruthfulQAWiderstand gegen verbreitete Falschaussagen und MythenMultiple-Choice / Freitext

Für die meisten praktischen Vergleiche reicht eine Kombination aus zwei bis vier dieser Tasks völlig aus. Willst du ein Modell speziell für Coding-Assistenz einsetzen, ergänze die Suite um coding-spezifische Tasks wie HumanEval, statt dich ausschließlich auf allgemeine Wissenstests zu verlassen, die für deinen konkreten Use Case wenig aussagekräftig sind. Ein Modell mit starkem MMLU-Score kann bei praktischen Programmieraufgaben trotzdem schwächeln, die beiden Fähigkeiten korrelieren nur begrenzt.

Halte dich bei der Task-Auswahl an eine einfache Regel: Wähle Aufgaben, die so nah wie möglich an dem liegen, was das Modell später tatsächlich tun soll. Ein Modell für einen internen Rechtschreib- und Grammatik-Assistenten profitiert wenig von einem starken TruthfulQA-Score, während ein Modell für automatisierte Datenanalyse-Reports stark von GSM8K- und Reasoning-lastigen Tasks abhängt. Die Standardtasks sind ein guter Ausgangspunkt, ersetzen aber nicht das Nachdenken über den eigentlichen Einsatzzweck.

Voraussetzungen: Hardware, Software und Accounts

Bevor es losgeht, brauchst du eine funktionierende Python-Umgebung und genug Rechenleistung für das Modell, das du testen willst. Die folgende Liste zeigt, was du in der Praxis wirklich brauchst, keine Marketingzahlen, sondern reale Mindestanforderungen für ein Setup, mit dem sich 7B- bis 13B-Modelle auf handelsüblicher Hardware evaluieren lassen.

Software-Voraussetzungen

  • Python 3.10 oder neuer (getestet mit 3.10, 3.11, 3.12)
  • pip, aktuelle Version (python -m pip install --upgrade pip)
  • Git für den Klon des lm-evaluation-harness-Repositorys
  • Optional: Ollama, wenn du Modelle lokal über eine einfache API bereitstellen willst
  • Optional: vLLM, wenn du die Inferenz beschleunigen willst (empfohlen ab 13B-Modellen)
  • Ein Hugging Face Account mit Access Token, falls du gated Modelle laden willst

Hardware-Anforderungen

Als Faustregel gilt: Ein Modell in 4-Bit-Quantisierung braucht ungefähr die Hälfte seines Parameterwerts in Gigabyte VRAM, ein 7B-Modell also grob 4 bis 5 GB, ein 13B-Modell entsprechend mehr. Für CPU-only-Setups ohne GPU brauchst du stattdessen ausreichend Arbeitsspeicher, rechne hier eher mit dem Vierfachen der Parameterzahl in Gigabyte RAM, da CPU-Inferenz ohne Quantisierungstricks deutlich mehr Puffer benötigt. Eine RTX 4060 mit 8 GB VRAM reicht für kleinere 7B-Modelle in 4-Bit, für 13B- bis 30B-Modelle solltest du mindestens 16 bis 24 GB VRAM einplanen oder auf eine Cloud-GPU-Instanz ausweichen.

KomponenteEmpfohlene VersionZweck
Python3.10+Laufzeitumgebung für lm-evaluation-harness
lm-evaluation-harness0.4.x (aktiv gepflegt)Kernframework für Benchmark-Tasks
PyTorchaktuelle stabile VersionBackend für lokale Modellinferenz
Ollamaaktuelle VersionEinfaches lokales Modell-Serving
vLLMaktuelle VersionSchnellere Batch-Inferenz für größere Modelle
Git2.xRepository-Klon und Versionsverwaltung

Plane für das komplette Tutorial etwa 90 Minuten ein, davon entfallen rund 20 Minuten auf Installation und Modell-Download (abhängig von deiner Internetverbindung) und der Rest auf die eigentlichen Testläufe. Ein einzelner MMLU-Durchlauf gegen ein 7B-Modell auf einer Mittelklasse-GPU dauert üblicherweise zwischen 5 und 15 Minuten, je nach Sample-Größe und Batch-Konfiguration.

Schritt 1 und 2: Python-Umgebung und lm-evaluation-harness installieren

Beginne mit einer sauberen virtuellen Umgebung. Das verhindert, dass sich Paketversionen mit anderen Projekten auf deinem System in die Quere kommen, ein Klassiker unter den Fehlerquellen bei Python-Tools.

# Schritt 1: Virtuelle Umgebung anlegen und aktivieren
python3 -m venv llm-bench-env
source llm-bench-env/bin/activate  # unter Windows: llm-bench-env\Scripts\activate

# Schritt 2: lm-evaluation-harness installieren
git clone https://github.com/EleutherAI/lm-evaluation-harness.git
cd lm-evaluation-harness
pip install -e .

# Optional: Erweiterungen für Hugging Face, vLLM oder API-Modelle
pip install -e ".[hf]"
pip install -e ".[vllm]"
pip install -e ".[api]"

Die Installation über pip install -e . installiert das Paket im „editable”-Modus, was praktisch ist, falls du später eigene Tasks hinzufügen willst (dazu mehr in Schritt 9). Prüfe direkt danach, ob die Installation funktioniert hat:

lm_eval --help
lm-eval ls tasks | head -20

Erscheint eine Liste mit verfügbaren Tasks wie mmlu, gsm8k, hellaswag oder arc_easy, war die Installation erfolgreich. Neuere 0.4.x-Releases bringen zusätzlich eine subcommand-Syntax mit (lm-eval run, lm-eval ls tasks, lm-eval validate), die alte lm_eval --model ...-Syntax bleibt aber vollständig abwärtskompatibel.

Schritt 3 und 4: Ein lokales Modell laden und bereitstellen

Für dieses Tutorial nutzen wir Ollama als einfachsten Einstiegspunkt, weil es Modell-Downloads, Quantisierung und lokales Serving in einem einzigen Befehl bündelt. Wenn du bereits Erfahrung mit Hugging Face Transformers hast, funktioniert lm-evaluation-harness genauso gut direkt gegen ein lokal geladenes Modell, ohne Ollama als Zwischenschicht.

# Schritt 3: Ollama installieren (Linux/Mac)
curl -fsSL https://ollama.com/install.sh | sh

# Schritt 4: Modell herunterladen und Server starten
ollama pull llama3.1:8b
ollama serve &

# Test, ob der Server erreichbar ist
curl http://localhost:11434/api/tags

Alternativ, wenn du direkt mit Hugging-Face-Gewichten arbeiten willst (nötig, wenn du Modelle einsetzt, die nicht über Ollamas Registry verfügbar sind), lädst du das Modell stattdessen so:

# Alternative: Hugging Face Modell direkt referenzieren
export HF_TOKEN="dein_hugging_face_token"
lm_eval --model hf \
  --model_args pretrained=meta-llama/Llama-3.1-8B,dtype=bfloat16 \
  --tasks mmlu \
  --device cuda:0 \
  --batch_size 8 \
  --limit 10

Der Parameter --limit 10 beschränkt den Testlauf auf zehn Beispiele pro Task, praktisch für einen schnellen Rauchtest, bevor du den vollen Durchlauf startest. Entferne ihn für den echten Benchmark, sonst bekommst du keine belastbaren Werte.

Schritt 5 und 6: Deinen ersten Benchmark-Lauf starten

Jetzt kommt der eigentliche Test. lm-evaluation-harness unterstützt Dutzende vordefinierte Tasks, die bekanntesten sind MMLU (allgemeines Wissen über 57 Fachbereiche), GSM8K (Mathe-Textaufgaben) und HellaSwag (Alltagslogik). Für einen ersten, vollständigen Lauf gegen dein über Ollama laufendes Modell nutzt du das local-completions-Backend, das mit jedem OpenAI-kompatiblen Server funktioniert.

# Schritt 5: Ersten vollständigen Task ausführen
lm_eval --model local-completions \
  --model_args model=llama3.1:8b,base_url=http://localhost:11434/v1/completions \
  --tasks gsm8k \
  --output_path ./ergebnisse/llama31-8b-gsm8k

# Schritt 6: Ergebnis direkt in der Konsole prüfen
cat ./ergebnisse/llama31-8b-gsm8k/results.json | python3 -m json.tool

Eine typische Ausgabe im Terminal sieht so aus (Werte sind Platzhalter zur Illustration des Formats, keine veröffentlichten Ergebnisse eines bestimmten Modells):

|Tasks|Version|Filter|n-shot|Metric|Value|Stderr|
|-----|-------|------|-----:|------|----:|-----:|
|gsm8k|    3.0|strict|     5|exact_match|0.62|0.014|

Running gsm8k: 100%|██████████| 1319/1319 [08:42<00:00, 2.52it/s]
Ergebnisse gespeichert unter: ./ergebnisse/llama31-8b-gsm8k/results.json

Die Spalte exact_match zeigt den Anteil exakt korrekt gelöster Aufgaben, Stderr den Standardfehler der Schätzung. Je kleiner die Stichprobe (gesteuert über --limit), desto größer die Schwankungsbreite, deshalb solltest du für belastbare Vergleiche immer den vollen Task-Datensatz laufen lassen und nicht nur ein paar Dutzend Beispiele.

Schritt 7 und 8: Mehrere Tasks und Few-Shot-Konfiguration kombinieren

In der Praxis willst du selten nur einen einzelnen Task testen. lm-evaluation-harness erlaubt es, mehrere Tasks in einem Durchlauf zu kombinieren, getrennt durch Kommas. Zusätzlich lässt sich die Zahl der Few-Shot-Beispiele steuern, also wie viele Beispielaufgaben das Modell vor der eigentlichen Testfrage als Kontext bekommt.

# Schritt 7: Mehrere Tasks in einem Lauf kombinieren
lm_eval --model local-completions \
  --model_args model=llama3.1:8b,base_url=http://localhost:11434/v1/completions \
  --tasks mmlu,gsm8k,hellaswag,arc_easy \
  --output_path ./ergebnisse/llama31-8b-suite

# Schritt 8: Few-Shot-Anzahl explizit setzen
lm_eval --model local-completions \
  --model_args model=llama3.1:8b,base_url=http://localhost:11434/v1/completions \
  --tasks mmlu \
  --num_fewshot 5 \
  --apply_chat_template \
  --system_instruction "Du bist ein präziser Assistent, der Fragen exakt beantwortet."

Der Parameter --apply_chat_template ist besonders wichtig für Instruct-Modelle: Ohne ihn testest du das Modell im Rohformat, was die Ergebnisse künstlich verschlechtern kann, weil Chat-Modelle auf ihr eigenes Prompt-Format trainiert wurden. Neuere 0.4.x-Releases unterstützen zusätzlich --fewshot_as_multiturn, wodurch Few-Shot-Beispiele als separate Chat-Turns statt als ein langer Prompt-Block übergeben werden, was näher an der echten Nutzung liegt.

Schritt 9: Schnellere Inferenz mit vLLM-Backend

Sobald du größere Modelle (13B aufwärts) oder mehrere Tasks gleichzeitig testest, wird das local-completions-Backend über Ollama spürbar langsam, weil es Anfragen sequenziell abarbeitet. vLLM bringt Batch-Inferenz und PagedAttention mit, was Durchläufe deutlich beschleunigt, besonders bei großen Task-Suiten mit tausenden Beispielen.

# Schritt 9: vLLM als Backend nutzen statt Ollama
pip install vllm

lm_eval --model vllm \
  --model_args pretrained=meta-llama/Llama-3.1-8B-Instruct,tensor_parallel_size=1,dtype=bfloat16,gpu_memory_utilization=0.85 \
  --tasks mmlu,gsm8k \
  --batch_size auto \
  --output_path ./ergebnisse/llama31-8b-vllm

Der Parameter gpu_memory_utilization=0.85 reserviert 85 Prozent des verfügbaren VRAM für vLLM, ein guter Standardwert, der genug Puffer für das Betriebssystem lässt. Bei Out-of-Memory-Fehlern (dazu mehr im Troubleshooting-Abschnitt) senkst du diesen Wert schrittweise, etwa auf 0.7.

Schritt 10: LiveBench für kontaminationsfreie Tests einrichten

MMLU, GSM8K und Co. existieren seit Jahren öffentlich im Netz. Die Wahrscheinlichkeit, dass Trainingsdaten aktueller Modelle diese Fragen (oder sehr ähnliche) bereits enthalten, ist real, ein Effekt, den Fachleute Benchmark-Kontamination nennen. LiveBench wurde laut dem zugehörigen Forschungspapier explizit entwickelt, um dieses Problem zu umgehen: Die Aufgaben stammen aus aktuellen Mathe-Wettbewerben, frischen arXiv-Papern, Nachrichtenartikeln und Datensätzen und werden monatlich aktualisiert, insgesamt 18 Aufgaben über sechs Kategorien (Mathematik, Programmierung, logisches Denken, Sprachverständnis, Befolgen von Anweisungen und Datenanalyse).

# Schritt 10: LiveBench-Repository klonen und einrichten
git clone https://github.com/LiveBench/LiveBench.git
cd LiveBench
pip install -e .

# Beispielhafter Aufruf gegen ein lokal laufendes Modell
python run_livebench.py \
  --model llama3.1:8b \
  --bench-name live_bench \
  --api-base http://localhost:11434/v1

Anders als lm-evaluation-harness bewertet LiveBench die Antworten automatisch anhand objektiver Musterlösungen statt über Multiple-Choice-Wahrscheinlichkeiten, was näher an echter Nutzung liegt, aber auch mehr Rechenzeit pro Beispiel kostet. Für einen ersten Eindruck reicht es, eine einzelne Kategorie zu testen, etwa nur math oder coding, statt der vollen Suite.

Schritt 11 und 12: Ergebnisse auswerten und vergleichen

Jeder Durchlauf von lm-evaluation-harness legt eine results.json-Datei im angegebenen Output-Pfad ab. Diese Datei enthält neben den reinen Scores auch Metadaten wie die genaue Task-Version, die Anzahl der Few-Shot-Beispiele und Konfigurationshashes, wichtig, um Läufe später eindeutig reproduzieren zu können.

{
  "results": {
    "mmlu": {
      "acc,none": 0.583,
      "acc_stderr,none": 0.004
    },
    "gsm8k": {
      "exact_match,strict-match": 0.62,
      "exact_match_stderr,strict-match": 0.014
    }
  },
  "config": {
    "model": "local-completions",
    "num_fewshot": 5,
    "batch_size": "auto"
  },
  "git_hash": "a1b2c3d",
  "date": "2026-08-25"
}

Um zwei oder mehr Modelle sauber zu vergleichen, lohnt sich ein kleines Python-Skript, das mehrere results.json-Dateien einliest und in einer Tabelle gegenüberstellt, statt manuell zwischen Ordnern hin- und herzuspringen:

import json
from pathlib import Path

def lade_ergebnis(pfad):
    with open(Path(pfad) / "results.json") as f:
        return json.load(f)["results"]

modelle = {
    "Modell A": lade_ergebnis("./ergebnisse/modell-a"),
    "Modell B": lade_ergebnis("./ergebnisse/modell-b"),
}

for task in ["mmlu", "gsm8k"]:
    zeile = [task]
    for name, ergebnis in modelle.items():
        metrik = next(iter(ergebnis.get(task, {}).items()), ("n/a", 0))
        zeile.append(f"{name}: {metrik[1]:.3f}")
    print(" | ".join(zeile))

Komplettes Beispielprojekt: Zwei Modelle im direkten Vergleich

Um alles bisher Gelernte zusammenzuführen, folgt hier ein vollständiges, lauffähiges Setup, das zwei lokal laufende Modelle gegen dieselbe Task-Suite testet und die Ergebnisse automatisch gegenüberstellt. Dieses Projekt eignet sich als Ausgangspunkt für dein eigenes, wiederkehrendes Benchmark-Setup, etwa als Teil einer CI-Pipeline vor jedem Modell-Update.

Projektstruktur anlegen

mkdir llm-vergleich && cd llm-vergleich
python3 -m venv venv && source venv/bin/activate
pip install lm-eval[hf] vllm

mkdir ergebnisse
touch vergleich.sh auswertung.py

Beide Modelle nacheinander testen

#!/bin/bash
# vergleich.sh - testet zwei Modelle gegen dieselbe Task-Suite
set -e

TASKS="mmlu,gsm8k,hellaswag,arc_easy"

echo "Teste Modell A..."
lm_eval --model local-completions \
  --model_args model=llama3.1:8b,base_url=http://localhost:11434/v1/completions \
  --tasks $TASKS \
  --num_fewshot 5 \
  --apply_chat_template \
  --output_path ./ergebnisse/modell-a

echo "Teste Modell B..."
lm_eval --model local-completions \
  --model_args model=mistral:7b,base_url=http://localhost:11434/v1/completions \
  --tasks $TASKS \
  --num_fewshot 5 \
  --apply_chat_template \
  --output_path ./ergebnisse/modell-b

echo "Fertig. Ergebnisse liegen in ./ergebnisse/"
python3 auswertung.py

Mit chmod +x vergleich.sh && ./vergleich.sh läuft das komplette Setup in einem Rutsch durch, inklusive automatischer Auswertung über das oben gezeigte auswertung.py-Skript. Für einen produktiven Einsatz solltest du das Skript um Logging und Fehlerbehandlung erweitern, gerade weil einzelne Task-Durchläufe bei größeren Suiten mehrere Stunden dauern können.

Benchmark-SuiteFokusAktualisierungszyklusBewertungsmethode
lm-evaluation-harnessAkademische Standardtasks (MMLU, GSM8K, HellaSwag)Statisch, versioniertMultiple-Choice-Wahrscheinlichkeit / Exact Match
LiveBench18 Tasks über 6 Kategorien, kontaminationsfreiMonatlichAutomatische Bewertung gegen Musterlösung
EuroEvalMehrsprachige Evaluation, 10+ SprachenLaufend gepflegtGold-Standard-Datensätze

Statistische Signifikanz: Wie viele Beispiele du wirklich brauchst

Ein Score allein sagt wenig, wenn du den Standardfehler ignorierst. In der oben gezeigten Beispielausgabe stand neben dem exact_match-Wert immer auch ein Stderr, der Standardfehler der Schätzung. Liegen zwei Modelle mit 0,62 und 0,64 exact_match bei einem Stderr von jeweils 0,014 auseinander, überlappen sich ihre Konfidenzintervalle fast vollständig, der Unterschied ist statistisch kaum aussagekräftig. Erst wenn die Differenz deutlich größer ist als die Summe der Standardfehler, lässt sich von einem echten Unterschied sprechen.

Das hat direkte Konsequenzen für deine Stichprobengröße. Ein Task mit nur 50 Beispielen produziert einen entsprechend großen Standardfehler, kleine, aber reale Unterschiede zwischen zwei Modellen verschwinden dann im Rauschen. GSM8K etwa umfasst im vollen Testset 1.319 Beispiele, ein Wert, der in der Praxis stabile, gut reproduzierbare Scores liefert. Wenn du aus Zeitgründen mit --limit arbeitest, dokumentiere immer, wie viele Beispiele tatsächlich getestet wurden, ein Vergleich zwischen einem 1.319er-Lauf und einem 50er-Lauf ist irreführend, selbst wenn beide denselben Task-Namen tragen.

Eine einfache Faustregel für den Alltag: Nutze --limit ausschließlich, um zu prüfen, ob dein Setup technisch funktioniert, niemals, um am Ende eine Vergleichszahl zu veröffentlichen. Für echte Entscheidungen, etwa welches Modell dein Team produktiv einsetzt, lohnt sich immer der volle Task-Datensatz, auch wenn das mehr Rechenzeit kostet.

Europäische und deutschsprachige Alternativen zum alten HF-Leaderboard

Nach der Einstellung der Hugging Face Open LLM Leaderboard 2025 verweist die offizielle Diskussion auf dem entsprechenden Hugging-Face-Space explizit auf EuroEval als Alternative, ein Projekt, das laut der Diskussion „seit drei Jahren besteht und aktuell zehn Sprachen mit größtenteils Gold-Standard-Datensätzen abdeckt". Für DACH-Teams, die Wert auf mehrsprachige oder europäische Evaluation legen, ist das der naheliegendste Startpunkt, auch wenn nicht jede Detailkonfiguration für deutschsprachige Spezialaufgaben öffentlich dokumentiert ist. Ergänzend verweist Hugging Face auf einen Community-Suchbereich namens OpenEvals, über den sich weitere, von der Community gepflegte Leaderboards finden lassen, statt eines einzelnen zentralen Nachfolgers.

Praktisch bedeutet das für dein eigenes Setup: Verlasse dich nicht auf eine einzelne externe Rangliste, sondern kombiniere öffentliche Referenzwerte (soweit vorhanden) mit deinen eigenen, reproduzierbaren Läufen. Wenn du speziell deutschsprachige Aufgaben testen willst, für die es aktuell keine etablierte, breit zitierte Standard-Suite gibt, kannst du eigene Tasks in lm-evaluation-harness definieren (siehe nächster Abschnitt zu den Stolperfallen) und eigene deutschsprachige Testsätze einspeisen, etwa aus internen Support-Tickets oder Fachtexten deiner Branche.

Wichtig ist dabei die Reihenfolge: Zuerst die etablierten, breit anerkannten Suiten laufen lassen, um eine Grundlinie zu haben, die sich mit anderen Teams vergleichen lässt, danach die eigene, spezifische Suite ergänzen. Wer nur eigene Tasks nutzt, verliert die Vergleichbarkeit mit der breiteren Community, wer sich nur auf generische Tasks verlässt, testet am eigenen Einsatzzweck vorbei. Die Kombination aus beidem liefert das vollständigste Bild und lässt sich später auch gegenüber Kolleginnen und Kollegen leichter begründen, die mit den Rohzahlen allein wenig anfangen können.

Quantisierungsformate im Benchmark-Kontext: GGUF, AWQ und GPTQ

Die Wahl des Quantisierungsformats beeinflusst nicht nur, wie viel VRAM ein Modell braucht, sondern auch, wie sich das Modell in deinem Benchmark schlägt, und das ist einer der am meisten unterschätzten Faktoren beim Modellvergleich. GGUF, ursprünglich für llama.cpp entwickelt, ist inzwischen das gängigste Format für CPU- und Consumer-GPU-Inferenz über Ollama und LM Studio. AWQ (Activation-aware Weight Quantization) und GPTQ verfolgen einen anderen Ansatz und zielen auf möglichst geringen Qualitätsverlust bei aggressiver Kompression, meist im Zusammenspiel mit vLLM oder ähnlichen Inferenz-Servern.

Für dein Benchmark-Setup bedeutet das: Ein Vergleich zwischen einem Modell in GGUF Q4_K_M und einem zweiten Modell in AWQ 4-Bit ist kein sauberer Test der Modellarchitektur, sondern vermischt zwei unterschiedliche Kompressionsverfahren mit jeweils eigenen Kompromissen. Wenn möglich, halte das Quantisierungsformat über alle getesteten Modelle hinweg identisch, oder dokumentiere die Unterschiede explizit in deiner Ergebnistabelle. Bei besonders kritischen Vergleichen, etwa wenn du dich zwischen zwei Modellen für den Produktiveinsatz entscheiden musst, lohnt sich zusätzlich ein Testlauf in voller Präzision (FP16 oder BF16) auf einer stärkeren GPU oder einer Cloud-Instanz, um zu prüfen, ob die Quantisierung selbst einen Teil der beobachteten Unterschiede verursacht.

lm-evaluation-harness unterstützt alle drei Formate über die jeweiligen Backend-Bibliotheken. Für GGUF-Modelle über Ollama nutzt du wie gezeigt das local-completions-Backend, für AWQ- oder GPTQ-quantisierte Hugging-Face-Modelle reicht meist ein zusätzliches quantization_config-Argument im --model_args-Parameter des hf-Backends.

Reproduzierbarkeit sichern: Versionen, Seeds und Snapshots

Ein Benchmark, der sich nicht reproduzieren lässt, ist am Ende nur eine Momentaufnahme ohne Beweiskraft. Drei Dinge solltest du deshalb bei jedem Lauf konsequent festhalten: die exakte Modellversion (inklusive Quantisierungsstufe und Commit-Hash, falls du ein Hugging-Face-Modell direkt referenzierst), die lm-evaluation-harness-Version, mit der getestet wurde, und die verwendete Hardware-Konfiguration. Die results.json-Datei liefert dafür bereits einen guten Teil der Metadaten automatisch mit, ergänze sie aber um eigene Notizen, etwa in einer begleitenden README-Datei pro Lauf.

# Metadaten für Reproduzierbarkeit festhalten
lm_eval --version > ./ergebnisse/modell-a/tool_version.txt
pip freeze > ./ergebnisse/modell-a/requirements_snapshot.txt
nvidia-smi --query-gpu=name,driver_version,memory.total --format=csv > ./ergebnisse/modell-a/gpu_info.txt
date -u +"%Y-%m-%dT%H:%M:%SZ" > ./ergebnisse/modell-a/timestamp.txt

Setze außerdem, wo immer möglich, einen festen Seed und eine Temperature von 0 für deterministische Aufgaben wie GSM8K oder MMLU. Bei generativen Tasks mit freierem Antwortformat (etwa LiveBench-Kategorien) lässt sich völlige Determinismus zwar selten vollständig garantieren, insbesondere bei Batch-Inferenz über vLLM, aber ein fixer Seed reduziert die Schwankungsbreite zwischen wiederholten Läufen spürbar. Wer diese drei Punkte, Versionierung, Hardware-Dokumentation und Seed-Kontrolle, von Anfang an konsequent umsetzt, erspart sich Monate später stundenlanges Rätselraten, warum ein alter Wert plötzlich nicht mehr nachvollziehbar ist.

Häufige Stolperfallen beim Selbst-Benchmarking

Wer zum ersten Mal eigene LLM-Benchmarks fährt, tappt fast immer in dieselben Fallen. Die folgende Liste spart dir Stunden an Debugging-Zeit.

  • Chat-Template vergessen: Instruct-Modelle ohne --apply_chat_template zu testen drückt die Scores künstlich nach unten, weil das Modell nicht im trainierten Format angesprochen wird.
  • Zu kleine Stichprobe für Marketingzwecke: Ein Lauf mit --limit 20 liefert extrem verrauschte Werte, die für interne Debugging-Zwecke okay sind, aber niemals als belastbares Ergebnis kommuniziert werden sollten.
  • Quantisierung ignorieren: Ein Modell in 4-Bit-Quantisierung schneidet bei manchen Tasks messbar schlechter ab als die volle Präzision. Wenn du Modelle vergleichst, achte darauf, dass beide in derselben Quantisierungsstufe laufen.
  • Few-Shot-Zahl inkonsistent lassen: Ein Vergleich zwischen einem 0-Shot- und einem 5-Shot-Lauf ist kein fairer Vergleich, auch wenn beide Zahlen aus demselben Tool stammen.
  • Batch-Size zu hoch für den verfügbaren VRAM: Führt meist nicht sofort zum Absturz, sondern zu schleichend falschen oder abgeschnittenen Antworten, bevor der Out-of-Memory-Fehler überhaupt auftritt.
  • Task-Version nicht dokumentiert: Task-Definitionen in lm-evaluation-harness ändern sich zwischen Releases gelegentlich. Ohne den git_hash aus der results.json zu speichern, lässt sich ein alter Lauf später nicht mehr exakt reproduzieren.

Troubleshooting: Die häufigsten Probleme und ihre Lösungen

Auch mit sauberer Installation läuft nicht jeder Durchlauf beim ersten Versuch durch. Die meisten Probleme lassen sich in wenigen Minuten beheben, sobald du weißt, wo du suchen musst. Diese acht Probleme tauchen in der Praxis am häufigsten auf, gesammelt aus typischen Fehlermeldungen und ihren jeweiligen Ursachen.

  • CUDA out of memory: Senke --batch_size auf einen festen kleinen Wert (z. B. 4 statt auto) oder reduziere bei vLLM gpu_memory_utilization schrittweise.
  • „Task not found"-Fehler: Prüfe die exakte Schreibweise mit lm-eval ls tasks | grep , Task-Namen ändern sich gelegentlich zwischen Major-Releases.
  • Verbindung zu Ollama schlägt fehl: Stelle sicher, dass ollama serve tatsächlich läuft und der Port 11434 nicht von einer Firewall blockiert wird, ein curl http://localhost:11434/api/tags sollte eine JSON-Antwort liefern.
  • Ergebnisse wirken unplausibel niedrig: Fast immer fehlt --apply_chat_template bei einem Instruct-Modell, siehe Stolperfalle oben.
  • Sehr lange Laufzeit ohne Fortschrittsanzeige: Manche Tasks wie volle MMLU-Läufe umfassen tausende Beispiele. Nutze --limit für einen schnellen Testlauf, bevor du den vollen Durchlauf über Nacht laufen lässt.
  • HF Token-Fehler beim Laden gated Modelle: Führe huggingface-cli login aus oder setze HF_TOKEN als Umgebungsvariable, bevor du den Befehl startest.
  • Inkonsistente Ergebnisse zwischen zwei Läufen desselben Modells: Prüfe, ob Sampling-Parameter wie Temperature zwischen den Läufen gleich gesetzt sind, für reproduzierbare Benchmarks empfiehlt sich Temperature 0 oder ein fixer Seed.
  • LiveBench-Skript bricht mit Timeout ab: Reduziere die getestete Kategorie auf eine einzelne (z. B. nur math) statt der vollen Suite, gerade bei langsamer lokaler Inferenz ohne vLLM.

Fortgeschrittene Tipps für dein Benchmark-Setup

Sobald das Grundsetup läuft, lohnen sich ein paar Optimierungen, die den Unterschied zwischen einem einmaligen Test und einem wiederholbaren Prozess ausmachen. Richte den Benchmark als Teil eines Cronjobs oder einer CI-Pipeline ein, die automatisch läuft, sobald du ein neues Modell in dein lokales Repository ziehst, so bekommst du sofort mit, wenn ein Update die Qualität für deinen Use Case verschlechtert statt verbessert.

Definiere außerdem eigene Custom-Tasks für Aufgaben, die näher an deinem tatsächlichen Produkteinsatz liegen, als es MMLU oder GSM8K je könnten. lm-evaluation-harness erlaubt das über YAML-Konfigurationsdateien, in denen du eigene Prompts, Antwortformate und Bewertungsmetriken definierst, ohne den Python-Kern des Tools anfassen zu müssen. Ein einfaches Beispiel für eine eigene Task-Definition:

# custom_task.yaml - eigener Task für deutschsprachige Support-Antworten
task: eigener_support_task
dataset_path: json
dataset_kwargs:
  data_files: ./daten/support_beispiele.jsonl
output_type: generate_until
doc_to_text: "Frage: {{frage}}\nAntwort:"
doc_to_target: "{{erwartete_antwort}}"
metric_list:
  - metric: exact_match
    aggregation: mean
    higher_is_better: true

Speichere jeden Lauf mit einem eindeutigen Zeitstempel im Output-Pfad statt Ergebnisse zu überschreiben, das erlaubt dir später eine Trendlinie über mehrere Modellversionen hinweg zu ziehen. Und dokumentiere immer, welche Hardware, welche Quantisierungsstufe und welche lm-evaluation-harness-Version für einen Lauf verwendet wurden, gerade Teams, die regelmäßig zwischen Modellversionen wechseln, verlieren sonst schnell den Überblick, welcher Wert unter welchen Bedingungen entstanden ist.

Ein weiterer Tipp aus der Praxis: Baue dir früh eine kleine, eigene Referenz-Suite aus 20 bis 30 Beispielen, die genau die Aufgaben abbilden, für die dein Team das Modell tatsächlich einsetzen will, etwa typische Support-Anfragen oder Code-Reviews aus eurem eigenen Repository. Diese Suite ersetzt nicht die etablierten akademischen Tasks, ergänzt sie aber um einen Praxis-Check, der näher an deinem echten Einsatzszenario liegt als jeder generische Benchmark. Kombiniert mit den YAML-Custom-Tasks aus dem vorherigen Abschnitt lässt sich diese Suite direkt in denselben Testlauf integrieren und liefert dir bei jedem Modellwechsel sofort eine Einschätzung, ob die Änderung für deinen konkreten Anwendungsfall tatsächlich ein Fortschritt ist.

Benchmark-Läufe mit CI/CD automatisieren

Ein manuell gestarteter Benchmark ist ein guter Anfang, wird aber schnell zur lästigen Pflicht, wenn du mehrmals pro Monat neue Modellversionen testen willst. Sinnvoller ist es, den Vergleich als automatisierten Schritt in deine bestehende Pipeline einzubauen, etwa als GitHub-Actions-Workflow, der bei jedem neuen Modell-Tag automatisch anspringt und die Ergebnisse als Artefakt ablegt.

# .github/workflows/llm-benchmark.yml
name: LLM Benchmark
on:
  workflow_dispatch:
  push:
    tags:
      - 'modell-v*'

jobs:
  benchmark:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - name: Python-Umgebung einrichten
        run: |
          python3 -m venv venv
          source venv/bin/activate
          pip install lm-eval[hf]
      - name: Benchmark ausführen
        run: |
          source venv/bin/activate
          lm_eval --model hf \
            --model_args pretrained=./modelle/aktuell,dtype=bfloat16 \
            --tasks mmlu,gsm8k,hellaswag \
            --apply_chat_template \
            --output_path ./ergebnisse/ci-lauf
      - name: Ergebnisse als Artefakt hochladen
        uses: actions/upload-artifact@v4
        with:
          name: benchmark-ergebnisse
          path: ./ergebnisse/ci-lauf

Der self-hosted-Runner ist hier bewusst gewählt: GPU-Inferenz auf gehosteten GitHub-Runnern ohne eigene Grafikkarte ist entweder gar nicht möglich oder unwirtschaftlich langsam. Wenn dein Team keinen eigenen Runner mit GPU betreiben will, lässt sich derselbe Workflow genauso als Cronjob auf einer eigenen Maschine realisieren, der die Ergebnisse anschließend in ein gemeinsames Dashboard oder eine einfache CSV-Historie schreibt. Wichtig ist weniger das konkrete Tool als die Konsequenz: Jede neue Modellversion sollte denselben Testlauf durchlaufen, bevor sie produktiv geht.

Kosten und Zeitaufwand realistisch einschätzen

Ein legitimer Vorteil des selbst gehosteten Benchmarks: Es fallen keine API-Kosten an, solange du ausschließlich lokale Modelle testest. Der eigentliche Preis ist Zeit und Strom. Ein vollständiger MMLU-Durchlauf mit allen 57 Fachbereichen gegen ein 7B-Modell auf einer Consumer-GPU dauert, wie oben erwähnt, meist 10 bis 20 Minuten, eine komplette Suite aus vier bis fünf Tasks entsprechend eine bis zwei Stunden. Willst du zusätzlich API-Modelle wie GPT-5.x oder Claude-Modelle in denselben Vergleich einbeziehen, fallen dafür die üblichen Token-Kosten des jeweiligen Anbieters an, lm-evaluation-harness unterstützt das über das local-chat-completions- beziehungsweise API-spezifische Modelltypen, sodass sich lokale und Cloud-Modelle in derselben Ergebnistabelle gegenüberstellen lassen.

Wer regelmäßig benchmarkt, sollte außerdem den Stromverbrauch nicht unterschätzen. Eine GPU, die stundenlang unter Volllast Inferenz fährt, schlägt sich messbar auf der Stromrechnung nieder, besonders bei mehreren vollständigen Task-Suiten pro Woche. Für gelegentliche Vergleiche reicht in der Regel ein einzelner Durchlauf pro neuem Modell-Release, ein tägliches Voll-Benchmarking lohnt sich nur für Teams, die aktiv an eigenen Fine-Tunes arbeiten und jede Trainingsiteration überwachen wollen.

Ein oft übersehener Kostenfaktor ist die Speicherung. Wer mehrere Modellversionen parallel vorhält, um sie im direkten Vergleich zu testen, braucht entsprechend Plattenplatz, ein einzelnes 8B-Modell in FP16 belegt schnell 16 GB, in mehreren Quantisierungsstufen kommen so über mehrere Modelle hinweg leicht mehrere Hundert Gigabyte zusammen. Räume nicht mehr benötigte Modellversionen konsequent auf, oder arbeite mit einem zentralen Modell-Cache (etwa dem Standard-Cache-Verzeichnis von Hugging Face oder Ollama), den sich mehrere Projekte auf derselben Maschine teilen, statt für jedes Projekt eine eigene Kopie vorzuhalten.

Häufig gestellte Fragen

Brauche ich zwingend eine GPU, um LLMs selbst zu benchmarken?

Nein, lm-evaluation-harness funktioniert auch auf der CPU, allerdings deutlich langsamer. Für kleine 7B-Modelle in 4-Bit-Quantisierung und kurze Testläufe mit --limit ist ein moderner Mehrkern-Prozessor ausreichend, für vollständige Task-Suiten gegen größere Modelle lohnt sich eine GPU spürbar.

Welche Aufgaben eignen sich am besten als Einstieg?

MMLU für allgemeines Wissen, GSM8K für mathematisches Denken und HellaSwag für Alltagslogik sind die drei am häufigsten zitierten Standardtasks und ein guter Startpunkt, weil sie in lm-evaluation-harness bereits vorkonfiguriert sind.

Warum weichen meine Ergebnisse von öffentlich kursierenden Zahlen ab?

Kleine Abweichungen sind normal und entstehen durch unterschiedliche Quantisierung, Few-Shot-Zahl, Prompt-Formatierung oder Task-Version. Größere Abweichungen deuten meist auf ein fehlendes Chat-Template oder eine zu kleine Stichprobe hin, siehe den Abschnitt zu den Stolperfallen weiter oben.

Ist LiveBench besser als lm-evaluation-harness?

Die beiden Tools ergänzen sich eher, als dass eines das andere ersetzt. lm-evaluation-harness deckt breite, etablierte akademische Tasks ab, LiveBench liefert dank monatlicher Aktualisierung frischeres, kontaminationsärmeres Material. Für ein vollständiges Bild lohnt sich der Einsatz beider Tools. Wer nur begrenzte Zeit hat, startet mit lm-evaluation-harness und den Standardtasks, ein zusätzlicher LiveBench-Lauf lohnt sich vor allem, sobald du ein Modell für den langfristigen Produktiveinsatz freigeben willst.

Kann ich auch geschlossene API-Modelle in denselben Vergleich einbeziehen?

Ja, lm-evaluation-harness bietet dafür eigene Modelltypen für API-basierte Anbieter, sodass lokale und API-Modelle grundsätzlich in derselben Ergebnisstruktur landen. Beachte dabei die jeweiligen Nutzungsbedingungen und Token-Kosten des Anbieters.

Wie oft sollte ich meinen Benchmark wiederholen?

Ein sinnvoller Rhythmus ist ein Durchlauf pro neuem Modell-Release, das du produktiv einsetzen willst, plus ein gelegentlicher Vergleichslauf, wenn du zwischen Anbietern wechselst. Tägliches Voll-Benchmarking lohnt sich nur, wenn du aktiv an eigenen Fine-Tunes arbeitest.

Was mache ich, wenn ein Task-Name in einer neuen Version nicht mehr existiert?

Task-Namen und Konfigurationen ändern sich gelegentlich zwischen Major-Releases von lm-evaluation-harness. Prüfe mit lm-eval ls tasks, ob sich der Name geändert hat, oder wirf einen Blick in das offizielle GitHub-Repository für die aktuelle Task-Liste.

Lohnt sich der Aufwand auch für ein kleines Team ohne eigene GPU-Infrastruktur?

Ja, gerade weil das Grundsetup mit einer einzelnen Consumer-GPU oder sogar nur der CPU für kleinere Modelle funktioniert. Du musst nicht die volle Suite aus diesem Tutorial umsetzen, um Nutzen daraus zu ziehen, schon ein einzelner MMLU- oder GSM8K-Lauf pro neuem Modell-Kandidaten liefert eine belastbarere Entscheidungsgrundlage als ein Blick auf fremde Marketing-Zahlen.

Quellen und weiterführende Dokumentation: EleutherAI lm-evaluation-harness auf GitHub, LiveBench.ai, LiveBench-Forschungspapier auf arXiv, Hugging Face Dokumentation zum Open LLM Leaderboard und Ollama.com.