Lokale LLM-Tools im Vergleich 2026: Ollama vs. LM Studio vs. llama.cpp vs. vLLM vs. Jan

Im August 2026 ist es längst kein Hobbyprojekt mehr, große Sprachmodelle auf dem eigenen Notebook oder dem eigenen Server laufen zu lassen. Unternehmen, die interne Dokumente nicht an eine externe API schicken dürfen, Solo-Entwickler, die ihre API-Rechnung von mehreren Hunderttausend Won (mehrere Hundert Euro) im Monat drücken wollen, und Ingenieure, die ihren Coding-Assistenten auch im Flugzeug nutzen möchten – sie alle stehen vor derselben Frage: „Womit soll ich das Ding denn nun betreiben?” Genau darauf gibt dieser Vergleich lokaler LLM-Tools eine Antwort. Grundlage sind ausschließlich Daten, die am 2. August 2026 direkt auf den offiziellen Release- und Preisseiten der jeweiligen Projekte geprüft wurden.

In dieser Kategorie kommen praktisch fünf Kandidaten in die engere Wahl: Ollama, LM Studio, llama.cpp, vLLM und Jan. Schon ein Blick auf die GitHub-Sterne zeigt, dass diese fünf den Markt unter sich aufteilen. Eine direkte Abfrage über die GitHub-API am 2. August 2026 ergibt: Ollama 177.543, llama.cpp 122.385, vLLM 87.913, Jan 43.808. (Bei LM Studio ist die App selbst Closed Source, ein Stern-Vergleich verbietet sich also. Öffentlich sind nur das lms-CLI und die SDKs mit 5.138 Sternen.)

Im ersten Halbjahr 2026 gab es in diesem Markt drei größere Umbrüche. Erstens ist die Gleichung „nur lokal = komplett kostenlos” zerbrochen. Ollama betreibt kostenpflichtige Pro-/Max-/Team-Abos, LM Studio ein nutzungsbasiertes Token-Guthaben in der Cloud. Zweitens hat sich das MLX-Backend auf Apple Silicon faktisch als Standard durchgesetzt – Ollama (ab 0.19), LM Studio und Jan (ab 0.7.7) setzen es alle ein. Drittens die Agentifizierung: Bei Ollama 0.32.0 startet schon der bloße Befehl ollama einen Agenten, und LM Studio hat mit „Bionic” ein eigenständiges Agentenprodukt vorgestellt.

Dieser Guide arbeitet auf über 10.000 Zeichen die aktuellen Versionen und Lizenzen, gemessene Benchmarks, Preismodelle, hardwarebedingte Einschränkungen und schließlich die Empfehlungen nach Anwendertyp durch. In Kapitel 6 korrigiere ich außerdem sechs Fakten, die in vielen Online-Ratgebern bis heute falsch stehen. Vorweg das Fazit: Achtzig Prozent dieser Entscheidung hängen an einer einzigen Frage – „Nutze ich das Modell allein, oder greifen mehrere Personen gleichzeitig darauf zu?”

1. Executive Summary: die fünf großen lokalen LLM-Tools im August 2026 auf einen Blick

Für alle, denen die Zeit fehlt: die Kerndaten aller fünf Werkzeuge in einer einzigen Tabelle. Sämtliche Versionen, Preise und Lizenzen darin wurden am 2. August 2026 direkt an der offiziellen Quelle geprüft.

📊 Große Vergleichstabelle der fünf lokalen LLM-Tools (August 2026)

Drei Zeilen dieser Tabelle sollten Ihnen als Erstes ins Auge springen: paralleles Serving, Apple Silicon / MLX und unterstützte Modellformate. Die allermeisten Fehlentscheidungen in der Praxis entstehen, weil genau diese drei Zeilen vor dem Start nicht gelesen wurden. Typische Beispiele: einen ganzen Tag damit verlieren, vLLM auf einem MacBook installieren zu wollen. Oder einen internen Chatbot mit Ollamas Standardkonfiguration bereitstellen und sich dann wundern, warum alles so zäh läuft, sobald die gleichzeitigen Anfragen in den zweistelligen Bereich klettern.

Besondere Aufmerksamkeit verdient die Zeile unterstützte Modellformate, denn sie ist der größte Lock-in-Faktor dieser Kategorie – und fehlt trotzdem in fast jedem Vergleich. Ollama, LM Studio, llama.cpp und Jan teilen sich das GGUF-Ökosystem (+MLX), vLLM setzt dagegen auf HF safetensors und Verwandte (FP8, AWQ, GPTQ); die GGUF-Unterstützung wurde aus dem Hauptzweig in das Out-of-Tree-Plugin vllm-gguf-plugin ausgelagert. Die vLLM-Dokumentation selbst nennt sie „highly experimental and under-optimized” und empfiehlt, den Tokenizer vom Basismodell statt aus der GGUF-Datei zu nehmen. Praktisch heißt das: Zwischen den ersten vier Werkzeugen wandern Modelldateien reibungslos hin und her, ein Umzug zu vLLM erfordert dagegen die komplette Neubeschaffung der Modellbibliothek.

2. Fünf lokale LLM-Tools im Vergleich: Deep Dive in die Kernfunktionen

Wenn Sie verstehen, wofür jedes Werkzeug ursprünglich gebaut wurde, fällt die Auswahl deutlich leichter. Die fünf Kandidaten stehen nämlich weniger in Konkurrenz zueinander, als dass sie auf unterschiedlichen Schichten sitzen. Tatsächlich nutzen LM Studio und Jan intern llama.cpp als Engine, und auch Ollama ist auf Technik aus der llama.cpp-Familie gestartet.

🦙 1) Ollama – Nr. 1 als Modell-Launcher mit einer CLI-Zeile

• Unschlagbar einfache Bereitstellung: Zwei Befehle, ollama pull und ollama run, führen vom Download bis zum Chat. Ollama betreibt eine eigene Modell-Registry, aus der sich Modelle wie bei Docker Hub schlicht über ihren Namen ziehen lassen, und unterstützt das GGUF-Format. Mit 177.543 GitHub-Sternen liegt das Projekt unter den fünf Kandidaten auf Platz 1 – und genau diese Ökosystemgröße ist Ollamas wertvollstes Kapital. Nahezu jedes nennenswerte Drittanbieter-Tool bringt eine Ollama-Anbindung von Haus aus mit.
• Dialogfähiger Agent eingeführt (v0.32.0, 11. Juli 2026): Der bloße Befehl ollama startet inzwischen einen Agenten, der chatten, coden, im Web suchen und Aufgaben delegieren kann. Wichtig zu wissen: Das Standardmodell ist glm-5.2:cloud – also ein Cloud-Modell. Ab hier klafft die Lücke zwischen dem Image als „reines Lokal-Tool” und dem tatsächlichen Standardverhalten.
• Apple Silicon über das MLX-Backend (v0.19, 30. März 2026): Die Performance auf Apple Silicon hat massiv zugelegt. Der offizielle Blog nennt allerdings eine klare Bedingung für das MLX-Preview-Release: „Please make sure you have a Mac with more than 32GB of unified memory.” Das wird leicht falsch weitergegeben, deshalb präzise: Auf einem MacBook mit 8 oder 16 GB läuft Ollama sehr wohl – es gibt lediglich keine MLX-Beschleunigung. Unterhalb dieser Schwelle arbeitet es normal über den bisherigen Metal-Pfad (llama.cpp). Artikel, die daraus „Ollama braucht einen Mac mit mindestens 32 GB” machen, sollten Sie ignorieren.
• Einstellungen für gleichzeitige Anfragen: Laut offizieller FAQ ist OLLAMA_NUM_PARALLEL „die maximale Zahl paralleler Anfragen, die jedes Modell gleichzeitig verarbeitet, Standard 1”, und OLLAMA_MAX_LOADED_MODELS steht standardmäßig auf „3 × Anzahl der GPUs”. Ollama legt das parallele Slot-Decoding von llama.cpp also durchaus offen – weil der Standardwert aber 1 ist, serialisiert eine unangetastete Installation die Anfragen faktisch. Wenn Ihr interner Chatbot langsam ist, ist der erste Griff diese Umgebungsvariable, nicht ein anderes Werkzeug.
• Warnungen zu abgekündigten Modellen (seit 11. Juli 2026): Wer CodeLlama, Qwen2.5 und Qwen2.5-coder, Llama 3.x, Mistral, StarCoder oder die Standard-Tags von DeepSeek-R1 startet, bekommt eine Deprecation-Warnung. Das heißt konkret: Wer ein Tutorial aus den Jahren 2024 oder 2025 eins zu eins nachbaut, landet zwangsläufig bei dieser Warnung. Wer heute einsteigt, sollte die aktuellen Modell-Tags selbst nachschlagen.
• Kontinuierliche Verbesserungen an der Engine: Draft-Modelle für spekulatives Decoding werden unterstützt, das Decoding für Qwen3-MoE wurde optimiert. Prompt-Caching wurde vom Context-Shifting entkoppelt, was Probleme mit inkonsistenten Antworten behoben hat. v0.32.3 brachte CUDA-Support für Windows auf ARM64, v0.32.5 behob einen MLX-Metal-Bug, der die Ausgabequalität von NVFP4-Modellen (besonders Laguna) verschlechtert hatte.

