Grundlagen lokaler KIs: Ollama, LLMs und OpenCode

Dieser Artikel beschreibt den Aufbau einer lokal gehosteten KI-Umgebung auf Basis von Ollama und Sprachmodellen wie Qwen3.6/Qwen3.8, sowie deren Nutzung über toolfähige CLI-Interfaces wie OpenCode. Darüberhinaus werden aber allerlei Grundlagen und manch Wissenswertes rund um diese Technologie erklärt, sodass man nach der Lektüre endlich mitreden kann :-).

Was sind LLMs?

Bevor es um Installation und praktischen Einsatz geht, klärt dieses Kapitel die Grundbegriffe: Was ist ein LLM eigentlich, was unterscheidet die verschiedenen Modellvarianten voneinander, und was lädt man sich genau herunter, wenn man sich ein Modell installiert?

Begriffsklärung: Large Language Model

Ein Large Language Model (LLM) ist ein neuronales Netz, das auf der sogenannten Transformer-Architektur basiert und auf sehr großen Textmengen trainiert wurde, typischerweise Milliarden bis Billionen Wörter aus Büchern, Webseiten, Quellcode und anderen Textquellen. Beim Training lernt das Modell statistische Zusammenhänge zwischen Wörtern bzw. Token und ist danach in der Lage, plausible Fortsetzungen von Text vorherzusagen. Aus dieser eigentlich einfachen Grundfunktion „sage das nächste Token voraus” entstehen in Kombination mit der schieren Modellgröße erstaunlich vielfältige Fähigkeiten wie Textverständnis, Zusammenfassung, Übersetzung, Codegenerierung oder dialogisches Antworten.

Training vs. Inferenz

Bei Sprachmodellen unterscheidet man grundsätzlich zwei Phasen:

Training (Pretraining/Finetuning)

Hier werden die Modellgewichte anhand riesiger Trainingsdatensätze angepasst. Das Pretraining erzeugt ein Basismodell mit allgemeinem Sprachverständnis; ein anschließendes Finetuning spezialisiert das Modell z.B. auf das Befolgen von Anweisungen, auf Dialogverhalten oder auf bestimmte Fachgebiete (etwa Programmierung). Training erfordert enorme Rechenleistung (sehr viele GPUs werden über Tage bis Wochen benötigt) und findet praktisch ausschließlich bei den Modellherstellern statt (z.B. Anthropic für die Claude-Modelle, Alibaba für die Qwen-Modellreihe, etc.).

Inferenz

Das ist die eigentliche Anwendung eines bereits trainierten Modells, also das Erzeugen einer Antwort auf Basis eines gegebenen Prompts. Genau das passiert, wenn ein Modell lokal mit Ollama ausgeführt wird: Die Modellgewichte werden geladen, und für jede Anfrage wird Token für Token eine Antwort berechnet. Inferenz ist deutlich weniger rechenintensiv als Training und lässt sich je nach Modellgröße auch auf gewöhnlicher, lokal vorhandener Hardware durchführen (siehe Das richtige Modell für die richtige Hardware).

Für den in diesem Artikel beschriebenen Anwendungsfall (lokal gehostete KI mit Ollama) ist ausschließlich die Inferenz relevant. Trainiert werden die Modelle bereits fertig von den jeweiligen Herstellern übernommen und lediglich heruntergeladen.

Parameteranzahl

Ein Sprachmodell besteht aus einer sehr großen Anzahl einzelner Zahlenwerte, den sogenannten Parametern bzw. Gewichten, die während des Trainings angepasst wurden. Die Parameteranzahl wird üblicherweise in Milliarden angegeben und ist fester Bestandteil des Modellnamens, z. B. 7b für 7 Milliarden oder 27b für 27 Milliarden Parameter (engl. 27 billion parameters).

Die Parameteranzahl wirkt sich direkt auf drei Aspekte aus:

• Qualität: Größere Modelle erfassen in der Regel komplexere Zusammenhänge, folgen Anweisungen zuverlässiger und neigen weniger zu Fehlern („Halluzinationen”). Die Unterschiede sind allerdings nicht linear und hängen stark vom konkreten Anwendungsfall ab.
• Geschwindigkeit: Mehr Parameter bedeuten mehr Rechenaufwand pro erzeugtem Token und damit eine niedrigere Antwortgeschwindigkeit bei gleicher Hardware.
• Ressourcenbedarf: Die Parameteranzahl bestimmt maßgeblich, wie viel Arbeitsspeicher (VRAM bzw. RAM) zum Laden des Modells benötigt wird (Details und Faustformeln dazu liefert Das richtige Modell für die richtige Hardware).

In der Praxis muss man also zwischen Antwortqualität, Geschwindigkeit und verfügbarer Hardware abwägen. Ein möglichst großes Modell ist nicht automatisch die richtige Wahl, wenn es auf der vorhandenen Hardware nur noch quälend langsam läuft oder gar nicht mehr vollständig geladen werden kann.

Basismodell vs. instruction-tuned/chat-optimiertes Modell

Nach dem Pretraining liegt zunächst ein Basismodell (base) vor. Es „kennt” Sprache und Fakten, ist aber primär darauf trainiert, Text plausibel fortzusetzen, jedoch nicht darauf, Fragen zu beantworten oder Anweisungen auszuführen. Spricht man ein reines Basismodell mit „Wie installiere ich Ollama unter Ubuntu?” an, führt das häufig eher zu einer Fortsetzung des Textes (z. B. weiteren, ähnlich formulierten Fragen) als zu einer hilfreichen Antwort.

Durch ein zusätzliches Finetuning, meist sogenanntes Instruction Tuning, teilweise ergänzt um Reinforcement Learning from Human Feedback (RLHF), entsteht daraus ein instruction-tuned bzw. chat-optimiertes Modell, häufig erkennbar am Namenszusatz instruct oder chat. Solche Modelle sind darauf trainiert, Anweisungen zu befolgen, im Dialogformat zu antworten und sich an ein vorgegebenes Rollen-/Systemprompt-Schema zu halten.

Für den praktischen Einsatz mit Ollama, OpenCode und ähnlichen Werkzeugen sind praktisch ausschließlich instruction-tuned bzw. chat-optimierte Varianten relevant. Reine Basismodelle spielen höchstens für spezielle Anwendungsfälle wie ein eigenes, nachgelagertes Finetuning eine Rolle und werden hier nicht weiter behandelt.

Was lädt man bei ollama.com/library tatsächlich herunter?

Führt man ollama pull qwen3.6:27b aus, wird kein Programm heruntergeladen, sondern ein Satz von Dateien, der im Kern aus den Modellgewichten sowie einigen Metadaten besteht.

Modellgewichte im GGUF-Format

Die eigentlichen Modellgewichte liegen im GGUF-Format vor (kurz für „GPT-Generated Unified Format”), einem von der llama.cpp-/Ollama-Community entwickelten Binärformat für Sprachmodelle. GGUF-Dateien enthalten die Gewichte dabei in aller Regel nicht mehr in voller Genauigkeit (z. B. 16-Bit-Gleitkommazahlen, fp16), sondern quantisiert, also mit reduzierter Zahlenpräzision. Dadurch verringern sich Downloadgröße und Speicherbedarf deutlich, auf Kosten einer meist geringen Einbuße an Antwortqualität. Details zu einzelnen Quantisierungsstufen und deren Auswirkungen behandelt Das richtige Modell für die richtige Hardware.

Aufbau eines Modell-Tags

Modelle werden bei Ollama über sogenannte Tags referenziert, beispielsweise:

qwen3.6:27b-instruct-q4_K_M

Ein solcher Tag setzt sich aus mehreren Bestandteilen zusammen:

Bestandteil	Bedeutung
qwen3.6	Modellname bzw. Modellfamilie
27b	Parametergröße (hier: 27 Milliarden Parameter)
instruct	Variante – hier ein instruction-tuned/chat-optimiertes Modell (siehe oben); alternativ z. B. base oder spezialisierte Varianten wie code
q4_K_M	Quantisierungsstufe, siehe Das richtige Modell für die richtige Hardware

Nicht jedes dieser Elemente muss im Tag explizit angegeben werden: Viele Modelle in der Ollama-Bibliothek definieren einen sinnvollen Default-Tag (meist eine instruction-tuned Variante mit einer gängigen mittleren Quantisierungsstufe), sodass z. B. bereits ollama pull qwen3.6:27b ohne weitere Zusätze ein direkt nutzbares Modell liefert.

Das Modelfile

Zu jedem Modell gehört außerdem ein sogenanntes Modelfile – eine von Ollama definierte Konfigurationsdatei mit unter anderem folgenden Angaben:

• Referenz auf die GGUF-Datei(en) mit den eigentlichen Modellgewichten
• Den Systemprompt, der dem Modell vorgibt, wie es sich verhalten soll (Rolle, Tonfall, Einschränkungen)
• Parameter-Defaults wie Temperatur (steuert Kreativität bzw. Zufälligkeit der Antworten), Kontextlänge und Stop-Token (Zeichenfolgen, bei denen die Textgenerierung abbricht)

Das Modelfile-Konzept erlaubt es zudem, eigene Modellvarianten auf Basis eines bestehenden Modells zu definieren, etwa mit angepasstem Systemprompt oder geänderten Parametern (siehe Was ist Ollama und welche Alternativen gibt es?).

Mitunter führen Hardwarebegrenzungen, vor allem ein zu knapper VRAM der Grafikkarte, zu Problemen bei der Inferenz, etwa zu Endlosschleifen oder einer Vermischung von JSON und Klartext in der Ausgabe. Ursache ist häufig, dass der für den Modellkontext zusätzlich benötigte Speicher nicht mehr vollständig ins VRAM passt und Teile davon in den deutlich langsameren Hauptspeicher ausweichen müssen, wodurch sich Antwortverhalten und -qualität des Modells spürbar verschlechtern können.

Durch Anpassung der Modellparameter (etwa einer kleineren Kontextlänge im Modelfile) lässt sich ein solches Verhalten häufig vermeiden. Ein Beispiel für das Anpassen von Modellparametern durch Anlegen eines eigenen Modelfile zeigt Das richtige Modell für die richtige Hardware.

Lizenzangaben

Jedes Modell in der Ollama-Bibliothek verweist auf die Lizenzbedingungen des jeweiligen Modellherstellers (z. B. Apache 2.0 oder eine herstellereigene „Community License”). Diese Angaben sind unabhängig von der Ollama-Software selbst und können sich zwischen Modellen deutlich unterscheiden – etwa hinsichtlich Einschränkungen bei kommerzieller Nutzung, Namensnennungspflichten oder Nutzungsbeschränkungen für bestimmte Anwendungsfälle. Vor einem produktiven bzw. kommerziellen Einsatz eines Modells sollte man die jeweilige Lizenz auf der Modellseite in der Ollama-Bibliothek prüfen.

Downloadgröße und Fähigkeiten

Die Downloadgröße eines Modells korreliert unmittelbar mit Parameteranzahl multipliziert mit der gewählten Quantisierungsstufe, nicht jedoch direkt mit den „Fähigkeiten” des Modells. Ein kleineres, aber neueres oder besser trainiertes Modell kann in bestimmten Anwendungsfällen einem größeren, älteren Modell durchaus überlegen sein. Die Downloadgröße ist somit ein Hinweis auf den Ressourcenbedarf, nicht auf die Qualität eines Modells.

Was ist Ollama und welche Alternativen gibt es?

Nachdem im vorigen Kapitel geklärt wurde, was ein LLM überhaupt ist und was man beim Herunterladen eines Modells tatsächlich erhält, geht es in diesem Kapitel um die Software, mit der man solche Modelle lokal betreibt: Ollama. Ergänzend werden gängige Alternativen kurz vorgestellt und eingeordnet.

Was ist Ollama?

Ollama ist ein lokaler Modell-Server für Sprachmodelle. Er übernimmt das Laden der Modellgewichte, die eigentliche Inferenz (siehe Was sind LLMs?) sowie die Verwaltung mehrerer Modelle und stellt darüber hinaus eine einheitliche Schnittstelle zur Verfügung, über die sich beliebige Anwendungen mit dem laufenden Modell verbinden können. Als Inferenz-Engine unter der Haube nutzt Ollama llama.cpp. Dies ist eine hocheffiziente, in C/C++ geschriebene Bibliothek zur Ausführung quantisierter GGUF-Modelle auf CPU und GPU. Ollama selbst ergänzt diese Engine um Komfortfunktionen wie Modellverwaltung, eine REST-API (damit Programme/Tools auch von anderen Rechnern aus die Inferenz anfragen können) und das Modelfile-Konzept.

Kernkonzepte

Modell-Registry (ollama pull)

