Was ist Ollama? Funktionsweise, Modelle und Einsatzgebiete

Große Sprachmodelle lokal zu betreiben scheitert selten am Modell selbst, sondern an der Toolchain: Gewichte konvertieren, Runtime kompilieren, GPU-Layer konfigurieren. Ollama fasst diese Schritte in einem einzigen Dienst zusammen und stellt die Modelle über eine HTTP-API bereit. Dieser Artikel erklärt, wie Ollama intern arbeitet, welche Modelle es unterstützt und wo der Einsatz technisch sinnvoll ist.

Was ist Ollama?

Ollama ist eine quelloffene Laufzeitumgebung für große Sprachmodelle, die Modellgewichte im GGUF-Format verwaltet, sie über einen lokalen HTTP-Server auf Port 11434 bereitstellt und die Inferenz wahlweise auf CPU oder GPU ausführt.

Technisch besteht Ollama aus zwei Teilen: einem Kommandozeilen-Client und einem Hintergrunddienst. Der Dienst verwaltet den Modellspeicher, lädt Modelle aus einer Registry und startet für jede Anfrage einen Runner-Prozess, der auf llama.cpp aufsetzt. Modelle liegen dabei nicht als einzelne Dateien vor, sondern als inhaltsadressierte Blobs mit einem Manifest, ähnlich dem Aufbau von Container-Images.

Voraussetzungen

• Ein Linux-Host mit x86_64- oder ARM64-CPU, zum Beispiel eine skalierbare Cloud-VPS für Linux-Workloads
• Mindestens 8 GB RAM für 7B-Modelle, 16 GB für komfortables Arbeiten
• 20 GB freier Speicherplatz unter /usr/share/ollama für Modell-Blobs
• Ein Benutzerkonto mit sudo-Rechten
• Optional: NVIDIA-GPU mit installiertem Treiber ab Version 535 für CUDA-Beschleunigung

Wie funktioniert Ollama intern?

Ollama trennt Client und Server: Der Befehl ollama run schickt eine HTTP-Anfrage an den lokalen Dienst, der das Modell bei Bedarf aus der Registry lädt, die GGUF-Gewichte in den Speicher legt und die Antwort als Token-Stream zurückgibt.

Die Entscheidung, ob Layer in den VRAM ausgelagert werden, trifft der Dienst automatisch anhand der erkannten GPU und der Modellgröße. Passt ein Modell nicht vollständig in den Grafikspeicher, läuft ein Teil der Layer auf der CPU. Das funktioniert, kostet aber deutlich Durchsatz.

graph TD
    A["ollama run llama3.2:3b"] --> B["Ollama-CLI"]
    B -->|HTTP 127.0.0.1:11434| C["Ollama-Server"]
    C --> D{"Modell lokal vorhanden?"}
    D -->|nein| E["Download aus der Registry"]
    E --> F["Blobs im Model Store"]
    D -->|ja| F
    F --> G["Runner lädt GGUF-Gewichte"]
    G --> H{"GPU verfügbar?"}
    H -->|ja| I["Layer in den VRAM auslagern"]
    H -->|nein| J["Inferenz über CPU und RAM"]
    I --> K["Antwort als Token-Stream"]
    J --> K

Ollama installieren

Das offizielle Installationsskript legt das Binary unter /usr/local/bin/ollama ab, erzeugt den Systembenutzer ollama und registriert eine systemd-Unit.

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

Prüfe danach Version und Dienststatus:

$ ollama --version
$ systemctl status ollama --no-pager

Der Dienst lauscht standardmäßig ausschließlich auf 127.0.0.1:11434. Das ist die richtige Voreinstellung, denn die API kennt keine eigene Authentifizierung.

Erstes Modell laden und ausführen

Mit ollama pull lädst du ein Modell in den lokalen Store, mit ollama run startest du eine interaktive Sitzung oder schickst einen einzelnen Prompt.

$ ollama pull llama3.2:3b
$ ollama run llama3.2:3b "Erkläre den Unterschied zwischen TCP und UDP in drei Sätzen."
$ ollama list

Der Tag hinter dem Doppelpunkt bezeichnet die Variante. llama3.2:3b meint die 3-Milliarden-Parameter-Version, llama3.2:3b-instruct-q8_0 zusätzlich eine bestimmte Quantisierung. Ohne Tag zieht Ollama :latest, was in der Regel eine 4-Bit-Quantisierung der mittleren Größe ist.

