GNAI-007: ROCm-Probelauf hinzugefügt.

docs/GNAI-000-DOC_Index.md

@@ -47,7 +47,7 @@ Der KI-Server heißt laut lesendem SSH-Abgleich vom 18.09.2026 `ghostnet-ki`; da
 
 Die getrennten Schlüsselzugänge für `ghost` und `ghost-agent` wurden am 19.09.2026 erfolgreich getestet. Der persönliche Login wurde vom Betreiber interaktiv bestätigt; der Agentenlogin wurde technisch gegen Benutzername und Hostname geprüft.
 
-Der KI-Server wurde als frisches Debian-Basissystem begonnen. Inzwischen sind die dokumentierten Ansible-Zugänge, die minimale Host-Baseline und Podman eingerichtet. Die LLM-Anwendungen sind weiterhin nicht installiert; GNAI-003 und GNAI-004 beschreiben für sie ein Zielbild.
+Der KI-Server wurde als frisches Debian-Basissystem begonnen. Inzwischen sind die dokumentierten Ansible-Zugänge, die minimale Host-Baseline und Podman eingerichtet. Ein gepinntes ROCm-Probeimage liegt im rootless Testing-Store und hat beide GPUs erkannt; dauerhafte LLM-Anwendungen sind weiterhin nicht installiert. GNAI-003 und GNAI-004 beschreiben für sie ein Zielbild.
 
 Der [Ansible-Deployment-Entwurf](ai/GNAI-007-PLAN_Ansible-Deployment.md) persistiert den seit dem 19.09.2026 fortgeschriebenen Planungs- und Implementierungsstand. Er ist ausdrücklich keine verbindliche Spezifikation und kein Nachweis einer vollständig eingerichteten Deploymentkette. Die dort genannten Runner-, Freigabe- und Secret-Verfahren sind bis zu ihrer Prüfung und formalen Übernahme vorläufig.
 
@@ -61,7 +61,9 @@ Die Rolle `podman_runtime` wurde am 20.09.2026 angewendet. Sie installierte Podm
 
 Die Rolle `workload_accounts` richtete am 20.09.2026 die gesperrten Konten `gnai-production` (UID/GID 980), `gnai-testing` (981) und `gn-encoding` (982) mit festen, getrennten SubID-Bereichen ein. Konfiguration bleibt rootverwaltet; Daten, rootless Podman-Stores und persistente systemd-User-Manager sind pro Workload getrennt. Der korrigierte Gesamtlauf meldete `ok=36 changed=0 unreachable=0 failed=0` und bestätigte drei unterschiedliche rootless Graph Roots. Images und Container wurden nicht angelegt.
 
-Die Rolle `amd_gpu_access` bestätigte am 20.09.2026 zwei Sapphire-Navi-21-Geräte `1002:73bf` mit dem Kernel-Treiber `amdgpu`, `/dev/kfd` sowie die zugehörigen Render-Nodes `/dev/dri/renderD128` und `/dev/dri/renderD129`. Alle drei Geräte verwenden die Gruppe `render`. `gnai-production` und `gnai-testing` besitzen nachweislich Lese-/Schreibzugriff; `gn-encoding` erhielt keine GPU-Gruppe. Nach Beseitigung einer konkurrierenden Gruppenverwaltung endete der Gesamtlauf mit `ok=55 changed=0 unreachable=0 failed=0`. ROCm im Container und tatsächliche Inferenz sind damit noch nicht nachgewiesen.
+Die Rolle `amd_gpu_access` bestätigte am 20.09.2026 zwei Sapphire-Navi-21-Geräte `1002:73bf` mit dem Kernel-Treiber `amdgpu`, `/dev/kfd` sowie die zugehörigen Render-Nodes `/dev/dri/renderD128` und `/dev/dri/renderD129`. Alle drei Geräte verwenden die Gruppe `render`. `gnai-production` und `gnai-testing` besitzen nachweislich Lese-/Schreibzugriff; `gn-encoding` erhielt keine GPU-Gruppe. Nach Beseitigung einer konkurrierenden Gruppenverwaltung endete der Gesamtlauf mit `ok=55 changed=0 unreachable=0 failed=0`. Dieser Rollenlauf allein wies ROCm im Container oder tatsächliche Inferenz noch nicht nach.
+
+Das getrennte Playbook `verify-rocm-container.yml` lud am 20.09.2026 für `gnai-testing` den offiziellen `llama.cpp`-ROCm-Build `b11058` als unveränderliches amd64-Manifest `sha256:b429b8be10d3d0353a09c98f4ab840fe516f779858a28f9fd4e5bdf10bc63cb4`. Mit `/dev/kfd`, beiden Render-Nodes und `keep-groups` meldete `rocminfo` genau zwei `gfx1030`-Agents; `llama-server --list-devices` meldete `ROCm0` und `ROCm1` als Radeon RX 6900 XT. Der abschließende Lauf endete mit `ok=33 changed=0 unreachable=0 failed=0`. Die Probecontainer wurden entfernt; dauerhafter Container-, Modell- und Inferenzbetrieb sind damit noch nicht abgenommen.
 
 ## 3. Sicherheitsbefunde mit Priorität
 
@@ -116,4 +118,14 @@ deckte auf, dass `workload_accounts` ergänzende Gruppen wieder entfernte. Nach
 Der Abschlusslauf war mit `changed=0` idempotent; Images und Container blieben
 weiterhin leer.
 
+Der anschließende rootless ROCm-Probelauf verwendete das Image ausschließlich
+über seinen amd64-Manifest-Digest. Die OCI-Labels bestätigten Build `b11058`
+und Revision `f072b103714dfa1eee531f80b24512faf38e3dd2`. Zwei kurzlebige
+Container prüften mit denselben minimalen Geräteoptionen zunächst die
+Architektur über `rocminfo` und anschließend die Geräteerkennung von
+`llama-server`. Beide RX 6900 XT wurden als `gfx1030` und als getrennte
+`ROCm0`-/`ROCm1`-Geräte erkannt. Der finale Wiederholungslauf meldete
+`changed=0`; das Image bleibt im Testing-Store, laufende Container, Modelle
+und Inferenz wurden nicht eingerichtet.
+
 Die WireGuard-Evidenz bleibt der Teiltest vom 12.09.2026: CachyOS-Laptop von WAN, Handshake, Ping auf Gateway/Proxmox und direkter IPv4-Internetpfad bestanden; KI-Server war ausgeschaltet. Neue Rollen, weitere Clientvarianten, Gateway-GUI-Zugriff, WAN-/IPv6-Isolation, Neustart und Restore sind noch nicht abgenommen. GNAI-006 ist erst nach Klärung der offenen Werte, Umsetzung und dokumentierter Abnahme technisch abgeschlossen.

docs/ai/GNAI-007-PLAN_Ansible-Deployment.md

@@ -30,6 +30,7 @@
 | 2026-09-20 | 0.9 | spektr / Codex | getrennte rootless Konten für AI Production, AI Testing und CPU-Encoding eingerichtet; Parallelitäts- und Repository-Grenzen ergänzt |
 | 2026-09-20 | 0.10 | spektr / Codex | ROCm als Backend für zwei RX 6900 XT, initialen `llama.cpp`-Modellstand und Layer-Split mit gleicher GPU-Gewichtung festgehalten |
 | 2026-09-20 | 0.11 | spektr / Codex | AMD-Gerätezugriff für beide rootless KI-Konten implementiert, angewendet und idempotent geprüft |
+| 2026-09-20 | 0.12 | spektr / Codex | gepinnten rootless ROCm-Probelauf für Testing implementiert; zwei `gfx1030`-Agents und zwei `llama.cpp`-ROCm-Geräte nachgewiesen |
 
 ---
 
@@ -122,7 +123,7 @@ Planungsrichtung und noch nicht bestätigten Implementierungsdetails.
 
 | Thema | Aktueller Planungsstand | Verbindlichkeit / Nachweis |
 | --- | --- | --- |
-| Konfigurationsmanagement | Ansible beschreibt Basissystem, Laufzeitumgebung, Dienste und Konfiguration | Control-Projekt, Preflight, `host_baseline`, `podman_runtime` und `workload_accounts` vorhanden und angewendet; GPU- und Anwendungsrollen fehlen noch |
+| 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 |
@@ -391,8 +392,11 @@ Als Ausgangspunkt dient eine bereits auf einer RX 7900 XTX verwendete
 Podman-Compose-Konfiguration. Die Serverumsetzung wird daraus mit folgenden
 Abweichungen als rootless Quadlet erzeugt:
 
