KI-Stack 2.4.0 ist final – der lokale Windows-KI-Stack wird erwachsen
Mit KI-Stack 2.4.0 ist die bisher umfangreichste Version meines lokalen KI-Stacks fertig. Aus dem ursprünglichen Ansatz, verschiedene lokale KI-Komponenten auf einem Windows-System zusammenzubringen, ist inzwischen ein transaktional installierbarer und reproduzierbarer KI-Stack geworden.
Der für mich entscheidende Unterschied zu den vorherigen Entwicklungsständen: 2.4.0 ist kein Release Candidate mehr.
Der Complete Installer 2.4.0 ist als Stable gekennzeichnet und wurde mit einer vollständigen realen Greenfield-Installation auf einem leeren physischen Zielsystem durchlaufen. Die Installation wurde vollständig abgeschlossen und der Installer beendete den Lauf erfolgreich mit Exitcode 0.
Was ist KI-Stack?
KI-Stack ist mein Versuch, die inzwischen ziemlich unübersichtlich gewordene Welt lokaler KI-Anwendungen in eine reproduzierbare Umgebung zu überführen.
Der Stack kombiniert unter anderem:
- Windows 11 als Host
- WSL2 mit Debian
- PowerShell 7
- Git und Python
- ComfyUI
- LM Studio
- Open WebUI
- SearXNG
- nginx
- Valkey
- lokale Sprachmodelle
- lokale Embeddings
- Bildgenerierung
- Videogenerierung
Entscheidend ist dabei nicht allein die Zusammenstellung der Programme.
Der eigentliche Schwerpunkt des Projekts liegt inzwischen darauf, Installation, Upgrade, Validierung und Wiederherstellung kontrollierbar zu machen.
Jedes ausführbare Paket des Projekts folgt deshalb einem gemeinsamen Konzept mit Self-Test, Dry Run, expliziter Ausführung, Transaktionsprotokollierung, Diagnose und Rollback.
Greenfield, Upgrade und Reparatur über denselben Installer
Eine der wichtigsten Änderungen in 2.4.0 ist für mich weniger spektakulär als ein neues KI-Modell, aber technisch wesentlich interessanter:
Der Installer verwendet denselben transaktionalen Pfad für
Greenfield-Installation, Upgrade und Reparaturplanung.
Damit wird nicht mehr davon ausgegangen, dass ein Zielsystem entweder komplett leer oder vollständig installiert ist.
Stattdessen wird der vorhandene Zustand geprüft.
Ist beispielsweise ein Modell bereits vorhanden und stimmen Dateiname, Größe und SHA-256, wird es wiederverwendet. Fehlende Modelle können automatisch aus revisionsgebundenen Quellen bezogen werden.
Auch unterbrochene Downloads müssen nicht zwangsläufig von vorne beginnen. Teildownloads können fortgesetzt werden. Stimmen anschließend Größe oder SHA-256 nicht, wird der betreffende Schritt als fehlgeschlagen behandelt.
Das klingt zunächst selbstverständlich.
Bei Installationen mit Modellen, die teilweise viele Gigabyte groß sind, macht es in der Praxis allerdings einen erheblichen Unterschied.
Transaktionen statt „Setup starten und hoffen“
Ein Kernprinzip von KI-Stack ist inzwischen die Transaktion.
Jeder Installationslauf bekommt eine eigene TransactionId.
Die dazugehörigen Zustände liegen beispielsweise unter:
C:\KI-Stack\state\complete-installer\<TransactionId>
Transaktionsbezogene Backups werden getrennt davon abgelegt:
C:\KI-Stack\backups\complete-installer\<TransactionId>
Damit stehen für einen begonnenen Installationslauf definierte Funktionen zur Verfügung:
Resume-KIStack-Installer.cmd
Start-KIStack-Audit.cmd
Start-KIStack-Validate.cmd
Start-KIStack-Repair.cmd
Start-KIStack-Rollback.cmd
Ein Resume arbeitet dabei nicht einfach stumpf alle Installationsschritte erneut ab. Bereits abgeschlossene oder inzwischen als konform erkannte Schritte werden geprüft und anschließend übersprungen.
Ein Rollback wiederum soll nur die Änderungen der jeweiligen Transaktion zurücknehmen. Bereits vorher vorhandene konforme Modelle und Benutzerdaten gehören nicht automatisch zum Löschumfang.
Gerade dieser Bereich hat während der Entwicklung deutlich mehr Aufwand verursacht als die eigentliche Installation einzelner KI-Anwendungen.
WSL2: Ein Windows-Neustart ist jetzt ein definierter Zustand
Ein schönes Beispiel dafür ist WSL2.
Auf einem Windows-System, auf dem WSL2 bislang nicht aktiviert wurde, kann Windows während der Einrichtung einen Neustart verlangen.
Frühere Installer behandeln solche Situationen gerne entweder als Fehler oder überlassen dem Benutzer anschließend die Frage, welche Schritte bereits durchgeführt wurden.
KI-Stack 2.4.0 behandelt den Neustart dagegen als fortsetzbaren Zustand.
Der Installer beendet sich in diesem Fall mit:
Exitcode 31
WINDOWS-NEUSTART ERFORDERLICH
und gibt die TransactionId aus.
Nach dem Neustart kann exakt diese Installation fortgesetzt werden:
Resume-KIStack-Installer.cmd <TransactionId>
Die bereits ausgeführten Schritte werden erneut geprüft und müssen nicht einfach blind noch einmal durchgeführt werden. Ein notwendiger Windows-Neustart löst deshalb auch keinen automatischen Rollback aus.
Das war einer der Punkte, die erst eine wirklich saubere Greenfield-Installation ermöglicht haben.
LM Studio wird Teil des verwalteten Starts
Eine weitere Besonderheit einer vollständig neuen Installation betrifft LM Studio.
LM Studio wird über winget installiert.
Auf einem komplett frischen System steht das Kommandozeilenwerkzeug lms jedoch nicht unmittelbar nach der Installation zur Verfügung. Es wird erst erzeugt, nachdem LM Studio erstmals gestartet und die Initialisierung abgeschlossen wurde.
KI-Stack 2.4.0 berücksichtigt auch diesen Zustand.
Der verwaltete Starter
Start-KIStack-LMStudio.cmd
prüft zunächst, ob lms bereits vorhanden ist.
Ist das der Fall, wird der lokale Server direkt gestartet:
lms server start --port 1234 --bind 127.0.0.1
Bei einer Greenfield-Installation kann zunächst die LM-Studio-GUI gestartet werden. Der Starter wartet begrenzt auf die Bereitstellung von lms, startet anschließend den API-Server und prüft, ob dieser tatsächlich unter
http://127.0.0.1:1234/v1/models
antwortet.
Das ist insbesondere für die Integration weiterer lokaler Werkzeuge wichtig.
Codex Local nutzt den lokalen LM-Studio-Endpunkt
Auch Codex Local ist in diesen Ablauf integriert.
Die Konfiguration setzt einen erreichbaren LM-Studio-Endpunkt unter
http://127.0.0.1:1234/v1/models
voraus.
Der Installer versucht deshalb nicht mehr, eine Konfiguration gegen einen möglicherweise noch nicht gestarteten Dienst vorzunehmen.
Stattdessen wird vorher der verwaltete LM-Studio-Start aufgerufen.
Ist der Endpunkt anschließend weiterhin nicht erreichbar, schlägt der entsprechende Installationsschritt mit einer nachvollziehbaren Fehlermeldung fehl.
Auch hier gilt:
Lieber ein deterministischer Fehler als ein scheinbar erfolgreiches Setup, das später nicht funktioniert.
Lokale Websuche mit SearXNG
Die lokale Suchintegration basiert weiterhin auf SearXNG.
Die Architektur besteht dabei nicht einfach aus einem einzelnen SearXNG-Prozess.
Der lokale Suchendpunkt wird über
uwsgi
bereitgestellt und hinter
nginx
betrieben.
Zusätzlich kommt
valkey-server
für lokale Cache- beziehungsweise Rate-Limiting-Funktionen zum Einsatz.
Der SearXNG-Endpunkt wird über /searxng veröffentlicht.
Eine weitere Änderung in 2.4.0 betrifft die Erkennung bereits vorhandener Installationen. Die Integrationskomponente akzeptiert sowohl den dedizierten
ki-stack-searxng.service
als auch einen vorhandenen generischen
uwsgi.service
als gültige laufende SearXNG-Instanz.
Damit wird verhindert, dass bei einem Upgrade versehentlich eine zweite Installation aufgebaut wird und anschließend Portkonflikte entstehen.
Klare Rollen für die KI-Modelle
Mit 2.4.0 habe ich außerdem die Modelllandschaft deutlich bereinigt.
Ein KI-Stack wird erstaunlich schnell unwartbar, wenn im Laufe der Zeit Modelle, Testkonfigurationen und ältere Workflows nebeneinander liegen bleiben.
Deshalb sind die Rollen inzwischen klarer definiert.
Chat
Heretic ist das Chat-LLM des aktuellen Stacks.
Embeddings
Für Embeddings wird ausschließlich Nomic verwendet.
Unter anderem kann
nomic-embed-text-v1.5.Q4_K_M.gguf
automatisch bereitgestellt werden.
Bildgenerierung
Der aktuelle visuelle Workflow basiert auf:
Z-Image Turbo
mit
Qwen3-4b-Z-Image-Engineer-V4-Q8_0.gguf
für die entsprechende Z-Image-Verarbeitung.
Videogenerierung
Für Video wird
WAN2.2 T2V 14B
mit den beiden vorgesehenen LightX2V-4-Step-LoRAs verwendet.
Ältere beziehungsweise experimentelle Pfade wie FLUX, Krea, Pony sowie WAN-5B/I2V gehören nicht mehr zum aktiven 2.4.0-Vertrag.
Diese Bereinigung halte ich inzwischen für genauso wichtig wie die Integration neuer Modelle.
Open WebUI als zentrale Oberfläche
Open WebUI bleibt die zentrale Benutzeroberfläche des Stacks.
Darüber werden unter anderem die lokalen Modelle und die verschiedenen KI-Funktionen zusammengeführt.
Der aktuelle Repository-Stand enthält unter anderem:
- OpenWebUI Agent Pack 1.8.9
- OpenWebUI Visual Pack 2.0.5
- Z-Image-Integration
- WAN2.2-Integration
- persistente MP4-Anhänge für erzeugte Videos
Das Visual Pack stellt damit Bild- und Videogenerierung innerhalb der lokalen OpenWebUI-Umgebung bereit.
Für bestimmte automatische OpenWebUI-Konfigurationen kann während der Installation temporär ein Administrator-API-Key angegeben werden.
Dieser wird verdeckt eingegeben, nur im Arbeitsspeicher verwendet und nicht dauerhaft gespeichert.
Wird kein API-Key bereitgestellt, kennzeichnet der Installer die betreffenden Schritte als notwendige manuelle Nacharbeit, statt so zu tun, als wäre die Konfiguration vollständig abgeschlossen.
Start, Stop und Status
Nach der Installation muss man sich nicht merken, welcher Dienst in WSL oder Windows in welcher Reihenfolge gestartet wird.
Dafür existiert eine Lifecycle-Schicht:
Start-KIStack.cmd
Stop-KIStack.cmd
Status-KIStack.cmd
Zusätzlich gibt es einen interaktiven Status:
Lifecycle\Status-KIStack-Interactive.cmd
Wichtig dabei:
Status ist read-only.
Ein Status-Aufruf startet nicht nebenbei ausgefallene Dienste und verändert damit nicht den Zustand des Systems.
Gerade bei Fehlersuche und Monitoring halte ich diese Trennung für wichtig.
Supply-Chain-Sicherheit wird Teil des Projekts
Mit wachsendem Umfang wird außerdem ein anderer Bereich wichtiger: die Frage, ob ein gebautes Release tatsächlich aus dem erwarteten Sourcecode entstanden ist.
Der Main-Branch des Projekts ist deshalb geschützt.
Änderungen werden über Pull Requests durchgeführt und durch mehrere automatische Prüfungen begleitet.
Dazu gehören unter anderem:
- Gitleaks
- PSScriptAnalyzer
- Bandit
- CodeQL
GitHub-Actions werden auf konkrete Commit-SHAs gebunden.
Payload-Verträge prüfen SHA-256-Werte anhand des tatsächlichen Inhalts.
Für Releases werden außerdem eine SPDX-2.3-SBOM und überprüfbare Build Attestations bereitgestellt.
Ein Release kann beispielsweise mit der GitHub CLI überprüft werden:
gh attestation verify .\<release>.zip --repo robertbackhaus-a11y/KI-Stack
Die dazugehörige SPDX-Attestation lässt sich ebenfalls prüfen:
gh attestation verify .\<release>.zip `
--repo robertbackhaus-a11y/KI-Stack `
--predicate-type https://spdx.dev/Document/v2.3
Das ist natürlich keine Garantie dafür, dass Software fehlerfrei ist.
Es macht aber nachvollziehbarer, welcher Sourcecode tatsächlich zu welchem Release-Artefakt geführt hat.
Vor der Installation: SHA-256 prüfen
Auch das heruntergeladene Installer-ZIP sollte vor dem Entpacken geprüft werden.
Für 2.4.0 werden deshalb das Release-ZIP und eine zugehörige SHA-256-Datei bereitgestellt.
Die Prüfung kann beispielsweise so erfolgen:
$zip = '.\KI-Stack-Complete-Installer-v2.4.0.zip'
$expected = (
(Get-Content "$zip.sha256" -Raw) -split '\s+'
)[0].ToLowerInvariant()
$actual = (
Get-FileHash -LiteralPath $zip -Algorithm SHA256
).Hash.ToLowerInvariant()
if ($actual -ne $expected) {
throw 'SHA-256 stimmt nicht überein.'
}
Erst danach sollte das Archiv entpackt werden.
Der eigentliche Meilenstein von Version 2.4.0
Die auffälligsten Teile eines lokalen KI-Stacks sind natürlich Modelle, Bildgeneratoren oder eine Weboberfläche.
Der größte Fortschritt von KI-Stack 2.4.0 liegt für mich aber woanders.
Nicht mehr:
Hier sind ein paar Skripte, mit denen diese Programme auf meinem Rechner funktionieren.
Sondern zunehmend:
Hier ist ein definierter Systemzustand, der installiert, geprüft, fortgesetzt, aktualisiert und im Fehlerfall wiederhergestellt werden kann.
Der Complete Installer ist dafür inzwischen nur die sichtbare Oberfläche.
Darunter befinden sich getrennte Komponenten für Foundation, Runtime, Python/Git, ComfyUI, Modelle, Anwendungen, Integration, Cutover, Recovery und Acceptance.
Der derzeit dokumentierte Gesamtstatus lautet:
TARGET_SYSTEM_ACCEPTANCE_PASSED
und der Complete Installer 2.4.0 ist als stabile, auf einem leeren realen Zielsystem erfolgreich getestete Version dokumentiert.
Damit ist KI-Stack 2.4.0 final.
Die Arbeit am Stack ist damit natürlich nicht beendet.
Aber 2.4.0 ist der Punkt, an dem ich erstmals guten Gewissens nicht mehr von einem Experiment oder Release Candidate spreche, sondern von einer reproduzierbar installierbaren Version des Systems.
Projekt
Der Sourcecode, die Installationsanleitungen und die technische Dokumentation befinden sich im GitHub-Repository: