LM Studio vs. Ollama: gleiche Engine, andere Türen – und welches du nimmst

Nimm LM Studio, wenn du alles auf dem Bildschirm sehen willst: Modell suchen, laden und chatten, ganz ohne Terminal. Nimm Ollama, wenn du einen Server willst, an den sich andere Programme hängen, offenen Code und einen Befehl pro Modell. Beide nutzen dieselbe Engine, llama.cpp: Auf demselben Rechner passen dieselben Modelle.

Der letzte Satz ist der eigentliche Knackpunkt dieses Vergleichs. Ollama 0.40.10, seit dem 23. Oktober 2026 die stabile Version, bringt llama.cpp im Build b11803 mit; LM Studio 0.4.26 bringt seine llama.cpp-Laufzeit 2.50.0 mit, gebaut auf b11337. Und auf einem Mac mit Apple Silicon können beide ein Modell zusätzlich über MLX laufen lassen. Dieselbe Engine, zwei Karosserien. Wir haben die beiden nicht mit der Stoppuhr gegeneinander antreten lassen, und mit derselben GGUF-Datei auf demselben llama.cpp hängt das Tempo vom Build der Engine und von den Einstellungen ab, die jedes Programm wählt (Kontextgröße, wie viele Schichten auf die Grafikkarte wandern). Einen Sieger beim Tempo küren wir deshalb nicht. Wirklich auseinander gehen sie bei dem, was du nachlesen kannst, bei den Türen, die ab Werk offen stehen, und bei dem, was jeder ungefragt nach draußen schickt. Den Code von Ollama haben wir überall dort gelesen, wo er das Netz berührt; der von LM Studio ist geschlossen, da können wir nur wiedergeben, was der Hersteller angibt.

LM StudioProgramm-Datenblatt→ OllamaProgramm-Datenblatt→

	LM Studio	Ollama
Was es ist	Eine Desktop-App: suchen, herunterladen, chatten und Server in einem Fenster	Ein lokaler Server mit Kommandozeile; Desktop-App nur für macOS und Windows
Version am 24. Oktober 2026	0.4.26	0.40.10
Code	Geschlossen (Lizenzbedingungen), kostenlos privat und im Job; die Kommandozeile lms steht unter MIT	Offen, MIT
Engines	llama.cpp (GGUF) und MLX auf Apple Silicon	llama.cpp (GGUF) und MLX, Standard auf Apple Silicon
Läuft auf	Windows x64 (AVX2) und ARM64, Macs mit Apple Silicon (macOS 14 oder neuer), Linux x64 und ARM64. Keine Intel-Macs	Windows 10 22H2 oder neuer x64 und ARM64, macOS 14 oder neuer (Intel-Macs nur auf dem Prozessor), Linux amd64 und arm64
Woher die Modelle kommen	Aus der eingebauten Suche (Hugging Face), als GGUF und MLX	Aus Ollamas eigener Bibliothek (ollama pull) oder als importierte GGUF- oder safetensors-Datei
Lauscht auf	127.0.0.1:1234	127.0.0.1:11434
Passwort für die lokale API	Ab Werk keins; API-Tokens mit Rechten, wenn du Require Authentication einschaltest	Keins, und der lokale Server hat keinen Schlüssel zu prüfen
CORS ab Werk	Aus; --cors oder der Schalter Enable CORS schalten es ein	Offen für Seiten auf localhost, 127.0.0.1 und 0.0.0.0 auf jedem Port
APIs	OpenAI-kompatibel (/v1), Anthropic-kompatibel (/v1/messages) und eine eigene REST-API	Die eigene (/api), OpenAI-kompatibel (/v1) und Anthropic-kompatibel (/v1/messages)
Ohne Fenster	Der Daemon llmster (lms daemon up)	ollama serve
Standardkontext	Ein eigener, den es nicht veröffentlicht; pro Modell beim Laden einstellbar	Nach Grafikspeicher: 4.096, 32.768 oder 262.144 Tokens
Meldet sich von selbst bei	2 Dingen, laut Hersteller (geschlossener Code)	4 Arten von Anfragen mit der Desktop-App, 2 nur mit ollama serve (im Code gelesen)
Modellordner	~/.lmstudio/models	~/.ollama/models

Gleiche Engine, gleiche Modelle: Was passt, hängt nicht vom Programm ab