💠 2) LM Studio – Nr. 1 als GUI-Komplettpaket ohne Terminal

• Zwei Runtimes an Bord: llama.cpp und MLX sind beide integriert, und ein Modell wird in die Engine geladen, die zum heruntergeladenen Format passt (GGUF oder MLX). Wichtig: Es wird nicht die Hardware erkannt und automatisch umgeschaltet. Auf dem Mac müssen Sie ein Modell im MLX-Format laden, um auf der MLX-Engine zu landen; laden Sie auf demselben Mac ein GGUF, läuft es über den llama.cpp-Pfad. Da das gewählte Format direkt die Performance bestimmt, lohnt sich beim Download ein bewusster Blick darauf.
• Quantisierungsstufen visuell auswählen: Im GUI-Modellbrowser sehen Sie Quantisierungsstufen wie Q4_K_M oder Q8 direkt und wählen sie per Klick. Für Einsteiger, die nicht abschätzen können, welche Variante zu ihrem RAM oder VRAM passt, ist allein diese Oberfläche das entscheidende Argument. Bei den anderen Werkzeugen muss man sich stattdessen durch Dateinamen interpretieren.
• Parallele Anfragen dank Continuous Batching (0.4.0, 28. Januar 2026): Server-Deployment-Modus, parallele Anfrageverarbeitung, neue REST-Endpunkte und eine überarbeitete Oberfläche kamen in einem großen Update auf einmal. Unter den Desktop-GUI-Tools ist LM Studio damit beim parallelen Betrieb am weitesten – der Einsatz als Server für ein kleines Team wird dadurch realistisch.
• llmster als Headless-Daemon: Eine Daemon-Komponente, die sich ohne GUI rein als Server betreiben lässt, mit Installationsbefehlen für Mac, Linux und Windows. Der Ablauf „per GUI einrichten, als Server ausrollen” wird damit möglich.
• Agentenprodukt Bionic (vorgestellt am 16. Juli 2026): Ein KI-Agent ausschließlich für offene Modelle, verfügbar als frühe Preview für macOS und Windows; am 27. Juli kam die Unterstützung für Kimi K3 in Bionic hinzu. Allerdings ist der Preis des Bionic Pass bislang nicht veröffentlicht – die offizielle Seite schreibt lediglich „coming soon”.
• Kostenlos für den beruflichen Einsatz (seit 8. Juli 2025): Davor brauchte man für die Nutzung im Unternehmen eine separate kommerzielle Lizenz. Heute darf LM Studio ohne Formular und ohne Rückfrage kostenlos am Arbeitsplatz eingesetzt werden. Diese Tatsache hat sich in vielen deutschsprachigen Quellen noch nicht herumgesprochen.

⚙️ 3) llama.cpp – Nr. 1 als reine Inferenz-Engine, auf der alles andere aufbaut

• Der Ursprung des GGUF-Formats: Das gesamte Ökosystem, das 16-Bit-Gewichte auf 8, 6, 5, 4, 3 oder 2 Bit herunterquantisiert, hat hier seinen Anfang genommen. Einzelnen Berichten zufolge existieren inzwischen sogar Quantisierungen im 1-Bit-Bereich, wodurch der Einsatz auf extrem schwacher Hardware weiter wächst. LM Studio, Jan und Ollama stehen alle in dieser Ahnenlinie.
• Ein Projekt ganz ohne Versionsnummern: Statt semantischer Versionierung kommen Build-Tags (bXXXXX) zum Einsatz. Am 2. August 2026 um 08:15 UTC ist b10226 der aktuelle Build – aber Builds werden mehrmals täglich erneuert (allein am 1. und 2. August erschienen b10218, b10219, b10221, b10223 und b10224). Eine Angabe wie „llama.cpp Version 1.x” existiert schlicht nicht.
• Die Funktionsdichte von llama-server: Auf Standardport 8080 stellt der Server eine OpenAI-kompatible API mit den Endpunkten /v1/chat/completions, /v1/completions, /v1/embeddings und /v1/models bereit. Bestehender Code auf Basis des OpenAI-SDK läuft unverändert weiter, sobald Sie die Base-URL ändern. Der Server von 2026 bringt zusätzlich paralleles Decoding (-np), doppelt kompatible Chat-Routen für OpenAI und Anthropic, Function Calling, spekulatives Decoding, experimentelle multimodale Eingaben, Endpunkte für Embeddings und Reranking, einen Router-Modus mit LRU-Verdrängung mehrerer Modelle sowie MCP-Hooks direkt in der Web-Oberfläche mit.
• Überragende Backend-Breite: Unterstützt werden CUDA, Metal, Vulkan, ROCm, SYCL und WebGPU, und das Ganze läuft unter macOS, Linux, Android und Windows. Bei der Hardwareabdeckung ist llama.cpp unter den fünf Kandidaten unangefochten die Nummer 1. Im April 2026 kam Berichten zufolge Linux-Support für Qualcomms Hexagon-NPU hinzu, womit auch Snapdragon-Notebooks und Edge-Geräte in Reichweite rücken.
• Das Flag --tools all: Ist es gesetzt, greift das LLM aus der Web-Oberfläche heraus direkt auf das lokale Dateisystem zu. So mächtig das ist, so riskant ist es auch – in Umgebungen, die mit nicht vertrauenswürdigen Prompts arbeiten, sollten Sie es unter keinen Umständen aktivieren.

🚀 4) vLLM – Nr. 1 beim Durchsatz für Produktions-Serving mit vielen Nutzern

• PagedAttention: Der KV-Cache wird nicht als zusammenhängender Speicherblock, sondern in Blöcken fester Größe bedarfsgesteuert zugeteilt – analog zum Paging eines Betriebssystems. Materialien aus dem Umfeld der Originalarbeit nennen eine Reduktion der Speicherverschwendung um bis zu Faktor 4, was entsprechend größere Batches auf die GPU bringt. Wer fragt, woher vLLMs Leistung kommt: Hier ist die Antwort.
• Continuous Batching: Endet eine Sequenz innerhalb eines Batches, rückt sofort eine neue Anfrage an ihre Stelle. Klassisches statisches Batching leidet dagegen unter dem Problem, dass die GPU untätig bleibt, bis die längste Anfrage fertig ist. Hinzu kommen Chunked Prefill und Flash Attention.
• Mörderische Release-Frequenz: Neue Releases erscheinen im Zwei- bis Vier-Wochen-Takt. Nach v0.22.0 vom 29. Mai 2026 folgten 0.22.1 am 5. Juni, 0.23.0 am 13. Juni, 0.24.0 am 30. Juni, 0.25.0 am 11. Juli, 0.25.1 am 14. Juli und v0.26.0 am 25. Juli – also mehr als fünf Minor-Releases in gut zwei Monaten. Beachten Sie dabei: Auch im August 2026 steckt vLLM weiterhin im 0.x-Bereich. Ein „vLLM 1.0” gibt es bis heute nicht.
• Klar gezogene Hardwaregrenzen: Auf GPU-Seite werden NVIDIA CUDA, AMD ROCm und Intel XPU unterstützt, auf CPU-Seite x86, ARM AArch64, Apple Silicon und sogar IBM Z (S390X). Allerdings ist GPU-Beschleunigung auf Apple Silicon nur über das separate Projekt vLLM-Metal möglich, nicht über den Hauptzweig. Noch wichtiger: Windows steht nicht auf der offiziellen Supportliste. Es kursieren Hinweise auf Community-Forks, offiziell ist davon nichts.
• Beleg für die Verbreitung im Enterprise-Umfeld: NVIDIA veröffentlicht eigene Release Notes für eine selbst optimierte vLLM-Variante (RN-11517-001_v26.06, Juli 2026). Die containerfreundliche Architektur passt hervorragend zum Ausrollen in Kubernetes-Clustern. Wenn Sie das genauer interessiert, ergänzt der Artikel Container-Tools im Vergleich: Docker vs. Kubernetes vs. Podman das Deployment-Bild sehr gut.