-- das Image `ghcr.io/ggml-org/llama.cpp:server-rocm` wird auf eine geprüfte
-  Version und den zugehörigen Digest festgelegt;
+- das Image `ghcr.io/ggml-org/llama.cpp:server-rocm` ist für den ersten
+  Testing-Stand als Build `b11058`, Revision
+  `f072b103714dfa1eee531f80b24512faf38e3dd2` und amd64-Manifest
+  `sha256:b429b8be10d3d0353a09c98f4ab840fe516f779858a28f9fd4e5bdf10bc63cb4`
+  festgelegt;
 - `/dev/kfd` und die tatsächlich benötigten `/dev/dri`-Geräte werden explizit
   eingebunden; `GroupAdd=keep-groups` erhält die nötigen ergänzenden
   Geräte-Gruppen im rootless Container;
@@ -442,12 +446,13 @@ angebundenen Slot läuft. `row` wird wegen seiner Ablösung im aktuellen
 mehr Kommunikation zwischen den Karten und ist mit dem geplanten
 quantisierten V-KV-Cache derzeit nicht kompatibel.
 
-Vor dem dauerhaften Start muss ein begrenzter Test `gfx1030`, beide GPUs,
-Device-Reihenfolge, verfügbaren VRAM und die tatsächliche 1:1-Verteilung in
-den `llama.cpp`-Startlogs bestätigen. Zusätzlich werden Prompt-Verarbeitung,
-Token-Generierung, VRAM-Nutzung und Stabilität bei 51.200 Token Kontext
-gemessen. Der 1:1-Wert ist erst nach diesem Test ein abgenommener
-Betriebsparameter.
+Der rootless Container-Probelauf hat inzwischen zwei `gfx1030`-Agents sowie
+`ROCm0` und `ROCm1` mit jeweils rund 16 GiB VRAM bestätigt. Vor dem dauerhaften
+Start muss ein begrenzter Modelltest noch die Device-Reihenfolge und die
+tatsächliche 1:1-Verteilung in den `llama.cpp`-Startlogs bestätigen. Zusätzlich
+werden Prompt-Verarbeitung, Token-Generierung, VRAM-Nutzung und Stabilität bei
+51.200 Token Kontext gemessen. Der 1:1-Wert ist erst nach diesem Test ein
+abgenommener Betriebsparameter.
 
 ---
 
@@ -627,8 +632,9 @@ nicht als Nachweis einer erfolgreichen Einrichtung.
 - Podman- und Quadlet-Grundruntime sowie getrennte rootless Workload-Konten
   eingerichtet und geprüft;
 - rootless Host-Gerätezugriff auf beide RX 6900 XT eingerichtet und geprüft;
-- ROCm-Funktion im rootless Container prüfen;
-- `llama.cpp` und lokaler Funktionstest;
+- ROCm-Funktion und `llama.cpp`-Geräteerkennung im rootless Testing-Container
+  mit gepinntem Image geprüft;
+- `llama.cpp` mit Modell und lokalem Inferenztest;
 - Wiederanlauf nach geplantem Reboot prüfen.
 
 ### Phase E – Anwendungen und Veröffentlichung
@@ -676,9 +682,9 @@ Vor der technischen Spezifikation sind mindestens folgende Punkte zu klären:
     Wiederanlauf von Production sicher, wenn Runner oder Testing ausfallen?
 15. Welche internen Hostnamen und Ports erhält Testing, und welche LAN-/VPN-
     Rollen dürfen darauf zugreifen?
-16. Funktioniert der benötigte AMD-GPU-Zugriff zuverlässig aus den getrennten
-    rootless Konten, und welche Gruppen-, Device- und Containeroptionen sind
-    dafür minimal erforderlich?
+16. Muss der für Testing nachgewiesene AMD-GPU-Zugriff vor der ersten
+    Production-Freigabe mit demselben gepinnten Image separat unter
+    `gnai-production` abgenommen werden?
 17. Wie wird ein Testing-Deployment eines Pull-Request-Commits in der
     eingesetzten Gitea-Version autorisiert, ohne Production-Secrets oder
     Production-Runner für veränderbaren PR-Code verfügbar zu machen?
