Wer im August 2026 nach einer Alternative zu ChatGPT, Claude oder Gemini sucht, landet fast zwangsläufig bei Ollama. Das Tool hat sich in Deutschland zum Standardweg entwickelt, um Sprachmodelle wie Llama 3.3, Mistral oder Qwen2.5 direkt auf dem eigenen Rechner laufen zu lassen, ganz ohne Cloud-Abo und ohne dass Firmendaten das Haus verlassen. Diese Anleitung zeigt in 12 Schritten, wie die Installation unter Linux, macOS und Windows gelingt, wie GPU-Beschleunigung funktioniert und wie am Ende ein eigener Dokumenten-Chatbot läuft.

Was ist Ollama und warum lokale LLMs 2026 wieder gefragt sind

Ollama ist eine Laufzeitumgebung, die Open-Source-Sprachmodelle bündelt, herunterlädt und über eine einfache Kommandozeile sowie eine REST-API bereitstellt. Statt CUDA-Bibliotheken, Python-Umgebungen und Modellgewichte einzeln zu jonglieren, reicht ein einziger Befehl, um ein Modell zu starten. Genau diese Einfachheit hat Ollama zum meistgesuchten Einstiegspunkt für lokale KI in Deutschland gemacht, mit rund 49.500 monatlichen Google-Suchanfragen allein im deutschsprachigen Raum.

Der Trend hat handfeste Gründe. Unternehmen in der DACH-Region achten seit der verschärften Auslegung der DSGVO besonders genau darauf, wohin Prompt-Daten fließen. Ein lokal betriebenes Modell verlässt den eigenen Server nie. Dazu kommt technischer Fortschritt: Mit Llama 3.3, Mistral Large 3 (Apache-2.0-Lizenz) und dem im Juli 2026 veröffentlichten Leanstral 1.5 von Mistral stehen offene Modelle bereit, die in vielen Alltagsaufgaben nah an kommerzielle APIs herankommen. Auch DeepSeek V4 und gpt-oss-120b gehören laut aktuellen Marktübersichten zum Kreis der 2026 produktionsreifen Open-Weight-Modelle.

Für IT-Abteilungen kommt ein dritter Grund dazu: Kontrolle über Kosten. Cloud-APIs rechnen nach Token ab, ein Wert, der bei wachsender Nutzung schwer vorherzusagen ist. Ein einmal eingerichteter Ollama-Server dagegen verursacht nach der Anschaffung nur noch Stromkosten, unabhängig davon, wie viele Anfragen ein Team an einem Tag stellt. Genau diese Kombination aus Datenschutz, technischer Reife und planbaren Kosten erklärt, warum lokale LLMs 2026 nicht mehr nur ein Hobbyprojekt für Bastler sind, sondern zunehmend in echten Unternehmensprozessen landen.

Diese Anleitung richtet sich an Entwicklerinnen und Entwickler, IT-Admins und technisch interessierte Nutzer, die Ollama von Grund auf einrichten wollen, inklusive Docker-Betrieb, GPU-Support und einem vollständigen Chatbot-Projekt am Ende.

Der Zeitpunkt für den Einstieg ist günstig gewählt. Neben den etablierten Namen hat Mistral im Mai 2026 mit Medium 3.5 ein neues Flaggschiff seiner Premier-Reihe veröffentlicht, das sich auch für Remote-Coding-Agents eignet, während Anfang Juli 2026 mit Robostral Navigate erstmals ein Modell speziell für Robotik-Aufgaben erschien. Für den klassischen Textbetrieb über Ollama bleiben aber vor allem Llama 3.3, die Mistral-Small- und Large-Varianten sowie Qwen2.5 die praxisnächsten Kandidaten, weil sie in vernünftiger Größe vorliegen und ohne exotische Hardware laufen.

Voraussetzungen: Hardware und Software im Überblick

Bevor es losgeht, lohnt sich ein Blick auf die Mindestanforderungen. Ollama läuft grundsätzlich auch ohne GPU, nur eben spürbar langsamer. Für ernsthafte Arbeit empfehlen aktuelle Setup-Guides mindestens 16 GB Arbeitsspeicher, besser 32 GB, sowie eine Grafikkarte mit mindestens 8 GB VRAM.

KomponenteMinimumEmpfohlenHinweis
BetriebssystemUbuntu 22.04, macOS 13, Windows 10Ubuntu 24.04, macOS 15, Windows 11Ollama unterstützt alle drei Plattformen nativ
RAM16 GB32 GB oder mehrGrößere Modelle brauchen mehr Arbeitsspeicher
GPU-VRAMkeine (CPU-Modus)8 GB+ (NVIDIA, AMD oder Apple Silicon)Beschleunigt Inferenz um ein Vielfaches
Speicherplatz20 GB frei100 GB+ SSDModelle wiegen zwischen 2 und 70+ GB
Dockeroptionalaktuelle VersionFür Open WebUI und Container-Betrieb

