Mein KI-Agent hat ein Benchmarking-Tool für meine KI-Agenten gebaut

Mein KI-Coding-Agent Hermes hat ein Benchmarking-Tool geschrieben. Es testet Geschwindigkeit, Intelligenz und Agenten-Tauglichkeit meiner lokalen Modelle — derselben Modelle, auf denen andere KI-Agenten laufen — und spuckt JSON und eine Terminal-Tabelle aus. Das Tool umfasst 1.660 Zeilen Python und heißt bench-llm — ein KI-Agent hat ein Benchmarking-Tool für KI-Agenten gebaut.

Was du am Ende hast

Ein Befehl gegen ein Modell liefert diese Form von Ausgabe in deinem Terminal (Beispiel-Lauf):

$ bench-llm gemma-4-31b-it

============================================================
  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Status:   READY
  GGUF Path:     ~/.lmstudio/models/google/gemma-4-31b-it-Q4_K_M.gguf
  GGUF Size:     16.5 GB
  Arch:          gemma4
  Quant:         Q4_K_M
============================================================

  🔥 Warming up model... OK (0.23s TTFT)

  ⚡ SPEED BENCHMARKS
  ----------------------------------------
    short_50 (131 chars, 3 runs)...
      TPS:  mean=84.2 median=83.8
      TTFT: mean=0.231s median=0.228s
    medium_200 (323 chars, 3 runs)...
      TPS:  mean=85.7 median=85.2
      TTFT: mean=0.312s median=0.308s
    long_800 (769 chars, 3 runs)...
      TPS:  mean=82.1 median=81.5
      TTFT: mean=0.541s median=0.537s

  🔍 Validating speed plausibility...
    Confidence: HIGH

  🧠 ABILITY TESTS
  ----------------------------------------
    Running: Code Generation (median_of_list)... PASS
    Running: Logic Puzzle (Pet Ownership)... PASS
    Running: JSON Compliance... PASS
    Running: Instruction Following... PASS
    Running: Summarization (Key Facts)... FAIL

    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
  ----------------------------------------
    Running: Task Acknowledgment... PASS
    Running: Format Adherence... PASS
    Running: Conciseness (Output/Input Ratio)... PASS

    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

================================================================================
  BENCHMARK RESULTS: gemma-4-31b-it
================================================================================

  📊 SUMMARY TABLE
  ──────────────────────────────────────────────────────────────────────
  Model ID                         gemma-4-31b-it
  GGUF Size                        16.5 GB
  Architecture                     gemma4
  Quantization                     Q4_K_M
  T/s (short, mean)                84.2
  TTFT (short, mean)               0.231s
  Ability Score                    4/5 (80.0%)
  Agent Fitness Score              3/3 (100.0%)
  Confidence                       🟢 HIGH
  ──────────────────────────────────────────────────────────────────────

Außerdem schreibt es eine vollständige JSON-Nutzlast nach ~/benchmarks/ — mit jeder Rohmessung, jeder Testantwort und einer strukturierten Zusammenfassung —, damit du die Ergebnisse wieder in deinen Agenten einspeisen und fragen kannst: „Welche meiner Modelle sollten die Massen-JSON-Arbeit übernehmen?"

Was es testet

Drei Dimensionen, jede gewählt, weil sie für einen immer aktiven Agenten-Stack zählt.

⚡ Geschwindigkeit

