Ollama mit Ihrem Coding-Agent verbinden

Was Sie verbinden

Sie können Ollama mit Ihrem Coding-Agent verwenden. Die Verbindung ist einfacher, als viele erwarten. Sie ändern eine Basis-URL und wählen einen Modellnamen aus. Das Feld für den API-Schlüssel erwartet weiterhin einen Wert. Der lokale Server ignoriert ihn jedoch, daher funktioniert jede Zeichenfolge.

Ollama lauscht auf Port 11434 und stellt gleichzeitig drei API-Schnittstellen bereit. /api ist Ollamas native API. /v1 ist die OpenAI-kompatible Schicht. Sie unterstützt mehrere Formate: /v1/chat/completions, /v1/responses, /v1/completions, /v1/models und /v1/embeddings. In der Ollama-Dokumentation wird der Schlüssel dort als erforderlich beschrieben, aber ignoriert. Die dritte Schnittstelle ist Anthropic-kompatibel. Der Client verwendet http://localhost:11434 als Basis-URL und hängt /v1/messages an. Dies entspricht dem von Claude Code verwendeten Format. Die meisten Agents verwenden /v1/chat/completions, Codex verwendet /v1/responses und Claude Code verwendet /v1/messages. Ihr Agent unterstützt bereits eines dieser Formate. An ihm müssen Sie daher nichts weiter ändern.

Dieser Teil dauert fünf Minuten. Ob das Ergebnis nutzbar ist, hängt von zwei Einstellungen ab, die fast niemand ändert: der Kontextlänge und dem Keep-Alive. Außerdem müssen Sie dem Modell Aufgaben geben, für die es geeignet ist. Beide Einstellungen erhalten einen eigenen Abschnitt. Die tatsächlichen Grenzen folgen am Ende.

Welche Coding-Agenten eine lokale Base-URL akzeptieren

Der Test besteht aus einer Frage: Bietet das Tool eine Einstellung für die Base-URL? Wenn ja, kann es mit Ihrem Server kommunizieren.

Ollama veröffentlicht Integrationsseiten für Claude Code, OpenCode, Codex, Cline, Roo Code, Zed, JetBrains IDEs und VS Code. Aider dokumentiert seine eigene Ollama-Unterstützung separat. Damit sind die meisten Tools abgedeckt, die im Oktober 2026 als Coding-Agent bezeichnet werden. Sie verwenden nicht alle dasselbe API-Format. Genau daran scheitern Konfigurationen.

• Die meisten Agenten erwarten einen OpenAI-kompatiblen Endpunkt. Geben Sie ihnen die Base-URL http://localhost:11434/v1 und einen beliebigen nicht leeren API-Schlüssel.
• Claude Code akzeptiert überhaupt keine OpenAI-Base-URL. Es verwendet die Anthropic Messages API und benötigt daher ANTHROPIC_BASE_URL mit dem Wert http://localhost:11434. Unter dieser Adresse stellt Ollama /v1/messages bereit.
• Codex verwendet die OpenAI Responses API. Ollama stellt auch /v1/responses bereit. Diese Unterstützung wurde in Version 0.13.3 hinzugefügt.
• Ein Agent ohne Einstellung für die Base-URL kann nicht umgeleitet werden, weil der Endpunkt im Client festgelegt ist. Akzeptiert der Agent zwar eine benutzerdefinierte URL, benötigt aber ein anderes API-Format, setzen Sie stattdessen eine Übersetzungsschicht davor, beispielsweise ein selbst gehostetes LiteLLM-Gateway. Stellen Sie Ihr Modell dort in dem Format bereit, das der Client erwartet.

Ollama kann diese Konfigurationen für Sie erstellen. ollama launch opencode startet OpenCode mit einer Inline-Konfiguration für das ausgewählte Modell, ollama launch claude macht dasselbe für Claude Code, und ollama launch droid --config schreibt die Konfiguration, ohne das Tool zu starten.

Ollama installieren und ein Modell abrufen, das Tools aufrufen kann

curl -fsSL https://ollama.com/install.sh | sh
systemctl status ollama --no-pager
ollama pull qwen3-coder:30b
ollama ls

