Software dockerLocal AIProxmoxServer

Standard-llama.cpp für GGUF-Modelle

llama.cpp mit CUDA-Unterstützung einrichten und GGUF-Modelle lokal auf der NVIDIA-GPU ausführen. Von der Docker-Konfiguration bis zum ersten laufenden Local-LLM.

llamacpp standard 1
10 Schritte 467 Views

In den vorherigen Anleitungen haben wir die technische Grundlage für unseren Local-AI-Server geschaffen. Proxmox VE wurde eingerichtet, die NVIDIA-GPU für einen unprivilegierten LXC-Container bereitgestellt und Docker für die Nutzung der GPU vorbereitet.

Jetzt kommt der eigentliche Schritt, bei dem aus dieser Grundlage ein nutzbarer Local-AI-Server wird: llama.cpp.

llama.cpp ist eine schlanke Inferenz-Engine, mit der sich große Sprachmodelle lokal und direkt auf der eigenen Hardware ausführen lassen. Ein besonderer Vorteil ist die Unterstützung des GGUF-Formats, das bei vielen lokal betriebenen LLMs verwendet wird.

In dieser Anleitung richten wir llama.cpp als Docker-Container mit CUDA-Unterstützung ein und starten anschließend ein erstes GGUF-Modell über den integrierten Webserver.

Dabei beschränken wir uns zunächst bewusst auf die Standardversion von llama.cpp. Ziel ist eine möglichst flexible Grundlage, mit der unterschiedliche GGUF-Modelle ausprobiert und betrieben werden können.

Am Ende der Anleitung haben wir:

  • llama.cpp mit CUDA-Unterstützung eingerichtet
  • die NVIDIA-GPU für llama.cpp verfügbar gemacht
  • ein GGUF-Modell gestartet
  • den integrierten Webserver getestet
  • wichtige Startparameter kennengelernt
  • die Grundlage für die Nutzung der llama.cpp-API geschaffen

Damit steht anschließend nicht nur ein einzelnes laufendes Modell zur Verfügung, sondern eine flexible Basis für verschiedene Local-AI-Anwendungen.

Hinweis: Diese Anleitung baut direkt auf der vorherigen Anleitung zur NVIDIA-GPU-Unterstützung im Proxmox-LXC auf. Docker und die NVIDIA Container Toolkit-Umgebung müssen deshalb nicht erneut eingerichtet werden.

Getestet mit dem Docker-Image server-cuda, llama.cpp-Build ___, Oktober 2026.

1

Voraussetzungen

Bevor wir mit llama.cpp beginnen, prüfen wir zunächst, ob die komplette GPU-Kette funktioniert:

Proxmox Host → LXC → Docker → NVIDIA GPU

Wenn beide folgenden Tests erfolgreich sind, ist die technische Grundlage für llama.cpp vorhanden.

NVIDIA-GPU im LXC prüfen
Zuerst prüfen wir, ob der LXC-Container direkt auf die NVIDIA-GPU zugreifen kann:
Wir bewegen uns vom Host Shell in den LXC-Container

pct enter 101 

Danach prüfen wir, ob die GPU im LXC-Container verfügbar ist:

nvidia-smi

Wenn die GPU erkannt wird, sollten unter anderem das NVIDIA-Modell, die Treiberversion und der verfügbare VRAM angezeigt werden.

NVIDIA-GPU aus Docker testen
Als Nächstes prüfen wir, ob Docker die GPU ebenfalls an einen Container weitergeben kann:

docker run --rm --gpus all nvidia/cuda:12.8.1-base-ubuntu24.04 nvidia-smi

Hier wird ein temporärer CUDA-Container gestartet. Dieser greift auf die NVIDIA-GPU des LXC zu und führt darin nvidia-smi aus.
Wenn auch hier die GPU angezeigt wird, funktioniert die komplette Kette und wir können mit der Einrichtung von llama.cpp beginnen.

Hinweis: Falls einer der beiden Tests fehlschlägt, sollte zunächst die GPU- und Docker-Einrichtung aus der vorherigen Anleitung überprüft werden. In dieser Anleitung beginnen wir erst mit llama.cpp, wenn beide Tests erfolgreich sind.

2

Verzeichnisstruktur für llama.cpp

