Ollama oder llama.cpp auf dem VPS: Was passt besser?

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

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 Model-Manager, ein Hintergrund-Daemon und eine HTTP-API, die auf dieser Engine aufsetzt. Die README von Ollama führt llama.cpp weiterhin als Inference-Backend auf (geprüft am 2. August 2026). Die eigentliche Frage lautet daher, welche Ebene Sie auf Ihrem VPS betreiben möchten, nicht welche schneller ist.

Führen Sie Ollama aus, 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 Context-Größe und die genaue Thread-Anzahl festlegen müssen, weil auf einem kleinen VPS jede dieser Einstellungen Speicher kostet, den Sie nicht haben.

Was die einzelnen Projekte tatsächlich sind

llama.cpp ist eine in C und C++ implementierte Transformer-Inferenz 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 ist eine interaktive Eingabeaufforderung und llama-bench misst den Durchsatz. Die Releases sind nach Build-Nummern statt nach semantischen Versionen gekennzeichnet. Der aktuelle Tag ist b10224. Er wurde am 2. August 2026 veröffentlicht. An den meisten Werktagen kommt ein neuer Tag hinzu.

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

Diese Paketierung ist der gesamte Unterschied. Ollama legt die Quantisierung, die Vorlage und die 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

Durch 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 Benennung von GGUF-Dateien ist verständlich, sobald das Muster bekannt ist: Q4_K_M bedeutet 4-Bit-K-Quantisierung mit mittlerer Größe. Eine höhere Zahl bewahrt 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 Repository bartowski/Meta-Llama-3.1-8B-Instruct-GGUF auf Hugging Face. Die Werte wurden am 2. August 2026 ausgelesen und von Bytes in GiB umgerechnet. 6 Builds eines Modells sind verfügbar. Der kleinste Build 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.

Mit llama.cpp geben Sie den Dateinamen an. Sie wählen daher 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 ausschließlich mit CPU). Es wird nichts automatisch für Sie ermittelt.

Bei Ollama wird die Quantisierung zusammen mit dem abgerufenen Tag verwendet. Mit ollama ls sehen Sie, 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. Wenn Sie ein Dokument mit 20.000 Tokens übergeben, werden die zusätzlichen Tokens verworfen, bevor das Modell sie überhaupt sieht. Die Antwort ist dann möglicherweise sicher formuliert, aber in Bezug auf eine Datei, die nur teilweise gelesen wurde, falsch. Erhöhen Sie den Wert mit OLLAMA_CONTEXT_LENGTH beim Daemon oder mit PARAMETER num_ctx in einer Modelfile. Auch bei llama.cpp ist der Standardwert nicht zuverlässig. Setzen Sie -c explizit und prüfen Sie den gesetzten Wert.

Die Speicherberechnung, die Ihnen niemand zeigt

Die Modelldatei umfasst nicht die gesamten Kosten. Der KV-Cache (Key-Value-Cache) enthält pro Layer und Kontext-Token einen Eintrag. 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 Head-Dimension von 128. Jeder Token speichert sowohl einen Key als auch einen Value mit jeweils 2 Byte in f16. Daraus ergibt sich 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 mit einem 4k-Kontext benötigt 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 hat es ausreichend Arbeitsbereich. Erhöhen Sie den Kontext auf 32k auf demselben System mit 8 GiB, belegt allein der Cache den verfügbaren Spielraum. Beobachten Sie den Speicherverbrauch mit free -h, während das Modell geladen ist, und verlassen Sie sich nicht auf eine Schätzung, die Sie nicht gemessen haben. Wenn Sie für deutlich mehr als 8B dimensionieren, zeigt dieselbe Berechnung für ein 27B-Modell auf einem VPS nur mit CPU, was die einzelnen Größen von 8 bis 64 GB tatsächlich aufnehmen können.