Ollama betreibt eine eigene Modell-Registry (https://ollama.com/library), aus der sich Modelle mit einem einzigen Befehl herunterladen lassen, z.B. ollama pull qwen3.6:27b. Der Aufbau der dabei verwendeten Modell-Tags wurde bereits in Was sind LLMs? erläutert.

Lokaler Modell-Cache

Einmal heruntergeladene Modelle werden lokal zwischengespeichert (unter Linux standardmäßig in /usr/share/ollama/.ollama/models bzw. ~/.ollama/models, abhängig von der Installationsart) und stehen danach ohne erneuten Download zur Verfügung. Mehrere lokal installierte Modelle können parallel vorgehalten werden, auch wenn zur Laufzeit jeweils nur ein Teil davon tatsächlich geladen ist.

Die aktuell installierten Modelle lassen sich mit ollama list anzeigen.

REST-API

Ollama stellt standardmäßig unter Port 11434 eine REST-API bereit, über die sich Anfragen an ein Modell stellen lassen (/api/generate, /api/chat) sowie Modelle verwaltet werden können. Diese API ist die Grundlage dafür, dass beliebige Programme, von einfachen curl-Aufrufen bis zu vollwertigen CLI-Werkzeugen wie OpenCode (siehe OpenCode-CLI), mit einem lokal laufenden Modell kommunizieren können, ohne selbst eine Inferenz-Engine mitbringen zu müssen. Ein praktisches Beispiel dazu folgt in Zugriff über die REST-API.

Das Modelfile-Konzept

Wie bereits in Was sind LLMs? beschrieben, bringt jedes Modell in der Ollama-Bibliothek ein Modelfile mit Metadaten, Systemprompt und Parameter-Defaults mit. Darüber hinaus erlaubt Ollama, eigene Modelfiles zu schreiben und darauf basierend eigene Modellvarianten zu erzeugen. Damit kann man etwa einen festen Systemprompt hinterlegen, Parameter wie die Temperatur anders voreinstellen oder ein bestehendes Modell unter einem eigenen Namen mit abweichender Konfiguration bereitstellen. Das ist beispielsweise nützlich, um für einen bestimmten Anwendungsfall (z. B. Codeassistenz) ein vorkonfiguriertes Modell bereitzuhalten, ohne bei jeder Anfrage erneut Systemprompt und Parameter mitgeben zu müssen.

Verwaltung mehrerer Modelle

Ollama kann beliebig viele Modelle lokal vorhalten, lädt zur Laufzeit aber nur die tatsächlich angefragten Modelle in den Arbeitsspeicher bzw. VRAM. Wird ein Modell eine gewisse Zeit lang nicht mehr verwendet, entlädt Ollama es automatisch wieder (Idle-Timeout, standardmäßig einige Minuten, konfigurierbar), um Speicher für andere Modelle oder Anwendungen freizugeben. Beim nächsten Zugriff wird das Modell bei Bedarf automatisch erneut geladen. Dies kostet abhängig von Modellgröße und Hardware einen kurzen Moment, danach steht das Modell wieder mit voller Geschwindigkeit zur Verfügung. Welche Modelle aktuell geladen sind, lässt sich jederzeit abfragen (siehe Ollama-Installation).

Plattformen

Ollama steht offiziell für Linux, macOS und Windows zur Verfügung und lässt sich zusätzlich als offizielles Docker-Image betreiben, was insbesondere für Server- oder Container-Umgebungen interessant ist. Die konkrete Installation unter Linux wird im nächsten Kapitel beschrieben.

Alternativen zu Ollama

Ollama ist bei Weitem nicht die einzige Möglichkeit, LLMs lokal zu betreiben. Je nach Anwendungsfall – grafische Bedienung, maximale Kontrolle, hoher Durchsatz für mehrere Nutzer – kann eine der folgenden Alternativen besser passen.

LM Studio

Eine grafische Desktop-Anwendung, die ebenfalls auf llama.cpp als Inferenz-Engine aufbaut, den Fokus aber stärker auf eine bedienerfreundliche GUI legt: Modellsuche, Download und Chat-Oberfläche sind direkt in die Anwendung integriert. Für Nutzer, die kein Terminal verwenden möchten, ist LM Studio oft der einfachere Einstieg als Ollama.

llama.cpp (direkt)

Die zugrundeliegende Inferenz-Engine, auf der sowohl Ollama als auch LM Studio aufbauen, lässt sich auch direkt verwenden. Das bietet die größtmögliche Kontrolle über Kompilierungsoptionen, Laufzeitparameter und unterstützte Hardware-Backends, erfordert im Gegenzug aber deutlich mehr manuelle Konfiguration als die komfortableren Aufsätze darüber.

vLLM

Eine Inferenz-Engine mit Fokus auf Hochdurchsatz- und Multi-User-Betrieb, u. a. durch Techniken wie kontinuierliches Batching mehrerer gleichzeitiger Anfragen. vLLM richtet sich eher an Server- bzw. Produktivbetrieb, bei dem viele Anfragen parallel bedient werden müssen, als an den Einzelplatz-/Desktop-Einsatz, um den es in diesem Artikel primär geht.

text-generation-webui (oobabooga)

Eine Web-Oberfläche mit Unterstützung für verschiedene Inferenz-Backends (u. a. llama.cpp) sowie einem umfangreichen Ökosystem an Erweiterungen, z. B. für Sprachausgabe, Bildgenerierung oder alternative Chat-Modi. Entsprechend flexibel, aber auch komplexer in der Konfiguration als ein reiner Ollama-Aufbau.

GPT4All

Eine Desktop-Anwendung mit Fokus auf einfache Bedienung und einem eigenen, kuratierten Modellkatalog. Richtet sich in erster Linie an Nutzer, die ohne größere Vorkenntnisse schnell ein lokales Modell ausprobieren möchten.

Jan

Eine quelloffene Desktop-Anwendung mit einer an ChatGPT angelehnten Bedienoberfläche. Wie LM Studio und GPT4All liegt der Schwerpunkt auf einer zugänglichen grafischen Oberfläche statt auf CLI-/API-zentrierter Nutzung.

LocalAI

Ein lokaler Server, der eine zur OpenAI-API kompatible Schnittstelle bereitstellt und dabei mehrere unterschiedliche Backends (u. a. llama.cpp) unter einer gemeinsamen API vereint. Interessant, wenn bestehende Anwendungen, die eigentlich für die OpenAI-API geschrieben wurden, ohne Codeänderungen gegen ein lokales Modell laufen sollen.

Kurzvergleich

Werkzeug	Bedienung	API-Kompatibilität	Multi-User	Ressourcenmanagement
Ollama	CLI + REST-API	eigene REST-API (+ teilweise OpenAI-kompatibel)	eingeschränkt	automatisches Laden/Entladen (Idle-Timeout)
LM Studio	GUI	eigene GUI, lokaler OpenAI-kompatibler Server	nein (Desktop-fokussiert)	manuell über GUI
llama.cpp (direkt)	CLI	eigener Server mit OpenAI-kompatiblem Modus	eingeschränkt	manuell (Startparameter)
vLLM	CLI/API	OpenAI-kompatible API	ja, für Hochdurchsatz ausgelegt	für Serverbetrieb optimiert (Batching)
text-generation-webui	Web-UI	mehrere Backends, teils OpenAI-kompatibel	eingeschränkt	manuell über UI
GPT4All	GUI	eigene GUI, eingeschränkte API	nein (Desktop-fokussiert)	manuell über GUI
Jan	GUI	eigene GUI, lokaler OpenAI-kompatibler Server	nein (Desktop-fokussiert)	manuell über GUI
LocalAI	API/CLI	vollständig OpenAI-kompatibel	ja	konfigurierbar über Server-Einstellungen

Für die in diesem Artikel beschriebene Zielsetzung – lokal gehostete KI mit toolfähigem CLI-Zugriff über OpenCode (siehe OpenCode-CLI) – bietet Ollama mit seiner Kombination aus einfacher Installation, REST-API und automatischem Ressourcenmanagement den besten Kompromiss und wird daher im weiteren Verlauf verwendet.

Ollama-Installation

Dieses Kapitel beschreibt die Installation von Ollama unter Linux, zunächst am konkreten Beispiel von Ubuntu, danach allgemeiner für andere Distributionen. Außerdem wird der erste praktische Umgang mit Ollama und einem heruntergeladenen Modell demonstriert.

Installation unter Ubuntu 24.04 (und neueren Versionen)

Installationsskript

Der offizielle und empfohlene Weg zur Installation von Ollama unter Linux ist das Installationsskript, das direkt von der Ollama-Webseite bezogen wird:

curl -fsSL https://ollama.com/install.sh | sh

Derselbe Befehl wird auch für spätere Aktualisierungen verwendet: Ein erneuter Aufruf erkennt eine bestehende Installation und aktualisiert sie auf die aktuelle Version, ohne bestehende Modelle oder Konfiguration zu verlieren.

Was das Skript im Hintergrund einrichtet

Das Installationsskript nimmt dem Nutzer mehrere Schritte ab:

• Es lädt das Ollama-Binary herunter und legt es systemweit ab (üblicherweise unter /usr/local/bin/ollama).
• Es legt einen eigenen Systembenutzer ollama an, unter dessen Rechten der Ollama-Dienst später läuft (bewusst getrennt vom eigenen Benutzerkonto, u. a. aus Sicherheitsgründen).
• Es richtet einen systemd-Dienst ollama.service ein und aktiviert dessen Autostart, sodass Ollama nach jedem Systemstart automatisch als Hintergrunddienst zur Verfügung steht.

Dienststatus prüfen

Ob der Dienst korrekt läuft, lässt sich mit den üblichen systemd-Bordmitteln prüfen:

# Status des Diensts anzeigen
systemctl status ollama

# Live-Logs des Diensts verfolgen
journalctl -u ollama -f

Da der Dienst über systemd bereits standardmäßig aktiviert (enabled) ist, ist nach der Installation keine weitere manuelle Konfiguration für den Autostart nötig.

GPU-Unterstützung

Ollama nutzt automatisch eine vorhandene GPU, sofern die nötigen Treiber- und Laufzeitkomponenten installiert sind. Andernfalls fällt es ohne weiteres dazutun auf reine CPU-Inferenz zurück, was insbesondere bei größeren Modellen deutlich langsamer ist.

Um zu prüfen, ob die Inferenz tatsächlich auf der GPU ausgeführt wird, lohnt sich die Verwendung des Tools btop, welches die Verwendung der GPU zeigt.

Für NVIDIA-GPUs (wie die in Das richtige Modell für die richtige Hardware beschriebene Blackwell-Generation) wird ein aktueller proprietärer NVIDIA-Treiber benötigt; das CUDA-Toolkit selbst muss in der Regel nicht separat installiert werden, da Ollama die benötigten CUDA-Laufzeitbibliotheken mitbringt. Für ganz neue GPU-Generationen wie Blackwell ist es dennoch ratsam, einen möglichst aktuellen Treiber zu verwenden, da die Unterstützung für neue Architekturen erst mit neueren Treiberversionen vollständig einzieht.

Ob die GPU erkannt wurde, zeigt sich beim Start eines Modells in den Logs (journalctl -u ollama -f) sowie in der Ausgabe von nvidia-smi, während ein Modell geladen ist.

$ nvidia-smi
Tue Aug 11 11:58:42 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.173.02             Driver Version: 580.173.02     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX PRO 4500 Blac...    Off |   00000000:01:00.0 Off |                  Off |
| 30%   44C    P1             74W /  200W |    5723MiB /  32623MiB |     95%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A         2301916      G   /usr/bin/gnome-shell                      4MiB |
|    0   N/A  N/A         2460693      C   ...local/lib/ollama/llama-server       5700MiB |
+-----------------------------------------------------------------------------------------+

Installation unter anderen Linux-Distributionen

Generisches Vorgehen vs. manuelle Installation

Das oben gezeigte Installationsskript ist nicht auf Ubuntu beschränkt, sondern funktioniert distributionsunabhängig auf den meisten gängigen systemd-basierten Linux-Systemen, da es die jeweilige Paketverwaltung erkennt und passende Abhängigkeiten nachinstalliert. Alternativ kann Ollama auch manuell installiert werden, indem lediglich das Binary aus den offiziellen Releases heruntergeladen und der systemd-Dienst von Hand eingerichtet wird. Das gibt mehr Kontrolle über den Installationsort und ist z. B. auf Systemen ohne systemd oder in restriktiveren Umgebungen sinnvoll.

Informationen zur Installation unter den unterschiedlichsten Betriebssystemen gibt es auf der offiziellen ollama-Download-Webseite.

Docker-/Container-Variante

Wer Ollama nicht direkt auf dem Host-System, sondern containerisiert betreiben möchte, kann das offizielle Docker-Image verwenden:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Die Option --gpus=all setzt eine funktionierende NVIDIA-Container-Toolkit-Installation auf dem Host voraus; ohne diese Option läuft der Container auf CPU-Inferenz. Das benannte Volume ollama:/root/.ollama sorgt dafür, dass heruntergeladene Modelle einen Container-Neustart überdauern.

Update und Deinstallation

Ein manuelles Update erfolgt – unabhängig von der gewählten Installationsart über das offizielle Skript – durch erneutes Ausführen desselben Installationsbefehls. Eine automatische Hintergrundaktualisierung wie bei den Desktop-Varianten für macOS/Windows gibt es unter Linux bewusst nicht; Updates erfolgen aktiv und kontrolliert durch den Nutzer.

Zum vollständigen Entfernen von Ollama sind mehrere Schritte nötig, da das Installationsskript selbst keinen Deinstallations-Befehl mitbringt:

# Dienst stoppen und deaktivieren
sudo systemctl stop ollama
sudo systemctl disable ollama

# Dienst-Definition, Binary und heruntergeladene Modelle entfernen
sudo rm /etc/systemd/system/ollama.service
sudo rm $(which ollama)
sudo rm -r /usr/share/ollama

# eigens angelegten Systembenutzer/-gruppe entfernen
sudo userdel ollama
sudo groupdel ollama

Beispielhafte Verwendung von Ollama und einem LLM-Modell

Modell herunterladen und Chat im Terminal

Ein Modell wird mit ollama pull heruntergeladen (siehe Was sind LLMs? zum Aufbau des dabei verwendeten Modell-Tags):

ollama pull qwen3.6:27b

Für einen schnellen interaktiven Test lädt ollama run das Modell bei Bedarf automatisch herunter und öffnet direkt einen Chat im Terminal:

ollama run qwen3.6:27b

In diesem Chatfenster kann man nun klassisch mit dem Chatbot quasseln:

$ ollama run qwen3.6:27b

Typische Ausgabe im Chatfenster:

Die englischen Ausgaben zwischen Thinking… und …done thinking werden im Chat mit grauem Text geschrieben und sind temporäre Antworten des Modells vor der Übersetzung in die Zielsprache.

Nützliche Shortcuts im Chat sind:

• Ctrl+C: aktuellen Prompt abbrechen
• Cursor hoch/runter: durch die Historie der Prompts scrollen
• Ctrl+D: Chat beenden

Modelle verwalten

Zur Verwaltung lokal installierter bzw. gerade geladener Modelle stehen folgende Befehle zur Verfügung:

# alle lokal heruntergeladenen Modelle auflisten
ollama list

# ein lokal installiertes Modell löschen
ollama rm qwen3.6:27b

# aktuell im Speicher (VRAM/RAM) geladene Modelle anzeigen
ollama ps

ollama ps ist besonders beim Zusammenspiel mit dem in Was ist Ollama und welche Alternativen gibt es? beschriebenen Idle-Timeout hilfreich, um zu prüfen, ob ein Modell aktuell tatsächlich geladen ist oder gerade neu geladen werden muss.

Zugriff über die REST-API

Da Ollama intern über eine REST-API angesprochen wird, lässt sich dieselbe Funktionalität auch direkt mit curl nutzen, ohne die interaktive Chat-Oberfläche zu verwenden:

# Eine Anfrage stellen
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3.6:27b",
  "prompt": "Warum ist der Himmel blau?",
  "stream": false
}'