Wichtig für Nvidia-Nutzer: Die aktuellen CUDA-Treiber sollten vor der Ollama-Installation eingerichtet sein. AMD-Karten benötigen die ROCm-Treiber, Apple-Silicon-Rechner (M-Serie) profitieren automatisch von der Metal-Beschleunigung, ganz ohne Zusatzinstallation.

Ein Punkt wird in vielen Anleitungen übersehen: Die Anforderungen hängen stark von der gewählten Modellgröße ab, nicht nur vom Modellnamen. Ein 8-Milliarden-Parameter-Modell läuft auf fast jedem aktuellen Laptop flüssig, während ein 70-Milliarden-Parameter-Modell selbst mit Quantisierung eine dedizierte GPU mit mindestens 24 GB VRAM verlangt, wenn es komplett im Grafikspeicher laufen soll. Wer weniger VRAM hat, kann Ollama auch Teile des Modells auf die CPU auslagern lassen, muss dann aber mit deutlich längeren Antwortzeiten rechnen. Für ein Team, das täglich mit einem 70B-Modell arbeitet, lohnt sich daher vorab eine kurze Kalkulation, ob eine gebrauchte RTX-3090 mit 24 GB VRAM oder gleich eine aktuelle Karte mit mehr Speicher die bessere Investition ist.

Schritt 1: Ollama unter Linux, macOS und Windows installieren

Die Installation unterscheidet sich je nach Betriebssystem, bleibt aber überall auf einen einzigen Befehl reduziert.

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

# macOS: per Homebrew
brew install ollama

# Windows: in PowerShell ausführen
irm https://ollama.com/install.ps1 | iex

Unter Linux legt das Skript automatisch einen systemd-Dienst an, der Ollama im Hintergrund startet. Auf macOS und Windows übernimmt das die App selbst, ein kleines Icon in der Menüleiste beziehungsweise im Systemtray zeigt den laufenden Dienst an. Wer lieber ein Docker-Image nutzt, überspringt diesen Schritt und springt direkt zu Schritt 10.

Schritt 2: Installation prüfen und den Dienst starten

Nach der Installation prüft ein kurzer Versionscheck, ob alles funktioniert hat.

ollama --version
ollama serve

Läuft der Dienst bereits im Hintergrund, meldet ollama serve einen belegten Port. Das ist normal, kein Fehler. Die Ausgabe von ollama --version sieht typischerweise so aus:

ollama version is 0.x.x

Erscheint stattdessen “command not found”, fehlt der Pfad in der Shell-Konfiguration. Ein Neustart des Terminals oder ein manuelles Quellen der Shell-Profildatei (source ~/.bashrc) behebt das meist sofort.

Schritt 3: Das erste Modell herunterladen mit ollama pull

Modelle werden nicht mitinstalliert, sondern separat geladen. Für den Einstieg eignet sich ein kompaktes, aber leistungsfähiges Modell.

ollama pull llama3.3:70b
ollama pull qwen2.5:14b
ollama pull mistral-small

Der Download zeigt einen Fortschrittsbalken pro Layer an, ähnlich wie bei Docker-Images. Ein Modell mit 70 Milliarden Parametern wiegt in quantisierter Form (Q4) meist 35 bis 45 GB, ein 7B- bis 8B-Modell dagegen nur 4 bis 5 GB. Wer wenig Speicherplatz oder eine schwächere GPU hat, startet besser mit einem kleineren Modell wie llama3.2 oder mistral:7b.

Schritt 4: Modelle im Chat ausführen mit ollama run

Sobald ein Modell heruntergeladen ist, startet der interaktive Chat mit einem einzigen Befehl.

ollama run llama3.3:70b

Die Terminal-Ausgabe sieht dann typischerweise so aus:

>>> Sende eine Nachricht (/? fuer Hilfe)
>>> Erklaere mir in zwei Saetzen, was Ollama macht.
Ollama laedt Open-Source-Sprachmodelle herunter und stellt sie lokal
ueber eine einfache CLI und REST-API bereit, ohne dass Daten an
externe Server gesendet werden.

Der Chat beendet sich mit /bye oder Strg+D. Wichtig: Beim allerersten Start eines Modells dauert das Laden der Gewichte in den Speicher spürbar länger als bei folgenden Anfragen, weil Ollama das Modell danach für einige Minuten im Arbeitsspeicher behält (Standard-Keep-Alive: 5 Minuten).

Schritt 5: Modelle verwalten mit list, ps, show und rm

Mit wachsender Modellsammlung braucht es Überblick. Vier Befehle reichen für die komplette Verwaltung.