Ollama verstärkt diesen Effekt. OLLAMA_NUM_PARALLEL ist standardmäßig auf 1 gesetzt. Der für ein Modell benötigte Speicher skaliert mit diesem Wert multipliziert mit der Kontextlänge. Wenn Sie beides gleichzeitig erhöhen, fordert der Daemon unbemerkt ein Mehrfaches des erwarteten RAM an. Dieselbe Berechnung legt auch die Obergrenze für gleichzeitige Benutzer fest, weil jede parallele Anfrage einen eigenen Anteil des KV-Cache benötigt. Das ist der Grund, warum ein Server bei einer Person problemlos läuft, bei fünf Personen aber 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. Die Verwaltung des Lebenszyklus ist damit ohne eigene Implementierung möglich. 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 jeder anderen Umgebung. Modelle bleiben standardmäßig 5 Minuten im Arbeitsspeicher und werden danach entladen. Die nächste Anfrage muss die gesamte Datei erneut von der Festplatte lesen, bevor sie beantwortet werden kann. Beim langsamen Speicher verlängert ein erneutes Laden von 4.58 GiB eine Antwort von zwei Sekunden auf dreißig Sekunden. Ein langer Keep-Alive-Wert verhindert diese Latenz und belegt den Arbeitsspeicher 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 Arbeitsspeicher. Bei Inaktivität wird nichts entladen. Dadurch gibt es keine unerwartete Verzögerung durch ein erneutes Laden, aber auch keine Möglichkeit, den Arbeitsspeicher freizugeben, ohne den Dienst zu stoppen. Wenn das Schreiben von Units für Sie neu ist, entspricht dies dem Muster eigene Dienste unter systemd auf einer VPS betreiben.

Achse 3: die API, mit der Ihre Anwendung kommuniziert

Diese Achse hat sich deutlich angenähert. Beide Projekte unterstützen inzwischen das OpenAI-Chat-Format. Daher funktionieren die meisten Clientbibliotheken mit beiden Projekten, sobald Sie nur die Basis-URL ändern.

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 stellt llama-server Betriebsrouten bereit, die Ollama nicht bietet: /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. Wenn Sie diesen Dienst überwachen möchten, ist dieser Unterschied wahrscheinlich ausschlaggebend.

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

Was ein VPS ohne GPU ehrlich leisten kann

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

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. Bei einem Tarif mit gemeinsam genutzten vCPUs erreicht ein 8B-Modell mit Q4_K_M für tg normalerweise nur 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 verlängert daher jede einzelne Anfrage.

Auf der CPU sinnvoll einsetzbar ist ein Modell mit 1B bis 4B Parametern für Klassifikation, Extraktion, kurze Zusammenfassungen oder Routing. Antworten treffen innerhalb weniger Sekunden ein. Der Speicherbedarf passt zu einem normalen Tarif. Auf der CPU nicht sinnvoll einsetzbar sind interaktive Chats mit Lesegeschwindigkeit, Coding-Assistenten, die Arbeit mit langen Dokumenten und alles, was in einer Agentenschleife viele Aufrufe nacheinander ausführt. Eine Schleife mit zwölf Aufrufen zu je vier Sekunden benötigt eine Minute, bevor sie überhaupt ein Ergebnis liefert. Wenn ein Coding-Assistent ohnehin vorgesehen war, beschreibt wie Sie einen Agenten auf ein selbst gehostetes Modell ansetzen können, für welche Aufgaben ein kleines lokales Modell tatsächlich Vorteile bietet und welche Aufgaben bei einer gehosteten API bleiben müssen.

Wenn die Zahlen nicht ausreichen, gibt es zwei Auswege. Liegt das Problem bei der Parallelität, 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 parallele 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 vorher einen Ausgangswert für die Hardware selbst. Die Bandbreite von Datenträger und Arbeitsspeicher beeinflusst die Ladezeit ebenso stark wie die CPU. Ein reproduzierbarer VPS-Benchmark ist den dafür benötigten Aufwand wert.

llama.cpp installieren und auf einen Build festlegen

Beide Projekte werden wöchentlich weiterentwickelt. Dokumentieren Sie daher die Version, die Sie bereitgestellt haben. 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 vorkompilierte Tarball von der Release-Seite. Build b10224 ist der aktuelle Tag zum Stand 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'

