12. November 2026 · VRAMfarm-Team

vLLM, Ollama oder llama.cpp: womit Sie Ihr LLM betreiben, mit den Befehlen

Sprechen nur Sie mit dem Modell, sind alle drei etwa gleich schnell, und Ollama macht die wenigste Arbeit: ein Installationsbefehl und ein ollama run. Schickt ein Skript 50 Anfragen parallel ab oder nutzen zehn Kollegen dasselbe Modell, holt vLLM aus derselben Karte insgesamt etwa 5- bis 10-mal so viele Tokens pro Sekunde heraus, und der Abstand wächst mit der Last. llama.cpp, die Engine, aus der Ollama hervorgegangen ist, wählen Sie, wenn Sie jedes Byte selbst steuern wollen: genaue Quantisierungsdateien, Cache-Typen, welche Schichten auf der CPU bleiben.

Alle drei laufen auf einem gemieteten Server mit leerem PyTorch-Image, und alle drei bieten eine OpenAI-kompatible API. Die Unterschiede liegen beim Batching, bei den Dateiformaten und beim Umgang mit dem Speicher.

Die Kurzfassung

Ollama baut auf denselben GGML-Grundlagen auf wie llama.cpp, Dateiformate, Quantisierungsstufen und das Tempo für einen Nutzer liegen deshalb nah beieinander. Ollama bringt Bequemlichkeit dazu: eine Modellbibliothek mit kurzen Namen, automatische GPU-Erkennung, Modelle, die bei Bedarf geladen werden. Was es verbirgt, ist die Kontrolle, und das merken Sie an dem Tag, an dem ein Modell langsam läuft und Sie wissen müssen, warum.

Tempo: eine Unterhaltung oder fünfzig

Bei einer einzelnen Unterhaltung begrenzt die Speicherbandbreite die Texterzeugung: Für jedes neue Token liest die Karte das ganze Modell einmal. Die Laufzeitumgebung spielt eine kleinere Rolle als die Größe der Datei. Daraus folgt etwas, womit viele nicht rechnen: vLLM mit einem 8B-Modell im Original-BF16 (16 GB) ist für einen Nutzer langsamer als Ollama mit einer 4-Bit-Datei (5 GB), schlicht weil es pro Token dreimal so viele Bytes liest.

Batching ändert das Bild. vLLM liest die Gewichte einmal für einen ganzen Stapel von Anfragen und nimmt neue Anfragen in den laufenden Stapel auf, sobald alte fertig sind. Die Gesamtausgabe wächst so fast linear mit der Zahl der Nutzer, bis Rechenleistung oder Cache-Speicher ausgehen. Planungswerte für ein 8B-Modell auf einer RTX 4090, abgeleitet aus der Bandbreite und Berichten aus der Community, nicht aus eigenen Benchmarks:

Für einen Nutzer reicht das Tempo in jeder Zeile: Menschen lesen 5–8 Tokens pro Sekunde. Der Abstand entsteht unter Last: ein Support-Bot, ein internes Werkzeug für ein Team oder ein Batch-Job, der über Nacht 100.000 Produktbeschreibungen klassifiziert. Dafür ist vLLM die richtige Engine, und die Kosten pro Million Tokens zeigen, was das für die Rechnung bedeutet.

Zwei weitere Engines sollten Sie kennen. SGLang ist eine nahe Alternative zu vLLM mit ähnlichen Formaten und einem OpenAI-kompatiblen Server, stark bei vielen Anfragen mit langem gemeinsamem Präfix. TensorRT-LLM holt das Maximum aus NVIDIA-Rechenzentrumskarten heraus, braucht aber mehr Einrichtung. Wenn Sie zwischen den ersten dreien wählen, brauchen Sie keine von beiden.

Wie jede mit dem Speicher umgeht

Die meisten Geschichten nach dem Muster „es war langsam“ und „es ist abgestürzt“ haben hier ihren Ursprung.

