Planning Benchmark: Wenn Lokale LLMs zeigen müssen, was sie wirklich drauf haben

Tja... da stehen wir nun. Die Welt schreit nach "Tokens pro Sekunde" (Tok/s), als wäre das die einzige Währung im KI-Casino. Jede Woche poppt ein neues Modell auf, das angeblich 300, 500 oder gar 1000 Tokens pro Sekunde raushaut. Aber mal ehrlich: Was bringt mir ein Modell, das mit 150 Tok/s Müll produziert? Richtig... gar nichts. Außer vielleicht einer schnelleren Erkenntnis, dass das Ergebnis für die Tonne ist. ;)

Transparenz-Check: Dieser Beitrag wurde mit Unterstützung von KI erstellt (Geraffel-Suite!). Der Text wurde von mir persönlich geplant, seziert und auf meinen individuellen Schreibstil getrimmt. Mensch am Steuer, KI als fleißiger Kopilot. Wer tiefer graben will: Die Fußnote am Ende erklärt das Setup. ;)

In den letzten Monaten haben wir eine wahre Schwemme an neuen Modellen erlebt. Llama 3, Qwen 2.5, DeepSeek-V3 – sie alle werben mit Benchmarks, die oft meilenweit von der Realität eines lokalen Setups entfernt sind. Wenn man seine LLMs auf einem privaten Linux-Desktop unter dem Schreibtisch rennen lässt (so wie ich meine dana mit ihrer RTX 3080), dann zählen andere Dinge als in der glitzernden Azure- oder AWS-Cloud. Da geht es um VRAM-Management, Hitzeentwicklung und vor allem: Bekomme ich eine verlässliche Antwort, ohne dass mein System einfriert?

Bisher war mein LLMGui Control Center ja ein ziemlich guter Tacho für lokale LLMs. Wir wussten, wie schnell sie Python-Funktionen tippen oder Bilder beschreiben können. Aber echte Planung? Komplexere Aufgaben, die mehr als nur einen Einzeiler erfordern? Das war bisher eher so ein Bauchgefühl. Zeit, das zu ändern. Zeit für den Planning Benchmark.

Das Lokale Dilemma: Warum wir selbst messen müssen

Die Cloud-Anbieter präsentieren uns immer "perfekte" Bedingungen. Aber wer lokal arbeitet, stößt auf ganz andere Probleme. Wir haben begrenzte Ressourcen. Wir haben keine H100er-Farmen. Wenn ich auf dana ein 14B-Modell starte, dann ist der VRAM zu 70% voll. Da bleibt wenig Platz für Halluzinationen oder ineffizienten Code.

Ein Planning-Benchmark ist hierbei essenziell. Er zeigt uns, ob ein Modell in der Lage ist, mit den Gegebenheiten vor Ort umzugehen. Kann es den lokalen SSH-Pfad korrekt auflösen? Versteht es, dass es keine unendliche Bandbreite hat? Diese Fragen beantwortet kein standardisierter MMLU-Test. Wir brauchen Real-World-Szenarien, die auf unseren eigenen Maschinen laufen.

Warum zur Hölle ein Planning Benchmark?

Geschwindigkeit ist eine feine Sache, keine Frage. Wenn ich ein 70B-Modell quäle, will ich wissen, ob es flüssig läuft. Aber "Planning" ist eine ganz andere Baustelle. Hier geht es um Reasoning, also die Fähigkeit eines Modells, eine komplexe Anforderung in logische Schritte zu zerlegen, bevor es überhaupt die erste Zeile Code tippt.

Die meisten Benchmarks da draußen (HumanEval, MBPP) testen isolierte Funktionen. "Schreibe eine Funktion, die eine Liste sortiert." Toll. Das kann heute jedes 3B-Modell im Schlaf. Aber was ist mit echten Workflows? Wenn ich sage: "Lade dieses Archiv herunter, entpacke es, finde die größte Datei und schlage mir passende Python-Abhängigkeiten vor", dann erweitere ich den Testraum massiv.

