Warum Ollama irgendwann nicht mehr reicht und was man stattdessen nutzt

Ollama ist die naheliegende erste Station, um Modelle lokal laufen zu lassen. Zwei Befehle, ollama pull llama3.1 und ollama run llama3.1, und nach etwa drei Minuten antwortet ein Modell auf dem eigenen Laptop. Keine Python-Umgebung, kein Treiberkampf, keine Konfigurationsdateien. Man nennt es das Docker der lokalen LLMs, und das trifft es: Ein Modell fühlt sich an wie eine App, die man zieht und startet.

Für Nebenprojekte, Experimente und kleine Entwicklerwerkzeuge trägt es einen monatelang. Ärger beginnt, wenn die Projekte größer werden. Anfragen werden langsam, wenn mehrere gleichzeitig eintreffen, das gewünschte Modell lädt nicht, und man wünscht sich mehr Stellschrauben. Genau dann lohnt es sich zu verstehen, was Ollama eigentlich ist, denn danach wirken die Alternativen nicht mehr wie ein großer Sprung. Nichts davon heißt, dass Ollama schlecht ist. Es heißt, dass die Aufgabe des Werkzeugs und Ihre eigene irgendwann nicht mehr zusammenpassen.

Ollama ist ein Wrapper, keine Engine

Die eigentliche Modellarbeit erledigt llama.cpp, ein C++-Programm. Ollama legt die angenehmen Teile darum: Es lädt Modelle herunter, betreibt einen Hintergrunddienst und stellt auf localhost:11434 eine API bereit, die sich wie die von OpenAI verhält. Der Wrapper ist das Produkt, und ollama pull ist wirklich schön. Wer fragt, wie man mit lokaler KI anfängt, dem empfiehlt man es immer noch zuerst.

Bequemlichkeit hat aber ihren Preis. Veröffentlichte Benchmarks sehen reines llama.cpp auf identischer Hardware oft etwa 5 bis 20 Prozent vor Ollama. Bei einem Wochenende Chatten merkt man den Unterschied nicht, wohl aber, sobald ein Projekt wächst.

Drei Grenzen, auf die Sie stoßen werden

Unter echter Last skaliert es nicht mehr

Ollama kann mehr als eine Anfrage gleichzeitig bedienen. Standardmäßig verarbeitet es bis zu vier parallel und fällt auf eine zurück, wenn der Speicher knapp ist, für leichte Nutzung also kein Problem. Die Schwachstelle ist ein gemeinsam genutztes Werkzeug. Stellen Sie sich eine interne App vor, die ein paar Kollegen im selben Moment aufrufen. Die Antwortzeiten werden nicht nur langsamer, sondern sprunghaft: Manche Antworten hängen, andere rauschen vorbei, der Durchsatz flacht ab, statt zu steigen, und eine einzige hängende Anfrage kann den ganzen Schwung aufhalten.

Kurz gesagt ist Ollama für eine Person gebaut, die mit einem Modell spricht, nicht für eine ganze Menge an Nutzern. Im Lastvergleich steigt der Durchsatz von vLLM mit mehr Nutzern weiter, während der von Ollama stagniert, und genau diese Lücke bringt Leute zum Wechsel.

Die Modellbibliothek hat Lücken

Die Registry ist kuratiert und enthält die meisten populären Modelle. Sie ist auch besser geworden, denn inzwischen lässt sich jedes GGUF mit einem Befehl direkt von Hugging Face ziehen:

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF

Ein Modelfile ist nicht nötig, und das deckt viele Fälle ab. Ein paar Lücken bleiben trotzdem. Ein Modell, das nur als safetensors ausgeliefert wird, müssen Sie selbst nach GGUF konvertieren. Ein in Shards aufgeteiltes GGUF läuft erst, wenn Sie die Teile zusammenfügen. Neue oder ungewöhnliche Modelle tauchen meist überall zuerst auf, nur nicht in der offiziellen Registry, und schnell ist ein Nachmittag damit verbracht, ein Modell vorzubereiten, das man eigentlich nutzen wollte.

