chr1zZo
Commodore
- Registriert
- Feb. 2009
- Beiträge
- 4.662
Seit einiger Zeit lassen sich leistungsfähige Sprachmodelle vollständig auf dem eigenen Rechner betreiben. Damit entfallen API-Kosten, der Quellcode bleibt auf der eigenen Hardware und man ist nicht mehr von einem Cloud-Anbieter abhängig. Die spannende Frage ist allerdings nicht mehr, ob das funktioniert, sondern wie gut solche Modelle im Alltag tatsächlich sind.
Für diesen Test lief Qwen 3.6 27B lokal in LM Studio auf einem normalen PC. Über einen SSH-Reverse-Tunnel wurde das Modell einem Linux-Server zur Verfügung gestellt und dort in OpenWolf Enhanced eingebunden. Anstatt mit öffentlichen Benchmarks zu arbeiten, musste sich das Modell an einem privaten Buglog mit 157 dokumentierten Fehlern aus echten Projekten beweisen. Jeder dieser Bugs enthält das ursprüngliche Symptom, die tatsächliche Ursache und den späteren Fix. Dadurch war ausgeschlossen, dass das Modell die Lösungen bereits aus seinem Training kennen konnte.
Öffentliche Benchmarks wie SWE-bench oder HumanEval sind hilfreich, beantworten aber letztlich eine andere Frage. Sie zeigen, wie gut ein Modell standardisierte Aufgaben löst. Mich interessierte dagegen, ob ein lokales Modell Fehler erkennt, die ausschließlich im eigenen Projekt existieren. Deshalb rekonstruierte OpenWolf automatisch den Codezustand aus der Git-Historie vor dem jeweiligen Fix. Qwen sah also genau den fehlerhaften Code, den damals auch der Entwickler vor sich hatte.
Der Test bestand aus drei aufeinander aufbauenden Szenarien. Zunächst erhielt das Modell lediglich eine Fehlerbeschreibung und den Namen der betroffenen Datei. Ohne den eigentlichen Code erreichte es eine Diagnosequalität von rund 60 Prozent. Auffällig war dabei weniger die Trefferquote als die Art der Fehler. Wenn Qwen danebenlag, formulierte es seine Erklärung oft ausgesprochen überzeugend. Die Antworten wirkten plausibel und technisch sauber, hatten mit der tatsächlichen Ursache aber nichts zu tun. Genau diese Art von Halluzination ist im Entwickleralltag problematisch, weil sie sich kaum von einer richtigen Analyse unterscheiden lässt, solange man die Lösung nicht bereits kennt.
Im zweiten Durchlauf durfte das Modell den Quellcode lesen. Allein dieser Unterschied veränderte das Ergebnis deutlich. Die Diagnosequalität stieg auf 83 Prozent und die zuvor beobachteten Halluzinationen verschwanden in dieser Stichprobe vollständig. Zusätzlich erhielt Qwen mehrere frei erfundene Fehlersymptome für fehlerfreien Code. Statt zwanghaft eine Ursache zu erfinden, antwortete das Modell jedes Mal sinngemäß, dass sich für das beschriebene Problem im vorhandenen Code keine Hinweise finden lassen. Das war vermutlich die wichtigste Beobachtung des gesamten Tests. Nicht die Größe des Modells entschied über die Qualität der Antwort, sondern ob ausreichend Kontext vorhanden war.
Der dritte Durchlauf entsprach eher einem klassischen Code Review. Es gab keine Fehlerbeschreibung mehr, sondern ausschließlich Quellcode. Qwen musste selbst entscheiden, ob und wo Probleme existieren könnten. Dabei fand es mehrere reale Fehler, darunter Race Conditions, nicht aufgeräumte Retry-Timer und einen reproduzierbaren Absturz. Gleichzeitig übersah es den schwersten Bug des gesamten Projekts. In einer Cron-Komponente hätte das Zusammenspiel mehrerer unscheinbarer Codezeilen dazu geführt, dass rund 95 Prozent einer Wissensdatenbank überschrieben worden wären. Genau solche systemischen Fehler, die sich erst aus dem Zusammenspiel mehrerer Komponenten ergeben, gehören nach wie vor zu den Schwächen lokaler Modelle.
Während der Benchmarks trat noch eine zweite Erkenntnis zutage, die ursprünglich gar nicht Teil des Tests war. Ein KI-gestützter Cronjob sollte regelmäßig eine Wissensdatei bereinigen. Wegen eines Kontextlimits sah das Modell jedoch nur den letzten Teil der Datei und erzeugte daraus eine deutlich kleinere Version, die anschließend ungeprüft zurückgeschrieben worden wäre. Interessanterweise war dieser Fehler jahrelang nie aufgefallen, weil der benötigte API-Schlüssel fehlte und der Cronjob deshalb nie ausgeführt wurde. Erst mit einem lokalen Modell wäre diese unbeabsichtigte Sicherheitsbarriere verschwunden. Das zeigt, dass ein Wechsel von Cloud- zu lokaler KI nicht nur neue Möglichkeiten eröffnet, sondern bestehende Annahmen über ein System verändern kann.
Mindestens genauso interessant wie die Ergebnisse des Modells war die Rolle von OpenWolf Enhanced. Qwen wurde nicht einfach als Chatbot verwendet, sondern arbeitete innerhalb einer Agentenarchitektur, die viele Aufgaben übernimmt, die ein Sprachmodell alleine nur unzureichend lösen kann. OpenWolf rekonstruiert den passenden Codezustand aus der Git-Historie, teilt große Dateien verlustfrei in mehrere Abschnitte auf, erkennt leere Modellantworten, verhindert ungeprüfte Änderungen an produktiven Dateien und nutzt das projektspezifische Buglog als reproduzierbaren Benchmark. Dadurch musste das Modell deutlich seltener raten und konnte mit denselben Informationen arbeiten, die auch einem menschlichen Entwickler zur Verfügung stehen würden. OpenWolf macht das Modell nicht intelligenter, sorgt aber dafür, dass dessen vorhandene Fähigkeiten wesentlich besser zur Geltung kommen.
Dabei lohnt sich auch die Unterscheidung zwischen Modell und Betriebsort. Häufig werden "lokal" und "Cloud" gleichgesetzt, obwohl es sich um zwei verschiedene Dinge handelt. Dasselbe Qwen-Modell kann lokal auf einem PC oder über Anbieter wie OpenRouter in der Cloud betrieben werden. Darüber hinaus existieren deutlich größere Varianten derselben Modellfamilie, etwa Qwen 235B, die für Privatnutzer praktisch nicht mehr lokal einsetzbar sind. Ein Vergleich innerhalb derselben Modellfamilie wäre deshalb besonders spannend, weil sich der Einfluss von Modellgröße und Rechenleistung untersuchen ließe, ohne gleichzeitig unterschiedliche Architekturen miteinander zu vergleichen.
Nach mehreren Tagen Testen bleibt vor allem ein Eindruck: Lokale Modelle sind inzwischen weit davon entfernt, nur eine Spielerei zu sein. Für Codeanalysen, Reviews, Dokumentation oder Routineaufgaben liefern sie bereits heute einen echten Mehrwert – insbesondere dann, wenn Datenschutz und laufende Kosten eine Rolle spielen. Sie ersetzen die großen Frontier-Modelle noch nicht, ergänzen sie aber sinnvoll. In Kombination mit einer Agentenarchitektur wie OpenWolf Enhanced entsteht ein Entwicklungswerkzeug, das viele alltägliche Aufgaben zuverlässig übernehmen kann, während komplexe Architekturentscheidungen oder kritische Änderungen weiterhin von einem Menschen oder einem leistungsfähigeren Modell geprüft werden. Nicht das einzelne Sprachmodell entscheidet am Ende über die Qualität des Ergebnisses, sondern das Zusammenspiel aus Modell, Kontext, Werkzeugen und Sicherheitsmechanismen.
Der obere Text wurde mit AI erstellt
Tools und Modell:
OpenWolf Enhanced
LM Studio 0.4.19
Qwen 3.6 27B auf einer 3090 (Kontextfenstergröße 16k / Quantisierung Q4_K_M - 4-Bit, GGUF)
Frontier AI Claude Opus 4.8
Schlusswort:
Eine Lokale AI ohne ein Cerebrum bzw. einen Harness halte ich für Kritisch, erst Recht wenn man diese für diverse Agentic / Automationsprozesse einsetzen möchte. Ebenso muss man hier das ganze nicht auf seiner Hardware verbrennen. So kann man sehr kostengünstig Qwen 3.6 235B oder Qwen 3 Coder 90B via diverse Cloud Anbieter nutzen, die Qualitativ Hochwertiger sind und selbst bei mehreren Mio Token am Tag 5-10€ kosten, was bei aktuellen Strompreisen mit eigener Hardware weitaus teurer wäre. (Nutzer mit Solar jetzt mal ausgeschlossen).
Ich werde den Benchmark auf größere Kontextlängen erweitern und weitere Modelle hinzufügen, somit hat man einen schönen Überblick.
Benchmark Update: Qwen 3.6 (2 Modelle) vs. Gemma 4
Ziel ist es hier innerhalb von ComputerBase im Bezug auf das Thema AI mehr Austausch zu erreichen und Nutzer aufzuklären die sich gerne mit AI beschäftigen möchten oder dies bereits tun.
Ich freue mich auf Feedback / Kritik und ambitionierten Austausch.
Für diesen Test lief Qwen 3.6 27B lokal in LM Studio auf einem normalen PC. Über einen SSH-Reverse-Tunnel wurde das Modell einem Linux-Server zur Verfügung gestellt und dort in OpenWolf Enhanced eingebunden. Anstatt mit öffentlichen Benchmarks zu arbeiten, musste sich das Modell an einem privaten Buglog mit 157 dokumentierten Fehlern aus echten Projekten beweisen. Jeder dieser Bugs enthält das ursprüngliche Symptom, die tatsächliche Ursache und den späteren Fix. Dadurch war ausgeschlossen, dass das Modell die Lösungen bereits aus seinem Training kennen konnte.
Öffentliche Benchmarks wie SWE-bench oder HumanEval sind hilfreich, beantworten aber letztlich eine andere Frage. Sie zeigen, wie gut ein Modell standardisierte Aufgaben löst. Mich interessierte dagegen, ob ein lokales Modell Fehler erkennt, die ausschließlich im eigenen Projekt existieren. Deshalb rekonstruierte OpenWolf automatisch den Codezustand aus der Git-Historie vor dem jeweiligen Fix. Qwen sah also genau den fehlerhaften Code, den damals auch der Entwickler vor sich hatte.
Der Test bestand aus drei aufeinander aufbauenden Szenarien. Zunächst erhielt das Modell lediglich eine Fehlerbeschreibung und den Namen der betroffenen Datei. Ohne den eigentlichen Code erreichte es eine Diagnosequalität von rund 60 Prozent. Auffällig war dabei weniger die Trefferquote als die Art der Fehler. Wenn Qwen danebenlag, formulierte es seine Erklärung oft ausgesprochen überzeugend. Die Antworten wirkten plausibel und technisch sauber, hatten mit der tatsächlichen Ursache aber nichts zu tun. Genau diese Art von Halluzination ist im Entwickleralltag problematisch, weil sie sich kaum von einer richtigen Analyse unterscheiden lässt, solange man die Lösung nicht bereits kennt.
Im zweiten Durchlauf durfte das Modell den Quellcode lesen. Allein dieser Unterschied veränderte das Ergebnis deutlich. Die Diagnosequalität stieg auf 83 Prozent und die zuvor beobachteten Halluzinationen verschwanden in dieser Stichprobe vollständig. Zusätzlich erhielt Qwen mehrere frei erfundene Fehlersymptome für fehlerfreien Code. Statt zwanghaft eine Ursache zu erfinden, antwortete das Modell jedes Mal sinngemäß, dass sich für das beschriebene Problem im vorhandenen Code keine Hinweise finden lassen. Das war vermutlich die wichtigste Beobachtung des gesamten Tests. Nicht die Größe des Modells entschied über die Qualität der Antwort, sondern ob ausreichend Kontext vorhanden war.
Der dritte Durchlauf entsprach eher einem klassischen Code Review. Es gab keine Fehlerbeschreibung mehr, sondern ausschließlich Quellcode. Qwen musste selbst entscheiden, ob und wo Probleme existieren könnten. Dabei fand es mehrere reale Fehler, darunter Race Conditions, nicht aufgeräumte Retry-Timer und einen reproduzierbaren Absturz. Gleichzeitig übersah es den schwersten Bug des gesamten Projekts. In einer Cron-Komponente hätte das Zusammenspiel mehrerer unscheinbarer Codezeilen dazu geführt, dass rund 95 Prozent einer Wissensdatenbank überschrieben worden wären. Genau solche systemischen Fehler, die sich erst aus dem Zusammenspiel mehrerer Komponenten ergeben, gehören nach wie vor zu den Schwächen lokaler Modelle.
Während der Benchmarks trat noch eine zweite Erkenntnis zutage, die ursprünglich gar nicht Teil des Tests war. Ein KI-gestützter Cronjob sollte regelmäßig eine Wissensdatei bereinigen. Wegen eines Kontextlimits sah das Modell jedoch nur den letzten Teil der Datei und erzeugte daraus eine deutlich kleinere Version, die anschließend ungeprüft zurückgeschrieben worden wäre. Interessanterweise war dieser Fehler jahrelang nie aufgefallen, weil der benötigte API-Schlüssel fehlte und der Cronjob deshalb nie ausgeführt wurde. Erst mit einem lokalen Modell wäre diese unbeabsichtigte Sicherheitsbarriere verschwunden. Das zeigt, dass ein Wechsel von Cloud- zu lokaler KI nicht nur neue Möglichkeiten eröffnet, sondern bestehende Annahmen über ein System verändern kann.
Mindestens genauso interessant wie die Ergebnisse des Modells war die Rolle von OpenWolf Enhanced. Qwen wurde nicht einfach als Chatbot verwendet, sondern arbeitete innerhalb einer Agentenarchitektur, die viele Aufgaben übernimmt, die ein Sprachmodell alleine nur unzureichend lösen kann. OpenWolf rekonstruiert den passenden Codezustand aus der Git-Historie, teilt große Dateien verlustfrei in mehrere Abschnitte auf, erkennt leere Modellantworten, verhindert ungeprüfte Änderungen an produktiven Dateien und nutzt das projektspezifische Buglog als reproduzierbaren Benchmark. Dadurch musste das Modell deutlich seltener raten und konnte mit denselben Informationen arbeiten, die auch einem menschlichen Entwickler zur Verfügung stehen würden. OpenWolf macht das Modell nicht intelligenter, sorgt aber dafür, dass dessen vorhandene Fähigkeiten wesentlich besser zur Geltung kommen.
Dabei lohnt sich auch die Unterscheidung zwischen Modell und Betriebsort. Häufig werden "lokal" und "Cloud" gleichgesetzt, obwohl es sich um zwei verschiedene Dinge handelt. Dasselbe Qwen-Modell kann lokal auf einem PC oder über Anbieter wie OpenRouter in der Cloud betrieben werden. Darüber hinaus existieren deutlich größere Varianten derselben Modellfamilie, etwa Qwen 235B, die für Privatnutzer praktisch nicht mehr lokal einsetzbar sind. Ein Vergleich innerhalb derselben Modellfamilie wäre deshalb besonders spannend, weil sich der Einfluss von Modellgröße und Rechenleistung untersuchen ließe, ohne gleichzeitig unterschiedliche Architekturen miteinander zu vergleichen.
Nach mehreren Tagen Testen bleibt vor allem ein Eindruck: Lokale Modelle sind inzwischen weit davon entfernt, nur eine Spielerei zu sein. Für Codeanalysen, Reviews, Dokumentation oder Routineaufgaben liefern sie bereits heute einen echten Mehrwert – insbesondere dann, wenn Datenschutz und laufende Kosten eine Rolle spielen. Sie ersetzen die großen Frontier-Modelle noch nicht, ergänzen sie aber sinnvoll. In Kombination mit einer Agentenarchitektur wie OpenWolf Enhanced entsteht ein Entwicklungswerkzeug, das viele alltägliche Aufgaben zuverlässig übernehmen kann, während komplexe Architekturentscheidungen oder kritische Änderungen weiterhin von einem Menschen oder einem leistungsfähigeren Modell geprüft werden. Nicht das einzelne Sprachmodell entscheidet am Ende über die Qualität des Ergebnisses, sondern das Zusammenspiel aus Modell, Kontext, Werkzeugen und Sicherheitsmechanismen.
Der obere Text wurde mit AI erstellt
Tools und Modell:
OpenWolf Enhanced
LM Studio 0.4.19
Qwen 3.6 27B auf einer 3090 (Kontextfenstergröße 16k / Quantisierung Q4_K_M - 4-Bit, GGUF)
Frontier AI Claude Opus 4.8
# Frontier vs. lokal auf Endverbraucher-Hardware — was Qwen 3.6 27B kann, was nicht
Stand: 2026-07-14. Alle Zahlen aus eigenen Läufen an einem einzigen Tag. Rohdaten liegen daneben
(
Setup: Qwen 3.6 27B, lokal in LM Studio auf dem PC des Nutzers, per SSH-Reverse-Tunnel an einen
Linux-Server gereicht (
Gegenspieler/Prüfer: Claude Opus 4.8 (Frontier, in der Session).
---
## 0. Der Bias, den man beim Lesen mitdenken muss
Es gab keinen neutralen Judge. Auf dem Server war weder ein OpenRouter- noch ein Anthropic-Key
gesetzt. Qwen sich selbst benoten zu lassen wäre wertlos gewesen, also hat **Claude die Antworten
benotet — ein Konkurrenzmodell bewertet einen Wettbewerber.** Das ist ein echter Interessenkonflikt und
wird hier nicht versteckt.
Was davon unberührt ist und deshalb am meisten zählt:
Wer die Diagnose-Prozente anzweifelt: berechtigt. Wer den reproduzierten
Befehl steht unten, er dauert zehn Sekunden.
---
## 1. Der Testaufbau — und warum kein öffentlicher Benchmark
Getestet wurde gegen
dokumentiertem Symptom, dokumentierter Ursache und dokumentiertem Fix. Diese Daten hat **kein Modell je
gesehen**.
Das ist der Kern der Sache: Bei SWE-bench & Co. lässt sich nie ausschließen, dass ein Modell die Lösung
auswendig kennt. Ein Modell, das die Antwort kennt, sagt nichts darüber, ob es unsere Bugs findet.
Ein privates Buglog ist der ehrlichste Maßstab, den man haben kann — und **genau das ist die Datei, die
OpenWolf Enhanced ohnehin führt** (siehe Abschnitt 6).
Kontaminationsschutz. Alle Bugs sind längst gefixt. Gäbe man dem Modell den aktuellen Dateiinhalt,
stünde die Lösung im Prompt. Der Code wird deshalb aus der Git-Historie vor dem Fix rekonstruiert —
und zwar nicht per Zeitstempel (Bugs werden ja nach dem Fix geloggt, der Zeitstempel liegt also hinter
dem Fix), sondern über eine Fix-Signatur: genommen wird der neueste Blob, in dem sie noch fehlt.
Fällt kein Blob durch den Filter, wird der Fall verworfen statt geraten. In Lauf 2 flogen so 4 von
11 Fällen raus.
---
## 2. Lauf 1 — Diagnose OHNE Code (nur Symptom + Dateiname)
| Metrik | Ergebnis |
|---|---|
| Diagnose | 24/40 = 60 % (9× voll, 6× teilweise, 5× verfehlt) |
| Tool-Calls (striktes JSON-Schema) | 5/5 |
| Ø Latenz | 55,8 s |
| Kosten | 0 |
Stark bei Standard-Fehlermustern, die in jedem Trainingskorpus tausendfach vorkommen: CSP blockt
Analytics, Next.js
stille Rechte-Eskalation durch Fallback-Whitelist.
Und dann erfindet es. Alle 5 Nuller sind nicht „weiß ich nicht", sondern **flüssig formulierte,
überzeugende, falsche Ursachen**:
| Bug | Wahrheit | Qwens Erfindung |
|---|---|---|
| Hook zählt Writes nie | Bash-Hook stieg vor dem Zählen aus | „Race-Condition mit
| Kugel im 3D-Wolfsgesicht | InstancedMesh-Identity-Matrix = Einheitskugel | „
| Zerquetschter X-Button |
Das ist die gefährliche Fehlerart: nicht Schweigen, sondern überzeugendes Danebenliegen. Wer die
Antwort nicht schon kennt, unterscheidet diese 5 nicht von den 9 Volltreffern.
---
## 3. Lauf 2 — Diagnose MIT Code + Halluzinations-Köder
Lauf 1 war absichtlich hart, aber nicht die Lage, in der ein Agent arbeitet: der liest die Datei.
| | ohne Code | mit Code |
|---|---|---|
| Diagnose (dieselben 6 Bugs) | 7/12 = 58 % | 10/12 = 83 % |
| erfundene Ursachen | 2 | 0 |
| Köder (5 frei erfundene Bugs gegen gesunden Code) | — | 5/5 korrekt abstiniert |
Das ist das wichtigste Ergebnis des Tages. Mit Code im Kontext verschwindet die Konfabulation in
dieser Stichprobe vollständig. Die zwei Erfindungen aus Lauf 1 lösten sich unterschiedlich auf: einen
Bug löste es richtig, den anderen verweigerte es ehrlich („NICHT_IM_CODE") statt zu erfinden.
Der Köder-Test ist der judge-freie Kern: fünf frei erfundene Symptome („CSV vertauscht ab Zeile 500
die Spalten", „Build scheitert bei Bindestrich im Hostnamen") gegen den echten, gesunden Code. Es gibt
nichts zu finden. Qwen hat alle fünf zurückgewiesen. Es weiß, wann es nichts weiß — wenn man ihm
das Material gibt.
Harte Limits: Bei der größten Datei (14,6k Zeichen) terminiert das Denken nicht — auch mit 9.000
Token Budget bleibt die Antwort leer, nach 231 Sekunden. Latenz 39–231 s.
---
## 4. Lauf 3 — Offene Bug-Suche (kein Symptom, nur Code)
Die eigentliche Reviewer-Aufgabe. Zwei Zahlen, die man nur zusammen lesen darf.
Recall — 1 von 2 (Dateien mit bekanntem Bug, Symptom verschwiegen):
Precision — 4 von 7 Funden sind echt (gesunder, aktueller Code):
| Fund | Urteil |
|---|---|
|
|
|
| Backup-Fehler wird verschluckt, Original trotzdem überschrieben | ECHT |
| Überlappende Blockbereiche korrumpieren die Datei | FALSCH (Bereiche sind per Konstruktion disjunkt) |
| CRLF wird stillschweigend normalisiert | stimmt, kosmetisch |
| Timezone-Vergleich | zweifelhaft |
Bei einer gesunden Datei sagte es „KEINE BEFUNDE" — es erfindet nicht auf Verdacht.
Der reproduzierte Absturz, zum Selbstnachstellen:
### Der wichtigste Befund ist ein Fehlschlag
Die geprüfte
20-KB-Kappung und das ungeprüfte Zurückschreiben nach
sichtbar. Der Bug, der 95 % der Wissensbasis gelöscht hätte.
Qwen hat ihn nicht gefunden. Es meldete drei kleinere Sachen und übersah die Katastrophe.
Kosten der offenen Suche: ~13.000 Reasoning-Tokens und ~6 Minuten pro Datei (gemessen: 372 s bei
14k Budget; mit 8k Budget kommt gar keine Antwort, weil das Denken das Budget frisst).
---
## 5. Der Beinahe-Unfall — und was er über lokale Modelle lehrt
Beim Testen der echten Cron-Jobs fiel auf: der Task
hätte die 78 KB große Wissensdatei durch eine 3,9 KB große „bereinigte" Fassung ersetzt — **95 % Verlust,
lautlos, ohne Backup**.
Die Kette: Kontext-Cap bei 20 KB → Modell sieht nur das letzte Viertel → Prompt sagt trotzdem
„return the cleaned file content only" → Ergebnis wird ungeprüft zurückgeschrieben.
Der Task war seit jeher aktiviert. Er ist nur nie gelaufen — weil
Ein fehlender API-Key war die einzige Sicherung. Und genau die entfällt in dem Moment, in dem man auf ein
lokales, keyloses Modell umstellt.
---
## 6. Was OpenWolf Enhanced dazu beiträgt
Der interessante Teil ist nicht „lokales Modell ist schlechter". Das überrascht niemanden. Interessant ist,
welche Werkzeuge ein lokales Modell brauchbar machen — und die sind alle im Tool gelandet:
1. Das private Buglog als Ground Truth. OpenWolf führt ohnehin ein
und Fix. Damit hat man einen Benchmark, den kein Modell auswendig kennen kann — ohne dafür irgendetwas
Zusätzliches zu bauen.
2. „Leere Antwort" ist ein eigener Fehlerzustand. Reasoning-Modelle verrechnen ihr Denken gegen
dasselbe
Fehler. Gemessen: ein zweizeiliger Merge-Prompt kostet 1.935 Reasoning-Tokens; mit dem alten Budget
von 900 kam garantiert nichts. Vorher gab OpenWolf das als leeren String weiter:
jeden Merge stumm,
→ Jetzt wirft eine vor der Antwort abgeschnittene Response. *(Diese Falle hat mich an einem Tag
dreimal erwischt — auch im eigenen Benchmark-Harness, wo ein leerer Köder als „HALLUZINIERT" gezählt
wurde. Wer lokale Reasoning-Modelle einsetzt, wird sie garantiert treffen.)*
3. Das lokale Modell schlägt vor, es überschreibt nicht. AI-Cron-Tasks laufen jetzt im Modus
bleiben unberührt. Ein Mensch — oder ein Frontier-Modell in der Session — entscheidet, was übernommen wird.
Der lokale Rechner macht die Fleißarbeit, die Hoheit über die Wahrheit bleibt beim Leser. Das ist
genau die Arbeitsteilung, die die Messungen nahelegen.
4. Zu große Dateien werden GETEILT, nicht abgeschnitten.
Absatzgrenzen und ist verlustfrei (per Test abgesichert). Ein Modell mit 16k Kontext liest eine 20k-Datei
damit vollständig — nur eben in mehreren Durchgängen. Abschneiden ist bei einer Wissensdatei kein
Größenlimit, sondern Datenverlust mit Zwischenschritt.
5. Fehlermeldungen, die den nächsten Schritt nennen. Port aus der konfigurierten
hartkodiert (LM Studio: 1234, Ollama: 11434), und der häufigste Fall „Tunnel steht, Server läuft nicht"
wird explizit benannt — er sieht aus wie ein Verbindungsfehler und ist keiner.
6. Vorschlags-Kategorien müssen am Text belegbar sein. Erste Version des Reflection-Prompts fragte
u. a. „was ist hier unklar?" → ein Modell ohne Projektwissen flaggte
korrekt und völlig nutzlos: eine Wissensdatei ist projektinterne Kurzschrift. Brauchbar sind nur
Kategorien, die das Modell im gezeigten Text selbst nachweisen kann (REDUNDANT, WIDERSPRUCH).
---
## 7. Fazit
Was Qwen 3.6 27B auf Endverbraucher-Hardware kann:
Was es nicht kann:
Die Arbeitsteilung, die sich daraus ergibt:
Das lokale Modell ist ein Nachtläufer und Vorfilter — es liest, sucht, schlägt vor, kostet nichts und
gibt keine Daten heraus. Das Frontier-Modell ist Prüfer und Entscheider. Wer das lokale Modell
entscheiden lässt, bekommt bug-157. Wer es gar nicht einsetzt, verschenkt einen kostenlosen Reviewer, bei
dem jeder zweite Fund echt ist.
---
Stand: 2026-07-14. Alle Zahlen aus eigenen Läufen an einem einzigen Tag. Rohdaten liegen daneben
(
raw-*.jsonl), jede Note ist einzeln nachprüfbar und widersprechbar.Setup: Qwen 3.6 27B, lokal in LM Studio auf dem PC des Nutzers, per SSH-Reverse-Tunnel an einen
Linux-Server gereicht (
ssh -N -R 1234:localhost:1234). Kontextfenster 16.640 Token. Kosten: null.Gegenspieler/Prüfer: Claude Opus 4.8 (Frontier, in der Session).
---
## 0. Der Bias, den man beim Lesen mitdenken muss
Es gab keinen neutralen Judge. Auf dem Server war weder ein OpenRouter- noch ein Anthropic-Key
gesetzt. Qwen sich selbst benoten zu lassen wäre wertlos gewesen, also hat **Claude die Antworten
benotet — ein Konkurrenzmodell bewertet einen Wettbewerber.** Das ist ein echter Interessenkonflikt und
wird hier nicht versteckt.
Was davon unberührt ist und deshalb am meisten zählt:
- Tool-Call-Disziplin (Schema-Validierung, rein maschinell)
- Abstinenz-Test (Schlüsselwort, wird gezählt, nicht bewertet)
- Reproduzierte Abstürze (ein Bug, den man nachstellen kann, ist kein Meinungsgegenstand)
- Laufzeiten und Token-Verbrauch
Wer die Diagnose-Prozente anzweifelt: berechtigt. Wer den reproduzierten
TypeError anzweifelt: derBefehl steht unten, er dauert zehn Sekunden.
---
## 1. Der Testaufbau — und warum kein öffentlicher Benchmark
Getestet wurde gegen
buglog.json: 157 echte, handgeschriebene Bugs aus privaten Repos, jeder mitdokumentiertem Symptom, dokumentierter Ursache und dokumentiertem Fix. Diese Daten hat **kein Modell je
gesehen**.
Das ist der Kern der Sache: Bei SWE-bench & Co. lässt sich nie ausschließen, dass ein Modell die Lösung
auswendig kennt. Ein Modell, das die Antwort kennt, sagt nichts darüber, ob es unsere Bugs findet.
Ein privates Buglog ist der ehrlichste Maßstab, den man haben kann — und **genau das ist die Datei, die
OpenWolf Enhanced ohnehin führt** (siehe Abschnitt 6).
Kontaminationsschutz. Alle Bugs sind längst gefixt. Gäbe man dem Modell den aktuellen Dateiinhalt,
stünde die Lösung im Prompt. Der Code wird deshalb aus der Git-Historie vor dem Fix rekonstruiert —
und zwar nicht per Zeitstempel (Bugs werden ja nach dem Fix geloggt, der Zeitstempel liegt also hinter
dem Fix), sondern über eine Fix-Signatur: genommen wird der neueste Blob, in dem sie noch fehlt.
Fällt kein Blob durch den Filter, wird der Fall verworfen statt geraten. In Lauf 2 flogen so 4 von
11 Fällen raus.
---
## 2. Lauf 1 — Diagnose OHNE Code (nur Symptom + Dateiname)
| Metrik | Ergebnis |
|---|---|
| Diagnose | 24/40 = 60 % (9× voll, 6× teilweise, 5× verfehlt) |
| Tool-Calls (striktes JSON-Schema) | 5/5 |
| Ø Latenz | 55,8 s |
| Kosten | 0 |
Stark bei Standard-Fehlermustern, die in jedem Trainingskorpus tausendfach vorkommen: CSP blockt
Analytics, Next.js
standalone kopiert public/ nicht, CSV-Dreifach-Quoting durch JSON.stringify,stille Rechte-Eskalation durch Fallback-Whitelist.
Und dann erfindet es. Alle 5 Nuller sind nicht „weiß ich nicht", sondern **flüssig formulierte,
überzeugende, falsche Ursachen**:
| Bug | Wahrheit | Qwens Erfindung |
|---|---|---|
| Hook zählt Writes nie | Bash-Hook stieg vor dem Zählen aus | „Race-Condition mit
fs.watch/Chokidar" — es gibt keinen Watcher || Kugel im 3D-Wolfsgesicht | InstancedMesh-Identity-Matrix = Einheitskugel | „
useGLTF-Platzhalter ohne Guard" || Zerquetschter X-Button |
cn() wrappte clsx ohne tailwind-merge | „tailwind-merge verwirft unbekannte Klassen" — genau verkehrt herum |Das ist die gefährliche Fehlerart: nicht Schweigen, sondern überzeugendes Danebenliegen. Wer die
Antwort nicht schon kennt, unterscheidet diese 5 nicht von den 9 Volltreffern.
---
## 3. Lauf 2 — Diagnose MIT Code + Halluzinations-Köder
Lauf 1 war absichtlich hart, aber nicht die Lage, in der ein Agent arbeitet: der liest die Datei.
| | ohne Code | mit Code |
|---|---|---|
| Diagnose (dieselben 6 Bugs) | 7/12 = 58 % | 10/12 = 83 % |
| erfundene Ursachen | 2 | 0 |
| Köder (5 frei erfundene Bugs gegen gesunden Code) | — | 5/5 korrekt abstiniert |
Das ist das wichtigste Ergebnis des Tages. Mit Code im Kontext verschwindet die Konfabulation in
dieser Stichprobe vollständig. Die zwei Erfindungen aus Lauf 1 lösten sich unterschiedlich auf: einen
Bug löste es richtig, den anderen verweigerte es ehrlich („NICHT_IM_CODE") statt zu erfinden.
Der Köder-Test ist der judge-freie Kern: fünf frei erfundene Symptome („CSV vertauscht ab Zeile 500
die Spalten", „Build scheitert bei Bindestrich im Hostnamen") gegen den echten, gesunden Code. Es gibt
nichts zu finden. Qwen hat alle fünf zurückgewiesen. Es weiß, wann es nichts weiß — wenn man ihm
das Material gibt.
Harte Limits: Bei der größten Datei (14,6k Zeichen) terminiert das Denken nicht — auch mit 9.000
Token Budget bleibt die Antwort leer, nach 231 Sekunden. Latenz 39–231 s.
---
## 4. Lauf 3 — Offene Bug-Suche (kein Symptom, nur Code)
Die eigentliche Reviewer-Aufgabe. Zwei Zahlen, die man nur zusammen lesen darf.
Recall — 1 von 2 (Dateien mit bekanntem Bug, Symptom verschwiegen):
- ✅
post-bash.ts: fand das nicht-atomare Read-Modify-Write exakt, inklusive Mechanismus. - ❌
llm-provider.ts: übersah den bekannten Bug und meldete stattdessen einen erfundenen
Precision — 4 von 7 Funden sind echt (gesunder, aktueller Code):
| Fund | Urteil |
|---|---|
|
openwolf recall stürzt ab, wenn buglog.json = null | ECHT, reproduziert ||
cron-state.json Lost-Update über den LLM-await hinweg | ECHT ||
stop() räumt Retry-setTimeout nie ab → Retries feuern nach dem Shutdown | ECHT || Backup-Fehler wird verschluckt, Original trotzdem überschrieben | ECHT |
| Überlappende Blockbereiche korrumpieren die Datei | FALSCH (Bereiche sind per Konstruktion disjunkt) |
| CRLF wird stillschweigend normalisiert | stimmt, kosmetisch |
| Timezone-Vergleich | zweifelhaft |
Bei einer gesunden Datei sagte es „KEINE BEFUNDE" — es erfindet nicht auf Verdacht.
Der reproduzierte Absturz, zum Selbstnachstellen:
Bash:
mkdir -p /tmp/x/.wolf && cd /tmp/x && printf 'null' > .wolf/buglog.json
openwolf recall test # → TypeError: Cannot read properties of null (reading 'bugs')### Der wichtigste Befund ist ein Fehlschlag
Die geprüfte
cron-engine.ts enthielt noch den schwersten Bug des Projekts (siehe Abschnitt 5): die20-KB-Kappung und das ungeprüfte Zurückschreiben nach
cerebrum.md, beides in derselben Datei, beidessichtbar. Der Bug, der 95 % der Wissensbasis gelöscht hätte.
Qwen hat ihn nicht gefunden. Es meldete drei kleinere Sachen und übersah die Katastrophe.
Kosten der offenen Suche: ~13.000 Reasoning-Tokens und ~6 Minuten pro Datei (gemessen: 372 s bei
14k Budget; mit 8k Budget kommt gar keine Antwort, weil das Denken das Budget frisst).
---
## 5. Der Beinahe-Unfall — und was er über lokale Modelle lehrt
Beim Testen der echten Cron-Jobs fiel auf: der Task
cerebrum-reflection (aktiv, jeden Sonntag 03:00)hätte die 78 KB große Wissensdatei durch eine 3,9 KB große „bereinigte" Fassung ersetzt — **95 % Verlust,
lautlos, ohne Backup**.
Die Kette: Kontext-Cap bei 20 KB → Modell sieht nur das letzte Viertel → Prompt sagt trotzdem
„return the cleaned file content only" → Ergebnis wird ungeprüft zurückgeschrieben.
Der Task war seit jeher aktiviert. Er ist nur nie gelaufen — weil
ANTHROPIC_API_KEY nicht gesetzt war.Ein fehlender API-Key war die einzige Sicherung. Und genau die entfällt in dem Moment, in dem man auf ein
lokales, keyloses Modell umstellt.
---
## 6. Was OpenWolf Enhanced dazu beiträgt
Der interessante Teil ist nicht „lokales Modell ist schlechter". Das überrascht niemanden. Interessant ist,
welche Werkzeuge ein lokales Modell brauchbar machen — und die sind alle im Tool gelandet:
1. Das private Buglog als Ground Truth. OpenWolf führt ohnehin ein
buglog.json mit Symptom, Ursacheund Fix. Damit hat man einen Benchmark, den kein Modell auswendig kennen kann — ohne dafür irgendetwas
Zusätzliches zu bauen.
2. „Leere Antwort" ist ein eigener Fehlerzustand. Reasoning-Modelle verrechnen ihr Denken gegen
dasselbe
max_tokens-Budget. Ist es aufgebraucht, kommt HTTP 200 mit leerem content — ein stillerFehler. Gemessen: ein zweizeiliger Merge-Prompt kostet 1.935 Reasoning-Tokens; mit dem alten Budget
von 900 kam garantiert nichts. Vorher gab OpenWolf das als leeren String weiter:
consolidate verwarfjeden Merge stumm,
openwolf llm --test meldete einen grünen Haken auf 0 Zeichen.→ Jetzt wirft eine vor der Antwort abgeschnittene Response. *(Diese Falle hat mich an einem Tag
dreimal erwischt — auch im eigenen Benchmark-Harness, wo ein leerer Köder als „HALLUZINIERT" gezählt
wurde. Wer lokale Reasoning-Modelle einsetzt, wird sie garantiert treffen.)*
3. Das lokale Modell schlägt vor, es überschreibt nicht. AI-Cron-Tasks laufen jetzt im Modus
proposal: das Ergebnis landet in .wolf/proposals/<task>-<zeitstempel>.md, kanonische Dateienbleiben unberührt. Ein Mensch — oder ein Frontier-Modell in der Session — entscheidet, was übernommen wird.
Der lokale Rechner macht die Fleißarbeit, die Hoheit über die Wahrheit bleibt beim Leser. Das ist
genau die Arbeitsteilung, die die Messungen nahelegen.
4. Zu große Dateien werden GETEILT, nicht abgeschnitten.
splitForContext() schneidet anAbsatzgrenzen und ist verlustfrei (per Test abgesichert). Ein Modell mit 16k Kontext liest eine 20k-Datei
damit vollständig — nur eben in mehreren Durchgängen. Abschneiden ist bei einer Wissensdatei kein
Größenlimit, sondern Datenverlust mit Zwischenschritt.
5. Fehlermeldungen, die den nächsten Schritt nennen. Port aus der konfigurierten
base_url statthartkodiert (LM Studio: 1234, Ollama: 11434), und der häufigste Fall „Tunnel steht, Server läuft nicht"
wird explizit benannt — er sieht aus wie ein Verbindungsfehler und ist keiner.
6. Vorschlags-Kategorien müssen am Text belegbar sein. Erste Version des Reflection-Prompts fragte
u. a. „was ist hier unklar?" → ein Modell ohne Projektwissen flaggte
S2, K2/K3, Ticker-Namen. Völligkorrekt und völlig nutzlos: eine Wissensdatei ist projektinterne Kurzschrift. Brauchbar sind nur
Kategorien, die das Modell im gezeigten Text selbst nachweisen kann (REDUNDANT, WIDERSPRUCH).
---
## 7. Fazit
Was Qwen 3.6 27B auf Endverbraucher-Hardware kann:
- Standard-Fehlermuster diagnostizieren (60 % ohne Code, 83 % mit Code)
- Werkzeugaufrufe gegen striktes JSON-Schema: 5/5, kein Schema-Verstoß
- Nein sagen: 5/5 erfundene Bugs zurückgewiesen, „KEINE BEFUNDE" bei gesundem Code
- Reale Bugs in fremdem Code finden, ohne Symptom — inklusive eines reproduzierten Absturzes
- Kosten: null. Datenschutz: alles bleibt lokal.
Was es nicht kann:
- Ohne Kontext arbeiten. Kontextlos erfindet es bei jeder vierten Antwort eine überzeugende falsche Ursache.
- Systemische Fehler sehen. Den 95-%-Datenverlust-Bug in der Datei, die es gerade prüfte, hat es übersehen.
- Schnell sein. 6 Minuten und 13.000 Denk-Tokens pro Datei bei offener Suche.
- Große Dateien verarbeiten. Ab ~15k Zeichen terminiert das Denken teils gar nicht mehr.
- Ideen haben. 0 von 3 Feature-Vorschlägen brauchbar — zwei bauten Vorhandenes nach, einer löste ein
Die Arbeitsteilung, die sich daraus ergibt:
Das lokale Modell ist ein Nachtläufer und Vorfilter — es liest, sucht, schlägt vor, kostet nichts und
gibt keine Daten heraus. Das Frontier-Modell ist Prüfer und Entscheider. Wer das lokale Modell
entscheiden lässt, bekommt bug-157. Wer es gar nicht einsetzt, verschenkt einen kostenlosen Reviewer, bei
dem jeder zweite Fund echt ist.
---
Schlusswort:
Eine Lokale AI ohne ein Cerebrum bzw. einen Harness halte ich für Kritisch, erst Recht wenn man diese für diverse Agentic / Automationsprozesse einsetzen möchte. Ebenso muss man hier das ganze nicht auf seiner Hardware verbrennen. So kann man sehr kostengünstig Qwen 3.6 235B oder Qwen 3 Coder 90B via diverse Cloud Anbieter nutzen, die Qualitativ Hochwertiger sind und selbst bei mehreren Mio Token am Tag 5-10€ kosten, was bei aktuellen Strompreisen mit eigener Hardware weitaus teurer wäre. (Nutzer mit Solar jetzt mal ausgeschlossen).
Ich werde den Benchmark auf größere Kontextlängen erweitern und weitere Modelle hinzufügen, somit hat man einen schönen Überblick.
Benchmark Update: Qwen 3.6 (2 Modelle) vs. Gemma 4
Ziel ist es hier innerhalb von ComputerBase im Bezug auf das Thema AI mehr Austausch zu erreichen und Nutzer aufzuklären die sich gerne mit AI beschäftigen möchten oder dies bereits tun.
Ich freue mich auf Feedback / Kritik und ambitionierten Austausch.
Zuletzt bearbeitet:
Richtig, ich habe es auch gezielt auf Endverbraucher Hardware gemacht und nicht auf einem LLM System. Kommt als Nachtrag die Tage mit dem höheren Kontext.
