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

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

Ollama und llama.cpp sind nicht in dem Sinn Konkurrenten, den 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. 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.

Verwenden Sie Ollama, wenn Sie einen Dienst möchten, der Modelle anhand ihres Namens abruft und ohne laufende Betreuung funktioniert. 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 auf einem kleinen VPS jede dieser Einstellungen Speicher belegt, den Sie nicht haben.

Was die einzelnen Projekte tatsächlich sind

llama.cpp ist eine in C und C++ implementierte Transformer-Inferenz-Engine auf Basis der ggml-Bibliothek. Sie 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 verschiedene Aufgaben separate Binärdateien bereit. llama-server ist ein HTTP-Server, llama-cli ist eine interaktive Eingabeaufforderung und llama-bench misst den Durchsatz. Releases werden anhand einer Build-Nummer statt einer semantischen Version gekennzeichnet. Der aktuelle Tag ist b10224, veröffentlicht am 2. August 2026. An den meisten Arbeitstagen kommt ein neuer Tag hinzu.

Ollama ist ein Go-Programm. Ein Hintergrund-Daemon, der mit ollama serve gestartet wird, lädt Modelle und beantwortet HTTP-Anfragen. Ein Kommandozeilen-Client kommuniziert mit diesem Daemon. Dahinter befindet sich 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 und speichert sie unter /usr/share/ollama/.ollama/models unter Linux. Diese Dateien liegen auf dem Root-Datenträger und belegen jeweils mehrere Gigabyte. Auf einem VPS mit einem 25-GB-Root-Volume sollten Sie daher wissen, was pull hinterlässt und wie Sie das Modellverzeichnis an einen anderen Ort verschieben, bevor der dritte Download den Speicherplatz füllt.

Diese Paketierung macht den gesamten Unterschied aus. 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 stellt Ihnen Flags bereit.

Achse 1: Modell- und Quantisierungssteuerung

Durch die 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 Sie das Muster kennen: Q4_K_M bedeutet 4-Bit-K-Quantisierung mit mittlerer Größe. Eine höhere Zahl erhält mehr Genauigkeit 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, abgerufen am 2. August 2026 und von Byte in GiB umgerechnet. Für ein Modell gibt es 6 Builds. 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 darüber, ob das Modell überhaupt geladen werden kann. Die Größe ist jedoch nur die Hälfte der Entscheidung. Eine Variante, die Sie sich leisten können, ist nicht automatisch eine Variante, die sich lohnt. 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 die Variante daher selbst.

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 Thread-Anzahl, und -ngl legt fest, wie viele Layer auf eine GPU verschoben werden (0 auf einem reinen CPU-System). Es wird nichts automatisch für Sie ermittelt.

Bei Ollama ist die Quantisierung im abgerufenen Tag enthalten. ollama ls zeigt, was tatsächlich auf der Festplatte vorhanden ist. Wenn die Registry die gewünschte Variante 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 in die kleinste Kategorie: 4096 Tokens. Senden Sie ein Dokument mit 20.000 Tokens, werden die zusätzlichen Tokens verworfen, bevor das Modell sie überhaupt sieht. Die Antwort ist dann möglicherweise selbstsicher, aber für eine Datei falsch, die das Modell nur teilweise gelesen hat. Erhöhen Sie den Wert mit OLLAMA_CONTEXT_LENGTH beim Daemon oder mit PARAMETER num_ctx in einer Modelfile. Wenn nur ein einzelner Auftrag ein größeres Kontextfenster benötigt, kann num_ctx pro Anfrage statt global für den Server gesetzt werden. Dadurch bleibt der zusätzliche Cache für alle anderen Aufgaben ungenutzt, die der Daemon bearbeiten soll. Auch bei llama.cpp gibt es keinen Standardwert, dem Sie vertrauen sollten. Setzen Sie -c ausdrücklich und prüfen Sie den gesetzten Wert.

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. Das Lifecycle-Management ist damit ohne eigene Konfiguration verfügbar. 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 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. Das Entladen einer 4.58 GiB großen Datei verlängert eine Antwort von zwei Sekunden auf dreißig Sekunden, wenn der Speicher langsam ist. Ein langer keep-alive-Wert verhindert diese Latenz, belegt den RAM jedoch dauerhaft. Beides verursacht reale Kosten. Wählen Sie die Variante, deren Nachteile für Sie geringer sind. Wenn das Modell dauerhaft im Speicher bleiben soll, sind einige Zeilen für keep_alive nötig, damit es Leerlaufzeiten und Reboots übersteht. Dadurch müssen Sie das Modell nicht nach jedem Neustart des Servers manuell vorwärmen.

llama.cpp stellt keinen Daemon bereit. Deshalb 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 den Dienst mit sudo systemctl enable --now llama-server. Der Prozess hält das Modell dann während seiner gesamten Laufzeit im Speicher. Im Leerlauf wird nichts entladen. Dadurch gibt es keine unerwartete Neuladung, aber auch keine Möglichkeit, den Speicher freizugeben, außer den Dienst zu stoppen. Wenn Sie bisher keine Units geschrieben haben, entspricht das demselben Muster wie eigene Dienste unter systemd auf einem VPS zu betreiben.

Achse 3: die API, mit der Ihre Anwendung kommuniziert

