← Ratgeber

AuswahlStand René HerzerMit KI erstellt

Ollama und Open WebUI skalieren: Was sich ändert, wenn viele Personen fragen

Ollama und Open WebUI wachsen nicht von selbst mit. Ollama bearbeitet ab Werk eine Anfrage je Modell gleichzeitig; für viele Personen setzen Häuser meist Software wie vLLM ein, die Anfragen bündelt. Open WebUI braucht für mehrere Instanzen PostgreSQL statt SQLite, Redis, eine eigene Vektordatenbank und gemeinsamen Dateispeicher. Aus einer Installation wird so ein verteiltes System mit fünf oder mehr Diensten, das jemand dauerhaft betreibt.

Warum stößt der Test an Grenzen?

Ein Test mit Ollama und Open WebUI läuft oft auf einem Rechner: Ollama führt das Modell aus, Open WebUI speichert Konten, Chats und Dokumente in eingebauten SQLite-Datenbanken. Für zehn Personen funktioniert das gut. Wächst die Zahl, zeigen sich zwei Engpässe: das Modell, das Anfragen nacheinander abarbeitet, und die Oberfläche, die als einzelner Prozess mit lokaler Datenbank gebaut ist.

Was begrenzt Ollama?

Laut Dokumentation bearbeitet Ollama ab Werk eine Anfrage je Modell gleichzeitig (OLLAMA_NUM_PARALLEL), weitere warten in einer Schlange von bis zu 512. Mehr Parallelität lässt sich einstellen. Der Speicher dafür wächst mit der Zahl gleichzeitiger Anfragen mal Kontextlänge: Vier Anfragen mit je 8.000 Tokens Kontext brauchen so viel Speicher wie eine mit 32.000.

Red Hat hat Ollama und vLLM im August 2025 auf demselben Grafikprozessor mit 1 bis 256 gleichzeitigen Personen verglichen. vLLM erreichte in der Spitze 793 Tokens pro Sekunde, Ollama 41; auch mit 32 parallelen Anfragen blieb Ollama zurück. Red Hat ordnet Ollama für einzelne Personen ein und vLLM für viele gleichzeitige Anfragen. Der Test galt einem kleinen Modell auf einer Karte; andere Messungen zeigen kleinere Abstände.

Was ändert sich mit vLLM?

vLLM ist Open-Source-Software unter Apache 2.0, die Anfragen laufend bündelt und den Speicher für Gespräche in Blöcken verwaltet. Dafür ist sie anspruchsvoller: Sie läuft auf Linux mit Grafikprozessoren, Modell, Speicheraufteilung, Kontextlänge und Format für Werkzeugaufrufe müssen passend eingestellt sein. Für mehrere Grafikprozessoren oder Server kommen Aufteilung des Modells und Lastverteilung dazu. Wie viele Fragen ein Server gleichzeitig schafft, hängt vom Modell und der Länge der Gespräche ab; belastbar ist nur ein Lasttest mit Ihren Aufgaben.

Was braucht Open WebUI für viele Personen?

Die Dokumentation von Open WebUI beschreibt für mehrere Prozesse oder Instanzen:

Baustein Im Test Für viele Personen
Datenbank SQLite, eingebaut PostgreSQL, extern; SQLite wird für mehrere Instanzen nicht unterstützt
Gemeinsamer Zustand keiner Redis, für Einstellungen, Sitzungen und Websockets
Vektordatenbank für die Dokumentensuche Chroma, eingebaut eigener Dienst, etwa PGVector, Qdrant oder Milvus; eingebautes Chroma ist für mehrere Prozesse nicht sicher
Dateien lokales Verzeichnis gemeinsamer Speicher oder Objektspeicher
Texte aus Dokumenten eingebaute Auslese eigener Dienst wie Tika oder Docling
Geheimer Schlüssel je Installation auf allen Instanzen gleich

Für kleine Teams unter 50 Personen empfiehlt die Dokumentation PostgreSQL und Redis, ab mehreren Prozessen, mehreren Instanzen oder über 1.000 Personen sind sie zusammen mit einer externen Vektordatenbank erforderlich.

