llama-server auf einem VPS mit systemd betreiben

Was Sie erstellen

Der Betrieb des llama.cpp-Servers auf einem VPS umfasst eine einzelne Binärdatei, llama-server. Diese lädt eine einzelne GGUF-Modelldatei und verarbeitet HTTP-Anfragen über eine OpenAI-kompatible API. Richten Sie einen beliebigen OpenAI-Client auf http://127.0.0.1:8080/v1, funktioniert er. Die Installation ist der einfache Teil.

Der übrige Aufwand betrifft den Betrieb: Version festlegen, den Port auf localhost beschränken, eine systemd-Unit erstellen und festlegen, was bei einem Speichermangel des Servers geschehen soll. Darum geht es in dieser Anleitung. Wenn Sie noch nicht zwischen den beiden naheliegenden Optionen entschieden haben, lesen Sie zuerst den Vergleich zwischen Ollama und llama.cpp. Dieser Artikel beschreibt bewusst die Vorgehensweise, die der Vergleich auslässt.

Wählen Sie ein Release-Tag aus und notieren Sie es

llama.cpp versieht nahezu jeden Merge mit einem Release-Tag. Die Tags sind daher Build-Nummern. b10488 ist der neueste Stand vom 18. August 2026. Es gibt keinen langfristig gepflegten stabilen Branch. „latest“ ist daher ein bewegliches Ziel. Die getestete Version ist die einzige Version, die Sie unterstützen können. Wählen Sie ein Tag aus, notieren Sie es und verwenden Sie dieselbe Zeichenfolge beim Klonen, im Namen Ihrer Binärdatei und in Ihren Notizen.

Zu jedem Tag gehören außerdem vorkompilierte Archive. Für eine CPU-only-x86-VPS ist das llama-b10488-bin-ubuntu-x64.tar.gz. Wenn Sie eine ARM-VPS statt einer x86-VPS verwenden, befindet sich daneben ein arm64-Archiv.

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10488/llama-b10488-bin-ubuntu-x64.tar.gz
tar tf llama-b10488-bin-ubuntu-x64.tar.gz | head

Listen Sie das Archiv vor dem Entpacken auf. So sehen Sie, wo die Dateien abgelegt werden. Diese Binärdateien sind gegen die C-Bibliothek des Images gelinkt, mit dem sie erstellt wurden. Auf einer älteren Distribution schlagen sie beim Start daher mit einem Fehler fehl, der eine nicht installierte GLIBC_-Version nennt. Das Erstellen aus dem Quellcode dauert auf einer kleinen VPS nur wenige Minuten und beseitigt diese gesamte Fehlerklasse. Daher verwenden wir im Folgenden diesen Weg.

llama-server aus einem festgelegten Tag erstellen

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone --depth 1 --branch b10488 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2

--branch b10488 auf einem --depth 1-Clone checkt diesen Tag und nichts anderes aus. Dadurch kann sich der Build während der Arbeit nicht verändern.

libssl-dev ist erforderlich, weil die Option LLAMA_OPENSSL standardmäßig aktiviert ist. Sie ermöglicht es der Binärdatei, später Modelle über HTTPS herunterzuladen. Ohne die Header schlägt der Konfigurationsschritt fehl.

-DBUILD_SHARED_LIBS=OFF erzeugt eine eigenständige Binärdatei. Der Standard-Build legt gemeinsam verwendete Bibliotheken neben der ausführbaren Datei ab. Wenn Sie dann nur die ausführbare Datei nach /usr/local/bin kopieren, schlägt der Start mit error while loading shared libraries: libllama.so fehl.

-t llama-server erstellt nur das Server-Target. Beim Standard-Build werden außerdem die anderen Werkzeuge und die Tests kompiliert. Auf einer VPS mit zwei Kernen dauert das mehrere zusätzliche Minuten für Dateien, die Sie nie ausführen werden.

-j 2 ist beabsichtigt. Jeder parallele Kompilierjob benötigt einen eigenen Arbeitssatz. Daher endet -j $(nproc) auf einem kleinen Tarif mit c++: fatal error: Killed signal terminated program cc1plus. Dabei beendet der Out-of-Memory-Killer des Kernels den Compiler. Verringern Sie die Anzahl der Jobs oder fügen Sie für den Build Swap hinzu.

