Wiki
Ollama vs. llama.cpp vs. LM Studio vs. vLLM
Vier Werkzeuge, eine Aufgabe: ein offenes Modell lokal betreiben
Hast du dich entschieden, ein offenes Modell auf eigener Hardware zu betreiben, musst du das Ding wählen, das es tatsächlich lädt und Anfragen beantwortet: die Runtime. Vier Namen tauchen ständig auf, und sie sind weniger Konkurrenten als verschiedene Ausprägungen derselben Aufgabe: der einfache Einstieg, die Engine, die GUI und der Produktionsserver. Hier ist, wofür jedes da ist und, nützlicher noch, worauf du pdf2okf richtest.
Der Vergleich auf einen Blick
| Werkzeug | Was es ist | Standard-Port | Am besten für |
|---|---|---|---|
| Ollama | Der einfachste Einstieg; ein Befehl lädt und stellt ein Modell bereit | :11434 | In Minuten laufen; einzelner Nutzer |
| llama.cpp | Die grundlegende C/C++-Inferenz-Engine (CPU + GPU + Metal); brachte GGUF hervor | :8080 | Kontrolle und minimaler Overhead; trägt weite Teile des Ökosystems |
| LM Studio | Eine Desktop-GUI mit Modell-Browser; liefert GGUF- und MLX-Runtime | :1234 | Wer eine grafische App will, kein Terminal |
| vLLM | Produktions-GPU-Serving (PagedAttention, Continuous Batching) | – | Viele Nutzer auf NVIDIA/AMD-GPUs (kein Laptop-Werkzeug) |
Was sie unterscheidet
Ollama ist der sanfte Start. Ein Befehl lädt ein Modell und stellt es auf :11434 bereit, und seit v0.19 hat es ein MLX-Backend für Apple Silicon. Willst du heute einfach ein lokales Modell, das dir antwortet, fang hier an.
llama.cpp ist die Engine unter weiten Teilen des Felds: ein schlanker C/C++-Inferenz-Kern, der über CPU, GPU und Apples Metal läuft, eine OpenAI-kompatible API auf :8080 bereitstellt und das GGUF-Format hervorgebracht hat, das fast alles andere lädt. Wähle es, wenn du maximale Kontrolle und minimalen Overhead willst oder direkt auf der Engine baust.
LM Studio ist die grafische Option: eine Desktop-App mit eingebautem Modell-Browser zum Finden und Herunterladen von Modellen, einer Chat-Oberfläche zur Nutzung und einem Server auf :1234. Sie liefert GGUF und MLX als Runtime, auf einem Mac kannst du also den schnelleren Apple-nativen Weg wählen, ohne die App zu verlassen. Gut für alle, die nicht im Terminal leben wollen.
vLLM ist bewusst der Ausreißer. Es ist für Produktions-GPU-Serving gebaut. PagedAttention und Continuous Batching halten eine Flotte von NVIDIA- oder AMD-GPUs ausgelastet, sodass du viele gleichzeitige Nutzer effizient bedienst. Es ist kein Laptop-Werkzeug. Bist du eine Person an einer Maschine, ist vLLM die falsche Antwort; stellst du einen geteilten Inferenz-Server für ein Team auf, die richtige.
Sie sprechen alle dieselbe API
Hier ist die stille Superkraft, die die Wahl entspannt: Alle vier stellen eine OpenAI-kompatible API bereit. Ollama auf :11434, llama.cpp auf :8080, LM Studio auf :1234, vLLM auf seinem Server-Endpunkt: darunter dieselbe Anfrageform. pdf2okf zeigt also auf jedes von ihnen auf genau dieselbe Weise. Du änderst eine Basis-URL, nicht dein Werkzeug. Tausch am Dienstag Ollama gegen LM Studio, und pdf2okf weiß es nicht und kümmert es nicht.
Einzelner Nutzer vs. Team-Server
Die Entscheidung kocht auf eine Frage herunter: Wen bedient das?
- Eine Person, eine Maschine: nimm Ollama für den schnellsten Start, LM Studio für eine GUI oder llama.cpp für die nackte Engine. Auf einem Mac ist die MLX-Runtime von LM Studio (oder oMLX) der schnelle Weg.
- Ein Team, ein geteilter Server: das ist vLLM auf einem GPU-Server, dimensioniert für gleichzeitige Last.
Eine Notiz zur Quantisierung
Welche Runtime du auch wählst, du fährst ein quantisiertes Modell: dieselben Gewichte, niedriger aufgelöst gespeichert, damit sie in deinen Speicher passen. GGUF ist der Standard-Quantisierungs-Container (aus llama.cpp; auch von Ollama und LM Studio geladen), und Q4_K_M ist der breit anerkannte Sweet Spot: rund 75% kleiner als volle Präzision bei etwa 3% Qualitätsverlust. Zum Dimensionieren gilt die Faustregel: ein 4-Bit-Modell braucht etwa die Hälfte seiner Parameterzahl in Gigabyte RAM, plus etwas für den KV-Cache des Kontextfensters. Ein 7B passt also in rund 4 bis 5 GB, ein Modell der 27B-Klasse in etwa 14 bis 16 GB.
Wo pdf2okf hineinpasst
pdf2okf ist von Grund auf modell- und runtime-agnostisch, und genau das macht diesen Vergleich entspannt. Es erzeugt ein OKF-kompatibles Bundle aus einfachen Markdown-Konzeptdateien, und die Struktur lebt im OKF-Bundle, nicht in der Runtime. Heute Ollama, vLLM wenn du auf ein Team skalierst, LM Studio auf dem Laptop, mit dem du reist: das Bundle ist identisch und deine Antworten bleiben darin verankert. Wähle die Runtime, die zu deinem Publikum passt, richte pdf2okf auf ihren OpenAI-kompatiblen Endpunkt und behalte deine Dokumente auf Hardware, die du kontrollierst. Den Apple-Silicon-Weg im Detail zeigt Lokale Dokumenten-KI auf dem Mac; das große Bild KI lokal betreiben 2026.