Lokale künstliche Intelligenz bedeutet inzwischen weit mehr, als ein einzelnes Sprachmodell auf einer Grafikkarte zu starten. Sobald neben Text auch eigene Dokumente, aktuelle Informationen aus dem Web, Bild- und Videogenerierung, Werkzeuge, spezialisierte Agenten oder der Zugriff auf das lokale System ins Spiel kommen, entsteht sehr schnell eine Landschaft unterschiedlicher Anwendungen, Modelle und Schnittstellen.

Genau daraus ist mein KI-Stack entstanden. Das Ziel des Projekts besteht nicht darin, möglichst viele KI-Anwendungen auf einem Windows-PC zu installieren, sondern aus ausgewählten Komponenten eine definierte, reproduzierbare und betreibbare lokale KI-Plattform zu bauen. Jede Anwendung und jedes Modell soll darin eine klar festgelegte Aufgabe erfüllen. Ebenso wichtig ist, dass sich die Umgebung nicht nur einmal auf meinem Entwicklungsrechner zum Laufen bringen lässt, sondern auf einem neuen System reproduzierbar installiert, aktualisiert, geprüft, repariert und bei Bedarf kontrolliert zurückgesetzt werden kann.

Der Stack verbindet inzwischen Windows 11, WSL2/Debian, LM Studio, Open WebUI, ComfyUI, SearXNG, lokale Sprach- und Embedding-Modelle, Bild- und Videogenerierung, RAG, spezialisierte Agenten, MCP, Local Control und persistentes Memory zu einem Gesamtsystem. Mit dem aktuell veröffentlichten Stand 2.17 hat sich dabei auch die Rolle des Systems verändert: Aus einer Umgebung zum Ausführen lokaler KI-Modelle wird zunehmend ein lokaler Assistent, der Wissen abrufen, Werkzeuge benutzen, Aufgaben auf dem Rechner durchführen und ausgewählte Informationen über mehrere Gespräche hinweg behalten kann.

Warum überhaupt ein eigener KI-Stack?

Eine einzelne KI-Anwendung zu installieren, ist heute vergleichsweise einfach. LM Studio lässt sich mit wenigen Schritten einrichten, Open WebUI ebenfalls. ComfyUI kann aus einem Repository installiert werden, und auch SearXNG ist für sich betrachtet kein außergewöhnlich komplizierter Dienst. Die eigentliche Herausforderung beginnt erst dann, wenn diese Komponenten zuverlässig miteinander arbeiten sollen.

Dann stellen sich ganz andere Fragen. Welche Anwendung stellt welchen API-Endpunkt bereit? Welches Modell wird für den normalen Chat verwendet, welches ausschließlich für Embeddings und welches für Bild- oder Videogenerierung? Was passiert, wenn ein Modelldownload nach mehreren Gigabyte abbricht? Welche Komponente darf bei einem Upgrade verändert werden, und welche vorhandene Installation muss erhalten bleiben? Wie lässt sich feststellen, ob ein Installationsschritt tatsächlich den gewünschten Zielzustand erzeugt hat und nicht lediglich das Installationsskript mit Exitcode 0 beendet wurde?

Dazu kommen klassische Betriebsfragen. Das Gesamtsystem muss gestartet und gestoppt werden können, ohne dass man jedes Mal wissen muss, welche Prozesse unter Windows und welche Dienste innerhalb von WSL2 laufen. Ein notwendiger Windows-Neustart während einer Installation darf nicht dazu führen, dass der Installationszustand verloren geht. Bei einem Upgrade muss nachvollziehbar sein, welche Änderungen zu welcher Transaktion gehören, und ein Repair darf vorhandene funktionierende Konfigurationen nicht unbeabsichtigt überschreiben.

Der KI-Stack ist deshalb inzwischen deutlich weniger ein Projekt zur Installation einzelner KI-Werkzeuge und wesentlich stärker ein Projekt zur Integration, Automatisierung und zum Betrieb einer lokalen KI-Plattform geworden.

Was bedeutet „lokal“?

Lokale KI bedeutet in diesem Projekt nicht, dass der Rechner vollständig vom Internet getrennt arbeitet. Schon die Installation benötigt externe Quellen, Anwendungen und Modelle müssen heruntergeladen werden, und eine Websuche über SearXNG benötigt naturgemäß Zugriff auf externe Webseiten und Suchquellen.

Der entscheidende Unterschied liegt an einer anderen Stelle: Die eigentliche Inference der Sprach-, Embedding-, Bild- und Videomodelle findet lokal auf der eigenen Hardware statt. Open WebUI, LM Studio und ComfyUI laufen ebenfalls auf dem eigenen System. Eigene Dokumente können lokal verarbeitet, segmentiert, eingebettet und durchsucht werden, ohne dass sie dafür zwangsläufig an einen externen KI-Anbieter übertragen werden müssen.

Auch die neueren Funktionen bleiben diesem Prinzip treu. MCP-basierte Tool-Aufrufe können vollständig lokal erfolgen, Local Control arbeitet auf dem eigenen Rechner, und das persistente Memory aus 2.17 bleibt in der lokalen Open-WebUI-Datenbank. „Lokal“ bedeutet damit vor allem, dass Datenhaltung, Inference und Kontrollschicht in der eigenen Umgebung bleiben, während externe Zugriffe gezielt und nachvollziehbar dort eingesetzt werden können, wo sie tatsächlich benötigt werden.

