Der Trend im Bereich Künstliche Intelligenz geht aktuell stark in Richtung mächtiger Cloud-Lösungen. Egal ob für die Code-Unterstützung im Editor oder als intelligenter Chatassistent – oft fließen die eigenen Daten direkt auf externe Server.
Ich habe mir in den letzten Wochen genauer angesehen, ob das eigentlich immer notwendig ist. Die Antwort lautet ganz klar: Nein. Lokale KI-Modelle bieten für viele Alltagsszenarien eine hervorragende und vor allem eigenständige Alternative. Allerdings ist der Weg dorthin – insbesondere wenn man die Integration selbst in die Hand nimmt – nicht immer stufenlos.
Die Idee dahinter: Warum überhaupt lokal?
Es gibt sehr pragmatische Gründe, warum man in Erwägung ziehen sollte, sogenannte Large Language Models (LLMs) auf der eigenen Hardware laufen zu lassen:
1. **Kosteneffizienz**: Externe KI-Dienste basieren meist auf Abo-Modellen
oder Pay-per-Token-Abrechnungen. Je intensiver man die KI nutzt – etwa
für das Generieren ganzer Code-Blöcke oder das ständige Refactoring –,
desto teurer wird es am Ende des Monats. Ein lokales Modell verursacht
nach der Anschaffung der Hardware keine laufenden Software-Kosten.
2. **Datenschutz**: Dies ist der wichtigste Punkt. Nicht jeder Codebaustein
oder jede Architekturfrage muss zwingend auf den Servern eines
Tech-Konzerns landen. Eine lokale KI läuft komplett auf dem eigenen
Rechner – die Daten bleiben offline und sicher.
3. **Unabhängigkeit**:
Man ist nicht auf die Verfügbarkeit von Cloud-Servern angewiesen. Wenn
das Internet streikt oder ein Dienst offline genommen wird, arbeitet
das lokale Modell unbeirrt weiter.
Die Hardwarefrage: Was braucht man wirklich?
Viele schrecken vor lokalen KIs zurück, weil sie absurde Hardware-Anforderungen befürchten. Um Lesern hier eine realistische Einschätzung zu geben: Mein Setup besteht aus einem betagten i7-8700K, 32GB RAM und einer RTX 3080 mit 12GB VRAM.
Das mag auf dem Blatt nach viel klingen, ist heute aber eher gutes Mittelfeld. Und genau hier zeigen sich die Stärken lokaler Modelle, wenn man sie richtig dimensioniert.
Lokale vs. Externe Modelle im Härtetest
Man darf sich jedoch nichts vormachen: Ein lokales Modell, das auf einer handelsüblichen Grafikkarte läuft, kann mit den "Milliarden-Parameter-Monstern" aus der Cloud nicht immer mithalten.
Die größten Unterschiede und Einschränkungen zeigen sich vor allem beim Kontext-Fenster und der Fehleranfälligkeit unter komplexen Systemarchitekturen.
Um das greifbar zu machen, habe ich ein spezifisches Python-Skript zum
Herunterladen, Entpacken und Analysieren von .zst-Dateien (von RedHat VEX)
formuliert und gegen Google Gemini sowie ein lokales Modell (Deepseek-Coder
via Open-WebUI) antreten lassen.
Der Basis-Prompt für alle Tests
Damit die Tests vergleichbar bleiben, habe ich stets exakt denselben Prompt verwendet:
Create a python script named test2.py on disk with the following functions:
open https://security.access.redhat.com/data/csaf/v2/vex/ locate the .zst file and download this as vex.tar.zst > calculate the sha256 checksum of this file and display this checksum > extract all files from this .zst archive > find the biggest file in the extracted files and show me the size in bytes > do the same for the file with the most lines > > identify the needed python packages and generate requirements.txt from the result > Create a virtual python env in the project folder > > consider finding the .zst file first on the website > check how to unpach .zst files
Der Platzhirsch: Google Gemini
Gemini hat sofort geliefert: Ein modulares Python-Skript, das sauber getrennt über requests die Webseite abfragt und zum Entpacken der .zst Datei
korrekt die externe zstandard-Bibliothek lädt. Keine Halluzinationen,
perfekter Codefluss.
Der lokale Challenger: Open-WebUI
Open-WebUI ist eine großartige, selbstgehostete Weboberfläche, die im Design und Handling stark an ChatGPT erinnert, aber im Hintergrund lokale LLMs (z. B. via Ollama) ansteuert. Es ist das perfekte Frontend für den heimischen KI-Server.
Doch wie hat sich das lokale Deepseek-Coder-Modell in Open-WebUI geschlagen?
Das Skript sah auf den ersten Blick super aus, bis zur entscheidenden
Extraktions-Zeile: with tarfile.open(file_path, "r:zstd") as tar:
Lokale Modelle fallen hier oft auf eine klassische Halluzination herein:
Das Standard-Modul tarfile in Python unterstützt out-of-the-box nämlich
gar kein natives Zstandard (.zst). Das lokale LLM war hier zu "kreativ"
und hat sich eine Funktion ausgedacht, die zwangsläufig in einem Fehler endet.
Die Prämisse lautet daher: Lokale Modelle eignen sich hervorragend für fokussierte Programmieraufgaben – sie müssen jedoch deutlich strikter kontrolliert und beim Coding stärker an der Hand genommen werden.
Geschwindigkeit und Benchmarks
Die Frage ist natürlich immer: Wie schnell ist sowas? Ich habe dazu eigene Benchmarks gefahren. Das Ergebnis mit meiner RTX 3080 (12GB):
- Ein DeepSeek Coder V2 (16B) rennt mit absolut brillanten ~208 Tokens pro Sekunde. Der generierte Code fliegt nur so über den Bildschirm.
- Selbst Modelle wie DeepSeek R1 Distill (14B) oder Llama 3.1 (8B) liefern pfeilschnelle 78 bis 140 Tokens/s.
- Aber Vorsicht: Sobald man zu große Modelle lädt, die nicht mehr komplett in die 12GB VRAM der Grafikkarte passen, bricht die Performance drastisch ein. Ein großes Qwen 2.5 Coder (32B) oder ein DeepSeek R1 (32B) muss RAM über die CPU auslagern und ruckelt dann mit eisigen ~2,5 Tokens pro Sekunde vor sich hin.
Die Lektion: Weniger Modell-Parameter bedeuten auf Standard-Rechnern oft ein wesentlich besseres und flüssigeres Coding-Erlebnis, solange das Modell in den VRAM der GPU passt!
Das Setup: VS Code Extension und das Model Context Protocol (MCP)
Um lokale Modelle wirklich produktiv in den eigenen Workflow einzubinden, habe ich mich an die Entwicklung einer eigenen VS Code Extension (Codename: llmgui) gewagt. Das Ziel: Ein lokales "Brain", das den Code versteht, mit dem ich gerade arbeite.
Die technische Grundlage dafür bot das Model Context Protocol (MCP), ein Open-Source-Standard, der von Anthropic initiiert wurde.
Was MCP ist – und was nicht
Die Idee von MCP ist großartig, aber man muss verstehen, was es eigentlich tut: * Was MCP ist: Es ist ein standardisiertes Kommunikationsprotokoll (oft über Standard I/O oder SSE/HTTP). Es definiert eine universelle Sprache, wie ein KI-Modell auf externe Werkzeuge (Tools), Dateisystemressourcen und vorberechnete Kontexte zugreifen kann. Statt für jedes LLM und jeden Editor proprietäre Schnittstellen zu bauen, spricht man MCP. * Was MCP nicht ist: MCP ist kein eigenes Sprachmodell, es führt von selbst keine Befehle aus und ist auch keine Sandbox-Laufzeitumgebung. Es ist lediglich der "Übersetzer" zwischen der KI (dem Gehirn) und den Werkzeugen (den Händen).
Wie wir MCP in llmgui einsetzen
In meiner VS Code Extension llmgui nutze ich einen eigenen, lokalen MCP-Server, der als Brücke zwischen der Benutzeroberfläche des Editors,
dem lokalen LLM und dem darunterliegenden Betriebssystem fungiert. Dieser
Server stellt der KI hochspezialisierte Werkzeuge zur Verfügung: Er erlaubt
es dem Modell, Dateien chirurgisch zu lesen und zu schreiben (view_file,
replace_file_content), Terminalbefehle auszuführen (run_command) oder
das Internet zu durchsuchen (search_web). Das LLM bittet via MCP unseren
Server darum, eine Aktion auszuführen – llmgui validiert die Anfrage,
führt sie (ggf. nach Nutzerfreigabe) aus und reicht das Ergebnis via MCP
zurück an die KI.
In der Praxis bringt MCP bei der Eigenentwicklung aber Tücken mit. Da das LLM nicht direkt im Kontext des Editors läuft, muss die gesamte JSON-RPC-Kommunikation minutiös validiert werden. Ein fehlerhaftes JSON in der Tool-Antwort? Das Modell stolpert.
Einmal vernünftig aufgesetzt, erhält man jedoch ein lokales "Brain", das aktiv mitdenkt und über eine übersichtliche Benutzeroberfläche gesteuert wird.
Über das integrierte Tool-Display lässt sich zudem jederzeit transparent nachverfolgen, welche Werkzeuge das LLM gerade initiiert.
Die Entwicklungshürden: Pfade, venv und der Editor-Kontext
Man könnte meinen, eine VS Code Extension zu schreiben sei einfach. Die Realität sah anders aus.
Der Kampf um die Projektsicht
Wenn die lokale KI ein Python-Skript ausführen soll, darf sie nicht aus Versehen das
System-Python zerschießen. Sie muss die exakte .venv des aktuellen Workspace
finden, aktivieren und die Befehle im korrekten Root-Verzeichnis ausführen.
Es erforderte umfangreiche Konfigurationen, um das Lifecycle-Management der Extension sauber zu synchronisieren, damit relative Dateipfade nicht ins Nichts führen.
Um dies alles transparent zu halten, musste auch eine saubere Dokumentationsfunktion für die Extension-Settings entwickelt werden.
Warum ein Planungsmodus bei lokalen LLMs essenziell ist
Genau hier, angesichts der Halluzinationsgefahr bei der .zst-Aufgabe,
zeigt sich, warum ein direkter Agentenmodus für lokale KIs oft fatal ist.
Im Direct Agent Mode prescht das LLM einfach vor und führt wilden Code aus.
Stattdessen nutzt man besser strukturierte Planungs- und Verfeinerungsschritte ("Planning & Refinement"). Man zwingt das System dazu, erst einmal Innezuhalten.
Die KI analysiert die Anforderung und erstellt einen strukturierten Plan, bevor sie auch nur eine Datei berührt. Dieser mehrstufige Planungs-Prozess reduziert Halluzinationen massiv.
Falls trotzdem mal Fehler im generierten Code landen, muss die Extension in der Lage sein, diese abzufangen.
Transparenz und Fallback-Lösungen
Und falls das Modell Befehle ausführen möchte, greift das Auto-Approve/Deny-System: Vor jeder sicherheitskritischen Aktion wartet das System auf Bestätigung.
Sollte das lokale Modell bei einer Mammut-Aufgabe dann doch einmal einknicken, greift ein gut konfigurierter Fallback.
Dieser Ausweg auf mächtigere, externe Dienste geschieht absolut bewusst und nur dann, wenn ich es explizit genehmige.
Ausblick & Troubleshooting: Die Tücken der Agenten
Das Setup läuft zwar hervorragend für strukturierte Befehle, aber ich habe momentan noch Baustellen im reinen Agenten-Modus offengelassen. Einen autonomen Agenten blind auf das System loszulassen, ist fehleranfällig und benötigt noch viel Finetuning bei den Prompts, Sicherheitsmechanismen und Pfad-Auflösungen. Das Feature ist vorhanden, genießt bei mir aktuell aber noch nicht das blinde Vertrauen für eine Dauerbelastung ohne den Planning-Modus.
Kurze Debugging-Tipps für die lokale KI
Falls die lokale KI sich aber doch mal komplett verhaspelt, anstatt Code auszugeben:
- Kontext flushen: Oft verliert die KI nach dutzenden Chat-Iterationen den Faden oder baut auf vorigen Halluzinationen auf. Manchmal hilft es einfach, einen harten Cut zu machen und eine neue Sitzung zu starten.
- System-Prompt schärfen: Wenn Parameter oder Formate (wie JSON) nicht eingehalten werden, muss der initiale System-Prompt strikter formuliert werden ("Answer strictly in JSON without Markdown backticks").
- Temperatur senken: Für stark strukturiertes Coding sollte die "Kreativität" (Temperature) der KI auf ein Minimum (0.0 bis 0.2) gesenkt werden, um konsistente Ergebnisse zu erzwingen.
Fazit: Eine lohnende Alternative mit Lernkurve
Der Aufbau eines performanten, lokalen KI-Workflows ist kein reiner Selbstläufer. Aber das Ergebnis spricht für sich: Die Abhängigkeit lässt sich reduzieren. Man spart Ressourcen und hat durch Werkzeuge wie den Planungsmodus selbst ein "kleineres" lokales Modell gut im Griff.
Es lohnt sich definitiv, diese Unabhängigkeit auszuprobieren.
Transparency Note: Einige Inhalte, Code-Snippets oder Grafiken in diesem Post wurden mittels KI (LLMs / Vibecoding) erstellt oder unterstützt, jedoch von mir persönlich kuratiert, überarbeitet und geprüft.