Ollama, LM Studio, vLLM: Lokal-Runner im Team-Vergleich

Die Frage «welchen Lokal-Runner nehmen wir» wird in vielen DACH-Teams falsch gestellt. Sie klingt nach einer Produktentscheidung, ist aber eine Architekturentscheidung. Ollama, LM Studio und vLLM lösen drei verschiedene Probleme, und die häufigste Fehlentscheidung entsteht, wenn ein Team ein Einzelplatz-Werkzeug in eine Server-Rolle presst oder umgekehrt eine Server-Runtime auf einen Entwickler-Laptop zwingt. Dieser Artikel ordnet die drei entlang der einzigen Dimension, die praktisch entscheidet: wie viele Menschen gleichzeitig auf das Modell zugreifen.

Stand: 28. Juli 2026. Die tragenden Durchsatz-Messungen stammen aus dem August 2025. Die Versionslage der drei Projekte ändert sich schnell, die hier beschriebene Rollenverteilung ist dagegen strukturell stabil.

Was unterscheidet Ollama, LM Studio und vLLM überhaupt?

Alle drei führen grosse Sprachmodelle lokal auf eigener Hardware aus, ohne dass Daten an eine Cloud-API gehen. Damit hört die Gemeinsamkeit auf. Ollama ist ein Developer-first-Einzelplatz-Runner, der Modellverwaltung, Inferenz und einen HTTP-Server in einer einzigen Binary bündelt und über eine CLI bedient wird. LM Studio ist eine Desktop-GUI mit integriertem Modell-Browser, gedacht für Menschen, die keine Kommandozeile anfassen wollen. vLLM ist eine Server-Runtime, die auf hohen Durchsatz bei vielen parallelen Anfragen optimiert ist und in produktiven API-Stacks läuft.

Der entscheidende Punkt: Ollama und LM Studio nutzen unter der Haube für viele Modelle denselben Inferenzkern (llama.cpp). Bei einem einzelnen Nutzer liefern sie deshalb ähnliche Token-Durchsätze. Der Unterschied zwischen den beiden ist nicht Geschwindigkeit, sondern Bedienung: CLI plus API gegen grafische Oberfläche. vLLM dagegen ist architektonisch anders gebaut und spielt seine Stärke erst aus, wenn mehrere Anfragen gleichzeitig eintreffen.

Ollama: ein Binary für alles

Ollama installiert sich mit einem Befehl, lädt ein Modell mit ollama pull <modell> und startet Chat oder API mit ollama run <modell>. Der integrierte Server hört standardmässig auf Port 11434 und spricht eine OpenAI-kompatible API. Für ein Team heisst das konkret: kein separater Serving-Layer, keine Datenbank, keine Extra-Konfiguration. Wer eine RAG-Pipeline oder ein internes Automatisierungs-Skript an ein lokales Modell hängen will, tauscht in der Praxis nur die API-Basis-URL aus und ist verbunden.

LM Studio: GUI plus optionaler Server

LM Studio läuft als Desktop-Anwendung mit einer ChatGPT-ähnlichen Oberfläche und lädt Modelle direkt über einen integrierten Hugging-Face-Browser, inklusive der Quantisierungs-Varianten. Zusätzlich kann es einen lokalen Server-Modus starten, der eine OpenAI-kompatible API auf http://localhost:1234/v1 bereitstellt. Der Preis der Bequemlichkeit ist Speicher: Laut Contabo belegt LM Studio im Leerlauf rund 300 bis 600 MB allein für die GUI, gegenüber 100 bis 200 MB bei Ollama. Auf einem Arbeitsplatz spielt das keine Rolle, auf einem geteilten Server schon.

vLLM: High-Throughput-Serving