Architektur des KI-Stacks

Die Architektur basiert auf einem Windows-11-Host, kombiniert aber bewusst Windows-native Anwendungen mit Linux-Diensten innerhalb von WSL2 und Debian. Diese Aufteilung ist kein historischer Zufall. Einige Komponenten lassen sich unter Windows sehr komfortabel betreiben, während klassische Linux-Dienste wie nginx, uWSGI, SearXNG oder Valkey in einer Debian-Umgebung wesentlich natürlicher aufgehoben sind.

Open WebUI bildet die zentrale Benutzeroberfläche und damit das eigentliche Cockpit des Stacks. Von dort werden Aufgaben an die jeweils zuständigen Backend-Komponenten weitergegeben. Für normale Chat-Anfragen wird das lokale Sprachmodell über LM Studio angesprochen. Eigene Dokumente laufen über den RAG- und Knowledge-Pfad. Bild- und Videogenerierung werden über ComfyUI ausgeführt, aktuelle Informationen können über SearXNG recherchiert werden, und spezialisierte Werkzeuge werden über MCP beziehungsweise die Agentenprofile eingebunden.

Mit den Releases 2.14 bis 2.17 kamen weitere Ebenen hinzu. Open Terminal stellt den lokalen Ausführungspfad bereit, MCP standardisiert die Tool-Schnittstelle, Local Control nutzt diese Werkzeuge für konkrete lokale Aktionen und das native Memory von Open WebUI ergänzt langfristigen Benutzerkontext.

Vereinfacht sieht der heutige Stack so aus:

Das Architekturdiagramm zeigt den aktuellen Gesamtstand des KI-Stacks. Open WebUI bildet die zentrale Benutzeroberfläche, während LM Studio, RAG/Knowledge, ComfyUI, SearXNG, MCP Runtime, Open Terminal, Local Control und persistentes Memory klar getrennte Aufgaben übernehmen. Windows 11 und WSL2/Debian bilden die Laufzeitebenen, während die NVIDIA-GPU ausschließlich für die tatsächlichen Inference- und Embedding-Pfade genutzt wird.

Windows 11 und WSL2/Debian als gemeinsame Plattform

Windows 11 bildet den Host des Systems. Hier laufen unter anderem PowerShell 7, der Complete Installer, LM Studio, ComfyUI sowie die zentralen Lifecycle- und Administrationsskripte. Mein Entwicklungssystem verwendet aktuell eine NVIDIA RTX 5090 mit 32 GB VRAM. Der Stack selbst ist jedoch nicht auf genau diese Grafikkarte festgelegt; welche Modelle sinnvoll betrieben werden können, hängt von VRAM, Modellarchitektur, Quantisierung und dem jeweiligen GPU-Offload ab.

WSL2 stellt parallel eine Debian-Laufzeit bereit. Dort befinden sich vor allem die Linux-basierten Infrastrukturkomponenten wie SearXNG und dessen Webservice-Umgebung. Diese Trennung hat sich als sinnvoll erwiesen, weil nicht versucht werden muss, jeden Dienst künstlich in eine Windows-native Betriebsform zu pressen.

Windows und Debian bilden deshalb keine zwei getrennten KI-Stacks. Sie sind zwei Laufzeitebenen desselben Systems und werden vom Installer und den Lifecycle-Funktionen als gemeinsame Plattform behandelt.

Open WebUI als zentrale Benutzeroberfläche

Open WebUI ist die Oberfläche, über die der Benutzer mit dem Gesamtsystem arbeitet. Die Idee besteht darin, nicht ständig zwischen LM Studio, ComfyUI, SearXNG und unterschiedlichen technischen Interfaces wechseln zu müssen. Open WebUI fungiert stattdessen als Integrationspunkt für Chat, Websuche, RAG, Bild- und Videogenerierung, spezialisierte Agenten, MCP-Tools und persistentes Memory.

Dazu kommen eigene Erweiterungspakete des Projekts. Das OpenWebUI Agent Pack verwaltet die vorgesehenen Workspace-Profile und ihre Fähigkeiten. Das Visual Pack bildet die Verbindung zu den ComfyUI-Workflows und sorgt unter anderem dafür, dass erzeugte Bilder oder Videos wieder als persistente Anhänge im jeweiligen Chat zur Verfügung stehen. Spezialisierte Packs wie der Ballistics Pack ergänzen zusätzliche fachliche Profile, ohne daraus allgemeine Systemrechte für alle Agenten abzuleiten.

Open WebUI ist damit längst nicht mehr nur ein alternatives Chat-Frontend für LM Studio. Es ist die zentrale Vermittlungsschicht zwischen Benutzer, Modellen, Wissen und Werkzeugen.

LM Studio und die lokalen Sprachmodelle

LM Studio bildet die lokale Runtime für die regulären Sprachmodelle und stellt dafür einen OpenAI-kompatiblen API-Endpunkt bereit. Im Stack läuft dieser standardmäßig lokal unter:

http://127.0.0.1:1234

Andere Komponenten müssen dadurch nicht wissen, wie LM Studio intern ein Modell lädt oder welche GPU-Konfiguration verwendet wird. Sie kommunizieren über eine definierte lokale API.

