Lokale Modelle einbinden: Ollama, llama.cpp und vLLM im Editor und im Agenten

Artikel-Übersicht

Ein lokales Modell zu starten dauert fünf Minuten. Es dazu zu bringen, dass ein Coding-Agent damit über zwanzig Werkzeugaufrufe hinweg sauber arbeitet, dauert deutlich länger — und genau dieser Teil fehlt in den meisten Anleitungen. Sie enden bei „das Modell antwortet", und zwei Tage später sitzt man vor einem Agenten, der ohne Fehlermeldung im Kreis läuft.

Dieser Artikel setzt dort an, wo die anderen aufhören. Er geht davon aus, dass du dich für ein Modell entschieden hast — im Zweifel Qwen3.8-27B, die Begründung dazu steht in Qwen3.8-27B gegen die Cloud — und dass eine Laufzeitumgebung installiert ist. Was hier folgt, sind die Schritte dazwischen: die richtige Laufzeitumgebung für deinen Zweck, die Startbefehle mit den Parametern, die tatsächlich zählen, die drei Einstellungen, an denen fast jedes Setup scheitert, und die konkrete Anbindung an Cline, Continue, Aider und Claude Code.

Wenn du bei der Installation stehst, fang bei Ollama installieren an; die Grundlagen zur Laufzeitumgebung und ihrer API stehen in Ollama: lokale Sprachmodelle betreiben, die Auswahl nach Speicherklasse in Welches Ollama-Modell?. Hier geht es ausschließlich um den Weg vom laufenden Modell zum arbeitenden Agenten.

Welche Laufzeitumgebung wofür

Die Wahl der Laufzeitumgebung entscheidet nicht über die Qualität der Antworten, sondern darüber, wie viel Kontrolle und wie viel Durchsatz du bekommst. Alle drei laden dieselben Gewichte und liefern eine OpenAI-kompatible Schnittstelle; sie unterscheiden sich in Bedienkomfort, Speicherverhalten und Mehrbenutzerfähigkeit.

	Ollama	llama.cpp	vLLM
Einrichtung	in Minuten	Kompilieren oder Binary	Python-Umgebung, mehr Aufwand
Modellformat	GGUF aus eigener Registry	GGUF	Safetensors, FP8, NVFP4
Kontrolle über Speicher	grob, über Modelfile	fein, über Flags	fein, über Flags
Standardverhalten	KV-Cache großzügig	sparsam	auf Durchsatz optimiert
Mehrere Nutzer	nur eingeschränkt	nein	ja, dafür gebaut
Werkzeugaufrufe	ja	ja	ja, mit eigenem Parser
Anthropic-API nativ	ja, ab 0.14	nein	nein

Die praktische Regel: Ollama für den Arbeitsplatz, llama.cpp wenn der Speicher knapp ist, vLLM sobald mehr als eine Person daran hängt. Ollama installiert und lädt Modelle am schnellsten, greift beim KV-Cache aber spürbar großzügiger zu als die beiden anderen — auf einer 24-GB-Karte ist das der Unterschied zwischen „läuft" und „läuft nicht". llama.cpp gibt dir die direkteste Kontrolle über Kontextgröße und Cache-Format. vLLM ist die einzige der drei, die für parallele Anfragen gebaut ist, unterstützt die Vision-Anteile und die Kontexterweiterung per YaRN — kostet dafür Einrichtungsaufwand.

Ein Punkt, der die Entscheidung entschärft: Alle drei sprechen dieselbe OpenAI-kompatible Schnittstelle. Adresse und Modellname sind das Einzige, was sich für die angebundenen Werkzeuge ändert. Du kannst also mit Ollama anfangen und später auf vLLM umziehen, ohne deine Editor-Konfiguration neu zu bauen — nur die URL wandert von Port 11434 auf 8000. Das ist der Grund, warum ich die Umgebung nicht überdenken würde, bevor sie tatsächlich klemmt.

Ein zweiter Unterschied betrifft die Modellbeschaffung. Ollama zieht Modelle aus der eigenen Registry, was bequem ist, aber die Auswahl an Quantisierungsstufen einschränkt. llama.cpp und vLLM laden direkt von Huggingface, dort bekommst du jede verfügbare Variante — inklusive der Stufen, die zwischen den bequemen Standardgrößen liegen und manchmal genau die sind, die noch auf deine Karte passen.

Das Modell starten

Die Standardbefehle aus den Schnellstartanleitungen erzeugen ein Setup, das für einen Chat reicht und für einen Agenten nicht. Hier die drei Varianten mit den Parametern, die zählen.