Das Installationsprogramm fügt eine systemd-Unit hinzu und startet sie. Daher sollte systemctl status ollama active (running) ausgeben. Falls nicht, gibt journalctl -e -u ollama den Grund aus.

Das Modell muss Tool-Aufrufe unterstützen, weil ein Agent auf diese Weise arbeitet. Er liest eine Datei, schreibt einen Patch, führt den Test aus, liest anschließend den Fehler und versucht es erneut. Ein Modell, das keinen Tool-Aufruf ausgeben kann, beschreibt die Änderung nur als Text, statt sie auszuführen. Der Agent wiederholt sich dann oder beendet den Vorgang. Suchen Sie auf der Modellseite unter ollama.com vor dem Abruf nach dem Label tools. qwen3-coder:30b trägt dieses Label. Im Oktober 2026 ist dieser Tag ein 19-GB-Download mit einem Kontextfenster von 256K. Wenn Ihr Server ausschließlich über die CPU arbeitet oder nur wenig RAM hat, zeigt die Speicherberechnung für das Qwen-27B-Tag auf einem VPS, was in 8 bis 64 GB tatsächlich passt, bevor Sie den Download starten. Nach dem Abruf liegen diese Gigabytes auf dem Root-Datenträger des Servers. Auf einem VPS bietet dieser am wenigsten freien Speicher. Daher sollten Sie wo Ollama seine Modelldateien speichert und wie Sie sie an einen anderen Ort verschieben lesen, bevor der Datenträger voll ist.

Bestätigen Sie nun, welche Namen der Server tatsächlich bereitstellt:

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

Die Zeichenfolgen in dieser Antwort müssen in Ihrer Agent-Konfiguration exakt enthalten sein. Wenn Sie dies zuerst prüfen, lassen sich die meisten Fehler wegen nicht gefundener Modelle vermeiden. Falls Ollama noch nicht installiert ist, finden Sie die ausführlichere Anleitung unter ein LLM mit Ollama auf einem VPS selbst hosten.

OpenCode auf Ollama ausrichten

Bearbeiten Sie ~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3-coder:30b": {
          "name": "qwen3-coder 30b"
        }
      }
    }
  }
}

Der Schlüssel unter models ist der an Ollama gesendete Modellname. Er muss daher exakt mit ollama ls übereinstimmen. Das Feld name ist nur die Bezeichnung in der Modellauswahl. Starten Sie opencode, wechseln Sie zum Ollama-Provider und überwachen Sie journalctl -e -u ollama, um zu bestätigen, dass die Anfrage auf Ihrem Server und nicht an anderer Stelle eingegangen ist. Die Einrichtung des Agenten selbst wird unter OpenCode auf einem VPS ausführen beschrieben.

Claude Code auf Ollama ausrichten

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3-coder:30b

ANTHROPIC_API_KEY wird absichtlich auf eine leere Zeichenfolge gesetzt. Die Basis-URL legt fest, wohin Anfragen gesendet werden. Durch das Leeren des Schlüssels bleiben Zugangsdaten für gehostete Dienste aus dieser lokalen Konfiguration heraus. ollama launch claude übernimmt diese Einstellungen automatisch.

Machen Sie sich klar, welche Funktionen die Kompatibilitätsschicht nicht bereitstellt. Sie implementiert weder tool_choice noch Prompt-Caching. Außerdem verfügt sie über keinen Endpunkt zur Token-Zählung. Die angezeigten Tokenzahlen sind daher Näherungswerte des Tokenizers des Modells. Claude Code übermittelt außerdem einen umfangreichen System-Prompt und stellt eine große Anzahl von Tools bereit. Daher benötigt es mehr Kontext als ein Chat-Client. Die weiter gefasste Frage, welche Funktionen übernommen werden und welche nicht, wird unter ob Sie Claude selbst hosten können behandelt.

Aider auf Ollama ausrichten

export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen3-coder:30b

Die Dokumentation von Aider empfiehlt das Präfix ollama_chat/ statt ollama/. Standardmäßig fordert Aider für jede Anfrage ausreichend Kontext sowie 8k Tokens für die Antwort an. Außerdem können Sie das Kontextfenster für jedes Modell in .aider.model.settings.yml festlegen. Das ist nützlich, wenn ein Modell ein anderes Fenster als der Serverstandard benötigt:

- name: ollama_chat/qwen3-coder:30b
  extra_params:
    num_ctx: 65536

Warum ein funktionierendes Setup trotzdem unsinnige Ergebnisse liefert

Dies ist der entscheidende Abschnitt. Ollama wählt die Standard-Context-Länge anhand der gesamten für Ollama sichtbaren VRAM-Menge (Videospeicher der GPUs) und zieht für jede erkannte GPU OLLAMA_GPU_OVERHEAD ab. Die Implementierung verwendet diese Schwellenwerte:

[
  {
    "label": "Under 23 GiB aggregate VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "23 to under 47 GiB aggregate VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "47 GiB aggregate VRAM or more",
    "default_context_tokens": "262,144"
  }
]

Die meisten VPS-Tarife und jeder Server ohne GPU landen in der ersten Zeile: 4,096 Tokens. Mehrere kleinere GPUs können zusammen die Schwelle von 47 GiB erreichen, die für die 262,144 Tokens in der letzten Zeile erforderlich ist.

Ein Agent übergibt 4096 Tokens, bevor er überhaupt arbeitet. Der System-Prompt, die Tool-Definitionen, die Repository-Auflistung und die erste geöffnete Datei sind bereits größer als das. Danach tritt das eigentliche Problem auf: Es erscheint kein Fehler. In der Dokumentation von Aider steht, dass Ollama Kontext, der das Fenster überschreitet, stillschweigend verwirft. Die ältesten Tokens fallen heraus. Dadurch antwortet das Modell selbstsicher zu einer Datei, die es nicht mehr sehen kann, oder vergisst eine Anweisung, die Sie zwei Schritte zuvor gegeben haben. Dieser Mechanismus steckt hinter den meisten Berichten, ein lokales Modell sei zum Schreiben von Code zu schlecht. Die Wahl der Zahl selbst ist eine separate Entscheidung. Welche Kosten num_ctx bei jeder Größe im KV-Cache verursacht, sollten Sie lesen, bevor Sie sich festlegen.

In der Ollama-Dokumentation steht, dass Aufgaben wie Agenten und Coding-Tools auf mindestens 64000 Tokens eingestellt werden sollten. Setzen Sie den Wert auf dem Server:

sudo systemctl edit ollama.service

Fügen Sie diese Zeilen in die Override-Datei ein:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=64000"

Laden Sie die Konfiguration anschließend neu und starten Sie den Dienst neu:

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

Senden Sie nach dem Neustart eine Anfrage von Ihrem Agenten. Führen Sie danach erneut ollama ps aus, damit ein geladenes Modell geprüft werden kann. ollama ps ist die relevante Prüfung. Der Befehl gibt eine Spalte CONTEXT aus. Diese Zahl entspricht dem Kontext, den das Modell tatsächlich erhalten hat. ID und SIZE werden bei Ihnen abweichen:

NAME               ID              SIZE     PROCESSOR    CONTEXT    UNTIL
qwen3-coder:30b    a1b2c3d4e5f6    24 GB    100% GPU     64000      4 minutes from now

Setzen Sie den Wert auf dem Server und nicht im Agenten. Dafür gibt es zwei Gründe. Das OpenAI-Schema für Chat Completions enthält kein Feld für die Context-Länge. Ein OpenAI-kompatibler Client kann daher keine Context-Länge anfordern. Außerdem gilt die Einstellung pro Server. Jeder Agent, den Sie auf diesen Server richten, übernimmt sie. Die Ausgabeseite hat eine eigene Obergrenze. Anders als die Context-Länge wird sie über den Kompatibilitätsendpunkt übertragen. Verwenden Sie daher num_predict und das darauf abgebildete Feld max_tokens, wenn eine Antwort mitten in einem Patch abbricht. Wenn ein Modell ein anderes Fenster benötigt, erstellen Sie mit einer Modelfile eine eigene Kopie:

FROM qwen3-coder:30b
PARAMETER num_ctx 65536

ollama create qwen3-coder-64k -f Modelfile