Als reguläres Chatmodell verwendet der aktuelle Stack qwen3.6-27b-uncensored-heretic-v2-native-mtp-preserved. Weitere Modelle können parallel getestet oder für spezielle Aufgaben eingesetzt werden, der definierte Architekturvertrag arbeitet jedoch bewusst mit einem festgelegten Hauptmodell. Dadurch bleibt nachvollziehbar, welcher Modellstand Teil des jeweils getesteten und freigegebenen Systems ist.

Nomic ist kein zweites Chatmodell

Für semantische Suche und RAG wird ein völlig anderer Modelltyp benötigt. Der Stack verwendet dafür Nomic Embed Text v1.5 mit 768-dimensionalen Embeddings. Nomic erzeugt keine normalen Chatantworten, sondern numerische Repräsentationen von Text.

Texte mit ähnlicher Bedeutung liegen dadurch im Vektorraum näher beieinander als inhaltlich völlig unterschiedliche Texte. Diese semantische Ähnlichkeit bildet die Grundlage der lokalen Wissenssuche.

Die Rollen bleiben deshalb bewusst getrennt:

Chat-LLM
→ Textverständnis, Schlussfolgerung und Antwortgenerierung

Nomic Embed Text
→ Embeddings und semantische Suche

Diese Trennung ist wesentlich, weil Sprachmodelle und Embedding-Modelle völlig unterschiedliche Aufgaben übernehmen, obwohl beide mit Text arbeiten.

RAG – eigenes Wissen für den lokalen Assistenten

Retrieval Augmented Generation, kurz RAG, ist inzwischen ein fester Bestandteil des KI-Stacks. Ein Sprachmodell kennt zunächst nur sein Trainingswissen und die Informationen, die ihm im aktuellen Kontext übergeben werden. Eigene technische Dokumentationen, Projektunterlagen, PDFs, Handbücher oder interne Wissensbestände kennt es nicht automatisch.

RAG ergänzt deshalb vor der eigentlichen Antwortgenerierung einen Suchprozess. Dokumente werden eingelesen, Text wird extrahiert und in kleinere Abschnitte zerlegt. Für diese Chunks werden Embeddings erzeugt, die zusammen mit Quelleninformationen und weiteren Metadaten in einer durchsuchbaren Wissensstruktur abgelegt werden.

Stellt der Benutzer später eine Frage, wird auch dafür eine semantische Repräsentation erzeugt. Das System sucht anschließend nicht nur nach identischen Begriffen, sondern nach inhaltlich passenden Textabschnitten. Diese relevanten Chunks werden zusammen mit der Benutzerfrage an das Sprachmodell übergeben, das daraus die eigentliche Antwort erzeugt.

RAG-Agenten zuverlässig betreiben

Wer tiefer in Chunking, Embeddings, Vektorsuche, Retrieval und die Abgrenzung zu Memory einsteigen möchte, findet die technische Vertiefung im separaten RAG-Artikel.

Der entscheidende Punkt bleibt: RAG trainiert das Chatmodell nicht neu. Die Dokumente werden zur Laufzeit als zusätzliche Wissensquelle verwendet. Damit kann der Wissensbestand unabhängig vom Sprachmodell aktualisiert werden, ohne jedes Mal ein Modell neu zu trainieren.

Globales und projektbezogenes Wissen

Das RAG-System ist inzwischen über die ursprüngliche einfache globale Wissenssammlung hinausgewachsen. Neben globalen Wissensbeständen können projektbezogene Collections verwendet werden. Dadurch muss nicht jedes Dokument jedem Agenten und jedem Projekt gleichermaßen zur Verfügung stehen.

Diese Trennung ist aus meiner Sicht langfristig wichtiger als die reine Anzahl indexierter Dokumente. Ein brauchbares Wissenssystem muss nicht nur Informationen finden können, sondern auch kontrollieren, welcher Kontext für welche Aufgabe überhaupt relevant ist.

Metadaten wie Quelldatei und Chunk-Position bleiben dafür wichtig. Sie sorgen dafür, dass Retrieval nicht zu einer undurchsichtigen Textsammlung wird, sondern Informationen weiterhin einer nachvollziehbaren Quelle zugeordnet werden können.

RAG, Websuche und Memory sind unterschiedliche Wissensebenen

RAG und Websuche werden häufig zusammengefasst, erfüllen aber unterschiedliche Aufgaben. RAG arbeitet mit einem kontrollierten eigenen Wissensbestand, während SearXNG aktuelle externe Informationen bereitstellt. Das Modell selbst besitzt zusätzlich sein eigenes Trainingswissen.

Mit 2.17 kommt eine vierte Ebene hinzu: Memory. Memory speichert keine Dokumentensammlung und ersetzt weder RAG noch Websuche. Es hält ausgewählte langfristig relevante Informationen über den Benutzer oder die Zusammenarbeit über mehrere Chats hinweg verfügbar.

Damit besitzt der Stack inzwischen vier klar getrennte Wissensquellen:

1. Modellwissen
   Wissen aus dem Training des Sprachmodells

2. RAG
   kontrollierter eigener Dokumentenbestand

3. Websuche
   aktuelle externe Informationen

4. Memory
   langfristig relevante Informationen aus der Zusammenarbeit

