LLMs lokal betreiben — Hardware, Tools, Modelle

Redaktion · 2. Mai 2026

Warum lokale LLMs überhaupt — und für wen

Cloud-APIs sind bequem, aber sie haben drei Schwachstellen, die für viele Setups zum Showstopper werden: Daten verlassen das Haus, jede Anfrage kostet, und ohne Internet steht nichts mehr. Wer regelmäßig mit vertraulichen Mandanten-Dokumenten arbeitet, eine eigene Coding-Assistenz mit zigtausend Anfragen pro Monat braucht oder schlicht offline produktiv bleiben will, kommt am lokalen Betrieb nicht vorbei.

Der Einstieg ist 2026 deutlich entspannter als noch zwei Jahre zuvor. Eine Mittelklasse-GPU mit 16 GB VRAM lässt sich für unter 1.000 € in einen halbwegs aktuellen Rechner einbauen, und die offenen Modelle haben in vielen Aufgaben mit den proprietären Frontier-Modellen aufgeschlossen — Qwen 3.5 27B erreicht laut Onyx-Leaderboard auf SWE-Bench Verified 72,4 % und passt auf eine 16-GB-GPU. Was lokal geht und was nicht, hängt aber an drei Größen: VRAM, Quantisierung, Modellgröße. Diese drei zu verstehen ist die halbe Miete.

Die Grundmechanik: VRAM, Quantisierung, Modellgröße

Sprachmodelle bestehen aus Milliarden Parametern (Gewichten). Damit das Modell rechnen kann, müssen alle Parameter in den schnellen Speicher der Grafikkarte (VRAM). Reicht das VRAM nicht, lagert das System auf RAM oder SSD aus — und die Inferenz wird zäh bis unbenutzbar. Eine ehrliche VRAM-Berechnung schlägt jedes Marketing-Versprechen.

Quantisierung — der wichtigste Hebel

Modelle werden ursprünglich in FP16 (16 Bit pro Parameter, 2 Byte) trainiert. Für den Betrieb lassen sie sich in niedrigere Präzisionen umrechnen — die Quantisierung. Üblich sind:

Q8 (8 Bit, 1 Byte/Param) — minimaler Qualitätsverlust, halber Speicherbedarf gegenüber FP16
Q5_K_M (~0,7 Byte/Param) — leichter, kaum spürbarer Qualitätsverlust
Q4_K_M (~0,55 Byte/Param) — Standard für lokale Setups, gutes Preis-Leistungs-Verhältnis
Q3 / Q2 — nur bei extremem Speicherdruck; die Qualität fällt sichtbar

Faustregel: VRAM (GB) ≈ Parameter (Mrd.) × Bytes/Param × 1,2 (der 20-%-Aufschlag deckt KV-Cache und Aktivierungen). Ein 8B-Modell in Q4_K_M braucht also rund 8 × 0,55 × 1,2 ≈ 5,3 GB. Ein 70B-Modell in Q4_K_M kommt auf rund 40 GB — das passt nur noch auf zwei 24-GB-Karten oder eine professionelle A100/H100.

Kontextfenster frisst zusätzlich VRAM

Was viele übersehen: Auch der gefüllte Kontext belegt Speicher. Für ein 8B-Modell kosten 32k Tokens Kontext schnell ein bis zwei zusätzliche GB. Wer mit großen Dokumenten arbeitet, sollte VRAM-Budget für den KV-Cache einplanen — sonst läuft der schöne 128k-Kontext nur auf dem Papier.

VRAM-Tabelle: Was passt auf welche GPU?

Realistische Empfehlungen auf Basis von Q4_K_M (Standard) und Q5_K_M (etwas mehr Qualität):