🟣 5) Jan – Nr. 1 als quelloffene GUI mit MCP-Agenten

• Vollständig quelloffener Desktop: Die App gibt es für Windows, macOS und Linux, lizenziert unter Apache 2.0. Diverse Review-Seiten schreiben Jan fälschlich AGPLv3 oder MIT zu; ein direkter Blick in die README des Repositories bestätigt jedoch Apache 2.0. Entwickelt wird das Projekt von Menlo Research, es hält 43.808 Sterne. Genau hier liegt der größte Unterschied zu LM Studio: Ist die App selbst quelloffen oder nicht?
• Der ungewöhnliche Port 1337: Die OpenAI-kompatible API läuft auf localhost:1337. Weil man das leicht mit Ollamas 11434 und llama.cpps 8080 durcheinanderbringt, sollten Sie es sich für die Integration genau merken.
• MCP-Unterstützung (Model Context Protocol): Eine Inline-Oberfläche zur Freigabe von MCP-Tools zeigt an, welches Werkzeug der Agent wann verwenden möchte, und lässt Sie das jeweils einzeln bestätigen. Im Open-Source-Lager gehört Jan damit zu den saubersten GUI-Umsetzungen von Agentenfunktionen.
• Rasante Entwicklung binnen sechs Monaten: v0.8.0 (22. Mai) brachte Multi-Token-Prediction (MTP) und die Integration des llama.cpp-Router-Prozesses, v0.8.1 (29. Mai) Anthropic-kompatible Custom Provider und OS-nativen TLS-Trust, v0.8.2 (1. Juni) das AMD-ROCm/HIP-Backend für Linux sowie pausier- und fortsetzbare Downloads, v0.8.3 (24. Juni) die Navigation durch Nachrichtenversionen, Vorschau für HTML-/SVG-Artefakte und Videoeingaben, v0.8.4 (Juli) schließlich native web_search- und web_fetch-Tools sowie die Umstellung auf einen Backend-Speicher für Zugangsdaten.
• Freie Wahl bei der Modellbeschaffung: GGUF-Modelle werden direkt von HuggingFace geladen (Llama, Gemma, Qwen, GPT-oss und andere). Bei Bedarf lassen sich auch Cloud-APIs wie OpenAI, Anthropic, Mistral, Groq oder MiniMax anbinden – die Kosten rechnet dann jedoch der jeweilige Anbieter direkt mit Ihnen ab, Jan verdient daran keinen Cent.

3. Duell der Benchmarks: Durchsatz, Latenz und Apple-Silicon-Performance

Jetzt zu den Zahlen. Entscheidend ist dabei nicht, wer schnell ist, sondern unter welchen Bedingungen jemand schnell ist. In dem Moment, in dem man ein Ranking ohne die zugehörigen Bedingungen aufstellt, wird der Benchmark zur Lüge.

Die Sternebewertung unten sind deshalb keine Messwerte. Sie ist eine qualitative Einschätzung auf Basis der Architektur – hat ein Werkzeug PagedAttention, Continuous Batching, parallele Slots? – und damit eine andere Art von Aussage als die gemessenen Tabellen weiter unten. Rechnen Sie Sterne nicht in Tok/s-Faktoren um.

[Gesamtdurchsatz bei vielen gleichzeitigen Anfragen — qualitativ, architekturbasiert]
vLLM              : ⭐⭐⭐⭐⭐ (hat PagedAttention und Continuous Batching)
llama.cpp         : ⭐⭐⭐⭐☆ (parallele -np-Slots + Router-Modus, kein PagedAttention)
LM Studio         : ⭐⭐⭐☆☆ (Continuous Batching ab 0.4.0, Platz 1 unter den GUI-Tools)
Ollama            : ⭐⭐⭐☆☆ (parallele Slots über OLLAMA_NUM_PARALLEL, Standard aber 1)
Jan               : ⭐⭐☆☆☆ (optimiert auf eine Person, eine Anfrage am Desktop)

※ Der Sterneunterschied zwischen Ollama und llama.cpp ergibt sich nicht daraus,
   ob die Funktion existiert, sondern aus dem Standardwert (Ollama: 1 Slot) und
   dem fehlenden PagedAttention. Ollama kann parallele Slots per Umgebungsvariable
   aktivieren – ohne paginierten KV-Cache wächst mit jedem Slot aber die
   Cache-Verschwendung, und die Kurve flacht früher ab.

[Gefühlte Antwortgeschwindigkeit im Einzelbetrieb (Batchgröße 1) — qualitativ]
Ollama            : ⭐⭐⭐⭐⭐ (kein Queuing-Overhead im Scheduler, schnelle erste Antwort)
llama.cpp         : ⭐⭐⭐⭐⭐ (mit manuellem Tuning die höchste Obergrenze)
LM Studio         : ⭐⭐⭐⭐☆ (mit Modellen im MLX-Format auf dem Mac besonders stark)
Jan               : ⭐⭐⭐⭐☆ (Abstand seit nativer MLX-Unterstützung geschrumpft)
vLLM              : ⭐⭐⭐☆☆ (kein Vorteil bei Einzelanfragen, TTFT sogar im Nachteil)

📈 3-1. Apple Silicon: gemessene Werte des MLX-Backends von Ollama (offizielle Primärdaten)

Die belastbarsten Zahlen stammen aus dem MLX-Benchmark, den Ollama im offiziellen Blog veröffentlicht hat. Bedingungen: Apple-M5-Serie (M5 / M5 Pro / M5 Max mit GPU Neural Accelerators), Modell Qwen3.5-35B-A3B.

Beim Decoding entspricht das einer Steigerung um etwa das 1,9- bis 2,3-Fache. Lesen Sie diese Tabelle aber bitte nicht als „einfach Ollama updaten und die doppelte Geschwindigkeit bekommen”. Schauen Sie noch einmal auf die Spaltenköpfe: Die 0.18-Spalte ist Q4_K_M, beide 0.19-Spalten sind NVFP4 und int4. Diese Zahlen zeigen also ein Versionsupdate zusammen mit dem Wechsel auf NVFP4- bzw. int4-quantisierte Modelle; wer sein bestehendes Q4_K_M-GGUF weiterverwendet und nur Ollama aktualisiert, sieht davon nichts. Auch der offizielle Blog nennt die Bedingungen: Qwen3.5-35B-A3B nach NVFP4 quantisiert, verglichen mit der vorherigen Implementierung in Q4_K_M unter 0.18. Um diesen Zuwachs auf dem Mac tatsächlich zu sehen, brauchen Sie Ollama-Update und Wechsel des Quantisierungsformats gemeinsam, und der ehrliche Rahmen liegt bei etwa Faktor 1,9 bis 2,3. Dieser MLX-Pfad öffnet sich zudem nur auf Macs mit mehr als 32 GB Unified Memory. Ein MacBook Air mit 16 GB ist damit nicht von Ollama ausgeschlossen – es läuft über den bisherigen Metal-Pfad, erhält nur die Zuwächse dieser Tabelle nicht.

📈 3-2. vLLM vs. Ollama: den Unterschied macht die Parallelität

Mehreren Benchmark-Quellen zufolge erreichte vLLM auf einer NVIDIA A100 bei 128 gleichzeitigen Anfragen rund 793 Tok/s, Ollama dagegen etwa 41 Tok/s; die P99-Latenz lag bei 80 ms für vLLM gegenüber 673 ms für Ollama. Bei 8 gleichzeitigen Anfragen standen 187 Tok/s (vLLM) 82 Tok/s (Ollama) gegenüber – etwa Faktor 2,3 –, und bei 64 gleichzeitigen Nutzern soll der Gesamtdurchsatz um das Acht- bis Neunfache auseinandergelegen haben.

