Ollama oder LM Studio: Durchsatz und Antwortbeginn

Für lange Ausgaben ist LM Studio mit MLX einen Blick wert; bei kurzen, interaktiven Anfragen kann Ollamas früherer Antwortbeginn wichtiger sein. Der Apple-Silicon-Vergleich von asiai maß auf einem Mac mini M4 Pro mit 64 GB gemeinsamem Speicher Qwen3-Coder-30B nach einem Aufwärmlauf und je einem Messlauf: LM Studio mit MLX und 4-Bit-Quantisierung erreichte 102,2 gegenüber 69,8 Token pro Sekunde bei Ollama mit llama.cpp und Q4_K_M; beim ersten Token lag Ollama mit 175 gegenüber 291 Millisekunden vorn.

Diese Werte entscheiden die Softwarewahl nicht allein. Wer Modelle ohne Skript suchen, laden und ausprobieren möchte, findet bei LM Studio einen grafischen Ablauf. Ollama passt gut zu wiederkehrenden Aufrufen über die Kommandozeile; beide Programme stellen lokale Modelle auch über eine API bereit. Der veröffentlichte Geschwindigkeitsvergleich gilt für die getesteten Modellformate und Backends, nicht für jede Installation.

Warum Durchsatz und Antwortbeginn auseinanderfallen

Token pro Sekunde beschreiben, wie schnell eine Antwort nach ihrem Beginn weitergeschrieben wird. Die Zeit bis zum ersten Token umfasst dagegen die Wartezeit, bevor überhaupt Text erscheint. Eine kurze Chat-Antwort kann sich deshalb mit dem früher startenden System flüssiger anfühlen, obwohl das andere bei einer langen Codeausgabe früher fertig wäre. Welche Größe zählt, hängt von der Länge und Art der eigenen Anfragen ab.

Im veröffentlichten Versuch liefen zwei Varianten desselben Modells: eine über Ollamas llama.cpp-Backend, die andere über MLX in LM Studio. Format, Quantisierung und Backend waren damit nicht identisch. Der gemessene Vorsprung lässt sich keinem der beiden Programme als isolierte Eigenschaft zuschreiben. Hinzu kommt die geringe Zahl ausgewerteter Läufe: Eine Rangfolge für andere Modelle, Rechner oder Kontextlängen wäre daraus nicht belastbar.

Modelle finden und bedienen

LM Studio führt in der grafischen Anwendung von der Modellsuche über den Download zum Laden und Chatten. Die Einstiegshilfe von LM Studio beschreibt dafür den Bereich Discover, einen Model Loader mit optionalen Ladeparametern und die Chatansicht. Wer mehrere Varianten ausprobieren will, kann Auswahl und Speicherbelegung sehen, bevor die Unterhaltung beginnt. Eine Oberfläche ersetzt allerdings nicht die Entscheidung über Modellgröße, Quantisierung und verfügbaren Arbeitsspeicher.

Ollama bietet ebenfalls eine Desktop-Anwendung. Der Ollama-Schnellstart zeigt außerdem, wie ein lokales Modell per Terminal geladen und über den lokalen HTTP-Server angesprochen wird. Das macht Modellname und Anfrage leicht zu Bestandteilen eines Skripts. Die Trennung zwischen grafischer und befehlsorientierter Bedienung ist dennoch keine starre Produktgrenze: Ausschlaggebend ist, welcher Weg für die häufigste Aufgabe weniger Handgriffe verlangt.

Lokale API und bestehende Anwendungen

Beide Programme können als lokaler Dienst für andere Anwendungen dienen. Ollama stellt dafür seine eigene HTTP-API sowie kompatible Endpunkte bereit. Bei LM Studio lässt sich der Server in der grafischen Anwendung oder über die Kommandozeile starten; die Dokumentation des LM-Studio-Servers beschreibt REST-Zugriffe und OpenAI-kompatible Endpunkte auf localhost sowie eine mögliche Freigabe im lokalen Netzwerk.

