# 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-server` als 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)](https://wiki.zn80.net/books/ai-llm/page/drei-rechner-ein-modell-llamacpp-rpc-cluster-im-heimnetz) - [Agentic LLM Inference Tuning Reference für Qwen 3.6 und Gemma 4](https://wiki.zn80.net/books/ai-llm/page/agentic-llm-inference-tuning-reference-for-qwen-36-and-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](https://wiki.zn80.net/books/ai-llm/page/lokale-installation-und-betrieb-von-llms-mit-vllm) - [llama.cpp — Installation, Betrieb und Konfiguration](https://wiki.zn80.net/books/ai-llm/page/llamacpp-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 - [Open WebUI — Übersicht und Setup](https://wiki.zn80.net/books/self-hosted-projects/page/open-webui) --- ### 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](https://wiki.zn80.net/books/ai-llm/page/the-ai-coding-loop-verification-driven-development-with-ai-agents) - [OpenCode LLM Benchmarks: IndexNow & Migration Mapping](https://wiki.zn80.net/books/ai-llm/page/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](https://wiki.zn80.net/books/ai-llm/page/llm-performance-hub)*