Was heißt das für den Betrieb?

Aus zwei Programmen werden fünf bis acht Dienste: Modell-Server, Oberfläche, PostgreSQL, Redis, Vektordatenbank, Dateispeicher, Dienst zum Auslesen von Dokumenten, davor ein Lastverteiler mit Zertifikat. Jeder braucht Updates, Überwachung, Sicherung und einen Plan für Störungen. Dazu kommen Lasttests, wenn ein neues Modell oder eine neue Version kommt. Wie ein Ablauf für Sicherheitsupdates aussieht, beschreibt der Ratgeber Sicherheitsupdates für einen selbstgebauten KI-Stack; was das an Personal bindet, rechnet KI selbst betreiben oder Plattform kaufen durch.

Wie geht das mit basebox?

basebox nutzt vLLM für das KI-Modell und verteilt die Anfragen automatisch auf die Grafikprozessoren. Je nach Klasse beantwortet ein Server 100, 150 oder über 200 Fragen im selben Moment, mit einem Antwortbeginn unter 2 Sekunden; weitere Anfragen werden der Reihe nach verteilt. Für mehr als 2.000 Personen richten wir basebox auf größeren oder mehreren Servern ein; Apps, Rechte und Anbindung bleiben gleich. In der Cloud übernehmen wir Betrieb und Updates. Steht bei Ihnen schon Hardware mit Grafikprozessoren, prüfen wir vorher kostenlos, ob sie reicht.

Hinweis: Angaben zu Ollama, vLLM und Open WebUI nach deren Dokumentation und dem genannten Test, Stand 11. Oktober 2026. Die Software ändert sich schnell; prüfen Sie die aktuelle Dokumentation Ihrer Version.

Häufige Fragen

Reicht es, OLLAMA_NUM_PARALLEL hochzusetzen?

Es hilft, aber begrenzt. Der Speicherbedarf wächst mit der Zahl gleichzeitiger Anfragen mal Kontextlänge. Im Test von Red Hat legte Ollama auch mit 32 parallelen Anfragen weniger zu als vLLM. Für ein ganzes Haus ist Software für viele gleichzeitige Anfragen üblich.

Ab wie vielen Personen braucht Open WebUI externe Dienste?

Die Dokumentation empfiehlt PostgreSQL und Redis schon für kleine Teams unter 50 Personen. Ab mehreren Prozessen, mehreren Instanzen oder über 1.000 Personen nennt sie PostgreSQL, Redis und eine externe Vektordatenbank als erforderlich.

Wie viele Personen fragen gleichzeitig?

Deutlich weniger, als Konten angelegt sind. Wer eine Stunde mit KI arbeitet, beschäftigt den Server nur wenige Minuten. Messen Sie im Test, wie viele Anfragen zu Spitzenzeiten gleichzeitig laufen, und planen Sie mit Reserve.

Quellen

  1. Ollama: FAQ zu gleichzeitigen Anfragen und Speicher ↗
  2. Red Hat: Ollama und vLLM unter Last im Vergleich (8. August 2025) ↗
  3. vLLM: Dokumentation ↗
  4. Open WebUI: Skalierung (Dokumentation) ↗
  5. Open WebUI: Betrieb mit mehreren Instanzen (Fehlersuche) ↗
  6. Open WebUI: Leistung und Speicherbedarf ↗
  7. Open WebUI: Redis ↗

Dieser Artikel wurde mit Unterstützung von KI erstellt, auf Grundlage der genannten Quellen. Verantwortlich für den Inhalt: basebox GmbH. Keine Rechtsberatung, keine Haftung. Stand der Recherche: 11. Oktober 2026.

Cookie-Einstellungen

Diese Website setzt keine Cookies zur Analyse oder Werbung und bindet keine Werkzeuge anderer Anbieter ein. Im Speicher Ihres Browsers liegt nur, was für die Bedienung nötig ist. Datenschutzerklärung