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

Am 11. August 2026 bat ich meinen Coding-Agenten um ein Tool, das die lokalen Modelle in meinem Agenten-Stack bewertet. Er lieferte mir daraufhin bench-llm: 1.660 Zeilen Python-Code, die die Geschwindigkeit in LM Studio messen, den von einem Modell generierten Code ausführen und prüfen, ob das Modell eine einfache Agentenaufgabe bewältigen kann. Innerhalb von zwei Wochen erzielten alle Modelle, die mir wichtig waren, eine Bewertung von 5/5 – daher habe ich daraus CrucibleForge entwickelt: 251 Testfälle, davon 158 schwierige; das Ganze ist nun als Open-Source-Projekt auf GitHub verfügbar. Diese Seite beschreibt beides. Nutzen Sie bench-llm, um innerhalb von fünf Minuten erste Messwerte zu erhalten; wenden Sie CrucibleForge an, wenn Sie Modelle bewerten müssen, die alle die einfachen Tests bestanden haben.

Was am Ende herauskommt

Ein einziger Befehl an ein Modell gibt Folgendes aus (Beispielausführung, gekürzt):

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

  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Size:     16.5 GB     Quant: Q4_K_M

  ⚡ SPEED BENCHMARKS
    short_50    TPS: mean=84.2   TTFT: mean=0.231s
    medium_200  TPS: mean=85.7   TTFT: mean=0.312s
    long_800    TPS: mean=82.1   TTFT: mean=0.541s
  🔍 Validating speed plausibility...  Confidence: HIGH

  🧠 ABILITY TESTS
    Code Generation (median_of_list)... PASS
    Logic Puzzle (Pet Ownership)....... PASS
    JSON Compliance.................... PASS
    Instruction Following.............. PASS
    Summarization (Key Facts).......... FAIL
    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
    Task Acknowledgment / Format Adherence / Conciseness: PASS
    Agent Fitness Score: 3/3

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

Die JSON-Datei enthält alle Rohdaten zu den Ausführungszeiten, alle Antworten des Modells sowie eine Zusammenfassung. Sie können diese Datei an Ihren Agenten weitergeben und fragen: „Welches meiner Modelle sollte die Arbeit mit großen JSON-Daten übernehmen?“

Welche Tests führt bench-llm durch?

Geschwindigkeit

Es werden drei Prompt-Längen gesendet (ca. 50, 200 und 800 Zeichen). Anschließend erfolgen Warm-up-Läufe, danach werden drei Werte gemessen. TTFT (Zeit bis zum ersten Token) gibt an, wie lange man warten muss, bis der Text erscheint; Werte über 500 ms wirken im Chat langsam. Durchsatz (Tokens pro Sekunde) zeigt, wie schnell das Modell nach Start schreibt. Prefill T/s gibt an, wie schnell das Modell den eingegebenen Prompt liest.

Zudem wird eine Plausibilitätsprüfung gegen bekannte Hardware-Grenzen durchgeführt. Falls ein 30-GB-Modell angeblich 200 T/s auf einer 7900 XTX erreicht, markiert bench-llm diesen Wert als fragwürdig – vermutlich wurde er durch spekulatives Decodieren oder einen „warmen“ Cache verfälscht.

Fähigkeiten

• Code-Generierung: Es soll median_of_list(numbers) geschrieben werden – inklusive der Randfälle. bench-llm führt die Funktion auf sechs Testfällen aus, anstatt nur den Text zu lesen.
• Logik-Rätsel: Ein Rätsel zur Verteilung von Haustieren unter vier Personen. Der Prüfer extrahiert alle vier Zuweisungen aus der Antwort.
• JSON-Konformität: Es muss ein Objekt mit exakt definierten Schlüsseln zurückgegeben werden – das ist die Mindestvoraussetzung für Tool-Aufrufe durch das Modell.
• Befehlsbefolgung: Die Zahlen 1 bis 10 auflisten, die geraden markieren und addieren. Die Mathematik ist einfach; entscheidend ist lediglich das Format der Ausgabe.
• Zusammenfassung: Ein dichter Text soll zusammengefasst werden – dabei müssen sechs spezifische Fakten erhalten bleiben. Die meisten Modelle vergessen mindestens einen davon.

Eignung als Agent

Das Modell erhält eine realistische Aufgabe: Es soll in den Syslog-Einträgen nach ERROR-Zeilen suchen, diese nach Diensten gruppieren und einen JSON-Bericht zurückgeben. Drei Kriterien bewerten diese Antwort:

• Aufgabenverständnis: Beschreibt das Modell einen Ansatz und nennt auch die eigenen Grenzen? Ein Modell, das sich Syslog-Einträge ausdenkt, scheitert hier.
• Formatkonformität: Enthält die Ausgabe ein services-Array, eine ganzzahlige total_errors-Angabe sowie einen Zeichenstring scan_period?
• Kompaktheit: Das Verhältnis von Ausgabe- zu Eingabelänge. Eine Antwort mit 20.000 Zeichen auf einen 1.300-Zeichen-Prompt wird als „zu ausführlich“ eingestuft – ein solches Modell verbraucht bei jeder Interaktion schnell den Kontextspeicher.

Wie es gebaut wurde

Meine Anweisung an den Codierungsagenten bestand aus einem Satz: „Ich brauche ein Tool, das lokale Modelle in LM Studio bewertet – Geschwindigkeit und Intelligenz geprüft werden; Ergebnisse sollen im JSON-Format sowie als Tabelle ausgegeben werden.“ Der Agent entwickelte das Tool an einem Nachmittag in vier Schritten: Zuerst wurden Geschwindigkeitstests über LM Studio’s OpenAI-kompatible Streaming-API durchgeführt, anschließend folgten Leistungstests. Danach implementierte der Agent die eigentliche Funktionalität – sowie letzte Feinabstimmungen wie das Auffinden der GGUF-Datei auf der Festplatte, Plausibilitätsprüfungen sowie die Unterstützung der Parameter --quick, --list und --check. Der Agent schrieb jede einzelne Zeile Code. Meine Aufgabe bestand darin, das Tool anhand echter Modelle zu testen und Rückmeldungen zu geben. Die Plausibilitätsprüfung wurde eingeführt, weil ich dem Agenten mitteilte, dass eine bestimmte Durchsatzrate für ein 123-Milliarden-Parameter-Modell unmöglich sei.

Design-Entscheidungen, die man gerne in eigene Tools übernehmen sollte:

• Streamen statt Abfragen. Die Zeitmessung pro Token ist der einzige Weg, um einen zuverlässigen TTFT-Wert zu erhalten.
• Den Code ausführen. Code, der zwar überzeugend aussieht, aber nicht läuft, gilt als fehlerhaft – nicht als erfolgreich.
• Die Antwort extrahieren, bevor sie geprüft wird. Die Prüfmechanismen entfernen dabei die vorangestellten Formulierungen wie „Natürlich! Hier ist Ihre Antwort:“. So bewertet der Test den eigentlichen Inhalt – nicht die Einleitung.
• Jeden Durchlauf mit einer leeren GPU starten. Andernfalls würde der Cache des vorherigen Modells den TTFT-Wert verfälschen. Wie bench-llm dies umsetzt, ist das erste „Stolperstein“ bei der Nutzung des Tools.

Einrichtung

# 1. Install both dependencies (requests reads LM Studio's model metadata;
#    without it every model shows as "not found")
pip install openai requests

# 2. Start LM Studio with at least one model; it listens on localhost:1234

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

Es gibt keine Konfigurationsdateien und keine Datenbank. LM Studio akzeptiert jeden beliebigen String als API-Schlüssel. Die Ergebnisse werden in ~/benchmarks/ gespeichert. Wenn Sie das Skript von überall aus ausführen möchten, kopieren Sie es in einen Ordner, der sich in Ihrem PATH befindet.

Fallstricke

• Es beendet llama-server. Um jeden Testlauf sauber zu starten, ruft das Skript pkill -f llama-server auf und wartet, bis LM Studio meldet, dass keine Modelle mehr geladen sind. Dadurch wird auch jeder andere laufende llama-server auf dem System beendet. Führen Sie das Skript nicht auf einem Rechner aus, der noch andere Dienste bereitstellt – oder entfernen Sie diesen Schritt.
• Der Kodierungstest führt den Modellausgabecode mittels exec() aus. Dabei wird ein neuer Namespace verwendet; dies ist jedoch kein Sandbox-Umfeld. Führen Sie den Test daher als Benutzer aus, der nichts zu verlieren hat – oder überspringen Sie die Fähigkeitstests mit --speed-only.
• Reasoning-Modelle wirken langsam. Der Wert TTFT umfasst das erste Token – auch solche, die zum Denkprozess gehören. Im JSON-Output werden diese Werte in ttft_reasoning_s und ttft_content_s aufgeteilt.
• Eine Bewertung von 4/5, wobei nur der Zusammenfassungstest fehlschlägt, ist ein sehr gutes Ergebnis. Fast jedes Modell vergisst mindestens ein Detail.
• Ein vollständiger Testlauf dauert pro Modell 2–5 Minuten. Nutzen Sie --quick, um viele Modelle zu vergleichen; danach können Sie den vollständigen Testlauf nur auf die besten Modelle anwenden.
• LM Studio muss bereits laufen. Das Skript bench-llm verbindet sich mit localhost:1234 und startet nichts selbst.