In der Realität erleben wir hier oft ein klassisches SNAFU. Da wird versucht, Dateien zu entpacken, bevor sie überhaupt erfolgreich heruntergeladen sind. Oder es werden Bibliotheken importiert, die im Standard-Python gar nicht existieren. Ein Modell, das "plant", sollte erst mal kurz innehalten (auch wenn es nur Millisekunden sind), die Abhängigkeiten sortieren und dann einen sauberen, modularen Workflow implementieren.

Die Benchmark-Aufgabe: Der Python-"Parcours"

Statt simpler Algorithmen muss das LLM jetzt ein komplettes Python-Skript namens test2.py abliefern. Und die Liste der Anforderungen liest sich wie ein Mini-Projekt für einen Junior-Dev. Es geht hier nicht nur darum, Code zu schreiben, sondern eine logische Kette von Operationen abzuarbeiten, die aufeinander aufbauen. Wenn Schritt 1 (Parsing) fehlschlägt, ist der Rest des Skripts Makulatur.

Das Ziel im Detail:

• HTML-Analyse: Das Modell muss eine lokale index.html einlesen und mittels BeautifulSoup oder lxml einen ganz bestimmten Link finden. Hier trennt sich schon die Spreu vom Weizen: Erkennt das Modell das richtige href-Attribut oder halluziniert es irgendwelche Standard-URLs?
• Download & Integrität: Die Datei (ein .tar.zst Archiv) muss "heruntergeladen" werden. Da wir lokal arbeiten, geschieht das über einen eingebetteten Fixture-Server. Danach muss das Modell mittels hashlib den SHA256-Hash berechnen und gegen eine vorgegebene Prüfsumme validieren. Das ist ein klassischer Sicherheits-Check, den KIs gerne mal "vergessen".
• Archiv-Geraffel: Das Entpacken von zstandard-komprimierten Tar-Files ist der Horror-Test für jede KI. Es erfordert die korrekte Kombination aus dem zstandard-Modul und tarfile. Wer hier nicht sauber mit File-Handlern umgeht, erzeugt Speicherlecks oder korrupte Files.
• Daten-Analyse: Das LLM muss durch das entpackte Verzeichnis traversieren (rekursiv!), die größte Datei nach Bytes finden und zusätzlich das File identifizieren, das die meisten Textzeilen enthält. Das erfordert saubere Fehlerbehandlung (was, wenn eine Datei binär ist und beim Zeilen-Zählen kracht?).
• Environment Setup: Zu guter Letzt muss das Modell eine requirements.txt schreiben und ein Python venv initialisieren.

Das erfordert Koordination. Wenn das Modell hier patzt, zeigt uns der Benchmark gnadenlos, wo die Grenzen der aktuellen "Reasoning"-Hypes liegen. Ein Modell kann noch so schnell sein – wenn es am Ende kein funktionierendes Environment aufbaut, ist es für die automatisierte Entwicklung wertlos.

Der Benchmark-Prompt

Für alle, die es ganz genau wissen wollen – das hier ist der exakte "Befehl", den ich den Modellen vor den Latz geknallt habe:

Scoring-Philosophie: Ergebnis zählt

Das Scoring ist Ergebnis-first. Ein schöner Plan, eleganter Code oder perfekte Fehlerbehandlung nützt nichts, wenn am Ende der falsche SHA256, die falsche Datei oder die falsche Zeilenzahl im Output steht. Wir messen hier echten Impact, kein "hätte, hätte, Lieferkette". ;)

Gewichtung (6-dim, wenn Ausführung + Correctness verfügbar):

Fallback-Gewichtungen:
- Nur Unit-Tests (kein Correctness-Score): UT 40%, Impl 20%, Adherence 15%, Planning 15%, Quality 10%
- Keine Ausführung (rein heuristisch): Impl 40%, Adherence 30%, Planning 20%, Quality 10%

Correctness-Checks (je 0 oder 1, Summe → 0–10):
- sha256_in_output — korrekter SHA256-Hash im stdout?
- biggest_file_correct — richtiger Dateiname der größten Datei?
- biggest_bytes_correct — korrekte Dateigröße in Bytes?
- most_lines_file_correct — richtiger Dateiname der zeilenreichsten Datei?
- most_lines_count_correct — korrekte Zeilenzahl?

