Sind lokale KI-Sprach-Modelle bereit für den Einsatz im Alltag?

KI-assistierte Programmierung ist mittlerweile im Alltag vieler Softwareentwickler angekommen. Ob Autocomplete oder autonome Coding-Agenten, solche Werkzeuge können die eigene Produktivität spürbar steigern. Die meisten von ihnen laufen jedoch über die Server von OpenAI, Anthropic, Google und ähnlichen Anbietern. Dafür zahlt man nicht nur monatliche Abonnements, sondern begibt sich auch in eine gewisse Abhängigkeit von diesen Unternehmen, ohne genau zu wissen, wohin die eigenen Daten dabei wandern. Und so unwahrscheinlich es auch sein mag, theoretisch könnte einem der Zugriff durch ein plötzliches Exportverbot verwehrt werden, sodass man von einem Tag auf den anderen ohne dasteht.

Deshalb hat mich interessiert, wie weit man mit offenen Modellen und vergleichsweise günstiger Consumer-Hardware kommt. Reicht eine einzelne Grafikkarte aus dem Gaming-Segment aus, um ein aktuelles, leistungsfähiges Modell mit brauchbarer Geschwindigkeit lokal zu betreiben? Und was noch wichtiger ist, ist das Ergebnis gut genug, um im Alltag tatsächlich eine ernsthafte Alternative zu den kommerziellen Anbietern zu sein?

In diesem Artikel möchte ich herausfinden, ob und wie ich ein aktuelles, frei verfügbares KI-Modell auf einem meiner Rechner lokal betreiben kann.

Für mein Experiment wollte ich Hardware nutzen, die ich persönlich besitze oder die im Büro frei „herumliegt”. Für meine Arbeit nutze ich hauptsächlich ein MacBook mit Apple Silicon. Daher war es naheliegend, dieses auch zur Entwicklung mit einem lokalen KI-Modell zu nutzen.

Mein Hauptrechner ist immer noch mein 16-GB-MacBook Pro M1 aus dem Jahr 2020, von dem ich mich nur schwer trennen kann. Mit diesem habe ich bereits 2023 erfolgreich ein kleines Sprachmodell zum Laufen gebracht. Damals war es noch eine abgespeckte Version von Metas offenem Llama-Modell. Obwohl es damals beeindruckend war, war es weit davon entfernt, gut genug für einen mir nützlich erscheinenden Einsatzzweck zu sein. Vieles der Infrastruktur zur Nutzung von KI-Modellen gab es noch nicht, deshalb musste ich selbst ein kleines Tool um die Inferenz-Library herum entwickeln. Ich habe damals einen kruden Prototypen entwickelt, mit dem man sich per Spracheingabe mit dem Modell unterhalten konnte und nach starker Verzögerung eine Sprachausgabe erhielt. Neben dem vergleichsweise schwachen Modell selbst lag das Problem vor allem an der zu schwachen Hardware. Dazu muss ich follgendes Erklären:

Neben schnellen parallelen Rechenkernen, wie sie z. B. eine GPU bietet, benötigt man Unmengen an Speicher mit hoher Bandbreite. Das ist im Prinzip der größte limitierende Faktor. Beim ausführen von KI Modellen werden unmengen an gelernten Parametern aus dem Speicher geladen und über Matrix multiplikationen mit vektoren die aus den eingabe (prompt) tokens erzeugt werden, verrechnet. Die ausführungsgeschwindig wird dadurch hauptsächlich dadurch begrenzt wie viele dieser Parameter pro Sekunde aus dem Speicher in den Rechenkernen der GPU geladen werden können. Für jeden erzeugten ausgabe Token muss das gesamte Modell durchlaufen werden. Damit dies überhaupt die chance hat einigermaßen performant zu sein muss das ganze Modell Vollständig in den der GPU am nächsten gelegnen Speicher passen. Im Falle von Desktop oder Server GPUs ist dies der dedizierte VRam der GPU. Im gegensatz zu CPUs deren Speicherzugriff für geringe latenz optimiert ist, sind GPUs und deren Speichersystem für hohen durchsatz ausgerichtet also ideal für diese Aufgabe.

Apple-Silicon-Macs nutzen dagegen eine sogenannte Unified-Memory-Architektur, bei der sich CPU und GPU denselben Arbeitsspeicher teilen. Damit die GPU dabei nicht ausgebremst wird, verfügt dieser gemeinsame Speicher über eine vergleichsweise hohe Bandbreite, die der eines reinen GPU-Speichers ähnelt. Für die Ausführung großer Sprachmodelle ergibt sich daraus ein Vorteil. Da es keinen separaten Grafikspeicher gibt, steht dem Modell der gesamte im Gerät verbaute Speicher zur Verfügung.

Gerade im Consumer- und Prosumer-Bereich ist das Preis-Leistungs-Verhältnis dadurch sehr attraktiv, da die verfügbare Speichermenge oft deutlich größer ist als bei bezahlbaren dedizierten GPUs. Der Nachteil liegt jedoch in der absoluten Bandbreite, die bei Highend diskreten GPUs weiterhin höher ist.

Für mein Experiment aus dem Jahr 2023 habe ich das gerade neu erschienene Llama 2 mit quantisierten 7 bzw. 13 Milliarden Parametern getestet. Diese passten gerade so in die 16 GB meines MacBooks. Generell kann man sagen, dass je größer das Modell ist, desto besser performt es in der Regel. Seit Llama 2 hat sich die Leistung der Modelle sowie die umliegende Infrastruktur jedoch stark verbessert. Neue Modelle wie Qwen können selbst in ihrer kleinen Variante alte Modelle mit deutlich mehr Parametern, z. B. Llama mit 70 Milliarden Parametern, in vielen Fällen deutlich schlagen.

Da aktuelle kommerzielle Coding-Modelle von OpenAI und Anthropic aber deutlich größer und mächtiger sind, wollte ich das derzeit (Stand Sommer 2026) beste frei verfügbare Modell in der größten Variante testen, die meine Hardware zulässt.

Testumgebung

Die für diesen Zweck beste mir zur Verfügung stehende Hardware war mein Linux-Rechner mit einer AMD Radeon 7900 XTX. Auf eine Unified-Memory-Architektur mit viel Speicher, wie vorher beschrieben, konnte ich hier nicht zurückgreifen, da mein einziges solches Gerät nur über 16 GB verfügt und damit für ein Modell dieser Größe zu wenig Speicher bietet. So blieb die dedizierte GPU mit ihren 24 GB VRAM die naheliegende Wahl. Als Betriebssystem kommt Arch Linux zum Einsatz. Die vollständigen Eckdaten finden sich in der folgenden Tabelle.

Software

Komponente	Version
Betriebssystem	Arch Linux
Kernel	7.1.2
Grafiktreiber	Mesa 26.1.4
GPU-Backend	Vulkan (RADV)
llama.cpp	b9859
ggml	0.15.3
Ollama	0.31.2

Hardware

Komponente	Details
CPU	AMD Ryzen 7950X3D (16 Kerne)
Arbeitsspeicher	64 GB DDR5 6000
GPU	AMD Radeon 7900 XTX (24 GB VRAM)

Alle Software-Komponenten habe ich direkt aus den offiziellen Arch-Repositories installiert, ohne selbst kompilieren oder auf das AUR zurückgreifen zu müssen.

Ich habe sowohl den ROCm- (Version 7.2.4) als auch das Vulkan-Backend ausprobiert, mich für die weiteren Tests aber auf Vulkan festgelegt. Warum, dazu später mehr.

Das Modell

Als Modell habe ich mich für Qwen 3.6 entschieden, derzeit eines der leistungsstärksten offenen Modelle für Coding-Aufgaben. Wie die meisten offenen Modelle wird auch Qwen nicht als eine einzelne Datei veröffentlicht, sondern in einer ganzen Reihe von Varianten. Die meisten davon findet man auf Hugging Face, der zentralen Plattform für offene Modelle, von der ich sie auch heruntergeladen habe. Bevor man sich für einen konkreten Download entscheidet, sollte man deshalb drei Dinge verstehen, in denen sich diese Varianten unterscheiden.