Welche Modelle unterstützt Ollama?

Ollama unterstützt alle Modelle im GGUF-Format aus der offiziellen Registry, darunter Llama, Mistral, Qwen, Gemma, Phi und DeepSeek, ergänzt um spezialisierte Embedding-, Code- und Vision-Modelle.

Eigene GGUF-Dateien lassen sich ebenfalls einbinden, indem du sie im Modelfile mit FROM /pfad/zur/datei.gguf referenzierst. Modelle im Safetensors-Format akzeptiert Ollama seit Version 0.3 direkt für Llama-, Mistral- und Gemma-Architekturen.

Quantisierung und Speicherbedarf

Die Quantisierung bestimmt, mit wie vielen Bit pro Gewicht ein Modell gespeichert wird, und entscheidet damit über Speicherbedarf, Geschwindigkeit und Antwortqualität.

Als Faustregel gilt: Ein größeres Modell mit q4_K_M liefert bessere Ergebnisse als ein kleineres Modell mit q8_0 bei gleichem Speicherbedarf. Rechne zusätzlich rund 1 bis 2 GB für den KV-Cache ein, bei großen Kontextfenstern deutlich mehr.

Die REST-API nutzen

Der Ollama-Server stellt unter http://127.0.0.1:11434 eine eigene REST-API bereit und zusätzlich seit Version 0.1.24 einen OpenAI-kompatiblen Endpunkt unter /v1.

$ curl http://127.0.0.1:11434/api/generate -d '{"model":"llama3.2:3b","prompt":"Was ist ein Reverse Proxy?","stream":false}'

Der OpenAI-kompatible Pfad erlaubt es, bestehende Clients ohne Codeänderung umzubiegen. Als API-Key genügt ein beliebiger Platzhalter:

$ curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ollama" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Nenne drei systemd-Befehle."}]}'

Wichtige Endpunkte: /api/generate für einzelne Prompts, /api/chat für Konversationen mit Verlauf, /api/embeddings für Vektoren und /api/tags für die Liste der lokalen Modelle.

Eigene Modellvarianten per Modelfile

Ein Modelfile definiert Basismodell, Inferenzparameter und System-Prompt. Daraus erzeugt ollama create eine benannte Variante, die sich wie jedes andere Modell ansprechen lässt.

FROM llama3.2:3b
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
PARAMETER repeat_penalty 1.1
SYSTEM """Du bist ein Assistent für Linux-Systemadministration. Antworte knapp und nenne immer den konkreten Befehl."""

$ ollama create ops-assistent -f /opt/ollama/Modelfile
$ ollama run ops-assistent "Wie prüfe ich offene Ports?"

num_ctx verdient besondere Aufmerksamkeit: Der Standardwert liegt je nach Modell bei 2048 oder 4096 Token. Wer ihn auf 32768 hochzieht, vervielfacht den Speicherbedarf des KV-Cache und riskiert, dass Layer aus dem VRAM in den RAM zurückfallen.

GPU-Nutzung prüfen und steuern

Der Befehl ollama ps zeigt in der Spalte PROCESSOR, welcher Anteil eines geladenen Modells im VRAM und welcher im RAM liegt.

$ ollama ps
NAME            ID              SIZE      PROCESSOR    UNTIL
llama3.2:3b     a80c4f17acd5    3.5 GB    100% GPU     4 minutes from now

Steht dort 100% GPU, läuft die Inferenz vollständig auf der Grafikkarte. Ein Wert wie 62%/38% CPU/GPU bedeutet, dass VRAM fehlt. Für 14B-Modelle und größer sowie für parallele Anfragen lohnt sich eine dedizierte GPU-Instanz für LLM-Inferenz mit ausreichend VRAM, weil dort die gesamten Layer im Grafikspeicher bleiben.

Das Verhalten des Dienstes steuerst du über Umgebungsvariablen in einem systemd-Override:

$ sudo systemctl edit ollama

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_MAX_LOADED_MODELS=2"