# Die Antwort (gekürzt)
{"model":"qwen3.6:27b","created_at":"2026-08-11T10:03:38.474807163Z","response":"Der Himmel erscheint blau aufgrund eines physikalischen Phänomens namens **Rayleigh-Streuung**.\n\nHier die Erklärung im Detail:...","done":true,"done_reason":"stop","context":[248045,....,13],"total_duration":21294755

Für dialogorientierte Anfragen mit mehreren Nachrichten (System-/Nutzer-/Assistenten-Rollen) steht analog der Endpunkt /api/chat zur Verfügung. Auf genau dieser REST-API bauen später auch CLI-Werkzeuge wie OpenCode auf (siehe OpenCode-CLI).

Neben seiner eigenen, nativen REST-API (/api/generate, /api/chat, …) bietet Ollama zusätzlich einen zur OpenAI-API kompatiblen Endpunkt unter /v1 an, u. a. /v1/chat/completions, /v1/completions und /v1/models. Dieses von OpenAI geprägte Schema hat sich mittlerweile als De-facto-Standard etabliert: Sehr viele Bibliotheken, SDKs und Tools sprechen bereits „die OpenAI-API” und lassen sich dadurch ohne Codeänderung gegen einen lokalen Ollama-Server statt gegen die Cloud-API von OpenAI richten. Dadurch genügt es, Basis-URL, Modellname und ggf. ein Platzhalter-API-Key anzupassen. Genau dieser kompatible Endpunkt kommt z. B. bei der Anbindung von OpenCode an Ollama zum Einsatz (siehe OpenCode-CLI). Aus demselben Grund bieten auch andere lokale Server wie LM Studio oder LocalAI einen OpenAI-kompatiblen Endpunkt an. Erst die Einigung auf ein gemeinsames Schema macht Modellserver in den verwendenden Tools weitgehend austauschbar.

Die standardisierte OpenAI-API kann wie folgt angesprochen werden:

# Erfrage verfügbare Modelle
curl -s http://localhost:11434/v1/models

# Eine Anfrage stellen
curl -s http://localhost:11434/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
      "model": "llama3:latest",
      "messages": [
        {"role": "user", "content": "Sag in einem Satz, wie es Dir als KI so geht!"}
      ]
    }'

# Die Antwort:
{"id":"chatcmpl-994","object":"chat.completion","created":1786441194,"model":"llama3:latest",
"system_fingerprint":"fp_ollama","choices":[{"index":0,"message":{"role":"assistant",
"content":"Ich bin ein Computerprogramm, daher erfahre ich die Welt nur durch meine Trainingsdaten und haben keine eigenen Gefühle oder Erinnerungen. Aber auch als Maschine habe ich einen eigenen Charakter - ich bin eine Sammlung von Regeln, Algorithmen und Wissenschaftskennzahlen, die mich dazu befähigen, mit Ihnen zu kommunizieren und auf Fragen zu antworten!"},"finish_reason":"stop"}], "usage":{"prompt_tokens":26,"completion_tokens":88,"total_tokens":114}}

Man kann über die oben gezeigte REST-API eine KI Anfrage auch einfach in eigene Programme integrieren. Einfach das Anfrage JSON-Paket formulieren, curl aufrufen und das Antwort-JSON parsen.

Netzwerkzugriff über OLLAMA_HOST und angepasste Konfiguration

Nach der Installation ist Ollama bereits so konfiguriert, dass es auch von anderen Rechnern im Netzwerk erreichbar ist. Diese Konfiguration wird über das Setzen der Umgebungsvariable OLLAMA_HOST=0.0.0.0:11434 erreicht.

Ollama hat für derartige Umgebungsvariablen eine eigene Konfigurationsdatei /etc/systemd/system/ollama.service.d/override.conf. In diese Datei kann man auch noch andere sinnvolle Umgebungsvariablen eintragen, wie bspw. die Zeit, die Ollama ein geladenes Modell vorhalten soll, bevor es aus dem GPU Speicher entladen wird.

Konfigurationsdatei /etc/systemd/system/ollama.service.d/override.conf:

Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=30m"

Nach dem Ändern dieser Datei den Dienst neu laden und neu starten:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Gegebenenfalls muss man noch eine laufende Firewall für den Port 11434 öffnen.

Ob der Dienst auch über das Netzwerk erreichbar ist, lässt sich von einem anderen Rechner aus testen.

In dieser Anleitung wird der auf der Simulationsworkstation installierte Ollama-Server beschrieben. Statt einer konkreten Adresse wird nachfolgend in allen Konfigurationsbeispielen und Kommandozeilen der Platzhalter <OLLAMA_IP> verwendet – er steht für die IP-Adresse bzw. den Hostnamen des Ollama-Servers und ist bei eigenen Aufrufen durch dessen tatsächliche Adresse zu ersetzen.

curl http://<OLLAMA_IP>:11434
Ollama is running

Die Ollama-REST-API bringt standardmäßig keinerlei Authentifizierung mit. Wer OLLAMA_HOST=0.0.0.0 setzt, macht den Dienst für jeden erreichbar, der Zugriff auf das jeweilige Netzwerksegment hat. Für den Einsatz im eigenen, vertrauenswürdigen Heim-/Firmennetz ist das in der Regel akzeptabel, sollte aber bewusst so entschieden und nicht versehentlich in ein öffentlich erreichbares Netzwerk exponiert werden. Details zur Einrichtung dieses Zugriffs für OpenCode folgen in OpenCode-CLI.

Sprachmodell-Interfaces: webbasiert ohne Dateizugriff

Die bisherigen Kapitel haben Ollama installiert und den direkten Zugriff über Terminal und REST-API gezeigt (siehe Ollama-Installation). Für den täglichen Gebrauch ist eine Terminal-Sitzung (siehe Modell herunterladen und Chat im Terminal) oder ein roher curl-Aufruf aber selten komfortabel genug. Dieses Kapitel beschreibt daher die erste von mehreren Stufen komfortablerer Interfaces: webbasierte Chat-Oberflächen, die sich auf reine Konversation mit einem Modell beschränken.

Konzept

Eine webbasierte Chat-Oberfläche läuft als eigener Dienst (typischerweise per Docker-Container) und spricht im Hintergrund über dieselbe REST-API mit Ollama, die bereits in Zugriff über die REST-API per curl demonstriert wurde. Bedient wird sie über den Browser wie eine gewohnte Chat-Anwendung à la ChatGPT: Modell auswählen, Nachricht eingeben, Antwort erhalten.

Entscheidend für die Einordnung ist, was eine solche Oberfläche nicht kann:

• Sie hat keinen Zugriff auf das lokale Dateisystem und kann keine externen Werkzeuge (Shell-Befehle, Codeausführung, Dateisuche o. ä.) aufrufen, selbst wenn das zugrundeliegende Modell dazu grundsätzlich in der Lage wäre (siehe Toolfähigkeit).
• Die Oberfläche stellt lediglich Anfragen an /api/chat bzw. den OpenAI-kompatiblen Endpunkt und reicht die Antwort unverändert an den Browser weiter.

Diese Abgrenzung ist bewusst gewählt: Ohne Werkzeugzugriff bleibt die Angriffsfläche gering und die Bedienung bleibt für Anwender ohne Terminal-Erfahrung zugänglich. Wer dagegen Dateizugriff oder Tool-Aufrufe benötigt, ist bei den in CLI-Interfaces mit Dateizugriff und OpenCode-CLI beschriebenen CLI-Werkzeugen an der richtigen Adresse.

Trotz dieser Einschränkung hat eine Web-Oberfläche gegenüber dem reinen Terminal-Chat (ollama run …) klare Vorteile:

• Übersichtlicher Chat-Verlauf mit mehreren parallelen Konversationen
• Bequemer Wechsel zwischen mehreren lokal installierten Modellen per Dropdown
• Zugriff durch mehrere Nutzer im Netzwerk über denselben Ollama-Server, jeweils mit eigenem Chat-Verlauf
• Formatierte Darstellung von Markdown, Code-Blöcken und (je nach Modell) Bildern

Beispiel: Open WebUI

Die nachfolgende Erklärung zur Nutzung einer Web-Chat-Bot Oberfläche soll nur der Illustration einer typischen KI-Chat-Anwendung dienen. Weitaus nützlicher (vor allem für produktive Aufgaben in der Programmierung und dateibasierten Recherche/Dokumentationsarbeit) sind die toolfähigen KI-Programme. Wer also an KI-Systemen mit Dateisystemzugriff und Agentenunterstützung interessiert ist, kann getrost zu Toolfähigkeit vorspringen.

Kurzbeschreibung

Open WebUI ist die im Ollama-Umfeld gebräuchlichste quelloffene Web-Oberfläche. Sie wird selbst als Docker-Container betrieben, ist von der eigentlichen Ollama-Installation unabhängig und verbindet sich über die REST-API mit einem oder mehreren Ollama-Servern. Da beide Komponenten unabhängig voneinander laufen, kann Open WebUI auf demselben Rechner wie Ollama betrieben werden oder auf einem anderen Rechner im Netzwerk, sofern der Ollama-Server dort erreichbar ist (siehe „Netzwerkzugriff über OLLAMA_HOST” in Ollama-Installation).

Installation via Docker (Linux und Windows)

Da Open WebUI selbst als Docker-Container läuft, ist die Installation auf Linux und Windows identisch, sofern Docker (unter Windows: Docker Desktop, i. d. R. mit WSL2-Backend) bereits eingerichtet ist:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

Die einzelnen Optionen im Überblick:

• -p 3000:8080 macht die Weboberfläche auf dem Host unter Port 3000 erreichbar
• --add-host=host.docker.internal:host-gateway erlaubt es dem Container, den auf dem Host laufenden Ollama-Dienst über host.docker.internal anzusprechen, obwohl er selbst in einem eigenen Docker-Netzwerk läuft
• Das benannte Volume open-webui:/app/backend/data sorgt dafür, dass Chat-Verläufe, Nutzerkonten und Einstellungen einen Container-Neustart überdauern

Nach dem Start ist die Oberfläche unter http://localhost:3000 erreichbar. Der erste Aufruf legt ein Administratorkonto an; jeder weitere Aufruf verlangt eine reguläre Anmeldung. Dieses einfache Nutzerkonzept ist bereits die Grundlage für die oben erwähnte Mehrnutzerfähigkeit.

