Ollama, LM Studio oder llama.cpp: Welches Werkzeug wofür?

Drei Werkzeuge dominieren den lokalen Betrieb von Sprachmodellen: Ollama, LM Studio und llama.cpp. Sie greifen im Kern auf dieselbe Inferenz-Technik zurück, unterscheiden sich aber deutlich in Bedienung, Automatisierbarkeit und Kontrolle über die Laufzeitparameter. Diese Anleitung zeigt dir, welches Werkzeug zu welchem Szenario passt und wie du jedes davon in Betrieb nimmst.

Was ist der Unterschied zwischen Ollama, LM Studio und llama.cpp?

Ollama, LM Studio und llama.cpp lösen dieselbe Aufgabe auf drei Abstraktionsebenen: llama.cpp ist die eigentliche Inferenz-Engine im GGUF-Format, Ollama eine Modell- und Serververwaltung darüber, LM Studio eine grafische Oberfläche für den Desktop.

LM Studio nutzt llama.cpp als Runtime und ergänzt auf Apple-Silicon zusätzlich MLX. Ollama baute lange ebenfalls direkt auf llama.cpp auf und bringt inzwischen eine eigene Engine für neuere Modellarchitekturen mit. Für dich bedeutet das: Qualität und Geschwindigkeit der Ausgabe sind bei gleichem Modell und gleicher Quantisierung sehr ähnlich. Der Unterschied liegt im Betriebsmodell.

Voraussetzungen

• Ein Linux-Host mit mindestens 16 GB RAM für Modelle der 7B- bis 8B-Klasse in 4-Bit-Quantisierung
• Optional eine NVIDIA-GPU mit installiertem Treiber und CUDA-Toolkit 12.x; eine GPU-Instanz für LLM-Inference nimmt dir die Treiberarbeit ab
• git, cmake ab 3.14 und ein C++-Compiler, falls du llama.cpp selbst baust
• Freier Speicherplatz: rechne mit 5 GB pro 8B-Modell in Q4_K_M

Die Beispiele laufen auf Ubuntu 24.04. Auf anderen Distributionen ändern sich nur die Paketnamen.

Welches Werkzeug passt zu deinem Setup?

Die Wahl hängt an drei Fragen: Läuft der Host headless, brauchst du eine stabile HTTP-API für andere Dienste, und musst du einzelne Laufzeit-Flags pro Start selbst setzen. Der folgende Entscheidungspfad bildet das ab.

graph TD
    A["Modell lokal betreiben"] --> B{"Host ohne Desktop?"}
    B -->|Nein| C["LM Studio: GUI, Modellsuche, schnelles Ausprobieren"]
    B -->|Ja| D{"Flags pro Start selbst setzen?"}
    D -->|Nein| E["Ollama: Dienst auf Port 11434, Modellverwaltung inklusive"]
    D -->|Ja| F["llama.cpp: eigener Build, volle Kontrolle über Kontext und Offloading"]
    C --> G["Für den Dauerbetrieb später auf Ollama oder llama.cpp umziehen"]

Ollama installieren und ein Modell laden

Ollama installierst du mit dem offiziellen Skript. Es richtet einen systemd-Dienst ein, erkennt vorhandene NVIDIA- oder AMD-GPUs und bindet die API standardmäßig an 127.0.0.1:11434.

$ curl -fsSL https://ollama.com/install.sh | sh
$ systemctl status ollama --no-pager
$ ollama pull llama3.1:8b
$ ollama run llama3.1:8b "Fasse den Unterschied zwischen RAM und VRAM in zwei Sätzen zusammen."

Seit Version 0.1.24 stellt Ollama zusätzlich eine OpenAI-kompatible Schnittstelle unter /v1 bereit. Bestehende Clients funktionieren damit ohne Anpassung des Codes:

$ curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.1:8b","messages":[{"role":"user","content":"Hallo"}]}'

Ollama im Netz erreichbar machen

Standardmäßig lauscht der Dienst nur auf localhost. Für den Zugriff aus deinem privaten Netz überschreibst du die Umgebungsvariable per systemd-Drop-in:

$ sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=2"

Danach sudo systemctl restart ollama ausführen. Die API kennt keine Authentifizierung. Stelle einen Reverse Proxy mit TLS und Basic Auth davor oder begrenze den Zugriff über die Firewall auf bekannte Quell-IPs.

LM Studio als Desktop-Werkzeug einsetzen

LM Studio ist eine Desktop-Anwendung für Windows, macOS und Linux (AppImage). Der Mehrwert liegt in der integrierten Hugging-Face-Suche: Du siehst vor dem Download, welche Quantisierung in deinen VRAM passt, und kannst Parameter wie Kontextlänge oder GPU-Layer per Regler testen.

Nach der Installation der Desktop-App steht die CLI lms bereit:

$ ~/.lmstudio/bin/lms bootstrap
$ lms ls
$ lms server start --port 1234
$ curl http://localhost:1234/v1/models

Das Modell wird beim ersten Request geladen, falls du --auto-load beziehungsweise das JIT-Loading aktiviert hast, sonst explizit mit lms load <modell>. Für reine Server ohne grafische Oberfläche ist LM Studio die schwächste Option: Die Ersteinrichtung setzt die GUI voraus, und die Anwendung ist proprietär. Für die Evaluationsphase, in der du fünf Modelle gegeneinander testest, ist sie dafür das schnellste Werkzeug.