| VRAM | Q4_K_M passt | Q5_K_M passt | Einsatz | |---|---|---|---| | 8 GB | 7B–8B (Llama 3.1 8B, Qwen 3 8B, Mistral 7B) | 7B knapp | Chat, Klassifikation, Coding-Hilfe | | 12 GB | 8B komfortabel, 13B möglich | 8B | Chat + größerer Kontext, einfache Agents | | 16 GB | bis 27B (Gemma, Qwen) | bis 14B | Coding-Modelle, RAG mit größerem Kontext | | 24 GB | bis 32B–34B | bis 22B | Anspruchsvolle Aufgaben, längere Kontexte | | 48 GB | bis 70B | bis 48B | 70B-Klasse als Daily Driver | | 2× 24 GB | 70B | 70B knapp | Tensor-Parallelism (vLLM) |

Werte als Orientierung, der genaue Bedarf hängt vom Modell-Architektur-Detail (Attention-Heads, KV-Heads bei GQA) und von Kontextlänge ab. Für eine modellgenaue Rechnung gibt es Tools wie den VRAM-Calculator von apxml.

MoE-Modelle: weniger aktive Parameter, aber voller Speicher

Eine Falle: Mixture-of-Experts-Modelle wie Qwen3.5 (122B total / 10B aktiv) oder Mistral Large 3 (675B total / 41B aktiv) brauchen den vollen Speicher für alle Parameter, auch wenn pro Token nur ein Bruchteil aktiv ist. Das macht sie schnell, aber nicht klein. Für Consumer-GPUs eignen sich Dense-Modelle in der 7B–34B-Range fast immer besser.

Tool-Landschaft: Was läuft wo

Vier Tools dominieren das Feld. Sie überlappen, lösen aber unterschiedliche Probleme.

Ollama — der Standard für Entwickler

Ollama ist das mit Abstand am weitesten verbreitete Tool. Ein-Zeilen-Installation, ein Befehl pro Modell, automatisches GPU-Offloading, eine OpenAI-kompatible HTTP-API — das reicht für die meisten Workflows. Es läuft als Hintergrunddienst und liefert Modelle für Coding-Assistenten, RAG-Pipelines und Eigenbau-Tools. Unter der Haube nutzt Ollama llama.cpp.

Schwäche: Bei vielen gleichzeitigen Anfragen skaliert Ollama nicht — pro Anfrage wird sequenziell verarbeitet. Für Single-User oder kleine Teams ist das egal, für eine produktive Multi-User-Instanz nicht.

LM Studio — die GUI für Nicht-Entwickler

LM Studio ist eine Desktop-App mit Modell-Browser, Chat-Interface und integriertem API-Server. Wer eine Demo vor Kollegen aufsetzen will oder Modelle vergleichen muss, kommt mit LM Studio ohne Terminal aus. Auch ein guter Einstieg für jemanden, der erstmal nur sehen will, was lokale LLMs leisten.

Schwäche: Closed Source und etwas weniger flexibel beim Tuning als llama.cpp direkt.

llama.cpp — die Engine

llama.cpp ist die C++-Inferenz-Bibliothek von Georgi Gerganov, auf der praktisch jedes andere lokale Tool aufbaut. Wer maximale Tokens pro Sekunde herausholen will, GGUF-Modelle direkt vom Hugging-Face-Hub fahren oder eigene Server-Setups bauen möchte, arbeitet direkt mit llama.cpp. Höhere Lernkurve, aber maximale Kontrolle.

vLLM — der Throughput-Server

vLLM ist die Wahl, wenn mehrere Nutzer gleichzeitig auf dasselbe Modell zugreifen. Durch PagedAttention und Continuous Batching erreicht vLLM unter Last ein Vielfaches der Ollama-Throughput-Werte — Benchmarks zeigen bis zu 16× mehr Tokens/s bei 5+ parallelen Nutzern. Der Preis: vLLM braucht NVIDIA-GPUs (CUDA), ist deutlich anspruchsvoller im Setup, und für einen einzelnen Nutzer ist der Vorteil vernachlässigbar.

Open WebUI — das Chat-Frontend

Open WebUI ist kein Inferenz-Tool, sondern ein ChatGPT-ähnliches Web-Interface, das sich an Ollama oder einen OpenAI-kompatiblen Endpoint hängt. Multi-User-Login, Prompt-Bibliothek, Datei-Uploads, RAG. Praktisch, wenn die ganze Familie oder das Team auf einer lokalen Instanz mitlesen soll.