# Alle installierten Modelle anzeigen
ollama list

# Aktuell laufende (geladene) Modelle anzeigen
ollama ps

# Details zu einem Modell anzeigen
ollama show llama3.3:70b

# Modell loeschen und Speicherplatz freigeben
ollama rm mistral-small

ollama list zeigt Name, ID, Größe und Änderungsdatum jedes Modells an, etwa in dieser Form:

NAME              ID              SIZE      MODIFIED
llama3.3:70b      a6eb4748fd29    42 GB     2 days ago
qwen2.5:14b       7cdf5a0187d5    9.0 GB    2 days ago
mistral-small     f8de6d0b8b9c    4.1 GB    3 days ago

Wer regelmäßig neue Modellversionen testet, sollte alte Stände mit ollama rm löschen. Gerade 70B-Modelle summieren sich schnell auf mehrere hundert Gigabyte, und ungenutzte Modelle bringen keinerlei Vorteil, wenn sie nur Speicherplatz belegen.

Schritt 6: Die REST-API auf Port 11434 nutzen

Der eigentliche Mehrwert von Ollama zeigt sich, sobald eigene Anwendungen das Modell ansprechen. Der Dienst lauscht standardmäßig auf Port 11434.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.3:70b",
  "prompt": "Fasse die DSGVO in drei Stichpunkten zusammen.",
  "stream": false
}'

Die Antwort kommt als JSON zurück, inklusive Token-Zahl und Zeitmessung für Ladezeit und Generierung, praktisch für alle, die die Performance im Blick behalten wollen. Wer die API von einem anderen Rechner im Netzwerk erreichen will, muss die Umgebungsvariable OLLAMA_HOST=0.0.0.0 setzen, sonst bleibt der Zugriff auf localhost beschränkt.

Schritt 7: Ein eigenes Modell mit dem Modelfile bauen

Ollama erlaubt es, aus einem bestehenden Modell eine angepasste Variante zu bauen, etwa mit fester Systemrolle oder anderer Temperatur. Dafür genügt eine Textdatei namens Modelfile.

FROM llama3.3:70b
PARAMETER temperature 0.3
PARAMETER num_ctx 8192
SYSTEM """
Du bist ein praezises Support-Tool fuer deutsche IT-Teams.
Antworte kurz, sachlich und auf Deutsch.
"""
ollama create it-support -f ./Modelfile
ollama run it-support

Diese Technik eignet sich für Teams, die dasselbe Basismodell für mehrere Anwendungsfälle einsetzen wollen, etwa Support-Bot, Code-Reviewer und Übersetzer, jeweils mit eigenem Systemprompt, aber ohne dass die Modellgewichte mehrfach gespeichert werden müssen.

Schritt 8: Die OpenAI-kompatible API verwenden

Seit einigen Versionen bietet Ollama zusätzlich einen Endpunkt, der die OpenAI-API nachbildet. Damit lassen sich bestehende Tools und SDKs, die ursprünglich für ChatGPT geschrieben wurden, ohne Codeänderung auf ein lokales Modell umstellen.

curl http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.3:70b",
  "messages": [{"role": "user", "content": "Was ist der Unterschied zwischen RAM und VRAM?"}]
}'

Wer bereits mit der offiziellen OpenAI-Python-Bibliothek arbeitet, muss lediglich die base_url auf http://localhost:11434/v1 ändern und einen beliebigen Platzhalter als API-Key eintragen. Der Rest des Codes bleibt unverändert.

Schritt 9: Open WebUI als grafische Oberfläche einrichten

Für Nutzer, die nicht dauerhaft im Terminal arbeiten wollen, bietet sich Open WebUI an, eine browserbasierte Oberfläche im Stil von ChatGPT, die direkt mit Ollama kommuniziert.

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

Nach dem Start ist die Oberfläche unter http://localhost:3000 erreichbar. Beim ersten Aufruf legt Open WebUI ein lokales Admin-Konto an, danach lassen sich alle über Ollama installierten Modelle direkt aus einem Dropdown auswählen, inklusive Chatverlauf, Dokumenten-Upload und Multi-User-Verwaltung.

Schritt 10: Ollama in Docker betreiben

Wer Ollama selbst containerisieren möchte, etwa für ein Homelab oder einen Server, nutzt am besten eine Docker-Compose-Datei, die Ollama und Open WebUI gemeinsam startet.

version: "3.8"
services:
  ollama:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama-data:/root/.ollama
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama
    restart: unless-stopped

volumes:
  ollama-data:
docker compose up -d

Der entscheidende Punkt hier ist die Umgebungsvariable OLLAMA_BASE_URL, die auf den Container-Namen ollama statt auf localhost zeigt. Genau diese Zeile vergessen die meisten beim ersten Versuch, mit der Folge, dass Open WebUI keine Modelle findet.

