Ollama oder llama.cpp auf einem VPS: Was passt?

Ollama vs llama.cpp: Welche Ebene möchten Sie betreiben?

Ollama und llama.cpp sind nicht auf die Weise Konkurrenten, die die Frage nahelegt. llama.cpp ist die Inference Engine: Sie lädt eine Modelldatei und wandelt einen Prompt in Tokens um. Ollama ist ein Model Manager, ein Hintergrund-Daemon und eine HTTP API, die auf dieser Engine aufsetzt. In der README von Ollama wird llama.cpp weiterhin als Inference-Backend aufgeführt (geprüft am 27. Oktober 2026). Die eigentliche Frage lautet daher, welche Ebene Sie auf Ihrem VPS betreiben möchten, nicht welche schneller ist.

Verwenden Sie Ollama, wenn Sie einen Dienst benötigen, der Modelle anhand ihres Namens abruft und ohne laufende Betreuung weiterarbeitet. Verwenden Sie llama.cpp direkt, wenn der Server klein ist und Sie die genaue Modelldatei, die genaue Context-Größe und die genaue Thread-Anzahl festlegen müssen, weil jede dieser Einstellungen auf einem kleinen VPS Speicher benötigt, der nicht verfügbar ist.

Was die einzelnen Projekte tatsächlich sind

llama.cpp ist eine in C und C++ implementierte Transformer-Inferenz auf Basis der ggml-Bibliothek. Das Projekt liest GGUF-Dateien. GGUF (GGML universal file format) ist ein Container in einer einzigen Datei. Er enthält die Gewichte, den Tokenizer und die Metadaten, die die Engine zum Ausführen des Modells benötigt. Das Projekt stellt separate Binaries für unterschiedliche Aufgaben bereit. llama-server ist ein HTTP-Server, llama-cli eine interaktive Eingabeaufforderung und llama-bench misst den Durchsatz. Das Projekt veröffentlicht inzwischen Releases nach dem Schema der semantischen Versionierung (MAJOR.MINOR.PATCH). v0.7.0, veröffentlicht am 15 October 2026, war am 27 October 2026 das neueste Release. Daneben erscheinen weiterhin mehrmals täglich Nightly-Tags mit Build-Nummern. Das neueste Tag am 27 October 2026 war b11913.

Ollama ist ein Go-Programm. Ein Hintergrund-Daemon, der mit ollama serve gestartet wird, lädt Modelle und beantwortet HTTP-Anfragen. Ein Command-Line-Client kommuniziert mit diesem Daemon. Dahinter steht eine Registry unter ollama.com, die vorgepackte Modelle enthält. Ollama verwendet semantische Versionen. v0.32.5 wurde am 27 July 2026 veröffentlicht, und v0.40.12 wurde am 27 October 2026 um 00:07 UTC veröffentlicht. ollama pull ruft eine GGUF-Datei zusammen mit einem Prompt-Template und einer Reihe von Standardparametern ab und speichert sie unter /usr/share/ollama/.ollama/models unter Linux. Diese Dateien liegen auf dem Root-Datenträger und sind jeweils mehrere Gigabyte groß. Auf einem VPS mit einem Root-Volume von 25 GB sollten Sie daher wissen, was pull hinterlässt und wie Sie das Modellverzeichnis an einen anderen Ort verschieben, bevor der dritte Download den Speicher füllt.

Das Paketierungskonzept ist der gesamte Unterschied. Ollama legt Quantisierung, Template und Kontextlänge für Sie fest und bietet Ihnen einen einzigen Namen, den Sie sich merken müssen. llama.cpp stellt diese Optionen als Flags bereit und verwendet automatisch Standardwerte für Einstellungen, die Sie nicht festlegen.

Achse 1: Modell- und Quantisierungssteuerung