Bevor wir llama.cpp als Docker-Container starten, legen wir eine feste Verzeichnisstruktur für die Installation und die Modelle an.
Wir verwenden dafür bewusst /opt/llamacpp. Dadurch bleiben Konfiguration, Modelle und weitere Dateien an einem zentralen Ort und sind unabhängig vom eigentlichen Docker-Container.
Das ist besonders praktisch, wenn später weitere GGUF-Modelle hinzukommen oder der llama.cpp-Container neu erstellt bzw. aktualisiert werden muss. Die Modelle bleiben dabei im Host-Dateisystem erhalten.

Verzeichnisse erstellen

Führe folgende Befehle aus:

mkdir -p /opt/llamacpp/models/huggingface
cd /opt/llamacpp

Anschließend sieht die Struktur zunächst so aus:

/opt/llamacpp/
└── models/huggingface/

Wofür sind die Verzeichnisse?
/opt/llamacpp/ – Hauptverzeichnis für unsere llama.cpp-Installation
models/huggingface/ – Cache für Modelle, die llama.cpp direkt von Hugging Face lädt

Die Modelldaten liegen außerhalb des Docker-Containers. Der Container kann dadurch jederzeit neu erstellt oder aktualisiert werden, ohne dass die heruntergeladenen Modelle verloren gehen.

3

llama.cpp Docker-Image

llama.cpp kann direkt auf dem System installiert und kompiliert werden. Für unsere Umgebung verwenden wir jedoch die Docker-Version. Dadurch müssen wir llama.cpp nicht selbst kompilieren und können eine bereits für CUDA vorbereitete Version verwenden.

Das offizielle llama.cpp-Projekt stellt verschiedene Docker-Images für unterschiedliche Einsatzbereiche bereit. Für unseren NVIDIA-Aufbau verwenden wir:

ghcr.io/ggml-org/llama.cpp:server-cuda

Dabei handelt es sich um die CUDA-Variante des llama.cpp-Servers für NVIDIA-GPUs.

Das Image müssen wir nicht separat herunterladen. Wir tragen es im nächsten Schritt in unsere docker-compose.yml ein. Beim ersten Start mit docker compose up -d prüft Docker automatisch, ob das Image bereits vorhanden ist. Falls nicht, wird es automatisch aus der GitHub Container Registry heruntergeladen.

Wichtig: Das Docker-Image enthält die llama.cpp-Software, aber noch kein Sprachmodell. Die GGUF-Modelle werden später separat bereitgestellt.

4

Docker Compose erstellen

Jetzt erstellen wir die Docker-Compose-Konfiguration für llama.cpp.

In dieser Datei legen wir fest, welches llama.cpp-Image verwendet wird, auf welchem Port der Server erreichbar ist, wo die Modelldaten gespeichert werden und dass der Container Zugriff auf die NVIDIA-GPU erhält.

Compose-Datei erstellen

Öffne die Datei:

nano /opt/llamacpp/docker-compose.yml

Füge folgenden Inhalt ein:

services:
  llamacpp:
    image: ghcr.io/ggml-org/llama.cpp:server-cuda
    container_name: llamacpp
    restart: unless-stopped

    ports:
      - "8080:8080"

    volumes:
      - /opt/llamacpp/models/huggingface:/root/.cache/huggingface

    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=compute,utility

    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Speichere die Datei mit Ctrl + O, bestätige mit Enter und verlasse nano mit Ctrl + X.

Was wird hier konfiguriert?

Image

ghcr.io/ggml-org/llama.cpp:server-cuda

Verwendet das zuvor ausgewählte llama.cpp-Image mit CUDA-Unterstützung.

Port

8080:8080

Der llama.cpp-Webserver wird über Port 8080 des LXC-Containers erreichbar sein.

Hugging-Face-Cache und Modelle

/opt/llamacpp/models/huggingface:/root/.cache/huggingface

Hier speichert llama.cpp die Modelle, die direkt von Hugging Face geladen werden. Sie liegen im Dateisystem des LXC und bleiben erhalten, wenn der Container neu erstellt wird.

NVIDIA-GPU

NVIDIA_VISIBLE_DEVICES=all
NVIDIA_DRIVER_CAPABILITIES=compute,utility

