LOKALE LLM-RUNTIMES - VERGLEICH
Lokale LLM-Runtimes im Vergleich: Ollama, vLLM, llama.cpp, LM Studio, LocalAI, TGI, GPT4All, KoboldCpp, Jan, OpenLLM
Zehn ernsthafte Runtimes für lokal betriebene Sprachmodelle, von Hobby-Desktop bis Production-GPU-Serving. Entscheidungs-Matrix Mai 2026.
Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05
Was ist eine lokale LLM-Runtime?
Eine lokale LLM-Runtime ist die Software-Schicht, die ein Open-Weight-Sprachmodell (Llama, Mistral, Qwen, DeepSeek) auf eigener Hardware lädt, im Speicher hält und Anfragen beantwortet. Ohne diese Schicht liegt das Modell nur als mehrere Gigabyte Gewichtsdateien auf der Platte. Die Runtime verwandelt diese Dateien in einen produktiven Dienst mit HTTP-API, Token-Streaming, Batch-Verarbeitung und Multi-User-Routing.
Im Mai 2026 existieren rund zehn ernsthafte Optionen mit klar unterschiedlichen Profilen. Manche zielen auf Hobby-Desktop und Mac-Notebook (LM Studio, GPT4All, Jan). Manche sind production-grade Server-Lösungen mit Throughput-Optimierung (vLLM, Text Generation Inference, OpenLLM). Manche sitzen dazwischen und decken beide Welten ab (Ollama, LocalAI, KoboldCpp). Und eine - llama.cpp - ist die fundamentale C-Bibliothek, auf der ein Grossteil der anderen aufbaut.
Für Treuhand- und Anwalts-Buros in der Schweiz ist die Wahl der Runtime keine Geschmacksfrage. Sie bestimmt drei harte Faktoren: erstens, ob das Setup auf vorhandenen Servern (CPU-only Hetzner-AX41) überhaupt läuft oder eine GPU braucht. Zweitens, ob die OpenAI-API-Kompatibilität bestehende Tools wie LiteLLM, n8n und LangChain direkt anbinden kann. Drittens, ob die Lösung skaliert, wenn aus zwei Test-Nutzern dreissig produktive Nutzer werden - oder ob ein Wechsel der Runtime ansteht, sobald die ersten Lastspitzen kommen.
Warum die Wahl wichtig ist
Drei harte Achsen entscheiden über die Eignung: Hardware-Profil, Throughput-Bedarf und Integrations-Tiefe. Wer die falsche Runtime einsetzt, bezahlt entweder mit ungenutzter GPU oder mit überlasteten CPU-Servern oder mit einer Code-Migration sechs Monate später.
Hardware-Profil: Ein 7B-Modell wie Llama 3.3 8B oder Phi-4 läuft mit 4-Bit-Quantisierung auf einer modernen CPU mit 16 GB RAM. Genau diese Setups bedient llama.cpp, Ollama, LM Studio. Sobald 70B-Modelle (Llama 3.3 70B, Qwen 2.5 72B) oder Production-Throughput gefragt sind, führt kein Weg an einer GPU mit mindestens 24 GB VRAM vorbei - und damit an vLLM oder Text Generation Inference.
Throughput: Eine Hobby-Runtime wie LM Studio bearbeitet eine Anfrage nach der anderen. Eine Production-Runtime wie vLLM verarbeitet dank Continuous Batching und PagedAttention dutzende parallele Anfragen pro Sekunde auf derselben GPU. Der Unterschied ist nicht 2x, sondern eher 10x bis 20x. Bei einer Kanzlei mit fünfzehn aktiven Mitarbeitern entscheidet dieser Faktor, ob ein Server reicht oder vier gebraucht werden.
Integrations-Tiefe: Wer Ollama, vLLM, LocalAI oder OpenLLM einsetzt, hat eine OpenAI-kompatible API ab Tag eins. Damit funktionieren LiteLLM-Routing, n8n-Knoten und LangChain ohne Anpassung. Eine Hobby-Runtime mit eigener API zwingt zur Adapter-Programmierung - drei bis fünf Tage Mehraufwand, jedes Mal wenn ein Tool dazu kommt.
Die zehn Runtimes im Detail
Ollama (Go, MIT, alle Betriebssysteme): die einfachste Inbetriebnahme im Markt. Ein Befehl, das Modell startet, eine OpenAI-kompatible API ist auf Port 11434 verfügbar. GGUF-Format, automatisches Modell-Management, gut dokumentierte Library mit Llama, Mistral, Qwen, Gemma, Phi. Mai 2026 ist Ollama der De-facto-Standard für lokale LLMs in Treuhand-Setups.
vLLM (Python/CUDA, Apache 2.0, Linux mit GPU): die Production-Antwort auf hohen Throughput. PagedAttention vermeidet den klassischen Speicher-Verschnitt bei langen Kontexten, Continuous Batching steigert GPU-Auslastung von 30% auf über 80%. Für einen Server mit dreissig gleichzeitigen Nutzern ist vLLM bis zu 20x effizienter als Ollama. Nur Linux, nur GPU, kein einfacher Mac-Support.
llama.cpp (C/C++, MIT, alle Plattformen): die Original-Bibliothek. Unter Ollama, LM Studio und KoboldCpp steckt llama.cpp. Sehr portable, läuft auf CPU, CUDA, Metal, ROCm, Vulkan. Wer maximale Kontrolle und minimalen Footprint will, baut direkt darauf - Preis: weniger Komfort, kein Modell-Manager, manuelle Kommandozeile.
LM Studio (Electron, proprietär kostenlos, Desktop): Hobby-Tool mit grafischer Oberfläche. Mac, Windows, Linux. Modelle aus Hugging Face per Klick, Chat-Interface eingebaut, lokaler API-Server für Entwicklung. Gut für Erkundung, Demo, persönliche Nutzung. Nicht für Multi-User-Production gedacht.
LocalAI (Go, MIT, Docker): OpenAI-API-kompatibler Allrounder. Nicht nur LLMs, sondern auch TTS, STT, Vision, Embeddings unter einer einzigen API. Wer mehrere Modalitäten lokal braucht (Sprache-zu-Text für Anwalts-Diktate plus LLM-Zusammenfassung) ist mit LocalAI gut bedient. Etwas mehr Konfigurations-Aufwand als Ollama, dafür breiter.
Text Generation Inference (TGI, Rust+Python, Apache 2.0, Hugging Face): Production-Serving direkt aus dem Hugging-Face-Universum. Tensor-Parallelism, Flash-Attention, Quantisierung. Sehr gute Performance, klare Docs, kompatibel mit allen HF-Modellen. Etwas weniger Community-Schwung als vLLM 2026, aber stabiler bei seltenen Architekturen.
GPT4All (C++, MIT, Nomic AI, Desktop): Hobby-Tool mit Fokus auf Einsteiger. Eingebaute Modell-Liste, Chat-UI, optionaler API-Modus. Ähnlich wie LM Studio im Charakter, etwas weniger Modell-Auswahl, dafür schlanker.
KoboldCpp (C++, AGPLv3, Self-Host): llama.cpp-Fork mit eigener Web-UI, ausgerichtet auf Roleplay und Story-Generation. Für Treuhand wenig relevant, aber starke Community für kreative Anwendungen. AGPL-Lizenz beachten - strenger als MIT.
Jan (Electron, AGPLv3, Desktop): offene Alternative zu LM Studio. Mac, Windows, Linux. Modell-Browser, Chat-UI, lokaler API-Server. Mai 2026 noch jünger als LM Studio, gewinnt aber Boden bei Nutzern, die proprietäre Tools meiden wollen.
OpenLLM (Python, Apache 2.0, BentoML): Production-Self-Host-Lösung mit BentoML-Integration. OpenAI-kompatibel, gut bei Multi-Modell-Setups (verschiedene Modelle auf einem Server). Etwas mehr Komplexität als Ollama, dafür Production-Features wie Health-Checks, Metriken, Batch-API.
Runtime-Auswahl in 6 Schritten
- 01Hardware-Inventar: GPU vorhanden? Wenn ja, VRAM-Grösse? Wenn nein, wie viel RAM in der CPU-Box?
- 02Concurrent-Last schätzen: wie viele parallele Anfragen erwartet? Bis 5 reicht Ollama, ab 10 lohnt vLLM oder TGI.
- 03Modell-Anforderung: 7B Modell reicht (Phi-4, Llama 3.3 8B) oder ein 70B-Modell? 70B braucht GPU mit mindestens 48 GB oder Quantisierung auf 4-Bit + 24 GB.
- 04API-Kompatibilität: brauchen Sie OpenAI-API-Format für LiteLLM, n8n, LangChain? Wenn ja: Ollama, vLLM, LocalAI, TGI, OpenLLM. Hobby-Tools nur für Solo-Use.
- 05Multi-Modalität prüfen: brauchen Sie auch Transkription, TTS, Vision auf derselben Box? Wenn ja: LocalAI.
- 06PoC fahren: zwei Wochenenden, Ollama installieren, ein 8B-Modell laden, fünf typische Mandantenfragen durchspielen. Erst dann produktiv.
Empfehlung je Anwendungsfall
Treuhand-Buro 5-15 Personen, ein Server, gemischte Last: Ollama. Schnell aufgesetzt, OpenAI-API verfügbar, läuft auf einer Workstation mit 24-GB-GPU oder auch CPU-only für kleinere Modelle. Standardwahl in der Schweiz Mai 2026.
Kanzlei 30+ Personen, dedizierter GPU-Server, hohe Concurrent-Last: vLLM. Lohnt sich ab etwa zehn parallelen Anfragen pro Sekunde. Setup-Aufwand ein bis zwei Tage, dann lange stabil. Erfordert Linux und CUDA.
Multi-Modal lokal (LLM + Transkription + TTS) auf einer Box: LocalAI. Anwalts-Diktate über Whisper transkribieren, Llama 3 zusammenfassen, TTS für Mandanten-Rückruf - alles in einem Docker-Container, eine API.
Persönliche Erkundung, Mac-Notebook, kein Server: LM Studio oder Jan. Klick-und-Los, Modelle aus Hugging Face, ideal um die Frage "lohnt sich lokal überhaupt" in einer Stunde zu beantworten.
Maximaler Hardware-Hebel, embedded oder Edge: llama.cpp direkt. Wer Wifi-Router, Industrial-PC oder Apple-Silicon mit maximaler Performance ausreizt, baut auf llama.cpp und verzichtet auf den Komfort-Layer.
Hugging-Face-zentriertes Team, viele exotische Modelle: TGI. Wer ständig neue Architekturen ausprobiert (MoE, Multi-Vision, lange Kontexte), profitiert vom Hugging-Face-Ecosystem.
Production-Plattform mit mehreren Modellen pro Server: OpenLLM. Wenn ein Server gleichzeitig Llama-70B für Mandanten-Chat und Phi-4 für schnelle Triage hosten soll, ist das BentoML-Modell von OpenLLM passender als Ollama.
Wann eine lokale Runtime falsch ist
Wenn Sie keine GPU haben, keinen Server-Admin und nur gelegentliche LLM-Nutzung von zwei bis drei Mitarbeitern, ist eine Cloud-API von Anthropic, OpenAI oder Mistral wirtschaftlicher als die Anschaffung einer 3000-CHF-GPU plus Strom. Faustregel: erst ab etwa 5 Millionen Tokens pro Monat lohnt sich lokal - darunter zahlt sich der Aufwand nicht aus.
Wenn der Use-Case Tagesaktualität braucht (Marktrecherche, Live-Nachrichten, neueste Rechtsprechung) und keine internen Dokumente, ist eine Cloud-API mit Search-Tool oder die Perplexity-API der korrekte Weg - kein lokales Modell löst dieses Problem ohne RAG.
Und: Wenn das Compliance-Argument der einzige Grund für lokal ist, lohnt der Blick auf EU-Hosting (Mistral La Plateforme, Hetzner-deployed Ollama-Instanz). Wer nur "Daten in der EU/CH" braucht und nicht "Daten in unserem eigenen Rack", spart sich den Operations-Aufwand.
Vor- und Nachteile
STÄRKEN
- Vollständige Datenkontrolle - keine externen API-Calls für Mandantendaten
- Keine Token-Kosten nach der Hardware-Investition
- Offline-fähig, kein Internet-Risiko
- OpenAI-kompatibel bei Ollama/vLLM/LocalAI/TGI/OpenLLM - bestehende Tools laufen sofort
SCHWÄCHEN
- GPU-Investition oder leistungsfähige CPU nötig - ab CHF 2000 bis über CHF 20000
- Operations-Aufwand: Updates, Backup, Monitoring, Modell-Wechsel
- Lokale Modelle bleiben (Mai 2026) hinter dem aktuellen Claude-Spitzenmodell / das jeweils aktuelle GPT-Spitzenmodell bei Reasoning zurück
- Lernkurve: zwei bis fünf Tage Setup, plus laufende Wartung
Häufige Fragen
Reicht Ollama für eine 10-Personen-Treuhand?
Ja, in den meisten Fällen. Auf einer Workstation mit RTX 4090 (24 GB VRAM) oder einer Hetzner-GPU-Box GEX44 läuft Ollama mit Llama 3.3 70B in 4-Bit-Quantisierung. Bis etwa 5 parallele Anfragen ist die Latenz akzeptabel (3-8 Sekunden). Bei mehr lohnt der Wechsel zu vLLM, das auf derselben Hardware 4-5x mehr Durchsatz erreicht.
Wie unterscheiden sich Ollama und llama.cpp?
Ollama ist ein Komfort-Layer über llama.cpp. Es liefert Modell-Manager, OpenAI-API-Server, automatische Quantisierung und ein Repository (ollama.com/library) gleich mit. llama.cpp pur ist die C-Bibliothek darunter - schneller und schlanker, aber jeder Modell-Download, jede Quantisierung, jeder API-Server muss selbst verwaltet werden. Für Produktiv-Einsatz: Ollama. Für Embedded oder maximalen Hardware-Hebel: llama.cpp.
Wie viele Tokens pro Sekunde sind realistisch?
Stark abhängig von Modellgrösse und Hardware. Beispiel-Zahlen Mai 2026 für Llama 3.3 8B in 4-Bit-Quantisierung: Apple M3 Max (Metal) über llama.cpp etwa 60-80 Tokens/s einzeln. RTX 4090 über Ollama etwa 100-130 Tokens/s. RTX 4090 über vLLM mit Batching etwa 400-600 Tokens/s aggregiert über alle parallelen Anfragen. Für Llama 3.3 70B in 4-Bit-Quantisierung: RTX 4090 über Ollama etwa 15-22 Tokens/s, vLLM auf zwei A100 mit Tensor-Parallel etwa 90-130 Tokens/s aggregiert.
Welche Runtime unterstützt Llama 4 MoE?
Mai 2026 unterstützen vLLM, Text Generation Inference und Ollama Llama 4 Scout (17B active) produktiv. Llama 4 Maverick (109B active) ist mit Ollama 4-Bit auf einer einzelnen H100 (80 GB) lauffähig, mit vLLM auch verteilt über zwei H100. llama.cpp hat MoE-Support seit Anfang 2026. LM Studio und Jan ziehen nach. KoboldCpp und GPT4All sind hier noch nicht so weit.
Verwandte Themen
Quellen
PASSEND ZU IHREM STACK?