Ollama, mit einer eigenen Modellvariante statt der Standardeinstellungen:

# Modell laden
ollama pull qwen3.8:27b

# Variante mit brauchbarem Kontextfenster anlegen
cat > Modelfile <<'EOF'
FROM qwen3.8:27b
PARAMETER num_ctx 32768
PARAMETER temperature 0.6
EOF

ollama create qwen3.8-agent -f Modelfile
ollama run qwen3.8-agent

llama.cpp als Server, mit quantisiertem KV-Cache:

llama-server \
  --model qwen3.8-27b-Q4_K_M.gguf \
  --ctx-size 32768 \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --n-gpu-layers 999 \
  --host 127.0.0.1 --port 8080

vLLM für den Mehrbenutzerbetrieb — hier sind die beiden Parser entscheidend:

vllm serve Qwen/Qwen3.8-27B-FP8 \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

Ohne --reasoning-parser qwen3 landen die Denkblöcke, mit denen das Modell jede Antwort eröffnet, ungefiltert im Antworttext — der Agent liest sie als Inhalt und wird wirr. Ohne --tool-call-parser qwen3_coder werden Werkzeugaufrufe nicht als solche erkannt, sondern als Text ausgegeben; der Agent wartet dann auf eine Aktion, die nie kommt. Auf einer einzelnen Blackwell-Karte brauchst du zusätzlich --enforce-eager, weil die Graph-Erfassung von CUDA sonst außerhalb des Speicherbudgets alloziert; das Kontextfenster musst du dort auf etwa 32K begrenzen.

Kurz zu den übrigen Parametern: --n-gpu-layers 999 bei llama.cpp bedeutet schlicht „so viele Schichten wie möglich auf die Grafikkarte" — passt nicht alles, landet der Rest im Hauptspeicher, und du merkst es sofort an der Geschwindigkeit. --host 127.0.0.1 bindet den Server bewusst nur an den eigenen Rechner; wer ihn im Netz erreichbar macht, stellt ein unauthentifiziertes Modell in die Landschaft. Bei vLLM steuert --max-model-len, wie viel Kontext der Dienst überhaupt zulässt — der Wert wird beim Start reserviert, du kannst ihn also nicht später hochdrehen.

Bevor du irgendein Werkzeug anbindest, prüf einmal, ob der Endpunkt das ausliefert, was du erwartest:

curl http://localhost:11434/v1/models

Antwortet dort eine Liste mit deinem Modellnamen, stimmen Adresse, Port und Name — die drei Dinge, an denen die Anbindung sonst scheitert. Bei llama.cpp lautet der Port standardmäßig 8080, bei vLLM 8000. Diese eine Zeile spart dir erfahrungsgemäß eine halbe Stunde Fehlersuche in Editor-Einstellungen, in denen gar nicht der Fehler steckt.

Die Kontextfalle

Der häufigste Grund, warum ein lokaler Agent „nicht funktioniert", ist ein Kontextfenster von 4.096 Token. Ollama setzt num_ctx standardmäßig auf einen kleinen Wert im Bereich von 2K bis 4K Token — sinnvoll für einen Chat, tödlich für einen Agenten. Ein Werkzeugaufruf mit Dateiinhalt frisst davon schnell die Hälfte. Nach drei, vier Schritten ist der Puffer voll, die ältesten Nachrichten fallen hinten raus, und der Agent verliert seine eigene Aufgabenstellung.

Das Tückische daran: Es gibt keine Fehlermeldung. Der Agent wirkt nicht kaputt, er wirkt dumm. Er wiederholt Schritte, die er gerade gemacht hat, liest dieselbe Datei zum dritten Mal, vergisst die Anweisung aus der ersten Nachricht. Wer das nicht kennt, schiebt es auf das Modell und wechselt zurück in die Cloud — obwohl nur eine Zahl falsch stand.

Die Korrektur ist der Modelfile-Block aus dem vorigen Abschnitt oder, bei llama.cpp und vLLM, das entsprechende Flag. Zwei Faustregeln dazu:

• Setz den Kontext auf das, was du wirklich brauchst, nicht auf das Maximum. Der KV-Cache wächst linear mit der Kontextlänge, und 262.144 Token reservieren ein Vielfaches dessen, was das Modell selbst belegt. Für Agentenarbeit an einzelnen Dateien sind 32.768 Token ein guter Startwert, für Arbeit über mehrere Dateien 65.536.
• Prüf nach, ob der Wert angekommen ist. Bei Ollama zeigt ollama show qwen3.8-agent die Parameter der Variante; verwendet der Agent versehentlich weiter das Basismodell, ist die Einstellung wirkungslos.