Damit wird festgelegt, dass die NVIDIA-GPU für den Container verfügbar ist und die für die Berechnung benötigten Funktionen bereitgestellt werden. Der Abschnitt deploy weist Docker die GPU zusätzlich als benötigtes Gerät zu, sodass sie beim Start nicht jedes Mal manuell angegeben werden muss.

Compose-Konfiguration prüfen

docker compose config

Wenn Docker die Konfiguration ohne Fehlermeldung ausgibt, ist die Compose-Datei syntaktisch korrekt.

Hinweis: Den Container starten wir hier noch nicht. Er hat noch kein Modell und würde wegen restart: unless-stopped immer wieder neu starten. Gestartet wird er in Schritt 5, sobald ein Modell festgelegt ist. Die wichtigsten Befehle (up, down, restart, logs) findest du gesammelt in Schritt 9.

5

Erstes GGUF-Modell laden und starten

Jetzt starten wir llama.cpp erstmals mit einem konkreten GGUF-Modell.

Für diesen Aufbau verwenden wir:

unsloth/Muse-Glimmer-30B-GGUF:UD-IQ2_XXS
Warum wählen wir IQ2_XXS?

Unsere Testplattform verfügt nur über eine RTX 3060 mit 12 GB VRAM. Bei größeren Sprachmodellen ist deshalb nicht nur die Größe des Modells selbst entscheidend, sondern auch der zusätzliche Speicherbedarf für Kontext, KV-Cache und den laufenden Inferenzprozess.

Das gewählte 30B-Modell ist als UD-IQ2_XXS mit rund 10,7 GB bereits so quantisiert, dass es grundsätzlich in den verfügbaren VRAM-Bereich einer 12-GB-GPU passt.

Die niedrige Quantisierung ist hier also eine bewusste Entscheidung:

12 GB VRAM → möglichst großes Modell → möglichst kleine Quantisierung

Dadurch können wir auf der RTX 3060 ein deutlich größeres Modell betreiben, als es beispielsweise mit einer Q4-Quantisierung dieser Modellgröße möglich wäre.

Wichtig: Die Größe der GGUF-Datei entspricht nicht dem gesamten benötigten GPU-Speicher. Während der Ausführung benötigt llama.cpp zusätzlichen Speicher für den Kontext und weitere Laufzeitdaten. Deshalb bedeutet eine 10,7-GB-GGUF-Datei nicht automatisch, dass 10,7 GB VRAM ausreichen.

Andere Hardware, andere Quantisierung

Die Wahl der Quantisierung hängt deshalb stark von der vorhandenen GPU und dem verfügbaren VRAM ab.

Mit einer einzelnen RTX 3090 mit 24 GB VRAM stehen deutlich mehr Reserven zur Verfügung. Damit können bei vergleichbaren Modellgrößen auch höher quantisierte Varianten eingesetzt werden.

Bei zwei RTX 3060 mit jeweils 12 GB VRAM kann der verfügbare GPU-Speicher über mehrere GPUs verteilt werden. Damit eröffnen sich ebenfalls Möglichkeiten für größere Modelle oder höhere Quantisierungen.

Genau das ist einer der Vorteile von llama.cpp. Wir sind nicht auf ein einzelnes Modell oder eine bestimmte Quantisierung festgelegt. Je nach vorhandener Hardware können unterschiedliche GGUF-Varianten eingesetzt werden.

Wir wählen für diese Anleitung jedoch bewusst die Variante, die zu unserer 12-GB-Testplattform passt.

Modell über Hugging Face laden

llama.cpp kann Modelle direkt über Hugging Face beziehen. Dafür verwenden wir den -hf-Parameter.

Dazu öffnen wir die bereits erstellte docker-compose.yml erneut:

nano /opt/llamacpp/docker-compose.yml

In der bestehenden Compose-Datei ergänzen wir den folgenden command-Block zwischen dem environment- und dem deploy-Abschnitt:

    command: >
      -hf unsloth/Muse-Glimmer-30B-GGUF:UD-IQ2_XXS
      --host 0.0.0.0
      --port 8080
      --n-gpu-layers 99

Die Compose-Datei enthält damit zusätzlich:

services:
  llamacpp:
    image: ghcr.io/ggml-org/llama.cpp:server-cuda
    container_name: llamacpp
    restart: unless-stopped

    ports:
      - "8080:8080"

    volumes:
      - /opt/llamacpp/models/huggingface:/root/.cache/huggingface

    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=compute,utility

    command: >
      -hf unsloth/Muse-Glimmer-30B-GGUF:UD-IQ2_XXS
      --host 0.0.0.0
      --port 8080
      --n-gpu-layers 99

    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Was bewirken die zusätzlichen Parameter?

-hf unsloth/Muse-Glimmer-30B-GGUF:UD-IQ2_XXS

weist llama.cpp an, das angegebene Modell direkt aus dem Hugging-Face-Repository zu verwenden. Die aktuelle llama.cpp-Server-Dokumentation unterstützt diese Form des direkten Hugging-Face-Modellbezugs.

Das Modell wird dabei im zuvor eingerichteten Hugging-Face-Cache abgelegt:
/opt/llamacpp/models/huggingface/

--host 0.0.0.0

Der llama.cpp-Server wird auf allen Netzwerk-Schnittstellen des Containers erreichbar.

--port 8080

Der llama.cpp-Server verwendet innerhalb des Containers Port 8080. Dieser ist durch unsere Compose-Konfiguration bereits nach außen weitergeleitet.

--n-gpu-layers 99

Damit weisen wir llama.cpp an, möglichst viele Modell-Layer auf die GPU auszulagern.

Der Wert könnte beispielsweise auch auf 50 gesetzt werden. Dann würden nicht alle Modellgewichte auf der GPU liegen und ein Teil müsste im System-RAM verarbeitet werden. Dadurch sinkt in der Regel die Tokens/s, da der Zugriff auf den VRAM deutlich schneller ist als auf die im System-RAM liegenden Modellanteile.

Mit 99 versuchen wir daher, möglichst viele Modell-Layer auf der RTX 3060 auszuführen.

Hinweis: Die tatsächliche VRAM-Nutzung hängt unter anderem vom Modell, der Quantisierung und der später gewählten Kontextgröße ab. Die Auslastung überprüfen wir nach dem Start des Modells.

llama.cpp starten

Nachdem die Compose-Datei angepasst wurde, prüfen wir zunächst die Konfiguration:

docker compose config

Wenn keine Fehlermeldung erscheint, starten wir den Container:

docker compose up -d

Beim ersten Start lädt Docker zuerst das llama.cpp-Image herunter. Das kann je nach Internetverbindung einige Zeit dauern. Den Download kannst du in einem zweiten Shell-Fenster zum Beispiel mit btop beobachten.

Anschließend beobachten wir die Logs:

docker logs -f llamacpp

Mit Strg + C verlässt du die Log-Anzeige wieder, der Container läuft dabei weiter.

Beim ersten Start lädt llama.cpp außerdem das Modell herunter, rund 10,7 GB. Danach wird das Modell geladen und die GPU initialisiert.

Ob die RTX 3060 genutzt wird, siehst du auf dem Proxmox-Host (nicht im Container) mit:

nvtop

Sobald das Modell geladen ist und im Log die Meldung zum Server erscheint, ist llama.cpp unter http://192.168.178.134:8080 erreichbar.

🔒 Sicherheit: Mit --host 0.0.0.0 kann jeder in deinem Netzwerk den Server nutzen. Im Heimnetz ist das meist in Ordnung. Gib Port 8080 aber nie im Router ins Internet frei. Optional schützt du den Server mit einem Schlüssel: Ergänze im command-Block die Zeile --api-key DEIN_KEY (ein langes, zufälliges Passwort). Danach trägst du den Schlüssel in den Einstellungen der Web-Oberfläche ein und sendest ihn bei curl mit -H "Authorization: Bearer DEIN_KEY".

Server testen

1. Web-Oberfläche: Öffne http://192.168.178.134:8080 im Browser. Dort kannst du direkt mit dem Modell chatten.

2. Status prüfen:

curl http://192.168.178.134:8080/health

Sobald das Modell geladen ist, kommt {"status":"ok"} zurück. Solange es noch lädt, erscheint eine Fehlermeldung.

3. Chat-Anfrage über die API:

curl http://192.168.178.134:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {"role": "user", "content": "Erkläre in zwei Sätzen, was GGUF ist."}
    ],
    "max_tokens": 200
  }'

Die Antwort kommt im OpenAI-kompatiblen Format. Damit kannst du den Server auch mit anderen Programmen nutzen, die eine OpenAI-API unterstützen.

