vLLM, Ollama oder llama.cpp: welcher Inferenz-Server für den Unternehmenseinsatz
Hinweis zum Inhalt: Die Informationen in diesem Artikel wurden nach bestem Wissen zum Zeitpunkt der Veröffentlichung zusammengestellt. Technische Details, Preise, Versionen, Lizenzmodelle und externe Inhalte können sich ändern. Bitte prüfen Sie die genannten Angaben eigenständig, insbesondere vor geschäftskritischen oder sicherheitsrelevanten Entscheidungen. Dieser Artikel ersetzt keine individuelle Fach-, Rechts- oder Steuerberatung.
Lokale KI für mehrere Personen gleichzeitig? WZ-IT liefert mit dem AI Cube vLLM und Open WebUI vorinstalliert, legt GPU-Server nach tatsächlicher Nutzerzahl aus oder übernimmt das Managed LLM Hosting. Auslegung gemeinsam klären
Die Frage nach dem richtigen Inferenz-Server wird fast immer als Geschwindigkeitsfrage gestellt und fast immer falsch beantwortet, weil eine Größe fehlt: wie viele Personen gleichzeitig arbeiten.
Für einen einzelnen Nutzer liegen die drei verbreiteten Werkzeuge dicht beieinander. Bei zehn gleichzeitigen Anfragen trennen sie sich um Faktoren, nicht um Prozente. Wer die Auswahl nach Einzelnutzer-Messungen trifft und dann ein Team darauf arbeiten lässt, hat eine Anschaffung getätigt, die im Alltag nicht trägt.
Dieser Beitrag ordnet die drei entlang dieser Größe ein. Alle Angaben aus den Repositories, Stand 24. August 2026.
Inhaltsverzeichnis
- Drei Werkzeuge, drei Ebenen
- Die drei im Überblick
- Der entscheidende Unterschied: gleichzeitige Nutzer
- llama.cpp
- Ollama
- vLLM
- Was wir im AI Cube ausliefern und warum
- Welches Werkzeug wofür
- Was ein Durchsatzvergleich nicht beantwortet
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Drei Werkzeuge, drei Ebenen
Der häufigste Fehler in Vergleichen ist, die drei nebeneinanderzustellen, als wären sie austauschbar. Sie liegen auf verschiedenen Ebenen:
llama.cpp ist die Engine. Sie führt das Modell aus, arbeitet auf CPU und GPU und ist das Fundament, auf dem vieles andere aufsetzt.
Ollama ist die Bedienschicht. Es nutzt llama.cpp und legt eine bequeme Verwaltung darüber: Modelle herunterladen, starten, ansprechen. Der Vergleich zwischen Ollama und llama.cpp vergleicht damit eine Hülle mit ihrem Inhalt.
vLLM ist ein eigenständiges Serving-System. Es baut nicht auf llama.cpp auf, sondern verfolgt einen anderen Ansatz, der auf GPU-Betrieb mit vielen gleichzeitigen Anfragen ausgelegt ist.
Daraus folgt: Die eigentliche Entscheidung liegt zwischen dem llama.cpp-Zweig und vLLM. Ob man llama.cpp direkt anspricht oder über Ollama, ist eine Frage der Bequemlichkeit.
Die drei im Überblick
Angaben aus den öffentlichen Repositories, Stand 24. August 2026.
| Werkzeug | GitHub-Sterne | Lizenz | Ebene | Ausgelegt auf |
|---|---|---|---|---|
| Ollama | 179.309 | MIT | Bedienschicht | Einzelplatz, schneller Einstieg |
| llama.cpp | 125.380 | MIT | Engine | CPU und GPU, maximale Kontrolle |
| vLLM | 89.860 | Apache-2.0 | Serving-System | GPU, viele gleichzeitige Anfragen |
Alle drei sind uneingeschränkt quelloffen und werden aktiv entwickelt. Die Sternezahlen bilden Bekanntheit ab, nicht Eignung: Ollama ist am bekanntesten, weil es der einfachste Einstieg ist, nicht weil es für den Produktivbetrieb die beste Wahl wäre.
Der entscheidende Unterschied: gleichzeitige Nutzer
Hier trennen sich die Werkzeuge, und zwar nicht graduell.
Veröffentlichte Vergleiche nennen für vLLM bei Parallellast Faktoren von zehn und mehr gegenüber dem llama.cpp-Zweig. Der Grund ist keine bessere Implementierung derselben Sache, sondern ein anderes Verfahren: vLLM fasst gleichzeitig eintreffende Anfragen zusammen und verarbeitet sie gemeinsam, statt sie nacheinander abzuarbeiten.
Bei einem Nutzer verschwindet dieser Vorteil weitgehend. Dort ist llama.cpp direkt genutzt sogar etwas schneller als Ollama, weil Ollama als Hülle Aufwand hinzufügt, in der Größenordnung eines niedrigen zweistelligen Prozentsatzes.
Praktische Folge: Der Sprung von einem auf zehn Nutzer ist kein Skalierungsproblem, das man mit mehr Hardware löst. Er ist eine Architekturfrage. Ein Aufbau, der für eine Person gut funktioniert, wird für ein Team nicht durch eine größere Grafikkarte gut, sondern durch ein anderes Serving-Verfahren.
Deshalb ist die Frage vor jeder Hardwarebeschaffung: Wie viele Personen arbeiten tatsächlich gleichzeitig? Nicht wie viele Zugang bekommen sollen. Die beiden Zahlen unterscheiden sich in der Regel um eine Größenordnung.
llama.cpp
Die Engine unter vielem anderen, unter MIT, mit 125.380 Sternen. Läuft auf CPU, auf GPU und auf Apple-Silicon-Hardware und ist die richtige Wahl überall dort, wo keine GPU zur Verfügung steht.
Stärke: läuft praktisch überall, geringster Ressourcenbedarf, größte Kontrolle über Einstellungen. Wer eingebettete Systeme bedient oder nur CPUs hat, kommt hier hin.
Grenze: keine Verwaltungsschicht, keine Modellverwaltung, kein Mehrbenutzerbetrieb im eigentlichen Sinne.
Ollama
Die verbreitetste der drei mit 179.309 Sternen, unter MIT. Installation und erstes Modell dauern Minuten, die Bedienung ist an Container-Werkzeuge angelehnt.
Stärke: der mit Abstand einfachste Einstieg. Für Entwicklung, Vorführungen und die Frage "taugt ein lokales Modell für unseren Fall überhaupt" ist Ollama das richtige Werkzeug.
Grenze: Es bleibt eine Bedienschicht über llama.cpp und erbt dessen Verhalten bei gleichzeitigen Anfragen. Für ein Team, das parallel arbeitet, ist es die falsche Grundlage, und das merkt man erst im Betrieb.
vLLM
Unter Apache-2.0, 89.860 Sterne, gebaut für GPU-Serving. Bietet eine OpenAI-kompatible Schnittstelle, wodurch Anwendungen meist ohne Änderung anschließen.
Stärke: der einzige der drei, der für viele gleichzeitige Anfragen ausgelegt ist. Dort liegen die Faktoren, nicht die Prozente.
Grenze: braucht praktisch eine GPU, ist aufwendiger einzurichten als Ollama und für einen einzelnen Nutzer überdimensioniert. Wer nur ausprobieren will, fängt nicht hier an.
Was wir im AI Cube ausliefern und warum
Im AI Cube liefern wir vLLM zusammen mit Open WebUI vorinstalliert aus. Diese Entscheidung folgt direkt aus dem Zweck des Geräts: Es steht in einem Unternehmen und wird von mehreren Personen genutzt.
Mit Ollama wäre die Einrichtung einfacher gewesen und das Gerät im Alltag schlechter. Die Erfahrung dahinter ist unspektakulär: Ein Aufbau, der beim Test durch eine Person überzeugt, enttäuscht bei fünf gleichzeitigen Anfragen, und dann steht die Anschaffung in Frage, nicht die Softwarewahl.
Open WebUI liegt als Oberfläche darüber, weil Nutzer eine Chat-Oberfläche mit Rechten, Wissensbereichen und Verlauf erwarten, keine Programmierschnittstelle. Wie sich das mit Wissensquellen verbindet, gehört zur Einrichtung und nicht zum Inferenz-Server.
Welches Werkzeug wofür
| Ausgangslage | Naheliegende Wahl | Begründung |
|---|---|---|
| Erster Versuch, taugt lokale KI überhaupt | Ollama | Minuten bis zum ersten Ergebnis |
| Ein Nutzer, dauerhafte Nutzung, GPU vorhanden | Ollama oder llama.cpp | Vorteil von vLLM greift nicht |
| Keine GPU, nur CPU oder eingebettetes System | llama.cpp | einziges, das dort sinnvoll läuft |
| Team ab etwa fünf gleichzeitigen Nutzern | vLLM | um Faktoren höherer Durchsatz bei Parallellast |
| Produktive Anwendung mit Nutzerverwaltung | vLLM plus Open WebUI | Serving und Oberfläche getrennt |
Was ein Durchsatzvergleich nicht beantwortet
Passt das Modell überhaupt in den Speicher? Die Wahl des Serving-Systems ist nachrangig gegenüber der Frage, ob Modell und Kontextlänge in den verfügbaren GPU-Speicher passen. Ein zu großes Modell wird durch kein Serving-Verfahren schnell.
Wie lang sind die Kontexte? Lange Eingaben, etwa bei Dokumentenrecherche, verbrauchen Speicher pro gleichzeitiger Anfrage. Die Zahl der parallel bedienbaren Nutzer sinkt damit erheblich, und das wird bei der Dimensionierung regelmäßig übersehen.
Wer aktualisiert Modelle und Serving-Schicht? Beide entwickeln sich schnell. Ein Aufbau, der ein Jahr nicht angefasst wird, läuft weiter, verliert aber den Anschluss an neue Modelle.
Was passiert bei Ausfall der GPU? Ein lokales KI-System ohne Ausweichpfad ist bei Hardwaredefekt vollständig aus. Ob das hinnehmbar ist, gehört vor die Anschaffung geklärt.
Unser Vorgehen bei WZ-IT
Wir fragen vor der Werkzeugwahl nach der Zahl der gleichzeitigen Nutzer, und zwar nachdrücklich, weil die erste Antwort fast immer die Zahl der Zugangsberechtigten ist. Aus dieser Zahl folgt das Serving-Verfahren, daraus die Hardware, und erst danach das Modell.
Für Versuchsaufbauten und die Frage nach der grundsätzlichen Eignung nutzen wir selbst Ollama, weil es dafür das schnellste Werkzeug ist. Was produktiv geht, läuft auf vLLM.
Was wir nicht tun, ist ein Ollama-Setup zu vergrößern, wenn die Nutzerzahl steigt. Der Wechsel gehört gemacht, bevor die Wartezeiten auffallen, nicht danach.
Weiterführende Guides
- AI Cube - lokale KI mit vLLM und Open WebUI vorinstalliert
- GPU-Server - Auslegung nach tatsächlicher Nutzerzahl
- LLM-Hosting - betreute Modelle ohne eigene Hardware
- vLLM, Ollama und Open WebUI - die Komponenten im Einzelnen
- Lokalen KI-Server nach Nutzern dimensionieren - die Rechnung dahinter
Unklar, wie viele Personen Ihre geplante Hardware trägt? Wir rechnen es anhand Modell, Kontextlänge und gleichzeitiger Nutzung durch, bevor etwas beschafft wird. Termin vereinbaren
Quellen
Lokale KI für mehrere Nutzer auslegen
Wir dimensionieren Hardware, Modell und Inferenz-Server nach Ihrer tatsächlichen Nutzerzahl und übernehmen den Betrieb.
Häufig gestellte Fragen
Antworten auf wichtige Fragen zu diesem Thema
Sie liegen auf verschiedenen Ebenen. llama.cpp ist eine Inferenz-Engine, Ollama eine Bedienschicht darüber, die llama.cpp nutzt, und vLLM ein eigenständiges Serving-System für GPU-Betrieb. Ollama und llama.cpp gegeneinander zu stellen vergleicht deshalb eine Hülle mit ihrem Inhalt.
Weil es für gleichzeitige Anfragen gebaut ist und diese zusammenfasst, statt sie nacheinander abzuarbeiten. Veröffentlichte Vergleiche nennen für Parallellast Faktoren von zehn und mehr gegenüber den anderen beiden. Bei einem einzelnen Nutzer verschwindet dieser Vorteil weitgehend.
Für kleine Gruppen mit gelegentlicher Nutzung funktioniert das. Sobald mehrere Personen gleichzeitig arbeiten, wird die Wartezeit spürbar, weil Anfragen nacheinander bedient werden. Der Wechsel auf vLLM ist dann kein Feinschliff, sondern der eigentliche Unterschied zwischen brauchbar und unbrauchbar.
vLLM steht unter Apache License 2.0, Ollama und llama.cpp unter MIT. Alle drei sind uneingeschränkt quelloffen ohne abgetrennte proprietäre Bestandteile.
Praktisch ja. vLLM ist auf GPU-Serving ausgelegt, und sein Vorteil entsteht aus Verfahren, die GPU-Speicher effizient nutzen. Für reinen CPU-Betrieb ist llama.cpp die richtige Wahl.
Direkt genutzt ja, um einen niedrigen zweistelligen Prozentsatz, weil Ollama als Hülle etwas Aufwand hinzufügt. Für einen einzelnen Nutzer ist dieser Unterschied im Alltag kaum spürbar und wiegt die einfachere Bedienung von Ollama selten auf.
Ollama, ohne Zögern. Installation und erstes Modell sind eine Sache von Minuten. Der Fehler ist nicht, damit anzufangen, sondern damit produktiv zu gehen, ohne die Nutzerzahl geprüft zu haben.
Nein, und die meisten Teams tun es nicht. Ollama für Entwicklung und Vorführungen, vLLM für den produktiven Betrieb ist eine verbreitete und sinnvolle Aufteilung.
Wenig, wenn die Anwendung über eine OpenAI-kompatible Schnittstelle spricht, denn beide bieten eine solche an. Zu prüfen sind Modellnamen, Formatunterschiede bei Quantisierung und das Verhalten bei langen Kontexten.
vLLM, zusammen mit Open WebUI als Oberfläche. Die Entscheidung folgt aus dem Einsatzzweck: Ein Gerät für ein Team muss mehrere gleichzeitige Anfragen bedienen, und genau dafür ist vLLM gebaut.
Geschrieben von
Timo Wevelsiep
Co-Founder & CEO
Co-Founder von WZ-IT. Spezialisiert auf Cloud-Infrastruktur, Open-Source-Plattformen und Managed Services für KMUs und Enterprise-Kunden weltweit.
LinkedInLassen Sie uns über Ihre Idee sprechen
Ob konkrete IT-Herausforderung oder einfach eine Idee - wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.
Rückruf vereinbaren
Unternehmen weltweit vertrauen WZ-IT
