Ollama Tutorial - Lokale LLMs in 5 Minuten starten

Ollama ist das mit Abstand einfachste Tool, um lokale Sprachmodelle auf dem eigenen Rechner zu starten. Du installierst ein einziges Paket, ziehst ein Modell mit einem Befehl und sprichst es entweder über die Kommandozeile oder über eine OpenAI-kompatible REST-API an. Es spielt keine Rolle, ob du auf einem MacBook mit Apple Silicon, einem Windows-Gaming-Rechner mit NVIDIA-Karte oder einem nackten Linux-Server arbeitest. In dieser Lektion lernst du die Installation auf allen drei Plattformen, das Laden und Verwalten von Modellen, das Schreiben eigener Modelfiles, die Integration über die REST-API, die Python-Anbindung und die GPU-Beschleunigung. Am Ende läuft dein erstes Modell, du kannst es aus eigenem Code ansprechen und kennst die typischen Stolpersteine.

Was ist Ollama eigentlich?

Ollama ist ein in Go geschriebenes Open-Source-Projekt unter MIT-Lizenz, das die Komplexität rund um lokale LLM-Inferenz hinter wenigen, klaren Befehlen versteckt. Im Kern ist es ein Wrapper um die Inferenz-Engine llama.cpp, ergänzt um einen Modell-Manager, eine HTTP-API und eine Quantisierungs-Pipeline. Du musst dich nicht mit GGUF-Dateien, Tokenizer-Konfigurationen oder GPU-Layer-Aufteilung beschäftigen, weil Ollama vernünftige Defaults wählt. Wer tiefer einsteigen will, kann jeden dieser Aspekte überschreiben.

Die Bedienung erinnert bewusst an Docker. Du kennst Befehle wie ollama pull (Modell aus dem Registry-Repository herunterladen), ollama run (Modell starten und interaktiv ansprechen), ollama serve (HTTP-API im Hintergrund) und ollama list (lokale Modelle anzeigen). Wer schon einmal Container gezogen oder Images gebaut hat, fühlt sich sofort heimisch. Genau wie bei Docker gibt es eine zentrale Registry, in der du Modelle und Modell-Varianten findest.

Ollama kommt aus der llama.cpp-Community, also aus dem Umfeld der Quantisierungs-Pioniere rund um Georgi Gerganov. Das Projekt wurde 2023 gestartet und hat innerhalb weniger Monate zur faktischen Standard-Lösung für lokale LLM-Workloads gemausert. Heute ist es Bestandteil zahlreicher Open-Source-Projekte: Open WebUI, AnythingLLM, LangChain, LlamaIndex und LibreChat unterstützen Ollama nativ. Wer einmal Ollama installiert hat, kann diese Stacks ohne weiteren Aufwand andocken.

Wichtig: Ollama ist eine Inferenz-Lösung, kein Trainings-Framework. Du benutzt vortrainierte Open-Weight-Modelle, optional mit eigenen System-Prompts und Parameter-Variationen. Wer Modelle auf eigene Daten finetunen will, braucht andere Tools wie Axolotl, Unsloth oder die Hugging-Face-Bibliotheken. Die finale Quantisierung und Auslieferung kann dann wieder über Ollama laufen, indem du dein eigenes GGUF-File in ein Modelfile packst.

Installation auf Mac, Linux, Windows

Auf macOS und Linux installierst du Ollama mit einem einzigen Shell-Befehl. Das Skript lädt das passende Binary, legt es nach /usr/local/bin/ollama und richtet auf macOS einen LaunchAgent beziehungsweise auf Linux einen systemd-Service ein. Auf Windows lädst du eine native .exe von der Projektseite, ein Doppelklick richtet einen Hintergrunddienst ein, der beim Login startet.

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

# Windows
# offizielle .exe von ollama.com herunterladen

# Verifizieren
ollama --version