Gerade diese Trennung ist wichtig. Ein Modell sollte nicht so behandelt werden, als besitze es automatisch aktuelles Wissen, und ein Memory-Eintrag sollte nicht mit einer dokumentierten Quelle verwechselt werden.

Persistentes Memory mit KI-Stack 2.17

KI-Stack 2.17 ergänzt persistentes Memory, ohne dafür einen zusätzlichen Memory-Service oder eine weitere Datenbank einzuführen. Stattdessen wird die bereits vorhandene native Memory-Funktion von Open WebUI verwendet. Die Informationen bleiben lokal in webui.db, sind benutzerbezogen und können über mehrere Chats hinweg genutzt werden.

Nicht jedes Profil erhält diese Fähigkeit automatisch. Allgemeine und technische Assistenten können von langfristigem Kontext profitieren, während beispielsweise ein Research-Agent bewusst stärker an aktuelle Quellen und den jeweiligen Rechercheauftrag gebunden bleibt.

Persistentes Memory wird außerdem nicht als ungefiltertes Langzeitarchiv verstanden. Nicht jede Information eines Chats sollte dauerhaft gespeichert werden. Stabile Präferenzen, Architekturentscheidungen oder langfristige Arbeitsbedingungen sind sinnvoll; Passwörter, Tokens oder kurzfristige Systemzustände gehören dagegen nicht in ein Memory.

KI-Stack 2.17 – Persistentes Memory

Im separaten 2.17-Artikel beschreibe ich die Abgrenzung zwischen Chatkontext, RAG und Memory sowie die Architektur von Open WebUI Native Memory, webui.db, Online-Backup und kontrolliertem Restore ausführlicher.

SearXNG für aktuelle Informationen

Für aktuelle Informationen verwendet der KI-Stack SearXNG. Der Dienst läuft innerhalb der Debian-Umgebung hinter einer klassischen Webservice-Architektur. nginx übernimmt die Rolle des Reverse Proxy, dahinter stellt uWSGI die SearXNG-Anwendung bereit und Valkey dient ergänzend als Speicher für Cache- beziehungsweise Rate-Limiting-Funktionen.

Vereinfacht entsteht:

Open WebUI
   ↓
nginx
   ↓
uWSGI
   ↓
SearXNG
   ↔
Valkey
   ↓
Internet / Suchquellen

Der Stack erkennt bereits vorhandene und funktionsfähige Dienste, statt bei einem Upgrade blind eine zweite SearXNG-Instanz zu erzeugen. Dieser Readback ist wichtig, weil ein zustandsorientierter Installer nicht nur prüfen darf, ob sein eigener historischer Installationsmarker existiert, sondern ob der reale Dienst tatsächlich gesund ist.

Tools und Agenten

Der Begriff „Agent“ wird im KI-Umfeld inzwischen sehr weit verwendet. Im KI-Stack bedeutet er nicht, dass ein Sprachmodell automatisch uneingeschränkten Zugriff auf den Rechner erhält. Stattdessen werden spezialisierte Profile mit definierten Fähigkeiten und Werkzeugen aufgebaut.

Ein Research-Agent benötigt beispielsweise Websuche, lokalen Wissenszugriff und einen Code Interpreter, aber nicht automatisch Shell- oder Administrationsrechte. Ein technisches Profil kann dagegen bewusst lokale Werkzeuge erhalten. Die Fähigkeiten eines Agenten werden damit nicht allein durch das Sprachmodell bestimmt, sondern durch das Zusammenspiel aus Prompt, Profil, Tool-Bindings, Knowledge-Bindings und Betriebssystemberechtigungen.

Diese Trennung ist für agentische Systeme entscheidend. Je leistungsfähiger ein Modell wird, desto wichtiger wird die Frage, was es tatsächlich erreichen darf.

MCP – die Standardschnittstelle für Werkzeuge

Mit KI-Stack 2.15 wurde MCP, das Model Context Protocol, zur standardisierten Tool-Schnittstelle für die terminalfähigen Profile. Open WebUI spricht damit nicht mehr für jede Fähigkeit eine individuell aufgebaute Integration an, sondern nutzt eine gemeinsame, klar definierte Verbindungsschicht zu den bereitgestellten Werkzeugen. MCP standardisiert die Kommunikation zwischen einer KI-Anwendung und externen Fähigkeiten und verhindert damit, dass für jedes Werkzeug dauerhaft eine proprietäre Frontend-Integration aufgebaut werden muss.

Im KI-Stack sitzt die MCP Runtime zwischen Open WebUI und der lokalen Ausführungsschicht. Open Terminal übernimmt darunter den eigentlichen Zugriff auf Dateien, Prozesse und Befehle. Die vorhandene Runtime stellt unter anderem Werkzeuge zum Lesen und Schreiben von Dateien, zur Prozesssteuerung, Suche und allgemeinen Befehlsausführung bereit.

Vereinfacht:

Open WebUI
   ↓
MCP
   ↓
MCP Runtime
   ↓
Open Terminal
   ↓
lokales System

MCP ersetzt dabei weder PowerShell noch APIs oder andere Systemwerkzeuge. Es ist vielmehr die standardisierte Verbindungsschicht, über die ein KI-Agent diese Fähigkeiten finden und verwenden kann.

Model Context Protocol (MCP) erklärt

Im separaten MCP-Grundlagenartikel gehe ich deutlich tiefer auf Host, Client und Server, Tools, Resources und Prompts, Function Calling, Transport, Security sowie die aktuelle stateless Architektur von MCP ein.

Open Terminal – kontrollierter lokaler Ausführungspfad

Open Terminal wurde mit KI-Stack 2.14 als verwaltete Komponente in den Complete Installer integriert. Es stellt einen lokalen Tool- und Terminal-Backend-Dienst bereit und kann unter anderem auf Dateisystem, PowerShell, WSL, Git und lokale Prozesse zugreifen.

Der Dienst bindet ausschließlich an localhost und verwendet ein lokal geschütztes Credential. Open WebUI bleibt die alleinige Benutzeroberfläche; Open Terminal ist kein zweites Frontend, sondern eine Ausführungsschicht im Hintergrund.

Mit 2.15 wurde dieser direkte Tool-Zugriff über MCP standardisiert. Der bisherige Open-Terminal-Pfad wurde dabei nicht sofort entfernt, sondern als funktionierender Rückfallweg erhalten.

KI-Stack 2.14 & 2.15 – Vom lokalen Terminalzugriff zu MCP

Der Detailartikel zu 2.14 und 2.15 beschreibt die Entwicklung vom sicheren lokalen Terminal-Backend bis zur standardisierten MCP-Tool-Schicht.

Local Control – wenn der Assistent tatsächlich handeln kann

Mit KI-Stack 2.16 wurde aus dem vorhandenen Tool-Zugriff ein allgemeiner Local-Control-Ansatz. Der entscheidende Schritt bestand dabei nicht darin, für jede Windows-Funktion ein eigenes MCP-Tool zu bauen. Die vorhandenen Werkzeuge, run_command, PowerShell und die bereits vorhandenen Lifecycle-Skripte wurden als ausreichend für einen großen Teil der lokalen Steuerung validiert.

Der Assistent kann dadurch beispielsweise Dateien lesen und verändern, Prozesse analysieren, Windows-Dienste oder geplante Tasks verwalten, strukturierte PowerShell-Abfragen durchführen, WSL und Docker ansprechen oder KI-Stack-Komponenten über deren vorhandene Betriebsfunktionen steuern.

PowerShell spielt dabei eine zentrale Rolle, weil Windows-Verwaltungsfunktionen bereits strukturiert zur Verfügung stehen. Anstatt Hunderte Spezialtools zu entwickeln, kann ein generisches MCP-Werkzeug auf bewährte Systemwerkzeuge zugreifen und deren Ergebnisse beispielsweise als JSON zurückgeben.

Local Control bedeutet allerdings nicht unbegrenzte Autonomie. Benutzerauftrag, Agentenprofil, verfügbare Tools, Betriebssystemberechtigungen und konkrete Ressourcen bilden weiterhin die Grenzen dessen, was der Assistent tun kann.

KI-Stack 2.16 – Local Control

Der 2.16-Artikel beschreibt die Local-Control-Architektur, PowerShell als universelle Steuerungsschicht, die bewusste Entscheidung gegen dutzende Windows-Spezialtools und das dahinterliegende Berechtigungsmodell.

ComfyUI als visuelle Workflow-Engine

Für Bild- und Videogenerierung verwendet der KI-Stack ComfyUI. ComfyUI ist dabei nicht die primäre Benutzeroberfläche des Systems, sondern die Workflow-Engine für reproduzierbare generative Pipelines.

Open WebUI nimmt die Benutzeranfrage entgegen. Das Visual Pack übersetzt diese in den vorgesehenen Workflow und übergibt ihn an ComfyUI. Dort findet die eigentliche visuelle Inference statt. Das Ergebnis wird anschließend wieder in den jeweiligen Chat zurückgeführt.

Die Rollen bleiben damit sauber getrennt:

Open WebUI
→ Benutzeroberfläche

Visual Pack
→ Integrationsschicht

ComfyUI
→ Workflow Engine und Inference

Die Stärke dieses Modells liegt darin, dass sich komplexe ComfyUI-Workflows verwenden lassen, ohne dass der normale Benutzer für jede Generierung im Node-Editor arbeiten muss.

Bildgenerierung mit Z-Image Turbo und Chroma1

Für Bildgenerierung sind im aktuellen Stack Z-Image Turbo und Chroma1 als die vorgesehenen Bildpfade festgelegt. Damit wurde die frühere Experimentierphase mit immer weiteren Modellfamilien bewusst reduziert.

Diese Konsolidierung ist ein wichtiger Teil des Architekturgedankens. Ein produktiver Stack wird nicht automatisch besser, wenn jedes jemals getestete Bildmodell dauerhaft installiert bleibt. Unterschiedliche Modelle bedeuten zusätzliche Gewichte, unterschiedliche Workflow-Anforderungen, mehr Abhängigkeiten und mehr Testaufwand.

Entscheidend ist deshalb nicht die größtmögliche Modellbibliothek, sondern eine begrenzte Auswahl definierter Modelle, deren Rolle und Integration klar beschrieben sind.

Videogenerierung mit WAN2.2

Für Videogenerierung verwendet der KI-Stack weiterhin WAN2.2. Videogenerierung ist deutlich GPU- und speicherintensiver als ein normaler LLM-Chat, lässt sich aber über dieselbe Benutzeroberfläche integrieren.