Grob abschätzen lässt sich der Bedarf so: Der Speicher für den Kontext wächst linear mit der Zahl der Token und mit der Zahl der Schichten des Modells. Verdoppelst du das Kontextfenster, verdoppelt sich auch dieser Anteil — bei einem 27B-Modell reden wir dabei nicht über Megabyte, sondern über Gigabyte. Deshalb ist „ich stell einfach das Maximum ein" auf Consumer-Hardware keine Option, sondern der schnellste Weg zurück in den Hauptspeicher.

Die typischen Symptome eines zu kleinen Fensters, damit du sie wiedererkennst: Der Agent liest dieselbe Datei mehrfach. Er fragt nach Informationen, die du am Anfang gegeben hast. Er beginnt eine Änderung und lässt sie unvollendet. Er bestätigt eine Anweisung und tut dann etwas anderes. Alles vier sieht nach einem schwachen Modell aus und ist keins.

Wenn der Speicher für den gewünschten Kontext nicht reicht, geh in dieser Reihenfolge vor: erst den KV-Cache quantisieren (Abschnitt weiter unten), dann das Kontextfenster senken, erst zuletzt die Modellquantisierung verschlechtern. Warum die Reihenfolge so ist, steht in Quantisierung von LLMs erklärt.

Bildunterschrift: So sieht ein zu kleines Kontextfenster aus: Der Agent legt weiter Informationen hinein, und was nicht mehr passt, fällt heraus — ohne dass irgendwo eine Fehlermeldung erscheint.

Die Reasoning-Stufe einstellen

Qwen3.8-27B startet auf der höchsten Denkstufe, und das ist im Alltag die falsche Einstellung. Das Modell kennt mehrere Stufen — von xhigh über medium bis low und ganz aus. Der Unterschied ist nicht kosmetisch: Auf der höchsten Stufe produziert das Modell ein Vielfaches an Denk-Token, bevor überhaupt ein Zeichen der eigentlichen Antwort erscheint. Bei einer lokalen Ausgabegeschwindigkeit im Bereich von zehn bis zwanzig Token pro Sekunde werden daraus Minuten.

Die veröffentlichten Messungen dazu sind eindeutig: Der Wechsel von xhigh auf medium nimmt rund ein Drittel der Wartezeit, und für einfache Aufgaben ohne Denkphase verdoppelt sich der Durchsatz ungefähr. An Qualität kostet das weniger, als man befürchtet — die Detailzahlen dazu stehen in Qwen3.8-27B gegen die Cloud.

Praktisch heißt das: Fahr mit medium als Standard und heb die Stufe nur für schwierige Entwürfe an. Über die OpenAI-kompatible Schnittstelle setzt du die Stufe pro Anfrage:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3.8-27B-FP8",
       "reasoning_effort": "medium",
       "messages": [{"role": "user", "content": "Erkläre diesen Fehler."}]}'

In vLLM stellst du sie pro Anfrage über das Feld reasoning_effort in der API ein, in Ollama über den Parameter in der Modellvariante — leg dir am besten zwei Varianten an, eine schnelle für den Alltag und eine gründliche für den Rest. Der Vorteil zweier Varianten: Du wechselst im Editor die Modellauswahl statt in Konfigurationsdateien zu editieren, und du siehst am Namen, womit du gerade arbeitest.

Wann sich die hohe Stufe lohnt, lässt sich ziemlich klar abgrenzen: bei Entwürfen, die mehrere Dateien betreffen, bei Fehlern, deren Ursache nicht offensichtlich ist, und bei Refactorings mit Abhängigkeiten. Für Testgenerierung, Umbenennungen, Dokumentation, kleine Bugfixes und alles, was du sonst selbst in zehn Minuten machen würdest, ist sie verschwendete Wartezeit. Was Reasoning-Modelle intern tun und warum die Stufe so stark durchschlägt, erklärt Reasoning-Modelle erklärt.

KV-Cache quantisieren