vLLM ist für produktives Serving mit hoher Parallelität gebaut. Die architektonischen Unterschiede zu den beiden anderen sind echtes Batching mehrerer Anfragen, intelligentes KV-Cache-Routing und Cluster-Fähigkeit. Vereinfacht gesagt verarbeitet vLLM mehrere Anfragen gemeinsam auf der GPU, statt sie nacheinander abzuarbeiten. Das ist der Grund, warum es bei Last so viel effizienter ist, und zugleich der Grund, warum es für einen einzelnen Nutzer keinen Vorteil bringt: Ein Batch aus einer einzigen Anfrage ist kein Batch.

Wie gross ist der Leistungsunterschied bei echter Last wirklich?

Der wichtigste Datenpunkt für die Entscheidung stammt aus einem Benchmark von Red Hat vom 8. August 2025, gemessen mit GuideLLM auf einer einzelnen NVIDIA A100-PCIE-40GB mit Llama 3.1 8B Instruct. Bei hoher Parallelität lieferte vLLM einen deutlich höheren Durchsatz als Ollama, mit Beispielwerten von 793 Token pro Sekunde bei vLLM gegenüber 41 Token pro Sekunde bei Ollama unter Peak-Last. Bei Einzelanfragen dagegen lagen beide nah beieinander, im Bereich von rund 130 bis 180 Token pro Sekunde. Diese beiden Zahlen zusammen sind die ganze Geschichte.

Was bedeutet das übersetzt in Betriebsrealität? Solange jeweils nur eine Person eine Anfrage stellt, ist Ollama praktisch gleich schnell wie vLLM und deutlich einfacher zu betreiben. Sobald aber ein Dutzend oder mehr Nutzer gleichzeitig Anfragen schicken, bricht der Durchsatz eines Einzelplatz-Runners ein, weil er die Requests seriell abarbeitet, während vLLM sie parallel batcht. Der Faktor 19 aus den Peak-Werten folgt direkt aus der unterschiedlichen Architektur. Einordnen muss man ihn trotzdem: Red Hat vertreibt mit dem eigenen AI Inference Server ein Produkt auf vLLM-Basis und bezeichnet sich als führenden kommerziellen Beitragenden des Projekts, ist bei diesem Vergleich also nicht neutral. Pexon Consulting verweist zusätzlich auf eine arXiv-Studie von 2025, die für vLLM bis zu 24-fachen Durchsatz gegenüber Text Generation Inference dokumentiert, also gegenüber einer anderen Server-Runtime und nicht gegenüber Ollama.

Die praktische Konsequenz ist eine klare Schwelle. Pexon beziffert die sinnvolle Ollama-Obergrenze auf rund 20 Nutzer, dokumentiert den Durchsatz-Einbruch aber schon ab mehr als fünf gleichzeitig chattenden Nutzern: dort bleiben etwa 15 Token pro Nutzer und Sekunde übrig, gegenüber rund 80 bei vLLM. Plane die Schwelle also konservativ. Darunter gewinnst du mit vLLM nichts ausser Setup-Aufwand. Darüber verlierst du mit Ollama Latenz-Stabilität und Durchsatz.

Welcher Runner passt zu welchem Team?

Die Zuordnung folgt zwei Achsen: Nutzerzahl und technisches Profil der Nutzer. Ein Fachbereich ohne CLI-Kompetenz braucht etwas anderes als ein Entwicklerteam, selbst bei gleicher Personenzahl.

Einzelplatz: Ollama oder LM Studio

Am Einzelplatz entscheidet allein, ob der Nutzer eine Kommandozeile akzeptiert. Für Entwickler und technische Nutzer ist Ollama die richtige Wahl, weil CLI und API die Einbettung in Skripte, RAG-Prototypen und Automatisierungen ohne Umweg erlauben. Für Fachbereiche, Enablement und Nicht-Techniker ist LM Studio richtig, weil die GUI und der integrierte Modell-Browser den Einstieg ohne jede technische Vorkenntnis ermöglichen. IT-Dock empfiehlt LM Studio explizit für Enablement und schnelle Tests in Marketing und RevOps.

Kleiner Team-Server bis rund 20 Nutzer: Ollama plus WebUI

