AI Coding auf privater Hardware

An die Softwareentwicklung mit KI habe ich mich inzwischen ziemlich gewöhnt, entsprechend nutze ich das auch gerne für meine privaten Projekte. Aufgrund der Abo-Kosten und Anfragen-Limitierungen in der Cloud habe ich versucht auf eigener Hardware ein ähnliches Setup aufzubauen. Es funktioniert allerdings nicht, für sinnvolle Programmierfähigkeiten braucht es deutlich größere Modelle als meine (oder bezahlbare) Hardware hergeben kann. Ein Erfahrungsbericht mit eingestreutem Hintergrundwissen.

Motivation

Softwareentwicklung mit KI ist inzwischen auf einem Niveau, das wirklich gut nutzbar ist. Auch wenn man die großen Entscheidungen weiterhin selbst treffen sollte, kann einem die KI große Menge an repetitiven Aufgaben abnehmen. Relativ klar ersichtliche Fehler kann KI auch schon reparieren. Die ganze großen KI-Modelle können sogar schwerere Dinge lösen.

Die Privatkunden-Flatrates haben immer eine Begrenzung der Anfragen pro Zeit. Bei intensiver Nutzung muss man eine Zwangspause einlegen, was meinen Fluss stört. Will man nicht warten, müsste man auf ein teureres Abo oder gar Abrechnung per Token umsteigen. Letzteres würde allerdings schnell kostspielig werden. Ich habe ja eine Gaming-Grafikkarte hier und weiß von meinem Beruf her, wie man diese Modelle startet und nutzt. Daher hatte ich die Idee, das ganze einmal zuhause zu betreiben.

Ich hatte die Hoffnung, zumindest halbwegs an Claude Code rankommen zu können. Das tut es allerdings nicht, bei weitem nicht. Aber ich hatte ein paar Tage nerdigen Spaß und habe noch mehr Gefühl für die Modelle gewonnen. Das möchte ich nun teilen, auch wenn es kein tolles Ergebnis am Ende hat.

Verfügbare Hardware

Zuerst eine Bestandsaufnahme der Hardware, da sie bestimmt, welche Modelle ich laufen lassen kann. Mein privates Laptop bringt das hier mit:

Laptop:
CPU: Intel Core i5-10210U (4 Kerne) 4.20 GHz
RAM: 16 GB
GPU: Intel UHD Graphics 1.10 GHz

Die Intel-Grafikkarte kann man letztlich vergessen, auch wegen mangelndem Softwaresupport. Somit bleibt da eine CPU und 16 GB RAM. Das ist schon etwas mau für derartige Modelle.

Dann habe ich noch einen Gaming-Rechner, der etwas besser ausgestattet ist:

Gaming-PC:
CPU: AMD Ryzen 7 5700X (8 Kerne) 4.6 GHz
RAM: 32 GB
GPU: AMD Radeon RX 7700 XT 12 GB

Auf der Grafikkarte habe ich 12 GB, das ist nicht so wirklich viel im Bereich Maschinenlernen. Der RAM auf dem Mainboard sind 32 GB, dann haben wir aber nur die CPU zum Rechnen. Auch nicht so toll.

Modellauswahl

Es gibt von vielen Firmen und Forschungsgruppen frei verfügbare Modelle. Diese kann man sich über diverse Plattformen herunterladen und dann auf seiner eigenen Hardware nutzen. Manche sind auch für kommerzielle Nutzung freigegeben, andere nicht.

Bekannte offene Modellfamilien:

• Qwen von Alibaba
• Gemma von Google
• Devstral von Mistral
• GPT-OSS von OpenAI
• DeepSeek von DeepSeek

Ich habe mit der Qwen-Familie angefangen, weil es die in vielen verschiedenen Größen und Varianten gibt.

Die aktuellste Variante ist das Qwen 3.6. Der Vorgänger war Qwen 3.5, davor gab es Qwen 3. Aber bleiben wir mal bei Qwen 3.6, der aktuellsten Variante. Das gibt es einmal in der Variante 27B und 35B-A3B.

Eine Liste mit Modellen findet man zum Beispiel bei Ollama.

Modellgrößen

Alle diese Large Language Models basieren auf der Transformer-Architektur, die 2017 veröffentlicht worden ist. Es haben sich seitdem nur noch Details und eben die Größe verändert. Man kann, einfach gesagt, ein Modell immer größer machen und es kann mehr lernen. Macht man es kleiner, braucht es weniger Arbeitsspeicher und kann schneller benutzt werden.