Für einen vorhandenen Client ist „OpenAI-kompatibel“ ein Ausgangspunkt, keine Zusage vollständiger Austauschbarkeit. Entscheidend sind der tatsächlich verwendete Endpunkt, das Anfrageformat, Streaming und gegebenenfalls Funktionen wie Werkzeugaufrufe. Auch der Serverstandort gehört zur Wahl: Ein Client auf demselben Rechner kann localhost nutzen; für Zugriffe von anderen Geräten muss die Netzwerkfreigabe bewusst eingerichtet werden. Diese Integrationsfragen bleiben dieselben, selbst wenn eine der beiden Konfigurationen beim Generieren schneller ist.

Speicherbedarf und Datenschutz getrennt bewerten

Eine Modelldatei ist nur ein Teil des Speicherbedarfs. Beim Laden kommen unter anderem Arbeitsdaten und der KV-Cache für den Kontext hinzu. Im beschriebenen Benchmark belegte der Ollama-Prozess mehr Speicher; dessen konfigurierte Kontextgröße und die Vorbelegung des Caches beeinflussten diesen Messwert. Daraus folgt keine allgemeine Aussage, dass Ollama bei jedem Modell und jeder Kontextlänge mehr Speicher benötigt. Wer knappen Arbeitsspeicher hat, sollte insbesondere die tatsächlich geladene Modellvariante und das benötigte Kontextfenster vergleichen.

Die Ollama-FAQ beschreibt Einstellungen für die Kontextlänge und den Parameter keep_alive, der steuert, wie lange ein Modell nach einer Anfrage geladen bleibt. Ein bereits geladenes Modell kann schneller wieder antworten, belegt aber weiter Speicher. Ein Test nach einem Kaltstart misst deshalb etwas anderes als eine Folge von Anfragen an ein warmes Modell. Auch parallele Anfragen können den Speicherbedarf verändern.

Für vertrauliche Eingaben zählt die tatsächlich gewählte Ausführungsroute. Ollama unterscheidet lokale Modelle, deren Prompts nach Herstellerangaben nicht an Ollama übertragen werden, von Cloud-Modellen, bei denen Anfragen verarbeitet werden. Bei LM Studio sollte der verwendete Client auf den lokalen Server zeigen und dessen Netzwerkfreigabe zum Einsatzzweck passen. Die Installation einer lokalen KI-Anwendung allein sagt noch nicht, welchen Weg eine konkrete Anfrage nimmt.

Ein kurzer Vergleich auf dem eigenen Gerät

Wer zwischen den Programmen wählen muss, kann mit einem kleinen, wiederholbaren Test die offenen Fragen für den eigenen Einsatz beantworten. Wichtig ist, die Betriebsbedingungen festzuhalten: Ein identischer Prompt macht unterschiedliche Modellformate oder Kontextgrößen noch nicht vergleichbar. Die Ergebnisse sollten deshalb immer zusammen mit der Konfiguration betrachtet werden.

Rechner, verfügbaren Speicher, Programmversionen, Modell, Format, Quantisierung, Backend und Kontextlänge notieren. Falls keine identische Modellvariante verfügbar ist, den Unterschied ausdrücklich festhalten.
Dieselbe kurze Anfrage für den Antwortbeginn und dieselbe längere Aufgabe für den laufenden Durchsatz verwenden. Ausgabelänge und weitere Einstellungen möglichst gleich halten.
Jedes Modell zunächst laden und aufwärmen, danach die Anfragen mehrfach wiederholen. Zeit bis zum ersten Token, Token pro Sekunde und Speicherbelegung getrennt erfassen; typische Werte sind hilfreicher als ein einzelner Spitzenwert.
Die Dauer des erstmaligen Ladens separat messen. Bei gelegentlicher Nutzung kann diese Wartezeit stärker ins Gewicht fallen als ein Vorteil während einer bereits laufenden Ausgabe.

Für einen grafischen Einstieg spricht der Ablauf in LM Studio, für häufige Befehlsaufrufe der direkte Weg über Ollama. Bei langen Ausgaben verdient der Durchsatz besonderes Gewicht, bei kurzen Dialogen der Antwortbeginn. Erst die Messung mit dem vorgesehenen Modell auf dem eigenen Rechner zeigt, welche dieser Eigenschaften im Alltag den größeren Unterschied macht.

Lesen Sie auch: