Local LLMs auf dem kleinen Server: die Alternativen

Das Spektrum jenseits eines Tools

OpenClaw ist eine Option für selbst gehostete Inferenz, aber nicht die einzige. Das Local-LLM-Ökosystem ist schnell gewachsen, und mehrere Werkzeuge lösen dieselbe Aufgabe mit unterschiedlichen Kompromissen. Welches passt, hängt stark von Ihrer Hardware, Ihrem Anwendungsfall und dem operativen Overhead ab, den Sie zu akzeptieren bereit sind.

Dieser Artikel behandelt die wichtigsten Alternativen, ihre Stärken und Schwächen und wie man sie auf einem kleinen oder begrenzten Server sinnvoll betreibt – einem VPS, einem kleinen Colocation-Server oder umgenutzter Büro-Hardware.

Die wichtigsten Kandidaten

Ollama

Ollama ist derzeit wohl die am weitesten verbreitete Option für lokale Inferenz. Es kapselt llama.cpp in einen sauberen Daemon mit REST-API und CLI, übernimmt Modell-Downloads und verwaltet die VRAM-/RAM-Zuteilung automatisch.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3:8b
ollama serve

Die API ist OpenAI-kompatibel, daher funktioniert jeder Client, der mit der OpenAI-API spricht, mit minimalen Anpassungen auch mit Ollama. Es läuft unter Linux, macOS und Windows.

Stärken: Einfache Einrichtung, automatische GPU-Erkennung, breite Modellunterstützung, aktive Community.

Schwächen: Begrenzte Konfigurationstiefe, keine integrierte Mehrbenutzer-Zugriffssteuerung, nicht für Produktions-Workloads mit hoher Concurrency ausgelegt.

llama.cpp

llama.cpp ist die Inferenz-Engine, auf der die meisten anderen Werkzeuge aufbauen. Der direkte Betrieb gibt Ihnen mehr Kontrolle bei weniger Overhead.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

Starten Sie den HTTP-Server:

./build/bin/llama-server   --model /models/llama3-8b.Q4_K_M.gguf   --host 0.0.0.0   --port 8080   --ctx-size 4096   --n-gpu-layers 99

Stärken: Minimale Abhängigkeiten, maximale Kontrolle, geringster Speicherbedarf, läuft bei Bedarf komplett auf der CPU.

Schwächen: Kein Modell-Management, keine API-Key-Unterstützung ab Werk, manuelle Einrichtung erforderlich.

LocalAI

LocalAI zielt darauf ab, ein Drop-in-Ersatz für die OpenAI-API über mehrere Backends hinweg zu sein (llama.cpp, whisper, stable-diffusion und mehr). Es ist die richtige Wahl, wenn Sie von einem einzigen Endpoint mehr als nur Text-Inferenz brauchen.

docker run -p 8080:8080   -v /models:/build/models   localai/localai:latest

Stärken: Multimodal (Text, Sprache, Bild), volle OpenAI-API-Kompatibilität, Docker-nativ.

Schwächen: Höherer Overhead als ein nackter llama.cpp-Prozess, mehr Komponenten, die gewartet werden müssen.

vLLM

vLLM ist auf Durchsatz ausgelegt. Es nutzt PagedAttention, um viele Anfragen gleichzeitig mit deutlich höherer Effizienz zu bedienen als Standard-Inferenz. Wenn Sie einen Dienst bauen, den viele Nutzer oder Prozesse gleichzeitig aufrufen, ist vLLM das richtige Fundament.

pip install vllm
python -m vllm.entrypoints.openai.api_server   --model meta-llama/Llama-3-8B-Instruct   --host 0.0.0.0   --port 8000

Stärken: Beste Concurrency-Performance, OpenAI-kompatibel, unterstützt Tensor-Parallelität über mehrere GPUs.

Schwächen: Braucht mehr VRAM als llama.cpp, Python-Abhängigkeitsstack, überdimensioniert für Single-User-Setups.

Betrieb auf einem kleinen Server: Was tatsächlich funktioniert

Nicht jeder hat einen Server mit 24 GB VRAM. Das realistische Small-Server-Szenario ist eines der folgenden:

–Ein VPS ohne GPU (4–16 GB RAM)
–Ein kleiner Colocation-Server mit einer älteren GPU (6–8 GB VRAM)
–Umgenutzte Desktop-Hardware mit einer Consumer-GPU der Mittelklasse

Was in jedem Fall tatsächlich geht.

Nur-CPU-VPS (ohne GPU)

CPU-Inferenz ist langsam, aber funktional für Use Cases mit wenig Traffic: ein privater Assistent, ein Summarization-Endpoint, der ein paarmal täglich aufgerufen wird, oder eine Entwicklungs-API.

