GNAI-008 v0.18: Deployment-Plan überarbeitet (drei Umgebungen, Model-Store, CI/CD-Scope)

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 <vibe@mistral.ai>
2026-11-01 17:31:45 +01:00
parent 4098dfac0b
commit f4aef4413b
1 changed files with 133 additions and 52 deletions
@@ -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