Bei der Quantisierung werden die Gewichte mit weniger Bits gespeichert als mit den 16 oder 32 Bits des ursprünglichen Modells. Die gängigen GGUF-Builds verwenden im Durchschnitt etwa 4, 5 oder 8 Bits pro Gewicht. Die Präzision ist innerhalb der Datei nicht einheitlich. Im Quantisierer-Quellcode von llama.cpp (Stand 27. Oktober 2026) speichert ein Q4_K_M-Build die meisten Tensoren mit 4 Bit. Die Ausgabeschicht sowie die Attention-Value- und Feed-Forward-Down-Tensoren in etwa der Hälfte der Schichten werden stattdessen mit 6 Bit als Q6_K gespeichert. Kleine Tensoren wie die Normen werden überhaupt nicht quantisiert. Dadurch passt ein Modell mit 8 Milliarden Parametern in den RAM eines gewöhnlichen VPS. Die Benennung von GGUF ist verständlich, sobald Sie das Muster kennen: Q4_K_M bedeutet 4-Bit-K-Quantisierung in mittlerer Größe. Eine höhere Zahl bewahrt mehr Präzision und benötigt mehr Speicher.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Das sind die veröffentlichten Dateigrößen im bartowski/Meta-Llama-3.1-8B-Instruct-GGUF-Repository auf Hugging Face, abgerufen am 2. August 2026 und von Bytes in GiB umgerechnet. 6 Builds eines Modells stehen zur Auswahl. Der kleinste ist 2.96 GiB groß, der größte 7.95 GiB. Der übliche Standard Q4_K_M ist 4.58 GiB groß. Auf einem VPS mit 4 GiB entscheidet diese eine Auswahl, ob das Modell überhaupt geladen werden kann. Die Größe ist jedoch nur die eine Hälfte der Entscheidung. Eine Zeile, die Sie sich leisten können, ist nicht automatisch eine sinnvolle Wahl. Was Q4, Q8 und fp16 tatsächlich an Antwortqualität kosten, zeigt, ob die zusätzlichen Gigabytes einen für Sie erkennbaren Vorteil bringen.

Mit llama.cpp geben Sie den Dateinamen an und wählen diese Zeile selbst aus.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c ist die Kontextgröße in Tokens, -t ist die Anzahl der Threads, und -ngl legt fest, wie viele Schichten auf eine GPU verschoben werden (0 auf einem reinen CPU-System). Nicht gesetzte Einstellungen verwenden Standardwerte. --fit ist standardmäßig aktiviert und passt nicht gesetzte Argumente an den verfügbaren Gerätespeicher an.

Bei Ollama ist die Quantisierung an den Tag gekoppelt, den Sie abrufen. ollama ls zeigt, was tatsächlich auf der Festplatte vorhanden ist. Wenn die Registry den gewünschten Build nicht enthält, importieren Sie selbst eine GGUF-Datei. Schreiben Sie eine Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Bauen Sie sie anschließend und prüfen Sie das Ergebnis:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Die Kontextlänge verursacht häufig Probleme. Ollama wählt den Standardwert anhand des verfügbaren VRAM. Ein System ohne GPU fällt in die kleinste Kategorie: 4096 Tokens. Wenn Sie ein Dokument mit 20.000 Tokens übergeben, werden die zusätzlichen Tokens verworfen, bevor das Modell sie überhaupt sieht. Die Antwort kann dann selbstsicher falsch sein, weil das Modell die Datei nur teilweise gelesen hat. Erhöhen Sie den Wert mit OLLAMA_CONTEXT_LENGTH auf dem Daemon oder mit PARAMETER num_ctx in einer Modelfile. Wenn nur ein Auftrag ein größeres Kontextfenster benötigt, kann num_ctx pro Anfrage statt serverweit gesetzt werden. Dadurch bleibt der zusätzliche Cache für alle anderen Aufträge ungenutzt, die der Daemon ausführen soll. Auch bei llama.cpp gibt es keinen Standardwert, dem Sie vertrauen sollten. Setzen Sie -c ausdrücklich und prüfen Sie, welcher Wert gesetzt ist.

Die Speicherberechnung, die Ihnen niemand zeigt

Die Modelldatei ist nicht der gesamte Speicherbedarf. Der KV-Cache (Key/Value-Cache) enthält pro Layer und Kontext-Token einen Eintrag. Er wächst mit der Länge der Unterhaltung.