Nach der Modellquantisierung ist der KV-Cache der größte Speicherhebel — und der am seltensten genutzte. Der Cache hält die Zwischenergebnisse für jeden Token im Kontext. Er wird standardmäßig in 16 Bit gehalten, obwohl 8 oder sogar 4 Bit für die meisten Aufgaben ausreichen. Genauer: Für jeden bereits verarbeiteten Token merkt sich das Modell zwei Vektoren, Key und Value, damit es sie beim nächsten Token nicht neu berechnen muss. Ohne diesen Cache müsste bei jedem Wort die gesamte bisherige Unterhaltung neu durchgerechnet werden — er ist der Grund, warum Generierung überhaupt zügig läuft, und gleichzeitig der Posten, der bei langem Kontext den Speicher auffrisst.

Einstellung	llama.cpp	vLLM	Effekt
Standard (16 Bit)	—	—	volle Genauigkeit, höchster Verbrauch
8 Bit	--cache-type-k q8_0 --cache-type-v q8_0	--kv-cache-dtype fp8	etwa halber Cache-Speicher, kaum messbarer Unterschied
4 Bit	--cache-type-k q4_0 --cache-type-v q4_0	—	etwa ein Viertel, bei sehr langem Kontext spürbar

In einem veröffentlichten llama.cpp-Benchmark läuft Qwen3.8-27B mit 4-Bit-Cache und 32.768 Token Kontext bei einer Gesamtbelegung von 17,0 GB — also innerhalb dessen, was eine 24-GB-Karte hergibt, samt Reserve für den Anzeigespeicher. Ohne diesen Griff passt dieselbe Kombination nicht.

Mein Rat für den Einstieg: 8 Bit ist der Punkt, an dem du Speicher gewinnst, ohne nachzudenken. Die 4-Bit-Variante lohnt sich, wenn du sonst das Kontextfenster halbieren müsstest — die Verschlechterung durch einen zu kleinen Kontext ist im Agentenbetrieb deutlich größer als die durch einen gröberen Cache.

Zwei Einschränkungen gehören dazu. Erstens: Je länger der Kontext tatsächlich genutzt wird, desto eher summieren sich die Ungenauigkeiten eines grob quantisierten Caches — bei einem Agentenlauf über zwanzig Schritte fällt 4 Bit eher auf als in einem kurzen Chat. Zweitens gilt der Griff nur für den Cache, nicht für die Gewichte: Ein 4-Bit-Cache macht aus einem 8-Bit-Modell kein schlechteres Modell, er verkleinert nur den Puffer. Wer beides gleichzeitig herunterdreht, verliert an zwei Stellen und weiß hinterher nicht, an welcher.

Werkzeugaufrufe: die eigentliche Bruchstelle

Nicht die Codequalität entscheidet, ob ein lokaler Agent brauchbar ist, sondern ob seine Werkzeugaufrufe im richtigen Format ankommen. Ein Agent arbeitet in einer Schleife: Er fordert eine Aktion an, bekommt ein Ergebnis, entscheidet neu. Diese Anforderung ist ein JSON-Objekt mit festem Schema. Weicht das Modell davon ab — ein Feld zu viel, ein Anführungszeichen falsch, der Aufruf in Prosa statt im Aufrufblock —, bricht die Schleife. Über zwanzig Schritte hinweg genügt ein Fehler.

Bei den kommerziellen Anbietern ist dieser Teil bis zur Langeweile durchgetestet. Lokal hängt er an drei Dingen: der Chat-Vorlage des Modells, dem Parser der Laufzeitumgebung und dem Systemprompt des Agenten. Genau deshalb machen dieselben Gewichte in einem Werkzeug einen guten Eindruck und im nächsten einen katastrophalen.

Die Werkzeuge gehen damit unterschiedlich um:

• Cline hat auf diesem Pfad die meiste Arbeit investiert: ein eigener, kompakter Systemprompt für Ollama und LM Studio sowie natives Werkzeug-Handling je Modellfamilie statt eines einzigen generischen Formats.
• Aider umgeht das Problem grundsätzlich. Es benutzt gar kein JSON-Werkzeugformat, sondern lässt sich Änderungen als Diff oder als ganze Datei in Klartext ausgeben und parst diese selbst. Damit entfällt exakt die Fehlerquelle, an der die meisten Agenten mit lokalen Modellen scheitern — der Grund, warum Aider lokal oft besser läuft als modernere Werkzeuge.
• Continue ist in erster Linie Autovervollständigung und Chat im Editor; die Agentenschleife ist kürzer, also fällt weniger auf.