Diese Zahlen dürfen nicht auf einer Stufe mit der Ollama-MLX-Tabelle oben stehen. Sie stammen aus Sekundärquellen, deren Originaldokumente ich nicht einsehen konnte – und keine einzige nennt Modell, Quantisierung, Kontextlänge oder Ollamas Slot-Einstellung (OLLAMA_NUM_PARALLEL). Dieses Kapitel begann mit dem Satz, dass ein Ranking ohne Bedingungen zur Lüge wird; derselbe Maßstab muss also auch hier gelten. Wurde die Ollama-Seite mit dem Standardwert von 1 Slot gemessen, könnte ein erheblicher Teil dieser Acht- bis Neunfach-Lücke Konfiguration statt Architektur sein. Zitieren Sie die exakten Faktoren nicht, nehmen Sie nur die Richtung mit. Wenn Sie belastbare Zahlen für Ihre Umgebung brauchen, ist vllm bench serve neben einer gleich konfigurierten Ollama-Messung präziser als jeder in diesem Artikel zitierte Wert.

Die Richtung selbst ist über mehrere Quellen hinweg konsistent und technisch schlüssig. Zusammengefasst in drei Sätzen:

1. Bei Batchgröße 1, also im Einzelbetrieb, sind die Tok/s von Ollama und vLLM praktisch identisch. Der Unterschied liegt im einstelligen bis maximal 20-Prozent-Bereich – und weil Ollama keinen Queuing-Overhead im Scheduler hat, ist die Zeit bis zum ersten Token (TTFT) dort sogar häufig kürzer.
2. Steigt die Parallelität, wächst der Durchsatz bei vLLM sauber weiter, während Ollamas Kurve vergleichsweise früh abflacht. Dass Ollama gar keine Parallelität besäße, ist allerdings schlicht falsch: Ein höherer Wert bei OLLAMA_NUM_PARALLEL aktiviert parallele Slots, und schon das Verlassen des Standardwerts 1 verändert die Kurve deutlich. Was danach an Abstand bleibt, kommt aus dem Fehlen von PagedAttention (paginierter KV-Cache) und Continuous Batching – und diesen Teil schließt keine Umgebungsvariable.
3. Das Fazit lautet also: „Wer allein arbeitet, hat keinen Grund für vLLM. Sobald die gleichzeitigen Anfragen in den zweistelligen Bereich klettern, gibt es keine Alternative zu vLLM.” Der Bereich dazwischen lässt sich mit Ollamas parallelen Slots, llama.cpps -np oder dem Continuous Batching von LM Studio ab 0.4.0 problemlos abdecken. Die konkreten Schwellen stehen in Tipp ⑧ in Kapitel 6.

📈 3-3. MLX vs. llama.cpp – und die Unterschiede zwischen den Mac-Generationen

Für Mac-Nutzer ist die Backend-Wahl gleichbedeutend mit Performance. Benchmarks aus Sekundärquellen sehen MLX 20 bis 87 Prozent vor llama.cpp; beim Dauerdurchsatz mit kurzem Kontext werden rund 230 Tok/s für MLX gegenüber etwa 150 Tok/s für llama.cpp berichtet. Ein weiterer, häufig zitierter Datenpunkt: Mit Qwen3-Coder-30B-A3B auf einem Mac mini M4 Pro (64 GB) standen rund 130 Tok/s unter MLX gegen 43 Tok/s bei Ollama (llama.cpp-Backend) – etwa Faktor 3. Dieser Faktor 3 misst nicht dasselbe wie die 20-bis-87-Prozent-Spanne oben. Die Spanne vergleicht MLX direkt mit llama.cpp; der Faktor-3-Fall vergleicht MLX mit „llama.cpp, erreicht über die Ollama-Runtime” – also ein Einzelfall, in dem sich Backend-Unterschied und Ollamas Runtime-Overhead addieren. Beide Zahlen aneinanderzureihen und daraus „MLX ist dreimal schneller” zu machen, wäre übertrieben.

Auch der Generationsunterschied bei der Hardware ist nicht zu vernachlässigen. Nach den Erhebungen von llmcheck.net liefert der M5 Max rund 28 Prozent mehr Tok/s als der M4 Max. Bei Llama 3 8B Q4 sind das 82 Tok/s (M5 Max) gegenüber 64 Tok/s (M4 Max), bei Qwen 3.5 30B-A3B Q4 58 Tok/s gegenüber 45 Tok/s. Mittelgroße Modelle (14 bis 35 B) erreichen auf einem M4 Pro mit 24 GB etwa 35 bis 55 Tok/s, und die Speicherbandbreite eines M5 Max mit 128 GB liegt bei rund 600 GB/s. Diese Zahlen zeigen unmittelbar: Über die Performance beim lokalen LLM entscheiden Speicherbandbreite und -kapazität, nicht die Anzahl der GPU-Kerne.

Praktisch folgt daraus: Wer einen Mac nutzt, sollte ein Werkzeug mit MLX-Unterstützung wählen (Ollama ab 0.19, LM Studio, Jan ab 0.7.7) und Modelle im MLX-Format laden. Allein der Wechsel des Backends bringt auf identischer Hardware 20 bis 87 Prozent (die meisten berichteten Fälle liegen bei 30 bis 50 Prozent). Größere Sprünge wie der Faktor-3-Fall kommen vor, dort ist aber Runtime-Overhead mit eingerechnet – kalibrieren Sie Ihre Erwartung deshalb an der Spanne, nicht am Ausreißer. Umgekehrt gilt: Auf einem NVIDIA-GPU-Server ist MLX bedeutungslos – dort entscheiden Sie je nach Parallelitätsbedarf zwischen Ollama und vLLM.

4. Preise im vollständigen Vergleich: Wie weit reicht „kostenlos” wirklich?

Das ist der Bereich, in dem 2026 die meisten Missverständnisse kursieren. Vorweg das Ergebnis: Der lokale Betrieb ist bei allen fünf Werkzeugen kostenlos, Geld kostet ausschließlich das Cloud-Inferenz-Add-on.

[Preisstruktur lokaler LLM-Tools, August 2026]
- llama.cpp        : 0 $        (keinerlei Bezahltarife, Cloud oder Abos. Reines OSS)
- vLLM             : 0 $        (Software gratis, Kosten entstehen allein durch eigene GPU-Infrastruktur)
- Jan              : 0 $        (Desktop gratis, kein Abo; externe APIs rechnet der jeweilige Anbieter ab)
- LM Studio        : 0 $        (lokal und beruflich gratis / Cloud nach Tokenverbrauch)
- Ollama           : 0 $        (lokal unbegrenzt gratis / Cloud-Pro ab 20 $ im Monat)

💰 4-1. Offizielle Preistabelle von Ollama

Auffällig ist, dass der Max-Tarif keine Neuanmeldungen mehr annimmt. Das lässt sich als Signal lesen, dass die Nachfrage die Kapazität übersteigt; für Neueinsteiger bleiben damit faktisch Free, Pro und Team. Übrigens: Eine offizielle Preisliste in Euro existiert nicht. Angaben wie „rund 19 € im Monat”, die man in deutschsprachigen Blogs findet, sind reine Umrechnungen aus dem US-Dollar – prüfen Sie den tatsächlich belasteten Betrag vor dem Kauf am Wechselkurs Ihres Kartenanbieters.

💰 4-2. Preisstruktur von LM Studio

Cloud-Preise nach Verbrauch (je 1 Mio. Token, in USD)

Weil der Cache-Preis bis auf ein Zehntel des Eingabepreises fällt, verändern sich die realen Kosten erheblich, sobald eine Arbeitslast denselben System-Prompt immer wieder verwendet. Wenn Sie tiefer in den Preisvergleich von Cloud-Modellen einsteigen wollen, lohnt ein Blick in ChatGPT vs. Claude vs. Gemini vs. DeepSeek im Vergleich – dort ist die Preisstruktur der Frontier-Modelle aufgeschlüsselt.

💰 4-3. Die eigentlichen Kosten stehen in keiner Preistabelle

Und hier liegt der Kern: Die realen Kosten eines lokalen LLM bestehen nicht aus dem Softwarepreis, sondern aus Hardware, Strom und Arbeitszeit.