Auf Linux-Servern empfehle ich, das Install-Skript vorher zu lesen (curl -fsSL https://ollama.com/install.sh -o install.sh && less install.sh), bevor du es ausführst. Das ist eine generelle Best-Practice für unbekannte Online-Skripte. Inhaltlich macht das Ollama-Skript nichts Wildes: Es erkennt die CPU-Architektur (amd64 oder arm64), lädt das passende Binary, prüft auf NVIDIA-Treiber und legt einen Service unter /etc/systemd/system/ollama.service an. Nach der Installation kannst du den Service mit systemctl status ollama prüfen.

Auf macOS bekommst du nach der Installation ein klassisches Menubar-Icon. Klick darauf öffnet keine grafische Oberfläche, sondern bestätigt nur, dass der Hintergrunddienst läuft. Die eigentliche Bedienung passiert weiterhin in der Terminal-App, die du auf deinem Mac über Spotlight aufrufst. Auf Apple-Silicon-Macs nutzt Ollama automatisch die Metal-Schnittstelle und damit die integrierte GPU plus die Neural Engine, ohne dass du etwas konfigurieren musst.

Auf Windows ist die Erfahrung ähnlich komfortabel. Die .exe registriert einen Hintergrunddienst, der unter dem aktuellen Nutzer läuft, und legt das ollama-Binary in den PATH. Du kannst danach in PowerShell, in der CMD oder in jedem WSL2-Terminal arbeiten. WSL2 ist ein eigenes Thema: Wenn du Ollama bereits unter Windows nativ installiert hast, brauchst du es im WSL2-Linux nicht erneut zu installieren. Du kannst die HTTP-API einfach über die Loopback-Adresse erreichen.

Eine kleine Stolperfalle ist Antivirus-Software auf Windows. Manche Suiten markieren Inferenz-Binaries fälschlich als Malware, weil sie viel CPU verbrauchen und Netzwerkverbindungen aufbauen. Falls die Installation hängt oder das Binary nach dem Download verschwindet, prüfe die Quarantäne. Auf Firmen-Laptops mit Endpoint-Detection lohnt sich ein kurzes Wort mit der IT, bevor du dich wunderst.

Wenn die Installation durch ist, läuft ollama --version und gibt eine Versionsnummer aus. Damit hast du die Voraussetzung, um das erste Modell zu laden. Ollama bringt selbst kein Modell mit, das holst du dir im nächsten Schritt aus der Modell-Library.

Erstes Modell laden und starten

Modelle in der Ollama-Library werden über einen Namen und einen Tag identifiziert. Der Name verweist auf die Familie (etwa llama3.2, mistral, phi3), der Tag auf eine konkrete Größen- und Quantisierungs-Variante (etwa 3b, 7b-instruct-q4_0). Ohne Tag holt Ollama die Default-Variante, was meist eine sinnvolle Quantisierung in Q4 ist.

ollama pull llama3.2:3b
ollama run llama3.2:3b "Erkläre Quantisierung in einem Satz"

Beim ersten pull lädt Ollama die Manifest-Datei und die einzelnen Layer-Blobs aus der Registry herunter. Die Dateien landen unter ~/.ollama/models (Linux/macOS) beziehungsweise %USERPROFILE%\.ollama\models (Windows). Ein 3B-Modell wiegt rund 2 GB, ein 7B-Modell zwischen 4 und 5 GB, ein 70B-Modell zwischen 35 und 50 GB. Plane den Speicherplatz also bewusst, vor allem auf Notebooks mit kleiner SSD.

Die Quantisierungs-Stufe entscheidet darüber, wie aggressiv die Modell-Gewichte komprimiert wurden. Q4_0 oder Q4_K_M sind die häufigsten Defaults und liefern eine gute Balance zwischen Qualität und Speicherbedarf. Q8 ist näher am Original, braucht aber doppelt so viel Platz und VRAM. Q2 ist extrem klein, leidet aber sichtbar an Halluzinationen. Wenn ein Tag wie q4_K_M auftaucht, beschreibt das die genaue Methode (K_M bedeutet “Mixed Precision pro Layer”). Für die meisten Praxis-Fälle reicht der Default.

Mit ollama run startest du das Modell entweder interaktiv (kein zusätzliches Argument) oder mit einem One-Shot-Prompt (Argument in Anführungszeichen). Im interaktiven Modus tippst du Nachrichten und bekommst Streaming-Antworten zurück. Mit Strg+D oder dem Befehl /bye beendest du die Sitzung. Innerhalb der Sitzung kannst du mit /set parameter temperature 0.2 Werte spontan überschreiben, mit /show info Modell-Metadaten ausgeben oder mit /save mymodel den aktuellen Zustand als neue Modell-Variante speichern.

Praktischer Tipp für die ersten Tests: Lass das Modell zwei oder drei deutsche Fragen beantworten, eine kleine Code-Aufgabe lösen und einen längeren Text zusammenfassen. So bekommst du ein Gefühl dafür, wo das Modell stark ist und wo es schwächelt. Llama 3.2 3B ist überraschend solide für deutsche Standardfragen, schwächelt aber bei mehrstufigen Logik-Aufgaben. Für anspruchsvollere Workloads probier später Llama 3.1 8B oder Mistral 7B.

Modelfile - Eigene Modell-Variante erstellen

Ein Modelfile ist eine kleine Konfigurationsdatei, mit der du aus einem Basis-Modell eine eigene Variante baust. Du gibst eine Eltern-Layer an (FROM), legst Default-Parameter fest (PARAMETER) und definierst einen System-Prompt (SYSTEM). Das Konzept ist analog zu einem Dockerfile: Du beschreibst deklarativ den Endzustand und Ollama baut daraus eine wiederverwendbare Einheit.

FROM llama3.2:3b

PARAMETER temperature 0.4
PARAMETER num_ctx 8192

SYSTEM Du bist ein freundlicher Assistent, der präzise auf Deutsch antwortet.

ollama create mein-assistent -f ./Modelfile
ollama run mein-assistent

Der Befehl ollama create baut keine neue Inferenz-Engine, sondern legt nur eine zusätzliche Manifest-Datei an, die auf die gleichen Layer-Blobs wie das Basis-Modell zeigt. Dein neues Modell verbraucht also kaum zusätzlichen Speicher. Sobald du ollama run mein-assistent aufrufst, lädt Ollama das Basis-Modell, wendet deine Parameter an und injiziert deinen System-Prompt vor jeder Konversation. Das Ergebnis ist ein deterministischeres Verhalten ohne Aufwand auf Aufrufer-Seite.

Die wichtigsten Parameter im Modelfile sind temperature (zwischen 0.0 und 2.0, niedriger heißt deterministischer), num_ctx (maximale Kontextlänge, standardmäßig 2048, je höher desto mehr RAM), num_predict (maximale Tokens in der Antwort), top_p (Nucleus Sampling, oft 0.9), top_k (Vocabulary-Beschnitt, oft 40) und repeat_penalty (gegen Wiederholungs-Schleifen). Für deutsche Geschäftsanwendungen empfehle ich temperature 0.3, num_ctx 8192 und repeat_penalty 1.15 als sinnvolle Defaults.

Über TEMPLATE lässt sich der Chat-Template überschreiben, etwa wenn du ein Modell ohne offizielle Chat-Schablone benutzt oder eine spezielle Tool-Calling-Syntax brauchst. Über MESSAGE kannst du Few-Shot-Beispiele hinterlegen, die Ollama vor jeder neuen Konversation als Kontext mitschickt. Diese Mini-Few-Shots sind oft wirksamer als ein langer System-Prompt. Drei bis fünf gute Beispiele formen das Antwort-Verhalten stärker als zwei Absätze Anweisungen.

Ein typisches Praxis-Beispiel: Du baust einen Modelfile für deinen Support, der den Stil deiner FAQ-Texte imitieren soll. Du nimmst Llama 3.1 8B als Basis, setzt temperature 0.2, schreibst einen System-Prompt mit Tonalitäts-Vorgaben und legst drei Beispiele als MESSAGE-Paare ab. Das fertige Modell heißt support-bot:v1, und alle deine Anwendungen rufen genau diesen Tag auf. Wenn du später am Verhalten schrauben willst, baust du support-bot:v2 und stellst die Anwendungen schrittweise um. So bekommst du Versionierung gratis dazu.

Modelfiles können auch eigene GGUF-Dateien einbinden, die du zum Beispiel von Hugging Face geladen hast. Statt FROM llama3.2:3b schreibst du dann FROM ./mein-feinjustiertes-modell.gguf und Ollama bindet die Datei direkt ein. Das ist der Weg, um fein justierte Modelle (LoRA-Merges, Domain-Adapter, eigene Vortrainings) in den Ollama-Workflow zu bekommen. Für reine Inferenz brauchst du dann keine separate llama.cpp-Konfiguration mehr, weil Ollama das übernimmt.

REST-API nutzen

Sobald Ollama als Hintergrunddienst läuft, lauscht es auf http://localhost:11434. Die JSON-API erlaubt dir, Modelle aus jedem beliebigen Programm anzusprechen, ohne eine Bibliothek zu installieren. Ein simples curl reicht, um das Konzept zu testen.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2:3b",
  "prompt": "Was ist eine Vektor-Datenbank?",
  "stream": false
}'