Hinweis: In dieser Anleitung geht es bewusst um ein flexibles Standard-llama.cpp-Setup, mit dem sich unterschiedliche GGUF-Modelle ausführen lassen. In Schritt 6 testen wir ein zweites Modell.

6

Ein weiteres GGUF-Modell mit anderen Parametern ausführen

Nachdem wir im vorherigen Schritt bereits ein Modell gestartet haben, testen wir jetzt ein weiteres Modell mit zusätzlichen Parametern.

Dafür verwenden wir:

unsloth/Qwen3.8-27B-GGUF:UD-IQ2_S

Damit sehen wir gleichzeitig, wie einfach sich ein anderes GGUF-Modell mit llama.cpp verwenden lässt.

Laufendes Modell beenden

Da das Modell aus dem vorherigen Schritt noch läuft, beenden wir zunächst den aktuellen Container:

docker compose down

Das Modell und die gespeicherten Daten werden dabei nicht gelöscht. Es wird lediglich der laufende Container beendet und entfernt.

Compose-Datei anpassen

Zuerst öffnen wir wieder unsere Compose-Datei:

nano /opt/llamacpp/docker-compose.yml

Wir ersetzen den bisherigen command-Block durch:

command: >
  -hf unsloth/Qwen3.8-27B-GGUF:UD-IQ2_S
  --host 0.0.0.0
  --port 8080
  --n-gpu-layers 99
  --ctx-size 32768
  --flash-attn on
  --cache-type-k q4_0
  --cache-type-v q4_0
  --jinja
  --temp 1.0
  --top-p 0.95
  --top-k 20
  --min-p 0.00
  --batch-size 512
  --ubatch-size 256
  --repeat-penalty 1.00

Speichere die Datei anschließend mit Ctrl + O, bestätige mit Enter und verlasse nano mit Ctrl + X.

Modell starten
Anschließend übernehmen wir die neue Konfiguration:

docker compose up -d

Die Logs können wir wieder mit folgendem Befehl beobachten:

docker compose logs -f

Während das Modell geladen wird, können wir mit diesen zwei befehlen beobachten:

nvidia-smi
btop

Wenn der Server erfolgreich gestartet wurde, ist llama.cpp anschließend über:
http://192.168.178.134:8080
erreichbar.

Damit haben wir gezeigt, dass wir nicht für jedes Modell llama.cpp neu installieren müssen. Wir beenden den laufenden Container, ändern Modell und Parameter in der Compose-Datei und starten ihn anschließend mit der neuen Konfiguration.

7

Wichtige Modellparameter verstehen

In Schritt 6 haben wir das Qwen-Modell mit mehreren Parametern gestartet. Diese Einstellungen bestimmen unter anderem den verfügbaren Kontext, den Speicherbedarf, die Geschwindigkeit und das Verhalten bei der Textgenerierung.

Speicher und Performance

--n-gpu-layers 99

Lagert möglichst viele Modell-Layer auf die GPU aus. Dadurch wird die RTX 3060 möglichst vollständig genutzt.

--ctx-size 32768

Legt die maximale Größe des verwendeten Prompt-Kontexts auf 32.768 Tokens fest. Ein größerer Kontext benötigt entsprechend mehr Speicher.

--flash-attn on

Aktiviert Flash Attention, eine optimierte Variante der Attention-Berechnung, die je nach Modell und Hardware Speicher und Rechenzeit einsparen kann.

--cache-type-k q4_0
--cache-type-v q4_0

Speichern den K- und V-Teil des KV-Caches in Q4_0. Dadurch wird der Speicherbedarf des KV-Caches reduziert.

--batch-size 512

Legt die maximale logische Batch-Größe für die Verarbeitung fest.

--ubatch-size 256

Legt die maximale physische Batch-Größe fest, die tatsächlich in einem Verarbeitungsschritt berechnet wird.

Textgenerierung

--temp 1.0

Bestimmt die Zufälligkeit der Textgenerierung. Höhere Werte erzeugen tendenziell abwechslungsreichere Ausgaben, niedrigere Werte eher vorhersehbare.

--top-p 0.95

Begrenzt die Auswahl der nächsten Tokens auf die wahrscheinlichsten Tokens, deren kumulierte Wahrscheinlichkeit 95 % erreicht.

