KI-Stack 2.7.0 – was sich seit Version 2.4 verändert hat und wie es weitergeht
Mit KI-Stack 2.7.0 ist der lokale KI-Stack seit Version 2.4 in relativ kurzer Zeit deutlich weitergewachsen. Interessanterweise ging es dabei weniger darum, immer neue Modelle oder Anwendungen hinzuzufügen. Der Schwerpunkt lag vielmehr darauf, bereits vorhandene Funktionen wirklich belastbar in den Stack zu integrieren und Fehler zu beseitigen, die erst bei realen Installationen und Rollback-Szenarien sichtbar werden.
Version 2.4.0 war der erste große Meilenstein dieser Entwicklung. Der Complete Installer hatte damals eine vollständige Greenfield-Installation auf einem leeren physischen Zielsystem erfolgreich abgeschlossen. Damit war erstmals nachgewiesen, dass aus den vielen Einzelkomponenten tatsächlich ein reproduzierbar installierbares Gesamtsystem entstehen kann. Seitdem folgten mit 2.5.0, 2.6.0 und 2.7.0 drei Releases, die jeweils einen anderen Teil des Stacks weiter absichern: 2.5.0 integrierte RAG produktiv in den Stack, 2.6.0 vervollständigte die Rollback-Logik für RAG und 2.7.0 behebt einen realen Greenfield-Fehler im Zusammenspiel von Codex Local und dem erstmaligen Start von LM Studio.
Damit verschiebt sich der Charakter des Projekts weiter weg von „funktioniert auf meinem Rechner“ und hin zu einem Stack, dessen Installations- und Betriebszustände zunehmend reproduzierbar, überprüfbar und im Fehlerfall kontrolliert wiederherstellbar werden.
Rückblick: Was war Version 2.4.0?
Mit Version 2.4.0 bestand der KI-Stack bereits aus den wesentlichen Komponenten. Windows 11 bildet den Host, WSL2/Debian stellt die Linux-Laufzeit bereit. LM Studio übernimmt die lokale LLM-Inference, Open WebUI bildet die zentrale Benutzeroberfläche und ComfyUI führt Bild- und Videoworkflows aus. Dazu kommen SearXNG für die Websuche sowie nginx, uWSGI und Valkey als Infrastrukturkomponenten.
Auch die Modellrollen waren zu diesem Zeitpunkt bereits relativ klar definiert. Heretic dient als Chat-LLM, Nomic als Embedding-Modell, Z-Image Turbo übernimmt die Bildgenerierung und WAN2.2 T2V 14B die Videogenerierung. Technisch wichtiger als die einzelnen Modelle war aber die darunterliegende Installationsarchitektur. Der Complete Installer arbeitete bereits transaktionsbasiert und kannte Self-Test, Dry Run, Execute, State, Backup, Resume, Repair, Validation und Rollback.
Version 2.4.0 war dabei die erste veröffentlichte Version, die eine vollständige reale Greenfield-Installation erfolgreich abschließen konnte. Damit war die Plattform grundsätzlich vorhanden. Die folgenden Versionen konnten sich deshalb stärker darauf konzentrieren, einzelne Funktionsbereiche wirklich produktionsreif zu machen.
Version 2.5.0 – RAG wird ein echter Bestandteil des Stacks
Die wichtigste funktionale Erweiterung nach 2.4.0 war Retrieval Augmented Generation, kurz RAG. RAG war zuvor bereits konzeptionell Bestandteil der Architektur, mit Version 2.5.0 wurde daraus jedoch erstmals ein eigener produktiver Installations- und Betriebsbaustein.
Das RAG-Modul wurde auf Version 0.3.0 angehoben und in den Complete Installer integriert. Der Release-Stand wurde dabei nicht nur synthetisch getestet, sondern auf einer frischen Windows-VM ohne vorherigen KI-Stack-Zustand real installiert. Auch der erste notwendige WSL2-Neustart und das anschließende Resume wurden dabei erfolgreich durchlaufen.
Die eigentliche Herausforderung bei RAG liegt nicht darin, lediglich ein Embedding-Modell zu starten. Ein produktiver RAG-Pfad benötigt einen vollständigen Lebenszyklus: Dokumente werden eingelesen, verarbeitet und in einen lokalen Knowledge-Bestand übernommen. Dafür wird Nomic weiterhin ausschließlich als Embedding-Modell verwendet, während das eigentliche Chatmodell davon getrennt bleibt. Mindestens genauso wichtig wie das Hinzufügen von Wissen ist aber die Frage, was bei Änderungen geschieht. Ein Dokument kann neu hinzugefügt, ersetzt oder entfernt werden, und diese Änderungen müssen nicht nur im lokalen State nachvollziehbar bleiben, sondern auch gegenüber dem realen Open-WebUI-Knowledge-System korrekt umgesetzt werden.
Genau diese Integration wurde mit 2.5.0 erstmals auf einem realen Open-WebUI-0.11.0-Zielsystem getestet. Für das Hinzufügen eines Dokuments und den anschließenden Rollback wurde überprüft, dass das Remote-Objekt tatsächlich gelöscht wird und nicht lediglich aus einer lokalen Zuordnung verschwindet. Der lokale Zustand und das Rollback-Archiv wurden anschließend ebenfalls geprüft.
Der HTTP-416-Fehler – warum reale Greenfield-Tests wichtig sind
Während der physischen Greenfield-Installation von 2.5.0 wurde außerdem ein Fehler im Modelldownload gefunden, der in einem normalen Happy-Path-Test leicht unentdeckt geblieben wäre. Der Installer unterstützt das Fortsetzen großer Downloads mittels HTTP-Range-Requests, was gerade bei WAN-Modellen wichtig ist, deren Dateien viele Gigabyte groß sein können.
Der Fehler trat auf, wenn bereits eine vollständig heruntergeladene .partial-Datei vorhanden war, diese aber noch nicht an ihr endgültiges Ziel verschoben worden war. Der Downloader versuchte in diesem Zustand, den Download genau ab dem Ende der Datei fortzusetzen:
Range: bytes=<ExpectedSize>-
Der Server reagierte darauf völlig korrekt mit:
HTTP 416 Range Not Satisfiable
Die Datei war schließlich bereits vollständig. Der Fix prüft in diesem Zustand nun direkt Größe und SHA-256. Ist die Datei korrekt, wird sie ohne weiteren HTTP-Request übernommen. Stimmt der Hash nicht, schlägt die Prüfung weiterhin kontrolliert fehl.
Genau solche Fehler zeigen, warum reale Greenfield-Tests inzwischen einen großen Stellenwert im Projekt besitzen. Ein synthetischer Test kann viele Dinge prüfen, aber er ersetzt nicht jeden Zustand, der während einer echten Installation mit vielen Gigabyte Downloads, Windows-Neustarts und Service-Abhängigkeiten entsteht.
Version 2.6.0 – Rollback wird wirklich vollständig
Version 2.6.0 war bewusst kein großes Feature-Release. Der Schwerpunkt lag ausschließlich auf dem RAG-Modul. Der Complete Installer selbst und die allgemeine Build-Pipeline blieben unverändert; stattdessen wurde das RAG-Modul auf Version 0.3.1 angehoben und sein Rollback-Verhalten weiter validiert.
Mit 2.5.0 war bereits der Ablauf Add → Rollback gegen ein reales Zielsystem getestet worden. 2.6.0 ergänzt nun die beiden anderen mutierenden Operationen Replace → Rollback und Remove → Rollback. Damit wurden erstmals alle drei wesentlichen Änderungsarten gegenüber einer realen Open-WebUI-Instanz getestet.
Beim Replace-Test wurde überprüft, dass nach dem Ersetzen tatsächlich der alte Remote-Inhalt verschwunden ist. Anschließend wurde ein Rollback durchgeführt, nach dem der ursprüngliche Inhalt wieder sowohl lokal als auch auf dem Remote-System vorhanden sein musste. Die wiederhergestellten Inhalte wurden dabei byteweise beziehungsweise über Hashwerte mit dem ursprünglichen Zustand verglichen.
Dasselbe Prinzip wurde für Remove getestet. Ein Dokument wurde zunächst hinzugefügt und anschließend entfernt. Danach musste der Rollback den ursprünglichen Zustand vollständig wiederherstellen. In beiden Fällen wurde zusätzlich ein zweiter Rollback ausgeführt, der als sauberer No-op enden musste.
Das ist ein wichtiger Punkt: Rollback muss idempotent sein. Ein bereits erfolgreich ausgeführter Rollback darf beim zweiten Aufruf weder zusätzliche Änderungen verursachen noch einen neuen Fehler produzieren.
Ein weiterer Fehler im Rollback-Pfad
Gerade die zusätzlichen Rollback-Tests zeigten einen weiteren Randfall. Wenn ein Rollback teilweise durchgeführt wurde und anschließend fehlschlug, konnte ein erneuter Rollback-Versuch versuchen, einen Remote-Inhalt erneut zu löschen, obwohl dieser bereits beim ersten Versuch entfernt worden war.
Open WebUI reagierte darauf korrekt mit HTTP 400. Für den Installer war das jedoch problematisch, weil der zweite Rollback-Versuch den vorherigen fehlgeschlagenen Vorgang fortsetzen sollte.
Die Logik wurde deshalb geändert. Ist der zu entfernende Remote-Eintrag bereits nicht mehr vorhanden, wird dieser Zustand nun als bereits erfüllt betrachtet. Andere Fehler, beispielsweise Netzwerkprobleme oder Serverfehler, werden weiterhin normal weitergegeben.
Auch das ist letztlich ein typisches Transaktionsproblem und kein eigentliches KI-Problem. Genau deshalb besteht der KI-Stack inzwischen aus deutlich mehr als nur Modellen.
Version 2.7.0 – Codex Local und der erste LM-Studio-Start
Mit Version 2.7.0 verschiebt sich der Fokus erneut. Diesmal betrifft die Änderung Codex Local, das von Version 0.1.3 auf 0.1.4 aktualisiert wurde. Der Grund dafür war ein Fehler, der bereits während der physischen Greenfield-Installation von 2.5.0 beobachtet worden war.
Der Fehler ist ein gutes Beispiel dafür, wie verschiedene eigentlich korrekt funktionierende Komponenten durch unterschiedliche Timeout-Annahmen dennoch gemeinsam scheitern können. LM Studio wird im KI-Stack über einen verwalteten Starter gestartet. Bei einem normalen späteren Systemstart ist das relativ schnell erledigt, bei einer wirklich frischen Installation ist die Situation jedoch anders.
LM Studio muss zunächst einmal seine GUI starten und seine eigene Ersteinrichtung durchführen. Erst anschließend wird das lms-CLI unter dem Benutzerprofil verfügbar. Der Applications-Starter berücksichtigt diesen Vorgang bereits. Sein maximal legitimes Zeitfenster liegt ungefähr bei 90 Sekunden für das erstmalige Erscheinen des lms-CLI plus weiteren 30 Sekunden für den Start des API-Servers.
Codex Local hatte jedoch zusätzlich eine eigene Warteschleife mit 30 Versuchen à zwei Sekunden, also nur 60 Sekunden. Das Ergebnis war vorhersehbar: Der LM-Studio-Starter konnte sich noch völlig innerhalb seines legitimen ersten Startvorgangs befinden, während Codex Local bereits zu dem Ergebnis kam, dass /v1/models nicht erreichbar sei.
Genau dieser Zustand wurde während einer realen Greenfield-Installation reproduziert.
2.7.0 macht den LM-Studio-Starter zum autoritativen Startvertrag
Der Fix besteht nicht darin, LM Studio einfach an irgendeiner Stelle länger warten zu lassen. Stattdessen wurde die Zuständigkeit klarer definiert. Der verwaltete LM-Studio-Starter ist jetzt der autoritative Start- und Timeout-Vertrag.
Codex Local darf nicht mit einem kürzeren unabhängigen Timeout dagegen arbeiten. Der Standardwert wurde deshalb von 30 auf 65 Versuche erhöht, was bei zwei Sekunden Wartezeit pro Versuch einem Budget von 130 Sekunden entspricht. Damit liegt das Wartungsbudget oberhalb des legitimen maximalen Startfensters des LM-Studio-Starters.
Noch wichtiger ist aber eine zweite Änderung. Codex Local startet den Starterprozess jetzt mit Start-Process -PassThru und kennt damit den tatsächlichen Prozesszustand. Beendet sich der Starter mit einem Fehlercode, wartet Codex Local nicht mehr sinnlos weiter, bis sein gesamtes Timeout abgelaufen ist. Der Fehler wird unmittelbar übernommen und als starterExitCode zurückgegeben.
Damit werden zwei Fälle sauber voneinander getrennt: LM Studio braucht legitim noch Zeit, oder der Starter ist tatsächlich fehlgeschlagen.
Reale Validierung von 2.7.0
Auch dieser Fix wurde nicht nur über einen Unit-Test abgesichert. Auf dem vorhandenen realen Zielsystem wurde der bereits laufende LM-Studio-Server beendet, während die LM-Studio-GUI geöffnet blieb. Anschließend wurde direkt die Codex-Local-Funktion ausgeführt, die für die Erreichbarkeit des Endpunkts verantwortlich ist.
Der verwaltete Starter musste dadurch tatsächlich tätig werden. Der Endpoint /v1/models war anschließend nach ungefähr 4,13 Sekunden erreichbar und lieferte drei Modelle zurück.
Der vollständige absolute Cold-Start einer noch niemals initialisierten LM-Studio-Installation wurde in diesem konkreten 2.7.0-Lauf nicht erneut auf einem frischen Rechner durchgeführt. Dieser Pfad wird durch den deterministischen Regressionstest gegen das 120-Sekunden-Zeitfenster abgesichert. Diese Unterscheidung zwischen realer Zielsystemvalidierung und Regressionstest ist im Release ausdrücklich dokumentiert.
Reproduzierbarkeit wird ebenfalls weiter verschärft
Direkt nach der Integration von 2.7.0 wurde noch ein weiterer kleiner, aber konzeptionell wichtiger Fix vorgenommen. Die Dateien unter:
tools/codex-local/current/**
werden nun in .gitattributes ausdrücklich als Bytevertrag behandelt und nicht mehr durch Git-Textnormalisierung verändert.
Der Hintergrund ist die reproduzierbare Erstellung der Installer-Pakete. Wenn Git beispielsweise Zeilenenden beim Checkout verändert, können aus identischem Quellinhalt auf unterschiedlichen Systemen unterschiedliche Bytefolgen entstehen. Das ist bei normalen Source-Dateien meistens unproblematisch, bei eingebetteten und per Hash geprüften Paketquellen dagegen relevant.
Für das RAG-Modul war eine entsprechende Absicherung bereits mit 2.5.0 nachgezogen worden. Nach 2.7.0 wurde dasselbe Prinzip nun auch explizit auf Codex Local erweitert.
Das klingt unspektakulär, gehört aber genau zu den Maßnahmen, die aus einem Buildprozess einen reproduzierbaren Buildprozess machen.
Was hat sich also seit 2.4 wirklich verändert?
Oberflächlich könnte man die Versionsfolge so zusammenfassen:
2.4
Installer stabil
2.5
RAG
2.6
RAG-Rollback
2.7
Codex-Local-Fix
Das trifft den eigentlichen Fortschritt aber nur teilweise. Der größere Wandel liegt in der Tiefe.
Mit 2.4 wurde erstmals der gesamte Stack real als Greenfield installiert. Dadurch wurden Fehler sichtbar, die vorher nicht auftauchten. Aus genau diesen Erkenntnissen entstanden die folgenden Releases.
2.5 machte RAG zu einem wirklichen Bestandteil der Plattform und beseitigte gleichzeitig den HTTP-416-Resume-Fehler bei Modelldownloads. 2.6 machte aus einem grundsätzlich vorhandenen RAG-Rollback einen vollständig gegen reale Add-, Replace- und Remove-Szenarien geprüften Transaktionsmechanismus. 2.7 behebt schließlich einen Integrationsfehler zwischen Codex Local und dem erstmaligen LM-Studio-Start.
Der gemeinsame Nenner lautet deshalb:
Seit 2.4 wird weniger neue Oberfläche gebaut und mehr reales Systemverhalten abgesichert.
Was unverändert geblieben ist
Nicht jeder Versionssprung bedeutet, dass die komplette Plattform neu gebaut wurde. Das ist ausdrücklich nicht der Fall.
Die grundlegende Architektur bleibt erhalten. Open WebUI bleibt die zentrale Oberfläche. LM Studio stellt das lokale Sprachmodell bereit. Heretic ist weiterhin das reguläre Chatmodell, Nomic übernimmt Embeddings, ComfyUI die visuellen Workflows, Z-Image die Bildgenerierung und WAN2.2 T2V 14B die Videogenerierung.
Auch SearXNG, nginx, uWSGI und Valkey bleiben Bestandteil der lokalen Sucharchitektur.
Die Änderungen zwischen 2.5, 2.6 und 2.7 sind bewusst fokussiert. 2.6 verändert beispielsweise keine Installer- oder Buildlogik, sondern ausschließlich den RAG-Bereich. 2.7 konzentriert sich wiederum auf Codex Local und lässt die restliche Architektur unverändert.
Diese Art kleinerer, zielgerichteter Releases ist aus meiner Sicht inzwischen sinnvoller als ein permanentes Umbauen des gesamten Stacks.
Der aktuelle Stand
Mit 2.7.0 besitzt der KI-Stack inzwischen eine ziemlich klar definierte Funktionsarchitektur. Auf Anwendungsebene stehen Open WebUI, LM Studio, ComfyUI, SearXNG, Codex Local und RAG. Daneben existieren die spezialisierten Modelle Heretic für Chat, Nomic für Embeddings, Z-Image Turbo für Bilder und WAN2.2 T2V 14B für Video.
Mindestens ebenso wichtig ist inzwischen die darunterliegende Betriebsarchitektur. Self-Test, Dry Run, Execute, State, Backup, Resume, Recovery, Repair, Rollback, Validation, Lifecycle, SHA-256-Verträge, deterministische Builds, Regressionstests und reale Zielsystemtests gehören mittlerweile genauso zum Projekt wie die eigentlichen KI-Modelle.
Der KI-Stack ist damit deutlich näher an einer lokalen Plattform als an einer Sammlung von Installationsskripten.
Was kommt als Nächstes?
Einen offiziellen 2.8.0-Branch oder eine veröffentlichte 2.8-Roadmap gibt es zum aktuellen Stand noch nicht. Deshalb wäre es falsch, bereits konkrete Features für Version 2.8 zu versprechen.
Die Entwicklung der letzten Versionen zeigt allerdings ziemlich klar, welche Themen als Nächstes sinnvoll sind. Ein naheliegender Schritt ist eine erneute vollständige Greenfield-Installation des aktuellen Gesamtstands, bei der insbesondere der erstmalige LM-Studio-/Codex-Local-Pfad ohne manuelle Hilfe erneut durchlaufen wird. Das wäre weniger ein neues Feature als die konsequente Bestätigung, dass der mit 2.7 korrigierte Ablauf auch auf einem vollständig leeren Rechner funktioniert.
Ein weiterer noch bestehender Punkt betrifft den Open-WebUI-Administrator-API-Key. Wird dieser während der Installation nicht bereitgestellt, bleiben aktuell der Rollback des temporären Knowledge-Bootstrap-Experiments und die Konfiguration der Code-Interpreter-Verbindung als manuelle Nacharbeit bestehen. Der Installer kennzeichnet diese Zustände sauber als CredentialRequiredForApiReadback beziehungsweise CredentialRequiredForApiConfiguration, statt sie stillschweigend als erfolgreich zu behandeln. Langfristig wäre es trotzdem sinnvoll, die Zahl der manuellen Schritte nach einer Greenfield-Installation weiter zu reduzieren.
Auch im RAG-Bereich verschiebt sich der Fokus. Mit 2.5 und 2.6 ist der technische Transaktionspfad für Add, Replace, Remove und Rollback deutlich stabiler geworden. Der nächste interessante Schritt liegt deshalb weniger in weiteren CRUD-Funktionen als im Betrieb größerer Wissensbestände: automatische Erkennung neuer Dokumente, saubere Neuindexierung geänderter Dateien, Entfernung gelöschter Quellen und ein dauerhaft aktueller Index für hunderte oder perspektivisch tausende Dokumente.
Ähnliches gilt für Agenten und Tools. Der bisherige Ansatz bleibt bewusst restriktiv. Ein Modell erhält nicht automatisch sämtliche verfügbaren Werkzeuge, sondern nur die Funktionen, die zu seinem Profil gehören. Dieses Prinzip sollte auch bei zukünftigen Erweiterungen erhalten bleiben. Interessanter als „mehr Agenten“ ist langfristig die Frage, wie klar sich deren Rechte, Tools, Wissensquellen und Laufzeitgrenzen definieren lassen.
Schließlich bleibt auch der Bereich reproduzierbarer Builds ein laufendes Thema. Der nach 2.7 ergänzte Codex-Local-Bytevertrag zeigt, dass hier weiterhin Detailarbeit notwendig ist. Für einen wirklich reproduzierbaren Installer müssen sämtliche eingebetteten Komponenten denselben Regeln folgen: deterministische Archivierung, definierte Dateibytes, keine unbeabsichtigte Git-Zeilenendennormalisierung, SHA-256-Verträge, reproduzierbare Paketquellen, SBOM und Build Attestations.
Fazit
Version 2.7.0 ist kein spektakuläres KI-Modell-Release – und genau das ist eigentlich ein gutes Zeichen.
Die wichtigen Änderungen seit 2.4 betreffen zunehmend Bereiche, die man als Benutzer kaum sieht. Downloads müssen korrekt fortgesetzt werden. Rollback muss Add, Replace und Remove wirklich rückgängig machen. Ein zweiter Rollback darf keinen Schaden verursachen. LM Studio und Codex Local müssen beim allerersten Start dieselben Zeitannahmen verwenden. Builds müssen dieselben Bytes erzeugen. Und der reale Systemzustand muss wichtiger sein als ein erfolgreicher Skript-Exitcode.
Damit wird aus dem lokalen KI-Stack langsam das, was ursprünglich das eigentliche Ziel war:
Nicht nur eine Maschine, auf der lokale KI funktioniert, sondern eine reproduzierbare Plattform, bei der Installation, Integration, Betrieb und Wiederherstellung genauso definiert sind wie die verwendeten Modelle.
Version 2.4 hat dafür die Grundlage gelegt. 2.5 hat RAG produktiv integriert. 2.6 hat dessen Transaktionsmodell vervollständigt. 2.7 räumt einen weiteren echten Greenfield-Fehler aus dem Weg.
Der nächste Schritt muss deshalb nicht zwangsläufig ein weiteres großes Feature sein. Die interessantere Frage lautet inzwischen:
Wie weit lässt sich der gesamte Stack automatisieren, validieren und reproduzieren, ohne dabei die Kontrolle über seine einzelnen Komponenten zu verlieren?
Projekt und Quellcode
Der KI-Stack wird auf GitHub entwickelt:
Dort befinden sich Sourcecode, Complete Installer, technische Dokumentation, Release-Unterlagen, Regressionstests sowie die Validierungs- und Recovery-Werkzeuge.
Weitere Artikel zum Projekt: