Erster produktiver Start des llama.cpp-Testing-Stacks auf ghostnet-ki (31.10.2026). Fix-Liste aus den Live-Läufen: - Quadlet-Exec ohne Binärnamen (AMD-Image hat ENTRYPOINT /app/llama-server; GNAI-010 v0.6 dokumentiert den Befund) - Deterministischer daemon-reload vor Unit-Zugriff (Handler allein griff nicht, wenn ein vorheriger Lauf die Quadlets gerendert hatte) - Netz-Abhängigkeit Wants/After im Container-Quadlet (Netzwerk-Unit wurde nie mitgestartet -> network not found) - Stopp-Bedingung für Profilwechsel korrigiert (nur aktive Units stoppen) - Health-Tool-Kette curl/wget/bash-/dev/tcp mit Pfad-Normalisierung; curl -f als Gesundheitssignal (Statuszeile stand nie im stdout) - chdir für alle runuser-Aufrufe der Health-Checks Nachweise: Health 200 OK, /v1/models Alias korrekt, Idempotenz changed=0, VRAM 12,6/13,0 GiB von je 16 GiB auf beiden Karten (Layer-Split 1:1), echte Chat-Completion mit System-Fingerprint des gepinnten Builds, Reasoning getrennt von der Antwort. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
LLM-Server ghostnet-ki
Dieser Gerätebereich dokumentiert den physischen Server 10.0.0.90. Er
gruppiert die gemeinsame Hostbasis, den eigentlichen LLM-Stack, den davon
fachlich getrennten CPU-Encoding-Workload und das host-weite Monitoring. Alle
vier Bereiche teilen Hardware, Betriebssystem und Ansible-Control-Projekt.
| Bereich | Inhalt |
|---|---|
| Host | Hardware, Debian-Basis und GPU-Ausgangslage |
| Zugänge | Benutzer, Netzwerk, Resolver und SSH |
| AI | Architektur, Ansible-Deployment, Modellbewertung und llama.cpp-Serving |
| Encoding | CPU-Encoding-Architektur und Pipeline-Plan |
| Monitoring | Systemmetriken, Collector und Dashboard |
Übergreifende Rollen stehen im Zugriffskonzept, der Gesamtstand im zentralen Dokumentationsindex.