OLLAMA · TECH
Ollama: lokale LLMs auf eigener Hardware – wo es funktioniert und wo nicht
Ollama ist ein lokaler Runtime für Open-Source-LLMs. Stark für Privacy-Demos und CPU-Klassifikation, langsam für 70B-Modelle ohne GPU.
Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05
Was ist Ollama?
Ollama ist ein Open-Source-Runtime (MIT-Lizenz), das Open-Weight-Sprachmodelle auf einem einzelnen Rechner ausführt – Linux, macOS und Windows. Gestartet 2023 als CLI-Wrapper rund um llama.cpp, hat sich Ollama bis Mai 2026 zu einem ausgereiften Tool entwickelt mit eigener Modell-Registry, REST-API auf Port 11434 und Bibliothek von über 200 Quantisierungs-Varianten.
Die Funktion ist einfach: ollama pull llama3.2 zieht ein Modell in einer kompakten GGUF-Quantisierung herunter, ollama run llama3.2 startet eine Chat-Session. Im produktiven Modus läuft ollama serve als Hintergrund-Daemon, andere Programme reden über die OpenAI-kompatible HTTP-Schnittstelle. Aktuelle Modell-Familien Stand Mai 2026: Llama 3.1 und 3.2, Gemma 2 (Google), Mistral und Mixtral, DeepSeek-r1 (Reasoning), Qwen 2.5 (Alibaba), Phi 4 (Microsoft), sowie spezialisierte Embedding-Modelle wie nomic-embed-text.
Version 0.5+ ist aktuell, mit aktiver Weiterentwicklung. Ollama nutzt GPU-Beschleunigung wenn vorhanden (NVIDIA via CUDA, Apple Silicon via Metal, AMD via ROCm), fällt sonst sauber auf CPU zurück. Quantisierung ist der Hebel: ein Llama-3.1-8B-Modell in Q4_K_M-Quantisierung passt in 5 GB RAM und läuft auf einem normalen Server mit etwa 15-30 Tokens pro Sekunde. Das gleiche Modell in 70B-Variante braucht 40 GB RAM und liefert ohne GPU nur 1-3 Tokens pro Sekunde – gerade noch nutzbar für Batch-Jobs, nicht für Chat.
Auf unserem Hetzner-Server (125 GB RAM, kein GPU) laufen 9 lokale Modelle: llama3.2 in 3B und 8B, gemma2:9b, mistral:7b, deepseek-r1:7b, qwen2.5:7b, phi4, plus nomic-embed-text für lokale Embeddings. Verwendung: Privacy-Demos und CPU-taugliche Klassifikations-Aufgaben.
Warum es wichtig ist
Lokal laufende LLMs lösen ein konkretes Problem: Berufsgeheimnis. Eine Anwaltskanzlei darf Mandanten-Schriftverkehr nicht durch US-Cloud-Endpoints schicken, eine Notar-Praxis ebenfalls nicht, ein Arzt unter Art. 321 StGB ohnehin nicht. Cloud-LLMs in EU-Region (Mistral La Plateforme, Azure OpenAI mit EU-Datenresidenz) lösen das für viele Fälle – aber nicht alle. Wo absolute Datentrennung gefordert ist, ist Ollama eine Option.
Der zweite Anwendungsfall sind hohe Batch-Volumen mit niedrigen Antwortzeit-Anforderungen. Wer pro Tag 10.000 E-Mails klassifizieren will (Spam, Mandanten-Anfrage, Lieferanten-Mahnung), bezahlt bei einem Cloud-Provider zwischen CHF 50 und CHF 300 pro Tag. Mit Ollama auf einem dedizierten Server läuft das für den Strompreis, sobald die Hardware steht. Die Antwortzeit liegt bei 1-3 Sekunden pro Mail statt 300 ms – für Batch-Verarbeitung kein Problem.
Der dritte Hebel sind Embeddings. nomic-embed-text und bge-large laufen auf CPU mit guter Geschwindigkeit (50-100 Texte pro Sekunde). Eine RAG-Pipeline kann die Embedding-Erzeugung damit komplett lokal halten – keine externen Provider-Aufrufe für den häufigsten Schritt der Pipeline. Das spart Geld und vereinfacht die Compliance-Geschichte.
Der Realismus-Check ist allerdings wichtig: lokale 70B-Modelle ohne GPU sind langsam. Wer auf der gleichen Qualität wie GPT-4o oder Claude Sonnet besteht, braucht GPU-Hardware (zwei A100 für 70B in voller Präzision sind nicht billig) oder eine kleinere Aufgabe. Die ehrliche Empfehlung: Ollama für Klassifikation, Extraktion, Embeddings und sensible Demos – für komplexe Generierung Cloud-LLMs unter Routing-Kontrolle.
Wie es funktioniert
Ollama besteht aus zwei Teilen: dem Daemon (ollama serve) und der CLI (ollama). Der Daemon hält Modelle im Arbeitsspeicher, akzeptiert HTTP-Requests und ruft im Hintergrund die llama.cpp-Inferenz-Engine auf. Die CLI ist ein dünner Client für den Daemon.
Modell-Management: ollama pull <model> lädt ein Modell aus der Ollama-Registry herunter. Die Modell-Datei ist in GGUF (GPT-Generated Unified Format) gepackt, eine für llama.cpp optimierte Quantisierung. Pro Modell gibt es typisch mehrere Tags: latest, q4_K_M, q5_K_S, q8_0 – die Zahl gibt die Bit-Tiefe der Gewichte an. Q4_K_M ist der Sweet Spot für 7B-13B-Modelle (kleinere Datei, kaum Qualitätsverlust); Q8_0 ist näher an Vollpräzision, braucht aber doppelt so viel RAM.
API: POST /api/generate für einfache Vervollständigung, POST /api/chat für Chat-mit-Verlauf, POST /api/embeddings für Embedding-Erzeugung. Eine OpenAI-kompatible Schicht läuft unter /v1/chat/completions, sodass jedes OpenAI-SDK funktioniert – base_url=http://ollama:11434/v1 und ein dummy-Key reichen.
Deployment: in unserer Konfiguration läuft Ollama in einem Docker-Container, mit dem Modell-Verzeichnis als Volume gemountet. Hinter LiteLLM-Proxy: Ollama-Modelle sind im Gateway als logische Modellnamen (z.B. local-llama, local-mistral) angemeldet. Anwendungen müssen Ollama nicht direkt kennen – sie sprechen mit LiteLLM, das routet auf Ollama.
Memory-Management: Ollama hält das zuletzt benutzte Modell im RAM (default 5 Minuten) und entlädt es danach. Wer Modelle dauerhaft hot halten will, setzt OLLAMA_KEEP_ALIVE=24h oder ruft sie regelmässig mit einem Health-Check auf. Mehrere Modelle parallel halten erfordert entsprechend RAM – neun Modelle auf einem 125-GB-Server sind kein Problem, solange nicht alle gleichzeitig geladen sind.
Ollama produktiv in 6 Schritten
- 01Hardware-Sizing: mindestens 16 GB RAM für 7B-Modelle, 32 GB für 13B, 64 GB für 30B, GPU für 70B-Echtzeit-Chat.
- 02Ollama via Docker installieren, Modell-Verzeichnis als Volume mounten, OLLAMA_KEEP_ALIVE und Concurrency konfigurieren.
- 03Modelle ziehen und Quantisierung wählen: Q4_K_M für 7B/13B Sweet-Spot, Q8_0 wenn Präzision wichtig und RAM da ist.
- 04Behind LiteLLM einbinden: Ollama-Endpoint als Provider in der Gateway-config.yaml, mit logischen Namen wie local-llama-8b.
- 05Use-Case-Tests fahren: Klassifikation, Extraktion, Embeddings mit echten Mandanten-Daten (oder echten Synthetic-Daten) messen.
- 06Monitoring: Prometheus-Scraper auf Ollama-Metriken (Modell-Ladezeit, Tokens/Sekunde), Grafana-Dashboard mit Qualitäts-KPIs aus dem LiteLLM-Audit-Log.
Wann Ollama einsetzen
Ollama ist die richtige Wahl, wenn (a) absolute Datentrennung Bedingung ist (Berufsgeheimnis, Mandantendaten ohne Drittland-Bezug), (b) hohe Volumen mit niedrigen Antwortzeit-Anforderungen anfallen oder (c) Embeddings lokal erzeugt werden sollen.
Konkrete Fälle: Anwaltskanzlei mit Mandanten-Schriftverkehr-Klassifikation (Eingangs-Triage), Treuhand-Büro mit lokaler MWST-Beleg-Vorklassifikation, Notar-Praxis mit lokalem Embedding für Dokument-Suche. Auch für reproduzierbare Demos und Schulungs-Umgebungen ist Ollama gut: das Modell läuft nachvollziehbar, keine Provider-Kosten während des Lernens.
Für Pilotprojekte mit unklarem Budget ist Ollama eine ehrliche Variante: zuerst auf eigenem Server mit Llama-3.1-8B und Q4-Quantisierung testen, ob die Qualität reicht. Wenn ja, dauerhaft lokal halten. Wenn nicht, mit klaren Daten zur Cloud wechseln – die Architektur über LiteLLM erlaubt den Wechsel ohne Code-Änderung.
Wann NICHT
Wer komplexe Generierung oder Reasoning auf der Qualitätsstufe GPT-4o / Claude Sonnet / Mistral Large braucht und keine GPU-Hardware hat, bleibt bei Cloud-Modellen. Ein lokales 70B-Modell auf CPU ist zwar möglich, aber mit 1-3 Tokens pro Sekunde für Chat unbrauchbar.
Ungeeignet ist Ollama auch für Anwendungen mit sehr niedriger und garantierter Antwortzeit – Voice-Bots, Echtzeit-Live-Translation, interaktive Chat-UI mit Streaming. Hier sind Cloud-Provider mit speziellen Schnellinferenz-Modellen (Groq, Cerebras) oder eine GPU-Instanz ehrlicher.
Für reine Pilotprojekte ohne Datenschutz-Bedarf ist Ollama Mehraufwand. Wer ein Wochenende lang einen Chat-Bot baut und einfach loslegen will, ist mit einem Cloud-Modell schneller dran. Ollama kommt ins Spiel, wenn Datentrennung oder Kostenoptimierung verlangt sind.
Vor- und Nachteile
STÄRKEN
- Volle Datentrennung – Modell und Daten verlassen die eigene Hardware nicht
- Keine variable Provider-Kosten, nur Hardware- und Strom-Aufwand
- OpenAI-kompatible API – bestehende Anwendungen können ohne Änderung wechseln
- GGUF-Quantisierung erlaubt grosse Modelle auf bescheidener Hardware
SCHWÄCHEN
- 70B-Modelle ohne GPU sind für Chat zu langsam (1-3 Tokens/Sek)
- Qualität hinter Top-Cloud-Modellen (GPT-4o, Claude Sonnet, Mistral Large) bei komplexer Generierung
- Modell-Updates und Quantisierungs-Wahl sind eigene Disziplin – nicht null Wartung
- Speichern und Mounten grosser Modell-Dateien (5-40 GB) verlangt Hardware-Planung
Häufige Fragen
Wie schnell ist ein 7B-Modell auf CPU?
Auf einem modernen AMD-EPYC- oder Intel-Xeon-Server mit DDR4-3200 RAM und Llama-3.1-8B in Q4_K_M-Quantisierung liefert Ollama 15-30 Tokens pro Sekunde. Eine durchschnittliche Antwort von 200 Tokens dauert also 7-13 Sekunden. Für interaktiven Chat zu langsam, für Klassifikation in Hintergrund-Jobs gut. Auf Apple Silicon (M2/M3) ist es deutlich schneller (50-80 Tokens/Sek) dank Metal-Beschleunigung.
Kann ich Ollama in einem RAG-Stack mit Qdrant nutzen?
Ja, das ist eine der häufigsten Anwendungen. Embedding-Modell (z.B. nomic-embed-text oder bge-large) läuft in Ollama, Vektoren landen in Qdrant, Suche und Reranking lokal, finale Antwort vom Sprachmodell – entweder ebenfalls lokal (Llama 3.1 8B für einfache Fälle) oder via LiteLLM-Routing in einer EU-Cloud (Mistral Large für komplexere Fälle). So bleibt die gesamte Pipeline unter Kontrolle.
Brauche ich eine NVIDIA-GPU?
Nein, für Modelle bis 13B reicht CPU mit ausreichend RAM. Eine GPU lohnt sich erst ab 30B-Modellen oder wenn Antwortzeit kritisch ist. Wenn GPU, dann für Ollama eine NVIDIA-Karte mit möglichst viel VRAM (24 GB für 30B-Quantisiert, 48 GB für 70B-Quantisiert). AMD GPUs gehen via ROCm, sind aber weniger ausgereift. Für die meisten CH-KMU-Setups ist eine GPU-freie Konfiguration der erste Schritt.
Verwandte Themen
Quellen
PASSEND ZU IHREM STACK?