Rechnen wir das für Llama 3.1 8B durch. Das Modell hat 32 Layer, 8 Key/Value-Heads und eine Head-Dimension von 128. Jeder Token speichert sowohl einen Key als auch einen Value mit jeweils 2 Byte in f16. Das ergibt 2 x 8 x 128 x 2 = 4096 Byte pro Layer. Über 32 Layer entspricht das 128 KiB pro Token. Ein Kontext mit 4096 Token benötigt daher 512 MiB. Ein Kontext mit 32,768 Token benötigt 4 GiB.

Ein Q4_K_M-8B-Modell benötigt bei einem Kontext von 4k also ungefähr 4.58 GiB für die Gewichte, zusätzlich etwa 0.5 GiB für den Cache und weiteren Speicher für die Laufzeitumgebung. Es passt nicht in 4 GiB RAM. In 8 GiB passt es mit ausreichend Arbeitsraum. Erhöhen Sie den Kontext auf demselben System mit 8 GiB auf 32k, belegt allein der Cache den verfügbaren Spielraum. Überwachen Sie den Speicherverbrauch mit free -h, während das Modell geladen ist. Verlassen Sie sich nicht auf eine Schätzung, die Sie nicht gemessen haben. Wenn Sie ein Modell deutlich oberhalb von 8B dimensionieren, zeigt dieselbe durchgerechnete Speicherberechnung für ein 27B-Modell auf einem CPU-only-VPS, was die einzelnen Größenklassen von 8 bis 64 GB tatsächlich aufnehmen.

Ollama verstärkt diesen Effekt. OLLAMA_NUM_PARALLEL ist standardmäßig auf 1 gesetzt. Der Speicherbedarf eines Modells skaliert mit diesem Wert und der Kontextlänge. Wenn Sie beide Werte gleichzeitig erhöhen, fordert der Daemon unbemerkt ein Mehrfaches des erwarteten RAM an. Dieselbe Berechnung begrenzt auch die Anzahl gleichzeitiger Benutzer. Jede parallele Anfrage benötigt einen eigenen Anteil des KV-Cache. Das erklärt, warum ein Server, der für eine Person problemlos läuft, bei fünf Personen ins Stocken gerät.

Achse 2: der Daemon, den Sie betreiben müssen

Das Ollama-Installationsskript schreibt eine systemd-Unit, erstellt einen ollama-Systembenutzer und aktiviert den Dienst. Damit erhalten Sie eine vollständige Verwaltung des Dienstlebenszyklus, ohne selbst etwas davon schreiben zu müssen. Die Konfiguration erfolgt über systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE ist auf einem CPU-VPS wichtiger als in jeder anderen Umgebung. Modelle bleiben standardmäßig 5 Minuten im Speicher und werden danach entladen. Die nächste Anfrage muss die gesamte Datei erneut laden, bevor sie beantwortet werden kann. Wenn der Kernel die Datei noch im Page Cache hält, geht das schnell. Dafür muss jedoch ausreichend RAM verfügbar sein. Sobald andere Prozesse die Datei aus dem Cache verdrängt haben, wird sie erneut von der Festplatte gelesen. Dadurch kann das erneute Laden von 4.58 GiB auf langsamem Speicher aus einer Antwortzeit von zwei Sekunden eine von dreißig Sekunden machen. Ein langes Keep-Alive behebt die Latenz, belegt den RAM jedoch dauerhaft. Beides verursacht reale Kosten. Wählen Sie die Variante, die Sie weniger beeinträchtigt. Wenn das Modell dauerhaft im Speicher bleiben soll, reichen einige Zeilen für keep_alive, damit es Leerlaufzeiten und Reboots übersteht. Dadurch müssen Sie das Modell nach jedem Neustart des Systems nicht mehr manuell vorwärmen.

llama.cpp stellt weder einen Daemon noch einen Dienstbenutzer bereit. Sie müssen beides selbst einrichten. Wechseln Sie in das Verzeichnis llama.cpp, in dem Sie den Build erstellt haben, installieren Sie die Binary und ihre Bibliotheken nach /usr/local, erstellen Sie einen llama-Benutzer und geben Sie ihm eine Kopie des Modells:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Wenn Sie statt des Builds das Release-Archiv verwendet haben, setzen Sie ExecStart auf das darin enthaltene llama-server. Das Archiv legt seine Bibliotheken neben der Binary ab. Schreiben Sie die Unit anschließend als /etc/systemd/system/llama-server.service:

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

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Aktivieren Sie sie mit sudo systemctl enable --now llama-server. Der Prozess hält das Modell dann während seiner gesamten Laufzeit im Speicher. Im Leerlauf wird es standardmäßig nicht entladen. Mit --sleep-idle-seconds können Sie jedoch das automatische Entladen und erneute Laden aktivieren, ohne den Dienst zu stoppen. Wenn das Schreiben von Units für Sie neu ist, entspricht dies dem Muster aus dem Betrieb eigener Dienste unter systemd auf einem VPS.

Achse 3: die API, mit der Ihre Anwendung kommuniziert

Diese Achse hat sich stark verengt. Beide Projekte verwenden jetzt das OpenAI-Chatformat. Daher funktionieren die meisten Client-Bibliotheken mit beiden Projekten, sobald nur die Basis-URL geändert wird.

Ollama lauscht auf 127.0.0.1:11434. Seine OpenAI-kompatible Route ist http://localhost:11434/v1/chat/completions; zusätzlich stellt es unter /api/chat eine native API bereit. Eine Anthropic-kompatible Route ist ebenfalls dokumentiert. Keine dieser Routen ermöglicht es dem Modell, selbstständig Informationen nachzuschlagen. Wenn Ihre Anwendung Antworten benötigt, die aktueller sind als die Trainingsdaten des Modells, sollten Sie daher die Websuche über Ollama's API, Open WebUI oder eine kurze Tool-Schleife einbinden.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

Mit den obigen Flags gestartet, lauscht llama-server auf 127.0.0.1:8080. Ohne weitere Angaben verwendet es jetzt standardmäßig Port 9931 (geprüft am 27. Oktober 2026). Lassen Sie --port daher in der Befehlszeile stehen, wenn Ihre Anwendung 8080 erwartet. Der Dienst stellt /v1/chat/completions, /v1/completions und /v1/embeddings bereit. Hinzu kommen der eigene Endpunkt /completion und eine integrierte Weboberfläche. Außerdem bietet er Betriebsendpunkte, die Ollama nicht bereitstellt: /health für eine Readiness-Prüfung, /props für die Einstellungen des geladenen Modells, /slots für den Status jedes Request-Slots und /metrics im Prometheus-Format, sobald Sie --metrics hinzufügen, da dieser Endpunkt standardmäßig deaktiviert ist. Wenn Sie diesen Dienst überwachen möchten, ist dieser Unterschied wahrscheinlich ausschlaggebend.

Keiner der beiden Server aktiviert für Sie die Authentifizierung. Beide verwenden aus gutem Grund standardmäßig die Loopback-Adresse. Greifen Sie über einen SSH-Tunnel oder hinter einem Reverse Proxy auf sie zu. Öffnen Sie Port 11434 oder 8080 niemals für das Internet.

Was ein VPS ohne GPU realistisch leisten kann

Ein VPS ohne GPU führt kleine Modelle langsam aus. Das ist die ehrliche Zusammenfassung. Entscheidend ist, die praktische Grenze zu kennen. Messen Sie, bevor Sie Ihre Architektur darauf ausrichten:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

Die Spalte pp zeigt die Geschwindigkeit der Prompt-Verarbeitung. Die Spalte tg zeigt die Geschwindigkeit der Tokenerzeugung. Beide Werte werden in Tokens pro Sekunde angegeben. Bei einem Plan mit gemeinsam genutzten vCPUs erreicht ein 8B-Modell mit Q4_K_M für tg normalerweise niedrige einstellige Werte. Die Prompt-Verarbeitung ist der kritische Teil: Der gesamte Prompt wird verarbeitet, bevor das erste Ausgabetoken erscheint. Ein langer System-Prompt verursacht daher bei jeder einzelnen Anfrage zusätzliche Wartezeit. Die Antwortlänge ist der Teil der Laufzeit, den Sie tatsächlich kontrollieren können. Bei drei Tokens pro Sekunde belegt ein Modell, das 600 Tokens ausgibt, den Server 200 Sekunden lang. Allein die Generierung dauert damit mehr als drei Minuten. Die Ausgabe mit num_predict zu begrenzen ist daher die kostengünstigste Möglichkeit, zu verhindern, dass eine zu ausführliche Antwort einen Timeout verursacht.

Auf der CPU sinnvoll einsetzbar ist ein 1B- bis 4B-Modell für Klassifikation, Extraktion, kurze Zusammenfassungen oder Routing. Antworten treffen innerhalb weniger Sekunden ein, und der Speicherbedarf passt zu einem normalen Plan. Ein konkretes Beispiel für diese Modellgröße statt einer Größenangabe liefert Nemotron 3.5 Lightning auf einem VPS herunterladen und messen mit dem exakten Tag, dem tatsächlich benötigten RAM und der Geschwindigkeit ohne GPU. Nicht sinnvoll auf der CPU einsetzbar sind interaktive Chats mit Lesegeschwindigkeit, Coding-Assistenten, die Verarbeitung langer Dokumente und alles mit einer Agentenschleife, die viele Aufrufe nacheinander ausführt. Eine Schleife mit zwölf Aufrufen zu jeweils vier Sekunden benötigt eine Minute, bevor sie überhaupt ein Ergebnis erzeugt. Wenn ohnehin ein Coding-Assistent geplant ist, zeigt einen Agenten auf ein selbst gehostetes Modell richten, bei welchen Aufgaben ein kleines lokales Modell tatsächlich Vorteile bietet und welche Aufgaben bei einer gehosteten API bleiben müssen.

Wenn die Werte nicht ausreichen, gibt es zwei Auswege. Liegt das Problem bei der Nebenläufigkeit, also bei vielen Benutzern, die gleichzeitig auf ein Modell zugreifen, ändert sich die Wahl der Engine. Der Vergleich von Ollama und vLLM für die gleichzeitige Bereitstellung behandelt dieses Thema. Liegt das Problem bei der reinen Geschwindigkeit, lautet die Antwort ein VPS mit angeschlossener GPU. Dort beginnt -ngl eine praktische Bedeutung zu bekommen. Ermitteln Sie zuvor eine Basislinie für die Hardware selbst. Bandbreite von Datenträger und Arbeitsspeicher beeinflusst die Ladezeit ebenso wie die CPU. Ein reproduzierbarer VPS-Benchmark ist den dafür benötigten Zeitaufwand wert.

llama.cpp installieren und auf einen Build festlegen

Beide Projekte werden wöchentlich aktualisiert. Halten Sie daher die eingesetzte Version fest. Der Upstream-Einzeiler installiert den aktuellen Build:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Um einen bestimmten Build festzulegen, verwenden Sie stattdessen das vorgefertigte Tarball von der Releases-Seite. Das Projekt veröffentlicht inzwischen auch Releases mit semantischer Versionsnummer: v0.7.0 war am 27 October 2026 die neueste Version, und die zugehörige Release-Seite verweist für die Binärdateien auf Nightly b11669. v0.8.0 folgte am 28 October 2026. Die zugehörige Release-Seite verweist für die Binärdateien auf Nightly b11960. Die folgenden Befehle verwenden b10224, den aktuellen Tag vom 2 August 2026. Ersetzen Sie ihn durch den Tag, den Sie getestet haben:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Alternativ können Sie denselben Tag aus dem Quellcode bauen:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev ist die dokumentierte Abhängigkeit für die HTTPS-Funktionen. Die Kompilierung dauert mehrere Minuten und benötigt mehr RAM, als die kleinsten Pläne bereitstellen. Bauen Sie daher auf einer größeren Maschine und kopieren Sie die Binärdateien, falls die kleine Maschine nicht genügend Ressourcen hat.