Läuft Ollama nicht auf demselben Rechner wie der Open-WebUI-Container, muss zusätzlich die Umgebungsvariable OLLAMA_BASE_URL gesetzt werden (Option -e OLLAMA_BASE_URL=http://<OLLAMA_IP>:11434 beim docker run-Aufruf), damit Open WebUI den richtigen Server findet.

Installation via pip (Alternative)

Wer kein Docker verwenden möchte, kann Open WebUI alternativ direkt als Python-Paket installieren und betreiben:

pip install open-webui
open-webui serve

Der Dienst ist danach standardmäßig unter http://localhost:8080 erreichbar. Da Open WebUI nativ auf dem Host läuft, entfällt der bei der Docker-Variante nötige Umweg über host.docker.internal: Ein auf demselben Rechner laufendes Ollama wird über das gewohnte localhost:11434 gefunden.

Open WebUI ist fest auf Python 3.11 ausgelegt; mit neueren Python-Versionen kommt es erfahrungsgemäß zu Installations- oder Laufzeitproblemen. Es empfiehlt sich daher, für die Installation gezielt eine virtuelle Umgebung mit Python 3.11 anzulegen, statt das System-Python zu verwenden.

Gegenüber der Docker-Variante ergeben sich dabei folgende Abwägungen:

• Vorteile: kein Docker/Docker Desktop nötig, kein Netzwerk-Workaround für die Verbindung zu einem lokal laufenden Ollama, geringerer Ressourcen-Overhead, direkter Zugriff auf das Dateisystem des Hosts – praktisch für schnelles Ausprobieren auf einem Entwicklerrechner.
• Nachteile: Abhängigkeit von einer passenden Python-Version, keine saubere Isolation von anderen Python-Paketen auf demselben System, kein eingebauter Autostart-/Neustart-Mechanismus (müsste händisch z. B. per systemd-Dienst nachgebaut werden) und ein weniger klar definiertes Datenverzeichnis als beim benannten Docker-Volume. Updates erfolgen manuell per pip install --upgrade open-webui, ohne das saubere Rollback-Modell eines neu gezogenen Docker-Images.

Für den produktiven oder mehrnutzerfähigen Einsatz ist die Docker-Variante daher die robustere und empfohlene Wahl; die pip-Installation eignet sich vor allem für lokales Testen ohne Docker-Unterbau.

Verbindung zu Ollama konfigurieren

Läuft Ollama auf demselben Host, erkennt Open WebUI über host.docker.internal:11434 in aller Regel automatisch einen bereits laufenden Ollama-Dienst; ein manueller Konfigurationsschritt entfällt dann. Ob die Verbindung steht, zeigt sich direkt nach der Anmeldung: Im Modellauswahl-Dropdown erscheinen alle Modelle, die zuvor per ollama pull heruntergeladen wurden (siehe Ollama-Installation).

Zusätzliche oder alternative Ollama-Server lassen sich nachträglich über die Admin-Einstellungen („Settings → Connections”) eintragen, etwa um Modelle mehrerer Ollama-Instanzen im selben Netzwerk über eine einzige Oberfläche zusammenzuführen.

Typische Funktionen

• Modellwahl: Umschalten zwischen allen auf dem verbundenen Ollama-Server verfügbaren Modellen per Dropdown, auch innerhalb eines laufenden Chats
• Chat-Verlauf: Beliebig viele parallele Konversationen, durchsuchbar und exportierbar
• Mehrere Nutzer/Profile: Eigene Konten mit jeweils eigenem Chat-Verlauf; Administratoren können Rollen und Zugriffsrechte auf Modelle einschränken
• Systemprompt/Parameter pro Chat: Temperatur, Systemprompt und weitere Modelfile-Parameter (siehe Was sind LLMs?) lassen sich pro Konversation überschreiben, ohne das zugrunde liegende Modell dauerhaft zu verändern

Open WebUI bringt eine Vielzahl weiterer Funktionen mit, die über reine Konversation hinausgehen – etwa das Hochladen von Dokumenten zur Beantwortung von Fragen darüber (Retrieval-Augmented Generation) oder Websuche-Integrationen. Diese Funktionen fallen streng genommen bereits unter Werkzeugnutzung im Sinne von Toolfähigkeit und werden hier nicht weiter behandelt, da der Fokus ab CLI-Interfaces mit Dateizugriff auf CLI-basierten, toolfähigen Interfaces liegt.

Toolfähigkeit: Wenn ein Sprachmodell mehr als nur Text erzeugt

Die bisherigen Kapitel haben Ollama über Terminal, REST-API (siehe Zugriff über die REST-API) und Web-Oberfläche (siehe Sprachmodell-Interfaces: webbasiert ohne Dateizugriff) angesprochen. In allen drei Fällen beschränkt sich das Modell darauf, aus einem Prompt eine Textantwort zu erzeugen. Bevor es in den folgenden Kapiteln um CLI-Werkzeuge mit Datei- und Shell-Zugriff wie OpenCode geht (siehe CLI-Interfaces mit Dateizugriff und OpenCode-CLI), klärt dieses Kapitel die dafür nötige Grundlage: Was bedeutet „Toolfähigkeit” bei einem Sprachmodell eigentlich, und wie funktioniert der Mechanismus dahinter technisch?

Definition: Tool Use / Function Calling

Mit Tool Use bzw. Function Calling bezeichnet man die Fähigkeit eines Sprachmodells, statt einer reinen Textantwort einen strukturierten Aufruf einer zuvor beschriebenen Funktion zu erzeugen. Das kann etwa „lies die Datei README.md” oder „führe den Shell-Befehl ls -la aus” sein. Das Modell selbst führt dabei nichts aus. Es formuliert lediglich, in einem festen JSON-Schema, welche Funktion mit welchen Parametern aufgerufen werden soll. Die eigentliche Ausführung obliegt dem aufrufenden Programm.

Ein vollständiger Tool-Use-Zyklus läuft dabei immer in denselben vier Schritten ab:

1. Das aufrufende Programm (der Host, z. B. OpenCode) schickt dem Modell zusätzlich zur eigentlichen Nachricht eine Liste verfügbarer Funktionen inklusive Name, Beschreibung und Parameterschema.
2. Entscheidet sich das Modell, eine dieser Funktionen zu nutzen, antwortet es nicht mit Fließtext, sondern mit einem strukturierten Funktionsaufruf (Name plus Parameterwerte als JSON).
3. Der Host führt die angeforderte Aktion tatsächlich aus, beispielsweise eine Datei lesen, einen Shell-Befehl ausführen oder eine Websuche starten. Das Ergebnis schickt das Tool als neue Nachricht zurück an das Modell. Deswegen ist es auch notwendig, dass ein so aufgerufenes Tool immer auch irgendeine Art von Ausgabe erzeugt.
4. Das Modell setzt die Konversation mit diesem zusätzlichen Wissen fort, entweder mit einer finalen Textantwort oder mit einem weiteren Funktionsaufruf.

Diese Schleife aus Aufruf, Ausführung und Rückgabe kann sich mehrfach wiederholen, bevor das Modell eine abschließende Antwort formuliert. Genau das macht aus einem einfachen Chatbot ein agentisches System, wie es die CLI-Werkzeuge in den folgenden Kapiteln nutzen.

Die von einem Tool erzeugte Ausgabe (Inhalt einer Datei, Verzeichnisliste, ausgelesene Netzwerkkommunikation) wird an das Modell übertragen, und das auch noch im Klartext im Netzwerk, falls die Kommunikation zum Model-Server nicht verschlüsselt (d.h. via https) geschieht. Das sollte man im Hinterkopf behalten, wenn man IP Schutz ernst nimmt.

Der Ablauf im Detail (Beispiel via REST-API)

Am konkretesten wird das Prinzip anhand der bereits aus Zugriff über die REST-API bekannten Ollama-API. Der Aufruf von /api/chat erhält dazu ein zusätzliches Feld tools, das die verfügbaren Funktionen als JSON-Schema beschreibt – hier am Beispiel einer einfachen read_file-Funktion, wie sie so oder ähnlich auch von echten CLI-Agenten genutzt wird:

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3.6:27b",
  "messages": [
    { "role": "user", "content": "Was steht in der Datei README.md?" }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "read_file",
        "description": "Liest den Inhalt einer Textdatei vom lokalen Dateisystem",
        "parameters": {
          "type": "object",
          "properties": {
            "path": { "type": "string", "description": "Pfad zur Datei" }
          },
          "required": ["path"]
        }
      }
    }
  ],
  "stream": false
}'

Statt einer Textantwort liefert das Modell nun einen strukturierten Funktionsaufruf zurück (Ausgabe gekürzt):

{
  "message": {
    "role": "assistant",
    "content": "",
    "tool_calls": [
      { "function": { "name": "read_file", "arguments": { "path": "README.md" } } }
    ]
  },
  "done": true
}

An dieser Stelle greift Ollama an keiner Stelle in das Dateisystem zu, sondern liefert lediglich die Absicht des Modells zurück. Der Host muss read_file("README.md") nun selbst ausführen, den gelesenen Dateiinhalt als neue Nachricht mit "role": "tool" an die bisherige Konversation anhängen und erneut an /api/chat schicken:

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3.6:27b",
  "messages": [
    { "role": "user", "content": "Was steht in der Datei README.md?" },
    { "role": "assistant", "content": "",
      "tool_calls": [ { "function": { "name": "read_file", "arguments": { "path": "README.md" } } } ] },
    { "role": "tool", "content": "# Projekt XY\nDieses Repository enthält ..." }
  ],
  "stream": false
}'

Erst jetzt antwortet das Modell mit einer regulären Textnachricht, die den Dateiinhalt einbezieht, z.B. „Die Datei README.md beschreibt das Projekt XY und enthält …”. Genau diese drei Schritte (Funktionsangebot → Funktionsaufruf → Funktionsergebnis zurückspielen) übernehmen CLI-Werkzeuge wie OpenCode oder Claude Code vollautomatisch im Hintergrund, meist mit deutlich mehr als einer einzigen Funktion (Datei lesen/schreiben, Verzeichnis auflisten, Shell-Befehl ausführen, Websuche, …) und häufig über mehrere Aufrufzyklen hinweg, bis eine Aufgabe vollständig gelöst ist.

Für dialogorientierte Anfragen wird derselbe Mechanismus auch über den in Zugriff über die REST-API erwähnten OpenAI-kompatiblen Endpunkt (/v1/chat/completions) angeboten, dort unter demselben, inzwischen quasi-standardisierten tools-Schema. CLI-Werkzeuge, die gegen die OpenAI-API entwickelt wurden, funktionieren dadurch ohne Anpassung auch gegen einen lokalen Ollama-Server, sofern das verwendete Modell toolfähig ist.

Wer führt die Funktion eigentlich aus?

Ein zentraler Punkt, der beim ersten Kontakt mit “Tool Use” leicht übersehen wird: Das Sprachmodell selbst kann und wird niemals eine Datei lesen, einen Befehl ausführen oder eine Webseite abrufen. Es erzeugt ausschließlich Text, nur in diesem Fall eben strukturierten Text in Form eines Funktionsaufrufs. Ob, wie und mit welchen Rechten diese Funktion tatsächlich ausgeführt wird, entscheidet allein der Host, also das umgebende Programm (Ollama-Client, OpenCode, ein eigenes Skript, …).

Diese Trennung hat eine wichtige Konsequenz: Sicherheit und Sandboxing sind Sache des Hosts, nicht des Modells. Ein Modell kann durchaus vorschlagen, rm -rf / auszuführen (d.h. im Linux Dateisystem alles zu löschen, worauf der Nutzer Zugriff hat) oder eine Zugangsdatei auszulesen. Ob das tatsächlich passiert, hängt vollständig davon ab, wie vorsichtig das aufrufende Programm mit solchen Vorschlägen umgeht (Bestätigungsabfragen, eingeschränkte Verzeichnisse, erlaubte Befehlslisten, …). Auf dieses Berechtigungsmodell gehen CLI-Interfaces mit Dateizugriff und OpenCode-CLI im Detail ein.

Voraussetzung: ein toolfähiges Modell

Nicht jedes Sprachmodell kann zuverlässig strukturierte Funktionsaufrufe erzeugen. Diese Fähigkeit muss beim Finetuning (siehe Was sind LLMs?) gezielt trainiert worden sein. Ein Modell, das nie mit Funktionsschemata konfrontiert wurde, ignoriert das tools-Feld entweder komplett oder versucht, den Aufruf als gewöhnlichen Text nachzuahmen, was in der Praxis meist zu unbrauchbaren oder gar nicht erst als Funktionsaufruf erkennbaren Ausgaben führt.

Ob ein Modell toolfähig ist, lässt sich an zwei Stellen nachprüfen:

• Auf der jeweiligen Modellseite in der Ollama-Modell-Bibliothek ist die Fähigkeit „tools” als Badge direkt neben dem Modellnamen aufgeführt.
• Lokal bereits heruntergeladene Modelle listen ihre Fähigkeiten über ollama show <modell> unter „Capabilities” auf; erscheint dort tools, unterstützt das Modell Function Calling.

Modelleigenschaften in der Ollama-Library-Webseite: “Badges” zeigen die Fähigkeiten und daneben stehen die Parameterzahl-Varianten, die bei diesem Modell verfügbar sind:

Hier die Ausgabe für das Modell qwen3.6:27b:

$ ollama show qwen3.6:27b
  Model
    architecture        qwen35
    parameters          27.8B
    context length      262144
    embedding length    5120
    quantization        Q4_K_M

  Capabilities
    completion
    vision
    tools
    thinking

  Parameters
    temperature         1
    top_k               20
    top_p               0.95
    min_p               0
    presence_penalty    1.5
    repeat_penalty      1

  License
    Apache License
    Version 2.0, January 2004
    ...

Modelle, die ausdrücklich für Agenten- bzw. Coding-Aufgaben beworben werden (z. B. viele instruct-Varianten aktueller Qwen- oder Llama-Modelle), bringen Toolfähigkeit in aller Regel mit. Reine „Chat”- oder besonders kleine Modelle unterstützen sie dagegen häufig gar nicht oder nur unzuverlässig. Dies ist ein Punkt, der bei der Modellwahl für CLI-Agenten in Das richtige Modell für die richtige Hardware wieder aufgegriffen wird.

Grenzen und Fallstricke

Auch bei grundsätzlich toolfähigen Modellen bleibt der Mechanismus fehleranfällig:

Halluzinierte Aufrufe

Ein Modell kann Funktionen mit nicht existierenden Namen oder Parametern „erfinden”, insbesondere bei komplexen oder mehrdeutigen Aufgaben.

Falsche oder unvollständige Parameter

Pfade, Dateinamen oder Befehlsargumente werden gelegentlich nur geraten statt tatsächlich aus dem Kontext korrekt abgeleitet.

Unnötige oder übereifrige Aufrufe

Manche Modelle neigen dazu, auch für triviale Anfragen Werkzeuge aufzurufen, obwohl eine direkte Antwort ausgereicht hätte.

Kein Ausführungsgarant

Da ausschließlich der Host über die tatsächliche Ausführung entscheidet, bleibt jeder Funktionsaufruf ein Vorschlag des Modells, kein garantierter Systemzugriff.

Diese Einschränkungen sind der Grund, warum produktiv genutzte CLI-Agenten in aller Regel zusätzliche Sicherheitsmechanismen mitbringen (Bestätigungsabfragen vor kritischen Aktionen, eingeschränkte Arbeitsverzeichnisse, Protokollierung aller Aufrufe) statt Funktionsaufrufe eines Modells blind auszuführen.

Leider kann man sich nicht darauf verlassen, dass ein CLI-Agent wirklich strikt absichert, dass Toolaufrufe niemals die erlaubten Verzeichnisse verlassen und Dateien außerhalb des Arbeitsverzeichnisses niemals gelesen/geschrieben werden. Schließlich können auch CLI-Agenten Programmierfehler enthalten. In diesem Fall hilft es nur, sich auf die Zugriffsbeschränkungen durch das Host-Betriebssystem zu verlassen (dedizierter Nutzer mit sehr beschränktem Zugriff für KI Aufgaben) oder grundsätzlich in der Sandbox (d.h. virtuellen Maschine) zu arbeiten.

Warum Toolfähigkeit wichtig ist

Toolfähigkeit ist die entscheidende technische Weiche zwischen den beiden in diesem Artikel behandelten Interface-Kategorien:

• Ohne Toolfähigkeit (oder bei einer Oberfläche, die sie bewusst nicht nutzt) bleibt es bei reiner Konversation, wie sie die Web-Oberflächen aus Sprachmodell-Interfaces: webbasiert ohne Dateizugriff bieten.
• Erst Toolfähigkeit eröffnet einem Sprachmodell mittelbar Zugriff auf Dateisystem, Shell, Codeausführung oder Websuche und damit die Fähigkeit, Aufgaben nicht nur zu beschreiben, sondern über den Host tatsächlich auszuführen.

Genau darauf bauen die in den folgenden Kapiteln behandelten CLI-Interfaces auf: OpenCode, Claude Code und Hermes sind im Kern nichts anderes als Host-Programme, die genau diese Aufruf-Ausführung-Rückgabe-Schleife implementieren. Zudem sind sie ergänzt um ein Berechtigungsmodell, eine Auswahl sinnvoller Funktionen (Datei- und Shell-Zugriff, Codesuche, …) und eine für Entwickler komfortable Bedienoberfläche im Terminal.

CLI-Interfaces mit Dateizugriff

Toolfähigkeit hat den technischen Mechanismus hinter Function Calling erklärt: Ein toolfähiges Modell kann strukturierte Funktionsaufrufe erzeugen, deren Ausführung jedoch vollständig dem umgebenden Host-Programm obliegt. Dieses Kapitel stellt genau solche Host-Programme vor. Konkret werden CLI-Werkzeuge vorgestellt, die im Terminal laufen, einem Sprachmodell Lese- und Schreibzugriff auf das lokale Dateisystem sowie die Shell zur Verfügung stellen und damit aus reiner Konversation echte, selbstständig ausgeführte Aufgaben machen.

Gemeinsames Funktionsprinzip

So unterschiedlich die einzelnen Werkzeuge im Detail auch sind, folgen sie alle demselben Aufbau:

• Ein CLI-Programm läuft lokal im Terminal und übernimmt die Rolle des in Toolfähigkeit beschriebenen Hosts.
• Als „Denk-Backend” nutzt es ein toolfähiges Sprachmodell – entweder lokal über einen Ollama-Server (nativ oder über dessen OpenAI-kompatiblen Endpunkt, siehe Zugriff über die REST-API) oder über die Cloud-API eines kommerziellen Anbieters.
• Dem Modell wird ein fester Satz an Funktionen angeboten, typischerweise Datei lesen/schreiben, Verzeichnis auflisten, Code durchsuchen und Shell-Befehle ausführen. Viele Werkzeuge lassen sich über den offenen Standard Model Context Protocol (MCP) zusätzlich um externe Werkzeuge erweitern, etwa Websuche oder Anbindungen an Projektverwaltungen.
• Jedes dieser Werkzeuge bringt ein eigenes Berechtigungsmodell mit, das genau die in Toolfähigkeit beschriebene Lücke schließt: Bestätigungsabfragen vor kritischen Aktionen, Beschränkung auf ein Arbeitsverzeichnis, Wiederherstellungspunkte vor destruktiven Änderungen oder Protokollierung aller ausgeführten Aufrufe.

Da bei jedem Werkzeugaufruf sowohl die Funktionsbeschreibung als auch das Ergebnis (Dateiinhalt, Befehlsausgabe, …) Teil des Gesprächskontexts werden, wächst der benötigte Kontext bei CLI-Agenten deutlich schneller als bei einem einfachen Chat. Ein zu knapp bemessenes Kontextfenster (siehe Was sind LLMs? und Das richtige Modell für die richtige Hardware) führt bei diesen Werkzeugen erfahrungsgemäß schon nach wenigen Werkzeugaufrufen zu abgeschnittenem Kontext oder erratischem Verhalten. Viele Agenten (z. B. Hermes Agent) empfehlen daher ausdrücklich ein Kontextfenster von mindestens 32.000 bis 64.000 Token, also deutlich mehr als der Ollama-Standardwert von 4.096.

Verbreitete CLI-Agenten im Überblick

Werkzeug	Lizenz/Modell	Ollama-fähig	Bemerkung
OpenCode	Open Source	ja (nativ + OpenAI-kompatibel)	Fokus dieses Artikels, siehe OpenCode-CLI
Claude Code	Anthropic, primär Cloud-API	nicht der Fokus	Referenz für Funktionsumfang eines ausgereiften CLI-Agenten
Hermes Agent	Open Source (Nous Research)	ja (über OpenAI-kompatiblen Endpunkt)	Workspace-Sandboxing, Checkpoints vor destruktiven Änderungen
Aider	Open Source	ja	Git-zentrierter Pair-Programming-Ansatz
Goose	Open Source (Agentic AI Foundation)	ja (eine von 15+ Providern)	MCP-basiertes Werkzeugsystem, auch als Desktop-App
Cline	Open Source	ja	ursprünglich VS-Code-Extension, seit CLI 2.0 auch eigenständig im Terminal

OpenCode

OpenCode hat sich als eines der verbreitetsten quelloffenen CLI-Werkzeuge in diesem Bereich etabliert: eine ausgereifte Terminal-Oberfläche, Unterstützung zahlreicher Modell-Anbieter und, für diesen Artikel entscheidend, nativer Zugriff auf lokale Ollama-Server ebenso wie auf beliebige andere OpenAI-kompatible Endpunkte. Da OpenCode damit den hier verfolgten Ansatz einer vollständig lokal gehosteten KI-Umgebung am direktesten unterstützt, widmet sich OpenCode-CLI diesem Werkzeug im Detail und beschreibt Installation, Konfiguration gegen einen lokalen Ollama-Server und praktische Nutzung.

Claude Code

Claude Code ist Anthropics eigener CLI-Agent und gilt in puncto Funktionsumfang, Zuverlässigkeit der Werkzeugaufrufe und Bedienkomfort vielfach als Referenzimplementierung, an der sich andere CLI-Agenten messen lassen müssen. Claude Code richtet sich jedoch primär gegen Anthropics eigene Cloud-API und ist nicht auf den Betrieb mit einem lokal gehosteten Modell ausgelegt. Für die hier verfolgte Zielsetzung Inferenz vollständig auf eigener Hardware, ohne dass Dateiinhalte oder Befehlsausgaben das eigene Netzwerk verlassen (siehe Toolfähigkeit) ist Claude Code damit keine Option. Es dient hier lediglich als Vergleichsmaßstab dafür, welchen Funktionsumfang ein ausgereifter, kommerziell entwickelter CLI-Agent bietet.

Hermes Agent

Hermes Agent von Nous Research ist ein quelloffener CLI-Agent mit Terminal-Oberfläche (TUI), Streaming-Ausgabe und Slash-Befehlen. Der Dateizugriff ist dabei ausdrücklich auf das jeweilige Arbeitsverzeichnis beschränkt. Das Lesen von Dateien außerhalb dieses Workspace (etwa Zugangsdaten an anderer Stelle im System) wird verweigert. Vor destruktiven Änderungen legt Hermes Agent zudem automatisch Wiederherstellungspunkte (Checkpoints) an.