Mit "stream": false bekommst du die komplette Antwort als ein JSON-Objekt zurück, sobald die Generierung fertig ist. Mit "stream": true (oder ohne den Parameter, das ist der Default) liefert Ollama Newline-Delimited JSON: für jedes generierte Token ein eigenes Objekt mit response, done und Performance-Metriken. Der Streaming-Modus ist die richtige Wahl für interaktive UIs, der Non-Streaming-Modus passt für Batch-Skripte und kurze Calls.

Für komplexere Konversationen mit Rollen ist /api/chat der richtige Endpoint. Du schickst ein messages-Array mit Rollen system, user und assistant, exakt wie bei der OpenAI-Chat-Completions-API. Ollama bietet zusätzlich eine OpenAI-kompatible Schnittstelle unter /v1/chat/completions, sodass viele bestehende Bibliotheken ohne Code-Änderung auf Ollama umschwenken. Du musst nur die Base-URL umbiegen und einen beliebigen Dummy-API-Key setzen, weil Ollama keinen Auth-Check macht.

Embeddings holst du dir unter /api/embeddings. Du übergibst Modell und Prompt, bekommst einen Vektor zurück und kannst den in eine Vektor-Datenbank wie Qdrant, Weaviate oder ChromaDB speichern. Praktisch jedes Embedding-Modell aus der Ollama-Library funktioniert hier, etwa nomic-embed-text (768 Dimensionen, multilingual) oder mxbai-embed-large (1024 Dimensionen, sehr stark). Damit baust du dir lokale RAG-Systeme komplett ohne Cloud-Abhängigkeit.