Größe (Anzahl der Parameter)

Am deutlichsten unterscheiden sich die Varianten in der Anzahl der Parameter, meist angegeben in Milliarden (B für „billion"). Ein Modell gibt es in der Regel in mehreren Größen, von wenigen Milliarden Parametern für schwache Hardware bis hin zu sehr großen Varianten mit mehreren Hundert Milliarden Parametern, die eher in ein Rechenzentrum gehören. Als grobe Faustregel gilt, dass ein größeres Modell bessere Ergebnisse liefert, dafür aber mehr Speicher braucht und langsamer läuft. Für die lokale Ausführung kommt es also darauf an, die größte Variante zu finden, die gerade noch vollständig in den verfügbaren Speicher passt.

Format

Dasselbe Modell wird außerdem in unterschiedlichen Dateiformaten angeboten, die jeweils für eine bestimmte Laufzeitumgebung gedacht sind:

• Safetensors enthalten die originalen Gewichte in voller Genauigkeit (meist FP16 oder BF16). Sie sind der Ausgangspunkt für die meisten anderen Formate.

• GGUF ist das Format rund um llama.cpp und wird auch von Ollama verwendet. Es steckt Gewichte und Metadaten in eine einzige Datei und ist auf effiziente Ausführung auf CPU und GPU ausgelegt. Für die lokale Nutzung auf Consumer-Hardware ist das meist die richtige Wahl.

• MLX ist ein speziell auf Apple Silicon optimiertes Format, das ich hier aber nicht weiter betrachte.

• GPTQ und AWQ sind auf GPUs zugeschnittene, bereits quantisierte Formate, die vor allem zusammen mit vLLM oder ähnlichen Servern zum Einsatz kommen.

Da ich das Modell mit llama.cpp und Ollama betreiben wollte, habe ich mich für das GGUF-Format entschieden.

Quantisierung

Ursprünglich liegen die Gewichte eines Modells mit 16 Bit pro Parameter vor. Bei der Quantisierung reduziert man diese Genauigkeit, etwa auf 8, 5 oder 4 Bit. Das verkleinert die Daten erheblich und senkt den Speicherbedarf, geht aber tendenziell zu Lasten der Qualität. Bei GGUF erkennt man die Stufe am Namen, zum Beispiel Q8_0, Q6_K, Q5_K_M oder Q4_K_M. Die Zahl steht dabei grob für die Bits pro Gewicht, die Zusätze wie _K_M bezeichnen neuere, „K-Quant" genannte Verfahren in den Ausprägungen S (small), M (medium) und L (large).

In der Praxis hat sich Q4_K_M als guter Kompromiss zwischen Größe und Qualität herausgestellt, während höhere Stufen wie Q5_K_M oder Q6_K bei genug Speicher noch etwas mehr herausholen. Sehr niedrige Stufen wie Q2_K sparen zwar am meisten Speicher, machen sich aber durch spürbare Qualitätseinbußen bemerkbar.

Statt zwangsläufig ein kleineres Modell nehmen zu müssen, kann man eine größere Variante wählen und sie so weit quantisieren, dass sie gerade noch in den vorhandenen Speicher passt. Ein stark quantisiertes großes Modell ist am Ende oft die bessere Wahl als ein kleines Modell in voller Genauigkeit.

Meine Wahl

Für meine 24 GB VRAM habe ich mich konkret für Qwen 3.6 mit 27 Milliarden Parametern im GGUF-Format und einer 4-Bit-Quantisierung entschieden. Die Datei Qwen3.6-27B-UD-Q4_K_XL.gguf ist rund 17,6 GB groß und passt damit vollständig in den Grafikspeicher, sodass noch genügend Platz für den Kontext bleibt. Das Kürzel `UD` steht dabei für die „Unsloth Dynamic" Quantisierung, bei der einzelne Schichten des Modells unterschiedlich stark quantisiert werden, um bei ähnlicher Dateigröße etwas mehr Qualität zu erhalten.

Installation

Um das Modell auszuprobieren, habe ich zwei Wege getestet. Zum einen Ollama, das den Einstieg besonders einfach macht, und zum anderen llama.cpp in Form des mitgelieferten `llama-server`, bei dem man das GGUF selbst von Hugging Face lädt und mehr Kontrolle über die Parameter hat.

Ollama

Ollama ist der bequemste Einstieg, da man sich weder um den Download der richtigen Datei noch um die passenden Parameter kümmern muss. Nach der Installation aus den offiziellen Arch-Repositories genügt ein einziger Befehl, um das Modell zu laden und direkt loszulegen:

ollama run qwen3.6:27b

Ollama lädt das passende 27B-Modell automatisch aus seiner eigenen Registry herunter und startet anschließend eine interaktive Eingabe. Im Hintergrund nutzt es dabei denselben Vulkan-Backend, sodass die Grafikkarte ohne weiteres Zutun verwendet wird.

Diese Bequemlichkeit hat allerdings ihren Preis. Man hat kaum Möglichkeiten, eine ganz bestimmte Variante auszuwählen, etwa eine konkrete Quantisierungsstufe wie das oben genannte Q4_K_XL. Ollama entscheidet weitgehend selbst, welche Version es lädt. Auch beim Konfigurieren hat man deutlich weniger Freiheit als bei llama.cpp, wo sich nahezu jeder Parameter direkt über die Kommandozeile steuern lässt. Für einen schnellen Einstieg ist das kein Problem, wer aber gezielt eine bestimmte Variante mit bestimmten Einstellungen betreiben möchte, stößt hier schnell an Grenzen.

Anfangs war mir gar nicht bewusst, dass die Standardeinstellungen zu Problemen führen konnten. Als das Modell plötzlich mittendrin abbrach, habe ich zunächst nicht verstanden, woran das lag. Erst nach einiger Suche wurde mir klar, dass das Kontextfenster bei Ollama standardmäßig nur 4096 Tokens groß ist. Für ein Chat-Gespräch reicht das, für einen Coding-Agenten ist es jedoch viel zu klein.

Beheben lässt sich das über die Umgebungsvariable OLLAMA_CONTEXT_LENGTH. Damit Ollama zusätzlich im Netzwerk erreichbar ist, habe ich außerdem OLLAMA_HOST gesetzt und den Server anschließend manuell gestartet:

OLLAMA_HOST=0.0.0.0 OLLAMA_CONTEXT_LENGTH=65536 ollama serve

Damit lauscht Ollama auf allen Netzwerkschnittstellen und nutzt ein Kontextfenster von 64k Tokens. Auch wenn sich das Problem so lösen lässt, war es einer der Gründe, warum ich für die eigentlichen Tests auf llama-server gesetzt habe, wo ich das Kontextfenster von Anfang an explizit auf denselben Wert gesetzt hatte.

Ollama bietet auch an, Tools wie opencode oder VS Code direkt aus Ollama heraus zu starten und anzubinden. Das fand ich zwar praktisch gedacht, hat aber nicht so recht in meinen Workflow gepasst, weshalb ich die Tools weiterhin lieber selbst gestartet und manuell an den Server angebunden habe.

llama.cpp (llama-server)

Der zweite Weg führt über llama.cpp, das ebenfalls fertig in den Arch-Repositories vorliegt. Hier lädt man das GGUF zunächst selbst von Hugging Face herunter, in meinem Fall die weiter oben beschriebene Datei Qwen3.6-27B-UD-Q4_K_XL.gguf. Anschließend startet man den mitgelieferten llama-server, der eine OpenAI-kompatible API bereitstellt:

llama-server -m Qwen3.6-27B-UD-Q4_K_XL.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 99 \
  -c 65536 \
  --jinja \
  --batch-size 2048 \
  --ubatch-size 1024 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --temp 0.6 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0 \
  --flash-attn on

Die einzelnen Optionen im Überblick:

• `-m` gibt den Pfad zur heruntergeladenen GGUF-Datei an.

• `--host 0.0.0.0` und `--port 8080` machen den Server im gesamten lokalen Netzwerk erreichbar, was später für die Remotenutzung wichtig wird. Die Weboberfläche und die OpenAI-kompatible API erreicht man anschließend z.b unter http://localhost:8080.

• `-ngl 99` (kurz für --n-gpu-layers`) lagert alle Schichten des Modells auf die GPU aus, was bei ausreichend VRAM für die beste Geschwindigkeit sorgt.

• `-c 65536` setzt das Kontextfenster auf 64k Tokens, was für längere Coding-Sessions mit viel Kontext angenehm ist.

• `--jinja` aktiviert die im Modell hinterlegte Chat-Vorlage (Jinja-Template). Das sorgt für die korrekte Formatierung der Prompts und ist unter anderem für die Nutzung von Tools bzw. Function Calling notwendig.

• `--batch-size 2048`und `--ubatch-size 1024` steuern, wie viele Tokens beim Verarbeiten des Prompts auf einmal berechnet werden, und beeinflussen die Geschwindigkeit der Prompt-Verarbeitung.

• `--cache-type-k q8_0` und `--cache-type-v q8_0` quantisieren den KV-Cache auf 8 Bit. Dadurch braucht das große Kontextfenster weniger VRAM, ohne die Qualität spürbar zu beeinträchtigen.

• `--temp 0.6`, `--top-k 20`, `--top-p 0.95` und `--min-p 0` sind die Sampling-Parameter. Sie entsprechen den von Qwen empfohlenen Einstellungen und bestimmen, wie „kreativ" bzw. deterministisch das Modell antwortet.

• `--flash-attn on` aktiviert Flash Attention, eine speicher- und rechenzeiteffizientere Implementierung des Attention-Mechanismus.

OpenCode

Als ersten echten Test wollte ich sehen, wie sich das Modell in einem realen, agentischen Coding-Workflow schlägt. Dafür habe ich Opencode genutzt, einen terminalbasierten Coding-Agenten, der sich statt an einen kommerziellen Anbieter auch an einen lokalen Server anbinden lässt.

Als Testprojekt habe ich einen kleinen Bildkonverter in C gewählt, den ich vor Jahren als Student geschrieben habe (Quellcode auf GitHub). Das Projekt besteht aus einer Library, die das proprietäre Bildformat des Echtzeit-Strategiespiels Stronghold einliest, und einem darauf aufbauenden Programm, das die Spielgrafiken in PNG-Dateien umwandelt und die zugehörigen Metadaten als JSON ablegt. Für einen Test ist dieses Projekt für mich interessant. Damals habe ich kaum Rücksicht auf Sicherheit genommen, und der in C geschriebene Code ist mit hoher Wahrscheinlichkeit voll von Bugs und Sicherheitslücken. Umso mehr hat mich interessiert, was das Modell darin findet und welche Verbesserungen es vorschlägt.

opencode lässt sich über JSON-Dateien konfigurieren. Dabei gibt es zwei Ebenen. Eine globale Konfiguration gilt für alle Projekte, während sich zusätzlich pro Projekt eine eigene Konfigurationsdatei im jeweiligen Projektverzeichnis anlegen lässt, die die globalen Einstellungen ergänzt oder überschreibt. Da mein llama-server eine OpenAI-kompatible API bereitstellt, habe ich ihn in meiner globalen Konfiguration als eigenen Provider über den Adapter @ai-sdk/openai-compatible eingebunden und auf die lokale Adresse http://localhost:8080/v1 verwiesen. Wichtig ist dabei, für das Modell tool_call zu aktivieren, damit opencode die Werkzeuge zum Lesen und Bearbeiten von Dateien nutzen kann.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama-cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LlamaCPP Server",
      "options": {
        "baseURL": "http://localhost:8080/v1"
      },
      "models": {
        "qwen-27b": {
          "name": "qwen-27b",
          "tool_call": true
        }
      },
      "permissions": {
        "*": "ask",
        "edit": "ask",
        "read": {
          "*": "allow",
          "*.env": "deny",
          "*.env.*": "deny",
          "*.env.example": "allow"
        }
      }
    }
  }
}

Über den “permissions” Block lege ich zudem fest, was der Agent ohne Rückfrage tun darf. Standardmäßig soll opencode bei jeder Aktion nachfragen (`"*": "ask"`), Bearbeitungen von Dateien muss ich ebenfalls bestätigen (`"edit": "ask"`). Beim Lesen von Dateien bin ich großzügiger und erlaube den Zugriff generell, sperre aber “.env” Dateien. Diese Ausnahme für “.env” Dateien wird so auch in der Dokumentation von opencode als Beispiel vorgeschlagen und sorgt dafür, dass keine Zugangsdaten oder Secrets versehentlich an das Modell gelangen.

Die Berechtigungen lassen sich auch für einzelne Kommandozeilen-Tools separat festlegen. So kann man dem Agenten etwa erlauben, harmlose Befehle wie `ls` oder `git status` ohne Rückfrage auszuführen, während potenziell gefährliche Kommandos weiterhin eine Bestätigung erfordern.

Ist die Konfiguration erledigt, ist die Nutzung denkbar einfach. Man wechselt im Terminal in das gewünschte Projektverzeichnis und startet opencode mit dem Befehl opencode. Es öffnet sich eine textbasierte Oberfläche, in der man dem Modell wie in einem Chat Anweisungen geben kann, etwa den Code zu analysieren, einen Fehler zu suchen oder eine Änderung umzusetzen. Der Agent liest daraufhin selbstständig die relevanten Dateien, schlägt Änderungen vor und führt bei Bedarf Kommandos aus, wobei er sich je nach gesetzten Berechtigungen vorher eine Bestätigung einholt.

Wer Claude Code kennt, findet sich schnell zurecht, denn opencode kennt viele ähnliche Slash-Commands. Mit `/init` lässt sich zum Beispiel eine AGENTS.md erzeugen, in der opencode das Projekt analysiert und die wichtigsten Informationen für den Agenten für zukünftige sessions zusammenfasst.

Opencode nach dem Start im Projektverzeichnis. Unten ist zu sehen, dass als Modell das lokale qwen-27b über den LlamaCPP Ser

Als konkrete Aufgabe habe ich das Modell gebeten, den Code nach kritischen Fehlern zu durchsuchen. Das Ergebnis hat mich positiv überrascht. Qwen hat eine ganze Reihe echter Bugs und Sicherheitslücken gefunden und dabei jeweils die betroffene Datei und Zeilennummer genannt. Die Verarbeitung dauerte allerdings ihre Zeit, auf die Geschwindigkeit gehe ich weiter unten noch genauer ein.

Ich habe dabei mehrere Durchläufe ausprobiert und zwischendurch immer wieder an den Parametern des `llama-server` geschraubt. Die folgenden Screenshots stammen deshalb nicht zwingend alle aus demselben Lauf.

Die vom Modell gefundenen Probleme, geordnet nach Schweregrad und jeweils mit konkreter Fundstelle im Code.

Anschließend habe ich das Modell gebeten, die gefundenen Probleme zu beheben. Es hat die Änderungen selbstständig umgesetzt, das Projekt neu kompiliert und den erfolgreichen Build verifiziert. Zum Abschluss fasst es die vorgenommenen Korrekturen übersichtlich in einer Tabelle zusammen.

Nach den Korrekturen fasst opencode die Fixes tabellarisch zusammen und bestätigt einen sauberen Build.

Remotenutzung mit VSCode

Bis hierhin lief alles direkt auf dem Linux-Rechner. Für meine tägliche Arbeit nutze ich aber vor allem mein MacBook, und dort läuft kein Modell dieser Größe lokal. Deshalb wollte ich das Modell zusätzlich remote testen, also den Server weiterhin auf dem Linux-Rechner ausführen, aber vom MacBook aus über VS Code darauf zugreifen. Genau aus diesem Grund hatte ich sowohl llama-server als auch Ollama von Anfang an mit `0.0.0.0` als Listen-Adresse gestartet, damit sie im lokalen Netzwerk erreichbar sind.

Theoretisch sollten sich beide Server über die in VS Code integrierte Copilot-Erweiterung anbinden lassen, die eine Konfiguration eigener, OpenAI-kompatibler Endpunkte erlaubt. In der Oberfläche war diese Möglichkeit allerdings als veraltet (deprecated) markiert, sodass ich mich nicht darauf verlassen wollte.

Bei der Suche nach einer Alternative bin ich in der Ollama-Dokumentation auf eine offizielle VS-Code-Erweiterung von Ollama gestoßen. Damit ließ sich die Verbindung zu meinem entfernt laufenden Ollama-Server problemlos herstellen. Diese Erweiterung konnte ich allerdings nur mit Ollama verbinden und nicht mit dem `llama-server`.

Performance-Eindruck

Bei der Geschwindigkeit lagen Ollama und llama-server dicht beieinander. Beide verarbeiteten je nach Aufgabe zwischen 35 und 45 Tokens pro Sekunde. Für ein Chat-Gespräch ist das mehr als flüssig, und auch für einen Coding-Agenten war es gut nutzbar, auch wenn man bei längeren Antworten etwas warten muss. An die Geschwindigkeit der kommerziellen Anbieter, die ihre Modelle auf viel leistungsstärkerer Datacenter Hardware betreiben, kommt man damit natürlich nicht heran.

Hier komme ich auch auf die weiter oben offengelassene Frage nach dem Backend zurück. In meinen Tests war das Vulkan-Backend etwas schneller als ROCm. Das war letztlich der Grund, warum ich mich für die weiteren Tests auf Vulkan festgelegt habe.

Während der Inferenz war die Grafikkarte durchgehend zu 99 % ausgelastet. Entsprechend stieg der Stromverbrauch. Im Leerlauf zog mein System (inklusive Bildschirme) rund 200 Watt, unter Last waren es fast 600 Watt. Für einzelne Anfragen ist das kein Problem, wer ein solches Modell aber dauerhaft laufen lassen möchte, sollte den Verbrauch und die damit verbundene Abwärme und Lautstärke nicht unterschätzen.

Fazit

Bleibt zum Schluss noch die Frage vom Anfang: Sind lokale KI-Modelle bereit für den Einsatz im Alltag? Nach meinem Experiment würde ich "Jein" sagen.

Ein Modell in einer Größe, die auf Consumer-Hardware läuft, ist keine direkte Konkurrenz zu den aktuellen großen Modellen von OpenAI oder Anthropic. Für echtes „Vibe Coding", bei dem man dem Agenten ganze Features überlässt und ihn möglichst eigenständig arbeiten lässt, reicht es nicht. Dafür sind die kommerziellen Modelle einfach zu weit voraus. Als Hilfe für konkrete Aufgaben ist ein lokales Modell aber durchaus brauchbar. In meinem alten C-Projekt hat Qwen echte Bugs und Sicherheitslücken aufgespürt, jeweils mit Datei und Zeilennummer benannt und sinnvolle Fixes vorgeschlagen. Genau darin sehe ich den größten Nutzen, nämlich als zusätzliches Werkzeug, um Fehler zu finden und Verbesserungen vorzuschlagen. Auch für kleinere Code-Generierungsaufgaben lässt es sich gut einsetzen, und als Hilfe, um sich in Codebasen zurechtzufinden, die man kaum kennt. Dass die eigenen Daten dabei den Rechner nicht verlassen und keine laufenden Kosten anfallen, kommt noch dazu.

Ein Punkt, der bei der reinen Betrachtung von Geschwindigkeit und Qualität leicht untergeht, ist der Dauerbetrieb. Eine Grafikkarte, die ein großes Modell auslastet, zieht spürbar Strom und wird entsprechend laut. Für einzelne Aufgaben zwischendurch ist das kein Problem, für einen dauerhaft mitlaufenden Assistenten finde ich die Lautstärke und den Energieverbrauch allerdings etwas problematisch.

Unabhängig davon war ich aber echt beeindruckt, was ein „persönlicher" Gaming-PC leisten kann. Dass auf der gleichen Hardware, die sonst für Spiele da ist, ein aktuelles Modell lokal läuft und wirklich brauchbare Arbeit macht, hätte ich vor ein paar Jahren nicht gedacht. Und wenn man bedenkt, wie groß der Sprung seit Llama 2 im Jahr 2023 war, bin ich gespannt, was die Zukunft noch bringt.