Initial commit

docs/LLAMA_INSTALL.md

@@ -0,0 +1,77 @@
+# llama.cpp samt Server, CLI und Benchmark installieren
+
+Der Installer baut die drei Programme `llama-server`, `llama-cli`, `llama-bench`
+aus dem offiziellen Repository mit CUDA. Er überschreibt weder `/usr/bin` noch
+einen vorhandenen Build und startet keinen Dienst. Kein AUR-Helper erforderlich.
+
+## Neue Arch-Maschine
+
+Zuerst einen zur GPU passenden NVIDIA-Treiber einrichten. `nvidia-smi` muss
+funktionieren. Treiberwahl und Kernelupdates werden nicht automatisiert.
+
+```bash
+sudo pacman -Syu --needed base-devel git cmake ninja cuda openssl
+```
+
+Dies ist eine vollständige Arch-Systemaktualisierung. Bei Kernel-/Treiberupdate
+Jobs beenden und neu starten, bevor du die GPU-Installation testest. Keine
+partielle Aktualisierung durch Ausschließen einzelner Systempakete erzwingen.
+
+Dann aus dem Deployment-Repo:
+
+```bash
+# master bewusst ausgewählt, keine als stabil behauptete Release-Version:
+./scripts/install-llama-cpp.sh --ref master --jobs 4 --cuda-arch 86
+```
+
+`86` ist für RTX 3080 gewählt. Für einen anderen Rechner dessen GPU-Architektur
+angeben. Mit `--ref <vollständiger-Commit>` lässt sich derselbe Quellstand erneut
+bauen. Tags/Branches werden aufgelöst und im jeweiligen `BUILD-INFO.txt` zusammen
+mit der SHA gespeichert. CUDA/Compiler/Arch-Pakete bleiben rollende Abhängigkeiten;
+das ist kein bitidentisch eingefrorenes Betriebssystem-Image.
+`--prefix /absoluter/pfad` erlaubt einen anderen Build-Speicherort. Dann den
+ausgegebenen Binary-Pfad ausdrücklich in `LLAMA_SERVER_BIN` konfigurieren.
+
+Falls CUDA den installierten Hostcompiler ablehnt: kompatiblen Compiler nach
+CUDA-/Arch-Dokumentation wählen und CMake z.B. über `CC`, `CXX`, `CUDAHOSTCXX`
+konfigurieren. Kein automatisches `--allow-unsupported-compiler` und keine
+Treiber-/Systemdateipatches. Ein fehlgeschlagener Build lässt aktive Versionen
+unverändert und bleibt zur Diagnose erhalten.
+
+Der Installer kopiert das Build-bin-Verzeichnis einschließlich dortiger
+Begleitdateien. Die Projektbibliotheken werden statisch gebaut; CUDA- und
+Systembibliotheken bleiben Laufzeitabhängigkeiten. Auf neuer Hardware neu bauen,
+nicht nur die Binary übertragen.
+
+## Auswahl
+
+- Erster verwalteter Build: Link `~/.local/opt/llama.cpp/current` wird angelegt.
+- Spätere Builds: der Link bleibt stehen, der neue Pfad wird ausgegeben.
+- Expliziter `LLAMA_SERVER_BIN` in `llama.env` hat Vorrang vor dem Link.
+- Ohne expliziten Pfad: verwalteter Link, sonst `llama-server` aus PATH.
+
+Auf der bisherigen Workstation **zunächst `/usr/bin/llama-server` beibehalten**.
+Einen Backend-Versionswechsel und VRAM-Tuning nicht im selben Vergleich vermischen.
+Für einen späteren Build dessen ausgegebenen Pfad in `LLAMA_SERVER_BIN` eintragen,
+prüfen und erst nach Jobende mit dem Restart-Helfer aktivieren. Den alten Pfad
+notieren; Rücknahme bedeutet Pfad zurücksetzen und erneut kontrolliert starten.
+
+```bash
+~/.local/libexec/hermes-stack-llama-run --check
+```
+
+Die Prüfung lädt kein Modell. Das erste echte Starten mit `LLAMA_HF_REPO`
+benötigt Netzwerk, genug Plattenplatz und ein vorhandenes HF-Repository. Bei
+Download-/Modellproblemen die vom Nutzer angegebene Modell-ID prüfen; sie wurde
+hier nicht heruntergeladen. Für offline und feste Modellversionen lokale
+GGUF-Dateien und ggf. passenden Vision-Projektor verwenden, SHA256 notieren.
+Modell und Projektor werden separat gesichert, nicht im Git-Repo abgelegt.
+
+## Offizielle Grundlagen
+
+- [llama.cpp bauen, CUDA und GPU-Architekturen](https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md)
+- [Arch CUDA-Paket](https://archlinux.org/packages/extra/x86_64/cuda/)
+- [NVIDIA Compute Capability](https://developer.nvidia.com/cuda-gpus)
+
+Ein echter CUDA-Build und Modellbetrieb müssen auf der Zielmaschine geprüft
+werden. Die mitgelieferten Tests benutzen keine GPU und laden keine Gewichte.