Vom Chat zur modularen KI-Plattform

Ein lokales Sprachmodell zu starten ist heute vergleichsweise einfach. Eine dauerhaft nutzbare KI-Plattform entsteht dadurch jedoch noch nicht. Sobald neben Text auch eigene Dokumente, aktuelle Webinformationen, Bilder, Videos und automatisierte Abläufe verarbeitet werden sollen, müssen mehrere spezialisierte Systeme zuverlässig zusammenspielen.

Genau an diesem Punkt setzt mein KI-Stack an. Er verbindet lokale Inferenz, Medienerzeugung, Wissenszugriff und Recherche hinter einer gemeinsamen Bedienoberfläche. Die Architektur ist modular aufgebaut: Jede Komponente erfüllt eine klar definierte Aufgabe und kann unabhängig betrieben, geprüft oder ausgetauscht werden.

Dieser Artikel beschreibt nicht primär die sichtbaren Funktionen, sondern die technische Struktur dahinter.

Architekturziele

Die Plattform wurde nicht mit dem Ziel entwickelt, möglichst viele KI-Werkzeuge zu installieren. Entscheidend waren fünf andere Anforderungen:

1. Eine zentrale Bedienoberfläche: Text, Bilder, Videos, Recherche und Dokumentenwissen sollen aus demselben Chat heraus nutzbar sein.
2. Lokale Verarbeitung: Sprachmodelle und Medienmodelle sollen auf der eigenen Hardware laufen.
3. Klare Systemgrenzen: Bedienung, Inferenz, Workflows, Datenhaltung und externe Recherche müssen voneinander getrennt bleiben.
4. Reproduzierbarer Betrieb: Installation, Start, Stop, Statusprüfung, Recovery und Validierung gehören zur Architektur.
5. Austauschbare Komponenten: Ein Modell oder Werkzeug darf nicht das gesamte System definieren.

Damit unterscheidet sich der Stack bewusst von einer monolithischen Anwendung. OpenWebUI, LM Studio, ComfyUI, SearXNG und ChromaDB werden nicht zu einem einzigen Programm verschmolzen. Sie bleiben eigenständige Dienste mit definierten Schnittstellen.

Die physische Grundlage

Der Stack läuft auf einer Windows-11-Workstation mit einer NVIDIA GeForce RTX 5090 und rund 32 GB Grafikspeicher. Windows stellt Hardwarezugriff und Desktopumgebung bereit. Linux-nahe Dienste können innerhalb von WSL2 mit Debian betrieben werden.

Diese hybride Basis ist eine bewusste Architekturentscheidung. GPU-intensive Desktopanwendungen lassen sich unter Windows direkt nutzen, während Linux-basierte Dienste in einer vertrauten Serverumgebung laufen können. Beide Bereiche kommunizieren ausschließlich über lokale Schnittstellen.

Die Hardware ist leistungsfähig, aber nicht unbegrenzt. Sprachmodell, Bildmodell und Videomodelle konkurrieren um denselben Grafikspeicher. Deshalb werden große Modelle nicht beliebig parallel geladen. Der Stack orchestriert Aufgaben, ersetzt aber kein Ressourcenmanagement auf Hardwareebene.

Schicht 1: OpenWebUI als Zugangs- und Integrationsschicht

OpenWebUI bildet den zentralen Zugang zum System. Hier beginnen Benutzeranfragen, hier werden Chatverläufe verwaltet und hier erscheinen die Ergebnisse.

Architektonisch ist OpenWebUI jedoch nicht das eigentliche KI-Modell. Es übernimmt vier andere Funktionen:

• Bereitstellung der Benutzeroberfläche,
• Verwaltung von Gesprächen und Dateien,
• Anbindung der lokalen Sprachmodell-API,
• Aufruf zusätzlicher Werkzeuge für Bilder, Videos, Recherche und Wissen.

Diese Trennung ist wichtig. Die Oberfläche kann aktualisiert oder ersetzt werden, ohne die Modelle und Workflows neu aufzubauen. Gleichzeitig kann ein Sprachmodell gewechselt werden, ohne dass sich die grundsätzliche Bedienung ändert.

