From f4aef4413b8440f598b369a390702e5dfcb2fdcd Mon Sep 17 00:00:00 2001 From: spektr Date: Sat, 31 Oct 2026 15:35:28 +0100 Subject: [PATCH] =?UTF-8?q?GNAI-008=20v0.18:=20Deployment-Plan=20=C3=BCber?= =?UTF-8?q?arbeitet=20(drei=20Umgebungen,=20Model-Store,=20CI/CD-Scope)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Betreiberentscheidungen 31.10.2026: Umgebungen Production, Testing und Experimental mit exklusivem GPU-Scheduling; Umschaltoperation ai_environment_switch für kurze Downtimes mit kommunizierten Zeitfenstern; Wartungsseite oder transparenter Endpunktwechsel für nutzerseitige Dienste; model_store als Kernrolle für gepinnte Weights in /var/lib/ghostnet-ai/shared; verallgemeinerte inference_engine-Rolle; Gitea-Actions-Kette mit Runner-Scope Experimental/Testing und Production ausschließlich über Promotion-Tag; Strata als erster Experimental-Kandidat (Abschnitt 7.6) mit gfx1030-Vorbehalten. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe --- .../ai/GNAI-008-PLAN_Ansible-Deployment.md | 185 +++++++++++++----- 1 file changed, 133 insertions(+), 52 deletions(-) diff --git a/docs/platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md b/docs/platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md index 3e514e6..f8a368f 100644 --- a/docs/platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md +++ b/docs/platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md @@ -2,7 +2,7 @@ **Dokumenten-ID:** GNAI-008-PLAN **Titel:** Ansible-Deployment für den KI-Server – Planungsstand -**Stand:** 2026-09-21 +**Stand:** 2026-10-31 **Status:** Nicht finaler Arbeitsentwurf zur Persistierung des aktuellen Planungsstands **Referenzen:** [Projektstand](../../../GNAI-000-DOC_Index.md), [Zielarchitektur](GNAI-004-INFRA_Architecture.md), [Modellbewertung](GNAI-009-PLAN_Llama-Model-Evaluation.md), [llama.cpp-Sollkonfiguration](GNAI-010-TECH_Llama-Serving.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md) @@ -36,6 +36,7 @@ | 2026-09-21 | 0.15 | spektr / Codex | je Modell ein festes, gegenseitig ausgeschlossenes Quadlet vorgesehen und dynamischen llama.cpp-Router zurückgestellt | | 2026-09-21 | 0.16 | spektr / Codex | überholten Phasen- und Dokumentenbacklog konsolidiert, Umsetzungsreihenfolge an GNAI-001 delegiert und privilegierten Runner nach Recovery verschoben | | 2026-10-19 | 0.17 | spektr / Mistral Vibe | LLM-Server-Projekt in die fachlichen Hauptverzeichnisse `host/`, `llm/` und `encoding/` aufgeteilt; Abschnitte 6 und 7.4 an die neue Struktur angepasst | +| 2026-10-31 | 0.18 | spektr / Mistral Vibe | Deployment-Plan mit Betreiberentscheidungen vom 31.10.2026 überarbeitet: dritte Umgebung Experimental, exklusives GPU-Scheduling mit schnellem Umschalter und kommunizierten Zeitfenstern, Wartungsseite/transparenter Endpunktwechsel für nutzerseitige Dienste, Model-Store als Kernrolle, verallgemeinerte Engine-Rolle, Gitea-Actions-Kette mit reduziertem Production-Scope, Strata als erster Experimental-Kandidat (Abschnitt 7.6) | --- @@ -132,22 +133,23 @@ Planungsrichtung und noch nicht bestätigten Implementierungsdetails. | Konfigurationsmanagement | Ansible beschreibt Basissystem, Laufzeitumgebung, Dienste und Konfiguration | Control-Projekt, Preflight, `host_baseline`, `podman_runtime`, `workload_accounts`, `amd_gpu_access` und der ROCm-Container-Probelauf vorhanden und angewendet; Anwendungsrollen fehlen noch | | Quell- und Freigabeverfahren | Änderungen über Gitea-Branches und Pull Requests; kein regulärer Direkt-Push auf `main` | vorgesehen; Branch-Schutz noch nicht geprüft oder eingerichtet | | CI | Pull Requests erhalten Lint-, YAML- und Ansible-Syntaxprüfungen ohne produktive Zugangsdaten | vorgesehen; Workflow noch nicht vorhanden | -| Produktionsausführung | Gitea Actions startet Ansible über eine dedizierte Production-Berechtigungsstufe | bevorzugte Lösung; Gitea-Version, Runner-Trennung und Actions-Funktion noch zu prüfen | +| Produktionsausführung | Gitea Actions startet Ansible über dedizierte Berechtigungsstufen je Umgebung | Betreiberentscheidung 31.10.2026: Experimental und Testing per ausgelöstem Workflow, Production ausschließlich über bewussten Promotion-Tag; Gitea-Version, Runner-Trennung und Actions-Funktion noch live zu prüfen | | Runner-Platzierung | eigener kleiner LXC, getrennt von Gitea und KI-Server | bevorzugt; Host, Adresse und Ressourcen noch offen | | Job-Isolation | containerisierte Jobs; für den Gitea Runner ist nach aktueller Herstellerdokumentation Docker der unterstützte Standard | bevorzugt; lokale Freigabe und LXC-Eignung noch offen | | Parallelität | Produktionsrunner führt höchstens einen Job gleichzeitig aus | vorgesehen; Runner-Konfiguration noch nicht vorhanden | -| Deployment-Freigabe | nach erfolgreichem Review bewusste Freigabe über geschützten `deploy-*`-Tag | bevorzugte Startvariante; Namensschema und berechtigte Teams noch offen | +| Deployment-Freigabe | Production nur nach erfolgreichem Review über geschützten Promotion-Tag; Experimental und Testing über bewusst ausgelöste Workflows | Betreiberentscheidung 31.10.2026; Namensschema und berechtigte Teams noch offen | | Zielzugang | eigener technischer SSH-Account `ansible-deploy` mit separatem, quellnetzbeschränktem Schlüssel und validiertem `NOPASSWD: ALL` | auf dem KI-Server eingerichtet und unabhängig verifiziert; spätere Runner-Übernahme und Rotation offen | | Geheimnisse | verschlüsselte Ansible-Variablen plus getrennt gespeichertes Vault-Passwort und Runner-Zugangsdaten | Richtung angenommen; konkreter Secret-Workflow noch offen | | Artefaktversionen | Pakete, Collections und Container-Images werden auf konkrete Versionen, nach Möglichkeit Digests, festgelegt | vorgesehen | | Repository-Zuschnitt | `infrastructure` bleibt alleinige Quelle für alle Ansible-Zustände des Hosts; KI- und Encoding-Dokumentation werden getrennt geführt; weitere Quellcode-Repositories erst bei eigenständig entwickelten Anwendungen | als aktuelle Planungsentscheidung angenommen | | Anwendungsupdates | Upstream-Artefakte werden im Infrastruktur-Repository auf eine geprüfte Version festgelegt; eigene Build-Repositories sind vorerst nicht Bestandteil des Projekts | vorgesehen; Registry- und Buildverfahren bei späterem Eigenentwicklungsbedarf neu bewerten | | Automatische Updates | kein unbeaufsichtigtes Produktionsupdate über `latest` oder Watchtower | vorläufige Sicherheitsentscheidung | -| Laufzeitumgebungen | Production und Testing werden als getrennte Stacks auf demselben physischen KI-Server betrieben | als aktuelle Planungsentscheidung angenommen | +| Laufzeitumgebungen | Production, Testing und Experimental werden als getrennte Stacks auf demselben physischen KI-Server betrieben | Betreiberentscheidung 31.10.2026 | | Production | stabiler, extern nutzbarer Stand mit bewusst freigegebenen Versionen | Zielbild; Dienste noch nicht eingerichtet | | Testing | interner, kurzlebiger oder zurücksetzbarer Stand für kontrollierte Tests vor dem Merge nach `main`; nutzt während eines Wartungsfensters beide GPUs exklusiv gegenüber Production | Zielbild; Dienste, Zugriffsweg und Umschaltverfahren noch nicht eingerichtet | -| Ressourcenbetrieb | AI Production und AI Testing laufen nicht gleichzeitig; der getrennte CPU-Encoding-Workload darf nachts parallel zur jeweils aktiven KI-Umgebung laufen | als aktuelle Planungsentscheidung angenommen; Grenzwerte und Lasttest offen | -| Workload-Konten | `gnai-production`, `gnai-testing` und `gn-encoding` verwenden getrennte rootless Podman-Stores und systemd-User-Manager | eingerichtet und mit `changed=0` verifiziert | +| Experimental | Stack-Bewertungsraum für neue Engines (erster Kandidat: Strata, Abschnitt 7.6) und Modellarchitekturen vor einer Testing-Freigabe; für Betreiber und Freunde nur in angekündigten Zeitfenstern nutzbar | Betreiberentscheidung 31.10.2026; Umgebung noch nicht eingerichtet | +| Ressourcenbetrieb | höchstens eine KI-Umgebung ist gleichzeitig aktiv; der Umschalter ist auf kurze Downtimes optimiert, Production-Stillstände für Tests anderer Umgebungen werden kommuniziert und in angekündigten Zeitfenstern durchgeführt; der getrennte CPU-Encoding-Workload darf nachts parallel zur jeweils aktiven KI-Umgebung laufen | Betreiberentscheidung 31.10.2026; Grenzwerte und Lasttest offen | +| Workload-Konten | `gnai-production` (980), `gnai-testing` (981) und `gn-encoding` (982) verwenden getrennte rootless Podman-Stores und systemd-User-Manager; `gnai-experimental` (983, geplant) kommt als viertes Konto hinzu | bestehende Konten eingerichtet und mit `changed=0` verifiziert; Experimental noch nicht angelegt | | Betriebsnachweis | erfolgreicher Lauf dokumentiert Git-Commit, Zielhost, Zeitpunkt, Prüfungen und Ergebnis | vorgesehen | | Rollback | Konfigurationsänderung über Revert und erneute Freigabe; persistente Daten zusätzlich über getestete Backups wiederherstellen | Grundprinzip; konkrete SOP noch zu erstellen | @@ -222,6 +224,7 @@ llm-server/ .gitea/workflows/ ├── validate.yml +├── deploy-experimental.yml ├── deploy-testing.yml └── deploy-production.yml ``` @@ -244,31 +247,33 @@ Umgebung läuft. --- -## 7. Production und Testing auf einem Host +## 7. Production, Testing und Experimental auf einem Host ### 7.1 Geltungsbereich der Trennung -Production und Testing laufen zunächst auf demselben physischen KI-Server. +Production, Testing und Experimental laufen auf demselben physischen KI-Server. Damit können Anwendungscontainer, Konfigurationen und Daten sauber logisch getrennt werden. Die Hardware kann wegen des hohen Leistungsbedarfs nicht -dauerhaft zwischen beiden KI-Umgebungen aufgeteilt werden. Stattdessen erhält -die jeweils aktive KI-Umgebung beide GPUs exklusiv gegenüber der anderen -KI-Umgebung. Ein fachlich getrennter CPU-Encoding-Workload darf außerhalb der +dauerhaft zwischen den KI-Umgebungen aufgeteilt werden. Stattdessen erhält +die jeweils aktive KI-Umgebung beide GPUs exklusiv gegenüber den anderen +KI-Umgebungen. Ein fachlich getrennter CPU-Encoding-Workload darf außerhalb der Stoßzeiten parallel laufen. Es entstehen dennoch keine getrennten Fehlerdomänen: - Kernel, AMD-Treiber beziehungsweise ROCm, Podman und systemd werden gemeinsam verwendet; -- ein Hostausfall betrifft beide Umgebungen; -- ein fehlerhafter Testing-Stand kann den gemeinsamen Host beeinträchtigen und - dadurch den Wiederanlauf von Production verzögern; +- ein Hostausfall betrifft alle Umgebungen; +- ein fehlerhafter Testing- oder Experimental-Stand kann den gemeinsamen Host + beeinträchtigen und dadurch den Wiederanlauf von Production verzögern; - Kernel-, Treiber- und Host-Runtime-Updates können nicht realitätsnah in Testing geprüft werden, ohne den gemeinsamen Host zu verändern. Testing ist deshalb für neue Anwendungsstände, Konfigurationen, MCP-Komponenten -und Integrationen vorgesehen. Für risikoarme Vorabtests von Kernel-, Treiber- -oder Podman-Upgrades wäre später ein zweiter Host oder eine ausreichend -vergleichbare separate Maschine erforderlich. +und Integrationen vorgesehen. Experimental nimmt darunter neue Engines und +Modellarchitekturen vor ihrer Testing-Reifung auf (Abschnitt 7.6). Für +risikoarme Vorabtests von Kernel-, Treiber- oder Podman-Upgrades wäre später +ein zweiter Host oder eine ausreichend vergleichbare separate Maschine +erforderlich. Die von externen Nutzern erwartete Stabilität von Production gilt außerhalb angekündigter Test- und Wartungsfenster. Solange nur dieser eine ausgelastete @@ -277,19 +282,19 @@ geplante Unterbrechung von Production. ### 7.2 Isolationsziele -| Bereich | Production | Testing | -| --- | --- | --- | -| Erreichbarkeit | für freigegebene Dienste über NPM; Backend- und Managementports bleiben intern | nur aus freigegebenem LAN/VPN; keine öffentliche NPM-Route | -| Container- und Unit-Namen | eigener eindeutiger Präfix | eigener eindeutiger Präfix | -| Podman-Netz | eigenes internes Netz | eigenes internes Netz ohne Verbindung zum Production-Netz | -| Konfiguration | eigener Verzeichnisbaum | eigener Verzeichnisbaum | -| Persistente Daten | eigene Volumes mit Backup- und Restore-Verfahren | eigene zurücksetzbare Volumes; keine Production-Datenkopie ohne Bereinigung und Freigabe | -| Secrets und API-Keys | ausschließlich Production-Credentials | eigene eingeschränkte Test-Credentials | -| Ports und Hostnamen | stabile freigegebene Endpunkte | getrennte interne Ports und noch festzulegende Testhostnamen | -| Ressourcen | erhält im Normalbetrieb beide GPUs und das festzulegende KI-Ressourcenbudget | erhält im Testfenster beide GPUs und das festzulegende KI-Ressourcenbudget | -| GPU | beide GPUs, solange Production aktiv ist | beide GPUs, nachdem Production vollständig beendet wurde | -| Ausführungszustand | standardmäßig aktiv | standardmäßig gestoppt | -| Verfügbarkeit | stabiler Betriebsstand außerhalb angekündigter Wartungsfenster | best effort; wird nach jedem Testlauf wieder vollständig gestoppt | +| Bereich | Production | Testing | Experimental | +| --- | --- | --- | --- | +| Erreichbarkeit | für freigegebene Dienste über NPM; Backend- und Managementports bleiben internal | nur aus freigegebenem LAN/VPN; keine öffentliche NPM-Route | nur in angekündigten Zeitfenstern über das Frontend; keine eigene NPM-Route | +| Container- und Unit-Namen | eigener eindeutiger Präfix | eigener eindeutiger Präfix | eigener eindeutiger Präfix | +| Podman-Netz | eigenes internes Netz | eigenes internes Netz ohne Verbindung zum Production-Netz | eigenes internes Netz ohne Verbindung zu den anderen KI-Netzen; Egress-Deny als Default | +| Konfiguration | eigener Verzeichnisbaum | eigener Verzeichnisbaum | eigener Verzeichnisbaum | +| Persistente Daten | eigene Volumes mit Backup- und Restore-Verfahren | eigene zurücksetzbare Volumes; keine Production-Datenkopie ohne Bereinigung und Freigabe | vollständig zurücksetzbare Volumes; Modellbezüge nur über gepinnte Model-Store-Artefakte | +| Secrets und API-Keys | ausschließlich Production-Credentials | eigene eingeschränkte Test-Credentials | eigene eingeschränkte Experimental-Credentials | +| Ports und Hostnamen | stabile freigegebene Endpunkte | getrennte interne Ports und noch festzulegende Testhostnamen | getrennte interne Ports | +| Ressourcen | erhält im Normalbetrieb beide GPUs und das festzulegende KI-Ressourcenbudget | erhält im Testfenster beide GPUs und das festzulegende KI-Ressourcenbudget | erhält im freigegebenen Fenster beide GPUs und das festzulegende KI-Ressourcenbudget | +| GPU | beide GPUs, solange Production aktiv ist | beide GPUs, nachdem Production vollständig beendet wurde | beide GPUs, nachdem die aktive Umgebung vollständig beendet wurde | +| Ausführungszustand | standardmäßig aktiv | standardmäßig gestoppt | standardmäßig gestoppt | +| Verfügbarkeit | stabiler Betriebsstand außerhalb angekündigter Wartungsfenster | best effort; wird nach jedem Testlauf wieder vollständig gestoppt | best effort; wird nach jedem Lauf wieder vollständig gestoppt | Eine gleichzeitige Inferenzlast beider KI-Umgebungen ist nicht vorgesehen. Vor dem Start von Testing muss nachweisbar sein, dass Production beendet wurde und @@ -316,8 +321,13 @@ entschieden. ### 7.3 Exklusives Umschaltverfahren -Ein Testing-Deployment ist zugleich ein geplantes Wartungsfenster für -Production. Der vorläufige Ablauf lautet: +Jedes Deployment einer nichtaktiven Umgebung ist zugleich ein geplantes +Wartungsfenster; das Fenster wird den Nutzern vorab angekündigt. Die +Umschaltoperation läuft als hostseitige Rolle (`ai_environment_switch`) und +kann über den CI/CD-Runner oder lokal ausgelöst werden; sie ist auf kurze +Downtimes optimiert (Stoppen der aktiven Umgebung, Prüfen der vollständigen +GPU-/RAM-Freigabe, Starten der Zielumgebung, Health Checks). Der vorläufige +Ablauf lautet: 1. konkreten PR-Commit und Testumfang festlegen; 2. Testing-Lauf durch eine berechtigte Person freigeben und Wartungsfenster @@ -339,6 +349,13 @@ Production. Der vorläufige Ablauf lautet: 12. Production-Health- und Inferenztests ausführen und erst danach das Wartungsfenster beenden. +Während des Fensters zeigen die nutzerseitigen Dienste entweder eine +Wartungsseite oder eine entsprechende Wartungsantwort (NPM) oder schalten +transparent auf den anderen Stack um (Endpunktwechsel im Frontend). Welches +Verfahren je Dienst greift, wird mit dem Frontend in Meilenstein 4 festgelegt; +die Umschaltoperation muss dafür einen abfragbaren Zustand (aktive Umgebung, +laufendes Fenster) bereitstellen. + Der Wiederanlauf von Production darf nicht ausschließlich von einem letzten Schritt im Gitea-Job abhängen. Runner-Abbruch, Netzwerkverlust oder ein fehlgeschlagener Test müssen durch einen hostseitigen Recovery-Mechanismus und @@ -350,11 +367,11 @@ erst in der technischen Spezifikation festgelegt. Der Testing-Deployment-Account soll Production nicht frei verwalten können. Er darf lediglich eine eng definierte hostseitige Umschaltoperation starten und deren Status abfragen. Der Umschaltdienst besitzt die notwendigen Rechte zum -geordneten Stoppen und Wiederanlaufen der beiden Stacks, stellt dem Testing-Job +geordneten Stoppen und Wiederanlaufen der KI-Umgebungen, stellt dem Testing-Job aber weder Production-Secrets noch allgemeine Production-Verwaltungsrechte zur Verfügung. -Production und Testing dürfen niemals gleichzeitig als aktiv markiert sein. +Die KI-Umgebungen dürfen niemals gleichzeitig als aktiv markiert sein. Jeder Start prüft den Gegenstatus und bricht bei einem widersprüchlichen oder unklaren Zustand ab. Der Encoding-Workload bleibt von diesem KI-Lock unabhängig; ein allgemeines Hostwartungsfenster kann weiterhin alle Workloads stoppen. @@ -376,13 +393,19 @@ llm-server/ │ ├── workload_accounts/ │ └── amd_gpu_access/ ├── llm/ansible/ # geplant; entsteht mit dem AI-Vertical-Slice +│ ├── inventories/ +│ │ ├── production/ +│ │ ├── testing/ +│ │ └── experimental/ │ ├── playbooks/ │ │ ├── ai.yml +│ │ ├── switch-environment.yml │ │ └── site.yml │ └── roles/ -│ ├── ai_stack/ -│ ├── ai_environment_switch/ -│ └── llama_cpp/ +│ ├── inference_engine/ # Quadlets je Engine-Profil (llama.cpp, Strata, …) +│ ├── model_store/ # gepinnte Weights und Artefakte im gemeinsamen Modellbestand +│ ├── ai_frontend/ # nutzerseitiges Frontend je Umgebung (Open WebUI) +│ └── ai_environment_switch/ # exklusive Umschaltoperation aus Abschnitt 7.3 └── encoding/ansible/ ├── playbooks/ │ └── video-encoding.yml @@ -392,22 +415,29 @@ llm-server/ `host.yml` verwaltet gemeinsame Pakete, Treiber, Benutzer und Runtime-Komponenten einmalig. `ai.yml` verwaltet ausschließlich den LLM-Stack -und genau eine explizit gewählte KI-Umgebung. `video-encoding.yml` verwaltet nur +und genau eine explizit gewählte KI-Umgebung (production, testing oder +experimental). `switch-environment.yml` führt die exklusive Umschaltoperation +aus Abschnitt 7.3 aus. `video-encoding.yml` verwaltet nur Encoding-Pfade, Images, Quadlets, Timer und Prüfungen. `site.yml` kann den unterstützten Gesamtzustand in definierter Reihenfolge herstellen. Hoständerungen dürfen nicht beiläufig durch einen Workload-Lauf erfolgen. Für den ersten umgesetzten Baseline-Stand gelten getrennte Konfigurationsbäume -unter `/etc/ghostnet-ai/{production,testing}` und getrennte persistente -Datenbäume unter `/var/lib/ghostnet-ai/{production,testing}`. Der Pfad -`/var/lib/ghostnet-ai/shared` ist für später ausdrücklich freigegebene -gemeinsame Daten reserviert. Konkrete Unterverzeichnisse, Eigentümer sowie -Unit- und Container-Namen werden mit den jeweiligen Fachrollen festgelegt. Die -Konten `gnai-production` und `gnai-testing` besitzen inzwischen ihre -Datenwurzeln und getrennten rootless Podman-Stores; Konfiguration bleibt -rootverwaltet und für die jeweilige Gruppe lesbar. Der Encoding-Workload -verwendet entsprechend `/etc/ghostnet-encoding` und -`/var/lib/ghostnet-encoding`. +unter `/etc/ghostnet-ai/{production,testing,experimental}` und getrennte +persistente Datenbäume unter +`/var/lib/ghostnet-ai/{production,testing,experimental}`. Der Pfad +`/var/lib/ghostnet-ai/shared` ist seit dem 31.10.2026 nicht mehr nur +reserviert, sondern als gemeinsamer Model-Store vorgesehen (Rolle +`model_store`): gepinnte Weights und Artefakte liegen dort genau einmal und +werden von allen KI-Umgebungen nur lesbar eingebunden; ein manuelles Hochladen +ist als zweiter Weg mit Prüfsummenverifikation vorgesehen. Konkrete +Unterverzeichnisse, Eigentümer sowie Unit- und Container-Namen werden mit den +jeweiligen Fachrollen festgelegt. Die Konten `gnai-production` und +`gnai-testing` besitzen inzwischen ihre Datenwurzeln und getrennten rootless +Podman-Stores; Konfiguration bleibt rootverwaltet und für die jeweilige Gruppe +lesbar. `gnai-experimental` (983) wird analog über `workload_accounts` +nachgezogen. Der Encoding-Workload verwendet entsprechend +`/etc/ghostnet-encoding` und `/var/lib/ghostnet-encoding`. ### 7.5 ROCm- und `llama.cpp`-Ausgangskonfiguration @@ -496,6 +526,36 @@ werden Prompt-Verarbeitung, Token-Generierung, VRAM-Nutzung und Stabilität bei 131.072 Token Kontext gemessen. Der 1:1-Wert ist erst nach diesem Test ein abgenommener Betriebsparameter. +### 7.6 Experimental-Kandidat Strata (Planungsstand 31.10.2026) + +Grundlage sind die Betreiberrecherchen unter +[`docs/planning/`](../../../planning/) (insbesondere +`local-ai-trends-2026.txt`). Strata ist eine MIT-lizenzierte, auf ggml/llama.cpp +aufbauende Inference-Engine (Niko1221) für die Qwen3.8-Flash-Next-Klasse; auf +gfx1030 gilt sie als experimentell/unvalidiert und erscheint mehrmals pro Woche +in neuen Releases. Ein Community-Benchmark auf praktisch identischer Hardware +(2× RX 6900 XT, 128 GB RAM, IQ3_S, 128K Kontext) meldet 57–61 t/s Decode und +bis 1.823 t/s Prefill gegenüber 26 beziehungsweise 274 t/s unter llama.cpp auf +derselben Maschine; auf dem hiesigen 64-GB-Host sind deshalb kleinere Quants +(Q2_0/IQ2_XS) oder Low-RAM-Flags einzuplanen. + +Konsequenzen für die Umsetzung: + +- Strata läuft zuerst und ausschließlich in Experimental; ein Testing- oder + Production-Einsatz setzt eine gfx1030-Validierung und den Fix von Bug #884 + voraus. +- Engine-Version und gegebenenfalls Source-Build werden wie Container-Images + gepinnt; bei diesem Release-Takt ist die Pin-Disziplin Pflicht. Das + Strata-Pendant zu GNAI-010 dokumentiert Flags, Ulimits (`memlock`, + `vm.max_map_count`), den Workaround `--adapt-every 100000`, die API-Key-Pflicht + und die per `iq_pack.py` erzeugten, im Model-Store zu pinnenden Artefakte. +- Das Workload-Konto `gnai-experimental` erhält Egress-Deny als Default + (Flash-Next zeigte in Sandbox-Tests ungefragte Netzwerkzugriffe); + API-Zugriff erfolgt ausschließlich über das Frontend beziehungsweise interne + Endpunkte mit API-Key. +- GNAI-009 nimmt Qwen3.8-Flash-Next als dritten Modellkandidaten auf, sobald + die Experimental-Umgebung steht. + --- ## 8. Vorgesehener Workflow @@ -516,6 +576,12 @@ abgenommener Betriebsparameter. Person und 10. nach erfolgreichem Statuscheck in den geschützten `main`-Branch mergen. +Seit dem 31.10.2026 gilt die Umgebungskette Experimental → Testing → +Production: Neue Engines und Stacks (zunächst Strata) werden über bewusst +ausgelöste Workflows in Experimental deployt und bewertet; der Testing-Lauf +prüft anschließend den konkreten PR-Stand; Production folgt nur über den +Promotion-Tag. + ### 8.2 Testing-Deployment vor dem Merge Ein Pull Request führt zunächst nur statische CI-Prüfungen in einer isolierten @@ -647,8 +713,12 @@ Für diesen Ansible-Teilplan gelten daraus drei Leitplanken: 1. Der erste interne `llama.cpp`-Vertical-Slice wird lokal kontrolliert und ohne öffentliche Route ausgerollt. 2. Statische CI erhält keine SSH- oder Deployment-Secrets. -3. Ein privilegierter Runner folgt erst nach stabilem Rollen-, Rollback- und - Recovery-Verfahren. +3. Der Runner deployt zunächst nur Experimental und Testing; Production folgt + erst nach stabilem Rollen-, Rollback- und Recovery-Verfahren + (Betreiberentscheidung 31.10.2026). +4. Der gemeinsame Model-Store wird mit dem ersten Vertical-Slice aufgebaut; + Engines referenzieren gepinnte Artefakte, statt eigene Gewichtskopien zu + halten. --- @@ -673,6 +743,13 @@ spätere Delivery-Kette bleiben hier nur folgende technische Fragen: Diese Fragen werden vor Einführung eines privilegierten Runners entschieden, nicht als Voraussetzung für den internen Testing-Vertical-Slice. +Am 31.10.2026 vorentschieden (Betreiber): Frage 5 – Production wird über +einen geschützten Promotion-Tag auf einem geprüften `main`-Commit ausgelöst. +Frage 6 – der Umschaltmechanismus ist die exklusive hostseitige Rolle +`ai_environment_switch` mit kommunizierten Zeitfenstern (Abschnitt 7.3); +Timeout- und Recovery-Details bleiben offen. Die übrigen Fragen gelten +unverändert. + --- ## 13. Referenzstand der Planung @@ -728,7 +805,7 @@ bestätigte: Dieser Lauf ist ein Zugriffs- und Identitätsnachweis. Er bestätigt weder ROCm noch Inferenzfunktion, privilegierte Deploymentrechte, Containerbetrieb oder -die geplante Umschaltung zwischen Production und Testing. +die geplante Umschaltung zwischen den KI-Umgebungen. Für den folgenden Bootstrap wurden ein eigener Ed25519-Schlüssel, ein Account-/sudoers-Playbook und ein getrenntes Prüfplaybook erstellt. Der @@ -868,7 +945,11 @@ Insbesondere wurden noch nicht: - Backups oder Rollbacks praktisch getestet oder - die geplante Deploymentkette technisch abgenommen. -Der nächste KI-spezifische Schritt ist die `llama.cpp`-Rolle für Testing. Die +Mit Revision 0.18 ist der nächste KI-spezifische Schritt die verallgemeinerte +Rolle `inference_engine` (erstes Profil: `llama.cpp` für Testing) zusammen mit +der Rolle `model_store` für den gemeinsamen gepinnten Modellbestand; +anschließend folgen `gnai-experimental` samt Strata-Profil (Abschnitt 7.6) und +die Gitea-Actions-Kette mit reduziertem Production-Scope (Abschnitt 11). Die bereichsübergreifende Priorität und die Abhängigkeit von den offenen Sicherheitsbefunden legt GNAI-001 fest. LiteLLM ist nicht länger automatisch der Folgeschritt, sondern wird vor einer Veröffentlichung anhand der benötigten