--top-k 20

Beschränkt die Auswahl zusätzlich auf die 20 wahrscheinlichsten Tokens.

--min-p 0.00

Deaktiviert die Min-P-Filterung. Bei einem Wert größer als 0 werden Tokens mit einer zu geringen Wahrscheinlichkeit ausgeschlossen.

--repeat-penalty 1.00

Legt die Bestrafung für wiederholte Token fest. 1.00 bedeutet, dass keine zusätzliche Wiederholungsstrafe angewendet wird.

Chat-Format

--jinja

Für Tool Calling, also wenn später ein Agent wie Hermes Werkzeuge über die API aufrufen soll, brauchst du diesen Parameter je nach llama.cpp-Version. Nutzt du später einen Agenten, nimm ihn deshalb mit auf.

Kurz zusammengefasst

Die Parameter lassen sich damit grob in drei Bereiche einteilen:

GPU und Speicher: n-gpu-layers, ctx-size, flash-attn, cache-type-k/v
Performance: batch-size, ubatch-size
Textgenerierung: temp, top-p, top-k, min-p, repeat-penalty

Welche Werte sinnvoll sind, hängt vom verwendeten Modell, der Quantisierung und der vorhandenen Hardware ab. Deshalb gibt es nicht für jedes GGUF-Modell eine einzige optimale Konfiguration.

8

GGUF-Modelle, Modellgrößen und Quantisierungen

In den bisherigen Schritten haben wir bereits unterschiedliche GGUF-Modelle verwendet. Dabei sind Begriffe wie 27B, 30B, Q4, IQ3 oder IQ2 aufgetaucht.

Um diese Bezeichnungen richtig einzuordnen, müssen wir zwei Dinge unterscheiden: Modellgröße und Quantisierung.

Was bedeutet 7B, 14B, 27B oder 30B?
Die Angabe beschreibt vereinfacht gesagt die Anzahl der Parameter, mit denen das Modell trainiert wurde.
Das B steht für Billion beziehungsweise Milliarde Parameter.

Beispiele:
7B → ca. 7 Milliarden Parameter
14B → ca. 14 Milliarden Parameter
27B → ca. 27 Milliarden Parameter
30B → ca. 30 Milliarden Parameter

Ein größeres Modell besitzt grundsätzlich mehr Parameter, die beim Ausführen im Speicher gehalten werden müssen. Dadurch steigt normalerweise auch der benötigte Speicherbedarf.
Die Modellgröße allein sagt allerdings noch nicht aus, wie viel VRAM benötigt wird. Dafür ist zusätzlich die verwendete Quantisierung entscheidend.

Was ist GGUF?
GGUF ist ein Dateiformat für lokal ausgeführte KI-Modelle. Es enthält neben den Modellgewichten auch weitere Informationen, die llama.cpp benötigt, um das Modell zu laden und auszuführen.
Ein wichtiger Vorteil von GGUF ist, dass dasselbe Modell in unterschiedlichen Quantisierungen angeboten werden kann.

Was bedeutet Quantisierung?
Bei der Quantisierung werden die Gewichte eines KI-Modells mit einer geringeren Anzahl an Bits gespeichert. Dadurch wird die Größe des Modells deutlich reduziert und es benötigt weniger Arbeitsspeicher und Grafikspeicher.
Der Vorteil: Ein Modell, das beispielsweise in voller Präzision sehr viel Speicher benötigen würde, kann durch Quantisierung auch auf Hardware mit weniger VRAM betrieben werden.
Der Nachteil: Je stärker ein Modell quantisiert wird, desto stärker kann sich die Qualität der Ausgabe verändern. Moderne Quantisierungsverfahren versuchen jedoch, diesen Qualitätsverlust möglichst gering zu halten.

Vereinfacht kann man sich die verschiedenen Quantisierungsstufen wie eine Abstufung vorstellen:

FP16->Q8->Q6->Q5->Q4->IQ3->IQ2

Je stärker quantisiert wird, desto kleiner wird das Modell und desto weniger Speicher wird benötigt. Gleichzeitig kann die Qualität gegenüber einer höher quantisierten Variante abnehmen.

Die Wahl ist deshalb immer ein Kompromiss zwischen:
Modellgröße ↔ VRAM-Bedarf ↔ Geschwindigkeit ↔ Qualität