Wenn Werkzeugaufrufe bei dir reihenweise scheitern, prüf in dieser Reihenfolge: Ist in vLLM der passende Tool-Parser gesetzt? Läuft das Modell mit der richtigen Chat-Vorlage? Und ist das Kontextfenster groß genug, damit die Werkzeugdefinitionen überhaupt vollständig im Prompt stehen? Die dritte Ursache ist häufiger, als man denkt — Werkzeugbeschreibungen kosten mehrere tausend Token, bevor der Agent das erste Wort gelesen hat. Wer das grundsätzlich verstehen will, findet die Mechanik in Model Context Protocol erklärt.

Zur Fehlersuche hilft ein Blick auf die Rohantwort. Ruf das Modell einmal direkt über curl mit einer Werkzeugdefinition auf und schau dir an, was tatsächlich zurückkommt: Steht der Aufruf in einem eigenen Feld, oder steht er als Text mitten in der Antwort? Im zweiten Fall liegt es an Parser oder Chat-Vorlage, nicht am Agenten — und du sparst dir das Durchprobieren von Werkzeugen, die alle dasselbe Problem haben werden. Besonders häufig tritt das bei GGUF-Dateien aus Drittquellen auf, deren mitgelieferte Chat-Vorlage nicht zur Modellversion passt.

Bildunterschrift: Die häufigste Bruchstelle im lokalen Agentenbetrieb: Das Modell liefert einen einwandfreien Werkzeugaufruf — nur nicht in dem Format, das der Agent erwartet.

Editor und Agent anbinden

Alle gängigen Werkzeuge lassen sich auf ein lokales Modell umbiegen — der Aufwand reicht von einer Zeile bis zu einem Proxy. Vier Wege, sortiert nach Aufwand.

Cline in VS Code

Cline spricht die OpenAI-kompatible Schnittstelle direkt an. In den Einstellungen wählst du als Anbieter Ollama oder „OpenAI Compatible" und trägst ein:

{
  "apiProvider": "openai-compatible",
  "openAiBaseUrl": "http://localhost:11434/v1",
  "openAiModelId": "qwen3.8-agent",
  "openAiApiKey": "nicht-noetig"
}

Wichtig ist der Modellname: Trag die Variante mit dem großen Kontextfenster ein, nicht das Basismodell. Das ist der Fehler aus dem Kontextfallen-Abschnitt, und er passiert genau hier. Cline arbeitet außerdem in zwei Modi — einem planenden und einem ausführenden. Lokal lohnt es sich, den Plan tatsächlich zu lesen, bevor du die Ausführung freigibst: Ein lokales Modell irrt sich häufiger in der Aufgabenzerlegung als ein kommerzielles, und ein falscher Plan kostet dich zwanzig Minuten Rechenzeit statt zwanzig Sekunden.

Continue in VS Code oder JetBrains

Continue wird über eine YAML-Datei im Profil konfiguriert. Ein Eintrag für Chat und Bearbeitung:

models:
  - name: Qwen3.8 lokal
    provider: ollama
    model: qwen3.8-agent
    roles:
      - chat
      - edit
      - apply

Für die Autovervollständigung im Editor solltest du ein deutlich kleineres Modell eintragen — ein 27B-Modell antwortet dafür zu langsam, und du merkst es bei jedem Tastendruck. In derselben Datei sieht das dann so aus:

  - name: Autovervollständigung
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete

Welches kleine Modell dafür taugt, hängt an deiner Sprache und deinem Speicher — die Auswahl steht in Welches Ollama-Modell?.

Aider im Terminal

Aider braucht nur die Adresse und den Modellnamen als Umgebungsvariablen:

export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen3.8-agent

Weil Aider Änderungen als Diff im Klartext erwartet, ist es der verlässlichste Einstieg, wenn dein Setup mit Werkzeugaufrufen kämpft. Es ist auch das Werkzeug, mit dem ich lokal anfangen würde, bevor ich mich an einen vollautonomen Agenten wage. Aider arbeitet standardmäßig eng mit Git zusammen und legt für jede Änderung einen Commit an; das ist genau das Sicherheitsnetz, das man bei lokalen Modellen braucht, weil man häufiger etwas verwerfen will.

Claude Code

Hier hat sich 2026 das meiste geändert. Claude Code spricht die Anthropic-Messages-API, Ollama sprach lange nur OpenAI-kompatibel — dazwischen brauchte es einen LiteLLM-Proxy als Übersetzer. Seit Ollama 0.14 vom 16. Januar 2026 liefert Ollama die Messages-API nativ unter /v1/messages, und der Proxy entfällt. Die Anbindung besteht dann aus drei Umgebungsvariablen:

export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_MODEL=qwen3.8-agent
export ANTHROPIC_SMALL_FAST_MODEL=qwen3.8-agent
claude

Die zweite und dritte Variable sind nötig, weil Claude Code intern feste Modellnamen verwendet und eine kleinere Variante für Nebenaufgaben wie Zusammenfassungen anspricht. Wer llama.cpp oder vLLM statt Ollama betreibt, braucht den Übersetzer weiterhin:

model_list:
  - model_name: claude-sonnet-4-5
    litellm_params:
      model: openai/qwen3.8-27b
      api_base: http://localhost:8080/v1
      api_key: nicht-noetig

Danach zeigt ANTHROPIC_BASE_URL auf den Proxy, üblicherweise http://localhost:4000. Auch die GitHub-Copilot-Kommandozeile lässt sich seit April 2026 gegen Ollama und vLLM richten — die Landschaft bewegt sich hier schnell, entsprechend lohnt vor dem Aufsetzen ein Blick in die aktuelle Dokumentation des jeweiligen Werkzeugs. Welches Werkzeug grundsätzlich wofür taugt, steht in KI-Coding-Assistenten.

Mein Setup

Das ist die Kombination, mit der ich lokal arbeite — bewusst konservativ eingestellt. Auf einer Maschine mit 32 GB Speicher, für einen einzelnen Nutzer:

• Qwen3.8-27B in 4-Bit-Quantisierung über Ollama geladen
• Eigene Modellvariante mit num_ctx 32768 angelegt und geprüft, dass der Agent sie auch benutzt
• Reasoning-Stufe auf medium, eine zweite Variante mit hoher Stufe für Entwurfsarbeit
• KV-Cache in 8 Bit
• Aider für alles, was einen Diff erzeugt; Cline für Aufgaben mit mehreren Schritten
• Claude Code direkt gegen Ollamas Messages-Endpunkt, ohne Proxy
• Kleines Modell separat für die Autovervollständigung im Editor
• Git-Zweig vor jedem Agentenlauf, damit das Zurückrollen eine Sekunde dauert

Der letzte Punkt klingt banal und ist der wichtigste. Ein lokaler Agent macht mehr Fehlversuche als ein kommerzieller; das ist verkraftbar, solange sie nichts kosten außer Zeit.

Warum so und nicht anders: 4 Bit statt 8 Bit beim Modell, weil der gewonnene Speicher in Kontext fließt — und ein größeres Fenster bringt im Agentenbetrieb mehr als die letzten Prozentpunkte Modellgenauigkeit. medium als Standardstufe, weil die Wartezeit sonst den Arbeitsfluss zerstört. Zwei Werkzeuge statt einem, weil Aider und Cline unterschiedliche Aufgaben unterschiedlich gut lösen und der Wechsel nichts kostet. Und Ollama statt vLLM, solange ich allein an der Maschine sitze: Der Mehraufwand von vLLM zahlt sich erst aus, wenn parallele Anfragen dazukommen.

Messen statt raten

Bevor du an den Einstellungen drehst, miss den Ist-Zustand — sonst optimierst du gegen ein Gefühl. Drei Messungen reichen.

Erstens die Geschwindigkeit. Ollama gibt sie auf Wunsch selbst aus:

ollama run qwen3.8-agent --verbose "Schreibe eine Funktion, die eine CSV-Datei einliest."

Am Ende stehen die Werte für Prompt-Auswertung und Generierung getrennt. Beides ist wichtig: Eine niedrige Generierungsrate merkst du beim Lesen, eine niedrige Prompt-Rate merkst du als Stille, bevor überhaupt etwas passiert. Als Orientierung: Ein dichtes 27B-Modell in 4 Bit liegt auf aktueller Consumer-Hardware im niedrigen zweistelligen Bereich bei der Generierung. Wenn du deutlich darunter landest, stimmt etwas nicht — meist die Speicherverteilung.

ollama ps zeigt dir dazu, welches Modell geladen ist und welcher Anteil davon tatsächlich auf der Grafikkarte liegt. Steht dort nicht die volle Auslagerung auf die GPU, hast du deine Ursache gefunden, bevor du überhaupt anfängst zu raten.

Zweitens die Speicherbelegung, während das Modell arbeitet — bei NVIDIA-Karten mit nvidia-smi, auf Apple-Hardware über die Aktivitätsanzeige. Der entscheidende Punkt: Läuft wirklich alles auf der Grafikkarte? Sobald Schichten in den Hauptspeicher ausgelagert werden, bricht die Geschwindigkeit um eine Größenordnung ein, und keine Einstellung der Welt holt das zurück.