AMD unter Windows

Die meisten lokalen KI-Werkzeuge setzen stillschweigend eine NVIDIA-Karte mit CUDA voraus. Eine AMD-GPU unter Windows ist so ziemlich die schlechteste Kombination für diese Welt. AMDs CUDA-Gegenstück heißt ROCm, kam spät auf Windows und läuft dort bis heute holprig. Ollama hat mit der Zeit etwas AMD-Unterstützung bekommen, doch lange kann man auf langsamer reiner CPU-Inferenz festsitzen, ohne zu ahnen, wie viel Geschwindigkeit ungenutzt bleibt. Der Ausweg war Vulkan, und das führt direkt zu den Alternativen weiter unten.

Erst tunen, dann wechseln

Erhöhen Sie zuerst das Limit für parallele Anfragen:

# On Linux/macOS
export OLLAMA_NUM_PARALLEL=4
ollama serve

Setzen Sie die Zahl so hoch, wie Ihr Speicher es erlaubt, und Sie bekommen mehr Spielraum für gleichzeitige Anfragen. Ein Produktionsserver wird Ollama dadurch nicht, aber für ein kleines Team kann es reichen, und die Änderung dauert zwei Minuten. Reicht es nicht, dann wechseln Sie.

Es gibt nicht den einen Ersatz

Kein einzelnes Werkzeug ersetzt Ollama überall, und das zu akzeptieren dauert eine Weile. llama.cpp, LM Studio und vLLM gewinnen jeweils auf ihrer eigenen Spur, die richtige Wahl hängt also von der Aufgabe ab.

llama.cpp für Tempo und Kontrolle

Da Ollama im Kern llama.cpp in hübscher Verpackung ist, besteht das einfachste Upgrade darin, direkt zur Quelle zu gehen:

llama-server -m models/qwen2.5-7b-instruct.Q4_K_M.gguf --port 8080 --ctx-size 8192

Damit bekommen Sie einen lokalen Server mit Endpunkt im OpenAI-Stil, eine im Browser eingebaute Weboberfläche und jede Einstellung in Reichweite. Außerdem ist er deutlich schlanker als Ollamas Installation mit mehreren Gigabyte.

Der Haken: Es gibt keinen Modellmanager. Sie laden GGUF-Dateien selbst herunter, legen sie in einen Ordner und richten den Server darauf aus. Das ist mehr Handarbeit, aber völlig transparent: Sie wissen immer, was läuft und wo es liegt, und das beruhigt bei allem, was in Richtung Produktion geht.

Auch für AMD-Besitzer lohnt es sich. Das Vulkan-Backend von llama.cpp war das Erste, das eine AMD-GPU unter Windows richtig nutzte, und nach Wochen im Schneckentempo auf der CPU fühlt sich der Unterschied wie Magie an.

LM Studio zum Stöbern und Testen von Modellen

Wer Modelle vergleicht, bevor er sich festlegt, ist mit LM Studio besser bedient als mit Ollama. Es hat einen Modellbrowser, der an Hugging Face angebunden ist. Sie suchen, es schlägt eine Quantisierung vor, die in Ihren RAM und VRAM passt, und Sie klicken auf Download. Kein Terminal, keine Suche nach der richtigen Datei.

Gereift ist es auch. Version 0.4.0 von Ende Januar 2026 brachte einen echten Headless-Daemon namens llmster, sodass es auf einem Server ohne Bildschirm laufen kann, dazu parallele Anfragen per Continuous Batching. Nebenläufigkeit ist keine Schwäche mehr. Auf Rechnern mit AMD- oder integrierter GPU schlägt seine Vulkan-Unterstützung Ollama zudem oft. Manchen taugt es nicht als tägliches Werkzeug, aber man öffnet es, wenn man entscheidet, welches Modell es sein soll.

vLLM für viele Nutzer oder die Produktion