Ein Beispiel aus unserer Anleitung
Wir haben eine RTX 3060 mit 12 GB VRAM.
Deshalb verwenden wir beim 30B-Modell aus Schritt 5:

Muse-Glimmer-30B-GGUF:UD-IQ2_XXS

Ein 30B-Modell ist deutlich größer als beispielsweise ein 7B- oder 14B-Modell. Durch die starke IQ2-Quantisierung wird der Speicherbedarf jedoch deutlich reduziert, sodass wir das Modell auf unserer 12-GB-GPU ausführen können.

Beim Qwen-Modell aus Schritt 6 verwenden wir dagegen:

Qwen3.8-27B-GGUF:UD-IQ2_S

Hier verwenden wir ebenfalls eine niedrige Quantisierung, weil wir weiterhin mit einer RTX 3060 mit 12 GB VRAM arbeiten.

Mit mehr VRAM stehen uns mehr Möglichkeiten zur Verfügung.
Auf meiner Workstation stehen sogar zwei RTX 3090 mit jeweils 24 GB VRAM zur Verfügung. Dort verwende ich beispielsweise das Modell:

unsloth/Qwen3.8-27B-GGUF:UD-Q8_K_XL

Durch die beiden GPUs stehen insgesamt 48 GB VRAM zur Verfügung. Dadurch kann das 27B-Modell mit der deutlich höheren Q8-K-XL-Quantisierung betrieben werden. Zusätzlich verwende ich dort einen Kontext von bis zu 200k Tokens.

Das zeigt sehr gut, welchen Unterschied die verfügbare VRAM-Menge macht:
Auf der RTX 3060 mit 12 GB müssen wir bei größeren Modellen stärker quantisieren, während mit zwei RTX 3090 deutlich mehr Speicher für Modellgewichte und einen großen Kontext zur Verfügung steht.

Auch mehrere GPUs können genutzt werden, um größere Modelle auszuführen, sofern die verwendete llama.cpp-Konfiguration die GPUs entsprechend nutzt.

Es geht also nicht einfach darum, immer das größtmögliche Modell zu verwenden. Entscheidend ist, eine Kombination aus Modellgröße, Quantisierung, Kontextgröße und verfügbarer Hardware zu finden, die zum jeweiligen Einsatzzweck passt.

Warum wir GGUF verwenden
Der große Vorteil unseres llama.cpp-Setups ist die Flexibilität. Wir können unterschiedliche Modelle und Quantisierungen verwenden, ohne die komplette Umgebung neu installieren zu müssen.

Wir ändern lediglich das verwendete GGUF-Modell und passen bei Bedarf die Parameter an die vorhandene Hardware an.

Genau diese Flexibilität ist das Ziel dieser Anleitung: eine allgemeine llama.cpp-Grundlage für unterschiedliche Local-LLM-Modelle zu schaffen.

Wo finden wir passende GGUF-Modelle?
Nachdem wir nun wissen, was Modellgröße, GGUF und Quantisierung bedeuten, stellt sich noch die Frage: Wo finden wir eigentlich die passenden Modelle und wie bekommen wir sie auf unseren Server?
Eine der wichtigsten Anlaufstellen ist Hugging Face. Dort werden sehr viele verschiedene KI-Modelle veröffentlicht und von der Community in unterschiedlichen Formaten und Quantisierungen angeboten.
Für unser llama.cpp-Setup suchen wir dabei gezielt nach GGUF-Modellen.
Ein weiterer Anbieter, bei dem wir häufig passende GGUF-Versionen finden, ist Unsloth. Dort werden unter anderem optimierte und quantisierte Versionen verschiedener Modelle bereitgestellt.

Huggingface
Unsloth

Ein passendes Modell auswählen
Haben wir uns für ein Modell entschieden, öffnen wir dessen Modellseite auf Hugging Face.
In der Modellübersicht finden wir häufig verschiedene Quantisierungen desselben Modells. Je nach verfügbarer Hardware können wir dort beispielsweise zwischen Q8, Q6, Q5, Q4 oder verschiedenen IQ-Quantisierungen wählen.
Wenn wir auf eine der angebotenen Quantisierungen klicken, öffnet sich die entsprechende Modellseite. Dort finden wir weitere Informationen zur gewählten Variante.

