# 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 ` 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.