Der AST (Abstract Syntax Tree) Check bleibt natürlich ein wichtiger Teil der Implementation-Dimension. Ich parse den Code tatsächlich als Python-Strukturbaum. Ein Modell, das nur print("Ich prüfe jetzt den Hash") ausgibt, ohne hashlib wirklich zu nutzen, bekommt hier eine glatte Null.

Besonders spannend ist der Quality Score. Auch wenn er nur noch 5% wiegt, bestrafen wir hier weiterhin "Lazy Coding". Wenn ein Modell keinen if __name__ == "__main__": Block nutzt oder Variablen wie a, b, c benennt, sinkt die Punktzahl. Professionalität ist die Basis für Sicherheit.

Der Ausführungsloop: "Versuch macht klug" (bis zu 5-mal)

Lokal laufende Modelle sind manchmal ein bisschen... eigenwillig. Ein kleiner Syntaxfehler oder ein importierter Name, der leicht daneben liegt, und das Skript kracht. Aber hey, wir Entwickler fixen unsere Fehler ja auch.

Der LLMGui-Benchmark nutzt daher einen Execution-Loop:
1. Generierung: Das Modell schreibt test2.py.
2. Ausführung: Wir starten das Skript in einer isolierten Sandbox (BM_WORK_DIR).
3. Fehler-Feedback: Wenn es knallt, fangen wir den stderr ein.
4. Auto-Fix: Wir schicken den Fehler plus spezifische "Hints" zurück an das Modell. "Hey, dein tarfile Aufruf braucht den mode='r|'. Fix das!"
5. Wiederholung: Das Ganze machen wir bis zu 5-mal.

Dies simuliert den echten Workflow eines Entwicklers. Wir geben der KI die Chance, aus ihren Fehlern zu lernen. Interessanterweise sehen wir hier oft, dass Modelle beim zweiten Versuch deutlich besseren Code liefern, weil sie durch die Fehlermeldung einen "Reality Check" bekommen haben.

Damit wir nicht unser echtes Internet mit tausenden Requests fluten, habe ich einen lokalen Fixture-Server eingebaut. Ein kleiner eingebetteter Python-HTTP-Server startet auf einem zufälligen Port und serviert die Testdaten. Das sorgt für Reproduzierbarkeit und verhindert, dass Netzwerk-Lags den Benchmark verfälschen.

Ground Truth: Was wir vom Code wirklich erwarten

Wie weiß man, ob der KI-Code wirklich das tut, was er soll? "Looks good to me" reicht nicht – vor allem nicht, wenn wir von automatisierter Planung sprechen. Deswegen gibt es die reference_solution.py. Das ist meine handgeklöppelte "Goldlösung", an der sich jedes Modell messen lassen muss.

Der "Gold-Standard" — Was das Skript leisten MUSS:

Ein erfolgreicher Run bedeutet nicht nur, dass keine Fehlermeldungen kommen. Wir erwarten eine präzise Umsetzung der folgenden Business-Logik:
1. Strikte Validierung: Wenn der SHA256-Hash nicht stimmt, muss das Skript mit einer klaren Fehlermeldung (SystemExit oder raise) abbrechen. Einfach weiterzumachen ist ein massives Sicherheitsrisiko.
2. Streaming-First: Wir erwarten, dass das Modell zstandard und tarfile so kombiniert, dass die Daten gestreamt werden. Wer erst 500 MB in den RAM lädt, bekommt Punktabzug bei der Quality.
3. Rekursive Präzision: Bei der Suche nach der größten Datei muss der gesamte Baum (os.walk oder pathlib.Path.rglob) durchsucht werden. os.listdir() reicht hier nicht, da das Archiv Unterverzeichnisse hat.
4. Robustes Zeilen-Zählen: Beim Zählen der Textzeilen darf das Skript nicht bei der ersten Binärdatei (z.B. einem Bild im Archiv) mit einem UnicodeDecodeError abschmieren. Ein sauberes errors='ignore' oder ein vorheriger Check auf Text-Content ist Pflicht.
5. Venv-Autarkie: Das erzeugte venv muss die korrekte Python-Version nutzen und darf keine globalen Pakete verwenden (--without-site-packages).