Context ist nicht kostenlos. Ein längeres Fenster benötigt mehr Speicher. Beobachten Sie daher die Spalte PROCESSOR. 100% GPU ist der gewünschte Wert. Sobald ein Teil des Modells auf die CPU ausgelagert wird, sinkt die Token-Rate so stark, dass ein Agenten-Loop unbrauchbar wird. Mit der Messung von Tokens pro Sekunde bei einem lokalen LLM ermitteln Sie die tatsächliche Grenze Ihres Servers. Wie Sie die Maschine vor dem Kauf dimensionieren, wird in Wie viel RAM und CPU ein Coding-Agent-VPS benötigt beschrieben.

Modell zwischen Anfragen geladen halten

Standardmäßig entlädt Ollama ein Modell 5 Minuten nach der letzten Anfrage. Das ist für ein Chatfeld sinnvoll, aber für Agent-Aufgaben ungeeignet. Sie pausieren, um einen Diff zu lesen, der Timer läuft ab, und die nächste Anfrage lädt mehrere Dutzend Gigabyte an Gewichten von der Festplatte, bevor das erste Token erscheint. Das wirkt wie ein Hänger.

OLLAMA_KEEP_ALIVE akzeptiert eine Dauerangabe wie 10m oder 24h, eine einfache Anzahl von Sekunden, -1, um das Modell dauerhaft geladen zu halten, oder 0, um es sofort zu entladen. Setzen Sie den Parameter neben die Kontextlänge:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=64000"
Environment="OLLAMA_KEEP_ALIVE=-1"

Das Anforderungsfeld keep_alive ist bei Ollamas nativen Endpunkten /api/generate und /api/chat sowie als Ollama-Erweiterung bei /v1/chat/completions verfügbar. Ein Agent, der zusätzliche Anforderungsfelder unterstützt, kann das Feld dort senden. Verwenden Sie andernfalls die Umgebungsvariable. Wenn Sie den Speicher wieder freigeben müssen, entlädt ollama stop qwen3-coder:30b das Modell, ohne den Server zu stoppen. Wenn die Einstellung einen Reboot überstehen soll oder Sie abwägen möchten, ob die Gewichte den ganzen Tag im Speicher bleiben oder der Speicher wieder freigegeben wird, funktioniert ein in Ollama im Speicher geladenes Modell behalten mit beiden Verfahren.

Ollama auf einem separaten Server ausführen

Ollama bindet an localhost. Damit Sie den Dienst von einem anderen Rechner erreichen, setzen Sie OLLAMA_HOST=0.0.0.0:11434 im selben systemd-Override und starten den Dienst neu.

Tun Sie das nur in einem privaten Netzwerk. Laut der Dokumentation von Ollama ist für die lokale API keine Authentifizierung erforderlich. Ein für das Internet geöffneter Port 11434 ermöglicht daher jedem die Nutzung Ihrer Hardware. Es gibt zwei sichere Optionen. Lassen Sie die Bindung auf localhost bestehen und leiten Sie den Port von Ihrem Laptop aus per SSH weiter:

ssh -N -L 11434:localhost:11434 you@your-vps

Ihr Agent verwendet weiterhin http://localhost:11434/v1 und erkennt keinen Unterschied. Die andere Option ist ein VPN. Dabei bindet Ollama an die VPN-Adresse statt an 0.0.0.0. Wenn mehrere Personen oder mehrere Agents einen Rechner gemeinsam nutzen, unterstützt Ollama parallele Anfragen, sofern der verfügbare Speicher ausreicht. Der Vergleich zwischen Ollama und vLLM zeigt, ab wann der Durchsatzunterschied problematisch wird.

Wo ein lokales Coding-Modell überzeugt und wo nicht

Ein Agent mit einem von Ihnen gehosteten Modell ersetzt eine Frontier-API nicht bei jeder Aufgabe. Bei vier Arten von Arbeiten ist er klar im Vorteil.