Ollama lagert auf die CPU aus, ohne Bescheid zu sagen. Passen Modell und Kontext nicht, verschiebt Ollama einige Schichten in den Arbeitsspeicher und läuft mit einem Bruchteil des Tempos weiter. In unserem eigenen Test schickte Qwen3 32B auf einer 24-GB-Karte mit 32k Kontext 18 % seiner Schichten auf die CPU und fiel von etwa 30 Tokens pro Sekunde auf 2,5. Führen Sie ollama ps aus: In der Spalte PROCESSOR sollte 100% GPU stehen. Setzen Sie den Kontext mit OLLAMA_CONTEXT_LENGTH, und denken Sie daran, dass OLLAMA_NUM_PARALLEL den Cache vervielfacht: Vier parallele Slots mit 8k Kontext brauchen den Cache von 32k.

llama.cpp tut genau, was Sie sagen. -ngl legt fest, wie viele Schichten auf die GPU kommen (99 heißt alle), -c setzt den gesamten Kontext, und -np die Zahl der parallelen Slots, die ihn sich teilen: -c 32768 -np 4 gibt vier Nutzern je etwa 8k. Bei Mixture-of-Experts-Modellen, die nicht passen, hält --n-cpu-moe einen Teil der Experten-Gewichte im Arbeitsspeicher, während die gemeinsamen Schichten auf der GPU bleiben. So laufen große MoE-Modelle auf kleineren Karten mit brauchbarem Tempo.

vLLM reserviert den Speicher im Voraus. Standardmäßig nimmt es beim Start 90 % der Karte und füllt, was die Gewichte nicht belegen, mit KV-Cache. Dann prüft es, ob eine Anfrage mit dem maximalen Kontext passt, und startet nicht, wenn nicht; die Fehlermeldung nennt den größten Kontext, der passen würde. Setzen Sie --max-model-len auf das, was Sie wirklich brauchen, und --gpu-memory-utilization niedriger, wenn sich noch etwas anderes die Karte teilen muss. Den Rest erklärt der Ratgeber zu CUDA out of memory.

Ollama: Startbefehle

Auf einem leeren PyTorch-Server, im Jupyter-Terminal oder per SSH:

curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 \
  ollama serve > /workspace/ollama.log 2>&1 &
ollama run qwen3:8b

Jede GGUF-Datei von Hugging Face funktioniert ebenfalls: ollama run hf.co/<user>/<repo>:Q4_K_M. Die API lauscht auf Port 11434:

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" \
  -d '{"model": "qwen3:8b", "messages": [{"role": "user", "content": "Hello"}]}'

Wenn Sie nur ein Chatfenster wollen, brauchen Sie nichts davon: Die fertige App Private ChatGPT installiert Ollama, ein Qwen3- oder MiMo-Modell und Open WebUI von selbst, wie unter Ihr eigenes ChatGPT mit Open WebUI beschrieben.

llama.cpp: einmal bauen, dann starten

llama.cpp muss mit CUDA kompiliert werden. Das Server-Image enthält die CUDA-Laufzeit, aber keinen Compiler; installieren Sie also zuerst das Toolkit von NVIDIA. Es lädt ein paar GB herunter, die als Traffic zählen, und der Build dauert 5–15 Minuten:

wget -q https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
dpkg -i cuda-keyring_1.1-1_all.deb && apt-get update -qq
apt-get install -y -qq cuda-toolkit-12-8 cmake git build-essential
export PATH=/usr/local/cuda-12.8/bin:$PATH

git clone https://github.com/ggml-org/llama.cpp /workspace/llama.cpp && cd /workspace/llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

Laden Sie dann eine GGUF-Datei herunter und starten Sie den Server mit vier parallelen Slots:

pip install -U huggingface_hub
hf download <user>/<repo>-GGUF <model>-Q4_K_M.gguf --local-dir /workspace/models
./build/bin/llama-server -m /workspace/models/<model>-Q4_K_M.gguf \
  -ngl 99 -c 32768 -np 4 --flash-attn on --host 127.0.0.1 --port 8081