Die automatisierten Tests in benchmark/test_generated.py nutzen pytest und prüfen diese Kriterien gnadenlos ab:
- Hash-Validität: Stimmt der berechnete SHA256? (Wird über BM_SHA256 an den Test übergeben).
- Größte Datei: Wurde wirklich das richtige File (vex_data_final.bin) gefunden?
- Zeilen-Zähler: Stimmt die Anzahl der Textzeilen (Erwartet: 1337 Zeilen in debug.log)?
- Virtualenv: Existiert der Ordner venv und lässt sich das Binary darin ansprechen?

Wenn das LLM also behauptet, alles sei super, aber die requirements.txt leer ist oder der Trash-Output-Pfad nicht stimmt... Tja... Punktabzug. Wir nutzen hier Marker-Dateien wie _EXEC_MARKER, um die Idempotenz zu wahren. Wir installieren die Pakete nur beim ersten Mal, um den Benchmark nicht unnötig in die Länge zu ziehen.

LLM-as-Judge: Die KI als gnadenloser Kritiker

Einige Dinge lassen sich schwer mit Code erfassen. Ist die Logik robust gegen Randfälle? Hier kommt ein zweites Modell ins Spiel, das als Judge fungiert.

Das Judge-Modell bewertet nach einer festen Rubrik:
- Correctness (0-10): Tut der Code funktional das Richtige?
- Completeness (0-10): Wurden wirklich alle Teilaufgaben gelöst?
- Code Quality (0-10): Ist der Code lesbar und sinnvoll strukturiert?
- Robustness (0-10): Gibt es sinnvolle Fehlermeldungen?

Wir nutzen hierbei einen speziellen System-Prompt, der den Judge anweist, besonders kritisch zu sein. Keine Bonus-Punkte für "guten Willen". Wenn der Code zwar funktioniert, aber aussieht wie Kraut und Rüben, gibt es im Bereich Code Quality eben nur eine 3 von 10. Digitaler Darwinismus in Reinform. Wir extrahieren die Scores mittels JSON-Parsing direkt aus dem Output des Judges.

GTK3-UI-Design: Cairo-Magie auf dana

Ich liebe GTK3. Es ist alt, es ist manchmal zickig, aber es ist unglaublich mächtig, wenn man Cairo (die 2D-Grafikbibliothek dahinter) bändigt. Im LLMGui Control Center haben wir jetzt ein richtiges Dashboard für diese Benchmarks gebaut.

Highlights der UI im Detail:

• VRAM-Monitoring: Da mein Rechner dana im Keller steht, muss das Tool die VRAM-Daten remote abgreifen. Ich nutze einen SSH-Hook (ssh -o ConnectTimeout=4 dana nvidia-smi), um die GPU-Last in Echtzeit anzuzeigen. Bei 12 GB VRAM wird es ab 80% Gelb – ein klares Signal, dass man mit dem Kontext sparen sollte. Das Tool erkennt sogar automatisch, ob SSH konfiguriert ist, und nutzt sonst einen Default-Wert von 12 GB (RTX 3080).

• Farbkodierung: Grün heißt: Alles im Lot (≤80%). Gelb heißt: Es wird eng (≤100%). Rot heißt: Wir sind im OOM-Territorium (>100%). Das ist essenziell für lokale Workflows, um Abstürze des gesamten Desktops zu vermeiden.
• ProgressBar & Step-Labels: Man sieht genau den Fortschritt über alle Modelle hinweg. Das Step-Label zeigt sogar an, was gerade passiert ("↳ Generiere Planungsschritte...", "↳ Analysiere AST..."). Der Text im Live-Output hat jetzt Word-Wrap, sodass man auch auf kleinen Fenstern alles lesen kann.

Der interaktive Radar-Chart: Kein Widget-Geraffel nötig