Für ein internes LLM-Gateway mit moderater Last ist ein Ollama-Server das pragmatische Muster. IT-Dock beschreibt für den Team-Rollout die Kombination aus Ollama plus Open WebUI plus Governance-Schicht: Ollama liefert Modell und API, Open WebUI stellt das Browser-Frontend, und Zugriffskontrolle sowie Protokollierung laufen über Netzwerk-Policies. Das ist in Stunden aufgesetzt statt in Tagen und trägt bis zur genannten Nutzerschwelle.

Produktive API mit hoher Last: vLLM

Sobald mehrere Dutzend bis Hunderte parallele Nutzer oder Requests im Spiel sind, führt kein Weg an vLLM vorbei. Red Hat bezeichnet es als geeignet für Enterprise-Grade-Anwendungen mit hoher Parallelität, Biteno und Pexon sehen es als Standardoption, sobald ein Team von der Spielwiese in die Produktion wechselt. Der typische Aufbau: vLLM als Serving-Engine hinter einer skalierenden API-Schicht mit Load Balancer, Authentifizierung und Monitoring. Ein LLM-Coding-Assistent für dreihundert Entwickler ist der Lehrbuchfall.

Fachbereich ohne Server-Know-how

Es gibt einen vierten Fall, der oft übersehen wird: ein Fachbereich braucht lokale Modelle, hat aber niemanden für Serveradministration. Die richtige Antwort ist dann kein zentraler Server, sondern mehrere LM-Studio-Einzelplätze, je einer pro Person. Das umgeht die gesamte Betriebskomplexität und bleibt trotzdem datenschutzkonform lokal, weil jede Instanz auf der eigenen Maschine läuft.

Szenario	Empfehlung	Begründung
Einzelentwickler, Tests und Prototypen	Ollama	CLI plus OpenAI-API, schnelle Installation, gute Integration in RAG und Automationen
Fachbereich, Enablement, Workshops	LM Studio	GUI-first, Chat-Interface, Modell-Browser, offline nutzbar
Interne Tools bis rund 20 Nutzer	Ollama plus Open WebUI	Moderate Last, einfacher Betrieb, API-Kompatibilität
Produktive API, viele parallele Nutzer	vLLM	Echtes Batching, KV-Cache-Routing, stabile Latenz unter Last
Fachbereich ohne Server-Know-how	Mehrere LM-Studio-Einzelplätze	Minimale Einstiegshürde, keine Serveradministration

Wie unterscheiden sich Modell-Katalog und Update-Verhalten?

Beim Modellzugang verfolgen die drei unterschiedliche Philosophien, die direkte Folgen für den Betrieb haben. Ollama reduziert Komplexität durch vordefinierte Modellpakete und das Modelfile-Konzept: Du lädst ein Modell über ollama pull und erhältst eine passende Quantisierung ohne eigene Auswahlentscheidung. Contabo nennt für Ollama und LM Studio die üblichen Kandidaten Mistral, Qwen und DeepSeek als unterstützt; vLLM behandelt diese Quelle nicht.

LM Studio geht den entgegengesetzten Weg und öffnet über den integrierten Hugging-Face-Browser den Zugang zu einer grossen Zahl von Community-Modellen. Der Preis: Die Auswahl von Architektur und Quantisierung liegt beim Nutzer. Für einen Workshop ist das ein Vorteil, weil man Modelle anschaulich durchprobieren kann, für den unbedarften Dauerbetrieb eine Fehlerquelle. vLLM ist am flexibelsten und am anspruchsvollsten zugleich: Es ist modell-agnostisch und lädt aus Hugging-Face-Repos oder lokalen Pfaden, verlangt aber explizite Konfiguration von Pfad, Tokenizer und Serving-Parametern.

Ollama und vLLM sind Open Source, LM Studio ist eine kostenlose, aber closed-source Anwendung von Element Labs, deren Lizenz die Weitergabe, das Reverse Engineering und den Betrieb als Dienst für Dritte untersagt. Alle drei folgen derselben Update-Logik: Neue Modelle und GPU-Optimierungen kommen laufend über neue Releases oder Container-Images. Für produktive Teams heisst das konkret, ein Staging-Umfeld für Rollouts vorzusehen, besonders bei vLLM-Updates. Ein Modell- oder Runtime-Update, das den Durchsatz verändert oder die API subtil bricht, gehört nicht ungetestet auf einen Produktions-Server mit dreihundert angebundenen Nutzern.

