SSD Nodes Learn 🎉 VPS ab $5.50/Monat
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-21

llama.cpp-Server auf einem VPS mit systemd betreiben

Bauen Sie llama-server aus einem festen Tag, laden Sie GGUF-Modelle über die OpenAI-kompatible API und sichern Sie localhost-Bindung sowie Speicherlimits per systemd.

Was Sie erstellen

Der Betrieb des llama.cpp-Servers auf einem VPS besteht aus einer einzelnen Binärdatei, llama-server, die eine einzelne GGUF-Modelldatei lädt und HTTP-Anfragen über eine mit OpenAI kompatible API beantwortet. 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: eine Version festlegen, den Port auf localhost beschränken, eine systemd-Unit erstellen und festlegen, was passiert, wenn dem System der Arbeitsspeicher ausgeht. Darum geht es in dieser Anleitung. Wenn Sie noch nicht zwischen den beiden naheliegenden Optionen entschieden haben, lesen Sie zuerst die Unterschiede zwischen Ollama und llama.cpp, denn diese Anleitung behandelt bewusst den praktischen Teil, den dieser Vergleich auslässt.

Release-Tag auswählen und dokumentieren

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 stabilen Branch. „latest“ ändert sich daher laufend, und die getestete Version ist die einzige Version, die Sie unterstützen können. Wählen Sie einen Tag aus, dokumentieren Sie ihn und verwenden Sie dieselbe Zeichenfolge für den Clone, den Namen der Binärdatei und Ihre Notizen.

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

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, in dem sie erstellt wurden. Auf einer älteren Distribution schlagen sie daher beim Start 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 vermeidet diese gesamte Problemklasse. Daher wird im Folgenden dieser Weg verwendet.

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-Klon checkt ausschließlich diesen Tag aus. Dadurch kann sich der Build während der Arbeit nicht unbeabsichtigt ä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. Beim Standard-Build werden gemeinsam genutzte Bibliotheken neben der ausführbaren Datei abgelegt. Wenn Sie anschließend 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-Ziel. 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 nicht ausführen werden.

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

Ein Flag können Sie gegebenenfalls ändern: GGML_NATIVE ist standardmäßig aktiviert, sodass der Compiler für die CPU kompiliert, auf der der Build ausgeführt wird. Das ist die richtige Einstellung, wenn Sie auf dem Rechner kompilieren, auf dem die Binärdatei später ausgeführt wird. Wenn Sie einmal kompilieren und die Binärdatei auf einen anderen Host kopieren, fügen Sie -DGGML_NATIVE=OFF hinzu. Andernfalls beendet sich eine Binärdatei mit Illegal instruction (core dumped) bei der ersten Inferenz, sobald sie Anweisungen verwendet, die von der anderen CPU nicht unterstützt werden.

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. Beides muss zum ausgecheckten Tag passen. Falls nicht, haben Sie etwas anderes gebaut. 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 beziehen 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. Daher muss nichts anderes installiert werden. Das Suffix des Dateinamens gibt die Quantisierung an, also die Präzision, 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 Präzision.

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 abgelegt, der den Befehl ausgeführt hat. Das ist der falsche Ort für einen Dienst, dessen Home-Verzeichnis Sie gleich unlesbar machen werden. Führen Sie anschließend ls -lh /srv/models aus, weil der Cache-Dateiname aus dem Repository-Namen und nicht aus dem einfachen Dateinamen abgeleitet wird.

Laden Sie die Datei für einen Dienst in einen von Ihnen gewählten Pfad herunter. So kann die Unit-Datei auf einen stabilen Pfad 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 das erste Limit, auf das viele stoßen. Dies sind die veröffentlichten Dateigrößen für zwei Modelle, geprüft am 18. August 2026.

