Lokales LLM fürs Code-Review

FAQ

Kann man Code-Prüfung mit einem lokalen LLM betreiben - und welche Hardware braucht man?

Ja, auf drei realistischen Stufen (Stand Juli 2026): 8-12 GB VRAM fahren 7-8B-Coder-Modelle - brauchbar für fokussiertes Review auf Diff-Ebene; 16 GB fahren die 14B-Klasse komfortabel. 24 GB (RTX-3090/4090-Territorium) fahren quantisierte 32B-Klasse-Modelle wie Qwen3 32B - dort fühlt sich lokales Review nach einer ernsthaften zweiten Meinung an. Unter 8 GB ist das ehrliche Setup: deterministische Checks plus ein sehr kleines Modell für Zusammenfassungen. Nur-RAM funktioniert, ist aber so langsam, dass es die Nutzung verändert.

Welche Modelle lohnen sich fürs lokale Code-Review?

Die Qwen-Coder-Familie war 2026 die konsistente Empfehlung über alle Größen in Community-Tests - Qwen 2.5 Coder 7B auf der Einstiegsstufe, die Qwen3-Generation bei 14B und 32B darüber. Der praktische Rat altert absichtlich schnell: Prüft in der Setup-Woche ein aktuelles Leaderboard, denn die Bestes-lokales-Modell-Antwort hat sich etwa quartalsweise geändert. Was sich nicht ändert, ist die Sizing-Logik: das größte Coder-Modell, das euer VRAM bei Q4-Quantisierung mit brauchbarem Tempo fährt.

Wie schwer ist das Setup wirklich?

Die Laufzeitumgebung ist der leichte Teil: Ollama (oder llama.cpp direkt) serviert ein quantisiertes Modell mit OpenAI-kompatibler API in Minuten, und die meisten Tools mit konfigurierbarem Endpoint können darauf zeigen. Die echte Arbeit ist der Workflow darum herum. Entscheiden, was das Modell reviewt, die Anbindung an Pre-Commit oder CI, und Prompts samt Kontextgrößen in dem halten, was ein lokales Modell gut verkraftet. Plant einen Tag für eine nützliche Pipeline, keine Stunde.

Wie viel schlechter ist ein lokales Modell als ein Frontier-Modell, ehrlich?

Merklich, und die Lücke hängt an der Aufgabe. Bei fokussiertem Diff-Review mit klaren Anweisungen fängt ein lokales 32B-Coder-Modell einen soliden Anteil dessen, was zählt. Bei Langkontext-Reasoning über viele Dateien, subtilen Architektur-Implikationen und exotischen Stacks bleiben Frontier-Modelle klar vorn (Stand Juli 2026). Die ehrliche Rahmung: Lokales Review tauscht Spitzen-Einsicht gegen eine harte Datengrenze - ein Tausch, der richtig ist, wo der Code nicht reisen darf, und falsch, wo er darf.

Was trägt die Qualitätslast, wenn das Modell kleiner ist?

Struktur. Ein kleineres Modell, das gegen einen schriftlichen Auftrag mit Grenzen und Akzeptanzkriterien reviewt, schlägt seine Gewichtsklasse. Weil der schwerste Teil, nämlich zu wissen, was die Änderung tun sollte, ihm übergeben statt von ihm geraten wird. Dazu die deterministische Schicht (Typen, Tests, Linter, Build), die offline null Qualität verliert - und das lokale Setup deckt mehr ab, als seine Benchmark-Werte nahelegen. Das Modell ist die Glasur; Referenz und deterministische Checks sind der Kuchen.

Wann ist lokales LLM-Review die falsche Wahl?

Wenn euch nichts von stärkeren Optionen abhält: Erlauben eure Richtlinien Cloud-Verarbeitung für den fraglichen Code, fängt ein Frontier-Modell oder ein guter Cloud-Reviewer pro Run mehr. Lokales Review verdient seinen Platz, wo die Datengrenze die Randbedingung ist - Kundencode, regulierte Repositories, Air-Gapped-Umgebungen - oder als immer verfügbare Basisschicht ohne Kosten pro Anfrage. Es aus Ideologie statt aus Randbedingungen zu wählen endet meist in stiller Nichtnutzung.