| Tool | Zielgruppe | Stärke | Schwäche | |---|---|---|---| | Ollama | Entwickler, Single-User | einfach, OpenAI-API | sequenzielle Anfragen | | LM Studio | Einsteiger, Nicht-Entwickler | GUI, Modell-Browser | closed source | | llama.cpp | Power-User | maximale Kontrolle, schnell | Lernkurve | | vLLM | Multi-User-Produktivbetrieb | Throughput, Batching | NVIDIA-only, komplex | | Open WebUI | Frontend-Bedarf | hübsche Chat-UI, RAG | rein UI, braucht Backend |

Formate: GGUF vs. Safetensors

Zwei Formate dominieren — und sie zielen auf unterschiedliche Use-Cases.

GGUF (GPT-Generated Unified Format) ist das Format der llama.cpp-Welt. Eine einzige Datei pro Modell, enthält Gewichte, Tokenizer und Metadaten. Quantisierungen sind direkt im Format (Q4_K_M, Q5_K_M, Q8_0). Wer Ollama, LM Studio oder llama.cpp nutzt, lädt GGUF.

Safetensors ist das Standard-Format der Hugging-Face-Welt — sicher (kein Pickle-Risiko), schnell zu laden, FP16/BF16 oder bereits AWQ/GPTQ-quantisiert. vLLM, Transformers und die meisten Trainings-Pipelines arbeiten damit. Für reine Inferenz auf Consumer-Hardware ist GGUF meist der entspanntere Weg, für produktive Multi-User-Setups Safetensors.

Modell-Empfehlungen nach VRAM-Klasse (Mai 2026)

Konkrete Auswahl, die wir für die jeweilige GPU-Klasse als Daily Driver empfehlen — alle in Q4_K_M, sofern nicht anders vermerkt.

8 GB VRAM

Llama 3.1 8B oder Qwen 3 8B für allgemeines Chatten und Klassifikation. Mistral 7B als kompakte Alternative. Für Deutsch lohnt der Blick auf SauerkrautLM-Varianten, die explizit auf deutsche Daten nachtrainiert wurden.

16 GB VRAM

Hier wird es interessant: Qwen 3.5 27B in Q4_K_M passt knapp und liefert für seine Größe extrem starke Coding-Ergebnisse. Alternativ Gemma 4 (effizient, schnell) oder DeepSeek-Coder 16B für reines Programmieren.

24 GB VRAM

Die Sweetspot-Klasse. Qwen 3.5 32B oder DeepSeek V3.2-Exp (in der kleineren Variante) sind hier zuhause. Längere Kontexte (16k–32k) laufen ohne Akrobatik. Wer Reasoning-Aufgaben löst, schaut auf DeepSeek R1 oder Qwen-Reasoning-Varianten.

48 GB+ VRAM

70B-Klasse als Daily Driver. Llama 3.3 70B oder die jeweilige Llama-4-Variante in Q4_K_M (~40 GB) lassen noch Luft für ordentlichen Kontext. Auf zwei 24-GB-Karten mit vLLM und Tensor-Parallelism funktioniert das ebenfalls — und ist günstiger als eine einzelne A6000.

Stolperfallen

Ein paar Sachen, die in der Praxis fast immer zuschlagen.

Quantisierungs-Verluste sind nicht linear

Q5 zu Q4 fühlt sich oft kaum anders an. Q4 zu Q3 dagegen wird sichtbar — Halluzinationen häufen sich, Logik-Aufgaben kippen. Q2 ist außer für Spielzwecke nicht zu empfehlen. Bei wichtigen Tasks lieber ein kleineres Modell in Q5 als ein großes in Q3.

CPU-Inferenz ist langsam, aber nicht unbenutzbar

