vLLM, Ollama oder llama.cpp: welcher Inferenz-Server für den Unternehmenseinsatz

Lokale KI für mehrere Personen gleichzeitig?

Der AI Cube kommt mit vLLM und Open WebUI vorinstalliert und erzeugt bis zu zehn Antworten gleichzeitig, für Teams von fünf bis zwanzig Personen: ab 6.490 € netto einmalig plus AI Cube Care ab 349,90 € netto im Monat. Für mehr Last legen wir GPU-Server ab 699 € netto im Monat nach Ihrer tatsächlichen Nutzung aus oder übernehmen das Managed LLM Hosting.

AI Cube ansehen · 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. Seit Oktober 2026 ergänzt ein Abschnitt SGLang, das vierte verbreitete Serving-System (Stand 1. Oktober 2026).

Inhaltsverzeichnis

• Drei Werkzeuge, drei Ebenen
• Die drei im Überblick
• Der entscheidende Unterschied: gleichzeitige Nutzer
• llama.cpp
• Ollama
• vLLM
• SGLang als Alternative zu 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.

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.

Mehrere Personen gleichzeitig, aber keine eigene GPU?

Der Managed GPU Server läuft mit vLLM in einem deutschen Rechenzentrum, mit einem abgestimmten Modell, Open WebUI und Betrieb durch WZ-IT, ab 699 € netto pro Monat und monatlich kündbar.

Managed GPU Server ansehen · LLM Hosting ansehen

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.

SGLang als Alternative zu vLLM

SGLang liegt auf derselben Ebene wie vLLM: ein eigenständiges Serving-System für GPU-Betrieb mit vielen gleichzeitigen Anfragen. Es wird von LMSYS getragen, einer gemeinnützigen Open-Source-Organisation, und bietet eine OpenAI-kompatible Schnittstelle (SGLang-Dokumentation).

Was RadixAttention leistet. SGLang legt den KV-Cache bereits verarbeiteter Token in einem Präfixbaum ab. Beginnen mehrere Anfragen mit demselben Text, etwa demselben System-Prompt, denselben Werkzeugbeschreibungen eines Agenten oder demselben bisherigen Gesprächsverlauf, wird dieser Teil nicht neu berechnet. Das SGLang-Paper von 2023 nennt bis zu 6,4-fachen Durchsatz gegenüber den damaligen Systemen, gemessen an solchen Arbeitslasten. Die Zahl ist kein aktueller Vergleich mit vLLM: vLLM verfügt inzwischen ebenfalls über automatisches Prefix Caching.

Wo SGLang seine Stärken hat. Agenten-Workloads mit langen, wiederkehrenden Präfixen, mehrstufige Gespräche und große Verteilungen über mehrere GPUs. Neue Modelle erscheinen häufig in beiden Systemen zeitnah; die Release Notes von v0.5.20 listen etwa GLM-5.3-Flash und Qwen3.8-Flash-Next sowie Optimierungen für DeepSeek-V4 auf RTX PRO 6000.

Was im Betrieb zu beachten ist.

• Versionswechsel. Der zweiwöchige Takt bringt auch Breaking Changes. In v0.5.20 wurde unter anderem Prefill Context Parallelism v1 entfernt, und die Responses-API speichert Ergebnisse nur noch mit --enable-response-store (Release Notes).
• Treiberstand. v0.5.19 war die letzte Version mit Wheels und Images für CUDA 12. Ein Update auf v0.5.20 setzt den passenden Treiber- und CUDA-Stand voraus.
• Pauschale Geschwindigkeitsaussagen tragen nicht. Ob SGLang oder vLLM schneller ist, hängt von Modell, Quantisierung, Hardware, Version und vor allem vom Anteil gemeinsamer Präfixe ab. Belastbar ist nur ein Test mit dem Zielmodell und der eigenen Last.

Für die Frage dieses Beitrags ändert SGLang wenig: Die Grenze verläuft weiterhin zwischen dem llama.cpp-Zweig für Einzelplätze und einem Serving-System für viele gleichzeitige Nutzer. SGLang ist eine zweite Option auf der Serving-Seite, kein Ersatz für die Frage nach der tatsächlichen Parallelität.

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

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.

Noch unklar, welches Werkzeug passt? Der KI-Potenzialcheck prüft an einem konkreten Ablauf, welcher Ansatz trägt, und endet mit einer Pilotempfehlung. Ab 3.900 € netto.

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
• GPU und VRAM für LLMs dimensionieren - KV-Cache, Kontextlänge und FP8-KV-Cache

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

• vLLM auf GitHub
• Ollama auf GitHub
• llama.cpp auf GitHub
• vLLM: Dokumentation
• Open WebUI: Dokumentation
• SGLang auf GitHub
• SGLang: Release v0.5.20
• SGLang: Dokumentation
• Zheng et al.: SGLang, Efficient Execution of Structured Language Model Programs
• vLLM: Automatic Prefix Caching
• LMSYS: About