Die API erlaubt auch Modell-Management aus dem Code: /api/pull lädt ein neues Modell, /api/push schiebt eines in die Registry, /api/tags listet vorhandene Modelle, /api/delete entfernt eines. Damit kannst du in CI/CD-Pipelines Modelle sauber bereitstellen, ohne in eine Shell zu wechseln. Für produktive Setups lohnt es sich, einen Health-Check auf /api/tags zu legen, weil dieser Endpoint sehr leichtgewichtig ist.

Wenn du Ollama auf einem Server betreibst und von außen erreichen willst, setzt du die Umgebungsvariable OLLAMA_HOST=0.0.0.0:11434, bevor du den Service startest. Achte unbedingt darauf, einen Reverse-Proxy mit Authentifizierung davorzuschalten (etwa Caddy, Nginx oder Traefik mit Basic Auth oder OIDC), weil Ollama selbst keinerlei Auth implementiert. Eine offene Ollama-Instanz im Internet ist eine Einladung für Missbrauch deiner Hardware.

Python-Integration

Die offizielle Python-Bibliothek heißt schlicht ollama und ist über pip install ollama verfügbar. Sie bietet einen High-Level-Client mit chat, generate, embeddings, list und pull. Intern wickelt sie alles über die HTTP-API ab, sodass du unter der Haube exakt die gleichen Aufrufe wie mit curl machst.