Ollama installieren und auf eine Version festlegen

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Das Skript liest OLLAMA_VERSION aus. Dadurch können Sie eine bekannte, funktionierende Version beibehalten, anstatt automatisch die heute veröffentlichte Version zu installieren. v0.32.5 wurde am 27. Juli 2026 veröffentlicht. Es gibt auch einen manuellen Weg, wenn Sie kein Skript an eine Shell weiterleiten möchten:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Beim manuellen Vorgehen werden weder die systemd-Unit noch der Service-Benutzer angelegt. Sie müssen beides selbst einrichten. Die vollständige Anleitung für Ollama auf einem VPS beschreibt diese Einrichtung Schritt für Schritt.

Fehlerbilder und die angezeigten Ausgaben

Ollama lädt das Modell nicht. Ältere Ollama-Releases prüften die Größe vor dem Laden, und ollama run gab eine Zeile dieser Form aus:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Der aktuelle Ollama-Quellcode enthält diese Meldung nicht mehr (geprüft am 27. Oktober 2026). Ollama übergibt das Laden jetzt an llama-server. Ein Modell, das nicht hineinpasst, erscheint daher stattdessen als Runner-Fehler. Die Fehler beginnen beispielsweise so:

llama-server reported out-of-memory during startup
llama-server process has terminated

In beiden Fällen ist die Behebung gleich. Wechseln Sie eine Quantisierungszeile nach unten, verringern Sie die Kontextlänge oder wählen Sie ein kleineres Modell.

llama.cpp schlägt nicht fehl, sondern wird extrem langsam. llama.cpp bildet die GGUF-Datei standardmäßig per Memory-Mapping ab, sodass auch eine Datei gestartet wird, die größer als der RAM ist. Der Kernel blättert die Gewichte dann bei jedem Token von der Festplatte in den Speicher und aus dem Speicher heraus. Dadurch sinkt die Generationsgeschwindigkeit auf Sekunden pro Token, während die Festplatte dauerhaft zu 100 Prozent ausgelastet ist. Übergeben Sie --load-mode none, um das Memory-Mapping zu deaktivieren. Diese Option hat --no-mmap ersetzt. --no-mmap ist im festgelegten Build b10224 als veraltet dokumentiert und erscheint in aktuellen Builds nicht mehr (geprüft am 29. Oktober 2026). Wenn der Kernel eingreift, zeigt dmesg den Grund:

Out of memory: Killed process 1234 (llama-server)

Die Modelldatei lässt sich überhaupt nicht laden. Eine GGUF-Datei für eine neuere Modellfamilie als die Ihres Engines erzeugt einen Fehler, der die unbekannte Architektur nennt. <arch> ist der in den Metadaten der Datei gespeicherte Name:

llama_model_load: error loading model: unknown model architecture: '<arch>'

Die Lösung ist ein Upgrade des Engines, nicht eine andere Datei. Das ist der Preis für das Festlegen einer Version. Deshalb notieren Sie die Build-Nummer. Sie müssen wissen, von welcher Version Sie aktualisieren.

Die API antwortet lokal, aber nicht aus Ihrer Anwendung. Ollama bindet 127.0.0.1:11434. Ein anderer Host erhält daher eine abgelehnte Verbindung. Setzen Sie OLLAMA_HOST=0.0.0.0:11434 über systemctl edit ollama nur dann, wenn der Port hinter einer Firewall oder in einem privaten Netzwerk liegt, da die API keine vorgeschaltete Authentifizierung hat.

Die erste Antwort nach einer Pause ist sehr langsam. Das Entladen nach 5 Minuten Inaktivität ist erfolgt, und das Modell wird erneut geladen. Das geschieht von der Festplatte, wenn der Page-Cache es nicht vorgehalten hat. ollama ps direkt vor der Anfrage ausgeführt zeigt, dass kein Modell geladen ist, und bestätigt dies. Erhöhen Sie OLLAMA_KEEP_ALIVE.

