Ollama, llama.cpp oder vLLM: die richtige Engine wählen

Ollama, llama.cpp oder vLLM: welche Engine brauche ich?

Die Wahl folgt zwei Fragen: Wie viele Menschen arbeiten gleichzeitig auf dem Modell, und passt das Modell ganz in den Grafikspeicher? Für die einzelne Person ist Ollama die bequemste Lösung. Reicht der Grafikspeicher knapp, versorgt llama.cpp ein ganzes Team und holt per Auslagerung das grösstmögliche Modell aus der Hardware. Passt das Modell bequem hinein und rechnen viele darauf, ist vLLM dafür gebaut.

Das Wichtigste in Kürze

• Beantworten Sie vor der Werkzeugwahl zwei Fragen: Wie viele Menschen arbeiten gleichzeitig auf dem Modell, und passt es ganz in Ihren Grafikspeicher? Zwischen richtiger und falscher Antwort lagen bei uns 0.9 und 62 Sekunden Wartezeit.
• Betreiben Sie keinen Mehrbenutzer-Dienst auf Ollama, und beurteilen Sie Ihre Hardware nicht danach. Es arbeitete Anfragen nacheinander ab, jemand wartete 62 Sekunden.
• Für den Einzelplatz gilt das Umgekehrte: Dort lieferte Ollama die erste Antwort nach 0.9 Sekunden und war damit die angenehmste Wahl.
• Wollen Sie das grösstmögliche Modell auf kleiner Hardware, führt der Weg über llama.cpp. Nur dort liegen die Experten eines MoE?MoEMixture of Experts: ein Modell, das viele Teilmodelle («Experten») speichert, pro Token aber nur wenige davon rechnet. Gespeichert werden alle Parameter, gerechnet wird mit einem Bruchteil.-Modells im Arbeitsspeicher.
• Prüfen Sie vor der Wahl von vLLM oder SGLang, ob Ihr Modell unterstützt ist. Unser Hybridmodell startete auf SGLang gar nicht.

Dieselbe Modelldatei, dieselbe RTX 4090, ein Nutzer: Ollama liefert 43.8 Tokens pro Sekunde, llama.cpp 43.4. Praktisch identisch. Dieselbe Datei, dieselbe Karte, vier Nutzer: Ollama fällt auf 38.7, llama.cpp steigt auf 125.1.

Diese zwei Messungen zeigen die erste Achse der Wahl: die Zahl gleichzeitiger Nutzer. Die zweite Achse ist Ihr Grafikspeicher im Verhältnis zum Wunschmodell, und dort stehen sich die beiden grossen Engines gegenüber. vLLM ist für Maschinen gebaut, in deren Grafikspeicher das Modell bequem passt, und verwandelt den Überschuss in Durchsatz. llama.cpp ist für die Gegenrichtung gebaut und holt aus knappem Grafikspeicher das grösstmögliche Modell heraus.

Die Engine ist dabei die Software, die ein Modell lädt, Anfragen entgegennimmt und die Grafikkarte auslastet. Auf die Klugheit der Antworten hat sie keinen Einfluss. Wir haben drei Werkzeuge auf derselben Hardware vermessen, dazu einen Spezialisten, der es nicht bis zur Messung geschafft hat.

Dies ist der vierte Teil unserer Serie über lokale Inferenz. Nach Maschine, Speicher und Quantisierung geht es um die Software, die das Modell ausliefert.

Für den Einzelplatz: Ollama

Ollama installiert sich in Minuten, lädt Modelle mit einem Befehl und legt unter der Haube dieselbe Maschine an wie llama.cpp, dessen Rechenkerne es verwendet. Die identischen 43.8 gegen 43.4 Tokens pro Sekunde bei einem Nutzer sind der Beleg: gleiche Kerne, gleiche Quantisierung, gleiche Karte.

Für die Person, die allein damit arbeitet, ist es sogar die schnellste Wahl: Die erste Antwort kam nach 0.92 Sekunden, bei llama.cpp mit unseren Server-Einstellungen erst nach 3.65.

Mit dem zweiten gleichzeitigen Nutzer beginnt das Problem:

Bei vier gleichzeitigen Nutzern verliert Ollama sogar leicht Durchsatz, und die Wartezeit bis zum ersten Zeichen springt von 0.92 auf 62 Sekunden. Das ist das Muster einer Warteschlange: Der vierte Nutzer wartet, bis die ersten drei fertig sind. llama.cpp, mit vier Slots konfiguriert, schiebt dieselben vier Anfragen gemeinsam durch die Karte.

Wir haben auch die Einstellung geprüft, die die Dokumentation dafür anbietet. Mit OLLAMA_NUM_PARALLEL=4 blieb der Durchsatz bei vier Nutzern unverändert (38.6 Tokens pro Sekunde), und der Einzelnutzer wurde deutlich langsamer (26.6 statt 43.8). Möglicherweise teilten sich dabei die vier Slots den eingestellten Kontext, was die Verschlechterung erklären würde; sicher sagen können wir nur: Mit den Mitteln, die die Dokumentation anbietet, liess sich das Verhalten nicht auf das Niveau von llama.cpp bringen.

Ollama ist damit nicht langsam, es ist ein Einzelplatzwerkzeug. Für genau diesen Platz ist es gut.

Für den kleinen Server: llama.cpp

llama.cpp ist die Maschine, die in Ollama steckt, ohne den Komfort und ohne dessen Grenzen: ein einzelnes Programm, das GGUF-Dateien lädt, eine OpenAI-kompatible Schnittstelle anbietet und Anfragen bündelt. Der Server war in unseren Läufen rund fünf Sekunden nach dem Start bereit, was Modellwechsel und Experimente flüssig macht.

Zwei Fähigkeiten machen es zur ersten Wahl für ein kleines Team mit einem eigenen Server.

Es bündelt. Die 125.1 Tokens pro Sekunde bei vier Nutzern aus der Grafik oben sind fast das Dreifache des Einzelnutzers, auf einer einzelnen Karte, und die Wartezeit blieb bei 8.1 Sekunden, wo Ollama dieselben vier Nutzer 62 warten liess.

Es holt aus knappem Grafikspeicher das grösste Modell. llama.cpp legt die selten gebrauchten Experten eines MoE-Modells gezielt in den Arbeitsspeicher (--n-cpu-moe, ausführlich in Teil 2). Damit lief bei uns ein 35-Milliarden-Modell in 4.5 GB Grafikspeicher, und ein 284-Milliarden-Modell mit 9.6 Tokens pro Sekunde auf zwei Consumer-Karten. vLLM kennt zwar ebenfalls eine Auslagerung, aber eine undifferenzierte: 8 GB eines Dense-Modells auszulagern kostete dort Faktor 22 beim Tempo. Von den drei Werkzeugen bietet nur llama.cpp diesen brauchbaren Handel.

Der Preis: Man konfiguriert selbst. Kontextlänge, Parallelität, Offload und Flash-Attention stehen als Flags in Ihrer Verantwortung, und die Voreinstellungen sind selten die richtigen. Die Kommandos, mit denen unsere Messungen liefen, stehen im Anhang.

Für den Betrieb: vLLM

vLLM ist für den Fall gebaut, in dem das Modell bequem in den Grafikspeicher passt und die Karte nie leer läuft: viele Nutzer, lange Eingaben, Dauerbetrieb. Es fährt kontinuierliches Batching (neue Anfragen steigen mitten in laufende Berechnungen ein), liest AWQ- und FP8-Formate und verwaltet den KV-Cache seitenweise.

Auf zwei Karten mit realistischer Last (10’000 Tokens Eingabe, 2’000 Ausgabe):

Bei vier Nutzern liefert vLLM das Doppelte von llama.cpp, bei acht bleiben 46 Prozent Vorsprung. Die Gegenrechnung: Beim Einzelnutzer wartete man auf das erste Zeichen 3.5 Sekunden gegen 0.6 bei llama.cpp, und der erste Start dauerte Minuten, weil vLLM seine Kernel kompiliert, wo llama.cpp nach fünf Sekunden bereit war.

Den grössten Trumpf spielt vLLM bei Lasten, die sich einen Kontext teilen, also bei RAG und Agenten mit festem Systemprompt. Sein Prefix-Caching liest den geteilten Teil nur einmal: In unserer Messung mit 8’000 Tokens geteiltem Kontext und acht Nutzern fiel die Wartezeit von 17.9 auf 0.9 Sekunden, Faktor 19 durch einen Schalter.

Der Spezialist, der nicht startete: SGLang

