LLM selbst hosten mit vLLM auf einem Hetzner-GPU-Server: unser Setup

Wer ein LLM selbst hosten will, findet hier unser Setup, so wie es läuft. Seit Juli 2026 betreiben wir das Open-Weight-Modell Qwen3-14B mit vLLM auf einem gemieteten Hetzner-GPU-Server in Deutschland. Zwischen Frage und Antwort sitzt kein Modellanbieter, und einen öffentlichen Endpunkt hat das Modell nicht.

Der Server: ein Hetzner GEX44 mit 20 GB VRAM

Unser Server ist ein Hetzner GEX44 mit einer NVIDIA RTX 4000 SFF Ada, einer kompakten Karte mit 70 Watt und 20 GB Grafikspeicher (VRAM). Dazu kommen ein Intel Core i5-13500, 64 GB Arbeitsspeicher und zwei NVMe-SSDs. Beim Chatten zählt vor allem eine Zahl: die Speicherbandbreite. Diese Karte schafft 280 GB/s, und genau das bestimmt die Geschwindigkeit. CPU und Arbeitsspeicher haben wenig zu tun.

Das Modell: Qwen3-14B in 4-Bit-AWQ

Wir nutzen Qwens eigene AWQ-Fassung von Qwen3-14B: 14,8 Milliarden Parameter, offene Gewichte unter der Lizenz Apache 2.0. Mit 16 Bit pro Gewicht bräuchte das Modell allein rund 29,6 GB, mehr als die Karte hat. AWQ (Activation-aware Weight Quantization) speichert die Gewichte in 4 Bit und schützt dabei die wenigen, auf die es am meisten ankommt. So passt das Modell in etwa 10 GB. Der Rest der Karte bleibt für den KV-Cache, den Arbeitsspeicher, in dem das Modell die laufenden Gespräche hält.

Die Gewichte liegen auf dem Server und sind auf eine Version festgelegt, ein Neustart lädt also nie eine neuere herunter. GGUF, das Format von llama.cpp und Ollama, ist in vLLM noch experimentell; den Unterschied erklärt Ollama oder vLLM. Welche anderen offenen Modelle in 20, 24 oder 96 GB passen, steht im Ratgeber zum VRAM-Bedarf.

Der Befehl vllm serve

Pfad, Modellname und Port sind Platzhalter. Die Einstellungen sind die, mit denen wir arbeiten.

vllm serve /path/to/model \
  --served-model-name my-model \
  --host 127.0.0.1 --port 8000 \
  --max-model-len 8192 \
  --max-num-seqs 2 \
  --max-num-batched-tokens 2048 \
  --gpu-memory-utilization 0.75 \
  --enforce-eager \
  --no-enable-log-requests \
  --disable-uvicorn-access-log

Was die Einstellungen bewirken:

• Host 127.0.0.1, die interne Loopback-Adresse des Servers: Aus dem Internet antwortet am Modell-Port nichts.
• 8.192 Token pro Anfrage, Prompt und Antwort zusammen. Ohne diese Grenze würde vLLM mit den vollen 40.960 des Modells planen; mit ihr passen zwei volle Gespräche mit Reserve in den Speicher.
• Zwei Anfragen gleichzeitig. Eine dritte wartet in der Schlange. Lange Prompts verarbeitet vLLM in Abschnitten von bis zu 2.048 Token.
• 75 % des Grafikspeichers für vLLM statt der standardmäßigen 92 %. Das lässt auf einer 20-GB-Karte Luft.
• Eager-Modus schaltet CUDA Graphs ab. Das spart Speicher und kostet etwas Tempo.
• Keine Request-Logs: vLLM schreibt keine Zeile pro Anfrage, und der eingebaute Webserver schreibt keine Access-Zeile. Prompts landen in keinem Log.

Auf unserer Karte belegen die Gewichte knapp die Hälfte des Speichers und der KV-Cache etwa ein Viertel, genug für fast vier volle Gespräche mit 8.192 Token. Für andere Modelle und Karten gibt es den VRAM-Rechner.

Der Thinking-Modus von Qwen3 zählt mit

Qwen3 startet im Thinking-Modus. Seine Denkschritte gehen vom selben Fenster mit 8.192 Token ab und kosten Zeit. Für normalen Chat schalten Sie den Modus ab, wie es die Modellkarte beschreibt, bevor Sie die Grenze anheben.

vLLM als systemd-Service, vom Internet abgeschottet

vLLM läuft als systemd-Service, der beim Booten startet und Speichergrenzen hat. Unsere eigenen Systeme erreichen ihn über einen eingeschränkten Tunnel, aus dem Internet ist er gar nicht erreichbar. Wenn Sie stattdessen einen Port öffnen, verlassen Sie sich nicht allein auf die API-Key-Option von vLLM. Der Sicherheitsleitfaden von vLLM nennt Routen, die der Schlüssel nicht schützt, und empfiehlt einen Reverse Proxy, der nur die nötigen Endpunkte durchlässt. Abschalten sollten Sie außerdem die Nutzungsstatistik, die vLLM standardmäßig sammelt.

Gemessen: Token pro Sekunde auf dem GEX44

Mit einer Anfrage schreibt das Modell 28,8 Token pro Sekunde, das erste Token kommt nach etwa 54 ms. Zwei gleichzeitige Anfragen laufen mit je 28,3 Token pro Sekunde, zusammen 56,4. Die zweite fährt also fast umsonst mit.

Die Grenze für eine einzelne Antwort setzt die Speicherbandbreite: Für jedes Token liest die Karte fast alle Gewichte einmal, und 280 GB/s reichen für etwa 33 Token pro Sekunde. Lange Prompts kosten nur einmal Zeit: Bei 1.701 Token kam das erste Token nach 1,09 s, beim selben Prompt ein zweites Mal nach 63 ms, weil der Prefix-Cache von vLLM behält, was er schon gelesen hat. Das zählt im Chat, wo jede Nachricht das ganze Gespräch erneut mitschickt.

Was ein Hetzner-GPU-Server kostet

Für ein 14B-Modell in 4 Bit und wenige Nutzer reichen 20 GB, wie unser GEX44 zeigt. Für größere Aufgaben gibt es den GEX131 mit einer NVIDIA RTX PRO 6000 Blackwell: 96 GB VRAM und 1.792 GB/s, für bis zu 1.199 € im Monat plus 599 € Einrichtung. Er reicht für Modelle der 30B-Klasse in 16 Bit, große Mixture-of-Experts-Modelle, mehrere Modelle nebeneinander oder Fine-Tuning. Alle Preise ohne MwSt.

Unser Server steht in Deutschland, die Prompts werden also dort verarbeitet. Was das für den Datenschutz bedeutet, lesen Sie in Eigener KI-Server und DSGVO.

Wenn Sie ein solches Modell auf einem eigenen Server möchten, ohne sich selbst um die Technik zu kümmern, gibt es dafür Private AI. Wir richten einen dedizierten GPU-Server bei Hetzner in Deutschland ein, installieren und passen ein Open-Weight-Modell an, testen es mit Ihren eigenen Fragen und warten die Maschine. Sie bekommen eine private Chat-Oberfläche und eine API, und mit jedem Kunden schließen wir einen Auftragsverarbeitungsvertrag. Das erste Gespräch ist kostenlos.