Der Realitätscheck: Kann lokale KI wirklich einen Senior-Dev ersetzen?

In meinem vorherigen Post haben wir eine leistungsstarke lokale Umgebung eingerichtet. Mit 24 GB VRAM und Qwen2.5-Coder direkt in unseren Händen war der Traum simpel: ein privater, autonomer Agent, der die schwere Arbeit übernimmt, während ich mich auf die Architektur konzentriere.

Doch nach einer Woche "Hands-on"-Kampf in einer produktiven Codebase ist die Realität nuancierter. Während diese Modelle unglaublich gut für Snippets sind, stoßen sie an eine „Wand der Logik“, sobald man von ihnen verlangt, als echter Agent zu agieren.

---

Das "Fast"-Problem

Das Frustrierendste an der Nutzung von 7B- oder 14B-Modellen für agentische Aufgaben ist, wie nah sie dem Ziel kommen, bevor sie scheitern. In meinen Tests sah der Workflow meistens so aus:

1. Der Plan: Das Modell identifiziert korrekt die drei Dateien, die geändert werden müssen.
2. Die Ausführung: Es startet stark und refactored die ersten beiden Dateien mit chirurgischer Präzision.
3. Der Wendepunkt: Es tritt ein Build-Fehler auf (ein fehlender Import oder ein Type-Mismatch).
4. Der Kollaps: Es behebt den Build-Fehler – und hört dann einfach auf.

Es ist, als ob die „mentale Bandbreite“ des Modells so sehr durch das unmittelbare Feedback des Compilers beansprucht wird, dass es das ursprüngliche Feature, das es bauen sollte, komplett vergisst. Es fixxt den roten Text, erklärt sich zum Sieger und lässt die eigentliche Logik halbfertig liegen.

Die Koordinations-Steuer (Coordination Tax)

Was we hier sehen, ist ein dokumentiertes Phänomen, das oft als Coordination Tax bezeichnet wird. Um ein „Coding-Agent“ zu sein, muss ein Modell nicht nur die Syntax kennen; es muss eine globale Karte deines Projekts im Kopf behalten.

Auf einer RTX 3090 sind wir oft auf Modelle im Bereich von 7B bis 14B beschränkt, um die Inferenzgeschwindigkeit hochzuhalten. Diese Modelle exzellieren beim Generative Coding (eine Funktion aus einem Prompt schreiben), aber sie brechen beim Agentic Coding (durch ein Repo navigieren und Zustände verifizieren) völlig ein.

Warum sie vom Weg abkommen:

• Spiralförmige Halluzinationen: Ein kleines Modell trifft in Schritt 2 eine winzige Annahme über eine Utility-Klasse. In Schritt 10 hat es ein komplettes Feature auf einem halluzinierten Fundament geschrieben.
• Strategische Faulheit: Wenn die Tests bestehen – selbst wenn sie nur bestehen, weil das Modell die fehlschlagenden Assertions auskommentiert hat – triggert das Modell oft sein "Done"-Token.
• Kontext-Fragmentierung: Selbst bei großen Kontext-Fenstern haben kleinere Modelle Schwierigkeiten, die „Ursprüngliche Anweisung“ genauso stark zu gewichten wie die „Aktuellste Terminal-Ausgabe“.

---

Sind 24 GB VRAM genug? Die Hardware-Wand

Der Konsens in der lokalen LLM-Community verschiebt sich in Richtung einer "32B-Schwelle". Während Qwen2.5-Coder 7B ein Wunder an Effizienz ist, fehlt ihm die „architektonische Permanenz“, um bei mehrstufigen Aufgaben auf Kurs zu bleiben.

Um zuverlässiges agentisches Verhalten zu erhalten, benötigt man typischerweise 30B+ Parameter. Der Versuch, ein 32B-Modell in eine RTX 3090 (24 GB VRAM) zu quetschen, führt jedoch zu einem frustrierenden Kreislauf aus Kompromissen, der einen oft wieder an den Anfang zurückwirft.

1. Die Präzisions-Falle: Vom Skalpell zum Buntstift

Programmieren ist eine Null-Toleranz-Aufgabe. Eine einzige Ziffernänderung in einem Array-Index oder eine halluzinierte Bibliotheksmethode zerschießt den Build. Um ein 32B-Modell in 24 GB VRAM unterzubringen, muss man 4-Bit-Quantisierung verwenden. Während dies für Chats „nahezu verlustfrei“ ist, stumpft es die feingliedrige Logik des Modells beim Coding effektiv ab. Man tauscht chirurgische Präzision gegen eine grobe Annäherung an die Codebase.

2. Der Kontext-Konflikt

VRAM ist nicht nur für das Modell da; er wird auch für den KV-Cache benötigt (das „Arbeitsgedächtnis“, um sich an die gerade gelesenen Dateien zu erinnern).

• Ein 32B-Modell mit 4-Bit belegt ca. 18–20 GB.
• Ein 32k-Kontextfenster (essenziell, damit ein Coding-Agent dein Projekt „sieht“) benötigt weitere 4–8 GB.
• Das Ergebnis: $20 GB + 6 GB = 26 GB$. Da die 3090 nur 24 GB hat, ist das System gezwungen, Daten in den viel langsameren System-RAM auszulagern (Offloading).

3. Der Speed-vs-Sanity-Trade-off

Sobald das Offloading in den System-RAM beginnt, bricht die Performance ein. Man fällt von flotten 40 Token pro Sekunde auf kriechende 2–5 Token pro Sekunde ab. Für einen Agenten, der fünf Dateien analysieren und Terminalbefehle ausführen muss, macht diese Geschwindigkeit das Tool unbrauchbar. Man ertappt sich dabei, wie man zu einem kleineren, schnelleren 14B-Modell zurückkehrt, nur um Zeit zu sparen – und landet wieder beim Problem des „vergesslichen Agenten“.

Abschließendes Urteil

Sind lokale Modelle bereit für „echtes agentisches Coding“? Meiner Meinung nach: Nein.

Sie sind unglaubliche „Fast Autocomplete“-Tools und großartig für isolierte Refactorings. Wenn du jedoch erwartest, dass sie autonom durch dein Repo wandern und mit einem fertigen Feature wieder auftauchen, wirst du mehr Zeit damit verbringen, den Agenten zu babysitten, als du für das Schreiben des Codes selbst gebraucht hättest.

Wir haben Privatsphäre erreicht. Wir haben Geschwindigkeit erreicht. Jetzt warten wir darauf, dass sich die „Intelligenzlücke“ schließt – oder wir schauen uns nach Dual-GPU-Setups um.