OLLAMA_KEEP_ALIVE legt fest, wie lange ein Modell nach der letzten Anfrage im Speicher bleibt. Der Standard sind 5 Minuten. Bei Diensten mit unregelmäßigem Traffic vermeidet ein höherer Wert wiederholte Ladezeiten von mehreren Sekunden. Wenn du OLLAMA_HOST=0.0.0.0:11434 setzt, ist die API ohne jede Authentifizierung im Netz erreichbar. Setze in dem Fall zwingend eine Firewall-Regel oder einen Reverse Proxy mit Auth davor.

Wofür wird Ollama eingesetzt?

Ollama wird überall dort eingesetzt, wo Prompts und Ergebnisse die eigene Infrastruktur nicht verlassen dürfen oder wo Inferenzkosten pro Token durch feste Serverkosten ersetzt werden sollen.

• Datenschutzkritische Verarbeitung: Vertrags-, Personal- oder Patientendaten bleiben auf dem eigenen Host.
• RAG-Systeme: nomic-embed-text erzeugt Embeddings, ein Chat-Modell formuliert die Antwort. Beides über dieselbe API.
• Entwicklung und Tests: Anwendungen gegen die OpenAI-kompatible Schnittstelle entwickeln, ohne API-Kosten zu erzeugen.
• Batch-Verarbeitung: Klassifikation, Zusammenfassung oder Übersetzung großer Dokumentmengen über Nacht.
• Code-Assistenz: qwen2.5-coder oder vergleichbare Modelle als Backend für Editor-Plugins.

Nicht geeignet ist Ollama als Hochlast-Serving-Stack für viele gleichzeitige Nutzer. Dafür sind Systeme mit Continuous Batching wie vLLM die passendere Wahl.

Verifikation

Drei Befehle bestätigen, dass die Installation vollständig funktioniert:

$ systemctl is-active ollama
active
$ curl -s http://127.0.0.1:11434/api/tags | head -c 120
{"models":[{"name":"llama3.2:3b","model":"llama3.2:3b","modified_at":
$ ollama run llama3.2:3b "Antworte nur mit OK."
OK

Liefern alle drei Befehle diese Ausgaben, sind Dienst, API und Inferenz einsatzbereit.

Troubleshooting

Error: listen tcp 127.0.0.1:11434: bind: address already in use: Es läuft bereits eine Ollama-Instanz, meist der systemd-Dienst. Stoppe entweder den Dienst mit sudo systemctl stop ollama oder verzichte auf den manuellen Start von ollama serve.

Modell läuft trotz GPU auf der CPU: Prüfe mit nvidia-smi, ob der Treiber die Karte erkennt, und sieh in journalctl -u ollama -n 50 nach Meldungen zur Library-Erkennung. Häufigste Ursache ist ein Treiber älter als Version 535 oder eine fehlende Neustart des Dienstes nach der Treiberinstallation.

Prozess wird vom OOM-Killer beendet: Das Modell passt nicht in den Arbeitsspeicher. Wechsle auf eine kleinere Quantisierung, reduziere num_ctx oder setze OLLAMA_MAX_LOADED_MODELS=1, damit nicht mehrere Modelle gleichzeitig im Speicher gehalten werden.

Fazit

Ollama reduziert den Betrieb lokaler Sprachmodelle auf drei Befehle: installieren, pull, run. Die eigentliche Arbeit liegt danach in der Dimensionierung. Wähle Modellgröße und Quantisierung passend zum verfügbaren VRAM, kontrolliere das Ergebnis mit ollama ps und passe num_ctx sowie OLLAMA_KEEP_ALIVE an dein Lastprofil an. Als nächster Schritt bietet sich ein Modelfile mit festem System-Prompt an, damit die Anwendungslogik nicht bei jedem Aufruf denselben Kontext mitschicken muss.

Weiterlesen

• Lokales Coding-Modell mit Ollama in der IDE nutzen
• Die Ollama-API aus eigenen Anwendungen ansprechen
• Ollama auf Ubuntu 24.04 installieren und als Dienst betreiben
• Ollama im Docker-Container betreiben
• Ollama im Netzwerk freigeben: Port, Bind-Adresse und Absicherung
• Ollama, LM Studio oder llama.cpp: Welches Werkzeug wofür?
• Ollama mit MCP-Servern verbinden: Werkzeuge für lokale Modelle
• Ollama-Modelle verwalten: aktualisieren, aufräumen, Speicher sparen
• Open WebUI als Oberfläche für Ollama einrichten