Ergebnisse: Basis-Modelle auf meinem „Rig“ und dem Mini-PC

Diese Werte stammen aus dem Testpaket, das auf bench-llm folgte (gleiche Messmethode, mehr Tests; Bericht vom 18.08.2026). Das „Rig“ ist ein GPU-System ohne Monitor, ausgestattet mit 2× RTX 5090 und 2× RTX 3090. „APU“ bezeichnet die integrierte GPU des Mini-PCs (als dieser noch einen lokalen Modellserver betrieb). Vergleichen Sie die Geschwindigkeiten bitte nur innerhalb eines einzelnen Geräts. Code, Tools, Instruct sowie Reason geben die Erfolgsraten an.

Das Gemma 4 26B-Modell mit Mixture-of-Experts-Architektur (4 Milliarden aktive Parameter) ist das Allround-Werkzeug auf dem „Rig“: Es erzeugt 229 Tokens pro Sekunde, benötigt lediglich 110 ms für die Ausgabe des ersten Tokens und weist eine perfekte Erfolgsrate beim Aufrufen von Tools auf. Seine Schwäche liegt im Befolgen von Anweisungen – ein Aspekt, auf den ein unüberwachter Agenten-Loop besonders angewiesen ist. Das 4-Milliarden-Parameter starke Nemotron-Modell auf dem Mini-PC folgt Anweisungen besser (94 % gegenüber 50 %). Allerdings ist es etwa zwölfmal langsamer (18,5 vs. 229 Tokens/s) und läuft auf einem anderen Gerät. Wählen Sie das Modell entsprechend der für Ihre Aufgaben relevanten Kriterien – nicht nach der höchsten Geschwindigkeit.

Was es ersetzt hat: CrucibleForge

bench-llm starb an seinem eigenen Erfolg – fünf Testkriterien ergeben zwar ein gutes Bewertungssystem, liefern aber kaum noch aussagekräftige Ergebnisse: Sobald alle Modelle 5/5 bzw. 3/3 Punkte erreichen, hat das Tool nichts mehr zu sagen. CrucibleForge ist die Neuimplementierung. Sie besteht aus rund 9.400 Zeilen Python-Code; ihre Grundregel lautet: Eine schwierige Frage sollte dennoch leicht bewertbar sein.

• 158 schwierige Testfälle. Mathematikaufgaben mit ganzzahligen Ergebnissen, Logikrätsel mit eindeutigen Lösungen sowie Programmieraufgaben, bei denen die Tests eine bestimmte Komplexität erzwingen (z. B. ein Algorithmus mit O(n²)-Komplexität scheitert an der Zeitbegrenzung). Außerdem Fallen beim Tool-Einsatz, Prompt-Injection-Tests, Kontextverarbeitung über 12.000–24.000 Tokens sowie Anweisungen mit mehreren Einschränkungen.
• Code wird durch Ausführung bewertet in einer bwrap-Sandbox ohne Netzwerk, mit schreibgeschütztem System und einer Zeitbegrenzung von 15 Sekunden. Damit ein Programm als „bestanden“ gilt, muss ein bestimmter Erkennungsstring in stdout erscheinen – es kann also nicht einfach mit Exit-Code 0 scheinbar erfolgreich sein. Ohne bwrap (was auf macOS und Windows immer der Fall ist) wird der Code nur ausgeführt, wenn man --allow-unsandboxed angibt.
• Freitextantworten erhalten eine Referenzantwort. Das Judge-Modell sieht die korrekte Antwort und entscheidet lediglich, ob die gegebene Antwort denselben Sinn hat. Jedes kompetente Instruct-Modell kann das leisten – somit ist der Bewertungsprozess nicht mehr ein Schwachpunkt.
• Beliebiges OpenAI-kompatibles API. LM Studio, Ollama, llama.cpp, vLLM, DeepSeek, OpenRouter und viele andere. Gehostete Modelle verarbeiten die Testfälle parallel; dabei werden auch die verbrauchten Token gezählt. API-Schlüssel müssen über Umgebungsvariablen bereitgestellt werden.
• Es holt Antworten zurück, die „denkende“ Modelle verlieren. Ein Reasoning-Modell, das seine gesamte Kapazität für das Nachdenken aufwendet, liefert manchmal eine leere Antwort. CrucibleForge erkennt das, fragt erneut ohne Reasoning ab und zählt solche Fälle. recover führt genau diese fehlerhaften Zeilen aus einem vorherigen Lauf erneut aus.
• Es teilt GPUs respektvoll auf. Auf meinem StudioForge-System reserviert ein Lauf die benötigten Grafikkarten und gibt sie nach Abschluss wieder frei. Im Gegensatz dazu löste bench-llm das Problem durch pkill – wodurch alle Modelle abrupt beendet wurden.
• Eine Web-Oberfläche unter 127.0.0.1:8777 erlaubt das Auswählen von Modellen und Kategorien, das Verfolgen der Logs sowie das Öffnen fehlerhafter Testfälle samt Prompt, Antwort, Reasoning-Informationen und Kommentaren des Judge-Modells. Vor der Nutzung ist ein Token erforderlich; ansonsten hört die Oberfläche nur auf Verbindungen vom lokalen Rechner.