Der Benutzer arbeitet weiterhin in Open WebUI. Das Visual Pack übergibt die Aufgabe an ComfyUI, der definierte WAN-Workflow erzeugt das Video und das Ergebnis wird anschließend als persistenter Dateianhang wieder im Chat verfügbar.

Vereinfacht:

Open WebUI
   ↓
Visual Pack
   ↓
ComfyUI
   ↓
WAN2.2
   ↓
Video
   ↓
Open WebUI

Damit werden Text-, Bild- und Videogenerierung nicht dadurch vereinheitlicht, dass dasselbe Modell alles erledigen soll, sondern durch eine gemeinsame Integrationsschicht über spezialisierte Modelle.

Codex Local und lokale Coding-Werkzeuge

Der Stack enthält außerdem Codex Local als isolierte Komponente. Die lokale Codex-Umgebung besitzt ein eigenes CODEX_HOME, sodass sie nicht unkontrolliert den globalen Benutzerzustand einer vorhandenen Codex-Installation verwendet.

Die lokale Coding-Integration verwendet ebenfalls den vorhandenen Modell-Endpunkt von LM Studio. Damit kann Codebearbeitung in die lokale Architektur eingebunden werden, ohne dass dafür zwingend ein Cloudmodell angesprochen werden muss.

Das Projekt entwickelt diesen Bereich weiter in Richtung lokal steuerbarer Entwicklungs- und Automatisierungswerkzeuge. Wichtig bleibt dabei dieselbe Grundregel wie beim übrigen Stack: Der Erfolg eines Startskripts ist nicht ausreichend. Entscheidend ist, ob der erwartete Endpunkt beziehungsweise die gewünschte Funktion tatsächlich verfügbar ist.

Der Complete Installer als Teil der Plattform

Mit wachsendem Funktionsumfang ist der Complete Installer zu einem der wichtigsten Bestandteile des KI-Stacks geworden. Die eigentliche Herausforderung besteht längst nicht mehr nur darin, einzelne Anwendungen zu installieren. Entscheidend ist vielmehr, einen neuen Rechner reproduzierbar in denselben definierten Zustand zu bringen und diesen Zustand später auch prüfen, aktualisieren, reparieren oder kontrolliert zurücksetzen zu können.

Deshalb behandelt der KI-Stack Installation nicht als einmalige Aneinanderreihung von Setup-Befehlen, sondern als zustandsorientierten und transaktionsgesicherten Prozess. Komponenten werden in klar getrennten Bereichen vorbereitet, installiert, integriert und anschließend technisch überprüft. Erst wenn der erwartete Zielzustand tatsächlich erreicht wurde, gilt ein Schritt als erfolgreich abgeschlossen.

Die historische Grundstruktur des Installers besteht aus den Phasen Foundation, Runtime, Python/Git, ComfyUI, Models/Workflows, Applications, Integration, Cutover und abschließender Validation. Im Laufe der Entwicklung sind weitere isolierte Komponenten wie RAG, Agent Pack, Visual Pack, Ballistics Pack, Codex Local, Open Terminal und MCP Runtime hinzugekommen. Diese Erweiterungen werden nicht künstlich in die ursprüngliche Nummernfolge gepresst, sondern über eigene Komponentenverträge in den Complete Installer eingebunden.

Installation vom Betriebssystem bis zur technischen Abnahme

Zu Beginn werden die Voraussetzungen des Windows-Hosts geschaffen. Dazu gehören insbesondere die Systembasis, WSL2 sowie die benötigten Laufzeitkomponenten. Python und Git gehören ebenfalls zum definierten Zielzustand und werden nicht einfach als beliebige bereits vorhandene Werkzeuge vorausgesetzt.

Darauf bauen ComfyUI, Anwendungen wie LM Studio und Open WebUI sowie die vorgesehenen Modelle und Workflows auf. Gerade bei großen Modellgewichten ist ein reproduzierbarer Download- und Prüfprozess wichtig. Der Installer erkennt bereits vorhandene gültige Dateien, kann vorbereitete lokale Caches verwenden und lädt nur dann neu, wenn dies tatsächlich notwendig ist. Nach dem Download werden Modelle nicht nur anhand ihres Dateinamens, sondern über definierte Größen- und Hash-Verträge geprüft.

Die Integrationsphase verbindet die zuvor einzeln funktionierenden Komponenten zu einem Gesamtsystem. Dazu gehören unter anderem SearXNG, Open-WebUI-Konfigurationen, RAG-Bindings, Agentenprofile, Visual Workflows und MCP-Verbindungen. Dabei zählt nicht nur, ob ein Installer-Marker vorhanden ist, sondern ob ein vorhandener Dienst tatsächlich gesund und verwendbar ist.

Anschließend folgt der Übergang vom installierten Komponentenbestand zum betriebsbereiten KI-Stack. Cutover und Validation prüfen deshalb nicht nur Dateien und Prozesse, sondern soweit möglich auch reale Endpunkte und Integrationen. Ein erfolgreicher Skriptlauf ist noch kein Beweis dafür, dass eine Anwendung wirklich funktioniert. Genau deshalb versucht der Stack, den gewünschten Zielzustand über Readbacks und Acceptance-Tests tatsächlich nachzuweisen.

Transaktionsgesicherte Installation und Recovery

Jeder Complete-Installer-Lauf besitzt eine eigene TransactionId. Der zugehörige Zustand und transaktionsbezogene Backups werden getrennt gespeichert, sodass später nachvollziehbar bleibt, welche Änderungen zu welchem Installationslauf gehören. Diese Trennung bildet die Grundlage für Resume, Repair und Rollback.

Ein notwendiger Windows-Neustart oder eine andere Unterbrechung muss deshalb nicht bedeuten, dass die Installation wieder von vorne beginnt. Resume setzt eine bestehende Transaktion fort und prüft bereits abgeschlossene Schritte erneut auf ihren aktuellen Zustand. Sind sie weiterhin konform, werden sie nicht unnötig wiederholt.

Audit, Validate, Repair und Rollback erfüllen dabei bewusst unterschiedliche Aufgaben. Audit untersucht das vorhandene System read-only, Validate prüft den erwarteten Zielzustand, Repair korrigiert erkannte Abweichungen und Rollback nimmt ausschließlich die Änderungen der jeweiligen Transaktion zurück. Ein Rollback bedeutet ausdrücklich nicht, den gesamten KI-Stack oder bereits vorher vorhandene gültige Modelle und Daten zu löschen.

Vor einer echten Änderung können Komponenten außerdem über Self-Test und Dry Run geprüft werden. Damit lässt sich zwischen Paketprüfung, Planung und tatsächlicher Ausführung unterscheiden. Der Installer wird dadurch komplexer als ein klassisches Setup, dafür aber deutlich nachvollziehbarer und kontrollierbarer.

Lifecycle nach der Installation

Nach erfolgreicher Installation wird der Stack über zentrale Lifecycle-Kommandos gestartet, gestoppt und geprüft:

Start-KIStack.cmd
Stop-KIStack.cmd
Status-KIStack.cmd

Neue Komponenten wie Open Terminal und MCP wurden in dieses bestehende Betriebsmodell integriert, statt jeweils eigene parallele Start- und Recovery-Verfahren einzuführen. Dadurch bleibt der Stack auch mit wachsendem Funktionsumfang als Gesamtsystem bedienbar.

Ein wichtiger Grundsatz ist dabei, dass Diagnose den Zustand nicht verändern darf. Ein Status- oder Audit-Aufruf soll nicht nebenbei einen ausgefallenen Dienst neu starten und damit genau den Fehlerzustand beseitigen, der untersucht werden soll. Start, Stop, Diagnose und Repair bleiben deshalb bewusst getrennte Funktionen.

Supply-Chain-Sicherheit und reproduzierbare Releases

Neben Installation und Betrieb spielt auch die Nachvollziehbarkeit der Releases eine zunehmend wichtige Rolle. Änderungen laufen über geschützte Entwicklungs- und Review-Prozesse, während automatisierte Prüfungen unter anderem Secrets, PowerShell-, Python- und allgemeine Codequalität kontrollieren.

Heruntergeladene Payloads und Modellartefakte werden über definierte Größen- und SHA-256-Verträge geprüft. Für Release-Artefakte werden außerdem SPDX-2.3-SBOMs und Build Attestations erzeugt. Dadurch lässt sich nachvollziehen, aus welchem Source-Stand ein Paket entstanden ist und ob ein heruntergeladenes Artefakt dem vorgesehenen Release entspricht.

Diese Mechanismen garantieren keine fehlerfreie Software. Sie sorgen aber dafür, dass Installation, Update, Recovery und Releaseprozess nicht als voneinander unabhängige Einzelaufgaben behandelt werden, sondern als zusammenhängender Teil der KI-Stack-Plattform.

Wo steht der KI-Stack mit Version 2.17?

Die sichtbaren Bestandteile eines KI-Stacks sind naturgemäß die Modelle. Ein großes Sprachmodell, Z-Image, Chroma oder WAN2.2 sind auf den ersten Blick interessanter als Transaktionsdateien, Hash-Prüfungen oder Recovery-Skripte.

Während der Entwicklung hat sich für mich jedoch immer deutlicher gezeigt, dass gerade die weniger sichtbare Plattformebene entscheidet, ob aus einem Experiment ein betreibbares System wird.

Der aktuelle Stack besteht deshalb aus zwei gleich wichtigen Ebenen.

Die sichtbare KI-Ebene umfasst unter anderem:

Open WebUI
LM Studio
lokales Sprachmodell
Nomic Embeddings
RAG / Knowledge
SearXNG
ComfyUI
Z-Image
Chroma
WAN2.2
Agenten
MCP
Local Control
Persistent Memory

Darunter liegt die Plattform- und Betriebsebene:

Complete Installer
Komponentenverträge
Transaktionen
State
Backups
Resume
Audit
Validation
Repair
Rollback
Lifecycle
Release Attestation
SBOM
Recovery

Erst beide Ebenen zusammen ergeben den eigentlichen KI-Stack.

Die Entwicklung von 2.14 bis 2.17

Die Releases 2.14 bis 2.17 markieren einen deutlichen Entwicklungsschritt. Mit 2.14 kam ein kontrollierter lokaler Terminal- und Tool-Zugriff hinzu. Version 2.15 standardisierte diesen Weg über MCP, 2.16 machte daraus Local Control und 2.17 ergänzte persistentes Memory.

Vereinfacht:

2.14
Open Terminal
   ↓
kontrollierter lokaler Zugriff

2.15
MCP
   ↓