Erstens die Hardwarekosten. Hier werden regelmäßig zwei verschiedene Dinge vermischt, also trennen wir sie sauber. Ollamas MLX-Beschleunigung setzt mehr als 32 GB Unified Memory voraus – das ist aber eine Zugangsbedingung für Ollamas MLX-Backend, keine Hardwareanforderung von Modellen der 30-B-Klasse. Ein 30-B-Modell selbst läuft auf einem M4 Pro mit 24 GB mit 35 bis 55 Tok/s (siehe 3-3). Ein Gerät unterhalb von 32 GB fällt also nicht aus dieser Performance-Diskussion heraus, es nutzt lediglich nicht Ollamas MLX-Pfad, sondern den bisherigen Metal-Pfad. Da bei lokalen LLMs Speicherbandbreite und -kapazität über die Performance entscheiden, kostet es dennoch Geld, große Modelle komfortabel zu betreiben: ein Mac mit großzügigem Unified Memory oder eine NVIDIA-GPU mit genug VRAM. Ob es vernünftig ist, sich für die Einsparung eines Abos zu 20 $ im Monat ein Gerät für mehrere Tausend Euro zu kaufen, hängt schlicht an Ihrer Nutzungsfrequenz.

Ein weiterer Kostenblock taucht in kaum einer Kalkulation auf: die Migration des Modellformats. Ollama, LM Studio, llama.cpp und Jan nutzen dieselben GGUF-Dateien weiter – sobald Sie aber zu vLLM wechseln, kommt Ihre GGUF-Bibliothek nicht mit. Die GGUF-Unterstützung von vLLM wurde aus dem Hauptzweig in ein Out-of-Tree-Plugin ausgelagert und bleibt experimentell, in der Praxis lädt man deshalb HF-safetensors-Builds (FP8/AWQ/GPTQ) neu herunter. Bei Modellen zwischen wenigen und Dutzenden Gigabyte bedeutet das neue Downloadzeit, neuen Speicherplatz und neue Validierungszeit. Zusätzlich müssen Sie den Tokenizer separat auf das Basismodell zeigen lassen. Wer über „Kosten, die nicht auf der Preisliste stehen” schreibt, darf diesen Posten nicht auslassen.

Zweitens wird die Kostenstruktur von vLLM besonders häufig missverstanden. Die Software ist unter Apache-2.0 vollständig kostenlos, aber vLLM spielt seine Existenzberechtigung erst auf GPUs im Rechenzentrumsformat aus. Die tatsächlichen Kosten von vLLM sind also der volle Stundenpreis der GPU-Instanz. Umgekehrt formuliert: Wenn Sie diese GPU bereits besitzen und mehrere Nutzer darauf zugreifen, vervielfacht vLLM den Durchsatz auf derselben Hardware – und wird damit zum Werkzeug, das die Stückkosten pro GPU senkt.

Drittens die Betriebszeit. llama.cpp kostet null Euro an Software, verlangt aber, dass Sie Build-Optionen und Flags selbst in die Hand nehmen; und weil sich der Build-Tag mehrmals täglich ändert, müssen Sie selbst nachhalten, unter welchem Build alles funktioniert hat. LM Studio dagegen ist unmittelbar nach der Installation einsatzbereit. Sobald Sie den Stundensatz Ihrer Ingenieure einrechnen, ist das kostenlose Werkzeug nicht mehr automatisch das günstigste.

5. Die finalen Empfehlungen nach Anwendertyp

Auf Basis aller bisherigen Daten hier die optimale Wahl für die jeweilige Situation. Wer nur dieses Kapitel liest, hat sein Ergebnis.

🎯 1) Nicht-Entwickler, Produktverantwortliche und Forschende, die zum ersten Mal ein lokales LLM ausprobieren

• Beste Wahl: LM Studio
• Warum: Sie müssen kein einziges Mal ein Terminal öffnen und können im GUI-Modellbrowser die Quantisierungsstufe sehen und auswählen. Vor allem aber ist LM Studio seit dem 8. Juli 2025 auch beruflich vollständig kostenlos – die Installation auf dem Firmenlaptop wirft also keine Lizenzfragen auf. Mit llama.cpp und MLX sind beide Runtimes integriert, ein Modell wird in die zu seinem Format passende Engine geladen – merken Sie sich nur, dass Sie auf dem Mac selbst ein Modell im MLX-Format wählen müssen, um auf der MLX-Engine zu landen.

🎯 2) Einzelentwickler, die mit der CLI vertraut sind und häufig Modelle wechseln

• Beste Wahl: Ollama
• Warum: Eine Zeile ollama run genügt, und wie die 177.543 GitHub-Sterne zeigen, ist das Ökosystem an Drittanbieter-Integrationen konkurrenzlos. Bei Batchgröße 1 liegt der Durchsatz praktisch gleichauf mit vLLM, während die Zeit bis zur ersten Antwort sogar häufig kürzer ausfällt. Beachten Sie nur, dass die Modell-Tags aus Tutorials von 2024 und 2025 (Llama 3.x, Qwen2.5, Mistral usw.) inzwischen Deprecation-Warnungen auslösen – nutzen Sie die aktuellen Tags.

🎯 3) Teams, die einen internen Chatbot oder eine RAG-API mit mehr als zehn gleichzeitigen Anfragen betreiben

• Beste Wahl: vLLM
• Warum: Ab diesem Bereich gehen die Alternativen aus. PagedAttention reduziert die Verschwendung im KV-Cache, Continuous Batching eliminiert GPU-Leerlauf – dadurch wächst der Durchsatz mit steigender Parallelität weiter an. Ollama kann mit OLLAMA_NUM_PARALLEL zwar parallele Slots aktivieren, ohne paginierten KV-Cache wächst mit jedem Slot aber die Cache-Verschwendung und die Kurve flacht früher ab. Prüfen Sie unbedingt vorab die Einschränkungen: Windows wird offiziell nicht unterstützt, die Apple-Silicon-GPU nur über das separate Projekt vLLM-Metal – und Ihre bestehende GGUF-Modellbibliothek wandert nicht mit. Beachten Sie außerdem: Auch in einem Zehn-Personen-Team stellen selten zehn Personen gleichzeitig Anfragen. Maßstab sind gleichzeitige Anfragen im Spitzenlastfall, nicht die Kopfzahl.

🎯 4) Ingenieure, die bis an die Grenze auf schwacher Hardware, Edge-Geräten oder Embedded-Systemen arbeiten

• Beste Wahl: llama.cpp
• Warum: Die Backend-Breite ist unter den fünf Kandidaten überragend. Unterstützt werden CUDA, Metal, Vulkan, ROCm, SYCL und WebGPU, und alles läuft unter macOS, Linux, Android und Windows. Quantisierungen mit 8/6/5/4/3/2 Bit lassen sich frei wählen, und mit dem Router-Modus von llama-server können Sie mehrere Modelle mit LRU-Verdrängung gleichzeitig betreiben. Sehr oft ist llama.cpp schlicht die einzige Option, die auf Hardware läuft, auf der kein anderes Tool startet.

🎯 5) Nutzer, die Open-Source-Prinzipien einhalten müssen oder MCP-Agenten erproben wollen

• Beste Wahl: Jan
• Warum: Jan ist das einzige GUI-Tool, dessen App selbst unter Apache 2.0 quelloffen ist. LM Studios App ist Closed Source und kommt damit in Organisationen mit Auditpflicht schwer durch die Prüfung. Jan bietet eine Inline-Oberfläche zur MCP-Toolfreigabe und hat mit v0.8.4 native web_search- und web_fetch-Tools ergänzt. Auch das AMD-ROCm-Backend für Linux (v0.8.2) wird unterstützt.

🎯 6) Entwickler, die einen Coding-Assistenten offline einbinden wollen

• Beste Wahl: Ollama oder LM Studio
• Warum: Beide Werkzeuge haben etablierte Wege zur Anbindung externer Coding-Tools. LM Studio lässt seine Modelle seit dem 30. Januar 2026 in Claude Code nutzen, und Ollama hat mit v0.32.3 die Anbindung an Claude Code Channels wiederhergestellt sowie über ollama launch chatgpt eine Integration in die Codex-App (nach der Umbenennung: ChatGPT) im Angebot. Wenn Sie wissen möchten, wie groß der Leistungsunterschied zu cloudbasierten Coding-Agenten ausfällt, lesen Sie ergänzend KI-Coding-Agenten im Vergleich: Cursor vs. GitHub Copilot vs. Cline.

🎯 7) Fälle, in denen die Sicherheitsrichtlinie kein einziges Byte außer Haus lässt

