LoLLMs WebUI: eine lokale Oberfläche für viele Modelle, mit einer klaren Ablaufgrenze
Lord of Large Language and Multi modal Systems Web User Interface
Auf einen Blick
- Was ist das?
- LoLLMs WebUI bündelt Bindings, Persönlichkeiten und Medienwerkzeuge in einer lokal betriebenen Weboberfläche. Das README nennt das Projekt selbst nur noch als Übergangslösung, und genau daraus ergibt sich die wichtigste Entscheidung für Interessenten.
- Für wen ist es gedacht?
- Wer heute einen lokalen, von einer Person genutzten Einstieg in viele Bindings und Persönlichkeiten sucht und die Ablösung durch das neue lollms-Projekt bewusst in Kauf nimmt, kann LoLLMs WebUI weiterhin einsetzen. Wer Mehrbenutzerbetrieb oder MCP-Kompatibilität braucht, sollte direkt zum neuen Repository wechseln, statt hier Erweiterungen zu erwarten.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 6 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Bedienfeld über Bindings, das der Autor selbst abkündigt
Das Projekt liefert eine Weboberfläche, die mehrere Inferenzwege hinter einer einzigen Bedienung zusammenführt. Laut README sind das Hugging-Face-Modelle lokal, GGUF- und GGML-Modelle, EXLLama v2 mit EXL-, AWQ- und GPTQ-Gewichten, außerdem die Dienste Ollama, vllm, OpenAI, Anthropic, Open-router und Novita-ai. Wer bisher für jeden dieser Wege ein eigenes Skript oder eine eigene Konfiguration gepflegt hat, bekommt hier eine gemeinsame Oberfläche. Dazu kommen Persönlichkeiten mit vordefinierten Begrüßungstexten, eine lokale Datenbank für Unterhaltungen sowie Erzeugung von Bildern, Video und Musik über verschiedene Anbieter.
Die Zielgruppe ist damit klar umrissen: einzelne Nutzer auf einer eigenen Maschine, die schnell zwischen Modellen und Aufgaben wechseln wollen, ohne für jeden Anbieter eine neue Umgebung aufzusetzen. Das README beschreibt den Betrieb ausdrücklich als lokal und für einen einzelnen Nutzer. Genau diese Einschränkung ist wichtig, denn sie erklärt, warum das Projekt in seiner jetzigen Form an eine Grenze stößt.
Warum dieses Repository nur noch eine Übergangslösung ist
Der README beginnt nicht mit Funktionen, sondern mit einer Abkündigung. Dort steht, dass ein neues lollms-Projekt unter einer anderen Adresse existiert und dass dieses neue Projekt eine fortgeschrittenere Version mit Mehrbenutzerbetrieb und MCP-Kompatibilität ist. Für die vorliegende WebUI heißt es, sie behalte nur minimale Unterstützung und werde irgendwann vollständig ersetzt.
Das ist ungewöhnlich offen formuliert und für die Bewertung wichtiger als jede Funktionsliste. Ein Projekt, dessen eigene Dokumentation die Nachfolge ankündigt, ist kein Ort für langfristige Erweiterungen. Wer heute Funktionen beisteuert, arbeitet an einer Codebasis, die absehbar nicht weitergeführt wird. Wer nur eine bestehende Installation betreibt, ist davon weniger betroffen. Die letzte hier genannte Veröffentlichung ist v14 mit dem Beinamen Saïph vom 11. November 2024, davor v13 (feather) und v12 (Strawberry) im Monatsabstand. Der letzte Push liegt laut Repository-Angaben im September 2026. Ob in diesem Zeitraum inhaltliche Arbeit oder nur eine Statusänderung stattfand, lässt sich aus dem Material nicht ableiten.
Der Weg von der Anfrage zur Antwort führt über Binding und Persönlichkeit
Die Oberfläche ist als Auswahlschicht aufgebaut. Der Nutzer wählt zuerst ein Binding, also den Weg zur Inferenz, dann ein Modell und schließlich eine Persönlichkeit. Diese Reihenfolge steht so im README und sie bestimmt den gesamten Datenfluss: Die Anfrage wird nicht direkt an einen Dienst geschickt, sondern zunächst gegen die gewählte Persönlichkeit und deren Begrüßungstext gestellt, bevor sie über das Binding das Modell erreicht.
Das erklärt, warum Persönlichkeiten hier mehr sind als Kosmetik. Sie bündeln Systemanweisungen, die vor jeder Unterhaltung greifen. Wer zwischen einem Coding-Assistenten und einer Figur für erzählerische Texte wechselt, wechselt nicht nur die Formulierung, sondern den gesamten Vorlauf. Ein weiterer Mechanismus ist das Prompt-Routing, das laut README Anfragen abhängig von der Komplexität der Aufgabe an verschiedene Modelle verteilt. Wie die Komplexität bestimmt wird, geht aus dem Material nicht hervor. Diese Lücke ist relevant, weil Routing ohne nachvollziehbare Regel im Betrieb schwer zu prüfen ist.
Die Unterhaltungen landen in einer lokalen Datenbank. Das README nennt Suchen, Exportieren und Löschen mehrerer Unterhaltungen sowie Bewertungen mit Daumen hoch und runter. Diese Bewertungen sind eine Rückmeldung an den Nutzer selbst, kein Trainingssignal, soweit das Material das erkennen lässt.
Installation: Skript oder manueller Weg mit Python 3.11
Für die automatische Installation verweist das README auf Skripte im scripts-Ordner: lollms_installer.bat für Windows, lollms_installer.sh für Linux und lollms_installer_macos.sh für macOS. Der Ablauf besteht demnach darin, das passende Skript herunterzuladen und auszuführen.
Seit Version 10.14 ist laut README auch die manuelle Installation wieder möglich. Der erste dort genannte Schritt lautet, Python 3.11 bereitzustellen. Das ist eine harte Vorgabe und keine Empfehlung, denn der Text schreibt "ensure Python 3.11 is installed". Wer eine neuere oder ältere Version im System hat, sollte das vor dem Start klären, statt sich auf die Fehlermeldung des Installers zu verlassen. Der README-Ausschnitt endet an dieser Stelle, weitere Schritte der manuellen Einrichtung sind im vorliegenden Material nicht enthalten. Als weitere Wege nennt das README Docker, conda und eine manuelle virtuelle Umgebung. Konkrete Befehle für diese Varianten stehen im Auszug nicht, sie lassen sich daraus also nicht belegen.
Für die Einrichtung der Bindings und Persönlichkeiten verweist das Projekt auf eigene Repositories, die im README verlinkt sind. Das deutet auf einen Aufbau mit austauschbaren Sammlungen hin. Details zur Struktur dieser Sammlungen gehen aus dem Auszug nicht hervor.
Die Oberfläche als Schaufenster: wo die Erwartung auseinanderläuft
Das README verspricht sehr viel. Es nennt über 500 KI-Persönlichkeiten und mehr als 2500 feinabgestimmte Modelle, dazu Beispiele von Autoreparatur über Coding-Hilfe bis zu medizinischer Einschätzung und Vertragsauslegung. Diese Beispiele sind Werbetext, nicht Funktionsbeschreibung. Die medizinische und die juristische Passage sind der schwächste Teil der Dokumentation, weil sie einen Nutzen suggerieren, für den eine lokale Oberfläche mit austauschbaren Persönlichkeiten keine Grundlage liefert. Wer solche Anwendungsfälle ernst nimmt, braucht Prüfverfahren, die das Projekt nicht beschreibt.
Die technische Zusage bleibt davon getrennt und ist prüfbar: mehrere Bindings, mehrere Medienanbieter, eine lokale Datenbank. Die Zahlen zu Persönlichkeiten und Modellen lassen sich aus dem Material nicht überprüfen, und sie sagen ohnehin nichts über die Qualität des einzelnen Eintrags. Für die Entscheidung zählt eher, dass die Auswahl über verlinkte Sammlungen organisiert ist und nicht fest im Hauptprogramm steckt. Das macht Erweiterungen leichter, verschiebt die Pflege aber in andere Repositories.
Grenzen: Einzelnutzerbetrieb, keine MCP-Anbindung, unklares Routing
Die deutlichste Grenze steht im Titel des README selbst: local, single user. Wer mehrere Personen auf einer Instanz arbeiten lassen will, findet hier keine beschriebene Grundlage. Das neue lollms-Projekt wird im README ausdrücklich mit Mehrbenutzerbetrieb und MCP-Kompatibilität beworben. MCP, also die Anbindung externer Werkzeuge über ein standardisiertes Protokoll, fehlt in der Feature-Liste dieser WebUI vollständig. Für Anwendungen, die auf Werkzeugaufrufe angewiesen sind, ist das ein Ausschlusskriterium und nicht eine Frage der Konfiguration.
Ein zweiter Punkt betrifft die Wartung. Das README spricht von minimaler Unterstützung. Wer Fehler meldet oder Beiträge einreicht, muss damit rechnen, dass die Antwort auf den Nachfolger verweist. Ein dritter Punkt ist das Prompt-Routing. Es wird als Funktion genannt, aber ohne Kriterium, ohne Schwellenwert und ohne Konfigurationsschlüssel. Solange das so bleibt, ist Routing im Betrieb kaum überprüfbar. Wer reproduzierbare Antworten braucht, sollte es abschalten oder die Auswahl fest einem Modell zuweisen, statt sich auf eine undokumentierte Verteilung zu verlassen.
Schließlich die Persönlichkeiten. Sie sind der sichtbarste Teil des Projekts und der am wenigsten spezifizierte. Das README nennt Begrüßungstexte, aber keine Angaben dazu, wie eine Persönlichkeit aufgebaut ist, wie sie versioniert wird und ob Änderungen an einer Sammlung bestehende Unterhaltungen verändern.
Der Vergleich mit Ollama: Oberfläche gegen Dienst
Ollama ist der naheliegende Vergleich, weil es hier als eines der Bindings auftaucht. Der Unterschied liegt im Ansatz. Ollama ist ein Dienst, der Modelle bereitstellt und über eine schmale Schnittstelle anspricht. LoLLMs WebUI ist eine Oberfläche, die unter anderem diesen Dienst nutzt, daneben aber lokale Gewichte über Hugging Face, EXLLama v2 mit EXL-, AWQ- und GPTQ-Formaten sowie mehrere gehostete Anbieter einbindet.
Wer nur ein Modell lokal betreiben und über eine API ansprechen will, fährt mit einem reinen Dienst schlanker. Wer dagegen im selben Fenster zwischen einem lokalen GGUF-Modell, einem gehosteten Dienst und einer Bildgenerierung wechseln möchte, bekommt bei LoLLMs WebUI genau diese Zusammenführung. Der Preis dafür ist die zusätzliche Schicht: Bindings, Persönlichkeiten und Sammlungen müssen zusammenpassen, und ein Fehler kann in jeder dieser Schichten liegen. Bei einem reinen Dienst entfällt diese Fehlerfläche. Dafür entfällt auch die gemeinsame Bedienung.
Eine weitere Alternative ist das neue lollms-Projekt desselben Autors. Es ist kein Wettbewerber von außen, sondern der vorgesehene Nachfolger mit Mehrbenutzerbetrieb und MCP-Kompatibilität. Wer heute neu anfängt, sollte begründen können, warum es nicht dieses Projekt wird.
Lizenz und Pflegeaufwand
Das Projekt steht unter Apache-2.0. Diese Lizenz erlaubt Weitergabe und Änderung unter Bedingungen, unter anderem der Beibehaltung von Urheberrechts- und Lizenzhinweisen sowie der Kennzeichnung geänderter Dateien. Wer LoLLMs WebUI in ein eigenes Produkt einbettet, sollte die Hinweispflichten prüfen. Eine Rechtsberatung ist das hier nicht, und die genauen Pflichten hängen davon ab, wie das Projekt eingebunden wird.
Der Pflegeaufwand ist der zweite Kostenpunkt. Das README nennt drei Installationswege über Skripte sowie Docker, conda und manuelle virtuelle Umgebungen. Jeder dieser Wege muss bei Änderungen an Abhängigkeiten mitgezogen werden. Hinzu kommt die Pflege der Sammlungen für Bindings und Persönlichkeiten, die in getrennten Repositories liegen. Wer eigene Persönlichkeiten oder Bindings beisteuert, arbeitet über mehrere Repositories hinweg.
Dem steht gegenüber, dass die Oberfläche selbst nur minimale Unterstützung erhält. Wer den Aufwand für eigene Anpassungen eingeht, sollte vorher klären, ob diese Anpassungen im Nachfolgeprojekt weiterverwendet werden können. Dazu findet sich im vorliegenden Material kein Hinweis.
Redaktionelles Fazit
Wer heute einen lokalen, von einer Person genutzten Einstieg in viele Bindings und Persönlichkeiten sucht und die Ablösung durch das neue lollms-Projekt bewusst in Kauf nimmt, kann LoLLMs WebUI weiterhin einsetzen. Wer Mehrbenutzerbetrieb oder MCP-Kompatibilität braucht, sollte direkt zum neuen Repository wechseln, statt hier Erweiterungen zu erwarten. Vor dem ersten Start ist zu prüfen, ob Python 3.11 vorhanden ist, welches der Skripte lollms_installer.bat, lollms_installer.sh oder lollms_installer_macos.sh zum eigenen System passt und ob die Lizenz Apache-2.0 zu den eigenen Weitergabepflichten passt.
Community-Notizen