Eine Variation ist Mixture of Experts (MoE). Dabei sind nicht immer alle Parameter im Modell aktiv, vielmehr ist immer nur eine kleine Teilmenge aktiv. Je nach Thema wählt das Modell selbst aus, welchen Teil von sich es nutzt. Diese Modelle brauchen zwar Arbeitsspeicher für alle Parameter, jedoch müssen sie bei der Berechnung nur die aktiven Parameter durchnudeln.

Das Modell mit Größe 27B hat also 27 Milliarden (billion) Parameter. Das 35B-A3B hingegen hat 35 Milliarden Parameter insgesamt, davon sind aber nur immer 3B aktiv, es ist also ein MoE-Modell.

Diese Nomenklatur findet sich bei allen Modellen.

Speicherbedarf

Die Parameter kann man nun mit unterschiedlich vielen Nachkommastellen im Arbeitsspeicher haben. Ich komme aus der Computerphysik, da haben wir 64-Bit genutzt. Computergrafik und -spiele nutzt 32-Bit. Pixar rechnet die Filme mit 24-Bit. Maschinenlernen hat zwar mit 32-Bit angefangen, jedoch hat man irgendwann Hardware mit 16-Bit gebaut, weil das schon ausreicht. Tatsächlich wurde dann Hardware (NVIDIA Hopper) mit 8-Bit gebaut, danach (NVIDIA Blackwell) kam 6-Bit und 4-Bit.

Wenn man jeden Parameter mit weniger Präzision vorhält, passen mehr Parameter in den vorhandenen Arbeitsspeicher. Und doppelt so viele Parameter mit halber Präzision sind meist eine bessere Wahl, daher auch das Rennen zu immer weniger Präzision.

Ein weiterer Vorteil von weniger Präzision ist die Speicher-Bandbreite in der Grafikkarte. Die ist zwar schnell, aber für jedes einzelne Token müssen alle (aktiven) Parameter einmal komplett durchgenudelt werden. Meine RX 7700 XT hat 12 GB Speicher, die mit 432.0 GB/s angebunden sind. Somit dauert es 28 ms, bis der einmal durch ist. Das klingt erstmal schnell, jedoch limitiert das bei einem die Grafikkarte ausfüllenden Modell direkt auf maximal 37 Token/s.

Neben den Parametern des Modells braucht man auch noch Grafikspeicher für die Aktivierungen und den Key-Value-Cache, in dem der Kontext gespeichert wird.

Man hat also drei Stellschrauben:

1. Modellgröße
2. Präzision (Quantisierung)
3. Kontextlänge

Aktualität

Die Modelle sind insgesamt über die letzten Jahre generischer geworden. Auch ist das Reasoning (auch »Thinking« oder »chain-of-thought« genannt) populär geworden. Alte Modelle haben das nicht, das ist ein Nachteil.

Zudem haben sich sehr spezialisierte Modelle als weniger geeignet gezeigt um den Coding-Anforderungen wie dem Nutzen von Werkzeugen (»tool calling«) gerecht zu werden.

Entsprechend sind die alten Qwen 2.5 und Qwen 3 raus. Die Gemma-4-Modelle sind vielleicht noch ganz okay, aber Modelle wie Starcoder, Phi-4 oder andere sind damit dann raus.

Kandidaten

Für meine Grafikkarte sehr interessant sind diese Modelle:

• Qwen 3.5-9B in 8-Bit oder 4-Bit
• Qwen 3.5-4B in 16-Bit, 8-Bit oder 4-Bit
• Gemma 4 12B in 4-Bit
• Gemma 4 E4B in 8-Bit

Diese werden wir im weiteren Verlauf anschauen.

Modelle bereitstellen

Nun muss ich das Modell irgendwie bereitstellen. Dazu habe ich unter Linux Ollama genutzt, das im Hintergrund dann llama.cpp nutzt. Das ist so eine Enthusiasten-Software. Im Profibereich wird vLLM, TensorRT-LLM oder SGLang eingesetzt, aber das ist hier nicht die Anforderung.

Ollama unter Linux

Ich habe mir Ollama per Snap installiert, damit es einen sinnvollen Platz bekommt, mit Updates versorgt wird und ich es auch wieder loswerden kann.

sudo snap install --classic ollama

Dann kann man den Server starten:

ollama serve

Dann kann man ein Modell herunterladen, hier einmal das Qwen 3.5-4B 4-Bit:

ollama pull qwen3.5:4b-q4_K_M

Erster Test

Nun kann ich dem Modell einmal etwas zu tun geben:

ollama run qwen3.5:4b-q4_K_M "What's the solution to Project Euler 1?" --verbose

Das hat zwar eine Weile gedauert, aber dann bekam ich die Antwort:

Thinking...
Okay, the user is asking "Hello, who are you?" I need to identify myself. I'm Qwen3.5, 
the latest large language model developed by Tongyi Lab. I should introduce my 
capabilities clearly but concisely. Let me make sure to mention key features like the 
256K context window, multilingual support, and specialized domains like code generation 
or medical advice. Keep the tone friendly and professional.
...done thinking.

Hello! I'm **Qwen3.5**, the latest large language model developed by Tongyi Lab. I'm 
designed to assist with a wide range of tasks, from answering complex questions and 
writing stories to analyzing data and generating code. I support over 100 languages, 
handle ultra-long context (up to 256K tokens), and excel in specialized domains like 
healthcare, law, and science. What would you like to explore today? 😊

total duration:       1m25.993022955s
load duration:        11.67495129s
prompt eval count:    16 token(s)
prompt eval duration: 4.087652535s
prompt eval rate:     3.91 tokens/s
eval count:           186 token(s)
eval duration:        1m7.320809967s
eval rate:            2.76 tokens/s

Wir sehen schon hier, dass mein Laptop wirklich langsam unterwegs ist. Es hat unter 3 Token pro Sekunde erzeugt. Bei den zehntausenden Tokens, die AI Coding in kurzer Zeit erzeugt, wäre das nicht nutzbar. Wir brauchen also definitiv eine Grafikkarte.

LM Studio unter Windows

Auf meinem Spielerechner ist nur Windows installiert. Das ist aber nicht weiter schlimm, mit LM Studio kann man auch dort ein LLM auf der Grafikkarte betreiben und per OpenAI-kompatibler API übers Netzwerk anbinden.

Das ganze sieht dann so aus, wenn der Server läuft und arbeitet:

Man muss ein bisschen aufpassen, wie viel Kontextlänge man erlaubt. Ich habe hier nur 50.000 Tokens erlaubt, damit passt das Qwen 3.5-9B in meine 12 GB Grafikkarte.

OpenCode als Orchestrator

Das LLM alleine kann man jetzt im Chat-Modus nutzen, aber das ist zum Programmieren nicht wirklich mehr der Stand der Technik. Man nutzt inzwischen Orchestratoren wie Claude Code (Anthropic) oder Codex (OpenAI), die auf dem Rechner dann auch Dateien einlesen und Kommandos ausführen können.

Das Grundprinzip ist schnell erklärt: Man stellt dem LLM eine Frage. Dann erzeugt es eine Antwort, die aber auch speziell formatierte Aufrufe von vordefinierten Funktionen enthält. So kann es dann etwas tun wie read_file("path/to/file.py") oder Dateien aktualisieren oder auch Bash-Kommandos ausführen. Der Orchestrator führt das Kommando aus und gibt dem LLM die Ausgabe als neue Eingabe mit. Das LLM verarbeitet das und überlegt sich die nächsten Schritte.

Ein offener Orchestrator ist OpenCode:

Damit das Teil mit meinem Gaming-Rechner kommuniziert, musste ich mit einer Konfigurationdatei in ~/.config/opencode/opencode.jsonc meine LM-Studio-Instanz eintragen:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (mu-vibrant)",
      "options": {
        "baseURL": "http://192.168.50.222:1234/v1"
      },
      "models": {
        "qwen/qwen3.5-9b": {
          "name": "Qwen 3.5 9B",
          "limit": {
            "context": 50000,
            "output": 8192
          }
        }
      }
    }
  }
}

Und dann konnte es auch schon losgehen. Ich habe das Teil erstmal eine einfache Frage gestellt.

Es brauchte hier 2:25 Minuten, bis die Antwort wirklich da war. Das lag am Hochfahren des Modells auf dem Gaming-Rechner.

Weitere Fragen gingen dann aber schon schneller. Hier waren es 8 Sekunden für eine Folgefrage.

Mit Code und Tool-Calls sieht es dann so aus:

Das ist von der Idee her wie Claude Code oder OpenAI Codex, nur eben quelloffen und mit allen möglichen Modellen nutzbar.

Experiment mit Programmieraufgabe

Wir haben jetzt ein LLM auf dem Gaming-PC laufen und den Orchestrator auf meinem Laptop. Nun müssen wir das ganze mit einem realistischen Beispiel ausprobieren.

Ich habe mir einen einfachen Fehlerbericht von meinem Hobbyprojekt genommen und das Modell angewiesen das zu lösen. Das hier ist der Prompt, den ich genutzt habe.

Please look into https://github.com/martin-ueding/geo-activity-playground/issues/450. The user wants the display of the buttons in the geo_activity_playground/webui/templates/activity/show.html.j2 template to be only shown when one is logged in. Please make the display conditional on login status.