Ein Modell wiegt, was es wiegt. Ein GGUF in Q4_K_M belegt in LM Studio genauso viele Bytes Speicher wie in Ollama, denn ein GGUF lädt in beiden normalerweise llama.cpp. Was den Speicherbedarf verändert, ist der Kontext: Je länger das Gespräch, das sich das Modell merken muss, desto größer der Cache, den es neben den Gewichten reserviert. Und genau da treffen die beiden Programme unterschiedliche Entscheidungen für dich, wie der Abschnitt zum Kontext weiter unten zeigt.

Auf einem Mac mit Apple Silicon gibt es einen zweiten Weg. Seit Version 0.40.0 lässt Ollama jedes Modell, dessen Architektur unterstützt wird, standardmäßig über MLX laufen, und ein Tag in seiner Bibliothek kann zwei Fassungen enthalten: Der Mac lädt die MLX-Fassung, wenn es eine gibt, alle anderen Rechner die GGUF. LM Studio lässt dir die Wahl: Die Suche zeigt GGUF und MLX nebeneinander, und es hat eine eigene MLX-Engine. Seit 0.4.25 nennt LM Studio außerdem eine dritte Engine, Splash, für Macs mit M3 oder neuer ab macOS 26.4; das ist die Angabe des Herstellers, denn der Code ist geschlossen.

Ein praktischer Haken, wenn du beide behalten willst. Sie teilen sich keinen Ordner: LM Studio legt Modelle in ~/.lmstudio/models ab, Ollama in ~/.ollama/models, in seinem eigenen Schichtformat. Installierst du beide, landet jedes Modell, das du in beiden willst, zweimal auf der Platte. Bei einem 20-GB-Modell ist das so ein Detail, an das man sich an dem Tag erinnert, an dem die Platte voll ist.

Welche Modelle auf deinen Rechner passen und mit welchem Kontext, rechnet unser Modellfinder mit derselben Regel aus, egal welches der beiden du nutzt.

Eine App zum Anschauen oder ein Server zum Ansprechen

LM Studio ist zum Anschauen gebaut. Du öffnest es, suchst im Tab Discover ein Modell, lädst es herunter, lädst es in den Speicher und chattest los. Der lokale Server sitzt auf der Seite Developer und startet per Schalter oder mit lms server start im Terminal; lms wird mit der App installiert. Dazu gibt es llmster, den Kern der App ohne Fenster, für eine Linux-Kiste oder einen Server: Installiert wird er per Skript, gestartet mit lms daemon up.

Ollama ist zum Ansprechen gebaut. ollama run mit einem Modellnamen lädt das Modell herunter und öffnet einen Chat im Terminal, und im Hintergrund lauscht ein Server auf jedes Programm, das ihn nutzen will: deinen Editor, eine Chat-Oberfläche, dein eigenes Skript. Unter macOS und Windows kommt eine Desktop-App mit Chatfenster und Einstellungen dazu; unter Linux gibt es gar keine Desktop-App, nur Server und Kommandozeile. Falls dich ollama serve neugierig macht: Das ist derselbe Server, von Hand gestartet, und bei den meisten Installationen musst du es nie eintippen.

Die erste Frage lautet also nicht, welches besser ist, sondern wie du arbeiten willst. Wenn dich das Terminal nervös macht, fühlst du dich in LM Studio nach ein paar Minuten zu Hause. Wenn du ein Modell als Dienst für andere Programme willst, steht dir Ollama nicht im Weg. Wie man beide Schritt für Schritt einrichtet, steht in unserer Anleitung für LM Studio und in der für Ollama lokal.

Ollama API Key: Der lokale Server hat keinen (LM Studio schon)

Ollamas eigene Dokumentation ist eindeutig: Die lokale API unter http://localhost:11434 verlangt keine Authentifizierung. Besteht ein Werkzeug auf einem API-Key, etwa ein OpenAI-Client, gib ihm einen beliebigen Text: Ollamas Beispiele verwenden api_key='ollama' und schreiben dazu, dass er nötig ist, aber ignoriert wird. Die API-Keys, die du in einem Konto bei ollama.com anlegst, sind für Ollamas Cloud (https://ollama.com/api und /v1), nicht für den Server auf deinem Rechner.

Es gibt eine Variable, die nach Schloss klingt und keins ist. OLLAMA_AUTH lässt nur den Ollama-Client seine Anfragen signieren; im Code prüft der Server nichts. Brauchst du ein Passwort vor einem lokalen Ollama, muss es von etwas kommen, das du davorschaltest, etwa einem Reverse Proxy mit eigener Anmeldung.

