Open-LLM-VTuber: eine lokale Sprachschleife mit Live2D-Avatar

Welches Problem die Sprachschleife löst, und für wen

Ein LLM im Terminal zu befragen ist einfach. Ein LLM so anzusprechen, wie man mit einer Person spricht, ist eine Kette aus vier Problemen: Mikrofonaufnahme im Browser, Transkription, Modellantwort und Vertonung, dazu die Frage, wann die Aufnahme endet und wann sie wieder beginnt. Open-LLM-VTuber nimmt diese Kette als Ganzes in den Blick und hängt ein Live2D-Modell daran, das die Antworten sichtbar begleitet. Die Zielgruppe benennt das README selbst: Nutzer, die einen virtuellen Begleiter wollen, und Entwickler, die den geschlossenen AI-Vtuber neuro-sama mit offenen Bausteinen nachbauen möchten. Der Name ist bewusst gewählt, wie das README erklärt: nicht Companion, nicht Waifu, sondern VTuber, weil das ursprüngliche Entwicklungsziel der Nachbau von neuro-sama mit offline lauffähigen Open-Source-Komponenten war. Praktisch heißt das: Das Projekt richtet sich an Menschen, die bereit sind, Modelle, Stimmen und Figuren selbst auszuwählen, statt eine fertige Figur mit festgelegter Stimme zu abonnieren.

Wie die Kette aus STT, LLM und TTS zusammenspielt

Die Architektur ist eine Pipeline mit einem Server in der Mitte. Der Client, wahlweise Webseite oder Desktop-Anwendung, hält Mikrofon und Live2D-Modell. Die Aufnahme geht an den Server, der sie über eine Speech-to-Text-Komponente in Text wandelt, diesen an ein Large Language Model weiterreicht und die Antwort durch eine Text-to-Speech-Komponente schickt. Zurück fließen Audio und Steuerdaten für die Figur. Für jede der drei Stufen nennt das README mehrere austauschbare Anbieter: bei den LLMs unter anderem Ollama und OpenAI, dazu TTS- und STT-Lösungen in größerer Zahl. Zwei Details dieser Schleife sind für die Bedienung wichtiger als die Modellwahl. Erstens die Unterbrechung per Stimme: Laut README funktioniert sie ohne Kopfhörer, weil die Software die eigene Ausgabe nicht als Nutzereingabe wertet. Zweitens die Trennung von gesprochenem Text und innerem Zustand. Das Projekt zeigt Gedanken, Ausdrücke und Aktionen an, ohne sie vorzulesen, und kann über ein Emotions-Mapping Live2D-Ausdrücke aus dem Backend heraus setzen. Wer die Kette nachvollziehen will, sollte wissen, dass die lange Zeit angekündigte Langzeitgedächtnisfunktion derzeit entfernt ist. Erhalten bleibt die Persistenz der Chatprotokolle, sodass sich frühere Gespräche fortsetzen lassen.

Installation und die Konfigurationsdateien im conf-Verzeichnis

Das README verweist für den Einstieg auf die Dokumentation unter open-llm-vtuber.github.io/docs/quick-start und stellt ein Docker-Image unter dem Namen Open-LLM-VTuber/open-llm-vtuber bereit. Der lokale Weg führt über Python, und die zentrale Stellschraube ist das Verzeichnis conf, in dem die Konfigurationsdateien liegen. Dort werden Anbieter und Zugangsdaten für die drei Stufen hinterlegt, also etwa ein Ollama-Endpunkt für das Modell und die Auswahl der STT- und TTS-Engines. Ein Punkt, der in vielen Anleitungen untergeht, steht im README als Warnung: Wird der Server auf einem anderen Rechner betrieben als dem, auf dem das Mikrofon sitzt, verlangt der Browser einen sicheren Kontext. Die getUserMedia-Schnittstelle startet nur unter HTTPS oder auf localhost. Wer also den Server auf dem PC laufen lässt und die Seite vom Telefon aus öffnet, muss HTTPS über einen Reverse Proxy einrichten. Das ist keine Empfehlung, sondern eine Bedingung der Browser-API, auf die das README ausdrücklich hinweist. Ein weiterer Konfigurationspunkt betrifft die Figur: Aussehen und Persona werden über eine eigene Anleitung zur Charakteranpassung festgelegt, die auf der Dokumentationsseite verlinkt ist.

Betriebsmodi, Plattformen und was der Desktop-Client anders macht

Zwei Betriebsarten stehen zur Wahl, und sie unterscheiden sich nicht nur kosmetisch. Die Webversion läuft im Browser und ist damit an die HTTPS-Regel gebunden. Der Desktop-Client kann zwischen Fenstermodus und Desktop-Pet-Modus wechseln. Im Pet-Modus ist der Hintergrund transparent, das Fenster liegt global über anderen Anwendungen, und Mausklicks können durch die Figur hindurchgehen, sodass sie sich an beliebiger Stelle auf dem Bildschirm ablegen lässt. Genau dieser Modus ist der Grund, warum die Desktop-Variante existiert. Plattformseitig nennt das README Windows, macOS und Linux. Bei der Hardware ist die Aussage vorsichtig formuliert: NVIDIA und Nicht-NVIDIA-GPUs werden unterstützt, rechenintensive Aufgaben können auf der CPU oder über Cloud-APIs laufen, und einige Komponenten nutzen auf macOS GPU-Beschleunigung. Welche Komponenten das im Einzelnen sind, sagt das README nicht. Wer auf einem Mac ohne diskrete GPU plant, sollte das vor der Installation in der Dokumentation prüfen, statt es aus dem Feature-Satz zu schließen.

