KI-Modelle lokal betreiben: Hardware, Quantisierung, Werkzeuge

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-weight-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.

Self-Hosting vs. API – die Kostenrechnung →Proprietär vs. open-weight →

Wie viel Speicher braucht ein Modell?

Die wichtigste Faustregel: Der Speicherbedarf richtet sich nach Parameterzahl und Zahlpräzision. In voller Präzision (FP16) gilt grob „2 GB je Milliarde Parameter“; mit Quantisierung 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 Kontextfenster. 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.

Faustregel FP16

~2 GB je Mrd. Parameter (8-bit ~1 GB, 4-bit ~0,5 GB + Overhead)

Anker (belegt)

Llama 3.1 8B Q4 = 4,58 GiB · Gemma 4 12B 4-bit ≈ 6,7 GB · 31B 4-bit ≈ 17,5 GB

Grobe Eignung

8 GB → 7–8B · 16 GB → 7–13B · 32 GB → ~30B · 64 GB → 70B (je 4-bit)

Dazu: KV-Cache

wächst linear mit der Kontextlänge – bei langen Kontexten erheblich

Merksatz Faustregel: 4-bit-Quantisierung braucht grob ein halbes GB je Milliarde Parameter. Für lange Kontexte zusätzlich Reserve fürs Kontextfenster einplanen.

Was das Kontextfenster ist →

Quantisierung & das GGUF-Format

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

Merksatz Quantisierung 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 Inferenz 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.

Merksatz Unified 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

LM Studio

GUI + Modell-Browser + Chat + lokaler Server – fürs Erkunden

Gemeinsam

beide auf llama.cpp-Basis, GGUF, macOS/Windows/Linux

Merksatz Ollama für scriptbares Serving, LM Studio fürs grafische Erkunden – im Kern dieselbe Engine. Beide sind ein guter Startpunkt.

Ollama, LM Studio & Co. im Werkzeugkasten →

Was geht – und wo die Cloud bleibt

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.

Merksatz Lokal ist für kompakte Modelle reif; die Frontier-Größe bleibt Cloud-Sache. Und offline halluziniert ein Modell genauso wie online.

Modelle nach Aufgabe „Lokal & Self-Hosting“ →Warum Modelle halluzinieren →