Das ist das Werkzeug, das das Nebenläufigkeitsproblem tatsächlich löst. vLLM wurde fürs Serving gebaut und stützt sich auf zwei Techniken. PagedAttention verwaltet den GPU-Speicher effizient, und Continuous Batching schiebt neue Anfragen in bereits laufende Arbeit ein, statt sie warten zu lassen.

Unter Last ist der Unterschied groß. In den veröffentlichten Benchmarks von Red Hat stieg der Durchsatz von vLLM mit zusätzlichen Nutzern fast linear, während Ollama früh stagnierte und die Latenz unruhig wurde. Auf einem ausgelasteten Server entscheidet diese Lücke alles.

vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000

Läuft es einmal, bietet es einen OpenAI-kompatiblen Endpunkt, sodass die meisten Apps es direkt anstelle von Ollama verwenden können.

Der Preis ist der Einrichtungsaufwand. Sie brauchen eine ordentliche Python-Umgebung, eine NVIDIA-GPU (oder AMD über ROCm unter Linux, nicht unter Windows) und vielleicht dreißig statt drei Minuten. Für den Privatgebrauch lohnt der Aufwand nicht. Für alles mit echten Nutzern spricht kaum etwas dagegen.

Ein vernünftiges Setup für den Alltag

Eine Aufteilung, die sich in der Praxis bewährt: llama.cpp mit llama-server für die tägliche Arbeit, weil es schnell und leicht ist und volle Kontrolle gibt, alle Modelle liegen in einem Ordner. LM Studio zur Modellauswahl: öffnen, stöbern, vergleichen, herunterladen, schließen. Steht je ein Inferenzserver für die Produktion an, kommt vLLM zuerst, auch wenn eine Kiste mit Windows und AMD dafür einfach nicht der richtige Ort ist.

Ollama installiert zu lassen ist trotzdem sinnvoll. Wenn jemand lokale KI zum ersten Mal sieht, bietet nichts einen sanfteren Einstieg. Nur ist es nach etwa einem halben Jahr nicht mehr das Werkzeug für jeden Tag.

Kurze Entscheidungshilfe

• Gerade erst angefangen oder einem Freund zeigen? Bleiben Sie bei Ollama. Einfacher geht es nicht.
• Ein Rechner, und es soll schnell und voll einstellbar sein? Nehmen Sie llama.cpp und llama-server.
• Noch auf Modellsuche? Der eingebaute Browser von LM Studio macht es leicht.
• Ein Server mit echten Nutzern dahinter? vLLM, und der zusätzliche Aufwand zahlt sich aus.
• Auf einer AMD-GPU festgesteckt? Achten Sie auf Vulkan-Unterstützung, die llama.cpp und LM Studio beide haben.
• Nur Probleme mit Nebenläufigkeit? Erhöhen Sie OLLAMA_NUM_PARALLEL, bevor Sie irgendetwas anderes ändern.

Wo Ollama hingehört

Ollama ist hervorragend in dem, wofür es gemacht wurde, nämlich Menschen ganz ohne Reibung in lokale KI einsteigen zu lassen, und das ist wertvoll. Die Falle besteht darin, dass Tutorials es als Ziellinie darstellen, obwohl es eigentlich die Startlinie ist. Sobald Sie wissen, dass es ein Wrapper ist, dass seine Nebenläufigkeit für viele Nutzer nicht skaliert und dass seine Bibliothek noch Lücken hat, fühlen sich die Alternativen nicht mehr wie Rebellion an, sondern wie der nächste Schritt. Sie haben keinen Fehler in Ollama gefunden. Sie sind dem Problem entwachsen, für das es gebaut wurde.

Wenn sich lokale Modelle träge oder eingeengt anfühlen, ist der günstigste Schritt vermutlich der direkte Umstieg auf llama.cpp. ollama run gegen llama-server zu tauschen dauert etwa zwanzig Minuten, und der Geschwindigkeitsunterschied zeigt sich sofort.