Eigene Adapter erweitern OpenWebUI um die Medienfunktionen des Stacks. Eine Bild- oder Videoanforderung wird nicht vom Sprachmodell selbst berechnet. Das Modell erkennt beziehungsweise formuliert die Aufgabe, während das zugehörige Werkzeug den passenden ComfyUI-Workflow startet.

Schicht 2: LM Studio als lokale Inferenzschicht

LM Studio stellt das lokale Sprachmodell über eine API bereit. OpenWebUI spricht diese Schnittstelle wie einen Modellendpunkt an. Dadurch bleiben Modellbetrieb und Chatoberfläche technisch voneinander getrennt.

Im aktuellen Aufbau wird bewusst eine Heretic-Variante von Qwen 3.6 verwendet. Die Konzentration auf ein definiertes Hauptmodell reduziert:

• mehrfach belegten Speicherplatz,
• unterschiedliche Laufzeitparameter,
• unklare Modellzuordnungen,
• zusätzliche Fehlerquellen bei Installation und Betrieb.

Parameter wie GPU-Offload und Thinking-Modus wurden auf dem realen Zielsystem getestet. Der Stack verlässt sich dabei nicht auf theoretische Hardwarewerte. Maßgeblich ist, wie Modell, Kontext und GPU-Auslastung im tatsächlichen Betrieb zusammenspielen.

Die Inferenzschicht erzeugt Text und entscheidet über Werkzeugaufrufe. Sie führt aber weder Bildmodelle noch die Vektorsuche selbst aus.

Schicht 3: ComfyUI als Medien- und Workflow-Engine

ComfyUI übernimmt alle rechenintensiven Bild- und Videoworkflows. Es läuft lokal und stellt seine Funktionen über eine Schnittstelle auf 127.0.0.1:8188 bereit.

Der Stack nutzt derzeit zwei klar abgegrenzte Medienpfade:

• Z-Image Turbo für die lokale Bildgenerierung,
• WAN2.2 für die lokale Text-zu-Video-Erzeugung.

Die eigentliche Intelligenz dieser Schicht steckt nicht nur in den Modellen, sondern auch in den versionierten Workflows. Ein Workflow definiert unter anderem:

• welches Modell geladen wird,
• welche Encoder und VAE-Komponenten verwendet werden,
• wie Prompt und negativer Prompt übergeben werden,
• welche Auflösung und Samplingparameter gelten,
• wo das Ergebnis gespeichert wird.

OpenWebUI übergibt die Aufgabe über einen Adapter an ComfyUI. Anschließend wird der Job überwacht, die erzeugte Datei übernommen und über den Dateimechanismus von OpenWebUI im Chat bereitgestellt.

Gerade die letzte Stufe ist architektonisch relevant. Eine erzeugte MP4-Datei ist noch kein nutzbares Chatergebnis. Erst wenn Dateityp, ID, URL, MIME-Typ und Metadaten dem erwarteten Vertrag entsprechen, kann OpenWebUI das Ergebnis anzeigen und zum Download anbieten.

Schicht 4: RAG und lokale Wissensbestände

Ein lokales Sprachmodell kennt weder meine aktuellen Projektdaten noch eigene Dokumentationen automatisch. Diese Aufgabe übernimmt die RAG-Schicht.

RAG steht für Retrieval Augmented Generation. Vor einer Antwort werden passende Inhalte aus einer Wissensbasis gesucht und dem Sprachmodell als zusätzlicher Kontext übergeben.

Der aktuelle Aufbau verwendet:

• nomic-embed-text-v1.5 als Embedding-Modell,
• Vektoren mit 768 Dimensionen,
• ChromaDB als Vektorspeicher,
• getrennte Präfixe für Dokumente und Suchanfragen.

Beim Import werden Dokumente in kleinere Abschnitte zerlegt. Jeder Abschnitt erhält neben seinem Vektor zusätzliche Metadaten:

• Quellpfad,
• Abschnittsnummer,
• Hashwert,
• Importzeitpunkt.