standardisierte Tool-Schnittstelle

2.16
Local Control
   ↓
lokale Aufgaben tatsächlich ausführen

2.17
Persistent Memory
   ↓
relevanten Kontext über Chats hinweg behalten

Damit entwickelt sich der Stack schrittweise von einer Sammlung lokaler KI-Runtimes zu einem lokalen Assistentensystem mit Wissen, Werkzeugen, Handlungsfähigkeit und langfristigem Kontext.

Fazit

Das Ziel des KI-Stacks besteht ausdrücklich nicht darin, sämtliche verfügbaren KI-Technologien auf einem Rechner zu sammeln. Ein wichtiger Teil der Entwicklung besteht inzwischen sogar darin, experimentelle Altlasten wieder zu entfernen, Schnittstellen zu vereinheitlichen und die Rollen der verbleibenden Komponenten klarer festzulegen.

Das reguläre Sprachmodell übernimmt Chat, Textverständnis und Antwortbildung. Nomic stellt Embeddings für semantische Suche bereit. RAG ergänzt eigenes dokumentiertes Wissen, SearXNG aktuelle externe Informationen und Memory langfristigen Benutzerkontext. ComfyUI führt die visuellen Workflows mit Z-Image, Chroma und WAN2.2 aus. Open WebUI verbindet diese Funktionen in einer gemeinsamen Oberfläche.

MCP bildet die standardisierte Verbindung zu Werkzeugen, Open Terminal stellt den kontrollierten lokalen Ausführungspfad bereit und Local Control nutzt vorhandene Systemwerkzeuge für tatsächliche Aktionen auf dem Rechner. Darunter sorgt der Complete Installer dafür, dass aus diesen Funktionen kein zufälliger Entwicklungsrechner, sondern ein reproduzierbarer, prüfbarer und reparierbarer Systemzustand entsteht.

Der zentrale Grundsatz des Projekts bleibt damit unverändert:

Nicht möglichst viele KI-Tools auf einem Rechner, sondern ein reproduzierbarer lokaler KI-Stack, dessen Komponenten definierte Aufgaben, Schnittstellen, Berechtigungen und Betriebszustände besitzen.

Weiterführende Artikel zum KI-Stack

Der Hauptartikel beschreibt bewusst das Gesamtsystem. Einzelne Architekturthemen sind inzwischen umfangreich genug, um sie separat zu behandeln.

Model Context Protocol (MCP) erklärt

Model Context Protocol (MCP) erklärt – Architektur, Tools und warum KI diese Schnittstelle braucht

MCP bildet die standardisierte Verbindungsschicht zwischen KI-Anwendungen und externen Fähigkeiten. Der Grundlagenartikel erklärt Host, Client und Server, Tools, Resources und Prompts, Tool Calling, stdio und HTTP, Security, Berechtigungen sowie die Abgrenzung zu APIs, RAG und Memory.

KI-Stack 2.14 & 2.15 – Vom lokalen Terminalzugriff zu MCP

Die Releases 2.14 und 2.15 schaffen die technische Grundlage für lokale Werkzeuge. Open Terminal stellt zunächst einen kontrollierten Ausführungspfad bereit, bevor MCP als standardisierte Tool-Schicht darüber eingeführt wird.

KI-Stack 2.16 – Local Control

KI-Stack 2.16 – Local Control: Wenn der lokale KI-Assistent wirklich handeln kann

Mit 2.16 wird aus dem Tool-Zugriff eine allgemeine Local-Control-Schicht. Der Artikel zeigt, wie MCP, run_command, PowerShell, WSL, Docker und bestehende KI-Stack-Skripte zusammenarbeiten und warum dafür bewusst keine zweite Windows-Control-Runtime gebaut wurde.

KI-Stack 2.17 – Persistentes Memory

KI-Stack 2.17 – Persistentes Memory: Wenn sich der lokale Assistent Dinge merken kann

Version 2.17 ergänzt langfristigen lokalen Kontext auf Basis der nativen Memory-Funktion von Open WebUI. Der Artikel erklärt die Abgrenzung zu RAG und Chatkontext sowie Backup und Restore der zugrunde liegenden webui.db.

Retrieval Augmented Generation – RAG

RAG-Agenten zuverlässig betreiben

Der RAG-Artikel vertieft die Verarbeitung eigener Dokumente, Chunking, Embeddings, semantische Suche, Knowledge Collections und die Frage, wie Quellenwissen zur Laufzeit in die Antwort eines lokalen Sprachmodells gelangt.

Projekt und Quellcode

Die Entwicklung des KI-Stacks erfolgt öffentlich auf GitHub:

https://github.com/robertbackhaus-a11y/KI-Stack

Dort befinden sich der vollständige Sourcecode, der Complete Installer, Installations- und Betriebsanleitungen, technische Dokumentation, Release-Unterlagen sowie die Validierungs- und Recovery-Werkzeuge.

Die eigentlichen Modellgewichte werden bewusst nicht in Git eingecheckt. Der Installer lädt sie anhand definierter Quellen und Integritätsverträge oder übernimmt bereits vorhandene beziehungsweise vorbereitete lokale Modelle.

Weitere Beiträge und Aktualisierungen zum Projekt finden sich auf okami.de in der Kategorie:

KI-Stack

https://www.okami.de/category/howtos/ki-stack