llama.cpp aus dem Quellcode bauen

llama.cpp baust du seit Mitte 2024 ausschließlich über CMake; der alte make-Pfad ist entfallen. Der Schalter -DGGML_CUDA=ON aktiviert die CUDA-Unterstützung, -DGGML_VULKAN=ON die Vulkan-Variante für AMD- und Intel-GPUs.

$ sudo apt install -y build-essential cmake git libcurl4-openssl-dev
$ git clone https://github.com/ggml-org/llama.cpp
$ cd llama.cpp
$ cmake -B build -DGGML_CUDA=ON
$ cmake --build build --config Release -j $(nproc)

Die fertigen Binaries liegen unter build/bin/. Für den Serverbetrieb ist llama-server relevant:

$ ./build/bin/llama-server \
  -hf bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M \
  --n-gpu-layers 99 \
  --ctx-size 8192 \
  --host 0.0.0.0 --port 8080

Die wichtigsten Parameter:

• --n-gpu-layers: Anzahl der Layer, die in den VRAM ausgelagert werden. 99 bedeutet praktisch „alles, was passt".
• --ctx-size: Kontextfenster in Token. Der KV-Cache wächst linear mit diesem Wert und belegt VRAM.
• --parallel: Anzahl paralleler Slots. Das Kontextfenster teilt sich auf die Slots auf.
• --cache-type-k / --cache-type-v: Quantisierung des KV-Cache, etwa q8_0. Spart spürbar Speicher bei langen Kontexten.

Wann lohnt sich llama.cpp statt Ollama?

llama.cpp lohnt sich, sobald du Laufzeitparameter wie KV-Cache-Quantisierung, Batch-Größe oder die exakte Layer-Verteilung über mehrere GPUs pro Start kontrollieren musst, oder wenn du einen Build für eine bestimmte Hardware brauchst.

Ollama abstrahiert diese Details bewusst weg und trifft eigene Entscheidungen darüber, wie viele Layer auf die GPU wandern. Das ist im Normalbetrieb praktisch und im Grenzbereich hinderlich: Wenn ein 14B-Modell knapp nicht in 16 GB VRAM passt, kannst du mit llama.cpp über --cache-type-k q8_0 und eine reduzierte Kontextlänge nachjustieren, bis es passt. Wer mehrere Modell-Endpunkte parallel betreibt und deren Auslastung im Blick behalten will, kombiniert das sinnvoll mit einer skalierbaren Cloud-VM als Gateway vor den GPU-Knoten.

Umgekehrt gilt: Für einen einzelnen Inferenz-Endpunkt, der stabil laufen und Modelle nach Bedarf nachladen soll, ist Ollama der geringere Wartungsaufwand. Updates kommen über den Paketkanal, Modellwechsel über einen einzigen Befehl.

Verifikation

Prüfe zuerst, ob das Modell wirklich auf der GPU liegt. Die Spalte PROCESSOR in ollama ps zeigt die Verteilung an:

$ ollama ps
NAME            ID              SIZE      PROCESSOR    UNTIL
llama3.1:8b     42182419e950    6.7 GB    100% GPU     29 minutes from now

Bei llama.cpp antwortet der Health-Endpoint mit dem Ladezustand, nvidia-smi zeigt die tatsächliche VRAM-Belegung:

$ curl -s http://localhost:8080/health
{"status":"ok"}
$ nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv
memory.used [MiB], utilization.gpu [%]
6412 MiB, 87 %

Steht in ollama ps etwas wie 48%/52% CPU/GPU, läuft ein Teil der Layer im Hauptspeicher. Die Generierung ist dann um ein Vielfaches langsamer.

Troubleshooting

Das Modell fällt komplett auf die CPU zurück. Meist fehlt der Treiber oder der Container sieht die GPU nicht. Prüfe nvidia-smi auf dem Host und in Ollama zusätzlich journalctl -u ollama -n 50. Dort steht, welche Bibliothek geladen wurde. Passt das Modell schlicht nicht in den VRAM, wechsle auf eine kleinere Quantisierung wie Q4_K_S.

Die Ollama-API ist von außen nicht erreichbar. Ohne gesetztes OLLAMA_HOST bindet der Dienst nur an 127.0.0.1. Kontrolliere mit ss -tlnp | grep 11434, an welche Adresse gebunden wurde, und setze das Drop-in aus dem Abschnitt oben.

Der llama.cpp-Build ignoriert die GPU. Wurde -DGGML_CUDA=ON vergessen oder fehlt nvcc im PATH, entsteht ein reiner CPU-Build ohne Fehlermeldung. Lösche das Verzeichnis build/ vollständig, prüfe nvcc --version und konfiguriere neu. Ein bestehender CMake-Cache übernimmt geänderte Schalter nicht zuverlässig.

Fazit

Nimm LM Studio, um Modelle und Quantisierungen schnell zu vergleichen. Nimm Ollama für den unbeaufsichtigten Serverbetrieb mit stabiler API und einfacher Modellverwaltung. Nimm llama.cpp, wenn du Kontextlänge, KV-Cache und Layer-Verteilung selbst bestimmen musst. Die drei schließen sich nicht aus: Evaluieren in der GUI, produktiv ausrollen über einen Dienst ist ein gängiger und sinnvoller Weg.

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 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
• Was ist Ollama? Funktionsweise, Modelle und Einsatzgebiete