Ein Flag möchten Sie möglicherweise ändern: GGML_NATIVE ist standardmäßig aktiviert. Dadurch zielt der Compiler auf die genaue CPU, auf der der Build ausgeführt wird. Das ist sinnvoll, wenn Sie den Build auf der Maschine erstellen, auf der die Binärdatei später läuft. Wenn Sie einmal erstellen und die Binärdatei auf einen anderen Host kopieren, fügen Sie -DGGML_NATIVE=OFF hinzu. Andernfalls beendet sich eine Binärdatei, die Instruktionen verwendet, die die andere CPU nicht unterstützt, bei der ersten Inferenz mit Illegal instruction (core dumped).

Installieren Sie die Binärdatei unter einem Namen, der den Tag enthält.

./build/bin/llama-server --version
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-b10488
sudo ln -sfn /usr/local/bin/llama-server-b10488 /usr/local/bin/llama-server

--version gibt die Build-Nummer und den Commit aus. Diese müssen mit dem ausgecheckten Tag übereinstimmen. Falls nicht, haben Sie etwas anderes erstellt. Wenn die Nummer im Dateinamen enthalten ist und ein Symlink auf diese Datei zeigt, besteht ein Upgrade aus einem ln -sfn und einem Neustart. Ein Rollback erfolgt mit demselben Befehl und der alten Nummer.

Ein GGUF-Modell herunterladen und zuerst den Speicherplatz prüfen

GGUF ist das einzige Dateiformat, das llama.cpp lädt. Eine Datei enthält die Gewichte, den Tokenizer und die Metadaten. Sie müssen daher nichts weiter installieren. Das Suffix des Dateinamens bezeichnet die Quantisierung, also die Genauigkeit, mit der die Gewichte gespeichert sind: Q4_K_M ist eine 4-Bit-Mischung, Q8_0 verwendet 8 Bit und f16 ist die nicht quantisierte Datei mit halber Genauigkeit.

Legen Sie ein Dienstkonto und ein Modellverzeichnis an, bevor Sie etwas herunterladen.

sudo useradd --system --home /srv/llama --create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
df -h /srv

Der Server kann ein Modell mit -hf selbst herunterladen. Das ist der schnellste Weg, um zu prüfen, ob Ihr Build funktioniert.

sudo -u llama env LLAMA_CACHE=/srv/models /usr/local/bin/llama-server \
  -hf ggml-org/gemma-3-1b-it-GGUF:Q4_K_M --host 127.0.0.1 --port 8080

LLAMA_CACHE legt das Downloadverzeichnis fest. Ohne diese Option wird die Datei unter ~/.cache/llama.cpp im Konto des Benutzers gespeichert, der den Befehl ausgeführt hat. Das ist der falsche Speicherort für einen Dienst, dessen Home-Verzeichnis Sie gleich unlesbar machen werden. Führen Sie anschließend ls -lh /srv/models aus, weil der Name der zwischengespeicherten Datei aus dem Repository-Namen und nicht aus dem einfachen Dateinamen abgeleitet wird.

Laden Sie die Datei für einen Dienst in einen von Ihnen festgelegten Pfad herunter. So kann die Unit-Datei auf einen stabilen Speicherort verweisen.

sudo -u llama curl -L --output-dir /srv/models -O \
  https://huggingface.co/ggml-org/gemma-3-1b-it-GGUF/resolve/main/gemma-3-1b-it-Q4_K_M.gguf

Der Speicherplatz ist die erste Begrenzung, auf die viele stoßen. Dies sind die veröffentlichten Dateigrößen für zwei Modelle, geprüft am 18. August 2026.

[
  {
    "label": "gemma-3-1b-it Q4_K_M",
    "size_gb": 0.81
  },
  {
    "label": "gemma-3-1b-it Q8_0",
    "size_gb": 1.07
  },
  {
    "label": "gemma-3-1b-it f16",
    "size_gb": 2.01
  },
  {
    "label": "gpt-oss-20b MXFP4",
    "size_gb": 12.11
  }
]

Die 4-Bit-Datei des 1B-Modells ist 0.81 GB groß. Dasselbe Modell ohne Quantisierung belegt 2.01 GB. Die Wahl des Formats verändert die Größe somit um mehr als den Faktor zwei. Ein 20B-Modell mit MXFP4 belegt 12.11 GB. Auf vielen Einsteiger-Tarifen passt es nicht auf die Festplatte. Anschließend muss es außerdem in den Arbeitsspeicher eingelesen werden. Wenn Sie eine bestimmte Modellfamilie in Betracht ziehen, zeigt dieselbe Größenberechnung für GLM, wie schnell das Hauptmodell den verfügbaren VPS-Speicher überschreitet, während ein kleineres Schwestermodell noch passt.

