KI-Modelle lokal betreiben: Hardware, Quantisierung, Werkzeuge
Open-weight-Modelle muss man nicht in der Cloud nutzen – viele laufen erstaunlich gut auf dem eigenen Rechner. Diese Seite klärt die zwei Fragen, an denen es meist hakt: Reicht meine Hardware? Und welches Werkzeug nehme ich? Die Zahlen sind Faustregeln; der reale Bedarf hängt von Modell, Quantisierung und Kontextlänge ab.
3 Min. Lesezeit
6 Abschnitte
7 Quellen
Stand: 16. Juni 2026
Warum überhaupt lokal?
Lokal punktet vor allem dort, wo nicht der Preis, sondern die Kontrolle zählt: Datenschutz und Datenresidenz (kein Datenabfluss an externe APIs), Offline- oder Air-Gap-Betrieb, konstant niedrige Latenz und Unabhängigkeit von einem einzelnen Anbieter. Voraussetzung ist ein open-weightModell, dessen trainierte Gewichte öffentlich herunterladbar sind, sodass man es selbst (lokal oder auf eigener Hardware) betreiben kann. Nicht zwingend vollständig quelloffen – die Lizenz bestimmt die erlaubte Nutzung.Mehr im Wissen →-Modell, dessen Gewichte man herunterladen darf.
Der Preis dafür ist Aufwand: Hardware, Einrichtung und eine spürbare Qualitätslücke zur Cloud-Frontier. Für viele Aufgaben ist diese Lücke längst klein genug – für die ganz harten Fälle bleibt die Cloud die bessere Wahl.
Die wichtigste Faustregel: Der Speicherbedarf richtet sich nach ParameterDie im Training gelernten „Stellschrauben“ eines Modells (gezählt in Milliarden). Mehr Parameter heißt grob mehr Kapazität, aber auch mehr Rechen- und Speicherbedarf – und sagt allein wenig über die Qualität.Mehr im Wissen → und Zahlpräzision. In voller Präzision (FP16) gilt grob „2 GB je Milliarde Parameter“; mit QuantisierungVerfahren, das die Gewichte eines Modells mit weniger Bits speichert (z. B. 4 statt 16). Das senkt Speicher- und Hardwarebedarf deutlich, kostet aber etwas Genauigkeit – wichtig fürs lokale Betreiben.Mehr im Wissen → sinkt das auf etwa 1 GB (8-bit) oder 0,5 GB (4-bit) je Milliarde – plus etwas Overhead. Ein 8-Milliarden-Modell in 4-bit belegt damit rund 4,5 GB, ein 70-Milliarden-Modell grob 40–46 GB.
Konkrete, belegte Anker: Llama 3.1 8B liegt als 4-bit-Variante (Q4_K_M) bei 4,58 GiB. Googles Gemma 4 gibt die Werte offiziell an – das 12B-Modell braucht in 4-bit etwa 6,7 GB, das 31B-Topmodell rund 17,5 GB. Daraus ergibt sich die grobe Eignung: 8 GB RAM reichen für kleine 7–8B-Modelle, 16 GB für 7–13B komfortabel, 32 GB bis etwa 30B, 64 GB für 70B in 4-bit.
Ein oft übersehener Posten kommt obendrauf: der KV-Cache fürs KontextfensterDie maximale Textmenge (in Tokens), die ein Modell pro Anfrage gleichzeitig „im Blick“ hat – Eingabe plus bisheriger Verlauf. Ist es voll, fällt Älteres aus dem Kontext.Mehr im Wissen →. Er wächst linear mit der Kontextlänge und kann bei langen Kontexten leicht die Größenordnung der Modellgewichte selbst erreichen. Wer mit großen Dokumenten arbeitet, sollte über die reine Modellgröße hinaus Reserve einplanen.
wächst linear mit der Kontextlänge – bei langen Kontexten erheblich
MerksatzFaustregel: 4-bit-Quantisierung braucht grob ein halbes GB je Milliarde Parameter. Für lange Kontexte zusätzlich Reserve fürs Kontextfenster einplanen.
Quantisierung speichert die Gewichte eines Modells mit weniger Bit – das schrumpft den Speicherbedarf drastisch, kostet aber etwas Genauigkeit. Für lokale Nutzung hat sich das Dateiformat GGUF (aus dem Projekt llama.cpp) durchgesetzt; die gängigen Stufen tragen Namen wie Q4_K_M, Q5_K_M oder Q8_0.
Als Kompromiss gilt Q4_K_M als empfohlener Standard: deutlich kleiner als die volle Präzision, mit nur geringem Qualitätsverlust. Q8 kommt dem Original sehr nahe (für mehr Qualität bei kleinen Modellen), während sehr niedrige Stufen wie Q2 oder Q3 spürbar an Qualität verlieren. Faustregel: Mit Q4 fährt man fast immer gut.
GGUF
verbreitetes Format für lokale Modelle (aus llama.cpp)
Q4_K_M
empfohlener Standard – kleiner Bauraum, geringer Qualitätsverlust
Q8 / Q2–Q3
Q8 ≈ nahe Original · Q2/Q3 sparen Platz, verlieren aber spürbar Qualität
MerksatzQuantisierung tauscht etwas Genauigkeit gegen viel Speicher. Q4_K_M ist der bewährte Standard-Kompromiss.
Apple Silicon: der heimliche Vorteil
Macs mit M-Chips sind für lokale Modelle überraschend stark – dank Unified Memory. Anders als bei einer klassischen Grafikkarte mit fest abgetrenntem VRAM teilen sich CPU und GPU denselben Speicherpool, sodass praktisch der gesamte RAM für das Modell nutzbar ist. Weil lokale InferenzDer laufende Betrieb eines fertig trainierten Modells – das Erzeugen von Antworten auf Anfragen. Anders als das einmalige Training fällt Inferenz bei jeder Nutzung an.Mehr im Wissen → vor allem durch die Speicherbandbreite begrenzt wird, spielt Apple Silicon hier seine Stärke aus.
Grobe Eignung nach RAM: 16 GB für 7–8B-Modelle, 32 GB bis etwa 30B, 64 GB und mehr für 70B. Eine Einschränkung aus der Praxis: Bei sehr großen Kontextfenstern stößt selbst reichlich Unified RAM an Grenzen, und die Antwortzeiten können dann auf Minuten steigen.
MerksatzUnified Memory macht Macs zum überraschend guten Heim-Server für lokale Modelle – die nutzbare „VRAM“-Grenze ist der gesamte RAM.
Womit starten: Ollama vs. LM Studio
Zwei Werkzeuge dominieren den Einstieg, und sie zielen auf unterschiedliche Vorlieben. Ollama ist ein Kommandozeilen-Werkzeug mit lokalem Server und OpenAI-kompatibler API – scriptbar, headless betreibbar (auch im Docker-Container) und damit die Wahl für Entwicklung und Automatisierung. LM Studio ist eine grafische App mit Modell-Browser und eingebautem Chat, die zusätzlich einen lokalen API-Server bereitstellt – ideal zum Erkunden und Ausprobieren.
Unter der Haube nutzen beide dieselbe Engine (llama.cpp), laden GGUF-Modelle und laufen auf macOS, Windows und Linux. Wer noch tiefer einsteigen will, kann llama.cpp direkt verwenden (das Fundament der beiden); Alternativen wie Jan oder GPT4All setzen ähnlich an. Beide großen Werkzeuge sind im Tooling-Bereich verlinkt.
Ollama
CLI + Server, OpenAI-kompatible API, headless/Docker – für Dev & Automation
Kompakte open-weight-Modelle (etwa von Llama, Qwen, Gemma, Mistral oder DeepSeek-Distillaten) laufen 2026 sinnvoll auf Consumer-Hardware: 7–13B auf 16 GB, bis ~30B auf 32 GB, 70B in 4-bit auf 64 GB oder einem entsprechend ausgestatteten Mac. Für viele Routine- und Datenschutz-Aufgaben reicht das gut aus.
Die echten Frontier-Modelle mit hunderten Milliarden Parametern sprengen diesen Rahmen jedoch – sie brauchen mehrere GPUs oder die Cloud. Und eine Grenze verschiebt sich durch lokalen Betrieb nicht: Halluzinationen bleiben auch offline. Lokal heißt privater und unabhängiger, nicht automatisch zuverlässiger.
MerksatzLokal ist für kompakte Modelle reif; die Frontier-Größe bleibt Cloud-Sache. Und offline halluziniert ein Modell genauso wie online.