LM Studio hat das seit Version 0.4.0 eingebaut. Auf der Seite Developer, unter Server Settings, schaltest du Require Authentication ein; mit Manage Tokens legst du Tokens an, jedes mit eigenen Rechten. Ab dann muss jede Anfrage Authorization: Bearer plus Token mitschicken, und der Endpunkt im Anthropic-Stil, /v1/messages, nimmt auch x-api-key. Ab Werk ist das aus, ein frisch installiertes LM Studio fragt also auch nach nichts.

Ollama Context Length – und wie LM Studio das löst

Ollama wählt den Standardkontext nach dem Grafikspeicher, den es beim Start des Servers erkennt. Im Code von 0.40.7: unter 23 GiB 4.096 Tokens, ab 23 GiB 32.768, ab 47 GiB 262.144. Die Dokumentation rundet auf 24 und 48 GiB. Der Server schreibt das Ergebnis ins Log, in eine Zeile, die vram-based default context enthält, und ollama ps zeigt den Kontext jedes geladenen Modells in der Spalte CONTEXT.

4.096 Tokens sind ein paar Seiten Text. Ein langer Chat oder eine große Code-Datei sprengt das schnell, und ab da sieht das Modell den Anfang nicht mehr. Ollama selbst empfiehlt mindestens 64.000 Tokens für Agenten, Websuche und Programmierwerkzeuge. 3 Wege, ihn zu erhöhen: der Kontext-Regler in den Einstellungen der Desktop-App, die Variable OLLAMA_CONTEXT_LENGTH beim Start des Servers (zum Beispiel OLLAMA_CONTEXT_LENGTH=32768 ollama serve) oder die Option num_ctx in jeder Anfrage.

LM Studio lässt dich entscheiden. Setzt du beim Laden das Häkchen bei Manually choose model load parameters oder nutzt lms load mit --context-length, legst du den Kontext pro Modell fest; sonst lädt es mit einem eigenen Wert, den es nicht veröffentlicht. Und --estimate-only zeigt, wie viel Speicher das Laden bräuchte, ohne etwas zu laden. Ein Schritt mehr, dafür eine Überraschung weniger.

Fernzugriff: OLLAMA_HOST=0.0.0.0 und Serve on Local Network in LM Studio

Beide lauschen ab Werk nur auf deinem eigenen Rechner: Ollama auf 127.0.0.1:11434, LM Studio auf 127.0.0.1:1234. Um sie von einem anderen Gerät zu erreichen, musst du sie bewusst öffnen.

Bei Ollama ist die Stellschraube die Variable OLLAMA_HOST=0.0.0.0:11434: unter Linux in der Zeile Environment= des Dienstes, unter macOS mit launchctl setenv, unter Windows als Umgebungsvariable deines Benutzerkontos. Die Desktop-App hat zusätzlich eine Einstellung, die dasselbe tut, ab Werk aus. Mach dir klar, was dazugehört: kein Passwort, und Ollamas Prüfung des Host-Headers jeder Anfrage greift nur, solange es auf deinem eigenen Rechner lauscht. Wer Port 11434 erreicht, kann Ollama nutzen, Modelle inklusive.

Bei LM Studio heißt der Schalter Serve on Local Network, alternativ lms server start mit --bind 0.0.0.0. Die Dokumentation warnt, dass jede Adresse außer 127.0.0.1 den Server über deinen Rechner hinaus öffnet, und empfiehlt, die Authentifizierung einzuschalten.

