{"id":21281,"date":"2026-10-07T21:48:00","date_gmt":"2026-10-07T19:48:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=21281"},"modified":"2026-10-05T16:49:56","modified_gmt":"2026-10-05T14:49:56","slug":"lokale-llm-software-vergleich-de","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/cloud-ai-de\/lokale-llm-software-vergleich-de\/","title":{"rendered":"Ollama, LM Studio, llama.cpp oder vLLM: Welche Software passt zu lokalen LLMs?"},"content":{"rendered":"

Die Softwarewahl f\u00fcr ein lokales LLM beginnt mit der Aufgabe. Ein privater Desktop-Chat, eine API f\u00fcr ein Skript und ein Dienst f\u00fcr mehrere gleichzeitige Anfragen brauchen unterschiedliche Eigenschaften. Die verbreiteten Produkte sitzen au\u00dferdem auf verschiedenen Ebenen: Oberfl\u00e4che, Modellverwaltung und Inferenz-Engine sind keine austauschbaren Begriffe.<\/p>\n

Der folgende Vergleich ordnet die dokumentierten Funktionen ein. Eigene Geschwindigkeitsmessungen liegen nicht zugrunde. Versionsstand, Modellarchitektur und Hardware bleiben Teil jeder konkreten Auswahl.<\/p>\n

\"Drei
Eine passende Oberfl\u00e4che ersetzt keinen Nachweis des GPU-Backends.<\/figcaption><\/figure>\n

Sechs Wege mit unterschiedlichen Schwerpunkten<\/h2>\n\n\n\n\n\n\n\n\n\n\n
Software<\/th>\nSt\u00e4rke im Einsatz<\/th>\nVor dem Start pr\u00fcfen<\/th>\n<\/tr>\n<\/thead>\n
Ollama<\/td>\nModellverwaltung und lokale API<\/td>\nBackend, Modelltag und Kontext<\/td>\n<\/tr>\n
LM Studio<\/td>\nDesktop-Oberfl\u00e4che und Modellwahl<\/td>\nRuntime, Format und GPU-Auslagerung<\/td>\n<\/tr>\n
llama.cpp<\/td>\nDirekte Kontrolle, GGUF, viele Backends<\/td>\nBuild und unterst\u00fctzte Architektur<\/td>\n<\/tr>\n
MLX LM<\/td>\nApple-Silicon-Ausf\u00fchrung<\/td>\nMLX-Artefakt und Speicherreserve<\/td>\n<\/tr>\n
vLLM<\/td>\nAPI-Serving und Parallelit\u00e4t<\/td>\nOS, GPU und Quantisierungskernel<\/td>\n<\/tr>\n
OpenVINO GenAI<\/td>\nEigener optimierter Inferenzpfad<\/td>\nModellkonvertierung und Zielger\u00e4t<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Desktop und API getrennt ausw\u00e4hlen<\/h2>\n

LM Studio passt zu einem grafischen Einstieg. Ollama eignet sich f\u00fcr einen \u00fcberschaubaren Dienst mit Modellverwaltung und API. Eine zus\u00e4tzliche Chat-Oberfl\u00e4che ver\u00e4ndert die darunterliegende Runtime nicht automatisch. Ein komfortabler Chat ist deshalb kein Beleg f\u00fcr hohe Serverleistung.<\/p>\n

llama.cpp bietet direkten Zugriff auf Modellparameter und Hardware-Backends. Der zus\u00e4tzliche Kontrollbedarf lohnt sich bei reproduzierbaren Konfigurationen oder ungew\u00f6hnlicher Hardware. Der Projektname beschreibt dabei eine Runtime, keine Beschr\u00e4nkung auf die Modellfamilie Llama.<\/p>\n

Das Backend entscheidet \u00fcber Hardware<\/h2>\n

CUDA, Metal, Vulkan, SYCL und XPU sind unterschiedliche Ausf\u00fchrungspfade. Eine NVIDIA-Anleitung l\u00e4sst sich nicht unver\u00e4ndert auf Intel Arc \u00fcbertragen. Ollama dokumentiert zus\u00e4tzliche Vulkan-Unterst\u00fctzung unter Windows und Linux; vorhandener Treiber, installiertes Backend und tats\u00e4chliche Ger\u00e4teerkennung m\u00fcssen zusammenpassen.<\/p>\n

Auf Apple Silicon sind MLX LM sowie geeignete Metal-Pfade naheliegende Kandidaten. Eine MLX-Quantisierung und eine GGUF-Datei sind dennoch verschiedene Artefakte. Ein Backend-Wechsel braucht eine Pr\u00fcfung von Modellrevision, Tokenizer und Chat-Template, sonst erkl\u00e4rt eine ge\u00e4nderte Ausgabe m\u00f6glicherweise nur eine andere Konfiguration.<\/p>\n

vLLM f\u00fcr den passenden Serverfall<\/h2>\n

vLLM richtet den Fokus auf Serving. Die GPU-Installation dokumentiert Linux; unter Windows kommt unter anderem WSL infrage. Native Windows-Bedienbarkeit anderer Produkte ist damit kein gleichwertiger Installationsweg. Eine unterst\u00fctzte GPU garantiert au\u00dferdem nicht jeden Quantisierungskernel.<\/p>\n

F\u00fcr eine Sitzung z\u00e4hlen First-Token-Zeit und fl\u00fcssige Ausgabe. F\u00fcr mehrere Sitzungen kommen Gesamtdurchsatz, Warteschlangen und Antwortlatenzen unter Last hinzu. Ein schneller Einzeltest entscheidet den Mehrbenutzervergleich nicht. SGLang ist ein zus\u00e4tzlicher Serving-Kandidat, dessen aktuelle Modellunterst\u00fctzung separat zu pr\u00fcfen bleibt.<\/p>\n

Ein belastbarer Auswahlweg<\/h2>\n

Zuerst stehen Betriebssystem, vorhandene Hardware und gew\u00fcnschtes Modell fest. Danach folgen ben\u00f6tigte Funktionen: strukturierte Ausgabe, Tool Calling, Bildverarbeitung oder Offline-Nutzung. Schlie\u00dflich wird ein gemeinsames Aufgabenpaket mit dokumentierter Revision, Kontext und Sampling ausgef\u00fchrt.<\/p>\n

Ein kleiner Desktop-Assistent braucht keinen komplexen Serving-Stack allein aus Vorsicht. Ein API-Dienst braucht dagegen nachvollziehbare Startkonfigurationen, Fehlerprotokolle und Lastgrenzen. Der vorhandene Speicherrechner hilft bei der Modellpassung; die endg\u00fcltige Softwarewahl folgt dem nachgewiesenen Backend und dem tats\u00e4chlichen Einsatz.<\/p>\n

Speicherbedarf f\u00fcr die Modellwahl: LLM-VRAM-Rechner.<\/a><\/p>\n

\n

Passende Werkzeuge<\/h2>\n