Schritt 11: GPU-Beschleunigung für Nvidia, AMD und Apple Silicon einrichten

Ohne GPU rechnet Ollama auf der CPU, was bei größeren Modellen schnell mehrere Sekunden pro Wort bedeutet. Mit passender Grafikkarte sieht das anders aus.

# Docker mit NVIDIA-GPU-Zugriff starten
docker run -d --gpus=all -p 11434:11434 ollama/ollama

# Anzahl der GPU-Layer manuell festlegen (bei knappem VRAM)
OLLAMA_NUM_GPU=35 ollama run llama3.3:70b

Für Nvidia-Karten wird das NVIDIA Container Toolkit vorausgesetzt, AMD-Nutzer installieren stattdessen die ROCm-Treiber und starten den Container mit den passenden Geräte-Flags. Auf Apple-Silicon-Macs (M-Serie) greift Ollama automatisch auf die Metal-API zurück, ganz ohne Zusatzkonfiguration. Wer llama.cpp direkt statt Ollama einsetzt, kompiliert die GPU-Unterstützung selbst: make GGML_CUDA=1 für Nvidia, make GGML_HIPBLAS=1 für AMD und make GGML_METAL=1 für Apple Silicon.

Schritt 12: Komplettes Projekt – ein lokaler Dokumenten-Chatbot in Python

Zum Abschluss ein vollständiges, lauffähiges Beispiel: ein einfacher Chatbot, der eigene Textdateien einliest und Fragen dazu über die lokale Ollama-API beantwortet. Zunächst die Python-Abhängigkeiten:

pip install requests
import requests
import glob

OLLAMA_URL = "http://localhost:11434/api/generate"
MODEL = "llama3.3:70b"

def dokumente_laden(pfad="./dokumente/*.txt"):
    inhalte = []
    for datei in glob.glob(pfad):
        with open(datei, "r", encoding="utf-8") as f:
            inhalte.append(f.read())
    return "\n\n".join(inhalte)

def frage_stellen(kontext, frage):
    prompt = f"""Beantworte die Frage ausschliesslich auf Basis des Kontexts.

Kontext:
{kontext}

Frage: {frage}
Antwort:"""

    antwort = requests.post(OLLAMA_URL, json={
        "model": MODEL,
        "prompt": prompt,
        "stream": False
    })
    return antwort.json()["response"]

if __name__ == "__main__":
    kontext = dokumente_laden()
    while True:
        frage = input("Frage (oder 'exit'): ")
        if frage == "exit":
            break
        print(frage_stellen(kontext, frage))

Legt man .txt-Dateien in den Ordner dokumente, beantwortet der Bot Fragen ausschließlich anhand dieser Inhalte, ganz ohne dass ein einziges Byte an einen externen Anbieter geht. Für größere Dokumentenmengen lohnt sich später der Ausbau zu echtem RAG mit einer Vektordatenbank wie Chroma oder Qdrant, aber für Teams mit überschaubarem Wissensbestand reicht dieser einfache Ansatz oft völlig aus.

Welche Modelle sich 2026 wirklich lohnen

Die Modelllandschaft hat sich seit Anfang 2026 spürbar weiterentwickelt. Für die Auswahl über Ollama sind vor allem Lizenz, Größe und Einsatzzweck entscheidend.

ModellParameterLizenzGuter Einsatzzweck
Llama 3.370BLlama Community LicenseAllgemeine Aufgaben, gute Deutschkenntnisse
Qwen2.514BApache 2.0Schnelle Antworten auf schwächerer Hardware
Mistral Small / Large 37B / großes MoEApache 2.0Mehrsprachige Aufgaben, EU-Anbieter
DeepSeek V4groß (MoE)MIT, mit Hosting-VorbehaltCoding und Reasoning
gpt-oss-120b120BApache 2.0Komplexe Aufgaben mit viel VRAM
Codellama34BLlama Community LicenseCode-Vervollständigung und Reviews

Aktuelle Marktübersichten zu Open-Weight-Modellen für deutsche Unternehmen führen Mistral Large 3, DeepSeek V4, gpt-oss-120b und das vollständig offene Schweizer Modell Apertus als 2026 produktionsreife Optionen, weil ihre Lizenzen einen Betrieb auf eigener Infrastruktur ausdrücklich erlauben. Wer mit begrenztem VRAM arbeitet, sollte grundsätzlich mit einer kleineren Variante beginnen und erst bei Bedarf auf größere Parameterzahlen wechseln.