Ausprobieren

git clone https://github.com/LaserLloyd/CrucibleForge.git crucibleforge
cd crucibleforge
uv sync
uv run crucibleforge config --init      # writes models.yaml; add your provider and model
uv run crucibleforge status             # is the provider up? how many cases?
uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge gui                # http://127.0.0.1:8777

Das standard enthält 56 Testfälle, die sich in unter einer Stunde auf einem 27-Milliarden-Parameter-Modell bei etwa 70 Tokens pro Sekunde verarbeiten lassen – inklusive Bewertung. Diesen Lauf kann man problemlos mehrfach ausführen. Zudem ist das Profil in zwei Teile unterteilt: coding enthält keine Judge-Bewertung, während chat die bewerteten Fälle enthält. Weitere Befehle sind run, judge, recover, report, pairwise, models, import-openclaw und cases.

Der Befehl, dem ich am meisten vertraue, prüft die Testfragen selbst: Er führt jede Referenzlösung in der Sandbox aus, berechnet alle mathematischen Ergebnisse erneut durch Brute-Force und baut jeden „langen Kontext“ neu auf. So sieht das Ergebnis vom 16.09.2026 aus:

$ uv run crucibleforge cases verify
251 cases checked, 0 with problems (36 reference solutions executed, 35 answers re-derived)

Der Testsatz (335 Tests) führt dieselbe Prüfung durch – somit kann kein fehlerhafter Testfall unbemerkt alle Modelle durchfallen lassen, insbesondere bei „schwierigen“ Fällen.

Wie ein Bericht aussieht

report erzeugt eine Markdown- sowie eine JSON-Datei. Jedes Modell erhält eine Zusammenfassungszeile sowie pro Kategorie eine Zeile mit den Rohdaten. Hier ist die Kategorien-Zeile für DeepSeek V4 Pro:

| Model        | Coding      | Math        | Tool use    | Instruction  | Reasoning    | Long-context |
| deepseek-pro | 89% (54/61) | 95% (21/22) | 94% (31/33) | 100% (31/31) | 100% (37/37) | 97% (29/30)  |

Jeder Fehler wird samt Grund aufgelistet. Alle sieben Programmierfehler des Modells sehen so aus wie die erste Zeile unten; die zweite Zeile zeigt einen der beiden Fälle, in denen das Modell beim Tool-Einsatz versagte:

- deepseek-pro [coding] CZ01-prime-census: TRUNCATED at 32768 tokens (32768 reasoning tokens); no code in response
- deepseek-pro [tooluse] TZ06-three-parallel-one-turn: 1 calls, expected 3

Das ist der nützliche Teil: Das Modell schrieb keinen schlechten Code – es dachte so lange nach, bis sein 32.768-Token-Budget aufgebraucht war, und schrieb anschließend gar nichts mehr. Ein größeres Budget oder geringerer Reasoning-Aufwand hätten dieses Ergebnis verändert. Allein die Bestehensquote hätte das nicht verraten.

Ergebnisse der schwierigen Testfälle

Dies sind die Ergebnisse der vollständigen Tests: alle 251 Fälle – oder fast alle. Der „Hard %“-Wert gibt die Erfolgsquote bei den schwierigen Testfällen an (154 von 158; die übrigen vier werden separat bewertet). Die Werte für „Code“, „Math“ und „Tools“ zeigen die Erfolgsquoten in den jeweiligen Kategorien. Ich habe die Zeilen der Tests mit nur 56 Fällen weggelassen, da diese nur 38 schwierige Fälle abdecken und daher nicht vergleichbar sind. Ebenso habe ich die Bewertungen zu Rollenspielen sowie Inhalten für Erwachsene aus dem vollständigen Bericht entfernt – sie sind für die Arbeit mit Agenten irrelevant.

