Ollama oder llama.cpp auf einem CPU-VPS?

Ollama vs llama.cpp: Auf welcher Ebene möchten Sie arbeiten?

Ollama und llama.cpp sind keine Konkurrenten, wie die Frage nahelegt. llama.cpp ist die Inference-Engine: Sie lädt eine Modelldatei und wandelt einen Prompt in Tokens um. Ollama ist ein Modellmanager, 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 2. August 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 funktioniert. Führen Sie llama.cpp direkt aus, wenn der Server klein ist und Sie die genaue Modelldatei, die genaue Kontextgröße und die genaue Thread-Anzahl festlegen müssen, denn auf einem kleinen VPS benötigt jede dieser Einstellungen Speicher, der Ihnen nicht zur Verfügung steht.

Was die einzelnen Projekte tatsächlich sind

llama.cpp ist eine in C und C++ entwickelte Implementierung für die Inferenz von Transformermodellen auf Basis der Bibliothek ggml. Das Programm liest GGUF-Dateien. GGUF (GGML universal file format) ist ein Container in einer einzelnen Datei. Er enthält die Gewichte, den Tokenizer und die Metadaten, die die Engine zum Ausführen des Modells benötigt. Das Projekt stellt für unterschiedliche Aufgaben separate Binärdateien bereit. llama-server ist ein HTTP-Server, llama-cli eine interaktive Eingabeaufforderung und llama-bench misst den Durchsatz. Releases werden anhand einer Build-Nummer statt anhand einer semantischen Version gekennzeichnet. Das aktuelle Tag ist b10224. Es wurde am 2. August 2026 veröffentlicht. An den meisten Werktagen kommt ein neues Tag hinzu.

Ollama ist ein Go-Programm. Ein Hintergrund-Daemon, der mit ollama serve gestartet wird, lädt Modelle und beantwortet HTTP-Anfragen. Ein Kommandozeilenclient kommuniziert mit diesem Daemon. Im Hintergrund beider Komponenten steht eine Registry unter ollama.com, die vorgepackte Modelle enthält. Ollama verwendet semantische Versionen. v0.32.5 wurde am 27. Juli 2026 veröffentlicht. ollama pull lädt eine GGUF-Datei zusammen mit einer Prompt-Vorlage und einem Satz von Standardparametern herunter. Unter Linux speichert es diese unter /usr/share/ollama/.ollama/models.

Diese Paketierung ist der gesamte Unterschied. Ollama legt Quantisierung, Vorlage und Kontextlänge für Sie fest und gibt Ihnen einen einzigen Namen, den Sie sich merken müssen. llama.cpp legt nichts fest und gibt Ihnen Flags.

Achse 1: Modell- und Quantisierungssteuerung

Bei der Quantisierung wird das Gewicht jedes Parameters von 16 oder 32 Bit auf 4, 5 oder 8 Bit reduziert. Dadurch passt ein Modell mit 8 Milliarden Parametern in den Arbeitsspeicher eines gewöhnlichen VPS. Die GGUF-Namensgebung ist verständlich, sobald Sie das Muster kennen: Q4_K_M bedeutet 4-Bit-K-Quantisierung mit mittlerer Größe. Eine höhere Zahl erhält mehr Präzision und benötigt mehr Arbeitsspeicher.