Bei der Lizenzwahl lohnt sich ein zweiter Blick, besonders für Unternehmen. Die Llama Community License von Meta erlaubt die kommerzielle Nutzung, schränkt sie aber für sehr große Organisationen mit mehr als 700 Millionen monatlich aktiven Nutzern ein, eine Grenze, die für die allermeisten deutschen Mittelständler ohnehin keine Rolle spielt. Modelle unter Apache-2.0-Lizenz wie Mistral Large 3 oder gpt-oss-120b räumen dagegen weniger Einschränkungen ein und eignen sich deshalb besonders für Firmen, die auf Nummer sicher gehen wollen.

Typische Einsatzszenarien für Ollama im Unternehmensalltag

In der Praxis tauchen bei deutschen IT-Teams immer wieder dieselben drei Anwendungsfälle auf. Der erste ist ein interner Support-Bot, der über das Modelfile aus Schritt 7 mit dem Wissen des eigenen Helpdesks kombiniert wird und Standardanfragen beantwortet, ohne dass Ticket-Inhalte je eine Cloud erreichen. Der zweite ist Code-Unterstützung: Modelle wie Codellama oder die coding-optimierten Varianten von DeepSeek laufen direkt in der Entwicklungsumgebung und liefern Vorschläge, ohne dass Quellcode das Firmennetz verlässt, ein Argument, das gerade bei Kundenprojekten mit strengen Vertraulichkeitsklauseln zählt.

Der dritte, häufigste Fall ist genau das Projekt aus Schritt 12: ein Dokumenten-Chatbot, der interne Handbücher, Richtlinien oder technische Dokumentation durchsuchbar macht. Für Teams mit wenigen hundert Seiten reicht der einfache Textdatei-Ansatz meist aus, größere Wissensbestände profitieren von einer echten Vektordatenbank. In allen drei Fällen bleibt der zentrale Vorteil derselbe: volle Kontrolle darüber, wohin die Daten fließen, kombiniert mit planbaren Kosten, die nicht mit jedem zusätzlichen Prompt weiter steigen.

Häufige Fehler und Stolperfallen beim Einstieg

  • Zu großes Modell für die vorhandene Hardware: Ein 70B-Modell auf einer 8-GB-GPU führt fast immer zu Auslagerung auf die CPU und quälend langsamen Antworten. Besser mit einem kleineren Modell wie Llama 3.2 oder Qwen2.5 14B starten und erst bei Bedarf hochskalieren.
  • Port 11434 doppelt belegt: Läuft bereits ein Ollama-Prozess im Hintergrund, meldet ein zweiter Start des Dienstes einen Fehler. Vorher mit ollama ps prüfen, ob der Dienst schon aktiv ist, statt den Fehler blind zu ignorieren.
  • OLLAMA_HOST vergessen: Ohne OLLAMA_HOST=0.0.0.0 bleibt der Zugriff aus dem lokalen Netzwerk oder aus einem Docker-Container blockiert, selbst wenn der Port offen ist. Viele Einsteiger suchen den Fehler dann fälschlicherweise in der Firewall.
  • API ungeschützt ins Internet gestellt: Ollama bringt standardmäßig keine Authentifizierung mit. Wer Port 11434 direkt am Router freigibt, öffnet die Tür für jeden im Internet, der mit dem Modell kostenlos rechnen oder es missbrauchen kann. Ein Reverse-Proxy mit Zugriffskontrolle ist Pflicht, nicht optional.
  • Falsche Quantisierung gewählt: Volle FP16-Gewichte brauchen doppelt so viel Speicher wie Q4-Quantisierungen, ohne dass die Antwortqualität im Alltag spürbar besser wird. Für die meisten Aufgaben reicht Q4 völlig aus und spart erheblich VRAM.
  • Docker-Netzwerk falsch konfiguriert: Zeigt Open WebUI im Container auf localhost statt auf den Ollama-Container-Namen, findet es keine Modelle. Immer den Servicenamen aus der Compose-Datei verwenden, niemals eine feste IP-Adresse.
  • Modell-Updates ignoriert: Wer ein Modell einmal geladen hat, bekommt neuere Versionen nicht automatisch. Ein regelmäßiges ollama pull auf denselben Modellnamen holt Bugfixes und Verbesserungen nach, kostet aber erneut Bandbreite und Speicherplatz.
  • Kontextfenster zu knapp bemessen: Wird num_ctx nicht angepasst, schneidet Ollama lange Unterhaltungen oder große Dokumente einfach ab, ohne eine deutliche Fehlermeldung auszugeben. Das führt oft zu scheinbar “vergesslichen” Antworten.

Troubleshooting: 10 typische Probleme und ihre Lösungen