Im Anschluss habe ich die Modelle dann noch gebeten einen Changelog-Eintrag zu schreiben.

Das Experiment habe ich dann mit verschiedenen Modellen ausprobiert und mir die Ergebnisse angeschaut. Bewertet habe ich dabei einerseits wie selbstständig das Modell die Aufgabe löst und andererseits wie schnell das ganze war.

Messergebnisse

Als ich die Aufgabe Claude Sonnet gegeben hatte, wurde sie innerhalb von ein paar Minuten korrekt gelöst. Ich musste gar nicht mehr in den Code schauen, so viel gute Erfahrungen habe ich damit bisher gesammelt.

Die hier getesteten Modelle haben häufig einen typischen Fehler gemacht. Sie haben angenommen, dass eine Variable im Template verfügbar ist, obwohl sie nur in anderen Templates verfügbar ist. Bei genauerer Betrachtung kann man das merken und die Variable noch in das Template übergeben.

Das hier sind die getesteten Modelle auf meiner Grafikkarte:

Interpretation

Die 4B-Klasse hat noch nicht einmal das Problem richtig verstehen können. Das ist schlicht unbrauchbar.

Die 9B-Klasse hat so gerade das Problem verstehen können. Manche der Modelle können das etwas besser als die anderen. Nachhelfen musste man aber trotzdem noch mehr oder weniger. Zudem ist die Inferenz auf meiner Grafikkarte einfach zu langsam, um nützlich zu sein. Da kann ich das schneller per Hand machen, so langsam ist das.

Claude Sonnet fühlt sich deutlich befriedigender an, da kommt keines der getesteten Modelle ran.

Kosten

Die Kostenrechnung erübrigt sich eigentlich, weil es nicht nutzbar ist.

Mein Gaming-Rechner verbraucht im Leerlauf 160 W. Ist die Grafikkarte entsprechend ausgelastet, sind es zwischen 280 und 320 W. Nehmen wir mal 300 W als Durchschnittsleistung. Bei grob 30 ct/kWh sind das dann 9 ct/h für den Betrieb.

Angesichts der ungefähr 20 EUR/Monat für ein Claude Pro oder Cursor Individual Lizenz wäre der Break-Even-Point mit den Stromkosten bei 7 Stunden pro Kalendertag. Da ich den Rechner so lange nicht laufen lassen würde, wäre der Eigenbetrieb günstiger.

Wir können auch die Kosten pro 1 Million Token (MTok) ausrechnen. Nehmen wir das Qwen 3.5 9B, das in der Eingabe 55 Token/s und in der Ausgabe 13 Token/s geschafft hat. Rechnen wir das auf die Stunde hoch und teilen den Strompreis dadurch, ergibt das dann 0,45 EUR/MTok in der Eingabe und 1,92 EUR/MTok in der Ausgabe.

Das ist also im Vergleich zu dem, was bei der Bedarfsabrechnung diverser Modell-Anbieter fällig wird, sogar mehr als das anscheinend vergleichbar kleinen GPT-5-nano. Das liegt wohl vor allem an der guten Skalierbarkeit von LLM-Inferenz auf großen Servern. Es ist fast egal, ob man 10 oder 100 parallele Anfragen abarbeitet, die Latenz bleibt ähnlich. Entsprechend ist es auch total ineffizient nur eine parallele Anfrage zu bearbeiten.

Bessere Grafikkarten

Hätte ich eine dickere Grafikkarte, könnte ich auch größere Modelle wie das Qwen 3.6 35B-A3B oder das Qwen 3.6 27B lokal laufen lassen. Die wären wahrscheinlich noch immer deutlich unter Claude Sonnet Niveau, aber besser als das, was ich bisher getestet habe.

Für so ein Modell der 30B-Klasse braucht es mindestens 24 GB RAM. Und die sind nur in den Spitzenmodellen verfügbar:

Also das ist auch keine sinnvolle Option, weil die Anschaffung 50 Monate Abokosten wären und ich nur ein schlechteres Modell hätte.

Fazit

Ich habe anhand eines konkreten Fehlerberichts für mein Hobbyprojekt verschiedene kleine KI-Modelle zusammen mit OpenCode auf meiner Hardware laufen lassen. Dabei haben sich jene Modelle als zu klein und schlecht für diese Aufgabe herausgestellt.

Selbst mit einer einzelnen High-End-Grafikkarte kommt man nur in die Region von 30B bis vielleicht 50B, die noch weit von Claude Sonnet (bestimmt mehr als 500B) entfernt sind.

Somit ist der Eigenbetrieb einfach keine realistische Option und man kommt um ein Cloud-Abo nicht herum.