3.7 KiB
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.
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:
# 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/currentwird angelegt. - Spätere Builds: der Link bleibt stehen, der neue Pfad wird ausgegeben.
- Expliziter
LLAMA_SERVER_BINinllama.envhat Vorrang vor dem Link. - Ohne expliziten Pfad: verwalteter Link, sonst
llama-serveraus 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.
~/.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
Ein echter CUDA-Build und Modellbetrieb müssen auf der Zielmaschine geprüft werden. Die mitgelieferten Tests benutzen keine GPU und laden keine Gewichte.