Wo liegen die Grenzen der einzelnen Werkzeuge?

Jedes der drei Tools hat einen Bereich, in dem es schlicht das falsche Werkzeug ist. Diese Grenzen zu kennen ist wichtiger als die Featurelisten.

• Ollama skaliert nicht in die Höhe: Es kennt kein hochoptimiertes Batching für viele parallele Requests. Über der 20-Nutzer-Schwelle leiden Durchsatz und Latenz messbar, wie der Red-Hat-Vergleich zeigt.
• LM Studio ist kein Produktions-Server: Der lokale Server-Modus existiert, ist aber ein Nebenprodukt der Desktop-App und nicht für High-Concurrency ausgelegt. Der höhere Leerlauf-RAM und die schwächere DevOps-Integration bestätigen den Desktop-Fokus.
• vLLM ist am Einzelplatz überdimensioniert: Es ist kein Alles-in-einer-Binary, sondern verlangt eine eigene Python-Umgebung, Modell-Konfiguration und einen API-Layer. Ohne echte Parallellast zahlt sich dieser Setup-Overhead nicht aus, und eine Chat-GUI bringt es von Haus aus nicht mit.

Die häufigsten Fehlgriffe folgen direkt aus diesen Grenzen: ein Team stülpt vLLM über einen Prototyp und verbringt zwei Tage mit Serving-Konfiguration, die niemand braucht. Oder ein Fachbereich baut LM Studio zum zentralen Gateway aus und wundert sich, warum die Antworten stocken, sobald fünf Leute gleichzeitig tippen. Beide Fehler kosten Zeit und Vertrauen in die Technik.

Was gilt beim Selbsthosten im DACH-Raum?

Ein zweiter Punkt betrifft die Modelllizenzen. Dass ein Modell lokal läuft, sagt nichts über seine Nutzungsrechte. Manche offene Gewichte tragen Non-Commercial-Klauseln oder Umsatz-Schwellen. Vor dem produktiven Einsatz eines Modells gehört die Lizenz des konkreten Gewichts geprüft, unabhängig davon, ob Ollama, LM Studio oder vLLM es ausführt. Der Runner ist lizenzneutral, das Modell nicht.

Fazit: erst die Nutzerzahl, dann das Werkzeug

Die Entscheidung ist einfacher, als die drei Produktnamen vermuten lassen, weil sie nicht wirklich konkurrieren. Bestimme zuerst, wie viele Menschen gleichzeitig zugreifen und ob sie technisch sind. Für Einzelplätze wählst du Ollama, wenn die Nutzer entwickeln, und LM Studio, wenn sie eine Oberfläche brauchen. Für einen kleinen Team-Server bis rund 20 Nutzer nimmst du Ollama mit Open WebUI. Für eine produktive API mit vielen parallelen Nutzern nimmst du vLLM und akzeptierst dessen Setup-Aufwand als Preis für stabilen Durchsatz. Welche GPU-Grösse dazu passt, haben wir in Lokale KI-Modelle 2026: 16, 24 oder 48 GB VRAM? durchgerechnet.

Der teuerste Fehler ist, mit dem falschen Werkzeug in die falsche Grössenordnung zu gehen. Wer einen Prototyp baut, verschwendet Zeit mit vLLM. Wer dreihundert Nutzer bedient, verliert Durchsatz mit Ollama. Die 20-Nutzer-Schwelle und der Faktor aus dem Red-Hat-Test sind die beiden Zahlen, die deine Wahl tragen sollten. Wenn du in Zukunft wachsen willst, plane den Wechsel von Ollama zu vLLM als bewussten Schritt ein, statt ihn unter Last erzwingen zu müssen.