1. “ollama: command not found” nach der Installation. Das Terminal neu starten oder source ~/.bashrc beziehungsweise source ~/.zshrc ausführen, damit der neue Pfad geladen wird. Hilft das nicht, prüfen, ob das Installationsskript tatsächlich ohne Fehler durchgelaufen ist, ein abgebrochener Download hinterlässt manchmal ein unvollständiges Binary.

2. “connection refused” auf Port 11434. Prüfen, ob der Dienst überhaupt läuft: ps aux | grep ollama unter Linux/macOS oder der Task-Manager unter Windows. Fehlt der Prozess, hilft ollama serve im Vordergrund, um Fehlermeldungen direkt zu sehen, statt im Blindflug zu debuggen.

3. Modell-Download bricht ab oder hängt. Meist liegt es an einer instabilen Verbindung oder einem überlasteten Registry-Server. ollama pull erneut ausführen, der Download setzt bereits geladene Layer automatisch fort und muss nicht von vorn beginnen.

4. GPU wird nicht erkannt. Mit nvidia-smi prüfen, ob der Treiber selbst die Karte sieht. Erscheint dort nichts, liegt das Problem am Treiber, nicht an Ollama. Bei Docker zusätzlich prüfen, ob --gpus=all gesetzt und das NVIDIA Container Toolkit korrekt installiert ist, ein häufig übersehener Schritt bei frischen Server-Installationen.

5. Out-of-Memory-Fehler beim Laden eines Modells. Ein kleineres oder stärker quantisiertes Modell wählen, etwa Q4 statt Q8, oder die Anzahl der auf die GPU ausgelagerten Layer über OLLAMA_NUM_GPU reduzieren. Auch das Schließen anderer speicherhungriger Programme schafft oft genug Puffer.

6. Open WebUI zeigt “no models found”. Die Umgebungsvariable OLLAMA_BASE_URL in der Compose-Datei kontrollieren, sie muss auf den Ollama-Servicenamen zeigen, nicht auf localhost. Ein Neustart des Containers nach der Änderung ist zwingend nötig, ein einfaches Neuladen der Browserseite reicht nicht.

7. Antworten werden mitten im Satz abgeschnitten. Der Kontext ist meist zu klein gewählt. Im Modelfile oder direkt im API-Aufruf num_ctx auf einen höheren Wert wie 8192 oder 16384 setzen, wobei ein größerer Kontext auch mehr VRAM verbraucht.

8. Windows-Firewall blockiert den Zugriff aus dem Netzwerk. Eine eingehende Regel für Port 11434 in der Windows Defender Firewall anlegen, sonst bleibt der Dienst nur lokal erreichbar, selbst wenn OLLAMA_HOST korrekt gesetzt ist.

9. Modell reagiert extrem langsam trotz vorhandener GPU. Mit ollama ps prüfen, ob das Modell tatsächlich auf der GPU läuft oder nur teilweise auf die CPU ausgelagert wurde. Reicht der VRAM nicht für alle Layer, sinkt die Geschwindigkeit drastisch, auch wenn theoretisch eine GPU vorhanden ist.

10. “permission denied” beim Installationsskript unter Linux. Das Skript benötigt Root-Rechte, um den systemd-Dienst einzurichten. Mit sudo ausführen oder, falls kein sudo verfügbar ist, das Binary manuell in ein Verzeichnis im PATH kopieren.

Profi-Tipps für den produktiven Einsatz

Wer Ollama über den privaten Testlauf hinaus produktiv einsetzen will, sollte ein paar Kniffe kennen. Erstens: Der Parameter OLLAMA_KEEP_ALIVE steuert, wie lange ein Modell nach der letzten Anfrage im Speicher bleibt. Für Server mit konstanter Last lohnt sich ein hoher Wert wie 24h, um das ständige Neuladen zu vermeiden.

Zweitens: Für den Zugriff über das offene Internet gehört vor Ollama immer ein Reverse-Proxy wie Caddy oder Nginx mit Basic-Auth oder OAuth, da die API selbst keine Zugriffskontrolle mitbringt. Drittens: Mehrere GPUs lassen sich über CUDA_VISIBLE_DEVICES gezielt zuweisen, was bei größeren Modellen wie gpt-oss-120b den Unterschied zwischen “läuft” und “passt nicht in den Speicher” ausmacht.

Viertens lohnt sich für Teams, die echte Retrieval-Augmented-Generation brauchen, die Kombination aus Ollama und einer Vektordatenbank wie Qdrant oder Chroma statt des einfachen Textdateien-Ansatzes aus Schritt 12. Fünftens: Wer regelmäßig zwischen Modellen wechselt, sollte ollama ps in ein Monitoring-Skript einbauen, um zu sehen, welches Modell gerade Speicher blockiert, bevor der nächste Ladevorgang an Speichermangel scheitert.