SGLang ist auf geteilte Kontexte spezialisiert und wäre für Agenten-Lasten der vierte Kandidat gewesen. Auf unserem Modell kam es nie so weit: Der Start scheiterte an einem seit Juli offenen Fehler mit Hybridmodellen (GitHub-Issue #30178); der dokumentierte Workaround behob den ersten Absturz, danach blieb die erste Anfrage in einem Timeout hängen.

Das ist kein Urteil über SGLang, auf reinen Attention-Modellen berichten andere gute Zahlen. Es ist ein Urteil über Werkzeugreife bei neuen Architekturen: Je neuer die Modellbauart, desto kleiner die Auswahl an Engines, die sie tatsächlich tragen. Prüfen Sie die Kombination aus Modell und Engine, bevor Sie eine der beiden festlegen.

Die Zuordnung

Ihre Situation	Werkzeug	Der Messwert dahinter
Eine Person, eigener Rechner	Ollama	erste Antwort nach 0.9 s, Tempo identisch mit llama.cpp
Kleines Team, ein Server	llama.cpp	verdreifacht den Durchsatz bei vier Nutzern, startet in 5 s
Modell grösser als der Grafikspeicher	llama.cpp	35 Milliarden Parameter in 4.5 GB, 284 Milliarden auf zwei Karten
Modell passt bequem, viele Nutzer	vLLM	240 Tokens pro Sekunde bei acht Nutzern
RAG und Agenten mit festem Kontext	vLLM mit Attention-Modell	Wartezeit um Faktor 19 gesenkt

Die Zuordnung ist keine Rangliste, jedes der drei Werkzeuge hat den Fall, in dem es die anderen schlägt. Der Fehlgriff kostete in unseren Messungen 62 Sekunden Wartezeit, auf einer Karte, die eine Sekunde konnte.

So starten Sie

1. 01

   Mit Ollama das Modell prüfen

   Für die Frage, ob das Modell Ihre Aufgaben kann, ist der Einzelplatz genau richtig. Diese Prüfung kostet einen Nachmittag und braucht keinen Server.

2. 02

   Für den Team-Test auf llama.cpp wechseln

   Dieselbe GGUF-Datei läuft dort weiter. Setzen Sie Kontextlänge und Parallelität bewusst, die Startkommandos aus dem Anhang sind ein geprüfter Ausgangspunkt.

3. 03

   Vor dem Dauerbetrieb vLLM gegen Ihre Last messen

   Mit dem eingebauten Benchmark (vllm bench serve) und Ihrer echten Eingabelänge, denn ohne sie ist die Frage nach der tragbaren Nutzerzahl nicht beantwortbar.

4. 04

   Engine-Version festhalten

   Unsere erste Messrunde lief versehentlich auf einer acht Minor-Versionen alten vLLM-Installation. Wer misst, notiert zuerst die Version, sonst misst er die Vergangenheit.

Bleibt die Frage, was der ganze Aufbau kostet und wann er sich rechnet. Sie beantwortet der fünfte und letzte Teil der Serie.

Testen Sie lokale KI gerade mit Ollama? Für eine einzelne Person ist das die richtige Wahl.

Sobald ein Team darauf zugreift, ändert sich das Bild grundlegend, und viele Pilotprojekte scheitern genau an dieser Stelle, ohne dass jemand die Ursache sieht.

Gemessen mit derselben Modelldatei auf derselben RTX 4090: Bei einem Nutzer liefern Ollama und llama.cpp praktisch identische 43.8 und 43.4 Tokens pro Sekunde, denn in Ollama steckt llama.cpp. Bei vier gleichzeitigen Nutzern sind es 38.7 gegenüber 125.1, und der vierte Nutzer wartet 62 statt 8 Sekunden auf das erste Zeichen. Ollama arbeitet die Anfragen nacheinander ab, llama.cpp bündelt sie.

Unser Schluss: Wer den Teambetrieb mit Ollama testet, beurteilt nicht seine Hardware, sondern eine Warteschlange. So entsteht der Eindruck, KI im eigenen Haus sei zu langsam, obwohl die Karte kaum ausgelastet ist.

Im Beitrag stehen alle Messwerte, die fertigen Startkommandos und der Fall, in dem vLLM bei geteiltem Kontext den Faktor 19 herausholt. Link in den Kommentaren.

#KI #LLM #Ollama #vLLM