Welches sollten Sie also verwenden?

Verwenden Sie Ollama, wenn die Modelle für Sie verwaltet werden sollen und Sie ohne zusätzlichen Aufwand einen OpenAI-kompatiblen Endpunkt benötigen. Für die erste Bereitstellung ist dies die richtige Standardwahl. Das gilt auch, wenn sich die Modellauswahl häufig ändern wird.

Verwenden Sie llama.cpp direkt, wenn der Arbeitsspeicher so knapp ist, dass Sie die passende Quantisierungszeile selbst auswählen müssen, wenn Sie /health, /slots und /metrics für die Überwachung benötigen oder wenn Sie ein Flag brauchen, das Ollama nicht bereitstellt. Auf einem VPS, auf dem das Modell gerade noch in den Arbeitsspeicher passt, ist dies die naheliegende Wahl. Denn genau die Einstellungen, durch die das Modell passt, wählt Ollama für Sie aus.

Beide Varianten parallel zu verwenden, ist normal. Verwenden Sie Ollama für Experimente und llama.cpp für das eine Modell, das Sie produktiv einsetzen und dessen Version sich niemals unbeabsichtigt ändern soll.

FAQ

Ist Ollama nur ein Wrapper um llama.cpp?

Nicht ganz, denn der Wrapper übernimmt wichtige Aufgaben. In der README von Ollama ist llama.cpp als Inferenz-Backend aufgeführt (geprüft am 27. Oktober 2026). Darauf aufbauend ergänzt Ollama eine Modellregistrierung, das Prompt-Template, das Chatnachrichten in einen Prompt umwandelt, eine Reihe von Standardparametern für das Sampling, einen Daemon mit Entladen bei Inaktivität und eine HTTP-API. Wenn Sie die Tokens pro Sekunde bei identischen Einstellungen vergleichen, vergleichen Sie dieselbe Engine mit sich selbst. Tatsächlich wählen Sie zwischen den Verwaltungsebenen.

Was ist auf einer VPS nur mit CPU schneller?

Beide verwenden dieselbe Engine. Bei identischer Modelldatei, Quantisierung, Kontextgröße und Thread-Anzahl liegen die Ergebnisse daher nahe beieinander. Unterschiede, die häufig berichtet werden, entstehen in der Regel durch unterschiedliche Standardeinstellungen, meistens durch Kontextlänge und Thread-Anzahl, nicht durch die Engine. Messen Sie mit llama-bench -m <file> -p 512 -n 128 und vergleichen Sie die Spalte tg auf Ihrem eigenen Server, bevor Sie veröffentlichten Werten vertrauen.

Kann ich meine eigene GGUF-Datei mit Ollama verwenden?

Ja. Legen Sie die Datei auf dem Server ab und schreiben Sie eine Modelfile, deren erste Zeile FROM ./your-model.gguf lautet. Fügen Sie anschließend alle benötigten PARAMETER-Zeilen hinzu, beispielsweise num_ctx, und führen Sie dann ollama create your-name -f ./Modelfile aus. ollama ls führt die Datei neben allen Modellen auf, die Sie aus der Registrierung abgerufen haben. So verwenden Sie eine Quantisierung, die in der Registrierung nicht angeboten wird.

Wie viel RAM benötige ich für ein 8B-Modell?

Planen Sie die Dateigröße, den KV-Cache und die Laufzeitumgebung ein. Eine Q4_K_M-Version von Llama 3.1 8B belegt auf dem Datenträger etwa 4.58 GiB. Ein Kontext mit 4096 Tokens benötigt zusätzlich ungefähr 512 MiB Cache. Daher sind 8 GiB RAM ausreichend, 4 GiB reichen nicht aus. Der Cache wächst mit der Kontextgröße. Dasselbe Modell benötigt bei einem Kontext von 32,768 Tokens allein etwa 4 GiB Cache. Bei Ollama müssen Sie außerdem beachten, dass der Bedarf mit OLLAMA_NUM_PARALLEL skaliert.