Sechstens: Wer die Antwortqualität feinjustieren will, sollte mit den Parametern temperature und top_p experimentieren, statt gleich ein anderes Modell zu suchen. Niedrigere Werte liefern konsistentere, vorhersehbarere Antworten, was sich für Support-Bots oder strukturierte Datenverarbeitung eignet, während höhere Werte für kreative Textaufgaben mehr Variation bringen. Siebtens lohnt sich ein Blick auf ollama show --modelfile, mit dem sich die vollständige Konfiguration eines bereits installierten Modells als Vorlage exportieren lässt, bevor man eigene Anpassungen daran vornimmt.

Ollama im Vergleich zu Cloud-LLMs

KriteriumOllama (lokal)Cloud-API (ChatGPT, Claude, Gemini)
DatenschutzDaten verlassen den eigenen Rechner nieDaten laufen über externe Server
Laufende Kostennur Strom und HardwareNutzung nach Token abgerechnet
Modellqualität (Spitzenmodelle)gut, aber meist hinter den größten Cloud-ModellenZugriff auf die jeweils stärksten Modelle
Offline-Fähigkeitvollständig offline nutzbarInternetverbindung zwingend nötig
Setup-Aufwandeinmalige lokale Installationsofort startklar über API-Key

Für viele DACH-Unternehmen ist die Entscheidung damit weniger eine Frage der reinen Modellqualität als eine Abwägung zwischen Datenschutz, Kostenkontrolle und Bequemlichkeit. Wer sensible Kundendaten verarbeitet, kommt an einer lokalen Lösung wie Ollama kaum vorbei.

Kostenrechnung: Was Ollama gegenüber einer Cloud-API wirklich spart

Ob sich der lokale Betrieb lohnt, hängt stark vom Nutzungsvolumen ab. Eine gebrauchte Grafikkarte mit 24 GB VRAM, die für ein 30B- bis 70B-Modell in Q4-Quantisierung ausreicht, kostet je nach Modell und Marktlage meist zwischen 600 und 1.200 Euro. Dazu kommen laufende Stromkosten, die bei intensiver Dauernutzung mit etwa 250 bis 350 Watt Leistungsaufnahme über den Tag gerechnet werden müssen. Ein Team, das täglich Hunderte Anfragen über eine Cloud-API schickt, zahlt dort nach Token, und diese Kosten wachsen linear mit dem Nutzungsvolumen, ohne Obergrenze.

Für kleine, unregelmäßige Nutzung bleibt eine Cloud-API oft günstiger, weil keine Vorabinvestition in Hardware nötig ist. Sobald ein Team aber dauerhaft mit vielen parallelen Anfragen arbeitet, etwa für automatisierte Code-Reviews oder Support-Tickets, kippt die Rechnung meist zugunsten der lokalen Lösung, weil die einmalige Hardware-Investition sich über Monate amortisiert. Wichtig dabei: Diese Kalkulation berücksichtigt nur Anschaffung und Strom, nicht den Aufwand für Wartung, Updates und Absicherung des Servers, der bei einer Cloud-API vollständig entfällt.

Migration: In 5 Schritten von der Cloud-API zu Ollama wechseln

Teams, die bereits Anwendungen gegen ChatGPT oder eine andere Cloud-API gebaut haben, müssen für den Umstieg auf Ollama selten von vorn anfangen. Fünf Schritte reichen für die meisten Projekte aus.

  • Modell auswählen: Ein offenes Modell mit vergleichbarer Größe zur bisherigen Cloud-Nutzung wählen, etwa Llama 3.3 als Ersatz für ein mittelgroßes Cloud-Modell.
  • Parallelbetrieb testen: Ollama zunächst neben der bestehenden Cloud-Anbindung laufen lassen und beide Antworten für dieselben Testfragen vergleichen, um Qualitätsunterschiede früh zu erkennen.
  • Endpunkt umstellen: Dank der OpenAI-kompatiblen API aus Schritt 8 reicht in vielen Fällen das Ändern der base_url, ohne dass der restliche Anwendungscode angefasst werden muss.
  • Prompts anpassen: Offene Modelle reagieren teils anders auf Systemprompts als kommerzielle Modelle. Ein kurzer Testlauf mit den eigenen Standardprompts deckt nötige Anpassungen auf.
  • Monitoring aufsetzen: Anders als bei einer Cloud-API gibt es kein Dashboard von Drittanbietern. Ein eigenes Logging der Antwortzeiten und Fehlerraten ersetzt das, was vorher der Cloud-Anbieter übernommen hat.

Ein vollständiger Umstieg lohnt sich selten von heute auf morgen. Realistischer ist ein hybrider Betrieb, bei dem unkritische oder besonders sensible Anfragen zuerst auf Ollama wandern, während komplexere Aufgaben vorerst bei der Cloud-API bleiben, bis das lokale Setup nachweislich stabil läuft.