Oder erstellen Sie denselben Tag aus dem Quellcode:

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 in den kleinsten Tarifen verfügbar ist. Erstellen Sie den Build daher auf einem größeren Server und kopieren Sie die Binärdateien, wenn der kleine Server nicht genügend RAM 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 verwenden, statt die Version zu installieren, die heute Morgen veröffentlicht wurde. v0.32.5 wurde am 27 July 2026 veröffentlicht. Es gibt auch einen manuellen Weg, wenn Sie lieber kein Skript in eine Shell pipen 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 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. Deshalb bricht der Vorgang sofort mit einer Begründung ab. Verwenden Sie eine niedrigere Quantisierungsstufe, reduzieren Sie die Kontextlänge oder wählen Sie ein kleineres Modell.

llama.cpp bricht nicht ab, sondern wird extrem langsam. llama.cpp ordnet die GGUF-Datei standardmäßig per Memory-Mapping zu. Deshalb startet auch eine Datei, die größer als der Arbeitsspeicher ist. Der Kernel lädt die Gewichte dann für jedes Token von der Festplatte nach und schreibt sie wieder zurück. Die Generierung benötigt dadurch mehrere Sekunden pro Token, während die Festplatte dauerhaft zu 100 Prozent ausgelastet ist. Übergeben Sie --no-mmap, um eine echte Speicherzuweisung zu erzwingen. Dann bricht der Prozess sofort ab, statt nur langsamer zu werden. 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 eine Fehlermeldung, die die unbekannte Architektur nennt:

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

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

Die API antwortet lokal, aber nicht aus Ihrer Anwendung. Ollama bindet an 127.0.0.1:11434. Von einem anderen Host aus wird die Verbindung daher abgewiesen. Setzen Sie OLLAMA_HOST=0.0.0.0:11434 über systemctl edit ollama nur dann, wenn der Port durch eine Firewall oder ein privates Netzwerk geschützt ist, da die API keine vorgeschaltete Authentifizierung besitzt.

Die erste Antwort nach einer Pause ist sehr langsam. Das Modell wurde nach 5 Minuten Inaktivität entladen und wird erneut von der Festplatte gelesen. ollama ps unmittelbar vor der Anfrage zeigt, dass kein Modell geladen ist. Das bestätigt die Ursache. Erhöhen Sie OLLAMA_KEEP_ALIVE.

Welche Variante 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. Das ist die richtige Standardwahl für eine erste Bereitstellung und für alle Szenarien, in denen sich die Modellauswahl regelmäßig ändern wird.

Verwenden Sie llama.cpp direkt, wenn der Speicher so knapp ist, dass Sie die passende Quantisierungszeile selbst 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 Speicher passt, ist das die pragmatische Wahl. Denn genau die Einstellungen, die den Betrieb ermöglichen, wählt Ollama sonst für Sie.

Beide Varianten parallel zu verwenden, ist normal. Ollama eignet sich für Experimente. llama.cpp eignet sich für das eine Modell, das Sie produktiv einsetzen und dessen Version Sie nicht automatisch ändern lassen 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 eine Modellregistrierung, die Prompt-Vorlage zur Umwandlung von Chat-Nachrichten in einen Prompt, mehrere standardmäßige Sampling-Parameter, einen Daemon mit dem Entladen ungenutzter Modelle und eine HTTP-API. Wenn Sie Tokens pro Sekunde bei identischen Einstellungen vergleichen, vergleichen Sie dieselbe Engine mit sich selbst. Tatsächlich entscheiden Sie sich zwischen den Verwaltungsschichten.

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 nah beieinander. Gemeldete Unterschiede entstehen meist durch unterschiedliche Standardwerte, insbesondere bei 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 einer veröffentlichten Zahl vertrauen.

Kann ich meine eigene GGUF-Datei mit Ollama verwenden?

Ja. Legen Sie die Datei auf dem Server ab. Schreiben Sie eine Modelfile, deren erste Zeile FROM ./your-model.gguf lautet, und fügen Sie alle benötigten PARAMETER-Zeilen hinzu, beispielsweise num_ctx. 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 Build von Llama 3.1 8B mit Q4_K_M benötigt 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, während 4 GiB nicht ausreichen. 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 wächst.