ChartGGUF file size on disk, published figures, 18 August 2026
The data behind this chart
[
  {
    "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 für das 1B-Modell ist 0.81 GB groß. Dasselbe Modell ohne Quantisierung ist 2.01 GB groß. Die Wahl des Formats verändert die Größe damit um mehr als den Faktor zwei. Ein 20B-Modell mit MXFP4 ist 12.11 GB groß. Auf vielen Einsteigerangeboten passt es nicht auf die Festplatte. Anschließend muss es außerdem noch in den Arbeitsspeicher eingelesen werden.

Prüfen Sie df -h vor jedem Download. Ein Root-Dateisystem, das während der Übertragung von 12 GB voll läuft, verhindert alle weiteren Schreibvorgänge, auch in das Journal.

Führen Sie den Dienst 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, 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 Inhalt:

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

Wenn der Server bereit ist, lautet der Inhalt {"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. Dieser Server hat nur ein Modell geladen. Der Wert wird daher nicht zur Auswahl verwendet.

Die OpenAI-kompatible API und weitere Endpunkte

POST /v1/chat/completions, POST /v1/completions und POST /v1/embeddings sind die OpenAI-kompatiblen Routen. GET /v1/models gibt das geladene Modell zurück. GET /health ist die oben beschriebene Bereitschaftsprüfung. GET /props gibt die aktuellen Servereinstellungen zurück. 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 einen nicht leeren API-Key übergeben. Dieser Schlüssel wird erst geprüft, wenn Sie --api-key selbst festlegen.

Übernehmen Sie keine Durchsatzangabe ungeprüft für Ihre eigene Planung. Die Inferenzgeschwindigkeit auf der CPU hängt von der Anzahl der Kerne, der Speicherbandbreite und den anderen Mandanten ab, mit denen Sie den Host gemeinsam nutzen. Messen Sie die Tokens pro Sekunde auf Ihrem eigenen System und betrachten Sie diesen Wert 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 Ratenbegrenzung und kein brauchbares Audit-Log. Die einzige integrierte Zugriffskontrolle ist --api-key. Sie vergleicht eine Zeichenfolge. Ein offener Inferenzport stellt jedem, der ihn findet, kostenlose Rechenleistung bereit. Derselbe Fehler bei Ollama hat dieselbe Ursache und Struktur: Absichern 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 aktivierter Pufferung hält nginx die Server-Sent Events (SSE) zurück, bis die Antwort abgeschlossen ist. Der Client wartet dann 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 Environment=, weil llama-server die LLAMA_ARG_*-Variablen für die meisten Flags liest. Ein Befehlszeilenargument überschreibt dabei die entsprechende Variable. Damit gibt es eine zentrale Stelle, an der Sie die Kontextgröße ändern können. 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 vorhanden. Wenn Sie rund um den Dienst geplante Aufgaben ausführen möchten, beispielsweise eine nächtliche Prüfung auf eine neue Version, ist ein systemd-Dienst mit Timer der passende Mechanismus dafür.

Vor einem OOM-Ereignis festlegen, was passieren soll

Der Speicherverbrauch 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 lesen. Der KV-Cache enthält den Zustand pro Token, den der Server für jede aktive Konversation speichert. Er liegt im anonymen Speicher. Er kann nicht verworfen werden und führt deshalb dazu, dass der Prozess beendet wird.

Daher haben die beiden Limits in der Unit unterschiedliche Aufgaben. MemoryHigh=3G ist ein Soft-Limit: Oberhalb dieses Werts setzt der Kernel die cgroup stärkerem Reclaim-Druck aus. Gemappte Modellseiten werden dann verdrängt und beim nächsten Token erneut von der Festplatte gelesen. Der Dienst läuft weiter, wird aber langsamer. MemoryMax=3500M ist ein Hard-Limit: Oberhalb dieses Werts wird der Prozess beendet, und das Journal meldet dies eindeutig.

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

Setzen Sie --ctx-size selbst. Der Standardwert ist 0. Das bedeutet, dass der vom Modell trainierte Kontext verwendet wird. Bei einem modernen Modell mit langem Kontext reserviert das beim Start einen sehr großen KV-Cache. Der Dienst beendet sich dann, bevor er eine einzige Anfrage verarbeitet. --parallel vervielfacht denselben Speicherbedarf, weil jeder Slot seinen eigenen Konversationszustand hält. Lassen Sie den Wert daher auf 1, bis Sie parallele Anfragen benötigen.

Mit Restart=on-failure wird ein beendeter Dienst automatisch neu gestartet. Wird er bei jedem Start beendet, gibt systemd irgendwann 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 schlimmer 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.

Beobachten Sie den tatsächlichen Wert mit systemctl show llama-server -p MemoryCurrent, 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 geringeren 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 Prozess mit selbst festgelegten Flags, einem fixierten 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 anhand ihres Namens herunterladen, mehrere Modelle auf dem Datenträger vorhalten, ein inaktives Modell entladen und mit einem einzigen Befehl aktualisieren, statt es neu zu bauen. Das sind konkrete Aufgaben, die Sie andernfalls selbst skripten müssten. Ollama auf einem VPS ausführen erledigt dieselbe Aufgabe, trifft diese Abwägung aber in die andere Richtung. Beide stellen eine mit OpenAI kompatible API bereit. Der Client-Code funktioniert daher unabhängig von der gewählten Richtung weiterhin.

Upgrade eines festgelegten Builds

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

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 müssen Sie daher nur einmal ln -sfn auf llama-server-b10488 ausführen und den Dienst neu starten. Lesen Sie vor dem Wechsel die Release Notes. GGUF-Dateien sind versioniert und ältere Dateien werden weiterhin geladen. Flags werden jedoch umbenannt: --mlock und --no-mmap sind bereits zugunsten von --load-mode veraltet. Eine Unit-Datei, die ein entferntes Flag übergibt, schlägt beim Start mit einer Meldung über ein nicht erkanntes Argument fehl.

Fehlerbilder und die angezeigten Meldungen

error while loading shared libraries: libllama.so nach dem Kopieren der Binärdatei an einen anderen Ort. Der Standard-Build erzeugt daneben gemeinsam genutzte Bibliotheken. Führen Sie den Build mit -DBUILD_SHARED_LIBS=OFF erneut aus 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 ausführenden Systems kompiliert. Führen Sie den Build auf diesem Rechner erneut aus 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 direkt auf dem VPS oder öffnen Sie mit ssh -L 8080:127.0.0.1:8080 user@your-vps einen Tunnel und verwenden Sie lokal http://127.0.0.1:8080.

HTTP 503 mit "message":"Loading model" in den ersten Sekunden oder Minuten nach einem Neustart. Das Einlesen einer mehrere Gigabyte großen Datei benötigt Zeit. systemd meldet die Unit bereits als aktiv, sobald der Prozess startet, also deutlich bevor das Modell im Arbeitsspeicher liegt.

Anfragen hängen und liefern anschließend 504 Gateway Time-out zurück. Der Proxy hat aufgegeben, 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 instabil und beendet sich anschließend mit start request repeated too quickly. Bei jedem Start beendet etwas den Prozess. Prüfen Sie journalctl -u llama-server auf die Meldung des OOM-Killers. Verringern Sie anschließend --ctx-size, verringern Sie --parallel oder erhöhen Sie MemoryMax.

FAQ

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

Führen Sie llama-server aus, wenn Sie einen exakt festgelegten Build verwenden, genaue Flags übergeben und ein Modell in einer einzelnen Datei behalten möchten, die nichts unbemerkt aktualisiert. Verwenden Sie Ollama, wenn Sie Modellverwaltung und Upgrades mit einem Befehl benötigen. Das Abrufen von Modellen anhand ihres Namens, das Speichern mehrerer Modelle auf dem Datenträger und das Entladen nicht verwendeter Modelle müssten Sie sonst selbst skripten. Beide stellen eine OpenAI-kompatible API bereit. Der Client-Code muss daher bei einem späteren Wechsel nicht geändert werden.

Welche Version von llama.cpp sollte ich festlegen?

Jeden Tag, den Sie tatsächlich erstellt und getestet haben. llama.cpp versieht nahezu jeden Merge mit einem Tag. Die Namen sind Build-Nummern wie b10488. Dieser Tag war am 18 August 2026 der neueste. Es gibt keinen separaten stabilen Branch. Daher ändert sich „aktuell“ mehrmals täglich. Klonen Sie mit --branch <tag>, installieren Sie die Binärdatei unter einem Dateinamen, der diesen Tag enthält, und zeigen Sie mit einem Symlink darauf. So sind Upgrade und Rollback jeweils mit einem Befehl möglich.

Wie viel RAM benötigt llama-server?

Gehen Sie zunächst 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 Konfiguration. 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 zurück?

Der Prozess wurde gestartet, aber die Modelldatei befindet sich noch nicht im Arbeitsspeicher. 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 benötigt. Es wird erst dann zum Problem, wenn ein Client oder ein Proxy diesen 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 Benutzerkonten und keine Ratenbegrenzung. Außerdem gibt es kein verwertbares Anforderungsprotokoll für Audits. Die einzige integrierte Prüfung ist --api-key. Sie vergleicht eine einzelne Zeichenfolge. Behalten Sie die standardmäßige 127.0.0.1-Bindung bei, schalten Sie nginx mit TLS davor und setzen Sie zusätzlich --api-key. Dadurch führt ein Fehler in der Proxy-Konfiguration nicht dazu, dass das Modell für alle erreichbar ist.