Wer keine GPU hat, kann llama.cpp im CPU-Modus fahren. Ein 8B-Modell läuft auf einer modernen CPU bei 5–10 Tokens/s — okay zum Tippen, nicht für Streaming-Chat. Apple-Silicon-Macs mit Unified Memory sind hier die Ausnahme: ein M3 Max mit 64 GB schlägt jede 16-GB-Consumer-GPU bei großen Modellen, weil RAM und VRAM dieselbe physische Adresse haben.

Erste Generation läuft heißer als gedacht

Eine 24-GB-Karte unter Volllast zieht 350–450 W und produziert entsprechend Lärm und Wärme. Wer die Workstation im Wohnzimmer stehen hat, sollte vorher messen — oder einen separaten Inferenz-Rechner auf einem alten Server-Mainboard aufsetzen.

Die OpenAI-API ist nicht ganz die OpenAI-API

Ollama, LM Studio und vLLM sprechen alle „OpenAI-kompatibel” — aber jeweils nur eine Teilmenge. Strukturierter Output, Function Calling, Streaming-Details und Tool-Use-Semantik weichen ab. Wer Code von der Cloud auf lokal portiert, sollte die Endpoints einmal Punkt für Punkt durchtesten.

Modell-Updates können brechen

Ein Update von Ollama oder ein neues Modell-Build kann Verhalten ändern (anderer Tokenizer, andere Default-Templates). Für produktive Setups Modell-Versionen pinnen und Templates explizit setzen, nicht auf Defaults verlassen.

Drei typische Setups

Setup A: Solo-Entwickler mit Coding-Fokus

Hardware: RTX 4080 oder 4090 (16/24 GB). Tool: Ollama plus Open WebUI als Chat-Oberfläche. Modelle: Qwen 3.5 27B oder 32B in Q4_K_M für Coding, ein kleines 7B-Modell für schnelle Klassifikations-Tasks. Anbindung an die IDE über die OpenAI-API von Ollama. Kosten: einmalig ~1.500–2.500 € für die GPU.

Setup B: Datenschutz-strikte Kanzlei oder Praxis

Hardware: Workstation mit 48 GB VRAM (eine A6000 oder zwei 4090 mit Tensor-Parallelism). Tool: vLLM als Server, Open WebUI als Frontend mit Multi-User-Login. Modell: Llama 3.3 70B oder eine deutsche SauerkrautLM-70B-Variante in Q4_K_M. Daten verlassen das Haus nicht, alle Mandanten-Dokumente bleiben lokal. Kosten: 5.000–10.000 € einmalig statt monatlich Cloud-Gebühren.

Setup C: Familien-Server für Offline-Zugriff

Hardware: gebrauchter Mini-PC oder Mac mini mit 32 GB Unified Memory. Tool: LM Studio mit Server-Modus oder Ollama, Open WebUI für die Familie. Modell: Llama 3.1 8B oder Gemma 4 — reicht für Hausaufgabenhilfe, Übersetzungen, Rezepte. Kein Mandantengeheimnis, aber auch keine US-Server, die das Familienleben mitlesen.

Fazit

Lokale LLMs sind 2026 ein realistisches Werkzeug, kein Bastelprojekt mehr. Wer 8–16 GB VRAM hat, bekommt mit Ollama und einem 7B/27B-Modell ein System, das die meisten Cloud-Anfragen ersetzt — bei null Token-Kosten und voller Datenkontrolle. Für Multi-User-Szenarien führt der Weg über vLLM und 48+ GB VRAM, dann aber mit echtem Throughput-Vorteil.

Die wichtigste Faustregel bleibt: lieber ein kleineres Modell in höherer Präzision als ein zu großes mit aggressiver Quantisierung. Und beim Hardware-Kauf nicht den KV-Cache vergessen — die nominal passende GPU reicht oft nicht, sobald 32k Kontext gefüllt sind. Wer sauber dimensioniert, hat ein lokales Setup, das jahrelang trägt.

Entdecke mehr

Blog

Themenuebersicht

KI-Konzepte Lokales LLM (Konzepte)KI-Werkzeuge Lokales LLM