Prüfen Sie df -h vor jedem Download. Wenn das Root-Dateisystem während einer Übertragung von 12 GB voll läuft, können alle anderen Prozesse, die schreiben müssen, ebenfalls fehlschlagen. Dazu gehört auch das Journal.

Führen Sie den Prozess einmal manuell aus und prüfen Sie ihn.

sudo -u llama /usr/local/bin/llama-server \
  --model /srv/models/gemma-3-1b-it-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 4096 --parallel 1 --threads 2 --no-webui

Fragen Sie in einer zweiten Sitzung den Server ab, ob er bereit ist.

curl -s http://127.0.0.1:8080/health

Während die Datei geladen wird, erhalten Sie HTTP 503 mit folgendem Body:

{"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}

Wenn der Server bereit ist, lautet der Body {"status": "ok" }. Senden Sie anschließend eine echte Anfrage.

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"Say hello in five words."}]}'

Ein JSON-Objekt mit einem choices-Array zeigt, dass der Server funktioniert. Das Feld model ist vorhanden, weil OpenAI-Clients es immer mitsenden. Auf diesem Server ist ein einzelnes Modell geladen. Daher wird der Wert nicht zur Auswahl verwendet.

Die OpenAI-kompatible API und was sonst noch auf dem Port verfügbar ist

POST /v1/chat/completions, POST /v1/completions und POST /v1/embeddings sind die OpenAI-kompatiblen Routen, und GET /v1/models meldet das geladene Modell. GET /health ist die oben beschriebene Bereitschaftsprüfung, GET /props gibt die aktuellen Servereinstellungen zurück, und GET /metrics stellt Prometheus-Zähler bereit, wenn Sie den Server mit --metrics starten.

Jedes OpenAI SDK funktioniert, sobald Sie die Basis-URL auf http://127.0.0.1:8080/v1 setzen und eine nicht leere API-Schlüsselzeichenfolge übergeben. Dieser Schlüssel wird erst geprüft, wenn Sie --api-key selbst festlegen.

Übernehmen Sie keine Durchsatzangabe als Wert für Ihren eigenen Plan. Die CPU-Inferenzgeschwindigkeit hängt von der Anzahl der Kerne, der Speicherbandbreite und den anderen Mandanten ab, mit denen Sie den Host teilen. Messen Sie daher die Token pro Sekunde auf Ihrem eigenen System und betrachten Sie dieses Ergebnis als maßgeblich. Gestohlene CPU-Zeit durch einen ausgelasteten Nachbarn zeigt sich hier als Generierungsgeschwindigkeit, die sich von Stunde zu Stunde ändert.

Auf 127.0.0.1 belassen und einen Proxy davorschalten

--host verwendet standardmäßig bereits 127.0.0.1. Der Server ist daher von außen nicht erreichbar, solange Sie diese Einstellung nicht ändern. Lassen Sie sie unverändert. In llama-server gibt es kein Benutzermodell, keine Rate-Begrenzung und kein brauchbares Audit-Log. Die einzige integrierte Zugriffskontrolle ist --api-key. Sie vergleicht eine Zeichenkette. Ein offener Inferenzport stellt jedem, der ihn findet, kostenlose Rechenleistung bereit. Derselbe Fehler mit Ollama hat dieselbe Ursache und Struktur: Absicherung einer selbst gehosteten Modell-API gilt hier unverändert.

Beenden Sie TLS (Transport Layer Security) in nginx und leiten Sie die Anfragen an den Loopback-Port weiter.