Drei Prompt-Längen — kurz (~50 Zeichen, „erkläre, was eine Variable ist"), mittel (~200 Zeichen, „erkläre Rekursion") und lang (~800 Zeichen, „vergleiche drei Programmierparadigmen") — mit drei Aufwärmläufen, gefolgt von den echten Messungen.

Was gemessen wird:

• TTFT (Time To First Token) — wie lange, bis das Modell zu tippen beginnt. Entscheidend für die Chat-UX; alles über 500 ms fühlt sich träge an.
• Durchsatz (Tokens/Sek.) — wie schnell es generiert, sobald es läuft. Wichtig für lange Codeblöcke und Berichte.
• Prefill-T/s — wie schnell es den Eingabe-Prompt vor der Generierung verarbeitet. Versteckte, aber reale Kosten.

Es führt auch einen Plausibilitätscheck gegen bekannte Hardware-Grenzen durch. Wenn dein 30-GB-Modell 200 T/s auf einer 7900 XTX behauptet, markiert bench-llm das — diese Zahl ist wahrscheinlich durch spekulatives Decoding oder einen vorgewärmten Cache verfälscht.

🧠 Fähigkeit

Fünf Tests, die für ein kompetentes Modell trivial sind und für ein kämpfendes Modell ein todsicherer Verräter:

• Code-Generierung — Schreibe median_of_list(numbers) mit Randfällen (leere Liste, gerade Länge, ungerade Länge, Eingabe nicht verändern). Die Funktion wird innerhalb von bench-llm gegen sechs Testfälle ausgeführt — kein Pattern-Matching gegen den Antworttext, sondern wirklich laufender Code.
• Logikrätsel — Ein Besitzrätsel mit vier Haustieren (Alice/Fisch, Bob/Vogel, Carol/Katze, Dan/Hund). Ein Regex extrahiert die Antwortzuordnungen aus der Antwort und prüft alle vier.
• JSON-Konformität — „Gib ein JSON-Objekt mit genau diesen Schlüsseln zurück." Testet, ob das Modell auf Abruf gültiges, schema-konformes JSON erzeugen kann — das absolute Minimum für Tool-Calling.
• Instruktionsbefolgung — Schreibe die Zahlen 1–10, markiere gerade Zahlen mit *, summiere sie. Testet präzise Format-Treue: Die Antwort ist trivial, das Format ist der ganze Punkt.
• Zusammenfassung — Ein dichter Absatz über heliumbasierte Quantencomputing. Prüft, ob sechs technische Kernfakten die Kompression überlebt haben. Die meisten Modelle verlieren mindestens eines.

🤖 Agenten-Tauglichkeit

Hier macht bench-llm etwas, das ich in anderen Benchmarking-Tools nicht gesehen habe. Es schickt dem Modell eine echte Agentenaufgabe — syslog nach ERROR-Zeilen durchsuchen, nach Dienst gruppieren, einen JSON-Bericht erstellen — und bewertet die Antwort, wie es ein Agenten-Supervisor täte:

• Aufgabenbestätigung — Versteht das Modell, worum es gebeten wurde? Kann es einen Ansatz skizzieren und Hindernisse benennen? (Ein Modell, das sofort damit beginnt, syslog-Einträge zu halluzinieren, fällt hier durch.)
• Format-Treue — Entspricht die Ausgabe dem geforderten JSON-Schema? Prüft das services-Array, die total_errors-Ganzzahl und den scan_period-String.
• Prägnanz — Wie ist das Ausgabe-zu-Eingabe-Verhältnis? Modelle, die auf einen 1.300-Zeichen-Prompt mit 20.000 Zeichen Geschwafel antworten, werden als VERBOSE markiert. Ein Agent, der nicht prägnant sein kann, verbrennt bei jedem Turn dein Kontextfenster.

Die drei Agenten-Tauglichkeitstests teilen sich denselben Prompt — sie bewerten verschiedene Aspekte derselben Antwort. Das hält den Benchmark schnell und misst trotzdem die Qualitäten, die zählen, wenn ein Modell unbeaufsichtigt läuft.

Wie es gebaut wurde

Hermes — der Coding-Agent auf meiner Maschine — hat das Ganze geschrieben. Ich gab ihm eine grobe Spezifikation: „Ich brauche ein Tool, das lokale Modelle in LM Studio benchmarkt, Geschwindigkeit und Verstand testet und JSON und eine Tabelle ausgibt." Es ging weg, kam mit einem funktionierenden Skript zurück, und wir iterierten.

Der Prozess war:

1. Erster Durchgang: nur Geschwindigkeitstests — Verbindung zur OpenAI-kompatiblen API von LM Studio, Tokens streamen, TTFT und T/s messen.
2. Zweiter Durchgang: Fähigkeitstests — Codierung (mit echter Ausführung), Logikrätsel, JSON-Schema-Konformität, Instruktionsbefolgung, Zusammenfassung.
3. Dritter Durchgang: Agenten-Tauglichkeit — die syslog-Aufgabe, Bewertung der Antwort, als wäre das Modell ein Agent in meinem Stack.
4. Politur-Durchgänge: GGUF-Dateiauflösung (die tatsächliche Modelldatei auf der Platte finden, Größe und Quantisierung melden), Geschwindigkeits-Plausibilitätsprüfung, die Übersichtstabelle, der --quick-Modus, --list zur Modellentdeckung, der Pre-Flight---check-Befehl.

Alle vier Iterationen passierten an einem Nachmittag. Das finale Skript hat 1.660 Zeilen. Jede Zeile wurde von Hermes geschrieben — ich habe reviewt, mit echten Modellen getestet, Probleme gemeldet („dieser Durchsatzwert kann für ein 123B-Modell nicht stimmen"), und es hat sie behoben. Der Plausibilitäts-Validator entstand genau aus dieser Art von Feedback-Schleife.

Design-Entscheidungen, die hielten

• Streaming statt Polling. bench-llm nutzt OpenAI-kompatibles Streaming für Token-genaues Timing. Ein Polling-Ansatz würde die TTFT-Messung verschmieren und die Granularität auf Token-Ebene verlieren.
• Echte Code-Ausführung für den Codierungstest. Es fragt nicht „sieht das wie eine Median-Funktion aus?" — es führt den Code per exec() in einem frischen Namensraum aus und läuft sechs Testfälle; selbstbewusst aussehende Ausgabe, die nicht läuft, fällt durch.
• Regex-basierte Antwort-Extraktion für Logik-/JSON-Tests. Benchmarks, die ein präzises Format verlangen, scheitern hart an Modellen, die vor der eigentlichen Ausgabe „Klar! Hier ist deine Antwort:" einfügen. Die Prüfer von bench-llm extrahieren die Nutzlast aus jedem Wrapper, den das Modell darum legt — sie testen den Inhalt des Modells, nicht seine Geschwätzigkeit.
• VRAM-Bereinigung zwischen Benchmarks. Es führt pkill -f llama-server aus und wartet, bis LM Studio null geladene Modelle anzeigt, bevor es weitermacht. Ohne das kann der KV-Cache eines vorherigen Modells die TTFT-Messung des nächsten Benchmarks verfälschen.
• GGUF-Dateiauflösung. Es mappt die Modell-IDs von LM Studio per Fuzzy-Matching auf Publisher-Name und Architektur zurück auf die echten GGUF-Dateien auf der Platte. Das liefert Modellgröße, Quantisierung und ob die Datei überhaupt existiert — und beantwortet „ist dieses Modell wirklich bereit für den Benchmark?", bevor du einen Lauf verschwendest.

Einrichtung

Drei Schritte:

# 1. Install the two dependencies (requests talks to LM Studio's model-metadata
#    endpoint — without it every model shows as "not found")
pip install openai requests

# 2. Make sure LM Studio is running with at least one model loaded
# (it should be listening on localhost:1234 — that's the default)

# 3. Run it
./bench-llm --list                         # see what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

Keine Konfigurationsdateien, keine API-Schlüssel (LM Studio akzeptiert jeden String), keine Datenbank. Die Ergebnisse landen in ~/benchmarks/.

Optional, aber nützlich: Kopiere bench-llm in deinen PATH, damit du es von überall ausführen kannst.

cp bench-llm ~/bin/
chmod +x ~/bin/bench-llm

Echte Ergebnisse: Basismodelle auf meinem Rig und meinem Laptop

Die Zahlen unten stammen von den Nachfolge-Suiten (gleiche Geschwindigkeitsmethode, breiterer Testsatz) und decken nur Basismodelle ab — keine Community-Fine-Tunes. „Rig" ist eine headless GPU-Box, 2× RTX 5090 + 2× RTX 3090; „APU" ist die integrierte GPU dieses Laptops. Geschwindigkeit ist nur innerhalb eines Geräts vergleichbar. Der eigene Vorbehalt der Suiten gilt: Die Transkripte erstrecken sich über mehrere Revisionen, also lies kleine Abstände als Rauschen.

Geschwindigkeit + Agenten-Tauglichkeit (bench-Suite, Bericht vom 2026-08-18 — Code / Tools / Instruct / Reason sind Bestehensquoten):

Hartes Level (Gauntlet, 2026-08-19 — Bestehensquote über die nur-schweren Fälle; „—" = Kategorie für dieses Modell nicht gelaufen):

Was ich daraus mitnehme: Das MoE Gemma 4 26B (4B aktiv) ist das tägliche Arbeitstier auf dem Rig — 229 T/s, 110 ms TTFT, perfektes Tool-Calling — und seine schwache Spalte ist Instruktionsbefolgung, genau das, worauf sich eine unbeaufsichtigte Agenten-Schleife stützt. Das 4B-Nemotron ist die Überraschung: Auf einer Laptop-APU befolgt es Instruktionen besser als das 26B auf dem Rig, nur fünfmal langsamer (18,5 T/s auf APU vs. 229 auf dem Rig). Auf dem harten Level erreicht das Basis-Qwen3.8 27B 74 % beim Codieren, die 1.5B- und 256M-Zeilen zeigen, wie „zu klein für Agentenarbeit" aussieht, und die Cloud-V4-Flash-Zeile ist die Decke, die die lokalen Modelle jagen — für 0,088 $ für den gesamten harten Lauf.

Was es anders macht

Es gibt jede Menge LLM-Benchmarks. Die meisten sind akademische Rätselsammlungen (MMLU) oder Leaderboard-optimierte Quizfragen. bench-llm tut drei Dinge, die für jemanden zählen, der lokale Modelle tatsächlich betreibt:

1. Es testet Agenten-Qualitäten, nicht Chatbot-Qualitäten. Format-Treue, Aufgabenbestätigung und Prägnanz entscheiden darüber, ob ein Modell in einer unbeaufsichtigten Agenten-Schleife funktioniert oder nicht. Ein Modell, das großartig im Gespräch ist, aber kein JSON-Schema befolgen kann, ist in einem Tool-Calling-Workflow nutzlos.
2. Es validiert seine eigenen Messungen. Der Plausibilitätsprüfer fängt Zahlen ab, die nicht stimmen können — Kontamination durch spekulatives Decoding, vorgewärmte Caches, Messfehler. Wenn ein Benchmarking-Tool dir nicht sagen kann, wann seine eigene Ausgabe Müll ist, kannst du ihm nichts glauben.
3. Es ist ein einziges Skript. Kein Docker, keine Datenbank, keine GPU-Treiber-Abhängigkeiten, kein 50-GB-Dataset-Download. Eine Python-Datei, ein pip install, und es funktioniert mit allem, was du gerade in LM Studio geladen hast.

Stolperfallen

• LM Studio muss zuerst laufen. bench-llm startet LM Studio nicht für dich — es verbindet sich mit localhost:1234. Wenn dort nichts lauscht, schlägt es mit einer klaren Fehlermeldung fehl.
• Die VRAM-Bereinigung ist aggressiv. Es führt zwischen den Benchmarks pkill llama-server aus, um den KV-Cache zu leeren. Wenn du andere llama-server-Prozesse am Leben halten willst, führe bench-llm nicht aus — oder ändere den Bereinigungsschritt.
• Zusammenfassung ist der schwerste Test. Fast jedes Modell, das ich getestet habe, verliert mindestens ein Kernfakt. Wenn ein Modell 4/5 erreicht und die Zusammenfassung die einzige Schwäche ist, ist das ein starkes Ergebnis — lies es nicht als Mangel.
• Denkende Modelle haben langsameren TTFT. Denkmodelle verbringen Zeit in einer Denkphase, bevor sie Ausgabe produzieren. bench-llm misst den TTFT ab dem ersten Token jeder Art — einschließlich Denk-Tokens. Dadurch wirken Denkmodelle langsamer, als sie sich anfühlen, weil die Denk-Tokens während dessen streamen, was sonst tote Luft wäre. Die JSON-Ausgabe trennt den TTFT in ttft_reasoning_s und ttft_content_s, damit du die Aufteilung sehen kannst.
• Der Codierungstest führt die Modellausgabe per exec() aus. Es läuft in einem frischen Namensraum mit reinen Testfunktionen — keine echte Sandbox, also führe es als Benutzer aus, der nichts zu verlieren hat — aber wenn dich der Gedanke, LLM-generierten Code auszuführen, unwohl macht, überspringe die Fähigkeitstests mit --speed-only.
• Viele Modelle brauchen Zeit. Ein vollständiger Benchmark für ein Modell dauert je nach Geschwindigkeit 2–5 Minuten; ein paar Dutzend sind ein Abend. Nutze --quick für Vergleiche und hebe dir die volle Suite für deine Top-Kandidaten auf.

Download

bench-llm ist ein einzelnes Python-Skript plus eine README. Kein Build-Schritt, kein Installationsassistent — entpacken und loslegen.

Das Zip enthält:

• bench-llm — das 1.660-zeilige Benchmarking-Skript
• README.md — kompakte Einrichtungs- und Nutzungsanleitung

Beide Dateien wurden von Hermes geschrieben, meinem Coding-Agenten. MIT-lizenziert — nutze es, verändere es, bring es in deine eigene Toolchain ein. Abhängigkeiten: openai und requests.

Verwandt: Was meine KI-Agenten tatsächlich kosten (warum lokale Geschwindigkeit zählt), Reasonix und DeepSeek Harness (die Coding-Agenten, die diese Modelle antreiben), und der lokale Agenten-Stack, in dem sie laufen.

Downloads

• bench-llm herunterladen (zip) 18 KB

Kostenlos für die private Nutzung. Wenn es dir einen Nachmittag erspart, ist der Kaffee-Button gleich in der Nähe.