Drittens die Trefferquote im Agentenbetrieb. Nimm dir fünf typische Aufgaben aus deinem Alltag und zähl schlicht, wie viele davon ohne Eingriff durchlaufen. Diese Zahl ist aussagekräftiger als jeder Benchmark, weil sie deinen Code, deine Sprache und dein Werkzeug einschließt. Wiederhol sie nach jeder Änderung an der Konfiguration.

Wann das Setup kippt

Der lokale Betrieb hat drei klare Grenzen, und es ist besser, sie vorher zu kennen als mitten im Projekt.

Die erste ist der Mehrbenutzerbetrieb. Eine Karte bedient eine Anfrage vernünftig. Sobald zwei Leute gleichzeitig arbeiten, brauchst du vLLM, mehr Speicher und jemanden, der das betreibt — aus dem Werkzeug wird ein Dienst mit Verfügbarkeitsanspruch.

Die zweite sind große Repositories. Agentenarbeit über viele Dateien hinweg füllt den Kontext schneller, als dir lieb ist, und lokal kannst du ihn nicht beliebig aufdrehen. Community-Berichte setzen lokale Modelle bei Einzeldateiarbeit in die Größenordnung von 70 bis 85 Prozent eines kommerziellen Spitzenmodells, mit deutlich größerem Abstand bei Aufgaben über mehrere Dateien. Das deckt sich mit meiner Erfahrung.

Die dritte ist die Erwartung an Tempo. Wenn du gewohnt bist, dass eine Antwort in Sekunden kommt, sind zehn Token pro Sekunde eine Umstellung. Für Aufgaben, die im Hintergrund laufen dürfen, ist das egal. Für interaktives Arbeiten am offenen Problem ist es der Punkt, an dem die meisten zurückwechseln.

Wenn einer dieser drei Punkte zutrifft, ist das kein Scheitern, sondern eine Arbeitsteilung: lokal für alles Vertrauliche und alles Asynchrone, kommerziell für den Rest. Diese Aufteilung lässt sich technisch sauber ziehen, weil beide Wege dieselbe Schnittstelle sprechen: Im Editor hinterlegst du beide Modelle und wechselst je nach Aufgabe und Vertraulichkeit. Was dabei rechtlich zu beachten ist und für welche Firmen der lokale Weg der einzig zulässige bleibt, steht im Grundlagenartikel Qwen3.8-27B gegen die Cloud.

Häufige Fragen

Warum läuft mein lokaler Agent im Kreis? Fast immer wegen eines zu kleinen Kontextfensters. Ollama startet mit wenigen tausend Token, die ein Agent nach drei Werkzeugaufrufen aufgebraucht hat. Leg eine Modellvariante mit num_ctx 32768 an und stell sicher, dass der Agent diese Variante anspricht und nicht das Basismodell.

Brauche ich für Claude Code noch einen Proxy? Nicht mit Ollama. Seit Version 0.14 vom Januar 2026 liefert Ollama die Anthropic-Messages-API direkt, du setzt nur ANTHROPIC_BASE_URL und die beiden Modellvariablen. Für llama.cpp und vLLM brauchst du weiterhin einen Übersetzer wie LiteLLM.

Ollama, llama.cpp oder vLLM — was nehme ich? Ollama am Arbeitsplatz, weil es am schnellsten läuft. llama.cpp, wenn der Speicher knapp ist und du jede Stellschraube brauchst. vLLM, sobald mehrere Leute oder mehrere parallele Agenten daran hängen.

Warum sind die Antworten so langsam, obwohl das Modell in den Speicher passt? Meist steht die Reasoning-Stufe auf dem Maximum. Setz sie auf medium und miss erneut. Zweithäufigste Ursache: Ein Teil des Modells liegt doch im Hauptspeicher, weil KV-Cache und Kontext mehr belegen als eingeplant.

Kann ich lokale Modelle mit MCP-Servern kombinieren? Ja — MCP ist unabhängig vom Modellanbieter, und die gängigen Agenten unterstützen es auch mit lokalen Modellen. Die Werkzeugbeschreibungen kosten allerdings Kontext, also plan sie beim Kontextfenster mit ein. Wie du selbst einen Server aufsetzt, steht in MCP-Server einrichten.

Welches Modell für die Autovervollständigung im Editor? Nicht dasselbe. Vervollständigung braucht Antwort in Millisekunden, dafür ist ein 27B-Modell die falsche Wahl. Trag ein kleines Modell für diese Rolle ein und lass das große für Chat, Bearbeitung und Agentenläufe arbeiten.