[
  {
    "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. Die Werte wurden am 2. August 2026 abgelesen und von Bytes in GiB umgerechnet. Es gibt 6 Builds eines Modells. Der kleinste ist 2.96 GiB groß, der größte 7.95 GiB. Die übliche Standardauswahl Q4_K_M ist 4.58 GiB groß. Auf einem VPS mit 4 GiB entscheidet diese einzelne Auswahl darüber, ob das Modell überhaupt geladen werden kann.

Mit llama.cpp geben Sie den Dateinamen an. Sie wählen also selbst die entsprechende Zeile 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 Layer auf eine GPU verschoben werden (0 auf einem System ohne GPU). Es wird nichts automatisch für Sie ausgewählt.

Bei Ollama ist die Quantisierung mit dem abgerufenen Tag verknüpft. 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

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

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

Die Kontextlänge ist die Einstellung, die häufig übersehen wird. Ollama wählt den Standardwert anhand des verfügbaren VRAM. Ein System ohne GPU fällt dabei in die kleinste Kategorie: 4096 Tokens. Senden Sie ein Dokument mit 20.000 Tokens, werden die zusätzlichen Tokens entfernt, bevor das Modell sie überhaupt sieht. Die Antwort ist dann möglicherweise selbstsicher, aber in Bezug auf eine Datei falsch, die das Modell nur zur Hälfte gelesen hat. Erhöhen Sie die Kontextlänge mit OLLAMA_CONTEXT_LENGTH beim Daemon oder mit PARAMETER num_ctx in einer Modelfile. Auch bei llama.cpp gibt es keinen Standardwert, dem Sie vertrauen sollten. Setzen Sie -c ausdrücklich und prüfen Sie, welchen Wert Sie festgelegt haben.

Die Speicherberechnung, die Ihnen niemand zeigt

Die Modelldatei ist nicht der gesamte Speicherbedarf. Der KV-Cache (Key-Value-Cache) enthält für jedes Token des Kontexts einen Eintrag pro Layer. Er wächst mit zunehmender Gesprächslänge.

Rechnen wir das für Llama 3.1 8B durch. Das Modell hat 32 Layer, 8 Key-/Value-Heads und eine Headdimension von 128. Jedes 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 sind 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 Spielraum für den laufenden Betrieb. Erhöhen Sie den Kontext auf demselben System mit 8 GiB auf 32k, belegt der Cache allein den gesamten verfügbaren Spielraum. Überwachen Sie den Speicherbedarf während des Ladens des Modells mit free -h. Vertrauen Sie keiner Schätzung, die Sie nicht selbst gemessen haben.

Ollama verstärkt diesen Effekt. OLLAMA_NUM_PARALLEL ist standardmäßig auf 1 gesetzt. Der Speicherbedarf eines Modells skaliert mit diesem Wert multipliziert mit der Kontextlänge. Erhöhen Sie beide Werte gleichzeitig, fordert der Daemon unbemerkt ein Mehrfaches des erwarteten RAM an.

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 diese selbst implementieren 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 einer CPU-VPS wichtiger als in den meisten anderen Umgebungen. Modelle bleiben standardmäßig 5 Minuten im Speicher und werden danach entladen. Die nächste Anfrage muss die gesamte Datei erneut von der Festplatte lesen, bevor sie beantwortet werden kann. Dadurch verlängert ein erneutes Laden von 4.58 GiB auf langsamem Speicher eine Antwortzeit von zwei auf dreißig Sekunden. Ein langer Keep-Alive-Wert verhindert diese Latenz, belegt den Arbeitsspeicher aber dauerhaft. Beides verursacht reale Kosten. Wählen Sie die Variante mit den geringeren Auswirkungen.

llama.cpp stellt keinen Daemon bereit. Daher schreiben Sie die Unit selbst 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. Bei Inaktivität wird nichts entladen. Dadurch gibt es keine unerwartete Verzögerung durch erneutes Laden, aber auch keine Möglichkeit, den Speicher freizugeben, ohne den Dienst zu stoppen. Wenn das Schreiben von Units für Sie neu ist, entspricht das demselben Muster wie das Betreiben eigener Dienste unter systemd auf einer VPS.

Achse 3: Die API, mit der Ihre Anwendung kommuniziert

Diese Achse ist deutlich kleiner geworden. Beide Projekte unterstützen inzwischen das OpenAI-Chatformat. Daher funktionieren die meisten Clientbibliotheken mit beiden Projekten, nachdem Sie lediglich die Basis-URL geändert haben.

Ollama lauscht auf 127.0.0.1:11434. Seine OpenAI-kompatible Route ist http://localhost:11434/v1/chat/completions. Zusätzlich stellt Ollama unter /api/chat eine native API bereit. Eine Anthropic-kompatible Route ist ebenfalls dokumentiert.

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"}]}'

llama-server lauscht auf 127.0.0.1:8080 und stellt /v1/chat/completions, /v1/completions und /v1/embeddings bereit. Zusätzlich gibt es den eigenen Endpunkt /completion und eine integrierte Weboberfläche. Außerdem bietet llama-server Betriebsrouten, die Ollama nicht besitzt: /health für eine Readiness-Prüfung, /props für die Einstellungen des geladenen Modells, /slots für den aktuellen Status jedes Anfrage-Slots und /metrics im Prometheus-Format. Wenn Sie diesen Dienst überwachen möchten, ist dieser Unterschied wahrscheinlich ausschlaggebend.

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

Was ein VPS ohne GPU tatsächlich 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 etwas darauf aufbauen:

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

Die Spalte pp gibt die Geschwindigkeit der Prompt-Verarbeitung an. Die Spalte tg gibt die Geschwindigkeit der Token-Generierung an. Beide Werte werden in Tokens pro Sekunde angegeben. Auf einem Tarif mit gemeinsam genutzter vCPU 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 Ausgabe-Token erscheint. Ein langer System-Prompt verursacht deshalb bei jeder einzelnen Anfrage eine zusätzliche Wartezeit.

Auf der CPU sinnvoll einsetzbar sind Modelle mit 1B bis 4B für Klassifizierung, Extraktion, kurze Zusammenfassungen oder Routing. Antworten erscheinen innerhalb weniger Sekunden. Der Speicherbedarf passt zu einem normalen Tarif. Nicht sinnvoll auf der CPU sind interaktiver Chat mit Lesegeschwindigkeit, Coding-Assistenten, die Verarbeitung langer Dokumente oder Agentenabläufe mit vielen aufeinanderfolgenden Aufrufen. Ein Ablauf mit zwölf Aufrufen und jeweils vier Sekunden benötigt eine Minute, bevor er überhaupt ein Ergebnis liefert.

Wenn die Werte nicht ausreichen, gibt es zwei Auswege. Liegt das Problem in der Parallelität, also darin, dass viele Benutzer gleichzeitig auf ein Modell zugreifen, ändert sich die Wahl der Engine. Der Vergleich von Ollama und vLLM für parallele Bereitstellung behandelt dieses Thema. Liegt das Problem in der reinen Geschwindigkeit, lautet die Antwort ein VPS mit angeschlossener GPU, bei dem -ngl eine praktische Bedeutung bekommt. Ermitteln Sie zuvor einen Referenzwert für die Hardware selbst. Die Bandbreite von Datenträger und Arbeitsspeicher beeinflusst die Ladezeit ebenso wie die CPU. Ein reproduzierbarer VPS-Benchmark ist den Zeitaufwand von einer Stunde wert.

llama.cpp installieren und auf einen Build festlegen

Beide Projekte ändern sich wöchentlich. Notieren Sie daher die eingesetzte Version. Die Upstream-Kurzinstallation 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, laden Sie stattdessen das vorkompilierte Tarball von der Releases-Seite herunter. Build b10224 ist der aktuelle Tag vom 2. August 2026:

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 Tarife bereitstellen. Bauen Sie daher auf einem größeren System und kopieren Sie die Binärdateien, falls der kleine Server 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. Dadurch können Sie eine bekannte, funktionierende Version beibehalten, statt automatisch die heute veröffentlichte Version zu installieren. v0.32.5 wurde am 27 July 2026 veröffentlicht. Es gibt auch einen manuellen Weg, wenn Sie lieber 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

Der manuelle Weg erstellt weder die systemd-Unit noch den Dienstbenutzer. Sie müssen beides selbst einrichten. Die vollständige Anleitung zu Ollama auf einem VPS beschreibt diese Einrichtung Schritt für Schritt.

Fehlerbilder und die angezeigten Meldungen

Ollama lädt das Modell nicht. ollama run gibt eine Zeile in dieser Form zurück:

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

Ollama prüft die Größe vor dem Laden. Der Vorgang schlägt daher sofort fehl und nennt den Grund. Verwenden Sie eine Quantisierungsstufe mit geringerer Größe, reduzieren 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. Daher kann auch eine Datei gestartet werden, die größer als der RAM ist. Der Kernel liest die Gewichte dann für jedes Token von der Festplatte ein und lagert sie wieder aus. Die Generierung sinkt auf mehrere Sekunden pro Token, während die Festplatte dauerhaft zu 100 Prozent ausgelastet ist. Übergeben Sie --no-mmap, um eine echte Speicherzuweisung zu erzwingen. Der Vorgang schlägt dann sofort fehl, statt sich immer weiter zu verlangsamen. 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 führt zu einer Fehlermeldung, die die unbekannte Architektur nennt:

error loading model architecture: unknown model architecture: 'qwen3next'

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

Die API antwortet lokal, aber nicht aus Ihrer Anwendung. Ollama bindet an 127.0.0.1:11434. Von einem anderen Host wird die Verbindung daher abgewiesen. 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 Modell wurde nach 5 Minuten im Leerlauf entladen und wird erneut von der Festplatte gelesen. ollama ps direkt vor der Anfrage zeigt, dass kein Modell geladen ist, und bestätigt dies. Erhöhen Sie OLLAMA_KEEP_ALIVE.

Welche Variante sollten Sie ausführen?

Führen Sie Ollama aus, wenn die Modelle automatisch verwaltet werden sollen und Sie ohne weiteren Aufwand einen OpenAI-kompatiblen Endpunkt benötigen. Das ist die richtige Standardwahl für eine erste Bereitstellung und für alle Einsatzfälle, in denen sich die Modellauswahl weiterhin ändern wird.

Führen Sie llama.cpp direkt aus, wenn der Arbeitsspeicher so knapp ist, dass Sie selbst die passende Quantisierungszeile auswählen müssen, wenn Sie /health, /slots und /metrics zur Überwachung benötigen oder wenn Sie ein Flag brauchen, das Ollama nicht bereitstellt. Auf einem VPS, auf dem das Modell nur knapp in den Arbeitsspeicher passt, ist das die konsequente Wahl. Denn genau die Einstellungen, die den Betrieb ermöglichen, wählt Ollama stellvertretend für Sie aus.

Der Betrieb beider Varianten ist üblich. Ollama für Experimente und llama.cpp für das eine Modell, das Sie produktiv einsetzen und dessen Version Sie nicht mehr ändern möchten.

FAQ

Ist Ollama nur ein Wrapper um llama.cpp?

Fast, aber der Wrapper übernimmt wichtige Aufgaben. In der README von Ollama ist llama.cpp als Inferenz-Backend aufgeführt (geprüft am 2 August 2026). Ollama ergänzt darauf aufbauend eine Modellregistrierung, die Prompt-Vorlage zur Umwandlung von Chatnachrichten in einen Prompt, mehrere Standardparameter für das Sampling, einen Daemon mit dem Entladen inaktiver Modelle sowie 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 Verwaltungsschichten.

Welche Variante ist auf einer VPS ohne GPU schneller?

Beide verwenden dieselbe Engine. Bei identischer Modelldatei, Quantisierung, Kontextgröße und Thread-Anzahl liegen die Ergebnisse daher eng beieinander. Unterschiede, von denen berichtet wird, entstehen meist durch abweichende Standardwerte, insbesondere durch Kontextlänge und Thread-Anzahl, und nicht durch die Engine. Messen Sie dies mit llama-bench -m <file> -p 512 -n 128 und vergleichen Sie die Spalte tg auf Ihrem eigenen System, bevor Sie veröffentlichten Werten vertrauen.

Kann ich meine eigene GGUF-Datei mit Ollama verwenden?

Ja. Legen Sie die Datei auf dem Server ab, erstellen Sie eine Modelfile, deren erste Zeile FROM ./your-model.gguf enthält, ergänzen Sie benötigte PARAMETER-Zeilen wie num_ctx und führen Sie anschließend ollama create your-name -f ./Modelfile aus. ollama ls listet das Modell neben allen Modellen auf, die Sie aus der Registrierung abgerufen haben. So verwenden Sie eine Quantisierung, die in der Registrierung nicht verfügbar ist.

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

Planen Sie die Dateigröße, den KV-Cache und die Laufzeitumgebung ein. Ein Q4_K_M-Build 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 berücksichtigen, dass der Bedarf mit OLLAMA_NUM_PARALLEL skaliert.