Diese Metadaten sind kein Komfortmerkmal, sondern Bestandteil der Nachvollziehbarkeit. Ohne sie wäre später kaum feststellbar, aus welcher Datei oder welchem Stand eine Antwort abgeleitet wurde.

Für Nomic werden Dokumente mit search_document: und Anfragen mit search_query: gekennzeichnet. Dadurch kann das Embedding-Modell die unterschiedlichen Aufgaben besser einordnen.

Der Datenfluss einer RAG-Anfrage sieht vereinfacht so aus:

1. OpenWebUI erhält die Benutzerfrage.
2. Die Frage wird als Suchvektor abgebildet.
3. ChromaDB liefert semantisch passende Textabschnitte.
4. Die Abschnitte werden dem Sprachmodell als Kontext übergeben.
5. Das Sprachmodell formuliert die Antwort.

RAG reduziert die Abhängigkeit vom Trainingswissen des Modells. Es garantiert dennoch keine korrekte Antwort. Schlechte Quelldokumente, ungeeignete Textabschnitte oder unpräzise Suchergebnisse bleiben mögliche Fehlerquellen.

Schicht 5: SearXNG für aktuelle externe Informationen

Die lokale Wissensbasis deckt eigene und bereits importierte Inhalte ab. Für aktuelle Informationen steht SearXNG als getrennte Rechercheschicht zur Verfügung.

Die Trennung zwischen RAG und Websuche ist bewusst:

• RAG arbeitet mit kontrollierten eigenen Quellen.
• SearXNG greift auf externe und veränderliche Informationen zu.

Eine Anfrage kann dadurch vollständig lokal beantwortet oder gezielt um aktuelle Webinformationen ergänzt werden. „Lokal“ bedeutet in dieser Architektur also nicht zwingend „offline“. Es bedeutet, dass externe Zugriffe eine erkennbare und steuerbare Funktion bleiben.

Persistente Daten und ausführbare Komponenten

Die Architektur trennt Programme, Modelle, Workflows und veränderliche Daten. Diese Trennung erleichtert Updates und Recovery.

Zu den persistenten Bestandteilen gehören insbesondere:

• heruntergeladene Sprach-, Bild- und Videomodelle,
• ComfyUI-Workflows,
• OpenWebUI-Daten,
• Vektordaten und Dokumentenmetadaten,
• erzeugte Bilder und Videos,
• Konfigurationen und Betriebsnachweise.

ComfyUI selbst befindet sich im Zielaufbau unter C:\KI-Stack\ComfyUI. Modelle werden zentral unter C:\KI-Stack\models verwaltet, während veränderliche ComfyUI-Daten unter C:\KI-Stack\data\comfyui liegen.

Diese Pfadtrennung verhindert, dass ein Programmupdate automatisch Modelle oder Nutzdaten überschreibt. Sie macht außerdem deutlicher, welche Teile gesichert werden müssen und welche bei Bedarf reproduzierbar neu installiert werden können.

Betriebs- und Validierungsschicht

Eine Architektur ist erst vollständig, wenn auch ihr Betrieb definiert ist. Deshalb umfasst der KI-Stack nicht nur die Laufzeitkomponenten, sondern auch:

• Installationslogik,
• Preflight-Prüfungen,
• Start-, Stop- und Statussteuerung,
• Fortsetzung abgebrochener Installationen,
• Backup und Rollback,
• Recovery,
• Paket- und Zielsystemvalidierung.

Dabei wird zwischen zwei Prüfarten unterschieden:

1. Quell- und Paketprüfung: Sind alle erwarteten Dateien vorhanden und stimmen Struktur sowie Prüfsummen?
2. Zielsystemprüfung: Laufen die Komponenten auf der tatsächlichen Maschine mit den vorgesehenen Pfaden, Ports, Modellen und Workflows?

Ein erfolgreicher Paketbau beweist nur, dass ein Paket erzeugt werden konnte. Er beweist nicht, dass LM Studio ein Modell lädt, ComfyUI auf die GPU zugreift oder OpenWebUI eine erzeugte Videodatei korrekt übernimmt.

