LLM Hosting in 2026: Local, Self-Hosted und Cloud-Infrastruktur Vergleich
LLM Hosting — Übersicht und Entscheidungshilfe
Large Language Models laufen längst nicht mehr nur in der Cloud. 2026 ist die Frage nicht mehr "Kann ich ein LLM selbst betreiben?" — sondern:
Welche Hosting-Strategie passt zu meinem Workload, meinem Budget und meinen Anforderungen an Kontrolle und Datenschutz?
Diese Seite ist meine persönliche Referenz. Ich dokumentiere hier, was ich tatsächlich betreibe und getestet habe — keine vollständige Marktübersicht, sondern ehrliche Erfahrungswerte aus zwei verschiedenen Kontexten: dem Arbeitsumfeld (Kubernetes-Cluster, Team-Betrieb) und dem Home-Lab (Workstation, Einzelnutzer).
Was LLM Hosting eigentlich bedeutet
LLM Hosting beschreibt, wie und wo Modelle für Inferenz betrieben werden. Diese Entscheidung hat direkte Auswirkungen auf:
- Latenz und Time-to-First-Token
- Durchsatz und Parallelität
- Kosten pro Request
- Datenschutz und Datenhoheit
- Infrastrukturkomplexität
- Operativen Aufwand
LLM Hosting ist keine reine Installationsaufgabe — es ist eine Infrastrukturentscheidung.
Entscheidungsmatrix
| Ansatz | Geeignet für | Hardware | Produktionstauglich | Kontrolle |
|---|---|---|---|---|
| llama.cpp | GGUF-Modelle, CLI + Server, Offline | CPU / GPU | Ja (llama-server) | Sehr hoch |
| vLLM | Hochdurchsatz-Produktion | Dedizierter GPU-Server | Ja | Hoch |
| Jan.ai | Lokale Experimente, Einzelnutzer | Consumer GPU / CPU | Begrenzt | Hoch |
| LM Studio | Lokale Experimente, Parameter-Tuning | Consumer GPU / CPU | Begrenzt | Hoch |
| LiteLLM | Proxy-Layer, Multi-Backend, API-Unified | Keiner (nur Proxy) | Ja | Hoch |
| Open WebUI | Team-Frontend für lokale Modelle | Keiner (nur Frontend) | Ja | Hoch |
Nur noch selten in Benutzung
| Ansatz | Geeignet für | Hardware | Produktionstauglich | Kontrolle |
|---|---|---|---|---|
| Ollama | Schneller Einstieg, minimale Konfiguration | Consumer GPU / CPU | Eingeschränkt | Hoch |
| Cloud-Anbieter | Zero-Ops, Skalierung ohne Hardware | Keiner (remote) | Ja | Gering |
Lokales LLM Hosting
Lokales Hosting bringt:
- Vollständige Kontrolle über Modelle und Parameter
- Keine tokenbasierte Abrechnung
- Vorhersehbare Latenz
- Datenschutz ohne Kompromisse
Die Kehrseite: Hardware-Grenzen, Wartungsaufwand und manuelle Skalierung.
llama.cpp
llama.cpp ist mein primäres Inference-Backend — sowohl auf der Arbeit als auch zu Hause. Es ist eine schlanke C/C++-Engine für GGUF-Modelle mit sehr feingranularer Kontrolle über Speicher, Threads, Kontextgröße und Quantisierung.
Ich nutze llama.cpp wenn:
- Ich maximale Kontrolle über Inference-Parameter brauche
- Das Deployment offline oder ohne Python-Stack laufen muss
llama-serverals OpenAI-kompatibler Endpunkt gefragt ist- Ich GGUF-Modelle direkt aus dem Hub laden will
Arbeit: llama.cpp-Instanzen laufen als Kubernetes-Pods, je ein Modell pro Quadro-RTX-6000-Ada-GPU (24 GB VRAM), hinter LiteLLM als einheitlichem API-Proxy.
Zuhause: llama.cpp direkt auf der RTX 5070 (12 GB VRAM), meistens als Backend für Jan.ai oder OpenCode.
- llama.cpp RPC Multi-GPU Setup Guide (Windows 11 & Linux Distributed Cluster)
- Agentic LLM Inference Tuning Reference für Qwen 3.6 und Gemma 4
- llama-server Konfiguration und Slot-Management — in Vorbereitung
- llama.cpp unter Kubernetes: Deployment-Muster und Fallstricke — in Vorbereitung
LiteLLM
LiteLLM ist kein Inference-Backend — sondern der Proxy-Layer davor. Ein einheitlicher OpenAI-kompatibler Endpunkt, der Requests an verschiedene Backends weiterleitet: llama.cpp-Instanzen, vLLM, externe Cloud-APIs. LiteLLM habe ich hauptsächlich im Arbeitsumfeld im Einsatz. Private nur eine Instanz für Tests und Updates.
Ich nutze LiteLLM wenn:
- Mehrere Modelle und Backends hinter einer einzigen API-URL liegen sollen
- Load-Balancing zwischen mehreren llama.cpp-Instanzen gefragt ist
- Nutzungsstatistiken und API-Key-Management zentral verwaltet werden sollen
- Clients (Open WebUI, Coding-Tools, Skripte) nichts vom Backend-Wechsel mitbekommen sollen
- LiteLLM als Proxy vor llama.cpp: Setup und Konfiguration — in Vorbereitung
- API-Usage-Tracking mit LiteLLM und Open WebUI — in Vorbereitung
vLLM
vLLM ist auf Hochdurchsatz-Inferenz ausgelegt — PagedAttention, kontinuierliches Batching, tensor-paralleles Sharding. Ich habe vLLM installiert und getestet, betreibe es aber nicht produktiv, weil llama.cpp + LiteLLM für mein Workload-Profil ausreichend ist.
Interessant wird vLLM wenn:
- Viele parallele Requests gleichzeitig bedient werden müssen
- Durchsatz wichtiger ist als einfache Konfiguration
- Hugging-Face-Modelle (Safetensors) direkt geladen werden sollen
- Lokale Installation und Betrieb von LLMs mit vLLM
- llama.cpp — Installation, Betrieb und Konfiguration
- vLLM vs. llama.cpp: Wann lohnt sich der Wechsel? — in Vorbereitung
Jan.ai
Jan.ai ist mein primäres lokales Frontend zu Hause — eine plattformübergreifende App mit eingebautem llama.cpp-Backend, experimenteller MLX-Unterstütung, übersichtlicher Modellverwaltung mit Zugriff auf Huggingface und direktem Zugang zu Inference-Parametern. Gut geeignet für Experimente, lokale Assistenten mit MCP-Server Unterstützung, Rollenspiel-Prompts (nicht so gut wie SillyTavern) und Modellvergleiche im interaktiven Betrieb.
Ich nutze Jan.ai wenn:
-
Ich schnell verschiedene Modelle ausprobieren will ohne CLI
-
Parameter wie Temperature, Top-P oder Repeat-Penalty direkt anpassen will
-
Eine lokale GUI ohne Cloud-Abhängigkeit gefragt ist
-
Jan.ai: Setup, Modellverwaltung und Parameter-Tuning — in Vorbereitung
-
Jan.ai vs. LM Studio: Vergleich aus der Praxis — in Vorbereitung
LM Studio
LM Studio ist eine Alternative zu Jan.ai mit ähnlichem Ansatz: lokale GUI, eingebettetes llama.cpp-Backend, OpenAI-kompatibler lokaler Server. Etwas stärker auf Entwickler-Workflows ausgerichtet, mit besserem Prompt-Template-Editor.
Ich nutze LM Studio wenn:
- Der eingebaute lokale Server als API-Endpunkt für andere Tools gefragt ist
- Ich Prompt-Templates für verschiedene Modellformate pflegen will
- Ich Modelle aus Hugging Face direkt in der App suchen und laden will
Weiterführende Links
- LM Studio als lokaler API-Server für OpenCode und andere Clients — in Vorbereitung
Open WebUI
Open WebUI ist das Team-Frontend im Arbeitsumfeld — eine ChatGPT-ähnliche Web-Oberfläche, die hinter LiteLLM auf die llama.cpp-Instanzen zugreift. Kollegen brauchen nichts zu installieren; sie öffnen den Browser.
Ich nutze Open WebUI wenn:
- Mehrere Nutzer Zugang zu den lokalen Modellen brauchen
- Ein benutzerfreundliches Frontend ohne technische Hürden gefragt ist
- RAG, Bildupload und Gesprächsverwaltung zentral verwaltet werden sollen
Weiterführende Links
OpenCode
OpenCode ist mein KI-gestütztes Coding-Werkzeug — ein CLI-Agent, der llama.cpp als Backend nutzt und direkt in den Entwicklungsworkflow integriert ist. Kein Frontend, kein Chat — sondern Codeanalyse, Refactoring und Aufgabenausführung im Terminal.
- The AI Coding Loop: Verification-Driven Development with AI Agents
- OpenCode LLM Benchmarks: IndexNow & Migration Mapping
- OpenCode mit lokalem llama.cpp-Backend: Konfiguration und Modellwahl — in Vorbereitung
Ollama
Ollama habe ich getestet, betreibe ich aber nicht aktiv. Es ist der einfachste Einstieg in lokale LLMs — gute CLI, automatisches Modell-Pulling, minimale Konfiguration. Die Einschränkungen beim Scheduling und die begrenzte Kontrolle über Inference-Parameter haben mich zu llama.cpp geführt.
Ollama macht Sinn wenn:
- Der schnellste Weg zu einem laufenden Modell gefragt ist
- Kein Interesse an Parameter-Tuning besteht
- Ein einzelner Nutzer lokal experimentiert
Weiterführende Links
- Warum ich von Ollama zu llama.cpp gewechselt habe — in Vorbereitung
Cloud LLM Hosting
Cloud-Anbieter abstrahieren die Hardware vollständig. Ich nutze Cloud-APIs punktuell — vor allem für Modelle, die lokal nicht sinnvoll betreibbar sind (frontier-Modelle wie Claude oder GPT-4-class).
Vorteile:
- Sofortige Skalierbarkeit
- Kein Hardware-Investment
- Keine Wartung
Nachteile:
- Laufende Kosten pro Token
- Daten verlassen die eigene Infrastruktur
- Vendor-Abhängigkeit
Weiterführende Links
- Cloud-APIs sinnvoll einsetzen: wann lokales Hosting nicht reicht — in Vorbereitung
Frontends & Oberflächen
Das Hosting-Backend ist nur ein Teil des Systems. Welches Frontend Nutzer sehen, beeinflusst die Akzeptanz erheblich.
| Frontend | Kontext | Typ |
|---|---|---|
| Open WebUI | Arbeit, Team | Web-App |
| Jan.ai | Zuhause, Einzelnutzer | Desktop-App |
| LM Studio | Zuhause, Entwicklung | Desktop-App |
| OpenCode | Zuhause, Terminal | CLI-Agent |
Kosten und Kontrollvergleich
| Faktor | Lokal | Cloud |
|---|---|---|
| Anschaffungskosten | Hardware | Keine |
| Laufende Kosten | Strom | Token-Abrechnung |
| Datenschutz | Vollständig | Eingeschränkt |
| Skalierung | Manuell | Automatisch |
| Wartung | Selbst | Anbieter |
| Modellkontrolle | Vollständig | Eingeschränkt |
Wann welcher Ansatz?
llama.cpp wenn maximale Kontrolle und GGUF-Modelle gefragt sind — sowohl für Einzelnutzer als auch im Kubernetes-Cluster.
LiteLLM sobald mehrere Backends oder mehrere Nutzer hinter einer einheitlichen API zusammengefasst werden sollen.
vLLM wenn llama.cpp unter Parallellast zum Engpass wird und Durchsatz Priorität hat.
Jan.ai oder LM Studio für lokale Experimente mit GUI, ohne CLI-Aufwand.
OpenCode wenn KI direkt in den Coding-Workflow integriert werden soll.
Open WebUI wenn Kollegen ohne technisches Setup Zugang zu lokalen Modellen brauchen.
Cloud wenn frontier-Modelle gefragt sind oder lokale Hardware nicht ausreicht.
Häufige Fragen
Was ist der einfachste Einstieg in lokale LLMs? Ollama — minimale Konfiguration, sofort lauffähig. Wer mehr Kontrolle braucht, wechselt zu llama.cpp.
Ist Self-Hosting günstiger als Cloud-APIs? Bei hohem, gleichmäßigem Volumen oft ja — sobald die Hardware amortisiert ist. Bei sporadischer Nutzung rechnet sich Cloud meistens besser.
Kann man LLMs ohne GPU betreiben? Ja, aber die Inferenzgeschwindigkeit ist erheblich eingeschränkt. Für produktiven Betrieb ist eine dedizierte GPU praktisch Pflicht.
Welches Frontend empfehle ich für ein Team? Open WebUI — es braucht keine lokale Installation auf den Client-Rechnern und lässt sich gut hinter einen Reverse-Proxy stellen.
Zur Performance und Optimierung der Inference-Backends: LLM Performance Hub