Ist ein lokaler Agent sicher gegen Prompt Injection? Nein, das ist eine andere Baustelle. Lokal verhindert den Datenabfluss zum Anbieter, nicht dass ein präparierter Inhalt aus dem Projekt den Agenten fehlleitet. Dazu mehr in KI-Sicherheit und Prompt Injection.

Zusammenfassung und praktische Tipps

• Kontextfenster zuerst. Der Standardwert von wenigen tausend Token ist der häufigste Grund für scheiternde Agenten — und er meldet sich nie mit einer Fehlermeldung.
• Modellvariante statt Basismodell. Lege sie mit einem Modelfile an und prüfe mit ollama show, dass die Parameter wirklich gesetzt sind.
• Reasoning-Stufe auf medium. Das nimmt rund ein Drittel der Wartezeit und kostet erstaunlich wenig Qualität.
• KV-Cache in 8 Bit. Der Griff mit dem besten Verhältnis von Aufwand zu gewonnenem Speicher.
• Die richtigen Parser in vLLM. Ohne --reasoning-parser und --tool-call-parser ist die Ausgabe für einen Agenten unbrauchbar, obwohl das Modell tadellos arbeitet.
• Aider zuerst probieren. Es parst Diffs aus Klartext statt JSON-Werkzeugaufrufe und umgeht damit die häufigste lokale Fehlerquelle.
• Claude Code braucht keinen Proxy mehr, wenn Ollama ab Version 0.14 darunterliegt — drei Umgebungsvariablen genügen.
• Zwei Modelle statt eins. Das große für Agentenarbeit, ein kleines für die Autovervollständigung.
• Vor jedem Agentenlauf ein Git-Zweig. Lokale Modelle machen mehr Fehlversuche; billig sind die nur, wenn das Zurückrollen trivial ist.
• Miss deine fünf Alltagsaufgaben. Diese Quote sagt dir mehr über dein Setup als jede Benchmarktabelle.

Mein Rat: Fang klein an und widersteh der Versuchung, sofort den vollautonomen Agenten aufzusetzen. Bring erst ein Modell mit vernünftigem Kontextfenster zum Laufen, arbeite ein paar Tage mit Aider und schau, wie sich die Antwortzeiten in deinem Alltag anfühlen. Erst wenn das trägt, hängst du Cline oder Claude Code daran. Die meisten Enttäuschungen mit lokalen Modellen entstehen nicht am Modell, sondern an drei falsch gesetzten Zahlen und an der Erwartung, dass sich Cloud-Tempo mit einer einzelnen Grafikkarte nachbauen lässt. Beides lässt sich beheben — das eine in fünf Minuten, das andere durch eine ehrliche Aufteilung der Arbeit.

Ressourcen

• Qwen3.8-27B gegen die Cloud: Was lokale Coding-Modelle 2026 wirklich leisten – der Grundlagenartikel dazu: Benchmarks, Hardware, Kosten und die Compliance-Frage
• vLLM-Rezept für Qwen3.8-27B – offizieller Startbefehl samt Parsern, Quantisierungen und den Hinweisen zum Einzelkartenbetrieb (abgerufen am 30.08.2026)
• Qwen/Qwen3.8-27B auf Huggingface – Model Card mit Kontextfenster, Lizenz und den Reasoning-Stufen (abgerufen am 30.08.2026)
• Ollama installieren: macOS, Linux, Windows und Docker – der Schritt davor, falls die Laufzeitumgebung noch fehlt
• Ollama: lokale Sprachmodelle auf dem eigenen Rechner betreiben – Grundlagen zur Laufzeitumgebung, ihrer API und den Grenzen im Mehrbenutzerbetrieb
• Welches Ollama-Modell? Auswahl nach Hardware und Zweck – Modellauswahl nach Speicherklasse, inklusive der kleinen Modelle für die Autovervollständigung
• Quantisierung von LLMs erklärt – warum die Reihenfolge KV-Cache, Kontext, Modellquantisierung genau so lautet
• Reasoning-Modelle erklärt – was die Denkstufen technisch bedeuten und warum sie so stark durchschlagen
• KI-Coding-Assistenten: welches Werkzeug wofür – Einordnung der Werkzeuge, inklusive der Frage, welche sich lokal betreiben lassen
• MCP-Server einrichten – eigene Werkzeuge an den Agenten hängen, auch lokal