Lokale KI-Modelle betreiben: Ollama & llama.cpp

Warum ueberhaupt lokal?

Wenn du ein LLM lokal betreibst, laeuft das komplette Modell auf deiner eigenen Hardware statt in der Cloud eines Anbieters. Keine Anfrage verlaesst dein Netzwerk, es gibt keine laufenden Tokenkosten, und du bist nicht davon abhaengig, ob ein Cloud-Anbieter seine API-Preise oder Nutzungsbedingungen aendert. Der Preis dafuer: Du brauchst passende Hardware, musst Modelle selbst updaten und bekommst in der Regel nicht die Spitzenleistung der groessten Cloud-Modelle.

Fuer Firmen mit sensiblen Daten, fuer Entwickler, die offline arbeiten wollen, oder einfach aus Interesse an der Technik ist der lokale Weg trotzdem attraktiv. Zwei Werkzeuge dominieren dieses Feld: Ollama als komfortable Rundum-Loesung und llama.cpp als das schnelle, schlanke Fundament, auf dem Ollama technisch aufbaut.

Ollama: der schnelle Einstieg

Ollama installierst du unter Windows und macOS per Installer, unter Linux mit einem Einzeiler:

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

Danach laedst und startest du ein Modell mit einem einzigen Befehl. Ollama zieht das Modell beim ersten Aufruf automatisch aus seiner Bibliothek:

ollama run llama3.2
ollama run qwen2.5:7b
ollama run mistral

Der Doppelpunkt trennt Modellname und Variante (Groesse bzw. Quantisierungsstufe), zum Beispiel qwen2.5:14b oder llama3.2:1b. Ohne Suffix nimmt Ollama eine sinnvolle Standardgroesse.

Weitere wichtige Befehle im Alltag:

ollama list          # installierte Modelle anzeigen
ollama ps            # aktuell im Speicher geladene Modelle
ollama pull qwen2.5   # Modell laden ohne sofort zu starten
ollama rm mistral      # Modell wieder loeschen
ollama show llama3.2   # Details: Parameter, Kontextfenster, Lizenz

Modelfile: eigene Varianten bauen

Mit einem Modelfile passt du System-Prompt, Temperatur oder Kontextlaenge eines Modells an und speicherst das Ergebnis als eigene, wiederverwendbare Variante:

FROM llama3.2
PARAMETER temperature 0.3
PARAMETER num_ctx 8192
SYSTEM "Du antwortest immer auf Schweizer Hochdeutsch, kurz und technisch praezise."

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

Das ist besonders praktisch fuer wiederkehrende Aufgaben, etwa einen Code-Review-Assistenten mit fixem Stil oder ein Modell, das immer in einer bestimmten Rolle antwortet.

Die lokale API

Sobald Ollama laeuft, steht automatisch ein lokaler HTTP-Server unter http://localhost:11434 bereit. Damit kannst du Modelle aus eigenem Code ansprechen, ganz ohne Cloud-Anbieter:

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.2",
  "messages": [{ "role": "user", "content": "Erklaer mir Quantisierung in zwei Saetzen." }],
  "stream": false
}'

In Python sieht ein einfacher Aufruf so aus:

import requests

response = requests.post("http://localhost:11434/api/chat", json={
    "model": "qwen2.5:7b",
    "messages": [{"role": "user", "content": "Fasse den Text zusammen."}],
    "stream": False
})
print(response.json()["message"]["content"])

Ollama bietet zusaetzlich eine OpenAI-kompatible Schnittstelle unter /v1/chat/completions (Stand: 2026-07). Damit funktionieren viele bestehende Tools und SDKs, die eigentlich fuer OpenAI-APIs gebaut wurden, mit minimaler Anpassung: Du aenderst nur die Basis-URL und den API-Key (ein beliebiger Platzhalter-String genuegt lokal).

llama.cpp: die Engine direkt nutzen

llama.cpp ist ein in C/C++ geschriebenes Inferenz-Programm, das gezielt auf Effizienz getrimmt ist: minimale Abhaengigkeiten, breite Hardware-Unterstuetzung (CPU, NVIDIA CUDA, Apple Metal, AMD ROCm/HIP, Vulkan, SYCL) und sehr gute Performance auch auf bescheidener Hardware. Wer direkt mit llama.cpp arbeitet, kompiliert das Projekt selbst oder laedt fertige Binaries und startet dann zum Beispiel den mitgelieferten Server:

llama-server -m ./qwen2.5-7b-instruct-q4_k_m.gguf --port 8080 -c 8192

Der Server stellt ebenfalls eine REST- und eine OpenAI-kompatible API bereit, dazu ein einfaches Web-Chat-Interface im Browser. Fuer schnelle Tests ohne Server gibt es llama-cli:

llama-cli -m ./modell.gguf -p "Schreib eine kurze Produktbeschreibung fuer einen Wasserkocher." -n 200

Der direkte Weg ueber llama.cpp lohnt sich, wenn du: die neuesten Modellarchitekturen sofort nutzen willst (Unterstuetzung landet dort oft zuerst), exotische Hardware ansteuerst, oder Build-Flags und Laufzeitparameter (Threads, Batch-Groesse, GPU-Layer-Offloading) feinjustieren willst, die Ollama standardmaessig verbirgt.

Modelle laden: Llama, Mistral, Qwen und Co.

Die grossen offenen Modellfamilien, die sich lokal betreiben lassen, aendern sich staendig (Stand: 2026-07), das Grundmuster aber nicht:

Die konkreten Modellnamen und Versionsnummern sind hier bewusst als Momentaufnahme zu verstehen: Neue Generationen erscheinen alle paar Monate. Das Prinzip “kleine, spezialisierte Modelle werden staendig besser” bleibt aber stabil.

Modelle findest du fertig quantisiert vor allem auf Ollamas Modellbibliothek und auf Hugging Face, oft in GGUF-Format direkt von der jeweiligen Community bereitgestellt (zum Beispiel unter dem Nutzernamen “bartowski” oder direkt von den Modell-Herstellern).

Quantisierung: kleiner Speicher, kleinerer Qualitaetsverlust

Ein Modell besteht aus Milliarden Gewichten (Parametern). Im Originalformat werden diese meist mit 16 Bit pro Zahl gespeichert (FP16/BF16). Quantisierung reduziert die Genauigkeit dieser Zahlen auf weniger Bits, etwa 8, 5 oder 4 Bit, wodurch Modellgroesse und Speicherbedarf drastisch sinken, bei nur moderatem Qualitaetsverlust.

Das gaengige Format dafuer ist GGUF, das Standarddateiformat von llama.cpp und damit auch von Ollama. Typische Quantisierungsstufen:

Q4_K_M hat sich (Stand: 2026-07) als praktischer Standard etabliert: deutlich kleiner als das Original, aber fuer die meisten Alltagsaufgaben kaum spuerbar schlechter. Fuer Aufgaben, bei denen Praezision zaehlt (Code, Mathematik, komplexes Reasoning), lohnt sich ein Blick auf Q5_K_M oder Q6_K, wenn die Hardware das hergibt.

Hardware: was du wirklich brauchst

Die zentrale Fausregel: Ein Modell muss (fast) komplett in den Arbeitsspeicher der Recheneinheit passen, die es ausfuehrt. Bei GPU-Beschleunigung ist das der VRAM der Grafikkarte, bei reiner CPU-Ausfuehrung der System-RAM.

Als grobe Orientierung fuer den Speicherbedarf bei Q4_K_M-Quantisierung: etwa 0,6 bis 0,7 GB pro Milliarde Parameter, zuzueglich etwas Puffer fuer den Kontext (KV-Cache). Bei FP16 ohne Quantisierung sind es etwa 2 GB pro Milliarde Parameter.

Wichtig: Diese Werte sind Naeherungen, kein Kontextfenster ist eingerechnet, und ein laengerer Kontext braucht zusaetzlichen Speicher fuer den KV-Cache. Wer ohne dedizierte GPU startet, kann trotzdem: kleine Modelle (bis etwa 8B) laufen auf aktuellen CPUs mit ausreichend RAM brauchbar schnell, besonders auf Apple-Silicon-Macs, deren Unified Memory GPU und CPU teilen und dadurch grosszuegiger dimensioniert ist als klassischer PC-VRAM.

Entscheidungshilfe: Ollama oder llama.cpp direkt?

Willst du in Minuten loslegen und musst nicht jeden Parameter tunen?
├── Ja  → Ollama
└── Nein
    ├── Brauchst du die neueste Modellarchitektur sofort nach Release?
    │   └── Ja → llama.cpp direkt
    └── Willst du exotische Hardware (Vulkan, spezielle SYCL/ROCm-Setups) exakt einstellen?
        └── Ja → llama.cpp direkt, sonst reicht Ollama

Fuer die allermeisten Anwendungsfaelle, gerade im KMU-Umfeld oder fuer persoenliche Projekte, ist Ollama der richtige Startpunkt. llama.cpp direkt lohnt sich, sobald du an die Grenzen der Ollama-Abstraktion stoesst.

Grenzen gegenueber Cloud-Modellen

Lokale Modelle sind kein Ersatz fuer Spitzenmodelle grosser Cloud-Anbieter, sie sind eine andere Werkzeugkategorie mit eigenen Staerken:

• Rohleistung: Die groessten Cloud-Modelle sind (Stand: 2026-07) bei komplexem Reasoning, sehr langen Kontexten und schwierigen Programmieraufgaben in der Regel weiterhin voraus. Der Abstand schrumpft, verschwindet aber nicht.
• Geschwindigkeit ohne High-End-GPU: Ohne starke GPU sind lokale Antworten oft spuerbar langsamer als eine Cloud-API.
• Multimodalitaet: Bild-, Audio- und Video-Verstehen ist lokal moeglich (etwa mit Vision-Modellen), aber die Auswahl und Qualitaet ist kleiner als im Cloud-Angebot.
• Wartung: Du bist selbst fuer Updates, Sicherheitsluecken in der Laufzeitumgebung und Modellwechsel verantwortlich.
• Daten bleiben lokal: Das ist der grosse Pluspunkt, gerade wenn Datenschutz oder Betriebsgeheimnisse eine Rolle spielen.

Fuer viele Aufgaben, insbesondere alles mit sensiblen Daten, klar definiertem Umfang oder hohem Anfragevolumen ohne Cloud-Kosten, sind lokale Modelle heute eine ernstzunehmende, produktionstaugliche Option. Fuer die absolute Spitzenleistung bei den komplexesten Aufgaben bleibt die Cloud vorerst meist die bessere Wahl.

Weiterlernen

• Ollama-Dokumentation - Offizielle Docs zu API, Modelfile und Konfiguration
• Ollama Modellbibliothek - Uebersicht aller verfuegbaren Modelle und Groessen
• llama.cpp auf GitHub - Quellcode, Build-Anleitung und Backend-Dokumentation
• Hugging Face GGUF-Modelle - Grosse Auswahl fertig quantisierter Modelle
• GGUF-Format-Spezifikation - Technischer Aufbau des Dateiformats