from ollama import Client

client = Client(host="http://localhost:11434")
response = client.chat(model="llama3.2:3b", messages=[
    {"role": "user", "content": "Erkläre Embeddings in 2 Sätzen."},
])
print(response["message"]["content"])

Für Streaming setzt du stream=True und iterierst über die zurückgegebenen Chunks. Jeder Chunk hat den gleichen Aufbau wie die Endantwort, nur dass done erst beim letzten Chunk auf True steht. Wer asynchron arbeiten möchte, importiert from ollama import AsyncClient und nutzt await client.chat(...). Das ist sinnvoll, wenn du in einer FastAPI- oder LangChain-Pipeline mehrere Calls gleichzeitig laufen lässt.

Die Python-Bibliothek deckt auch Embeddings und Tool-Calling ab. Mit client.embeddings(model="nomic-embed-text", prompt="...") bekommst du einen Vektor, mit client.chat(model="...", tools=[...]) aktivierst du Funktion-Aufrufe, sofern das Modell sie unterstützt (Llama 3.1 und 3.2 tun das, Mistral 7B nicht zuverlässig). Die Tool-Definition folgt dem JSON-Schema-Format aus der OpenAI-API, sodass du bestehende Tool-Schemata wiederverwenden kannst.

Wer in JavaScript oder TypeScript arbeitet, greift zur offiziellen ollama-NPM-Bibliothek. Die API ist nahezu identisch, nur mit Promises statt Async-Iteratoren. Für Go gibt es ebenfalls einen offiziellen Client. Für andere Sprachen reicht ein normaler HTTP-Client, weil die JSON-API einfach genug ist. So findest du im Schnitt für jede Sprache einen funktionierenden Pfad in unter zehn Minuten.

GPU-Beschleunigung aktivieren

Auf Mac-Geräten mit M-Serie passiert die GPU-Aktivierung vollautomatisch. Ollama nutzt die Metal-Schnittstelle und verteilt die Modell-Layer auf die integrierte GPU. Der RAM ist Unified Memory, das heißt CPU und GPU teilen sich den gleichen Speicherpool. Das ist einer der Gründe, warum ein M2 Pro mit 32 GB ein 14B-Modell flüssig laufen lässt, was auf einem klassischen Windows-Laptop mit 8 GB Grafikspeicher gar nicht möglich wäre. Du brauchst keine Treiber, keine CUDA-Toolkits, keine spezielle Konfiguration: Es funktioniert einfach.

Auf Linux mit NVIDIA-GPU brauchst du den proprietären NVIDIA-Treiber und die CUDA-Runtime. Ein nvidia-smi zeigt dir, ob die Karte erkannt wird und wie viel VRAM frei ist. Ollama erkennt verfügbare CUDA-Bibliotheken beim Start und nutzt sie automatisch. Wenn ollama serve keine GPU findet, prüfe ldconfig -p | grep cuda und stelle sicher, dass der nvidia-uvm-Kernelmodul geladen ist. Auf Headless-Servern hilft oft nvidia-modprobe -u. Mit der Umgebungsvariable OLLAMA_LLM_LIBRARY=cuda_v12 kannst du eine bestimmte CUDA-Variante erzwingen, falls Ollama auf die CPU-Bibliothek zurückfällt.

Auf Windows ist das Setup weitgehend deckungsgleich mit Linux. Du installierst den aktuellen NVIDIA-Game-Ready- oder Studio-Treiber, Ollama liefert die CUDA-Runtime direkt mit (du musst kein separates CUDA-Toolkit installieren). Falls die GPU nicht erkannt wird, schau in den Ollama-Logs (%LOCALAPPDATA%\Ollama\server.log) nach Hinweisen. Häufigste Ursache ist eine veraltete Treiber-Version, gefolgt von einer GPU mit weniger als 4 GB VRAM, die Ollama bewusst überspringt. AMD-Karten unter Windows werden über ROCm experimentell unterstützt, sind aber deutlich weniger erprobt.