Sicherheit: Ollama produktiv und sicher betreiben

Ollama selbst wurde als lokales Entwicklerwerkzeug konzipiert, nicht als produktionsreifer Server mit eingebauter Zugriffskontrolle. Wer den Dienst über den eigenen Laptop hinaus einsetzt, etwa auf einem Team-Server oder in einem Homelab, sollte deshalb ein paar grundlegende Maßnahmen ergreifen, statt sich auf die Standardeinstellungen zu verlassen.

Am wichtigsten ist die Netzwerktrennung: Der Ollama-Port 11434 sollte niemals direkt am Router in Richtung Internet freigegeben werden. Stattdessen gehört ein Reverse-Proxy wie Nginx oder Caddy davor, der Anfragen erst nach erfolgreicher Authentifizierung durchlässt. Für Teams mit mehreren Nutzern bietet sich zusätzlich Open WebUI an, das ein eigenes Nutzerverwaltungssystem mit Rollen mitbringt und so verhindert, dass jeder Zugriff auf jedes Modell und jeden Chatverlauf hat.

Zweitens lohnt sich ein Blick auf die Modellherkunft. Ollama lädt Modelle standardmäßig aus der offiziellen Modell-Bibliothek, wer aber eigene GGUF-Dateien aus unbekannten Quellen importiert, sollte diese vorher prüfen, ähnlich wie bei jeder anderen ausführbaren Software auch. Drittens gehört ein regelmäßiges Update-Fenster zum sicheren Betrieb dazu, da neue Ollama-Versionen neben Funktionen auch Sicherheitskorrekturen mitbringen. Wer den Dienst über Monate ohne Updates laufen lässt, verzichtet auf genau diese Korrekturen.

Häufig gestellte Fragen zu Ollama

Ist Ollama kostenlos?
Ja, Ollama selbst ist Open Source und kostenlos nutzbar. Kosten entstehen nur für die eigene Hardware und den Stromverbrauch, es gibt keine versteckten Abo- oder Nutzungsgebühren des Projekts selbst.

Welches Modell eignet sich für Einsteiger?
Ein kompaktes Modell wie Llama 3.2 oder Mistral 7B läuft auch auf durchschnittlicher Hardware flüssig und eignet sich gut, um sich mit den Grundbefehlen vertraut zu machen, bevor man zu größeren, ressourcenhungrigeren Modellen wechselt.

Kann Ollama ohne GPU laufen?
Ja, im CPU-Modus. Die Antwortgeschwindigkeit sinkt dabei deutlich, besonders bei Modellen ab 30 Milliarden Parametern, für kleinere Modelle bis etwa 8 Milliarden Parameter bleibt sie im Alltag aber meist noch akzeptabel.

Wie sicher ist die Ollama-API im Netzwerk?
Ohne zusätzliche Absicherung gar nicht. Die API bringt von Haus aus keine Authentifizierung mit, ein Reverse-Proxy mit Zugriffskontrolle ist für den Netzwerkbetrieb Pflicht, insbesondere sobald der Port über das lokale Gerät hinaus erreichbar sein soll.

Unterstützt Ollama deutsche Sprache gut?
Modelle wie Llama 3.3 und Mistral Large 3 liefern brauchbare deutsche Antworten, kommen aber bei komplexer Fachsprache oder juristischen Texten nicht immer an spezialisierte, größere Cloud-Modelle heran.

Was kostet der Betrieb im Vergleich zu einem Cloud-Abo?
Nach der Anschaffung der Hardware fallen nur Stromkosten an. Bei sehr hoher, dauerhafter Nutzung amortisiert sich eine leistungsfähige GPU oft schneller als laufende API-Gebühren, bei sporadischer Nutzung bleibt die Cloud-API meist günstiger.

Läuft Ollama auch auf einem Raspberry Pi?
Technisch ja, praktisch nur mit sehr kleinen Modellen und stark eingeschränkter Geschwindigkeit, da die ARM-CPU keine nennenswerte GPU-Beschleunigung bietet und der Arbeitsspeicher meist knapp bemessen ist.

Wie aktualisiere ich Ollama?
Unter Linux und macOS reicht ein erneuter Lauf des Installationsskripts beziehungsweise brew upgrade ollama. Windows-Nutzer laden die neue Version über die offizielle Webseite. Ein Update betrifft nur die Laufzeitumgebung, bereits heruntergeladene Modelle bleiben davon unberührt.

Weiterführende technische Dokumentation: die offizielle Ollama-Webseite, das Ollama-Repository auf GitHub, das llama.cpp-Projekt, die offizielle Modellübersicht von Mistral AI sowie das Open-WebUI-Repository für die grafische Oberfläche.