• Beste Wahl: llama.cpp oder Jan (zweite Wahl: Ollama in reiner Lokalkonfiguration)
• Warum: Alle fünf Werkzeuge laufen vollständig offline, aber komplett ohne jede Cloud-Komponente kommt nur llama.cpp aus. Auch Jan hat auf dem Desktop weder Abos noch Abrechnung und ist konsequent local-first entworfen. Wenn Sie Ollama einsetzen, prüfen Sie unbedingt, dass das Standardmodell des Agenten in v0.32.0 glm-5.2:cloud ist – also ein Cloud-Modell – und geben Sie ein lokales Modell explizit an. Bei einem Vertrag auf Teamebene sichert der Team-Tarif Zero Data Retention und kein Logging ausdrücklich zu.

6. Praxistipps und typische Fehler (was in vielen Ratgebern bis heute falsch steht)

Dieses Kapitel ist der praktischste Teil des Artikels. Ich habe hier sechs Fakten, die in einem Großteil der aktuellen Online-Quellen schlicht falsch stehen, zusammen mit Praxistipps zusammengetragen.

① „LM Studio braucht im Unternehmen eine kommerzielle Lizenz” → falsch. Zum 8. Juli 2025 wurde die Lizenzpflicht für kommerzielle Nutzung abgeschafft. Sie dürfen LM Studio heute ohne Formular und ohne gesonderte Anfrage kostenlos am Arbeitsplatz einsetzen. Trotzdem geben zahlreiche Blogs weiterhin die alte Regelung wieder – und es gibt tatsächlich Teams, die LM Studio deswegen aus der Auswahl gestrichen haben. Wenn Sie gerade eine Einführung im Unternehmen prüfen, korrigieren Sie diesen Punkt als Erstes.

② „Jan steht unter AGPLv3” → falsch. Es ist Apache 2.0. Diverse Review-Seiten schreiben AGPLv3 oder MIT, doch die direkt in der README des Repositories geprüfte Lizenz lautet Apache 2.0. Die AGPL bringt beim Betrieb als Netzwerkdienst eine Offenlegungspflicht für den Quellcode mit sich und scheitert deshalb oft an der Rechtsabteilung – bei Jan trifft das schlicht nicht zu. Wer Jan wegen der Lizenz aussortiert hat, sollte die Entscheidung noch einmal überdenken.

③ „vLLM 1.0 ist erschienen” → gibt es bislang nicht. Stand August 2026 ist v0.26.0 aktuell, und das Projekt steckt weiterhin im 0.x-Bereich. Bei einem Projekt, das alle zwei bis vier Wochen ein Release herausbringt, ist das Pinnen der Version praktisch Pflicht. Wer in der requirements.txt nur vllm stehen hat, arbeitet zwei Wochen später in einer anderen Umgebung als sein Teamkollege. Schreiben Sie die exakte Version fest und lesen Sie vor jedem Upgrade die Release Notes.

④ „Ollama ist ein komplett kostenloses, rein lokales Tool” → 2026 nur noch zur Hälfte richtig. Der lokale Betrieb bleibt unbegrenzt kostenlos, aber es existieren Cloud-Abos wie Pro für 20 $ im Monat, und das Standardmodell des Agenten in v0.32.0 ist ein Cloud-Modell (glm-5.2:cloud). Wer also gedankenlos ollama eintippt und interne Daten hineinkopiert, schickt diese Daten unter Umständen nach draußen. In sicherheitskritischen Umgebungen gewöhnen Sie sich an, schon beim ersten Setup ein lokales Modell explizit festzulegen.

⑤ „Die neueste llama.cpp-Version ist 1.x” → dieses Versionsschema existiert überhaupt nicht. llama.cpp nutzt keine semantische Versionierung, sondern ausschließlich Build-Tags (bXXXXX). Am 2. August 2026 ist das b10226, morgen sieht es anders aus. Der Praxistipp lautet: Notieren Sie den Build-Tag, unter dem alles funktioniert hat, und checken Sie genau diesen Tag aus. Wer jedes Mal einfach den Master zieht, erlebt regelmäßig, dass ein Flag, das gestern noch lief, heute nicht mehr funktioniert.

⑥ „Mit MLX wird der Mac einfach doppelt so schnell” → gleich zwei Bedingungen. Erstens setzt Ollamas MLX-Preview-Backend einen Mac mit mehr als 32 GB Unified Memory voraus. Daraus „auf einem 16-GB-Mac kann man Ollama nicht nutzen” zu machen, ist jedoch falsch: Unterhalb der Schwelle läuft Ollama normal über den bisherigen Metal-Pfad (llama.cpp), nur eben ohne MLX-Beschleunigung. Zweitens sind die 1,9 bis 2,3 Fachen aus dem offiziellen Blog nicht der Effekt des Versionssprungs allein, sondern des gleichzeitigen Wechsels auf NVFP4- bzw. int4-quantisierte Modelle. Wer bei Q4_K_M bleibt und nur die Version anhebt, sieht diesen Rahmen nicht. Bei 16 GB oder weniger planen Sie mit kleinen Modellen der 7- bis 8-B-Klasse und Q4-Quantisierung – und ändern Sie Modellgröße und -format, bevor Sie das Werkzeug wechseln.

⑦ Wer sich die Portnummern merkt, halbiert den Integrationsaufwand. Ollama 11434, llama-server von llama.cpp 8080, Jan 1337. Alle drei bieten eine OpenAI-kompatible API – bestehender Code auf Basis des OpenAI-SDK läuft unverändert weiter, sobald Sie nur die Base-URL ändern. Einen neuen Client zu bauen ist unnötig. llama.cpp stellt darüber hinaus Anthropic-kompatible Chat-Routen bereit, sodass sich auch Code auf Basis des Anthropic-SDK weiterverwenden lässt.

⑧ Beantworten Sie zuerst „Wie viele gleichzeitige Anfragen gibt es in der Spitze?”, und wählen Sie dann das Werkzeug. (Die eine Schwelle dieses Artikels.) Der häufigste Designfehler ist, diese Reihenfolge umzudrehen. Immer wieder sieht man Teams, die Ollama für einen internen Dienst aufsetzen und bei nachlassender Geschwindigkeit GPUs nachkaufen. Der erste Griff ist aber weder GPU-Kauf noch vLLM-Migration. Laut offizieller Ollama-FAQ steht OLLAMA_NUM_PARALLEL – die maximale Zahl paralleler Anfragen pro Modell – standardmäßig auf 1. Eine unangetastete Ollama-Installation serialisiert Ihre Anfragen faktisch, und diese Art von Langsamkeit ist ein Konfigurations-, kein Hardwareproblem. OLLAMA_MAX_LOADED_MODELS mit dem Standardwert 3 × Anzahl der GPUs sollten Sie im selben Zug prüfen.

Das Rezept hat deshalb zwei Schritte. (1) Erhöhen Sie zuerst OLLAMA_NUM_PARALLEL, und (2) wenn die Kurve dann immer noch nicht anzieht, wechseln Sie zu vLLM. Umgekehrt zahlen Sie eine unnötige Migration plus die Neubeschaffung sämtlicher Modelle. Was nach Schritt 1 an Abstand bleibt, kommt aus dem Fehlen von PagedAttention und Continuous Batching – und das lässt sich nicht über die Slot-Zahl lösen.

Dieser Artikel wendet die folgenden Schwellen in allen Kapiteln identisch an. Maßstab sind gleichzeitige Anfragen in der Spitze, nicht registrierte Nutzer.

[Einheitliche Entscheidungsschwelle nach gleichzeitigen Anfragen]
1–4 gleichzeitige Anfragen   → Ollama (NUM_PARALLEL anpassen) · LM Studio · Jan
5–10 gleichzeitige Anfragen  → llama.cpp -np · Continuous Batching in LM Studio 0.4.0+
mehr als 10 oder jeder       → vLLM
Dienst mit SLA

⑨ Ignorieren Sie Deprecation-Warnungen bei Modell-Tags nicht. Seit dem 11. Juli 2026 zeigt Ollama Abkündigungswarnungen für die Standard-Tags von CodeLlama, Qwen2.5 und Qwen2.5-coder, Llama 3.x, Mistral, StarCoder und DeepSeek-R1. Wenn Sie ein Tutorial kopieren und diese Warnung sehen, ist das ein Signal, dass das Tutorial mindestens ein Jahr alt ist. Mit hoher Wahrscheinlichkeit sind dann auch die übrigen Inhalte veraltet.