Die mit Kleinbuchstaben gekennzeichneten Modelle sind von der Community angepasste oder modifizierte Versionen; sie werden unter ihren jeweiligen Registry-Bezeichnungen aufgeführt. Die nicht markierten Zeilen wurden am 16.09.2026 aus den gespeicherten Testergebnissen neu erstellt. Die Tests umfassen mehrere Revisionen des Testsets – daher sollten Abweichungen von ein oder zwei Prozentpunkten als „Rauschen“ betrachtet werden. ¹ Aus dem Bericht vom 25.08.2026; spätere Tests mit nur 56 Fällen ersetzten die Ergebnisse dieser Modelle. Eine frühere Version dieser Seite wies für V4 Flash einen Wert von 272/308 aus: Dabei wurden zwei vollständige Testläufe unter einem Label zusammengefasst; der oben angegebene Wert von 0,331 bezieht sich auf einen einzelnen Lauf. ² MiniMax M3 ist das gehostete Modell von MiniMax. Ein Fall wurde nicht bewertet; die Kostenangabe ist nur eine Schätzung: Ich nutze ein Flatrate-Abonnement – der Wert basiert auf dem Platzhalter-Satz in meiner Registry-Datei ($0,255/$1,02 pro Million eingegebener bzw. ausgegebener Tokens). Bei MiniMaxs Listenpreis von $0,60/$2,40 wären die Kosten etwa 2,4-mal höher; bei der aktuellen Rabattaktion nur etwa 1,2-mal. ³ Diese Modelle konnten 140 der 154 schwierigen Fälle bewältigen; für die übrigen benötigten sie mehr Kontextinformationen, als ihnen zur Verfügung standen.

Meine Schlussfolgerungen:

• Das gehostete Modell kostet etwa einen Dollar pro Lauf. V4 Pro schaffte 143 von 154 schwierigen Fällen – für nur $1,10. Das ist günstig genug, um das Modell bei Bedarf erneut zu testen, falls lokale Ergebnisse zu gut erscheinen.
• Ein 27-Milliarden-Parameter-Modell auf eigener Hardware kommt nahe ran. Qwen3.8 27B erreichte 135 Punkte – zwei Punkte weniger als V4 Flash – und erzeugt dabei 1,7-mal mehr Tokens pro Sekunde.
• Geschwindigkeit sagt nichts über die Leistungsfähigkeit aus. MiniMax M3 ist mit 212 Tokens/Sekunde das schnellste gehostete Modell – doch erreicht es nur 85% der Punkte; insbesondere im Bereich Mathematik schneidet es schlecht ab (77%). joyfox-35b-rp erzeugt 319 Tokens/Sekunde und erreicht 75%.
• Modifikationen eines Modells können negative Auswirkungen auf dessen Leistung haben. Das modifizierte Qwen3.8 27B erreichte im Bereich „Code“ nur 62% – gegenüber 85% beim Basis-Modell.
• Lange Kontextfenster allein sagen wenig über die Leistungsfähigkeit aus. Die Modelle mit 1,5 Milliarden, 7 Milliarden bzw. 256 Millionen Parametern schaffen immer noch die meisten schwierigen Fälle (83%, 80% bzw. 56%), obwohl ihre Leistung in den Bereichen „Code“ und „Mathematik“ stark nachgelassen hat.

Download

Der Download enthält bench-llm, das ursprüngliche, inzwischen nicht mehr weiterentwickelte Programm – nicht CrucibleForge (das auf GitHub zu finden ist). Die ZIP-Datei enthält zwei Dateien: bench-llm, ein Skript mit 1.660 Zeilen, sowie README.md mit kurzen Einrichtungshinweisen. Es gibt nichts zu kompilieren oder zu installieren – lediglich die Dateien entpacken und ausführen. Beide Dateien wurden vom Agenten erstellt und stehen unter der MIT-Lizenz. Die notwendigen Abhängigkeiten sind openai sowie requests. Lesen Sie die Hinweise vorher, bevor Sie das Programm auf einem Rechner ausführen, der auch andere Dienste bereitstellt.

Verwandte Themen: StudioForge (der GPU-Server, von dem diese Modelle die Grafikkarten mieten), Was meine KI-Agenten tatsächlich kosten (warum lokale Ausführungsgeschwindigkeit wichtig ist), DeepSeek Harness (ein Codierungsagent, der von diesen Modellen unterstützt wird) sowie der lokale Agenten-Stack, in dem sie laufen.

Downloads

• Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

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