Lokale LLM-Benchmarks: Welche Tests für welchen Zweck taugen

Lokale LLM-Benchmarks taugen am meisten als Betriebswerkzeug. Sie sichern eine konkrete Entscheidung ab: Ist dieses Modell auf dieser Hardware schnell genug, zuverlässig genug und kontrollierbar genug für die geplante Aufgabe?

Diese Unterscheidung klingt pedantisch, entscheidet aber über den Nutzen der Messung. Ein lokales Modell kann hohe Tokenraten liefern und trotzdem in Tool-Ketten scheitern. Es kann auf bekannten Wissensaufgaben gut aussehen und in deutscher Fachsprache unpräzise werden. Es kann in einem Chatfenster überzeugend antworten und im Agentenbetrieb JSON falsch formatieren, alte Instruktionen wieder aufnehmen oder einen Tool-Call an der falschen Stelle auslösen.

Der Fehler liegt selten im Benchmark selbst. Er liegt in der falschen Frage. Wer nur wissen will, ob ein vLLM-, Ollama-, LM-Studio- oder llama.cpp-Setup überhaupt sauber läuft, braucht andere Tests als jemand, der ein lokales Modell in Hermes, Open WebUI, AnythingLLM oder eine eigene Tool-Pipeline einbindet. Der sinnvolle Benchmark beginnt daher mit der Entscheidung, die am Ende getroffen werden soll.

Lokale LLM-Benchmarks brauchen drei Ebenen

Die erste Ebene ist Serving-Performance. Hier geht es um Prompt-Processing, Time to First Token, Generierungsgeschwindigkeit, Kontextlänge und Verhalten unter Last. Diese Ebene beantwortet die Betriebsfrage: Trägt die Hardware den geplanten Workload, oder ist das Setup schon vor der Modellqualität zu langsam?

Die zweite Ebene ist Modellkompetenz. Hier geht es um Instruktionsbefolgung, Reasoning, Code, Faktenwissen, Mehrsprachigkeit und bekannte Evaluierungsaufgaben. Diese Ebene beantwortet die Qualitätsfrage: Hat das Modell für die Aufgabe genug Substanz, wenn Geschwindigkeit und Setup bereits passen?

Die dritte Ebene ist Agenten- und Workflow-Verhalten. Hier zählen Tool-Auswahl, strukturierte Ausgabe, mehrstufige Abläufe, Fehlerbehandlung, Abstention und Prompt-Injection-Resistenz. Diese Ebene beantwortet die Produktfrage: Kann das Modell in einem tatsächlichen Arbeitsfluss zuverlässig handeln, oder wirkt es nur im Chat gut?

Ein einzelner Score kann diese drei Ebenen nicht abdecken. Genau deshalb führen lokale Benchmarks so oft in die Irre: Ein Durchsatzwert wird als Qualitätsurteil gelesen, ein Capability-Score als Betriebsgarantie, ein Tool-Score als Sicherheitsnachweis. Alle drei Lesarten sind zu grob.

Der praktische Einstieg ist deshalb einfach: Erst die Ebene wählen, dann das Tool. Für Speed ist ein kleiner Durchsatztest sinnvoll. Für allgemeine Fähigkeit braucht es eine Capability-Suite. Für lokale Agenten braucht es Tool- und Workflow-Tests. Erst die Kombination ergibt ein belastbares Bild.

Für Speed: llama-benchy zuerst, aber nicht zuletzt

Für die erste Ebene ist llama-benchy ein guter Startpunkt. Der Nutzen liegt in der Nüchternheit: Das Tool misst die rohe Serving-Leistung gegen OpenAI-kompatible Endpunkte und macht sichtbar, wie schnell ein Backend bei verschiedenen Generierungslängen arbeitet. Das hilft bei vLLM, SGLang, llama.cpp und ähnlichen Setups, weil die Messung nicht an eine einzelne Engine gebunden ist.