Port 8080 belegt auf unseren Servern Jupyter, daher 8081. llama-server stellt die API im OpenAI-Stil unter /v1 bereit und eine einfache Chatseite unter der Wurzeladresse. Wenn Sie llama.cpp wieder nutzen werden, behalten Sie den gebauten Ordner /workspace/llama.cpp im gespeicherten Ordner, statt jedes Mal neu zu kompilieren.

vLLM: eine API mit zwei Befehlen

pip install "vllm==0.11.0" "transformers>=4.56,<5"   # gebaut für CUDA 12.8
vllm serve Qwen/Qwen3-8B --max-model-len 16384 \
  --host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &

Ein einfaches pip install vllm holt die neueste Version mit eigenem PyTorch-Build, und im Herbst 2026 zielt dieser Build auf eine neuere CUDA-Version, als die Treiber vieler Maschinen unterstützen; die Engine startet dann nicht. Deshalb legt der Befehl oben vLLM 0.11.0 fest (PyTorch 2.8, CUDA 12.8), die Version, die auch unser vLLM-Server nutzt. Auf einer Maschine, deren Katalogeintrag CUDA 13 oder neuer zeigt, können Sie eine spätere Version nehmen. Prüfen Sie die CUDA-Version, die vor dem Start angezeigt wird; wie Sie diese Zahlen lesen, erklärt der Artikel zu CUDA- und Treiberkonflikten. Der fertige vLLM-Server spart Ihnen diesen Schritt: vLLM ist in einer zur Maschine passenden Version installiert und startet von selbst ein Qwen-7B-Modell. Um dort ein anderes Modell bereitzustellen, führen Sie pkill -f "vllm serve" aus und starten Ihren eigenen Befehl auf Port 8000.

In Ihrem Code nutzen Sie den normalen OpenAI-Client mit Ihrer eigenen Adresse:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="change-me")
r = client.chat.completions.create(model="Qwen/Qwen3-8B",
    messages=[{"role": "user", "content": "Summarise this ticket: ..."}])
print(r.choices[0].message.content)

Dieselben Zeilen mit einer anderen Basis-URL verbinden einen Telegram-Bot, eine RAG-Pipeline oder eine bestehende App, die für OpenAI geschrieben wurde.

Die API von außen erreichen und am Laufen halten

Ein Server hat keine eigene öffentliche IP; SSH, Jupyter und Apps laufen über unsere Adresse mit Ports, die diesem Server zugewiesen sind. Auf dem vLLM-Server ist Port 8000 bereits freigegeben, und das Dashboard zeigt die API-Adresse. Auf einem leeren PyTorch-Server sind nur SSH und Jupyter freigegeben. Erreichen Sie Ollama oder llama.cpp deshalb über einen SSH-Tunnel von Ihrem Computer: ssh -p <port> -L 8081:localhost:8081 root@<address> (Port und Adresse von der Serverkarte; die Anleitung zum SSH-Schlüssel richtet den Schlüssel ein), dann nutzen Sie http://localhost:8081. Ein eigenes Docker-Image kann einen eigenen Port freigeben. Docker innerhalb des Servers gibt es nicht, deshalb installiert jeder Befehl hier mit pip oder einem Skript.

Was von außen erreichbar ist, braucht einen Schlüssel. vLLM nimmt --api-key, llama.cpp ebenfalls --api-key, und Ollama hat keinen eigenen Schlüssel; lassen Sie es also hinter einem Tunnel.

Starten Sie langlaufende Server wie oben mit nohup ... & und einer Logdatei oder in tmux (apt-get install -y tmux, dann tmux new -s llm), damit sie weiterlaufen, wenn Sie den Browser oder die SSH-Sitzung schließen. Sie enden mit dem Server: Die Abrechnung endet in der Minute, in der Sie auf „Stoppen“ klicken, und der nächste Start beginnt mit einer leeren Festplatte, bis auf das, was Sie im gespeicherten Ordner behalten haben.