server {
    listen 443 ssl;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

proxy_buffering off ist für Streaming erforderlich. Bei aktiviertem Buffering hält nginx die Server-Sent Events (SSE) zurück, bis die Antwort abgeschlossen ist. Der Client wartet daher ohne Ausgabe und erhält anschließend die gesamte Antwort auf einmal. proxy_read_timeout 600s deckt lange Generierungen ab, weil der Standardwert von 60 Sekunden eine langsame Antwort in 504 Gateway Time-out umwandelt. Rufen Sie das Zertifikat mit Certbot und Let's Encrypt mit nginx ab.

Die systemd-Unit

Schreiben Sie /etc/systemd/system/llama-server.service.

[Unit]
Description=llama.cpp server
After=network-online.target
Wants=network-online.target

[Service]
User=llama
Group=llama
Environment=LLAMA_ARG_MODEL=/srv/models/gemma-3-1b-it-Q4_K_M.gguf
Environment=LLAMA_ARG_HOST=127.0.0.1
Environment=LLAMA_ARG_PORT=8080
Environment=LLAMA_ARG_CTX_SIZE=4096
Environment=LLAMA_ARG_N_PARALLEL=1
Environment=LLAMA_ARG_THREADS=2
ExecStart=/usr/local/bin/llama-server --no-webui
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
MemoryHigh=3G
MemoryMax=3500M
OOMPolicy=stop
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

Die Einstellungen stehen in den Zeilen von Environment=, weil llama-server die LLAMA_ARG_*-Variablen für die meisten Flags liest. Ein Befehlszeilenargument überschreibt dabei die entsprechende Variable. Dadurch können Sie die Kontextgröße an einer zentralen Stelle ändern. Außerdem bleibt ExecStart kurz genug, um es auf einen Blick zu erfassen.

ProtectSystem=strict macht das gesamte Dateisystem für diese Unit schreibgeschützt. Das ist unproblematisch, weil der Server das Modell nur liest. Fügen Sie ReadWritePaths=/srv/models hinzu, wenn der Dienst selbst Modelle mit -hf herunterladen soll. ProtectHome=yes blendet /home und /root aus. Das ist der zweite Grund, Modelle in /srv abzulegen: Wenn ProtectHome aktiviert ist, ist der Standardpfad ~/.cache/llama.cpp für den Prozess überhaupt nicht sichtbar.

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server
systemctl status llama-server
curl -s http://127.0.0.1:8080/health
journalctl -u llama-server -n 50 --no-pager

enable --now ist der Teil, den viele überspringen. Ohne enable ist der Server nach dem nächsten Reboot nicht mehr aktiv. Wenn Sie geplante Aufgaben rund um den Dienst ausführen möchten, beispielsweise jede Nacht nach einem neuen Release suchen, ist ein systemd-Dienst mit Timer der dafür vorgesehene Mechanismus.

Entscheiden Sie vorab, was bei OOM passiert

Die Speichernutzung besteht aus zwei Teilen, die sich unter einem Limit unterschiedlich verhalten. Die Modelldatei wird standardmäßig per Memory-Mapping eingebunden. Ihre Seiten sind daher dateigestützt: Der Kernel kann sie verwerfen und später erneut von der Festplatte einlesen. Der KV-Cache enthält den Zustand pro Token, den der Server für jede aktive Unterhaltung speichert. Er liegt im anonymen Speicher. Er kann nicht verworfen werden und führt deshalb dazu, dass der Prozess beendet wird.

Deshalb haben die beiden Limits in der Unit unterschiedliche Aufgaben. MemoryHigh=3G ist ein Soft Limit. Oberhalb dieses Werts setzt der Kernel die Cgroup unter Reclaim-Druck. Dadurch werden eingebundene Modellseiten ausgelagert und beim nächsten Token erneut von der Festplatte gelesen. Der Dienst bleibt aktiv, wird aber langsamer. MemoryMax=3500M ist ein Hard Limit. Oberhalb dieses Werts wird der Prozess beendet. Im Journal wird das eindeutig vermerkt.

llama-server.service: A process of this unit has been killed by the OOM killer.

Setzen Sie --ctx-size selbst. Der Standardwert ist 0. Er entspricht dem Kontext, mit dem das Modell trainiert wurde. Bei einem modernen Modell mit langem Kontext wird dadurch beim Start ein sehr großer KV-Cache reserviert. Der Dienst wird dann beendet, bevor er eine einzige Anfrage verarbeitet. --parallel vervielfacht denselben Speicherbedarf, weil jeder Slot seinen eigenen Unterhaltungszustand enthält. Lassen Sie den Wert daher auf 1, bis Sie Parallelverarbeitung benötigen.

Mit Restart=on-failure wird ein beendeter Dienst erneut gestartet. Wird er bei jedem Start beendet, gibt systemd auf, und systemctl status gibt start request repeated too quickly aus. Das ist das korrekte Verhalten: Eine Neustartschleife, die alle fünf Sekunden eine 12-GB-Datei erneut einliest, ist schlechter als ein Ausfall. Korrigieren Sie das Limit oder die Kontextgröße und löschen Sie anschließend den Zustand mit sudo systemctl reset-failed llama-server.

Überwachen Sie mit systemctl show llama-server -p MemoryCurrent den tatsächlichen Wert, während eine Anfrage verarbeitet wird. Prozessspeicher und CPU mit systemd begrenzen behandelt diese Direktiven ausführlicher.

Vermeiden Sie Swap für diese Arbeitslast. Bei einem ausgelagerten Modell wird jedes Token zu Festplattenzugriffen an zufälligen Offsets. Das Einbinden der Modelldatei per Memory-Mapping erzielt denselben Effekt mit weniger Nachteilen, weil der Kernel die benötigten Seiten direkt aus der Datei liest.

Wo Ollama die bessere Wahl ist

Hier gibt es zwei Wege. Wählen Sie llama-server, wenn Sie einen einzelnen Prozess mit selbst gesetzten Flags, einem festgelegten Build und einer von Ihnen ausgewählten Datei möchten. Im Hintergrund ändert sich nichts, weil kein anderer Prozess läuft.

Wählen Sie Ollama, wenn Sie Modelle verwalten möchten: Modelle nach Namen herunterladen, mehrere Modelle auf der Festplatte vorhalten, ein nicht verwendetes Modell entladen und mit einem einzigen Befehl aktualisieren, statt einen neuen Build zu erstellen. Diese Aufgaben müssten Sie andernfalls selbst skripten. Ollama auf einem VPS ausführen erfüllt dieselbe Aufgabe, setzt den Schwerpunkt aber anders. Beide stellen eine OpenAI-kompatible API bereit. Der Client-Code funktioniert daher unabhängig von der Richtung des Wechsels weiter.

Ein gepinntes Build aktualisieren

Ersetzen Sie bNNNNN durch den Tag, auf den Sie wechseln.

cd llama.cpp
git fetch --tags
git checkout bNNNNN
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-bNNNNN
sudo ln -sfn /usr/local/bin/llama-server-bNNNNN /usr/local/bin/llama-server
sudo systemctl restart llama-server

Die alte Binärdatei bleibt auf dem Datenträger. Für ein Rollback setzen Sie ln -sfn wieder auf llama-server-b10488 und starten den Dienst neu. Lesen Sie die Release Notes, bevor Sie wechseln. GGUF-Dateien sind versioniert, und ältere Dateien werden weiterhin geladen. Flags werden jedoch umbenannt: --mlock und --no-mmap sind zugunsten von --load-mode bereits veraltet. Eine Unit-Datei, die ein entferntes Flag übergibt, schlägt beim Start mit einer Meldung zu einem nicht erkannten Argument fehl.

Fehlerbilder und die angezeigten Meldungen

error while loading shared libraries: libllama.so, nachdem Sie die Binärdatei an einen anderen Ort kopiert haben. Der Standard-Build erzeugt daneben gemeinsam genutzte Bibliotheken. Erstellen Sie den Build mit -DBUILD_SHARED_LIBS=OFF neu oder kopieren Sie das gesamte Verzeichnis build/bin.

Illegal instruction (core dumped) beim Start oder bei der ersten Anfrage. Die Binärdatei wurde mit aktiviertem GGML_NATIVE für eine andere CPU als die des aktuellen Systems kompiliert. Erstellen Sie den Build auf diesem Rechner neu oder konfigurieren Sie ihn mit -DGGML_NATIVE=OFF.

c++: fatal error: Killed signal terminated program cc1plus während des Builds. Der Compiler wurde beendet, weil er zu viel Arbeitsspeicher verwendet hat. Verringern Sie -j oder fügen Sie für den Build Swap hinzu und entfernen Sie ihn anschließend wieder.

curl: (7) Failed to connect ... Connection refused von Ihrem Laptop aus. Das ist korrekt: Der Server lauscht auf der Loopback-Adresse des VPS. Testen Sie auf dem VPS selbst oder öffnen Sie mit ssh -L 8080:127.0.0.1:8080 user@your-vps einen Tunnel und verwenden Sie http://127.0.0.1:8080 lokal.

HTTP 503 mit "message":"Loading model" während der ersten Sekunden oder Minuten nach einem Neustart. Das Einlesen einer mehrere Gigabyte großen Datei dauert. Außerdem meldet systemd die Unit als aktiv, sobald der Prozess startet. Das geschieht deutlich bevor das Modell im Arbeitsspeicher liegt.

Anfragen hängen und liefern anschließend 504 Gateway Time-out zurück. Der Proxy hat die Anfrage beendet, bevor das Modell fertig war. Erhöhen Sie proxy_read_timeout und deaktivieren Sie proxy_buffering, damit die Tokens während ihrer Erzeugung an den Client übertragen werden.

Die Unit wird wiederholt gestartet und beendet sich anschließend mit start request repeated too quickly. Bei jedem Start beendet ein Prozess die Unit. Prüfen Sie journalctl -u llama-server auf den Eintrag des OOM-Killers. Verringern Sie anschließend --ctx-size, verringern Sie --parallel oder erhöhen Sie MemoryMax.

FAQ

Sollte ich den Server von llama.cpp oder Ollama auf meinem VPS ausführen?

Führen Sie llama-server aus, wenn Sie einen exakten Build festlegen, präzise Flags übergeben und ein Modell in einer einzelnen Datei verwalten möchten, die nicht unbemerkt aktualisiert wird. Verwenden Sie Ollama, wenn Sie Modellverwaltung und Upgrades mit einem Befehl benötigen. Modelle anhand ihres Namens abzurufen, mehrere Modelle auf der Festplatte zu verwalten und nicht verwendete Modelle zu entladen, müssten Sie sonst selbst skripten. Beide stellen eine OpenAI-kompatible API bereit. Der Client-Code muss sich daher bei einem späteren Wechsel nicht ändern.

Auf welche llama.cpp-Version sollte ich mich festlegen?

Auf jedes Tag, das Sie tatsächlich gebaut und getestet haben. llama.cpp versieht nahezu jeden Merge mit einem Tag. Die Namen sind Build-Nummern wie b10488. Das war am 18 August 2026 das neueste Tag. Es gibt keinen separaten stabilen Branch. Daher ändert sich der aktuelle Stand mehrmals täglich. Klonen Sie mit --branch <tag>, installieren Sie die Binärdatei unter einem Dateinamen, der dieses Tag enthält, und verweisen Sie mit einem Symlink darauf. Dadurch werden Upgrade und Rollback jeweils zu einem einzelnen Befehl.

Wie viel RAM benötigt llama-server?

Gehen Sie von der Größe der GGUF-Datei aus. Addieren Sie anschließend den KV-Cache. Dieser wächst mit --ctx-size und mit der Anzahl der --parallel-Slots. Veröffentliche Werte ersetzen keine Messung Ihrer eigenen Umgebung. Die Gesamtgröße hängt vom Modell, der Quantisierung und dem von Ihnen erlaubten Kontext ab. Führen Sie systemctl show llama-server -p MemoryCurrent aus, während eine Anfrage verarbeitet wird, und verwenden Sie den angezeigten Wert.

Warum liefert /health mit „Loading model“ den Status 503?

Der Prozess wurde gestartet, aber die Modelldatei befindet sich noch nicht im Speicher. Daher antwortet der Server mit {"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}. Das ist nach jedem Neustart normal und dauert so lange, wie das Einlesen der Datei dauert. Es wird nur dann zum Problem, wenn ein Client oder ein Proxy den ersten Status 503 als endgültigen Fehler behandelt. Fragen Sie /health wiederholt ab, bis {"status": "ok" } zurückgegeben wird.

Kann ich llama-server direkt im Internet bereitstellen?

Binden Sie den Server nicht an 0.0.0.0 und öffnen Sie den Port nicht. Der Server bietet keine Konten und keine Ratenbegrenzung. Außerdem gibt es kein verwertbares Anfrageprotokoll für Audits. Die einzige integrierte Prüfung ist --api-key. Sie vergleicht eine einzelne Zeichenfolge. Behalten Sie die standardmäßige Bind-Adresse 127.0.0.1 bei, schalten Sie nginx mit TLS davor und setzen Sie zusätzlich --api-key. Dadurch bleibt das Modell auch bei einem Fehler in der Proxy-Konfiguration nicht für alle erreichbar.