Verwenden Sie llama.cpp oder Ollama mit quantisierten Modellen. Entscheidend ist die Wahl des richtigen Quantisierungslevels:

|-----------|-------------|------------|-------------------|

| 7B | Q4_K_M | ~5 GB | ~5–10 tokens/sec |

| 7B | Q2_K | ~3 GB | ~7–12 tokens/sec |

| 13B | Q4_K_M | ~9 GB | ~3–6 tokens/sec |

Für einen Nur-CPU-VPS ist ein 7B-Modell mit Q4_K_M-Quantisierung der praktische Sweet Spot. Größere Modelle werden für den interaktiven Einsatz unbrauchbar langsam.

Aktivieren Sie alle verfügbaren Kerne:

ollama serve &
OLLAMA_NUM_PARALLEL=1 OLLAMA_MAX_LOADED_MODELS=1 ollama run llama3:8b

Oder mit llama.cpp:

./llama-server --model llama3-8b.Q4_K_M.gguf   --threads $(nproc)   --ctx-size 2048   --n-gpu-layers 0

Kleine GPU (6–8 GB VRAM)

Eine RTX 3060 (12 GB), RTX 4060 (8 GB) oder eine ältere GTX 1080 (8 GB) eröffnet GPU-Inferenz, die bei den meisten Modellen 5–10x schneller ist als die CPU.

Bringen Sie das Modell in den VRAM, indem Sie die Anzahl der GPU-Layer justieren. Passt das Modell nicht vollständig hinein, lagert llama.cpp den Rest an die CPU aus (hybride Inferenz):

# Try full GPU offload first
./llama-server --model llama3-8b.Q4_K_M.gguf   --n-gpu-layers 99   --ctx-size 4096

# If VRAM is tight, reduce layers
./llama-server --model llama3-8b.Q4_K_M.gguf   --n-gpu-layers 20   --ctx-size 2048

Ollama erledigt das automatisch und gibt aus, wie viele Layer ausgelagert wurden:

ollama run llama3:8b
# Output includes: "loaded X layers on GPU"

Für 6–8 GB VRAM, praktische Modellwahl:

–Llama 3 8B Q4_K_M (~5 GB VRAM) – gutes Allround-Modell, passt problemlos
–Mistral 7B Q4_K_M (~5 GB VRAM) – starkes Instruction Following
–Gemma 2 9B Q4_K_M (~6 GB VRAM) – hervorragendes Verhältnis von Qualität zu Größe
–Qwen2.5 7B Q4_K_M (~5 GB VRAM) – stark bei Code und strukturierten Aufgaben

Sicherer Betrieb

Unabhängig vom Tool gilt dieselbe Härtung wie bei jedem internen Dienst:

–Nur an localhost oder ein VPN-Interface binden, niemals 0.0.0.0 auf einer öffentlich erreichbaren IP ohne Authentifizierung
–Einen Reverse Proxy (nginx oder Caddy) mit TLS und Basic Auth oder mTLS vorschalten
–Den Inferenz-Endpoint rate-limiten, um versehentliche oder absichtliche Ressourcen-Erschöpfung zu verhindern

Eine minimale Caddy-Konfiguration:

ai.internal.example.com {
    basicauth {
        user $2a$14$...
    }
    reverse_proxy localhost:11434
}

Das richtige Tool wählen

| Szenario | Empfohlenes Tool |

|---------|-----------------|

| Persönlicher Assistent, einfache Einrichtung | Ollama |

| Wenig RAM, maximale Kontrolle | llama.cpp direkt |

| Multimodal (Text + Sprache + Bild) | LocalAI |

| Hohe Concurrency, Team-Nutzung | vLLM |

| Eingebettet in Python-Anwendung | llama-cpp-python |

Fazit

Das Ökosystem für selbst gehostete Inferenz ist so weit gereift, dass Sie keine Spezialhardware und keine komplexe Infrastruktur mehr brauchen, um ein nützliches lokales Modell zu betreiben. Ein bescheidener Server mit 8–16 GB RAM verkraftet CPU-Inferenz für Workloads mit wenig Traffic. Eine Consumer-GPU der letzten beiden Generationen deckt die meisten Use Cases auf Team-Niveau ab.

Die Wahl des Tools zählt weniger als die Wahl des Modells und des Quantisierungslevels. Beginnen Sie mit Ollama wegen der leichten Bedienung und wechseln Sie zu llama.cpp, wenn Sie mehr Kontrolle oder weniger Overhead brauchen.

Wenn Sie Local Inference in Ihrer Umgebung aufsetzen wollen oder Hilfe bei der Auswahl der passenden Hardware brauchen – melden Sie sich.