⑩ --tools all reißt die Vertrauensgrenze ein. Ist dieses Flag in llama.cpp gesetzt, greift das LLM aus der Web-Oberfläche direkt auf das lokale Dateisystem zu. Für private Experimente ist das mächtig – in einer Pipeline, die externe Dokumente oder Webseiten ins Modell einspeist, wird aus einer Prompt-Injection jedoch unmittelbar ein Dateizugriff. Schalten Sie es in Umgebungen mit externen Eingaben nicht ein.

⑪ Wenn vLLM auf Ihrer Roadmap steht, kalkulieren Sie die Neubeschaffung der Modelle ein. „Alle sind OpenAI-kompatibel, es ist also nur eine Zeile Base-URL” gilt ausschließlich für den Client-Code. Modell-Assets folgen Ihnen nicht. Ollama, LM Studio, llama.cpp und Jan teilen sich das GGUF-Ökosystem (+MLX), vLLM setzt dagegen auf HF safetensors (FP8/AWQ/GPTQ), und die GGUF-Unterstützung wanderte aus dem Hauptzweig in das Out-of-Tree-Plugin vllm-gguf-plugin. Die offizielle Dokumentation nennt sie „highly experimental and under-optimized”, warnt vor Inkompatibilitäten mit anderen Funktionen und empfiehlt, den Tokenizer vom Basismodell statt aus der GGUF-Datei zu nehmen. Nehmen Sie deshalb drei Zeilen in den Migrationsplan auf: (1) Liste der neu zu ladenden Modelle und deren Gesamtgröße, (2) Zeit für Download und Validierung, (3) alles, dessen Qualität nach dem Wechsel des Quantisierungsformats erneut geprüft werden muss. In der Praxis ist das der größte Kostenblock jedes Werkzeugwechsels.

7. Häufige Fragen (FAQ)

F. Wer gewinnt den Vergleich der lokalen LLM-Tools am Ende?

Einen absoluten Sieger gibt es nicht, nur Sieger je nach Bedingung. Für Solo-Entwickler ist es Ollama, wer eine GUI braucht nimmt LM Studio, für Multi-User-Serving ist es vLLM, für extreme Hardwareanforderungen llama.cpp, und für Open-Source-Prinzipien plus MCP-Agenten Jan. Wenn Sie unbedingt „das eine unkomplizierte” hören wollen: Ollama verbindet Ökosystemgröße (177.543 GitHub-Sterne) mit Bedienkomfort und ist damit eine solide erste Wahl.

F. Was ist schneller, Ollama oder vLLM?

Die Antwort kippt je nach Bedingung. Im Einzelbetrieb mit Batchgröße 1 sind die Tok/s beider Werkzeuge praktisch identisch, und weil Ollama keinen Queuing-Overhead im Scheduler hat, kommt die erste Antwort dort sogar oft schneller. Steigt die Zahl gleichzeitiger Anfragen, wächst der Durchsatz bei vLLM dagegen kontinuierlich weiter, während Ollamas Kurve vergleichsweise früh abflacht. Verwechseln Sie das aber nicht mit „Ollama hat keine Parallelitätsfunktionen”: OLLAMA_NUM_PARALLEL aus der offiziellen FAQ legt die Zahl paralleler Slots fest und steht standardmäßig auf 1 – ein guter Teil der gefühlten Langsamkeit ist schlicht ein nie erhöhter Wert. Was danach bleibt, kommt aus dem Fehlen von PagedAttention und Continuous Batching. Legen Sie also zuerst fest, ob „schnell” für Sie Durchsatz oder Antwortlatenz bedeutet, und vergleichen Sie erst dann.

F. Darf ich LM Studio im Unternehmen kostenlos einsetzen?

Ja. Seit dem 8. Juli 2025 ist die Lizenzpflicht für kommerzielle Nutzung entfallen, Sie können LM Studio also ohne Formular und ohne Anfrage kostenlos am Arbeitsplatz nutzen. Der Gratistarif enthält lokale LLM-Ausführung, Offline-Sprachtranskription, den Bionic-Agenten, llama.cpp- und MLX-Backend sowie LM Link für bis zu fünf Geräte. Wenn Sie irgendwo lesen, für den beruflichen Einsatz brauche es eine gesonderte Lizenz: Dieser Text ist veraltet.

F. Ich möchte ein lokales LLM auf dem MacBook nutzen – welches Tool ist gut?

Auf dem Mac ist ein Werkzeug mit MLX-Backend die richtige Antwort. Ollama (ab 0.19), LM Studio und Jan (ab 0.7.7) unterstützen MLX alle. Ollamas MLX-Preview-Backend setzt allerdings mehr als 32 GB Unified Memory voraus. Genau hier liegt der häufigste Irrtum: Auf einem 16-GB-Mac hört Ollama nicht auf zu funktionieren, es fehlt nur die MLX-Beschleunigung – der bisherige Metal-Pfad (llama.cpp) läuft einwandfrei. LM Studio und Jan nennen für MLX keine vergleichbare Speicherbedingung, die Speicherobergrenze selbst wirkt aber bei jedem Werkzeug gleich. Auf einem 16-GB-Mac sind Q4-Modelle der 7- bis 8-B-Klasse unabhängig vom Werkzeug die realistische Obergrenze, ab 14 B wird es selbst mit reduziertem Kontext eng. Die eigentliche Frage auf einem 16-GB-Mac lautet also nicht „Ollama oder nicht”, sondern welche Modellgröße und welches Format Sie laden können. Von vLLM auf dem Mac rate ich ab: Die GPU-Unterstützung für Apple Silicon läuft ausschließlich über das separate Projekt vLLM-Metal und ist nicht in den Hauptzweig integriert.

F. Kann ich vLLM unter Windows nutzen?

Offiziell nicht. In der Liste unterstützter Hardware in der offiziellen Installationsdokumentation von vLLM taucht Windows nicht auf. Es kursieren Hinweise auf Community-Forks, doch da es sich nicht um offiziellen Support handelt, ist der produktive Einsatz riskant. Wenn Sie unter Windows Multi-User-Serving brauchen, wenden Sie dieselben Schwellen aus Tipp ⑧ in Kapitel 6 an. Oberhalb von zehn gleichzeitigen Anfragen ist vLLM auf WSL2 oder auf einem Linux-Server die realistische Konfiguration. Im Bereich von fünf bis zehn decken LM Studio ab 0.4.0 mit Continuous Batching oder das parallele Decoding von llama.cpp per -np das direkt unter Windows problemlos ab. Bei einer bis vier genügt meist schon, Ollamas OLLAMA_NUM_PARALLEL anzuheben.

F. Sind alle lokalen LLM-Tools kostenlos? Gibt es versteckte Kosten?

Der lokale Betrieb ist bei allen fünf Werkzeugen kostenlos. llama.cpp, vLLM und Jan haben überhaupt keine Bezahltarife, Ollama und LM Studio berechnen ausschließlich Cloud-Inferenz-Add-ons (Ollama Pro für 20 $/Monat, LM Studio nach Tokenverbrauch). Die echten Kosten sind Hardware, Strom, Betriebszeit und die Neubeschaffung von Modellen. Die 32-GB-Zahl wird ständig vermischt, deshalb präzise: Mehr als 32 GB Unified Memory ist eine Bedingung von Ollamas MLX-Backend, keine Anforderung von Modellen der 30-B-Klasse. Ein 30-B-Modell selbst läuft auf einem M4 Pro mit 24 GB mit 35 bis 55 Tok/s. Große Modelle komfortabel zu betreiben kostet natürlich trotzdem Geld in Speicherkapazität und -bandbreite – und bei vLLM ist praktisch die komplette Rechnung der Preis der Rechenzentrums-GPU. Und weil ein Umzug zu vLLM Ihre GGUF-Modellbibliothek nicht mitnimmt, kalkulieren Sie Zeit und Speicherplatz für das erneute Herunterladen zweistelliger Gigabyte-Mengen mit ein.

F. Was unterscheidet LM Studio und Jan?

Beide sind GUI-first-Desktopwerkzeuge, der entscheidende Unterschied ist die Quelloffenheit. Bei LM Studio ist die App selbst Closed Source, auf GitHub liegen nur das lms-CLI und die SDKs. Jan hingegen steht komplett unter Apache 2.0. Funktional liegt LM Studio bei der visuellen Auswahl der Quantisierung und bei parallelen Anfragen dank Continuous Batching vorn, Jan punktet auf der Agentenseite mit Inline-Freigabe für MCP-Tools und nativen web_search- und web_fetch-Tools. Für Organisationen mit Auditpflicht: Jan. Wenn Komfort vorgeht: LM Studio.

