Viele KI-Lösungen wirken im ersten Moment beeindruckend – bis man genauer hinsieht. Für jede Aufgabe gibt es einen anderen Cloud-Dienst, Daten wandern zwischen mehreren Anbietern, Modelle ändern sich ohne Vorankündigung und aus einem vermeintlich einfachen Werkzeug wird schnell ein unübersichtliches Geflecht aus Konten, Abonnements und Schnittstellen.
Mein Ziel war deshalb ein anderes: eine lokale KI-Plattform, die sich wie ein zusammenhängendes System bedienen lässt. Sie sollte Sprachmodelle, Bild- und Videoerzeugung, Webrecherche, Wissenssuche und automatisierte Workflows verbinden, ohne für jede Funktion eine eigene Benutzeroberfläche zu benötigen.
Aus diesem Anspruch ist der KI-Stack entstanden.
Kein einzelnes Programm, sondern eine Plattform
Der KI-Stack ist keine weitere Chat-Anwendung und auch kein bloßes Installationsskript. Er ist eine modular aufgebaute lokale Plattform für Windows 11 und WSL2/Debian. Die einzelnen Komponenten erfüllen klar abgegrenzte Aufgaben:
- OpenWebUI bildet die zentrale Bedienoberfläche.
- LM Studio stellt die lokalen Sprachmodelle bereit.
- ComfyUI übernimmt die Bild- und Videoerzeugung.
- SearXNG ermöglicht kontrollierte Webrecherche.
- ChromaDB und RAG-Funktionen erschließen eigene Dokumente und Wissensbestände.
- Eigene Adapter verbinden diese Dienste so, dass Ergebnisse direkt im Chat erscheinen.
Für den Anwender soll diese Aufteilung möglichst unsichtbar bleiben. Er formuliert seine Aufgabe in einer Oberfläche. Ob dafür ein Sprachmodell, eine Bild-Pipeline, eine Videosynthese, eine Recherche oder eine Wissensdatenbank angesprochen wird, entscheidet der jeweilige Workflow.
Die technische Basis
Der aktuelle Stack läuft auf einer leistungsfähigen Windows-Workstation mit einer NVIDIA GeForce RTX 5090 und rund 32 GB Grafikspeicher. Die Hardware ist wichtig, aber sie ist nicht der eigentliche Kern des Projekts. Entscheidend ist die saubere Trennung zwischen Bedienung, Inferenz, Medienerzeugung, Datenhaltung und Betrieb.
Windows 11 stellt die Desktop- und Hardwarebasis bereit. WSL2 mit Debian übernimmt die Linux-nahen Dienste. Diese Aufteilung erlaubt es, GPU-intensive Windows-Anwendungen und containerisierte beziehungsweise Linux-basierte Komponenten sinnvoll miteinander zu verbinden.
Gleichzeitig bleibt der Stack modular. Nicht jeder Baustein muss dauerhaft laufen, und einzelne Komponenten können aktualisiert oder ersetzt werden, ohne die gesamte Plattform neu aufzubauen.
Lokale Sprachmodelle statt API-Pflicht
Die Sprachmodelle werden über LM Studio bereitgestellt. Aktuell konzentriert sich der Stack bewusst auf eine Heretic-Variante von Qwen 3.6. Die Reduktion auf ein klar definiertes Modell ist kein Nachteil, sondern eine Betriebsentscheidung: Weniger Varianten bedeuten weniger Speicherbedarf, weniger unklare Zustände und besser reproduzierbare Ergebnisse.
Das Modell wird überwiegend auf die GPU ausgelagert. Parameter wie Offload, Kontextgröße und Thinking-Modus wurden nicht theoretisch gewählt, sondern auf dem realen Zielsystem getestet. In der verwendeten Konfiguration liegt die Antwortzeit für typische Anfragen im Bereich weniger Sekunden.
Ein lokales Modell ersetzt nicht automatisch jedes Cloud-Modell. Es bietet aber drei wesentliche Vorteile:
- Daten können innerhalb des eigenen Systems verarbeitet werden.
- Modellversion und Laufzeitparameter bleiben kontrollierbar.
- Es entstehen keine nutzungsabhängigen API-Kosten für jede einzelne Anfrage.
Eine Oberfläche für Chat, Bilder und Videos
OpenWebUI ist die zentrale Schnittstelle des Stacks. Dort werden nicht nur Textantworten erzeugt. Eigene Werkzeuge übergeben Anforderungen an ComfyUI und bringen die Ergebnisse wieder in den Chat zurück.
Für Bilder kommt Z-Image Turbo zum Einsatz. Die Pipeline ist auf schnelle lokale Erzeugung ausgelegt und unterstützt neben dem eigentlichen Prompt auch einen negativen Prompt. Damit lassen sich typische Bildfehler und unerwünschte Elemente gezielter unterdrücken.
Für Videos wird WAN2.2 verwendet. Die Videoerzeugung ist deutlich rechenintensiver als die Erstellung eines Einzelbildes, funktioniert aber ebenfalls lokal. Der entscheidende Integrationsschritt bestand nicht allein darin, eine MP4-Datei zu erzeugen. Das Ergebnis musste über den tatsächlichen Dateivertrag von OpenWebUI bereitgestellt werden, damit es direkt im Chat verfügbar und herunterladbar ist.
Genau an solchen Details zeigt sich der Unterschied zwischen einer Demo und einem belastbaren System: Ein Modell kann technisch ein Ergebnis erzeugen. Nutzbar wird es erst, wenn Erzeugung, Übergabe, Anzeige, Download und Fehlerbehandlung zusammenpassen.
Eigene Dokumente mit RAG nutzbar machen
Ein Sprachmodell kennt die eigenen Unterlagen, Projektdokumentationen und aktuellen Arbeitsstände nicht automatisch. Dafür enthält der Stack einen RAG-Strang – Retrieval Augmented Generation.
Dokumente werden zerlegt, mit dem lokalen Embedding-Modell nomic-embed-text-v1.5 vektorisiert und in ChromaDB abgelegt. Bei einer Anfrage sucht das System zunächst nach passenden Textabschnitten und übergibt diese anschließend als Kontext an das Sprachmodell.
Dabei reicht es nicht, beliebige Textstücke in eine Datenbank zu schreiben. Für belastbare Ergebnisse werden Metadaten benötigt, unter anderem:
- Quelldatei,
- Nummer des Textabschnitts,
- Hashwert,
- Importzeitpunkt.
Zusätzlich werden die von Nomic vorgesehenen Präfixe search_document: und search_query: berücksichtigt. Sie helfen dem Embedding-Modell, Dokumentinhalt und Suchanfrage korrekt zu unterscheiden.
RAG ist trotzdem kein Wahrheitsautomat. Schlechte Quelldokumente, unpassende Textabschnitte oder fehlende Metadaten führen auch mit einem guten Modell zu schlechten Antworten. Deshalb gehören Importqualität, Nachvollziehbarkeit und Tests fest zur Architektur.
Webrecherche bleibt möglich
„Lokal“ bedeutet in diesem Projekt nicht zwangsläufig „vollständig offline“. Über SearXNG kann der Stack gezielt auf aktuelle Informationen im Internet zugreifen. Der Unterschied liegt in der Kontrolle: Recherche ist eine klar erkennbare Funktion und keine undurchsichtige Hintergrundaktivität eines beliebigen Cloud-Dienstes.
Damit lassen sich lokale Verarbeitung und aktuelle externe Informationen kombinieren. Für sensible Inhalte kann die Webrecherche deaktiviert bleiben; für aktuelle technische Fragen oder bekannte Softwareprobleme steht sie bei Bedarf zur Verfügung.
Installation allein reicht nicht
Der aufwendigste Teil eines solchen Projekts ist überraschenderweise nicht die Installation der einzelnen Anwendungen. Die eigentliche Arbeit steckt in den Übergängen und im Betrieb:
- Stimmen Pfade und Ports auf dem realen Zielsystem?
- Starten und stoppen die Komponenten in der richtigen Reihenfolge?
- Werden vorhandene Installationen erkannt?
- Lassen sich abgebrochene Installationen fortsetzen?
- Funktionieren Backup, Rollback und Recovery?
- Bleiben Modell- und Workflowstände nachvollziehbar?
- Wird das tatsächlich ausgelieferte Paket geprüft – oder nur der Quellstand?
Der KI-Stack wird deshalb als vollständiges Installations- und Betriebspaket entwickelt. Validierung, Wiederanlauf und reproduzierbare Dateiprüfungen sind keine nachträglichen Extras, sondern Teil des Produkts.
Eine wichtige Lehre aus dem Projekt lautet: Ein erfolgreicher Build ist noch kein erfolgreich installiertes Zielsystem. Erst die Prüfung auf der realen Maschine zeigt, ob Versionsauflösung, Pfade, Dienste, GPU-Zugriff und Integrationen tatsächlich funktionieren.
Was der Stack heute leistet
Der aktuelle Stand deckt die wichtigsten Arbeitsarten einer lokalen KI-Plattform ab:
- Chat mit einem lokal betriebenen Sprachmodell,
- lokale Bildgenerierung über Z-Image Turbo,
- lokale Videogenerierung über WAN2.2,
- kontrollierte Websuche über SearXNG,
- Dokumentensuche und Kontextanreicherung mit ChromaDB,
- gemeinsame Bedienung über OpenWebUI,
- definierte Workflows sowie Start-, Stop- und Statussteuerung,
- Installations-, Prüf- und Recovery-Mechanismen.
Nicht jede denkbare Komponente bleibt dauerhaft im Paket. Modelle und Funktionen, die keinen klaren Mehrwert liefern oder den Betrieb unnötig komplizieren, werden bewusst entfernt. Ein guter Stack wird nicht dadurch besser, dass er möglichst viele Werkzeuge enthält. Er wird besser, wenn die verbleibenden Werkzeuge nachvollziehbar zusammenspielen.
Wo die Grenzen liegen
Auch eine starke Workstation hat physikalische Grenzen. Große Sprachmodelle konkurrieren mit Bild- und Videomodellen um Grafikspeicher. Hochauflösende Videos benötigen Zeit. Modellupdates können Workflows verändern. Und eine lokale Installation ist nicht automatisch sicher, wartbar oder datenschutzkonform.
Wer einen vergleichbaren Stack aufbaut, muss deshalb auch klassische IT-Themen berücksichtigen:
- Patch- und Versionsmanagement,
- Zugriffsschutz,
- Protokollierung,
- Sicherung der Daten und Konfigurationen,
- Lizenzbedingungen der verwendeten Modelle,
- Trennung zwischen vertrauenswürdigen und fremden Inhalten,
- Schutz vor manipulierten Dokumenten und Prompt Injection.
Lokale KI verschiebt Verantwortung vom Cloud-Anbieter zurück zum Betreiber. Genau das ist einer ihrer größten Vorteile – aber eben auch eine Verpflichtung.
Fazit
Der KI-Stack zeigt, dass sich Sprachmodelle, Bild- und Videoerzeugung, RAG und Webrecherche auf einer lokalen Plattform sinnvoll verbinden lassen. Der eigentliche Mehrwert entsteht nicht durch ein einzelnes Modell. Er entsteht durch die Architektur zwischen den Komponenten.
Für mich ist das Projekt deshalb weniger ein KI-Spielplatz als eine lokale Arbeitsplattform: kontrollierbar, erweiterbar und auf dem eigenen System nachvollziehbar. Noch ist nicht jeder Baustein abgeschlossen. Aber der entscheidende Punkt ist erreicht: Aus mehreren Einzelwerkzeugen ist ein zusammenhängender Stack geworden.
Der Quell- und Projektstand ist auf GitHub dokumentiert: KI-Stack.