Diese Achse hat sich stark angenähert. Beide Projekte unterstützen inzwischen das OpenAI-Chatformat. Daher funktionieren die meisten Clientbibliotheken mit beiden Projekten, wenn 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 es unter /api/chat eine native API bereit. Eine zu 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 bietet es den eigenen Endpunkt /completion und eine integrierte Weboberfläche. Außerdem stellt es 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 der einzelnen Request-Slots und /metrics im Prometheus-Format. Wenn Sie diesen Dienst überwachen möchten, ist dieser Unterschied wahrscheinlich entscheidend.

Keiner der beiden Server aktiviert die Authentifizierung automatisch für Sie. Beide verwenden aus gutem Grund standardmäßig Loopback. 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 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 zeigt die Geschwindigkeit der Prompt-Verarbeitung. Die Spalte tg zeigt die Geschwindigkeit der Token-Generierung. Beide Werte werden in Tokens pro Sekunde angegeben. Auf einem VPS mit gemeinsam genutztem vCPU erreicht ein 8B-Modell mit Q4_K_M normalerweise nur niedrige einstellige Werte bei tg. Die Prompt-Verarbeitung ist der kritische Teil: Der gesamte Prompt wird verarbeitet, bevor das erste Ausgabe-Token erscheint. Ein langer System-Prompt verursacht daher bei jeder einzelnen Anfrage eine zusätzliche Wartezeit. Die Antwortlänge ist der Teil der Kosten, den Sie tatsächlich kontrollieren können. Bei drei Tokens pro Sekunde belegt ein Modell, das 600 Tokens ausgibt, den VPS drei Minuten lang. Mit der Begrenzung der Ausgabe durch num_predict verhindern Sie daher am günstigsten, dass eine zu lange Antwort zu einem Timeout führt.

Auf der CPU sinnvoll nutzbar ist ein 1B- bis 4B-Modell für Klassifizierung, Extraktion, kurze Zusammenfassungen oder Routing. Antworten treffen innerhalb weniger Sekunden ein. Der Speicherbedarf passt zu einem normalen Tarif. Ein konkretes Beispiel statt einer Größenordnung bietet Nemotron 3.5 Lightning, auf einem VPS heruntergeladen und gemessen. Dort finden Sie den genauen Tag, den tatsächlich benötigten RAM und die Geschwindigkeit ohne GPU. Nicht sinnvoll auf der CPU nutzbar sind interaktiver Chat mit Lesegeschwindigkeit, Coding-Assistenten, die Verarbeitung langer Dokumente sowie Agentenschleifen mit vielen aufeinanderfolgenden Aufrufen. Eine Schleife mit zwölf Aufrufen zu jeweils vier Sekunden benötigt eine Minute, bevor sie überhaupt ein Ergebnis liefert. Wenn ohnehin ein Coding-Assistent geplant war, beschreibt wie Sie einen Agenten auf ein selbst gehostetes Modell richten kann, bei welchen 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 parallele Bereitstellung behandelt dieses Thema. Liegt das Problem bei der reinen Geschwindigkeit, lautet die Antwort ein VPS mit angeschlossener GPU. Dort beginnt -ngl relevant zu werden. Ermitteln Sie zuvor eine Referenz für die Hardware selbst. Bandbreite von Datenträger und Arbeitsspeicher beeinflusst die Ladezeit ebenso stark wie die CPU. Ein reproduzierbarer VPS-Benchmark ist den Zeitaufwand wert.

llama.cpp installieren und auf einen Build festlegen

Beide Projekte werden wöchentlich aktualisiert. Notieren Sie daher die eingesetzte Version. 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 Releases-Seite. Build b10224 ist seit dem 2. August 2026 das aktuelle Tag:

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 dieses 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 die kleinsten Tarife bereitstellen. Erstellen Sie den Build daher auf einem größeren System und kopieren Sie die Binärdateien, wenn der kleine Server nicht genügend Arbeitsspeicher 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 Meldungen

Ollama verweigert das Laden des Modells. 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 schlägt der Vorgang sofort mit einer Begründung fehl. Wechseln Sie zur nächsten Quantisierungszeile, 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. 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 in den Speicher und wieder zurück. Die Generierung sinkt dadurch 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. Dann schlägt der Vorgang sofort fehl, statt 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. Ein GGUF, das für eine neuere Modellfamilie als Ihre Engine erstellt wurde, gibt einen Fehler aus, der 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 Festhalten an einer bestimmten 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. Deshalb erhält ein anderer Host eine Verbindungsverweigerung. 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 Authentifizierung davor hat.

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 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?

Fast, aber der Wrapper übernimmt wichtige Aufgaben. In der README von Ollama ist llama.cpp als Inferenz-Backend aufgeführt (Stand: 2. August 2026). Zusätzlich stellt Ollama eine Modellregistrierung, das Prompt-Template zur Umwandlung von Chat-Nachrichten in einen Prompt, mehrere Standardparameter für das Sampling, einen Daemon mit Entladen bei Inaktivität und eine HTTP-API bereit. Wenn Sie die 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 CPU-only-VPS schneller?

Beide verwenden dieselbe Engine. Bei identischer Modelldatei, Quantisierung, Kontextgröße und Thread-Anzahl liegen die Ergebnisse daher nah beieinander. Unterschiede, von denen Nutzer berichten, entstehen meist durch abweichende Standardeinstellungen, 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 und erstellen Sie eine Modelfile, deren erste Zeile FROM ./your-model.gguf enthält. 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. Mit ollama ls wird die Datei neben allen Modellen aufgeführt, die Sie aus der Registrierung geladen 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, während 4 GiB nicht ausreichen. Der Cache skaliert 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 auch mit OLLAMA_NUM_PARALLEL skaliert.