CORS ist die andere Tür, und hier starten die beiden an entgegengesetzten Enden. CORS entscheidet, welche Webseiten den Server aus deinem Browser heraus nutzen dürfen. Ollama akzeptiert ab Werk Seiten von localhost, 127.0.0.1 und 0.0.0.0 auf jedem Port, dazu ein paar App-Schemata (app://, file://, tauri://, vscode-webview://, vscode-file://), und antwortet jedem anderen Ursprung mit 403; Browser-Erweiterungen musst du über OLLAMA_ORIGINS hinzufügen, das der Liste Ursprünge hinzufügt und nie die eingebauten entfernt. LM Studio lässt CORS aus, solange du nicht Enable CORS einschaltest oder den Server mit --cors startest; da der Code geschlossen ist, können wir nicht sagen, ob es solche Anfragen ablehnt oder nur die Antwort verbirgt. So oder so: Das Schloss ist Require Authentication, nicht CORS.

Was jeder von sich aus nach draußen schickt

Das ist der Teil, den wir im Code gelesen haben, und hier entpuppt sich Ollama als der Gesprächigere der beiden. Mit geöffneter Desktop-App unter macOS oder Windows schickt Ollama 4 Arten von Anfragen an ollama.com, ohne dass du etwas tust: Es sucht stündlich nach Updates (die Einstellung für automatische Updates verhindert nur den Download, nie die Prüfung), holt alle 4 Stunden einen Katalog empfohlener Modelle, lädt beim Serverstart die Steckbriefe seiner Cloud-Modelle vor und fragt beim Öffnen der App bei ollama.com nach deinem Konto, ob du eins hast oder nicht. Nur mit ollama serve, wie unter Linux, bleiben die 2 Cloud-Verbindungen, und OLLAMA_NO_CLOUD=1 schaltet sie ab; mit der Desktop-App bleiben die stündliche Update-Prüfung und die Kontoabfrage, egal was du einstellst. Eine Analytics-Bibliothek steckt nirgends drin. Gezählt haben wir das am Code von 0.40.2 und seitdem jede Version bis 0.40.7 geprüft: Keine ändert etwas daran.

LM Studio sagt, es habe keine Telemetrie, und laut Hersteller gehen 2 Dinge von selbst raus: Die App sucht nach Updates (laut Datenschutzerklärung erhält der Hersteller dabei App-Version und Build, Betriebssystem und IP-Adresse), und die Inferenz-Engines aktualisieren sich selbst, seit Version 0.3.9 ab Werk an und in den App-Einstellungen abschaltbar. Die Suche in Discover fragt bei Hugging Face an, aber nur, wenn du sie benutzt. Ist das alles? Das können wir dir nicht sagen: Der Code ist geschlossen, und niemand außerhalb der Firma kann ihn zum Nachprüfen lesen. Das ist der Deal.

Die Lizenz folgt derselben Linie. Ollama steht unter MIT: Du kannst es lesen, ändern und weitergeben. LM Studio ist laut seinen Bedingungen privat und im Job kostenlos, darf aber nicht als Dienst weiterverkauft werden; die Kommandozeile lms, die SDKs und die MLX-Engine stehen unter MIT. Alle Details, jedes Ziel mit Quelle, stehen auf unseren Seiten zu Ollama und LM Studio.

Und llama.cpp oder vLLM?

llama.cpp ist die Engine unter der Haube von beiden. Direkt genutzt bekommst du jede Option und den neuesten Build am Tag seines Erscheinens, und es meldet sich von selbst bei niemandem: keine Update-Prüfung, gar nichts. Sein Server lauscht seit v0.7.0 auf 127.0.0.1:9931 (bis v0.6.0 auf 8080). Der Preis: das Terminal und der passende Build für deine Grafikkarte. Wenn dir Ollama oder LM Studio irgendwann zu eng werden, ist das der nächste Schritt, und unsere Anleitung für llama.cpp führt dich hindurch.

llama.cppProgramm-Datenblatt→

vLLM spielt in einer anderen Liga. Es ist dafür gebaut, viele Nutzer gleichzeitig von einem Linux-Rechner mit NVIDIA-Karten zu bedienen; unter Windows läuft es nur in WSL, auf dem Mac experimentell und nur auf dem Prozessor. Für eine Person mit einem Laptop ist es keine Alternative zu diesen beiden. Wenn du einen gemeinsam genutzten Server aufbaust, fang mit unserer Anleitung für vLLM an. Und für den Vergleich mit Ollama stellt unser vLLM vs. Ollama beide nebeneinander.

vLLMProgramm-Datenblatt→

Welches wir installieren würden, je nach Fall

• Du hast noch nie ein Terminal geöffnet: LM Studio. Suchen, herunterladen und chatten in einem Fenster.
• Du willst ein Modell für deinen Editor, deine Skripte oder andere Programme: Ollama. Ein Befehl, ein Server, der immer lauscht, und eine OpenAI-kompatible API.
• Du willst ein Passwort für die lokale API ohne Zusatzteile: LM Studio, mit Require Authentication.
• Du willst genau wissen, was deinen Rechner verlässt: Ollama, dessen Code man lesen kann, als ollama serve mit OLLAMA_NO_CLOUD=1; oder llama.cpp, das sich bei niemandem meldet.
• Du hast einen Mac mit Intel-Chip: Ollama, laut Ollama nur auf dem Prozessor. LM Studio gibt es dafür nicht.
• Du hast einen Linux-Server ohne Bildschirm: beide, als Ollama-Server oder als llmster von LM Studio.

Wenn nach der Installation etwas hakt, stehen die genauen Fehlermeldungen und ihre Lösung in LM Studio funktioniert nicht und Ollama funktioniert nicht.