Diese Unterscheidung war eine der wichtigsten praktischen Erkenntnisse des Projekts.

Typische Datenflüsse

Reine Textanfrage

Benutzer → OpenWebUI → LM Studio → lokales Sprachmodell → OpenWebUI

Anfrage an eigene Dokumente

Benutzer → OpenWebUI → Embedding/Suche → ChromaDB
         → gefundener Kontext → LM Studio → OpenWebUI

Bild- oder Videoanforderung

Benutzer → OpenWebUI → Werkzeugadapter → ComfyUI-Workflow
         → erzeugte Datei → OpenWebUI-Dateispeicher → Chat

Aktuelle Webrecherche

Benutzer → OpenWebUI → SearXNG → externe Quellen
         → Suchergebnisse → Sprachmodell → OpenWebUI

Warum die Modularität wichtig ist

KI-Modelle und Werkzeuge entwickeln sich schnell. Eine Architektur, die vollständig von einem Modell oder einer Oberfläche abhängt, altert entsprechend schnell.

Im KI-Stack bleiben die Verantwortlichkeiten getrennt:

Bereich	Verantwortliche Komponente
Bedienung und Gespräche	OpenWebUI
Sprachmodell-Inferenz	LM Studio
Bilder und Videos	ComfyUI
Eigene Wissensbestände	ChromaDB und Embedding-Modell
Aktuelle externe Informationen	SearXNG
Installation und Betrieb	KI-Stack-Steuerung und Validation Gate

Dadurch kann beispielsweise das Sprachmodell gewechselt werden, ohne den Video-Workflow zu verändern. Ebenso kann ein neuer ComfyUI-Workflow ergänzt werden, ohne die RAG-Datenbank neu aufzubauen.

Modularität bedeutet allerdings nicht, dass Komponenten beliebig austauschbar wären. Schnittstellen, Dateiverträge, Modellformate und Metadaten müssen weiterhin zusammenpassen. Austauschbarkeit entsteht durch definierte Verträge, nicht durch bloße räumliche Trennung.

Sicherheits- und Vertrauensgrenzen

Lokale Verarbeitung verbessert die Kontrolle über Daten, beseitigt aber keine Sicherheitsanforderungen.

Der Stack besitzt mehrere Vertrauensgrenzen:

• zwischen Benutzerinhalt und Sprachmodell,
• zwischen importierten Dokumenten und RAG-Kontext,
• zwischen lokalen Diensten,
• zwischen lokaler Verarbeitung und Webrecherche,
• zwischen erzeugten Dateien und ihrer späteren Verwendung.

Insbesondere fremde Dokumente und Webinhalte können manipulierte Anweisungen enthalten. RAG und Recherche benötigen deshalb eine klare Quellenkennzeichnung und dürfen nicht automatisch mit uneingeschränkten Systemrechten verbunden werden.

Auch lokal ausgeführte Modelle, Custom Nodes und Erweiterungen sind Softwarekomponenten, die geprüft und aktualisiert werden müssen. Ein lokaler KI-Stack ist nicht allein deshalb vertrauenswürdig, weil keine kommerzielle API verwendet wird.

Fazit

Die Architektur des KI-Stacks folgt einem einfachen Prinzip: Eine gemeinsame Oberfläche, aber getrennte Verantwortlichkeiten.

OpenWebUI koordiniert die Benutzerinteraktion. LM Studio stellt das Sprachmodell bereit. ComfyUI erzeugt Bilder und Videos. ChromaDB erschließt eigene Dokumente. SearXNG ergänzt aktuelle externe Informationen. Die Betriebs- und Validierungsschicht sorgt dafür, dass daraus nicht nur eine Demo, sondern ein reproduzierbar betreibbares System entsteht.

Der eigentliche Wert liegt damit nicht in einer einzelnen KI-Komponente. Er liegt in den definierten Übergängen zwischen Oberfläche, Modellen, Workflows, Daten und Betrieb.

Der Projektstand wird im GitHub-Repository dokumentiert: robertbackhaus-a11y/KI-Stack.