Wo das Projekt an Grenzen stößt

Die deutlichste Einschränkung ist der Projektstatus. Das README bezeichnet das Projekt als früh und in aktiver Entwicklung und kündigt zugleich an, dass die Arbeit an v2.0 begonnen hat, einer vollständigen Neuimplementierung der Codebasis, die sich nach eigener Aussage noch in einer frühen Diskussions- und Planungsphase befindet. Für v1 werden ausdrücklich keine neuen Feature-Issues und Pull Requests mehr gewünscht; Fehlerkorrekturen und bestehende Pull Requests laufen weiter. Wer heute auf v1 aufsetzt, baut auf einer Linie, die keine neuen Funktionen mehr erhalten soll. Dazu kommt der entfernte Langzeitspeicher: Das Projekt verspricht ihn zurück, aber derzeit ist er nicht da. Ein zweiter Grenzfall betrifft die Umgebung. Ohne HTTPS gibt es auf einem entfernten Gerät kein Mikrofon, und damit keine Sprachinteraktion, egal wie gut die Pipeline konfiguriert ist. Ein dritter Punkt ist die Lizenz. Die Metadaten weisen NOASSERTION aus, das Repository enthält eine LICENSE-Datei, deren Bedingungen sich aus dem Material nicht ablesen lassen. Wer das Projekt kommerziell einsetzen oder weitergeben will, muss diese Datei selbst lesen und im Zweifel juristischen Rat einholen. Für einen schnellen Prototyp ist das kein Hindernis. Für ein Produkt mit Weitergabe ist es eine offene Frage.

Was eine schlanke Eigenbaulösung anders macht

Die naheliegende Alternative ist, die Kette selbst zu verdrahten: ein STT-Dienst, ein LLM-Endpunkt, ein TTS-Dienst und ein Frontend, das ein Live2D-Modell über die passende Web-Bibliothek rendert. Der Unterschied liegt nicht in der Funktion, sondern in der Kopplung. Eine Eigenbaulösung enthält nur die Anbieter, die man tatsächlich braucht, hat keine Konfigurationsschicht für ungenutzte Engines und keine Abhängigkeit von einem Projekt, dessen nächste Hauptversion die Codebasis ersetzt. Dafür fehlt alles, was Open-LLM-VTuber bereits gelöst hat: die Unterbrechung per Stimme ohne Kopfhörer, das Emotions-Mapping auf Live2D-Ausdrücke, der Pet-Modus mit Klick-Durchlässigkeit, die Anzeige innerer Gedanken und die persistierten Chatprotokolle. Diese Punkte einzeln nachzubauen kostet mehr Zeit, als die Konfiguration des bestehenden Projekts in Anspruch nimmt. Die Wahl hängt also davon ab, ob man die Interaktionsdetails als Kern des eigenen Vorhabens betrachtet oder als Beiwerk. Wer nur einen lokalen Sprachassistenten ohne Figur braucht, ist mit einem direkten STT-LLM-TTS-Skript schneller fertig und hat weniger bewegliche Teile zu warten.

Wartung, Upgrades und die Lizenzfrage

Der Wartungsaufwand verteilt sich auf drei Ebenen. Die erste ist das Projekt selbst: Solange v1 nur noch Fehlerkorrekturen erhält, sind Sicherheitsupdates zu erwarten, neue Funktionen nicht. Die zweite Ebene sind die angebundenen Dienste. Weil STT, LLM und TTS austauschbar sind, ändert sich mit jedem Anbieterwechsel die Konfiguration, und ein Upgrade des Projekts kann Anpassungen an den Konfigurationsdateien im conf-Verzeichnis erforderlich machen. Wer viele Anbieter parallel eingetragen hat, trägt diesen Aufwand mehrfach. Die dritte Ebene ist der Wechsel auf v2.0. Eine vollständige Neuimplementierung bedeutet in der Regel, dass die eigene Konfiguration nicht unverändert übernommen werden kann. Ob es einen Migrationspfad geben wird, lässt sich aus dem Material nicht beantworten; das README verweist für die Planung auf die Entwickler-Community. Zur Lizenz: Der Metadatenwert NOASSERTION ist keine Lizenzangabe, sondern ein Platzhalter für einen nicht automatisch erkannten Lizenztext. Die LICENSE-Datei im Repository ist die maßgebliche Quelle, und die Frage, ob eine Weitergabe oder ein kommerzieller Betrieb zulässig ist, lässt sich ohne deren Lektüre nicht beantworten. Das ist keine Formalie, sondern der erste Punkt, der vor einem Deployment zu klären ist.

Redaktionelles Fazit

Sinnvoll ist Open-LLM-VTuber für Entwickler, die eine lokale Sprachschleife mit sichtbarer Figur selbst zusammenstecken wollen und bereit sind, die Konfigurationsdateien im conf-Verzeichnis Zeile für Zeile zu lesen. Wer ein fertiges Produkt mit Support, stabiler API und klarer Lizenz braucht, sollte warten, bis v2.0 den Planungsstatus verlassen hat, oder auf eine schlanke Eigenbaulösung aus Whisper, einem LLM-Endpunkt und einem TTS-Dienst ausweichen. Vor dem ersten Deployment ist zu klären, ob HTTPS über einen Reverse Proxy eingerichtet werden kann, ob die gewählte TTS-Engine auf der Zielplattform läuft und unter welchen Bedingungen der NOASSERTION-Lizenztext die Weitergabe erlaubt.

Offizielle Quellen

1. Issues
2. Open-LLM-VTuber/Open-LLM-VTuber on GitHub
3. Project website
4. README
5. Releases