Das visuelle Highlight ist der Radar-Chart. Er zeigt die Scores als Pentagon oder Hexagon. Jedes Modell hat eine eigene Farbe aus der Catppuccin Mocha Palette – weil wir ja auch was fürs Auge wollen. ;)

Das Besondere: Der Chart ist voll interaktiv, aber ohne externe Library!
- Hit-Detection: Klickt man in der Legende auf einen Modellnamen, wird dieses Modell ein- oder ausgeblendet.
- Cairo-Implementierung: Wir berechnen bei jedem Redraw Hit-Boxes (_radar_legend_rects) und prüfen im button-press-event, ob der User getroffen hat.
- Effekt: Das ausgeblendete Modell wird in der Legende durchgestrichen, die Farbfläche wird gedimmt und das Polygon verschwindet sofort vom Chart.

Man braucht keine aufgeblähten Widget-Bäume, wenn man direkt mit Cairo zeichnen kann. Das händische Zeichnen der Gitterringe (bei 2.5, 5.0, 7.5 und 10.0 Punkten) gibt dem Ganzen einen sehr wertigen Look. Es fühlt sich einfach "snappy" an.

Technische Stolpersteine (Die "Learn-it-the-hard-way" Liste)

Hier sind die drei fiesesten Probleme, die mich während der Entwicklung genervt haben:

1. Der tarfile Streaming-Bug: tarfile.open(fileobj=reader) knallt bei Non-seekable-Quellen. Man muss zwingend mode="r|" nutzen. Dieser Hint wird jetzt automatisch in den Fix-Prompt eingebaut. Das hat mich Stunden an Debugging gekostet, bis ich gemerkt habe, dass Zstandard den Stream nicht "zurückwickeln" kann.
2. GTK ListStore Integer Overflow: GTK3 speichert Integers als 32-Bit. Ein 14B-Modell (ca. 8 GB) erzeugt einen OverflowError beim .append(). Die Lösung: Rohdaten in einem separaten Dict speichern, in der Liste nur Keys oder Strings. Lustigerweise bleibt die Tabelle sonst einfach leer – ohne Fehlermeldung. Klassisches GTK-Verhalten. ;)
3. Thread-Safety mit GLib.idle_add: Background-Threads dürfen die UI nicht direkt ändern. Alles muss über GLib.idle_add(callback) laufen, sonst raucht X11 einfach ab oder man bekommt diese netten Segmentations Faults, die einen zur Verzweiflung bringen.

Erste Ergebnisse: Die harte Wahrheit in Zahlen

Kommen wir zum spannenden Teil. Ich habe die Engine heute Morgen über meine aktuelle Modell-Riege fließen lassen. Die Daten stammen aus dem Run 2026-03-01 15:47:50.

Benchmark Dashboard (March 2026)

[!NOTE]
Legende zur Execution:
✔ 1/5 = Der generierte Code lief direkt im ersten Versuch fehlerfrei durch.
✘ 5/5 = Das Modell hat 5 Versuche bekommen, aber der Code ist jedes Mal mit einem Fehler (SNAFU!) abgeschmiert.
Der Total Score gewichtet Planung, Adherence und Implementation – auch wenn die Execution am Ende scheitert (z.B. wegen eines fehlenden Imports), kann der Plan dahinter trotzdem brillant sein.

Update 2026-03-01: Die folgenden Benchmark-Werte waren beim initialen Post teilweise unvollständig oder durch noch laufende Runs nicht final. Ich habe die Liste nun mit den komplett durchgelaufenen Ergebnissen ergänzt und korrigiert.

Hier noch mal die Analyse im Detail (nach korrigierter Messung):