@@ -844,26 +850,48 @@ bleibt ohne GPU-Gruppe. Der korrigierte Gesamtlauf endete mit
 `ok=55 changed=0 unreachable=0 failed=0`. Weder ein ROCm-Image noch ein
 Container oder eine Inferenz wurden dabei ausgeführt.
 
+Danach wurde `verify-rocm-container.yml` mit der eigenständigen Rolle
+`rocm_container_probe` ergänzt. Das Playbook wiederholt zunächst den
+Host-Gerätenachweis und arbeitet anschließend ausschließlich im rootless
+Podman-Store von `gnai-testing`. Es verwendet das offizielle
+`llama.cpp`-ROCm-Image als unveränderliches amd64-Manifest
+`sha256:b429b8be10d3d0353a09c98f4ab840fe516f779858a28f9fd4e5bdf10bc63cb4`
+und prüft dessen OCI-Labels auf Build `b11058` und Revision
+`f072b103714dfa1eee531f80b24512faf38e3dd2`.
+
+Die ephemeren Probecontainer erhielten nur `/dev/kfd`, die beiden zuvor
+ermittelten Render-Nodes und `keep-groups`; ein
+`HSA_OVERRIDE_GFX_VERSION` wurde nicht gesetzt. `rocminfo` meldete genau zwei
+GPU-Agents mit `gfx1030`. `llama-server --list-devices` meldete getrennt
+`ROCm0` und `ROCm1`, beide als AMD Radeon RX 6900 XT mit jeweils rund 16 GiB
+VRAM. Der Abschlusslauf endete mit
+`ok=33 changed=0 unreachable=0 failed=0`. Die Probecontainer wurden durch
+`--rm` entfernt; das gepinnte Image bleibt für den folgenden Testing-Aufbau im
+Store. Modellladen, Layer-Verteilung und Inferenz wurden noch nicht geprüft.
+
 ---
 
 ## 15. Abschlussgrenze dieses Entwurfs
 
-Mit Version 0.11 sind der aktuelle Planungsstand, der ausdrücklich begrenzte
+Mit Version 0.12 sind der aktuelle Planungsstand, der ausdrücklich begrenzte
 Ansible-Preflight, der verifizierte Deployment-Account und die angewendete
 minimale Host-Baseline, die Podman-/Quadlet-Grundruntime und die getrennten
-Workload-Konten sowie deren begrenzter AMD-Gerätezugriff persistiert.
+Workload-Konten, deren begrenzter AMD-Gerätezugriff sowie der rootless
+ROCm-/`llama.cpp`-Gerätenachweis für Testing persistiert.
 Insbesondere wurden noch nicht:
 
 - ein Gitea Runner angelegt,
 - Gitea Actions oder Schutzregeln konfiguriert,
-- eine ROCm-Container- oder Anwendungsrolle, ein Production-Inventar oder ein
+- eine dauerhafte `llama.cpp`-Anwendungsrolle, ein Production-Inventar oder ein
   Vault erstellt,
 - eine Production- oder Testing-Umgebung eingerichtet oder voneinander
   abgenommen,
-- ROCm-Userspace, GPU-Container oder Anwendungen auf dem KI-Server installiert,
+- ein dauerhafter GPU-Container, ein Modell oder eine Anwendung auf dem
+  KI-Server eingerichtet,
 - Backups oder Rollbacks praktisch getestet oder
 - die geplante Deploymentkette technisch abgenommen.
 
-Der nächste technische Schritt ist ein begrenzter rootless ROCm-Container-Test
-für beide KI-Konten, der beide Karten als `gfx1030` erkennen muss. Darauf bauen
-die `llama.cpp`-Rolle, das initiale Testing-Modellprofil und später LiteLLM auf.
+Der nächste technische Schritt ist die `llama.cpp`-Rolle für Testing. Sie soll
+das gepinnte Image als rootless Quadlet betreiben, das initiale Modell mit
+geprüfter Checksumme einbinden und den vorgesehenen Layer-Split sowie eine
+reale Inferenz abnehmen. Darauf baut anschließend LiteLLM auf.