Für den lokalen Betrieb verbindet sich Hermes Agent über den bereits aus Zugriff über die REST-API bekannten OpenAI-kompatiblen Endpunkt (http://localhost:11434/v1) mit Ollama; ein API-Schlüssel wird dabei nicht benötigt. Wie im obigen Hinweis zum Kontextfenster erwähnt, sollte vor der Nutzung mit Ollama gezielt eine ausreichend große Kontextlänge im Modelfile hinterlegt werden (siehe Was sind LLMs?), da Hermes Agent bei zu geringem Kontext bereits nach wenigen Werkzeugaufrufen unzuverlässig wird.

Weitere Vertreter

Neben den drei oben genannten Werkzeugen existiert eine wachsende Zahl weiterer CLI-Agenten mit Dateizugriff, von denen einige ebenfalls lokale Ollama-Server unterstützen:

• Aider verfolgt einen stärker git-zentrierten Ansatz: Änderungen werden automatisch als Commits nachvollzogen, was sich besonders für iteratives Pair-Programming an bestehendem Code eignet.
• Goose (ursprünglich von Block entwickelt, inzwischen bei der Linux Foundation als Agentic AI Foundation weitergeführt) unterstützt über 15 verschiedene Modell-Anbieter, darunter Ollama, und baut sein Werkzeugsystem konsequent auf dem Model Context Protocol auf. Neben der CLI existiert auch eine Desktop-Anwendung.
• Cline, ursprünglich als reine VS-Code-Extension bekannt, bietet seit der Version 2.0 auch einen eigenständigen CLI-/Headless-Modus und eignet sich dadurch inzwischen auch für automatisierte, nicht-interaktive Abläufe.

Diese Liste ist nicht abschließend, denn das Feld quelloffener CLI-Agenten entwickelt sich derzeit schnell weiter.

Übersichtsseite für CLI-/Tool-Integrationen

Für einen aktuellen, breiteren Vergleich lohnt sich ein Blick in extern gepflegte Übersichten, etwa die kuratierte Liste awesome-cli-coding-agents auf GitHub, die sowohl quelloffene Werkzeuge (Pi, OpenCode, Aider, Goose, …) als auch Anbieter-eigene Agenten (Claude Code, Codex, Gemini CLI) sowie zugehörige Infrastruktur auflistet.

Beim Vergleich einzelner Werkzeuge anhand solcher Listen sind vor allem folgende Kriterien relevant, die in diesem Kapitel bereits angeklungen sind:

Unterstützte Backends

Beschränkung auf einen Cloud-Anbieter oder Unterstützung Ollama-kompatibler bzw. beliebiger OpenAI-kompatibler Endpunkte?

Sandboxing-/Berechtigungsmodell

Bestätigungsabfragen, Workspace-Beschränkung, Wiederherstellungspunkte vor destruktiven Aktionen?

Unterstützte Sprachmodell-Anbieter

Wie flexibel lässt sich zwischen lokalen und Cloud-Modellen wechseln, und wie einfach ist ein späterer Anbieterwechsel?

Anforderungen an das Kontextfenster

Manche Agenten (siehe Hermes Agent oben) benötigen bereits im Grundbetrieb ein deutlich größeres Kontextfenster als der Ollama-Standardwert.

Wie eines dieser Werkzeuge, konkret OpenCode installiert und gegen einen lokalen Ollama-Server konfiguriert wird, zeigt das nächste Kapitel.

OpenCode-CLI

Wie schon mehrfach erwähnt, ist OpenCode das für diesen Artikel zentrale CLI-Werkzeug, da es lokale Ollama-Server nativ unterstützt und damit eine vollständig lokal gehostete KI-Umgebung ohne Cloud-Anbindung ermöglicht. Dieses Kapitel beschreibt Installation und Konfiguration von OpenCode gegen einen bereits laufenden Ollama-Server (siehe Ollama-Installation) Schritt für Schritt.

Wichtig ist hier, dass OpenCode-CLI auf dem Rechner des jeweiligen Nutzers installiert wird und dann mit dem entfernten Ollama Model-Server kommuniziert.

Installation unter Linux

Der schnellste Weg ist das offizielle Installationsskript:

curl -fsSL https://opencode.ai/install | bash

Das Skript erkennt Betriebssystem und Architektur automatisch, lädt die passende Binärdatei herunter und richtet sie im PATH ein. Standardmäßig landet das Programm dabei in ~/.opencode/bin/opencode

Der in der Dokumentation erwähnte Weg, durch Setzen der Umgebungsvariable OPENCODE_INSTALL_DIR den Installationspfad anzupassen, funktioniert in der aktuellen Version nicht. Falls man OpenCode tatsächlich für mehrere Nutzer installieren möchte, empfiehlt sich der Weg über das Debian Paket (siehe unten).

Alternativ steht OpenCode auch über gängige Paketmanager zur Verfügung, etwa:

npm install -g opencode-ai
# oder
bun add -g opencode-ai

Für Debian-basierte Distros kann man auch die deb-Datei aus dem OpenCode Download-Bereich herunterladen und systemweit für alle Nutzer installieren:

# herunterladen
curl https://opencode.ai/de/download/stable/linux-x64-deb > opencode.deb
# und installieren
sudo dpkg -i opencode.deb

Nach der Installation prüft folgender Befehl, ob OpenCode korrekt eingerichtet ist und zeigt die installierte Version an:

opencode --version

Konfigurationsdateien legt OpenCode unter Linux im XDG-konformen Verzeichnis ~/.config/opencode/ ab (Hauptkonfiguration: opencode.json), Zugangsdaten für Cloud-Anbieter getrennt davon unter ~/.local/share/opencode/auth.json. Für den in diesem Kapitel beschriebenen reinen Ollama-Betrieb bleibt Letzteres leer, da lokale Ollama-Server ohne API-Schlüssel auskommen.

Installation unter Windows

Unter Windows wird neben der Kommandozeilenvariante seitens OpenCode die sogenannte OpenCode-Desktop App empfohlen. Das ist ein einfacher Installer, und danach kann man sofort loslegen, allerdings funktioniert das wohl aktuell noch nicht richtig.

CLI Variante unter Windows

Für Windows empfiehlt die OpenCode-Dokumentation selbst den Betrieb unter WSL2, da dort die Linux-Installation (siehe oben) unverändert funktioniert und die volle Funktionalität gewährleistet ist. Dies ist ein Ansatz, der sich mit der bereits in Ollama-Installation beschriebenen Docker-Desktop-Nutzung unter Windows (i. d. R. ebenfalls mit WSL2-Backend) deckt.

Wer OpenCode dennoch nativ unter Windows betreiben möchte, kann auf dieselben Node/Bun-basierten Paketmanager-Installationen wie unter Linux zurückgreifen:

npm install -g opencode-ai

Alternativ liegt unter den Releases auf GitHub eine eigenständige Windows-Binärdatei bereit.

Die native Windows-Unterstützung von OpenCode ist anders als die ausgereifte Linux/WSL2-Variante zum jetzigen Zeitpunkt noch in Entwicklung. Bei Problemen mit der nativen Installation ist der Umweg über WSL2 die verlässlichere Option.

Wie unter Linux verifiziert opencode --version die Installation. Da OpenCode intern denselben, plattformunabhängigen Konfigurationsmechanismus nutzt, liegt die Konfigurationsdatei auch unter Windows im äquivalenten benutzerspezifischen Konfigurationsverzeichnis (unter WSL2 identisch zu Linux: ~/.config/opencode/opencode.json).

Ollama-Server für den Zugriff durch OpenCode konfigurieren

Läuft OpenCode auf demselben Rechner wie Ollama, ist keine weitere Netzwerkkonfiguration nötig, denn OpenCode erreicht den Ollama-Server direkt über localhost:11434. Soll OpenCode dagegen von einem anderen Rechner im Netzwerk aus auf Ollama zugreifen, muss der Ollama-Dienst zunächst für Netzwerkzugriff freigegeben werden, wie bereits in Netzwerkzugriff über OLLAMA_HOST und angepasste Konfiguration beschrieben.

Die Ollama-API verlangt standardmäßig keine Authentifizierung. Wird OLLAMA_HOST=0.0.0.0 gesetzt, ist der Server damit für jeden erreichbar, der Netzwerkzugriff auf den entsprechenden Port hat. Eine Freigabe über das lokale, vertrauenswürdige Netzwerk hinaus (z. B. direkt ins Internet) sollte unbedingt vermieden bzw. nur über einen vorgeschalteten, abgesicherten Reverse-Proxy erfolgen.

OpenCode opencode.json für den Zugriff auf einen Ollama-Server konfigurieren

Damit OpenCode einen lokalen Ollama-Server als Anbieter zur Auswahl anbietet, muss er als eigener Provider in ~/.config/opencode/opencode.json eingetragen werden (unter Windows liegt die Datei unter %HOME%/.config/opencode/opencode.json). Da Ollama, wie in Zugriff über die REST-API beschrieben, einen OpenAI-kompatiblen Endpunkt bereitstellt, genügt dazu der generische OpenAI-kompatible Provider-Treiber von OpenCode:

{
  "$schema": "https://opencode.ai/config.json",
  "language": "de",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (lokal)",
      "options": {
        "baseURL": "http://<OLLAMA_IP>:11434/v1"
      },
      "models": {
        "qwen3.6:27b": {
          "name": "Qwen 3.6 27B"
        }
      }
    }
  }
}

Dabei gilt:

• "language": "de" ist ein optionaler Parameter, der OpenCode sagt, ab sofort standardmäßig Deutsch als Sprache zu verwenden (kann auch weggelassen werden).
• provider.ollama ist ein frei wählbarer Bezeichner für den Provider-Eintrag; er muss lediglich innerhalb der Konfigurationsdatei eindeutig sein.
• npm verweist auf das generische, OpenAI-kompatible Anbindungspaket – dasselbe Prinzip, mit dem laut Zugriff über die REST-API praktisch jedes Werkzeug angebunden werden kann, das „die OpenAI-API spricht”.
• options.baseURL zeigt auf den in Zugriff über die REST-API vorgestellten OpenAI-kompatiblen Endpunkt von Ollama. Läuft Ollama auf einem anderen Rechner, ist localhost durch dessen Adresse zu ersetzen.
• Unter models müssen die gewünschten, bereits per ollama pull heruntergeladenen Modelle (siehe Ollama-Installation) eingetragen werden. Der JSON-Schlüssel muss dabei exakt dem Ollama-Tag entsprechen, inklusive Doppelpunkt (z. B. qwen3.6:27b, nicht qwen3.6-27b) – nur so findet OpenCode das passende, bereits lokal vorhandene Modell wieder.
• Das name Attribut enthält den Modellnamen, der später in der Modellliste innerhalb von OpenCode erscheint.

Bei Verwendung von OpenCode-Desktop darf man das Attribut language nicht setzen (gibt eine Warnung).

Da ein lokaler Ollama-Server keinen API-Schlüssel verlangt, ist für den Ollama-Provider kein zusätzlicher Aufruf von opencode auth login nötig. Dieser Befehl (der Zugangsdaten in ~/.local/share/opencode/auth.json ablegt) ist ausschließlich für Cloud-Anbieter wie Anthropic oder OpenAI relevant, falls diese zusätzlich zum lokalen Ollama-Provider genutzt werden sollen.

Wie bereits im vorherigen Kapitel angemerkt (siehe CLI-Interfaces mit Dateizugriff), benötigt OpenCode für zuverlässiges Werkzeugverhalten ein ausreichend großes Kontextfenster. Erfahrungsgemäß sind das mindestens 16.000 bis 32.000 Token, idealerweise mehr. Ollama verwendet standardmäßig ein Kontextfenster von 4.096 (4K) Token. Steht jedoch ausreichend VRAM zur Verfügung, wird dieses Limit automatisch angepasst, aktuell bei 24-48GB VRAM auf 32K Tokens und bei noch mehr VRAM auf 256k. Tatsächlich wurden bei meinem Test 32k (=32768 Tokens) als Standardwert definiert. Das reicht zwar für kleinere Anfragen aus, führt aber bei längeren Chats oder größeren Dateien zu fehlerhaften oder ausbleibenden Werkzeugaufrufen. Die Kontextlänge lässt sich, wie in Was sind LLMs? beschrieben, über ein angepasstes Modelfile dauerhaft erhöhen, welches aber Auswirkung auf die VRAM-Nutzung hat.

Wie man das Kontextfenster anpasst und wie man den GPU Speicher optimal auslastet ist in Warum braucht man zusätzlichen Speicherplatz für das Kontextfenster? beschrieben.

Verbindung testen

Nach dem Speichern der Konfiguration lässt sich die Anbindung wie folgt prüfen:

opencode models ollama

Dieser Befehl listet alle unter dem Provider ollama konfigurierten Modelle auf und bestätigt damit, dass OpenCode die Konfigurationsdatei korrekt eingelesen hat. Ob die Verbindung zum Ollama-Server tatsächlich funktioniert, zeigt sich beim ersten Chat-Aufruf:

opencode run --model ollama/qwen3.6:27b "Liste die Dateien im aktuellen Verzeichnis auf"

Antwortet OpenCode mit einer Dateiliste, war sowohl die Verbindung zum lokalen Ollama-Server als auch der erste Werkzeugaufruf erfolgreich (in diesem Fall das Auflisten eines Verzeichnisses, siehe Toolfähigkeit). Für den interaktiven Betrieb genügt anschließend der Aufruf von opencode ohne weitere Argumente. Das öffnet die Terminal-Oberfläche, in der zunächst das lokale Modell ausgewählt werden sollte. Standardmäßig bringt OpenCode nämlich diverse freie Cloud-Modelle mit.

Die Modellauswahl erhält man über die Eingabe von /models. In der Liste scrollt man dann zu dem Eintrag Qwen 3.6 27B (siehe Konfigurationsdatei opencode.json oben).

Sinnvolle Shortcuts im Editor sind Ctrl+p (Öffne Befehlsliste) und Ctrl+d (schließe OpenCode).

Farbvarianten im Terminal

Grundlegend passt sich OpenCode an die Farbvariante (dunkles oder helles Thema) der Konsole an.

Heller Hintergrund und Standard-Thema opencode:

Dunkler Hintergrund und Standard-Thema opencode:

Mit dem Befehl /themes kann man noch den Hervorhebungsmodus anpassen.

Linux-Terminal-Anpassungen und Wayland-Korrekturen

Wenn man im Terminal mit OpenCode arbeitet, gibt es mitunter Probleme beim Kopieren und Einfügen von Text. Wer stattdessen (noch) eine X11-Sitzung nutzt, ist von diesem Problem nicht betroffen, da X11 die von OpenCode verwendete Zwischenablage-Funktionalität bereits systemseitig mitbringt. Im Zweifel zeigt der Befehl echo $XDG_SESSION_TYPE an, ob die aktuelle Sitzung unter wayland oder x11 läuft.

Betroffen sind vor allem Linux-Desktops, die auf dem Wayland-Display-Server statt auf dem älteren X11 laufen (bei den meisten aktuellen Distributionen inzwischen die Standardeinstellung). OpenCodes Terminal-Oberfläche nutzt für Copy & Paste einen Mechanismus, den Wayland ohne zusätzliches Hilfsprogramm nicht bereitstellt – markierter Text in der OpenCode-GUI lässt sich dann zwar mit der Maus kopieren, aber nicht mehr per Strg+V in ein anderes Programm einfügen (und umgekehrt).

Abhilfe schafft die Installation des Kommandozeilenwerkzeugs wl-clipboard, das die fehlende Zwischenablage-Anbindung für Wayland nachrüstet:

sudo apt install -y wl-clipboard

Nach der Installation funktioniert Copy & Paste zwischen der OpenCode-GUI und anderen Anwendungen wie gewohnt, ohne dass OpenCode neu konfiguriert werden müsste.

Grundsätzlich ist es sinnvoll, den Text mit gedrückter Shift-Taste und der Maus zu markieren und dann via Kontextmenü zu kopieren. Auch kann man mit Shift-Rechtsklick das Kontextmenü mit Texteinfügen-Option öffnen.

Das richtige Modell für die richtige Hardware

Was sind LLMs? hat Parameteranzahl, Quantisierung und Modelfile bereits begrifflich eingeführt, und die dortigen sowie in CLI-Interfaces mit Dateizugriff gegebenen Hinweise zum Kontextfenster wurden bislang nur qualitativ behandelt. Dieses Kapitel führt beides zusammen und beantwortet die praktisch entscheidende Frage: Welches Modell läuft auf welcher Hardware noch sinnvoll, und welcher Speicher wird dafür konkret benötigt?

Speicherbedarf von KI Modellen

Bei der Inferenz von Sprachmodellen möchte man eigentlich den gesamten benötigen Speicher im VRAM der Grafikkarte halten, da hier die Zugriffszeiten sehr klein sind und dadurch die Berechnungsgeschwindigkeit maximiert wird. Grafikspeicher wird dafür für verschiedenen Dinge benötigt:

• Modellgewichte
• Kontextfenster
• Input/Output-token

Der tatsächliche Bedarf hängt von einer Vielzahl an Parametern ab, wobei die Modellgröße (Anzahl der Parameter) und auch die Quantisierung maßgeblich sind (auch die konkrete Hardware und der Modellserver wie z.B. Ollama haben Einfluss).

Speicherbedarf für Modellgewichte je nach Quantisierung

Als grobe Faustregel (tatsächliche Werte können Abweichen) gilt für den reinen Speicherbedarf der Modellgewichte:

Speicherbedarf (GB) ≈ Parameteranzahl (Milliarden) × Bytes pro Parameter

Die „Bytes pro Parameter” ergeben sich direkt aus der gewählten Quantisierungsstufe (siehe Was sind LLMs?). Die folgende Tabelle zeigt die im Ollama-/llama.cpp-Umfeld gebräuchlichsten Stufen:

Quantisierung	Bit/Parameter (ca.)	Größe rel. zu fp16	Qualitätseinbuße
fp16	16	100 %	keine (Referenzgröße, volle Genauigkeit)
q8_0	8	≈ 50 %	kaum wahrnehmbar
q6_K	≈ 6,5	≈ 40 %	sehr gering
q4_K_M	≈ 4,5–5	≈ 28–30 %	leicht merkbar, in der Praxis meist tolerierbar – gängiger „Sweet Spot”
q2_K	≈ 2,5–3	≈ 15–18 %	deutlich, nur bei starker Speicherknappheit sinnvoll

Ein Modell mit 27,8 Milliarden Parametern (siehe Beispielrechnung weiter unten) benötigt demnach in fp16 rund 55,6 GB, in q8_0 rund 27,8 GB und in q4_K_M nur noch rund 15,6 GB Speicher für die reinen Modellgewichte. Dies ist ein Unterschied, der bei der Hardwarewahl den Ausschlag geben kann.

Ob dieser Speicher aus VRAM (Grafikkartenspeicher) oder RAM (Hauptspeicher) stammt, wirkt sich massiv auf die Geschwindigkeit aus: VRAM bietet eine Speicherbandbreite von mehreren hundert GB/s bis wenigen TB/s, während gewöhnlicher System-RAM meist nur einen Bruchteil davon erreicht. Passt ein Modell vollständig ins VRAM, läuft die Inferenz entsprechend deutlich schneller als bei teilweisem Offloading, bei dem Ollama (über das darunterliegende llama.cpp) einen Teil der Modell-Layer auf die CPU und damit in den langsameren RAM auslagert, um trotz begrenztem VRAM lauffähig zu bleiben. Offloading erweitert also den nutzbaren Modell-/Kontextumfang auf Kosten der Geschwindigkeit, statt schlicht nicht mehr zu funktionieren.

Wie viel eines Modells tatsächlich im VRAM liegt und wie stark die GPU dabei ausgelastet ist, lässt sich unmittelbar mit dem bereits in Ollama-Installation erwähnten btop beobachten. Dies ist ein schneller praktischer Test, ob ein gewähltes Modell samt Kontext noch vollständig in die verfügbare Hardware passt. Wichtig ist dabei, dass die ausgegebene GPU-Speichernutzung immer auch das aktuell gewählte Kontextfenster beinhaltet (siehe unten). Man kann aber beim Laden des Modells zuschauen, wie zunächst die Modellgewichte geladen werden (beim Qwen 3.6:27b 15GB) und dann je nach konfiguriertem Kontextfenster der Speicherverbrauch weiter ansteigt.

Warum braucht man zusätzlichen Speicherplatz für das Kontextfenster?

Neben den reinen Modellgewichten belegt auch das Kontextfenster Speicher, und das zusätzlich zu den Gewichten. Für jedes Token im aktuellen Kontext legt das Modell einen sogenannten KV-Cache an (siehe Glossar in Glossar und Quellen), der die für die Aufmerksamkeitsberechnung nötigen Zwischenzustände zwischenspeichert. Dieser Cache wächst linear mit der Anzahl der Token im Kontext sowie mit Modellgröße und -architektur (Anzahl Layer, Anzahl und Dimension der Attention-Heads).

Als grobe Formel gilt:

KV-Cache (Byte) ≈ 2 × Anzahl Layer × KV-Hidden-Dimension × Bytes pro Wert × Anzahl Token

Der Faktor 2 steht dabei für die getrennt gespeicherten „Key”- und „Value”-Zustände. Legt man für ein Modell der Größenordnung 27–30 Milliarden Parameter typische Architekturwerte zugrunde (rund 60 Layer, eine effektive KV-Hidden-Dimension von etwa 1024, 2 Byte pro Wert), ergibt sich überschlägig ein Bedarf von rund 240 KB pro Token im Kontext.

Daraus folgt beispielhaft:

Kontextlänge	Zusätzlicher Speicherbedarf (KV-Cache, überschlägig)
8.192 Token (8K)	≈ 1,9 GB
32.768 Token (32K)	≈ 7,7 GB
131.072 Token (128K)	≈ 30,7 GB

Diese Werte sind eine überschlägige Beispielrechnung auf Basis typischer Architekturparameter für ein Modell dieser Größenordnung, keine für ein konkretes Modell verifizierte Angabe – die genaue Layer- und Head-Konfiguration eines Modells liefert ollama show --verbose. Konkrete Messwerte liefert die Tabelle unten.

Entscheidend ist der grundsätzliche Zusammenhang: Der KV-Cache wächst linear mit der Kontextlänge, und schon ein mittelgroßes Kontextfenster kann bei einem großen Modell mehrere Gigabyte zusätzlich zu den Modellgewichten belegen. Wird dieser zusätzliche Bedarf beim Einplanen der Hardware übersehen, zeigen sich genau die in Was sind LLMs? beschriebenen Symptome (Endlosschleifen, vermischte JSON-/Klartextausgabe), sobald der KV-Cache nicht mehr vollständig ins VRAM passt.

Genau dieser zusätzliche Bedarf ist auch der Grund, warum CLI-Agenten wie OpenCode ein deutlich größeres Kontextfenster benötigen als der Ollama-Standardwert von 4.096 Token vorgibt: Der verfügbare Speicher muss sowohl für die Modellgewichte als auch für einen bei jedem Werkzeugaufruf weiter wachsenden Kontext reichen.

Eigenes Modelfile zur Anpassung der Kontextlänge

Der Ollama-Standardwert für die Kontextlänge (4.096 Token bzw. der dynamisch angepasste Standardwert von 32k) lässt sich über ein eigenes Modelfile dauerhaft anpassen. Dazu wird zunächst eine Datei mit folgendem Inhalt angelegt:

Modelfile:

FROM qwen3.6:27b

PARAMETER num_ctx 131072

Der Parameter num_ctx legt dabei die gewünschte Kontextlänge in Token fest – hier 131.072 Token (128*1024 = 128k). Man kann auch noch weitere Parameter hinzufügen, siehe docs.ollama.com/modelfile.

Aus diesem Modelfile lässt sich anschließend eine eigene, individuell benannte Modellvariante erzeugen:

ollama create qwen3.6-27b-128k -f ./Modelfile

Das neue Modell erscheint danach unter dem gewählten Namen (qwen3.6-27b-128k) in ollama list und kann wie jedes andere Modell verwendet werden, etwa direkt im Terminal:

ollama run qwen3.6-27b-128k

oder (nach entsprechendem Eintrag unter models in der opencode.json) als eigener Modelleintrag in OpenCode (siehe OpenCode-CLI).

Während der Inferenz zeigt btop gut die Auslastung an.

GPU Speicherauslastung während der Inferenz beim 128k Kontextfenster:

Die Ausgabe neben dem GPU Auslastungsbalken zeigt hier 25G von 31G, d.h. es ist noch einiges an Luft im VRAM.

Wenn man das Ganze überreizt und ein zu großes Kontextfenster erlaubt, dann wird der Hauptspeicher mitbenutzt (offloading) und die Berechnung wird zäh.

VRAM und RAM Speicherauslastung beim 256k Kontextfenster:

Der Einfluss des Kontextfensters hängt vom jeweiligen Prompt und natürlich der Länge der gelesenen Dateien und Eingabedaten ab. Um das mal vereinfacht zu testen, habe ich bei einem schon recht großen Repository den Befehl /init ausgeführt und dabei die Speicherauslastung beobachtet. Die Qualität der erstellten Agents.md-Datei variierte zum Teil stark, wobei aber nicht zwingend das längere Kontextfenster stets auch bessere und passgenauere Inhalte geliefert hat. Auch die Ausführungszeit war vergleichbar - lediglich bei der 256k Variante, die mit teilweisem Offloading gerechnet hat, war eine deutliche Verlängerung der Antwortdauer spürbar.

Gemessene Speicherauslastungen beim qwen3.6:27b Modell mit verschiedenen Kontextfensterlängen:

Kontextfenster	VRAM + RAM	Init-Zeit / Tokens
4k	17 GB	Abbruch
32k	19 GB	3m2, 29.100 tokens
48k	20 GB	3m, 41.300 tokens
64k	21 GB	3m7, 36.000 tokens
128k	25 GB	2m10, 27.500 tokens
200k	29 GB	3m8, 30.700 tokens
256k	30 GB + 8 GB	6m44, 33.800 tokens

Die Modellgewichte selbst benötigen ca. 15 GB.

Beste Modelle für 32 GB VRAM und 32 GB Hauptspeicher

Als konkrete Zielkonfiguration dient meine Simulationsworkstation mit 32 GB Hauptspeicher und einer NVIDIA-Grafikkarte der Blackwell-Generation (NVIDIA RTX Pro 4500 Blackwell mit 32 GB VRAM), welche man derzeit für gerade mal ca. 1700 + 3500 = 5200€ insgesamt bekommt.

Wenn man die NVIDIA Karte in ein System mit integrierter Grafik einbaut (hier ist das ein Ryzen 9 9950x mit AMD Radeon Graphics), dann kann man die integrierte AMD-GPU für die Grafikausgabe auf dem Bildschirm benutzen und hat die gesamte Blackwell-Karte und somit auch den gesamten VRAM für die KI zur Verfügung. Verwendet man die NVIDIA Karte stattdessen auch für die Grafikausgabe, so reduziert sich der verfügbare VRAM, was man ja tunlichst vermeiden möchte.

Verwendet man die theoretischen Berechnungen oben, kommt man meist zu konservativen Abschätzungen (und nimmt dadurch zu kleine Kontextfenster). Besser ist ausprobieren, z.B. die in nachfolgender Tabelle genannten Modelle:

Modell	Quantisierung	Download
qwen3.6:27b	Q4_K_M	qwen3.6:27b
qwen3.6:27b	Q6_K	hf.co/unsloth/Qwen3.6-27B-MTP-GGUF:Q6_K
qwen3.6:35b	Q4_K_M	qwen3.6:35b
qwen3-coder:30b	Q4_K_M	qwen3-coder:30b
qwen3.8:27b	Q4_K_M	qwen3.8:27b

Das Modell qwen3.6:35b ist ein MoE (Mixture-of-Experts)-Modell, welches ziemlich schnell ist im Vergleich zu einem dichten Modell wie qwen3.6:27b. Genauso ist auch qwen3-coder:30b ebenfalls ein MoE Modell und sehr schnell, aber bei komplexeren Anfragen deutlich schwächer/ungenauer als das qwen3.6:27b.

Man kann die Modelle auch von HuggingFace herunterladen, wie bspw. die Q6_K Varianten oben. Dazu auf der HuggingFace-Webseite nach dem Modell suchen, dann die gewünschte Quantisierung in der Tabelle auswählen, und in der Sidebar auf “Modell verwenden” klicken. Dort kann man dann zum Downloadlink für die Ollama-Installation scrollen.

Liste von möglichen Quantisierungen, die 32GB Speicher ziemlich gut ausreizen

Modell	Quantisierung	Kontextfenster
qwen3.6-27b-Q6_96k	Q6_K	96k (28 GB)
qwen3.6-27b-128k	Q4_K_M	128k (25 GB)
qwen3.6-27b-200k	Q4_K_M	200k (29 GB)
qwen3.6-35b-128k	Q4_K_M	128k (25 GB)
qwen3-coder-30b-96k	Q4_K_M	96k (27 GB)
qwen3.8-27b-128k	Q4_K_M	128k (26 GB)