Oben rechts befindet sich die Schaltfläche „Use this model“.

Wenn wir diese öffnen, können wir anschließend „llama.cpp“ auswählen.
Dort zeigt uns Hugging Face den passenden Befehl für die Verwendung des Modells mit llama.cpp an.

Zum Beispiel:

-hf unsloth/Qwen3.8-27B-GGUF:Q4_0

Diesen Befehl können wir einfach in die Zwischenablage kopieren.

Anschließend wechseln wir zurück zu unserem Server und öffnen die Compose-Datei:

nano /opt/llamacpp/docker-compose.yml

Dort fügen wir den kopierten -hf-Parameter an der entsprechenden Stelle in unsere llama.cpp-Konfiguration ein.
Beim nächsten Start des Containers weiß llama.cpp dadurch, welches Modell von Hugging Face verwendet werden soll.

9

Betrieb und Verwaltung

Zum Abschluss hier die wichtigsten Docker-Befehle, die wir für den Betrieb und die Verwaltung von llama.cpp benötigen.

Container starten

docker compose up -d

Startet den llama.cpp-Container im Hintergrund. Wurde das benötigte Docker-Image noch nicht heruntergeladen, wird es automatisch geladen.

docker compose down

Stoppt und entfernt den llama.cpp-Container.

Die Modelle im Verzeichnis /opt/llamacpp/models bleiben dabei erhalten.

docker compose restart

Startet den bestehenden Container neu.

docker compose logs -f

Zeigt die laufenden Logs des llama.cpp-Containers an. Mit Ctrl + C kann die Log-Anzeige verlassen werden.

Alternativ kann der Container direkt angegeben werden:

docker logs -f llamacpp

Mit diesem Befehl zeigen wir gezielt die Logs des Containers llamacpp an. Das ist besonders praktisch, wenn auf dem System mehrere Docker-Container gleichzeitig laufen und wir nur die Ausgaben eines bestimmten Containers beobachten möchten.

docker ps

Zeigt die aktuell laufenden Docker-Container an.

Wenn eine neue Version des llama.cpp-Docker-Images verfügbar ist, kann dieses zunächst heruntergeladen werden:

docker compose pull

Anschließend wird der Container mit der neuen Image-Version neu erstellt bzw. gestartet:

docker compose up -d

Modell wechseln

Das verwendete GGUF-Modell ist in unserer docker-compose.yml im Bereich command festgelegt. Datei öffnen:

nano /opt/llamacpp/docker-compose.yml

Dort den Eintrag unter command anpassen, zum Beispiel:

command: >
  -hf neues-modell
  --host 0.0.0.0
  --port 8080
  --n-gpu-layers 99

Anschließend die Änderung übernehmen:

docker compose up -d

Damit wird der llama.cpp-Container mit der neuen Konfiguration gestartet.

Speicherplatz prüfen und alte Modelle löschen

Jedes Modell belegt mehrere GB, und der Container hat in unserem Aufbau 40 GB. Prüfe den Platz mit:

df -h /
du -ah /opt/llamacpp/models | sort -rh | head -10

Nicht mehr benötigte Modelle entfernst du, indem du ihren Ordner unter /opt/llamacpp/models/huggingface/ löschst (bei Hugging-Face-Caches beginnt der Ordnername meist mit models--). Wenn du dir unsicher bist, lass es lieber.

10

Fazit & Ausblick

Mit dieser Anleitung haben wir auf der technischen Grundlage der Proxmox- und der NVIDIA-Anleitung einen vollständigen llama.cpp-Server mit CUDA-Unterstützung eingerichtet.

Dabei haben wir gesehen, wie sich GGUF-Modelle über Docker einbinden und mit unterschiedlichen Parametern betreiben lassen. Gleichzeitig haben wir die Grundlagen von Modellgrößen, Quantisierungen, Kontextgrößen und GPU-Nutzung kennengelernt.

Dieser dritte Teil bildet bewusst die allgemeine Grundlage für llama.cpp und GGUF-Modelle. Im nächsten Teil beschäftigen wir uns gezielt mit Bonsai 2 und dem dafür benötigten llama.cpp-Fork.

Weiter mit Teil 4: Bonsai 2 mit llama.cpp-Fork

← Zurück zu den Local AI-Anleitungen