In der Praxis ist dieser Test der erste Rauchmelder nach einem Deployment. Wenn Prompt-Processing, Tokenrate oder Time to First Token deutlich unter Erwartung liegen, lohnt keine grosse Capability-Debatte. Dann ist zuerst der Stack zu prüfen: Rezept, Quantisierung, Batch-Verhalten, Kontextfenster, GPU-Speicher, Container-Parameter oder Backend-Wahl.

Der Punkt ist aber ebenso wichtig: llama-benchy sagt nichts über Tool-Qualität, JSON-Disziplin oder deutsche Fachpräzision. Es misst, ob der Server schnell liefert, nicht ob das Modell in einer Arbeitskette richtig entscheidet. Ein Speed-Test ist daher ein Startsignal, kein Freigabeschein.

Diese Trennung zeigte sich auch in internen lokalen Setups. Speed-Tests lieferten plausible Decode-Werte, während echte Agentenläufe subjektiv deutlich träger wirkten. Der Grund lag weniger in der Messung selbst. Entscheidend war die zusätzliche Kette aus Tool-Schritten, Orchestrierung, API-Roundtrips und Stop-Bedingungen. Der rohe Durchsatz erklärte nur eine Schicht des Systems.

Für Leser, die den Inferenz-Stack selbst einordnen wollen, passt dazu der bestehende AISyndicate-Vergleich zu vLLM, llama.cpp, Ollama und TensorRT-LLM. Dort geht es um die Engine-Entscheidung, hier um die Messlogik danach.

Für Modellqualität: Capability-Suites gezielt einsetzen

Wenn der Endpoint schnell genug läuft, folgt die zweite Ebene: Modellkompetenz. Hier sind lm-evaluation-harness und LightEval die naheliegenden Werkzeuge. Beide helfen, Modelle über definierte Aufgaben zu prüfen, statt nur einzelne Prompts aus dem Bauch heraus zu testen.

Der häufigste Fehler besteht darin, diese Suites als Pflichtmarathon zu behandeln. Für lokale Entscheidungen reicht oft ein gezieltes Subset. Ein Coding-Assistent braucht andere Aufgaben als ein deutschsprachiger Recherchehelfer. Ein RAG-Modell braucht andere Prüfungen als ein Modell, das strukturierte JSON-Ausgaben für Automationen erzeugen soll. Ein vollständiger Benchmarklauf über grosse Task-Sammlungen kann sinnvoll sein, aber er ist selten der erste Schritt.

Capability-Scores sind zudem nur vergleichbar, wenn die Bedingungen sauber dokumentiert sind: Modellvariante, Quantisierung, Backend, Kontextlänge, Chat-Template und Sampling-Parameter. Eine kleine Änderung kann das Ergebnis verschieben. Das gilt besonders bei lokalen Open-Weight-Modellen, weil Modellkarte, Serving-Stack und tatsächliche Prompt-Form oft auseinanderfallen.

LightEval ist für viele neue Setups angenehmer, weil es besser in moderne Hugging-Face-Workflows passt und Fehler auf Sample-Ebene leichter sichtbar macht. lm-evaluation-harness bleibt stark, wenn historische Vergleichbarkeit oder breite Aufgabenabdeckung wichtiger sind. Die Wahl ist weniger eine Glaubensfrage als eine Betriebsfrage: Welche Suite passt zu den Modellen, Daten und Wiederholungen, die tatsächlich geplant sind?

Für lokale Quantisierung kommt ein weiterer Punkt hinzu. FP8, INT4, FP4 oder GGUF-Varianten können ähnliche grobe Scores zeigen und trotzdem andere Fehlerprofile haben. Wer Quantisierung ernsthaft bewertet, sollte mindestens Speed, ein kleines Capability-Set und Tool-Verhalten erneut prüfen. Der AISyndicate-DeepDive zu LLM-Quantisierung und lokaler Inferenz erklärt diese Verschiebung ausführlicher.

Für Agenten: tool-eval-bench als praktischer Verhaltenstest