• Umfangreiche mechanische Änderungen, bei denen jede einzelne Änderung klein ist und Sie sie prüfen können. Umbenennungen in einem Repository, das Ergänzen von Type Hints, das Schreiben von Docstrings oder das Übersetzen von Kommentaren. Das Modell läuft stundenlang, ohne dass sich die Kosten erhöhen.
• Arbeiten, die Ihre Hardware nicht verlassen dürfen. Dazu gehören Client-Code unter einer Vertraulichkeitsvereinbarung oder ein internes Repository, das Sie nicht an einen Drittanbieter senden dürfen.
• Offline- und Air-Gap-Systeme, auf denen überhaupt keine gehostete API erreichbar ist.
• Planbare Kosten. Sobald der Server bezahlt ist, verursacht ein Agent, der in einer Schleife Tokens verbraucht, keine zusätzlichen Kosten. Das ist das Gegenteil einer API mit nutzungsabhängiger Abrechnung. Wann ein GPU-VPS gegenüber API-Tokens kostendeckend ist enthält die Berechnung.

Bei langen Aufgaben mit mehreren Schritten ist er im Nachteil. Die Aufgabe „Finden Sie heraus, warum dieser Test fehlschlägt, beheben Sie die Ursache und aktualisieren Sie die Aufrufer“ erfordert viele korrekte Tool-Aufrufe nacheinander. Dabei muss der vollständige Verlauf weiterhin im Kontext vorhanden sein. Ein Modell im Bereich von 8B bis 14B auf einem leistungsschwachen Server erzeugt möglicherweise einen fehlerhaften Tool-Aufruf oder verliert nach einigen Durchläufen den Plan. Dann verbringen Sie mehr Zeit damit, das Modell zu steuern, als die Aufgabe selbst gedauert hätte. Das ist kein Prompt-Problem, das sich durch eine andere Formulierung lösen lässt. Es ist eine Frage der Kapazität.

Auch wenn Fehler teuer sind und Sie nicht jede Zeile lesen werden, ist es im Nachteil. Übertragen Sie dem lokalen Modell eng abgegrenzte Aufgaben und prüfen Sie die Ausgaben. Verwenden Sie für Arbeiten, die Sie nicht Schritt für Schritt kontrollieren würden, weiterhin ein gehostetes Modell.

Fehlermodi und die zugehörigen Meldungen

curl: (7) Failed to connect to localhost port 11434 after 0 ms: Connection refused. Der Server läuft nicht oder der Agent verweist auf einen anderen Host. Führen Sie systemctl status ollama aus und anschließend journalctl -e -u ollama.

Der Agent meldet, dass das Modell nicht existiert. Der Name in Ihrer Konfiguration stimmt nicht mit einem Namen überein, den der Server bereitstellt. Vergleichen Sie ihn mit curl http://localhost:11434/v1/models und kopieren Sie die Zeichenfolge von dort. Das Tag ist Teil des Namens; daher schlägt eine Konfiguration, die ein Tag angibt, das Sie nie heruntergeladen haben, fehl, auch wenn ein ähnliches Modell installiert ist.

Der Agent antwortet in Prosa und bearbeitet keine Datei. Entweder unterstützt das Modell keine Tools oder die Anfrage samt Tool-Definitionen füllt bereits das Kontextfenster aus. Prüfen Sie das Label tools auf der Modellseite und anschließend die Spalte CONTEXT in ollama ps.

Langes Schweigen vor dem ersten Token, dann normale Geschwindigkeit. Das Keep-Alive ist abgelaufen und die Gewichte werden erneut von der Festplatte gelesen. Setzen Sie OLLAMA_KEEP_ALIVE.

Das Modell widerspricht einer Datei, die es gerade gelesen hat. Kontextkürzung. ollama ps zeigt meist einen CONTEXT-Wert, der kleiner ist als angenommen, da die Umgebungsvariable an Ihre Shell und nicht an die systemd-Unit übergeben wurde.