Wer manuell steuern will, wie viele Modell-Layer auf die GPU geladen werden, setzt PARAMETER num_gpu im Modelfile oder schickt "options": {"num_gpu": 32} im API-Call. Der Wert beschreibt, wie viele Transformer-Layer auf die GPU offgeladet werden. Bei knappem VRAM lohnt es sich, den Wert manuell zu reduzieren, um mit der Restmenge im RAM weiterzuarbeiten. Eine grobe Faustregel: Reserviere 1 GB VRAM für Aktivierungen pro 1024 Tokens Kontext, der Rest steht für Modell-Layer zur Verfügung.

Häufige Fehler

• Zu wenig RAM: Du startest ein 13B-Modell auf einem Notebook mit 16 GB RAM und das System swappt zu Tode. Die Antwort kommt nicht oder Ollama crasht. Faustregel: Modell-Größe (in GB) plus 4 GB Reserve sollten kleiner als der freie RAM sein. Notfalls auf eine kleinere Quantisierung wechseln (etwa Q4_K_M statt Q5_K_M) oder ein kleineres Modell wählen.
• Port-Konflikt auf 11434: Ein anderer Dienst belegt schon Port 11434, etwa eine ältere Ollama-Instanz oder eine zweite Installation in WSL2. lsof -i :11434 (Linux/macOS) beziehungsweise netstat -ano | findstr :11434 (Windows) zeigt den Übeltäter. Mit OLLAMA_HOST=127.0.0.1:11500 kannst du Ollama auf einen anderen Port zwingen.
• Quantisierung zu aggressiv: Q2- oder Q3-Quantisierungen sparen massiv RAM, leiden aber sichtbar an Qualität. Wenn das Modell plötzlich Wörter erfindet, deutsche Wörter verstümmelt oder Mathe-Aufgaben falsch löst, probier eine höhere Quantisierungs-Stufe.
• Falsche Modell-Tag-Schreibweise: Tags sind case-sensitive. llama3.2:3b funktioniert, Llama3.2:3B nicht. Im Zweifel listet ollama list deine lokalen Tags exakt so, wie sie im API-Call erwartet werden.
• Cache zu klein oder voll: Wenn der Default-Pfad ~/.ollama auf einer kleinen Partition liegt, läuft die SSD voll. Setze OLLAMA_MODELS=/pfad/auf/grosse-platte als Umgebungsvariable, bevor du den Service startest, und Ollama legt alle Modelle dort ab.
• Antworten brechen mittendrin ab: Default für num_predict ist 128 Tokens, je nach Setup. Lange Antworten werden mittendrin gekappt. Setze num_predict 2048 oder -1 (unbegrenzt) im Modelfile oder pro API-Call.
• GPU wird nicht genutzt: Trotz NVIDIA-Karte läuft alles auf der CPU. Prüfe nvidia-smi, prüfe Ollama-Logs, prüfe OLLAMA_LLM_LIBRARY. Häufig hilft ein Neustart des Ollama-Service nach Treiber-Update.
• Erste Anfrage hängt: Beim ersten Call lädt Ollama das Modell in den Speicher, das kann je nach Größe und Disk-Geschwindigkeit 5 bis 30 Sekunden dauern. Folge-Calls sind dann schnell. Mit OLLAMA_KEEP_ALIVE=24h bleiben Modelle länger im Speicher.

Nächster Schritt

Du hast Ollama installiert, dein erstes Modell läuft, du kennst Modelfiles, REST-API und Python-Anbindung. Im nächsten Schritt vertiefst du dein Wissen mit den Modell-spezifischen Guides: Llama lokal installieren zeigt dir die Llama-Familie im Detail, Mistral lokal installieren deckt das europäische Pendant ab, und der Hardware-Guide hilft dir, die richtige Maschine für deinen Use-Case auszuwählen. Wer es eilig hat, springt direkt zum Hardware-Guide, weil das die meisten Fragen am Anfang klärt.