Während das qwen3.6-27b-200k noch voll im VRAM läuft, passt das qwen3.8-27b-200k schon nicht mehr hinein und durch das offloading wird es langsamer. Auch das qwen3-coder-30b-128k passt knapp nicht mehr in den VRAM.

Zum aktuellen Zeitpunkt (August 2026) scheint qwen3.8-27b-128k die beste Modellkonfiguration für komplexe Fragestellungen zu sein und das qwen3-coder-30b-96k für schnellere (aber weniger komplexe) Coding-Aufgaben.

Glossar und Quellen

Dieses abschließende Kapitel fasst die in diesem Artikel verwendeten Fachbegriffe kompakt zusammen und listet die verwendeten sowie weiterführenden Quellen. Das Glossar ist alphabetisch sortiert und verweist jeweils auf das Kapitel, in dem der Begriff ausführlich behandelt wird.

Glossar

Agentisches System

Ein System, in dem ein Sprachmodell nicht nur antwortet, sondern über wiederholte Zyklen aus Funktionsaufruf, Ausführung durch den Host und Rückgabe des Ergebnisses eigenständig mehrschrittige Aufgaben bearbeitet (siehe Toolfähigkeit).

Arbeitsverzeichnis (Workspace)

Das Verzeichnis, aus dem ein CLI-Agent gestartet wurde und innerhalb dessen er auf Dateien zugreifen darf. Bildet bei den meisten Werkzeugen zugleich die Grenze des Sandboxings (siehe CLI-Interfaces mit Dateizugriff).

Basismodell (base)

Modell direkt nach dem Pretraining. Es setzt Text plausibel fort, ist aber nicht darauf trainiert, Anweisungen zu befolgen (siehe Was sind LLMs?).

CLI-Agent

Terminal-basiertes Host-Programm, das einem toolfähigen Sprachmodell Datei- und Shell-Zugriff bereitstellt, z. B. OpenCode, Aider oder Goose (siehe CLI-Interfaces mit Dateizugriff).

Finetuning

Nachgelagertes Training eines Basismodells zur Spezialisierung, etwa auf Dialog, Anweisungsbefolgung oder Programmierung (siehe Was sind LLMs?).

Function Calling

siehe Tool Use / Function Calling.

GGUF

Binärformat für (quantisierte) Modellgewichte, entwickelt im Umfeld von llama.cpp und von Ollama verwendet (siehe Was sind LLMs?).

Halluzination

Sachlich falsche, aber sprachlich überzeugend formulierte Modellausgabe. Bei Tool Use auch in Form erfundener Funktionsnamen oder Parameter (siehe Toolfähigkeit).

Host

Das Programm, das ein Modell aufruft und die vom Modell vorgeschlagenen Funktionsaufrufe tatsächlich ausführt. Sicherheit und Sandboxing liegen ausschließlich beim Host, nicht beim Modell (siehe Toolfähigkeit).

Idle-Timeout

Zeitspanne, nach der Ollama ein nicht mehr genutztes Modell automatisch aus dem Speicher entlädt (siehe Was ist Ollama und welche Alternativen gibt es?).

Inferenz

Die Anwendung eines fertig trainierten Modells, also das Erzeugen einer Antwort Token für Token. Der für lokal gehostete KI allein relevante Betriebsmodus (siehe Was sind LLMs?).

Instruction Tuning

Finetuning-Verfahren, das ein Basismodell in ein anweisungsbefolgendes bzw. chat-optimiertes Modell überführt (Namenszusatz häufig instruct oder chat, siehe Was sind LLMs?).

Kontextfenster / Context Window

Maximale Anzahl Token, die ein Modell gleichzeitig verarbeiten kann. Bei CLI-Agenten der kritischste Einzelparameter, da jeder Werkzeugaufruf samt Ergebnis den Kontext weiter füllt (siehe CLI-Interfaces mit Dateizugriff und Das richtige Modell für die richtige Hardware).

KV-Cache

Pro Token im Kontext zwischengespeicherte „Key”- und „Value”-Zustände der Aufmerksamkeitsberechnung. Wächst linear mit der Kontextlänge und ist der Grund für den zusätzlichen Speicherbedarf neben den Modellgewichten (siehe Das richtige Modell für die richtige Hardware).

llama.cpp

In C/C++ geschriebene Inferenz-Engine für quantisierte GGUF-Modelle. Bildet den Unterbau von Ollama und LM Studio (siehe Was ist Ollama und welche Alternativen gibt es?).

LLM (Large Language Model)

Auf der Transformer-Architektur basierendes neuronales Netz zur Textgenerierung (siehe Was sind LLMs?).

MCP (Model Context Protocol)

Offener Standard, über den sich CLI-Agenten um externe Werkzeuge (Websuche, Projektverwaltung, …) erweitern lassen (siehe CLI-Interfaces mit Dateizugriff und Weblink unten).

mDNS (Multicast DNS)

Verfahren zur Namensauflösung im lokalen Netz ohne DNS-Server, auch als Bonjour/Zeroconf bekannt. Ermöglicht das Auffinden von Diensten im lokalen Netzwerk (siehe Das richtige Modell für die richtige Hardware).

Modelfile

Ollama-spezifische Konfigurationsdatei eines Modells mit Referenz auf die GGUF-Gewichte, Systemprompt und Parameter-Defaults. Dient auch zum Anlegen eigener Modellvarianten, etwa mit erhöhter Kontextlänge (siehe Was sind LLMs? und Das richtige Modell für die richtige Hardware).

Modell-Tag

Bezeichner eines Modells in der Ollama-Bibliothek, zusammengesetzt aus Modellname, Parametergröße, Variante und Quantisierungsstufe, z. B. qwen3.6:27b-instruct-q4_K_M (siehe Was sind LLMs?).

num_ctx

Modelfile-Parameter zur Festlegung der Kontextlänge in Token. Der Ollama-Standardwert von 4.096 ist für CLI-Agenten in aller Regel zu klein (siehe Das richtige Modell für die richtige Hardware).

Offloading

Auslagerung eines Teils der Modell-Layer vom VRAM in den langsameren Hauptspeicher, wenn das Modell nicht vollständig auf die GPU passt. Erhält die Lauffähigkeit auf Kosten der Geschwindigkeit (siehe Das richtige Modell für die richtige Hardware).

OLLAMA_HOST

Umgebungsvariable, mit der die Netzwerkbindung des Ollama-Dienstes festgelegt wird. Der Wert 0.0.0.0 gibt den Dienst für das gesamte Netzwerk frei (siehe Ollama-Installation).

Ollama

Lokaler Modell-Server, der Modellverwaltung, Inferenz über llama.cpp und eine REST-API unter einem Dach vereint (siehe Was ist Ollama und welche Alternativen gibt es?).

OpenAI-kompatibler Endpunkt

Von Ollama unter /v1/… bereitgestellte Schnittstelle, die dem De-facto-Standard der OpenAI-API entspricht. Grundlage dafür, dass Werkzeuge wie OpenCode ohne Anpassung gegen einen lokalen Server laufen (siehe Ollama-Installation).

OpenCode

Quelloffener, toolfähiger CLI-Agent mit nativer Unterstützung lokaler Ollama-Server; das zentrale Werkzeug dieses Artikels (siehe OpenCode-CLI).

opencode.json

Konfigurationsdatei von OpenCode unter ~/.config/opencode/, in der Provider und Modelle eingetragen werden (siehe OpenCode-CLI).

Parameter (Gewichte)

Die im Training angepassten Zahlenwerte eines Modells. Ihre Anzahl (in Milliarden, z. B. 27b) bestimmt maßgeblich Qualität, Geschwindigkeit und Speicherbedarf (siehe Was sind LLMs?).

Pretraining

Erstes, sehr rechenintensives Training auf großen Textmengen, aus dem ein Basismodell hervorgeht (siehe Was sind LLMs?).

Provider

In opencode.json konfigurierter Modellanbieter. Für lokale Ollama-Server wird der generische, OpenAI-kompatible Provider-Treiber verwendet (siehe OpenCode-CLI).

Quantisierung

Reduktion der Zahlenpräzision der Modellgewichte (z. B. q4_K_M statt fp16) zur Verringerung von Speicherbedarf und Downloadgröße, bei meist geringer Qualitätseinbuße (siehe Das richtige Modell für die richtige Hardware).

RAG (Retrieval-Augmented Generation)

Verfahren, bei dem vor der Antwortgenerierung passende Textausschnitte aus einer Dokumentensammlung gesucht und in den Kontext eingefügt werden. In diesem Artikel nicht vertieft (siehe Sprachmodell-Interfaces: webbasiert ohne Dateizugriff).

REST-API

Netzwerkschnittstelle von Ollama auf Port 11434 (/api/generate, /api/chat), über die beliebige Programme mit einem lokal laufenden Modell kommunizieren (siehe Was ist Ollama und welche Alternativen gibt es? und Ollama-Installation).

RLHF (Reinforcement Learning from Human Feedback)

Trainingsverfahren, das Modellantworten anhand menschlicher Bewertungen weiter ausrichtet; häufig ergänzend zum Instruction Tuning (siehe Was sind LLMs?).

Sandboxing

Einschränkung dessen, was ein Host bei Werkzeugaufrufen tatsächlich zulässt, etwa Beschränkung auf ein Arbeitsverzeichnis, Bestätigungsabfragen oder der Betrieb in einer virtuellen Maschine (siehe Toolfähigkeit).

Sitzung (Session)

Einzelne, in sich abgeschlossene Konversation innerhalb eines OpenCode-Projekts. Getrennte Sitzungen je Teilaufgabe halten den Kontext klein und übersichtlich (siehe OpenCode-CLI).

Systemprompt

Dem eigentlichen Dialog vorangestellte Anweisung, die Rolle, Tonfall und Einschränkungen des Modells vorgibt. Teil des Modelfiles, pro Konversation überschreibbar (siehe Was sind LLMs?).

Temperatur

Modellparameter, der die Zufälligkeit bzw. „Kreativität” der Ausgabe steuert (siehe Was sind LLMs?).

Token

Kleinste Verarbeitungseinheit eines Sprachmodells, typischerweise ein Wortteil. Kontextlänge und Antwortgeschwindigkeit werden in Token gemessen (siehe Was sind LLMs?).

Tool Use / Function Calling

Fähigkeit eines Modells, statt Fließtext einen strukturierten Funktionsaufruf im JSON-Schema zu erzeugen. Die Ausführung obliegt stets dem Host (siehe Toolfähigkeit).

Transformer

Netzwerkarchitektur, auf der praktisch alle heutigen Sprachmodelle basieren (siehe Was sind LLMs?).

VRAM

Grafikkartenspeicher, primärer Ablageort für Modellgewichte und KV-Cache bei GPU-Inferenz. Deutlich schneller angebunden als gewöhnlicher System-RAM (siehe Das richtige Modell für die richtige Hardware).

Wayland

Auf modernen Linux-Desktops verbreiteter Display-Server. Erfordert für Copy & Paste in der OpenCode-TUI das Zusatzpaket wl-clipboard (siehe Linux-Terminal-Anpassungen und Wayland-Korrekturen).

WSL2 (Windows Subsystem for Linux)

Linux-Laufzeitumgebung unter Windows und der von der OpenCode-Dokumentation empfohlene Weg, OpenCode unter Windows zu betreiben (siehe OpenCode-CLI).

Quellen und weiterführende Links

Ollama

• Projektseite und Dokumentation: https://ollama.com
• Modell-Bibliothek (Tags, Fähigkeiten-Badges, Lizenzen): https://ollama.com/library
• Downloads für alle Plattformen: https://ollama.com/download
• Quellcode: https://github.com/ollama/ollama
• Überblicksartikel: https://de.wikipedia.org/wiki/Ollama

Inferenz-Engines und Alternativen

• llama.cpp (Inferenz-Engine unter Ollama und LM Studio): https://github.com/ggerganov/llama.cpp
• LM Studio: https://lmstudio.ai
• vLLM (Hochdurchsatz-/Multi-User-Betrieb): https://github.com/vllm-project/vllm
• LocalAI (OpenAI-kompatibler Server über mehrere Backends): https://localai.io
• GPT4All: https://www.nomic.ai/gpt4all
• Jan: https://jan.ai
• text-generation-webui (oobabooga): https://github.com/oobabooga/text-generation-webui

Web-Oberflächen ohne Werkzeugzugriff

• Open WebUI: https://openwebui.com

OpenCode

• Projektseite und Dokumentation: https://opencode.ai
• Downloadvarianten (CLI und Desktop): https://opencode.ai/docs
• Konfigurationsschema für opencode.json: https://opencode.ai/config.json
• Quellcode: https://github.com/sst/opencode

CLI-Agenten, Werkzeuge und Vergleichsübersichten

• Kuratierte Übersicht quelloffener und anbietereigener CLI-Agenten: awesome-cli-coding-agents
• Vergleich OpenCode gegenüber anderen CLI-Agenten: https://terminaltrove.com/compare/ai-coding-agents/
• Model Context Protocol (MCP): https://modelcontextprotocol.io