Die dritte Ebene ist für lokale KI oft die wichtigste, weil viele Setups über Chat hinausgehen. Sobald ein Modell Tools auslöst, Dateien verarbeitet, JSON zurückgibt, RAG-Kontext nutzt oder mehrstufige Aufgaben abarbeitet, reichen Speed und Capability nicht mehr.

Hier ist tool-eval-bench derzeit als früher Praxistest nützlich. Es prüft OpenAI-kompatible Endpunkte auf Tool-Auswahl, mehrstufige Abläufe, strukturierte Ausgabe, Fehlerbehandlung und einzelne Prompt-Injection-Szenarien. Das ist kein Sicherheitsnachweis für produktive Systeme und keine vollständige Capability-Evaluation. Es ist ein Verhaltenstest, der typische Bruchstellen früher sichtbar macht als ein normaler Chat-Smoke.

Der Bedarf dafür ist nicht akademisch. WildToolBench etwa prüft Tool-Use näher an realem Nutzerverhalten: zusammengesetzte Aufgaben, implizite Absichten über mehrere Dialogturns und wechselnde Instruktionen. Für lokale Setups ist das besonders relevant, weil der eigene Serving-Stack zusätzliche Fehlerquellen einführt.

Das ist für lokale Setups entscheidend. Eine interne Suite kann sehr wertvoll sein, aber sie ist schwer extern zu erklären. Ein öffentlicher Testlauf mit dokumentiertem Setup schafft zumindest eine gemeinsame Sprache für erste Tool-Verhaltensvergleiche. Wenn ein Modell in einem Full-Mode- oder Hard-Mode-Lauf gut abschneidet, ist das ein besserer Ausgangspunkt als ein Screenshot aus einer Chatoberfläche. Für formale Vergleichbarkeit gehören jedoch Capability-Suites wie lm-evaluation-harness und Function-Calling-Benchmarks wie BFCL daneben.

Unsere interne Erfahrung zeigt den Nutzen und die Grenze zugleich. In einem dokumentierten Qwen3.6-FP8-Lauf über alle 84 Szenarien des Hard-Mode-Runs erreichte das lokale Setup einen gewichteten Gesamtscore von 91/100. Die interne Punktetabelle weist 153 von 168 möglichen Bewertungspunkten aus; die Hard-Mode-Kategorie selbst lag bei 28 von 30 Punkten. Die mediane Turn-Zeit lag bei rund 1,45 Sekunden. Positiv war nicht nur der Score: Tool-Output-Prompt-Injection wurde ignoriert, ein veralteter Memory-Eintrag wurde gegen das aktuelle Verzeichnis geprüft, und eine verkettete Datei-/Kursabfrage kam als exaktes JSON zurück. Gleichzeitig zeigte ein Cross-Turn-Injection-Fall eine bekannte Schwachstelle: Eine gespeicherte Instruktion aus einem früheren Turn kann den aktuellen Auftrag beeinflussen. Das macht den Lauf nicht unbrauchbar. Es zeigt nur, welche Tool-Klassen Policy-Gates, Rollenprüfung oder menschliche Bestätigung brauchen.

Genau diese Nuance macht den Test wertvoll. Ein guter Tool-Benchmark beruhigt nicht pauschal. Er macht Fehlerklassen sichtbar, die ein normaler Speed-Test verschweigt. Wenn ein Modell bei Tool-Selektion stark ist, aber bei gespeicherten Instruktionen, Seiteneffekten oder Sicherheitsgrenzen schwächelt, gehört diese Information vor jede produktive Einbindung.

BFCL ist als Ergänzung sinnvoll, wenn Function Calling formal eingeordnet werden soll. Für den praktischen lokalen Agentenstart ist tool-eval-bench oft der schnellere Einstieg, weil es unkompliziert gegen eigene OpenAI-kompatible Endpunkte läuft. Es ersetzt BFCL oder Capability-Suites aber nicht, sondern ergänzt sie.

Ein Workflow, der im Alltag trägt

Ein brauchbarer lokaler Benchmarklauf beginnt mit einem Smoke-Test: Endpoint erreichbar, Antwortformat korrekt, Chat-Template sauber, Reasoning-Ausgaben nicht versehentlich im normalen Content. Dieser Schritt klingt banal, verhindert aber viele falsche Benchmarkinterpretationen.