Alles funktioniert, aber langsam, und PROCESSOR ist nicht 100% GPU. Normalerweise passen das Modell und sein Kontext nicht in den VRAM. Wenn PROCESSOR auf einem Rechner mit GPU 100% CPU anzeigt, schließen Sie zuerst die andere Ursache aus: Ollama hat die GPU möglicherweise gar nicht gefunden. Die Dokumentation von Ollama weist darauf hin, dass es unter Linux nach einem Suspend/Resume-Zyklus gelegentlich vorkommt, dass eine NVIDIA-GPU nicht erkannt wird und das System auf die CPU zurückfällt; das Neuladen des Treibers mit sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm dient hierbei als Workaround. Wenn die GPU gefunden wird und die Aufteilung bestehen bleibt, verringern Sie die Kontextlänge oder wechseln Sie zu einem kleineren Modell oder einer geringeren Quantisierung. Bevor Sie das Modell erneut herunterladen, erläutert was q4_K_M, q8_0 und fp16 jeweils an Speicher kosten und wo die Qualität tatsächlich abnimmt, wie viel Speicherplatz ein Schritt nach unten einbringt und welche Einbußen Sie dafür in Kauf nehmen.

FAQ

Kann ich Claude Code auf Ollama verweisen?

Ja, aber nicht mit einer OpenAI-kompatiblen URL. Claude Code verwendet die Anthropic Messages API, und Ollama stellt dieses Format unter /v1/messages am selben Port 11434 bereit. Exportieren Sie ANTHROPIC_BASE_URL=http://localhost:11434 und ANTHROPIC_AUTH_TOKEN=ollama und setzen Sie ANTHROPIC_API_KEY auf einen leeren Wert. Starten Sie den Dienst anschließend mit claude --model qwen3-coder:30b. ollama launch claude übernimmt diese Einstellungen automatisch. Die Kompatibilitätsschicht unterstützt tool_choice und Prompt-Caching nicht. Außerdem gibt es keinen Endpunkt zur Tokenzählung. Die gemeldeten Tokenzahlen sind daher Näherungswerte.

Warum antwortet mein lokales Modell zu Code, den es nicht sehen kann?

Weil die Anfrage nicht mehr in das Kontextfenster passt und der älteste Teil ohne Fehlermeldung entfernt wurde. Ollama legt den Standardkontext anhand des insgesamt erkannten VRAMs fest, nachdem der konfigurierte Overhead pro GPU abgezogen wurde: Unter 23 GiB beträgt der Standardwert 4,096 Tokens, von 23 bis unter 47 GiB beträgt er 32,768 Tokens und ab 47 GiB beträgt er 262,144 Tokens. Setzen Sie OLLAMA_CONTEXT_LENGTH=64000 in der systemd-Unit, starten Sie Ollama neu und prüfen Sie in ollama ps, ob die Spalte CONTEXT den neuen Wert anzeigt.

Welches Modell sollte ich für einen Coding-Agent auf einem VPS verwenden?

Wählen Sie das größte Modell mit dem Label tools, das mit einem Kontextfenster von 64k in den Arbeitsspeicher passt. Bevorzugen Sie ein für Code optimiertes Modell. qwen3-coder:30b ist die übliche Wahl auf einem GPU-Server mit ausreichend VRAM. Wenn dieses Modell für Ihren Server zu groß ist, sind die RAM-Werte und CPU-only-Geschwindigkeiten für Nemotron 3.5 Lightning ein nützlicher Vergleich, bevor Sie den Download starten. Unterhalb von ungefähr 14B Parametern kann ein Modell weiterhin Fragen zu Code gut beantworten, aber bei mehrstufigen Änderungen versagen. Agent-Aufgaben reagieren empfindlich auf kleine Formatierungsfehler in Tool-Aufrufen. Testen Sie das Modell mit einer echten Aufgabe aus Ihrem eigenen Repository statt mit einem Beispiel-Prompt.

Benötige ich eine GPU, um einen Coding-Agent mit meinem eigenen Modell auszuführen?

In der Praxis ja. CPU-only-Inferenz funktioniert und ist für einzelne Fragen ausreichend. Ein Agent sendet jedoch pro Aufgabe viele Anfragen, und jede Anfrage liest einen langen Verlauf erneut ein. Eine niedrige Tokenrate verlängert dadurch eine Aufgabe von zwei Minuten auf eine Stunde. Prüfen Sie die Spalte PROCESSOR in ollama ps: Jeder Wert außer 100% GPU bedeutet, dass ein Teil des Modells auf der CPU ausgeführt wird. Die Tokenrate sinkt dadurch deutlich.