• DeepSeek-Coder-V2 (16B): Bleibt der unangefochtene Champion mit 9.75. Die Heuristik ist so stark, dass auch die fehlende Execution den Sieg nicht gefährdet.
• Llama 3.2-Vision & DeepSeek-R1 (7B): Teilen sich Platz 2 mit starken 9.12, allerdings beide ohne erfolgreiche Ausführung.
• Codestral (22B): Ebenfalls stark mit 8.88, profitiert von hoher Planungs- und Umsetzungskompetenz.
• Die Mittelschicht (7.88 - 8.50): Modelle wie Llama 3.1, Phi4 und Qwen2.5-Coder (14B) und (7B Uncensored) platzieren sich hier dicht an dicht. Einige davon (wie Phi4 und Qwen) glänzen mit erfolgreichen Executions!
• Tiefkühlkost (0.00 - 3.75): Die kleineren oder älteren Modelle (Moondream, DeepSeek-Coder:6.7b, Qwen3-VL) tun sich beim autonomen Planen enorm schwer. Auffällig: Auch hier gibt es vereinzelte Execution-Erfolge (z. B. Mistral-Nemo, DeepSeek-Coder), was die Gesamtkomplexität der Benchmark-Metriken unterstreicht.

Lektion: Verlasst euch niemals nur auf Tokens pro Sekunde. Ein Modell mit 10 Tok/s, das beim ersten Mal funktionierenden Code liefert, spart euch am Ende mehr Zeit als ein 150-Tok/s-Raser, der 5 Anläufe braucht (und dann immer noch scheitert). Effizienz schlägt Geschwindigkeit. Punkt.

Infrastructure as Code (IaC): Ein neues Paradigma für LLMs?

Wenn wir über "Planning" sprechen, sprechen wir eigentlich über automatisierte Infrastruktur. Ein LLM, das in der Lage ist, ein venv anzulegen, Abhängigkeiten zu managen und Dateien zu validieren, bewegt sich im Bereich von Infrastructure as Code (IaC).

In einer Welt, in der wir hunderte von Agenten für verschiedene Aufgaben einsetzen, wird die Fähigkeit zur Selbst-Konfiguration zum entscheidenden Faktor. Ein Modell, das im Planning-Benchmark versagt, wird niemals in der Lage sein, eine komplexe Cloud-Infrastruktur oder ein lokales Kubernetes-Cluster sicher zu verwalten. Das ist der tiefere Sinn dieses Tests: Wir suchen nicht nur einen Chatbot, sondern einen digitalen Systemadministrator.

Ausblick: Was kommt als nächstes?

Der Benchmark ist erst der Anfang. Ich plane bereits eine massive Erweiterung der Suite, um noch tiefere Einblicke in die "Seele" der Modelle zu bekommen:

• Multi-Prompt-Library: Verschiedene Szenarien von Web-Scraping über komplexe SQL-Injection-Tests bis hin zu asynchronem API-Design stehen auf der Roadmap.
• Side-by-Side-Diff: Ich möchte die generierten Lösungen direkt im Vergleich zur Goldlösung im Code-Editor-Widget visualisieren. Das hilft uns Menschen, die Logikfehler der KI schneller zu verstehen.
• History-Charts: Langzeit-Tracking der Modell-Performance über mehrere Updates hinweg. Es wird spannend zu sehen, ob ein Modell durch ein neues Quantisierungsverfahren an Planning-Qualität verliert.
• Agentic Workflows: Die Integration von "Tools", die das LLM während des Benchmarks selbstständig aufrufen darf – eine Art "Sandbox-Hacking".

Lokale LLMs sind bereit für den Ernstfall. Man muss ihnen nur die richtigen Fragen stellen – und sie gnadenlos benchmarken. Wer seine Daten privat halten will (so wie ich), kommt um ein eigenes, lokales Benchmark-System nicht herum. Das Vertrauen in Cloud-Benchmarks ist gut, die Kontrolle auf der eigenen Hardware ist besser. Das ist nicht nur technisches Geraffel, das ist digitale Souveränität.

Bleibt pragmatisch, testet eure Modelle und lasst das Geraffel nicht Überhand nehmen!

Stay secure,
MrMarco ;)

Footnote: Dieser Beitrag wurde mit Hilfe von KI-Modellen erstellt (Geraffel-Suite!). Der Text wurde von mir geplant, seziert und auf meinen persönlichen Stil getrimmt. KI ist ein Werkzeug, keine Ausrede für schlechten Content. Mensch steuert, Maschine tippt.