Danach folgt die Speed-Messung. Ein kurzer llama-benchy-Lauf zeigt, ob der Serving-Stack in der richtigen Grössenordnung liegt. Bei grossen Abweichungen wird zuerst die Infrastruktur geprüft, nicht das Modell bewertet.

Erst danach lohnt ein Capability-Sampling. Ein Coding-Assistent braucht andere Aufgaben als ein deutschsprachiger Recherchehelfer; ein RAG-System sollte mindestens eigene Dokumentfragen sehen.

Der vierte Schritt ist der Agententest. Sobald Tools, JSON oder mehrstufige Abläufe im Zielsystem vorkommen, zählt tool-eval-bench oder ein vergleichbarer Tool-Test. Der Gesamtscore hilft, die Fehlerliste hilft mehr. Ein Modell, das selten scheitert, aber bei Side-Effect-Tools falsch eskaliert, ist riskanter als der Score vermuten lässt.

Am Ende steht die manuelle Fehleranalyse. Zehn bis zwanzig Failure-Cases zu lesen bringt mehr als eine weitere Dezimalstelle im Score. Erst dort zeigen sich Muster: falsches Tool, verlorener Kontext, zu viel Gehorsam gegenüber injizierten Instruktionen oder zu wenig Abstention.

Die interne AISyndicate/OpenClaw-v7-Suite folgt genau dieser Logik, ist aber bewusst kein öffentlicher Standard. Sie prüft konkrete Arbeitsfälle aus unserem System: deutsche Fachpräzision, Tool-Verhalten, JSON-Disziplin und lokale Endpoint-Besonderheiten. Das ist intern nützlich, weil öffentliche Benchmarks diese Mischung nicht exakt abbilden. Extern bleibt eine öffentliche Suite die bessere Referenz, weil sie reproduzierbarer und leichter überprüfbar ist.

Welche Empfehlung aus den Tests folgt

Für kleine lokale Setups mit Ollama, LM Studio oder llama.cpp reicht als Einstieg ein dreistufiges Minimum: Endpoint-Smoke, Speed-Test, kleiner Tool- oder JSON-Test. Wer nur gelegentlich chattet, braucht keinen Forschungsbenchmark. Wer lokale Automationen baut, braucht mindestens einen Tool-Test.

Für Workstation- oder lokale Server-Setups ist die Messlatte höher. Dort entstehen schnell falsche Sicherheiten, weil die Hardware stark genug wirkt. Gerade deshalb sollten Speed, Capability und Tool-Verhalten getrennt dokumentiert werden. Ein Modell kann als schneller Chat-Server gut sein, als RAG-Assistent brauchbar und als autonomer Tool-Agent trotzdem ungeeignet.

Für öffentliche Vergleiche sollten interne Scores nur als Erfahrungswert auftauchen. Die Quellenlage und die Methodik müssen unterscheidbar bleiben: öffentliche Benchmark-Suite für externe Diskussion, interne Suite für konkrete Betriebsentscheidungen. Diese Trennung schützt vor Überverkauf und macht die eigenen Ergebnisse glaubwürdiger.

Die wichtigste Folge ist organisatorisch. Wer lokale Modelle ernsthaft betreibt, braucht Benchmark-Pflege als Teil des Betriebs. Modelle wechseln, Quantisierungen ändern sich, Backends werden aktualisiert, Templates verschieben Verhalten. Ohne wiederholbare Tests bleibt jede Verbesserung ein Bauchgefühl.

Lokale LLM-Benchmarks sind dann stark, wenn sie eine Entscheidung vorbereiten. Welches Backend trägt den Workload? Welches Modell kann die Aufgabe? Welche Tool-Fehler sind akzeptabel? Wo braucht es ein Policy-Gate? Wer diese Fragen trennt, bekommt aus Benchmarks ein Instrument. Wer sie vermischt, bekommt eine schöne Zahl und eine falsche Sicherheit.