F. Wie prüfe ich die Version von llama.cpp?

Es gibt keine semantische Versionierung. Stattdessen kommen Build-Tags der Form bXXXXX zum Einsatz. Am 2. August 2026 um 08:15 UTC ist b10226 der aktuelle Build – allein am 1. und 2. August erschienen jedoch b10218, b10219, b10221, b10223 und b10224 hintereinander, so häufig wird aktualisiert. In der Praxis empfiehlt sich, den Build-Tag mit nachweislich korrektem Verhalten zu notieren und genau diesen Tag festzuschreiben.

F. Kann ich bestehenden OpenAI-API-Code unverändert auf lokale Modelle umziehen?

Ja, in den allermeisten Fällen. Alle fünf Werkzeuge bieten eine OpenAI-kompatible API, Sie ändern also nur die Base-URL des SDK auf die lokale Adresse. Die Ports lauten Ollama 11434, llama-server von llama.cpp 8080 und Jan 1337; LM Studio und vLLM stellen ebenfalls jeweils einen kompatiblen Server bereit. llama.cpp unterstützt /v1/chat/completions, /v1/completions, /v1/embeddings und /v1/models und bringt zusätzlich Anthropic-kompatible Chat-Routen mit – die Portabilität ist dort also besonders gut.

8. Fazit: Der Vergleich lokaler LLM-Tools 2026 endet bei zwei Fragen

Wir haben alle fünf Werkzeuge nach Version, Lizenz, Performance, Preis und Hardwaregrenzen durchleuchtet – die eigentliche Entscheidung ist am Ende erstaunlich einfach. Die erste Frage lautet: „Wie viele gleichzeitige Anfragen gibt es in der Spitze?” Bei einer bis vier wählen Sie nach Geschmack zwischen Ollama (mit angepasstem OLLAMA_NUM_PARALLEL), LM Studio und Jan; bei fünf bis zehn sind llama.cpps -np oder das Continuous Batching von LM Studio in ihrem Element; oberhalb von zehn oder bei jedem Dienst mit SLA heißt die Antwort vLLM. In diesem letzten Bereich lässt sich der verbleibende Abstand kaum über Umgebungsvariablen schließen, denn er kommt aus dem Vorhandensein oder Fehlen von PagedAttention und Continuous Batching (die genauen Grenzen verschieben sich allerdings mit Modellgröße, Kontextlänge und SLA – messen Sie einmal in Ihrer eigenen Umgebung nach). Die zweite Frage lautet: „Können Sie ein Terminal öffnen?” Wenn ja, stehen Ihnen Ollama und llama.cpp offen; wenn nein oder wenn Sie es nicht wollen, bleiben LM Studio und Jan.

Dass diese Kategorie im ersten Halbjahr 2026 spürbar erwachsen geworden ist, zeigt sich ebenfalls deutlich. Auf Apple Silicon hat sich MLX als Standard etabliert und der Decode-Durchsatz ist auf identischer Hardware deutlich gestiegen (laut offiziellem Ollama-Benchmark von 58 Tok/s unter 0.18 mit Q4_K_M auf 134 Tok/s unter 0.19 mit int4 – allerdings als Ergebnis von Versionssprung und Wechsel des Quantisierungsformats zusammen), und inzwischen bieten alle fünf Werkzeuge eine OpenAI-kompatible API. Eine Sache muss hier aber präzise gesagt werden: Der API-Aufrufcode ist eine Zeile Base-URL, Ihre Modell-Assets folgen jedoch nicht. Zwischen den ersten vier wandern GGUF-Dateien reibungslos, ein Wechsel ist dort tatsächlich billig – eine GGUF-Bibliothek wandert aber nicht zu vLLM (die Unterstützung wurde aus dem Hauptzweig in ein experimentelles Out-of-Tree-Plugin ausgelagert). Wenn vLLM in Ihren Plänen vorkommt, kalkulieren Sie Zeit und Speicherplatz für die Neubeschaffung der Modelle von Anfang an ein.

Gleichzeitig ist eine Entwicklung entstanden, die Wachsamkeit verlangt. Die Gleichung „lokales Tool = komplett kostenlos = die Daten verlassen niemals das Gerät” gilt nicht mehr automatisch. Das Standardmodell des Agenten in Ollama v0.32.0 ist ein Cloud-Modell, und auch LM Studio betreibt ein Cloud-Guthaben. Wenn Datenschutz der Grund für Ihre Einführung war, prüfen Sie unbedingt, ob Sie beim ersten Setup ein lokales Modell explizit festgelegt haben; auf Organisationsebene empfehle ich, zuerst llama.cpp ganz ohne Cloud-Komponenten oder die quelloffene GUI Jan in Betracht zu ziehen.

Zusammenfassung: die passende Empfehlung für Ihre Lage

┌─ Mehr als zehn gleichzeitige Anfragen in der Spitze? (Oder ein Dienst mit SLA?)
│   └─ JA → vLLM (v0.26.0)
│            ※ kein offizieller Windows-Support, Mac-GPU nur via vLLM-Metal
│            ※ Software gratis, Kosten = komplette GPU-Infrastruktur
│            ※ GGUF-Bibliothek wandert nicht mit → Neubeschaffung einkalkulieren
│
├─ Fünf bis zehn gleichzeitige Anfragen?
│   └─ JA → llama.cpp mit parallelem Decoding -np (b10226, MIT)
│            oder Continuous Batching in LM Studio 0.4.0+ (0.4.20)
│            ※ besonders realistisch für Multi-User-Serving unter Windows
│
└─ NEIN (1–4 gleichzeitige Anfragen / faktisch Einzelnutzung)
    │
    ├─ Ist Ihnen das Terminal vertraut?
    │   ├─ JA ──┬─ solide erste Wahl      → Ollama (v0.32.5, MIT)
    │   │       │                          ※ wenn langsam: erst OLLAMA_NUM_PARALLEL (Standard 1)
    │   │       │                          ※ MLX-Preview braucht > 32 GB Unified Memory
    │   │       │                            (darunter läuft der bisherige Metal-Pfad)
    │   │       │                          ※ Achtung: Agenten-Standardmodell ist ein Cloud-Modell
    │   │       └─ Extremtuning der HW     → llama.cpp (b10226, MIT)
    │   │                                  ※ meiste Backends, null Bezahlelemente
    │   │
    │   └─ NEIN ┬─ Komfort geht vor        → LM Studio (0.4.20)
    │           │                          ※ seit 08.07.2025 auch beruflich gratis
    │           │                          ※ auf dem Mac Modelle im MLX-Format selbst wählen
    │           │                          ※ aber: die App selbst ist Closed Source
    │           └─ Open Source und MCP Pflicht → Jan (v0.8.4, Apache 2.0)
    │                                      ※ API-Port 1337, komplett kostenlos
    │
    └─ Wenn kein Byte das Haus verlassen darf
        → llama.cpp (null Cloud-Elemente) oder Jan
        → bei Ollama/LM Studio: lokales Modell zwingend explizit angeben

[Port-Spickzettel] Ollama 11434 · llama.cpp 8080 · Jan 1337
[Preis-Spickzettel] lokal überall 0 $ / Ollama Pro 20 $ · Team 25 $ (pro Platz)
                    LM Studio Cloud nach Tokenverbrauch
[Format-Spickzettel] Ollama · LM Studio · llama.cpp · Jan teilen sich GGUF (+MLX)
                     vLLM = HF safetensors · FP8 · AWQ · GPTQ (GGUF: Experimental-Plugin)

Bei lokalen LLMs geht es längst nicht mehr um die Frage „Geht das überhaupt?”, sondern um „Womit und unter welchen Bedingungen lasse ich sie laufen?”. Nehmen Sie den Spickzettel oben als Grundlage, entscheiden Sie sich heute für eines der Werkzeuge und installieren Sie es. Innerhalb des GGUF-Ökosystems (Ollama, LM Studio, llama.cpp, Jan) können Sie jederzeit mit einer Zeile Base-URL wechseln; nur beim Umzug zu vLLM müssen Sie die Modelle neu beschaffen. 🚀