Lokale LLMs: Modelle, VRAM und Quantisierung

Lokale KI beginnt bei der Aufgabe

Ein Sprachmodell auf dem eigenen Rechner kann Texte überarbeiten, Code erklären oder interne Dokumente auswerten. Dafür braucht es nicht zwangsläufig einen Serverraum. Die entscheidende Frage lautet: Welche Qualität, Antwortzeit und Kontextlänge muss der konkrete Ablauf erreichen?

Wer nur die Parameterzahl vergleicht, übersieht schnell den eigentlichen Engpass. Ein großes Modell, das ständig Daten zwischen Arbeitsspeicher und Grafikkarte verschieben muss, kann im Alltag weniger nützlich sein als ein kleineres Modell, das vollständig in den Grafikspeicher passt.

Dieser Leitfaden ordnet ausgewählte, lokal betreibbare Modelle nach Anwendungsfall ein. Die Auswahl ist keine Rangliste der neuesten Veröffentlichungen. Stand der verlinkten Dokumentation ist September 2026. Die Speicherangaben sind Planungswerte für Inferenz, also die Ausführung eines fertigen Modells, keine eigenen Hardwaremessungen und keine Angaben für Training oder Fine-Tuning.

Welche Modelle passen zu welchem Anwendungsfall?

Für einen Chatassistenten sollte die konkrete Variante für Instruktionen oder Dialoge trainiert sein. Ein Basismodell derselben Familie ist nicht automatisch ein guter Ersatz. Ebenso wichtig sind die passende Laufzeit und das vom Hersteller vorgesehene Chatformat.

Die Modelltypen und Fähigkeiten sind in den Herstellerunterlagen beschrieben: Qwen3-8B, Qwen2.5-Coder-7B-Instruct, Qwen3-Coder bei Ollama, Gemma 3 12B IT und Qwen3-Embedding-0.6B. Die Zuordnung zu Arbeitsabläufen ist unsere redaktionelle Einordnung.

Textarbeit und strukturierte Routinen

Für Zusammenfassungen, Textvarianten oder die Zuordnung eines Tickets zu einer Kategorie ist ein Modell der 7B- bis 8B-Klasse ein sinnvoller erster Test. Dabei steht B für Milliarden Parameter. Bei sehr eng begrenzten Aufgaben kann auch ein kleineres Modell ausreichen.

Qwen3-8B lässt sich mit und ohne Thinking betreiben. Für kurze Umformulierungen ist der zusätzliche Denkprozess häufig unnötig; bei anspruchsvolleren Fragen lohnt ein Vergleich. Mehr erzeugte Denktokens bedeuten zusätzliche Wartezeit, aber keine Garantie für eine richtige Antwort. Die vorgesehenen Schalter beschreibt die Qwen3-Modellkarte.

Coding: kleine Aufgaben zuerst

Ein lokaler Coding-Assistent lässt sich gut an begrenzten Aufgaben bewerten: eine Funktion erklären, einen Testfall ergänzen oder einen Fehler anhand eines Stacktraces eingrenzen. Qwen2.5-Coder-7B-Instruct ist dafür ein kompakter Kandidat aus einer auf Code spezialisierten Familie. Modellbeschreibung von Qwen.

Für größere Aufgaben kommt Qwen3-Coder-30B-A3B-Instruct infrage. Hier ist eine Unterscheidung entscheidend: Rund 30 Milliarden Parameter sind insgesamt vorhanden, etwa 3,3 Milliarden werden pro Token aktiviert. Diese Mixture-of-Experts-Architektur reduziert die aktive Rechenarbeit. Sie macht aus dem Modell aber kein 3B-Modell beim Speicherbedarf. Die angebotene lokale 30B-Version ist bei Ollama mit rund 19 GB Dateigröße aufgeführt. Qwen3-Coder bei Ollama.

Bei agentischen Abläufen muss zusätzlich geprüft werden, ob Modell, Chatformat und Anwendung dieselben Werkzeugaufrufe unterstützen. Ein guter Codevorschlag allein belegt noch keine verlässliche Bearbeitung eines ganzen Repositorys.

Dokumentenwissen braucht eine Suche

Eine interne Wissensbasis sollte nicht bei jeder Anfrage vollständig in den Prompt kopiert werden. Bei Retrieval-Augmented Generation, kurz RAG, sucht das System zunächst passende Textstellen und übergibt diese an das Antwortmodell.

Qwen3-Embedding-0.6B erzeugt dafür numerische Repräsentationen von Texten. Es ist ein Embedding-Modell, kein Chatmodell, und schreibt selbst keine Antworten. Herstellerdokumentation.

Praktisch entscheidet hier viel Vorarbeit über die Qualität: Lassen sich PDFs sauber auslesen? Bleiben Überschriften und Tabellenzusammenhänge erhalten? Findet die Suche die richtige Passage? Die Antwort sollte auf konkrete Fundstellen verweisen und fehlende Belege kenntlich machen. Mehr Parameter reparieren keine unbrauchbare Dokumentenaufbereitung.

Bilder und Screenshots

Gemma 3 12B IT nimmt Text und Bilder entgegen und erzeugt Text. Damit lässt sich beispielsweise testen, ob ein Assistent Informationen aus einem Screenshot oder einer Produktabbildung erfassen kann. Gemma-Modellkarte.

Bei Rechnungen und gescannten Tabellen zählen allerdings die exakt übernommenen Zeichen und Zahlen. Ein plausibel klingendes Ergebnis reicht hier nicht. Bildverarbeitung benötigt außerdem zusätzlichen Speicher; die folgenden Text-Richtwerte lassen sich deshalb nicht unverändert auf Bildstapel übertragen.

Wie viel VRAM braucht ein lokales LLM mindestens?

Ein universelles VRAM-Minimum gibt es nicht. CPU-Inferenz kann ohne dedizierten Grafikspeicher auskommen, sofern genügend RAM vorhanden ist. Für interaktive Nutzung ist aber oft entscheidend, ob das Modell vollständig auf der GPU läuft. CPU- und GPU-Anteile lassen sich beispielsweise mit llama.cpp kombinieren; Tempo und Speicherbedarf hängen dann stark von der Hardware ab. llama.cpp-Dokumentation.

Für den reinen Gewichtsspeicher gilt näherungsweise: Parameterzahl × Bits pro Parameter ÷ 8 = Bytes. Acht Milliarden Parameter benötigen rechnerisch 16 GB bei 16 Bit, 8 GB bei 8 Bit oder 4 GB bei 4 Bit. Das sind dezimale GB; 4 GB entsprechen rund 3,73 GiB. Diese Rechnung lässt Quantisierungsmetadaten, abweichend gespeicherte Tensoren und den gesamten Laufzeitbedarf weg.

Gewichte, Startuntergrenze und Reserve

Die Tabelle bezieht sich auf typische dichte Textmodelle mit Q4-K-artiger Gewichtsquantisierung. Angenommen sind eine einzelne Anfrage, ungefähr 4.096 Tokens Gesamtkontext einschließlich Ausgabe, ein üblicher FP16-KV-Cache und vollständige GPU-Ausführung. Modellarchitektur und Laufzeit können die Werte verschieben. Die untere Grenze ist ein knapper Planungsansatz, keine zugesicherte Mindestanforderung.

Diese Bereiche sind aus Gewichtsspeicher plus geschätzter Laufzeitreserve abgeleitet. Für Qwen3-8B in Q4 ist eine 8-GB-GPU damit ein plausibler Startpunkt für kurze Einzelanfragen. Eine 6-GB-Karte kann bereits eng werden. Für die rund 19 GB große Qwen3-Coder-30B-Version ist 24 GB VRAM ein knapper Ansatz mit begrenztem Kontext, keine Zusage für das maximal beworbene Kontextfenster.

Vor einem Hardwarekauf sollte die genaue Kombination aus Modelldatei, Quantisierung, Laufzeit, Kontext und Parallelität auf vergleichbarer Hardware geprüft werden. Auch Desktopdarstellung und andere Programme können VRAM belegen.

Warum die Modelldatei nicht ausreicht

Zum Gewichtsspeicher kommen der KV-Cache für bereits verarbeitete Tokens sowie Arbeitsbereiche für Berechnungen. Besonders lange Kontexte können den Cache zu einem großen Speicherposten machen. Bei Modellen mit durchgehend vollständiger Attention wächst er bei gleicher Konfiguration ungefähr proportional zur Tokenzahl; Sliding-Window- und hybride Architekturen verhalten sich anders. Hugging Face: Cache-Strategien.

Mehrere gleichzeitige Anfragen benötigen ebenfalls zusätzlichen Speicher. Ein beworbenes Kontextfenster von 128K oder 256K Tokens sagt daher nicht, dass es auf der eigenen GPU nutzbar ist. In Ollama lässt sich mit ollama ps kontrollieren, ob ein geladenes Modell vollständig auf der GPU liegt oder teilweise auf der CPU läuft. Ollama-FAQ.

RAM und Apple Unified Memory

Bei einer dedizierten Grafikkarte ist System-RAM kein gleichwertiger Ersatz für VRAM. Auslagerung kann größere Modelle ermöglichen, aber die Antwortzeit deutlich verschlechtern. Für einen Arbeitsplatz mit einem 7B- bis 8B-Modell sind 16 GB System-RAM ein knapper Ausgangspunkt; 32 GB lassen mehr Platz für Anwendung, Dokumente und weitere Programme. Das ist eine Planungsempfehlung, kein hartes Modellminimum.

Auf Apple-Silicon-Systemen teilen sich CPU und GPU den Unified Memory. Von beispielsweise 32 GB Gesamtspeicher steht deshalb nicht alles dem Modell zur Verfügung. Betriebssystem, Anwendungen und Laufzeit benötigen ebenfalls Platz. Unterstützte GPU-Speicherbudgets und Speicherbandbreite zählen zusätzlich; die Kapazität allein sagt wenig über Tokens pro Sekunde aus.

Quantisierung: Was Q4, Q5 und Q8 bedeuten

Quantisierung speichert Modellgewichte mit geringerer numerischer Präzision. Dadurch sinkt der Speicherbedarf. Wie stark die Antwortqualität leidet und ob die Ausführung schneller wird, hängt vom Verfahren, dem Modell und den verfügbaren Hardware-Kernels ab. Verfahren sind deshalb nicht allein anhand ihrer Bitzahl austauschbar. Hugging Face: Quantisierungsverfahren.

Die folgende Auswahlhilfe ist eine praktische Heuristik für verbreitete GGUF-Varianten, keine gemessene Qualitätsrangliste:

GGUF ist das Dateiformat, nicht die Quantisierung. Eine GGUF-Datei kann unterschiedliche Präzisionen enthalten. Bei Bezeichnungen wie Q4_K_M werden nicht zwangsläufig alle Gewichte exakt mit vier Bit gespeichert. Blockinformationen und gemischte Tensorpräzisionen erklären, warum die Datei größer als die einfache Vier-Bit-Rechnung sein kann. Die Werkzeuge und Optionen beschreibt llama.cpp zur Quantisierung.

Für die Entscheidung lohnt ein direkter Vergleich: Dasselbe Modell in Q4 und Q5 mit denselben Aufgaben ausführen und dabei Fehler, Antwortzeit und Speicher messen. Bei knappem Speicher zusätzlich ein kleineres Modell in höherer Präzision testen. Welcher Kompromiss besser ist, lässt sich nicht pauschal aus der Parameterzahl ableiten.

Gewichte und KV-Cache sind getrennte Stellschrauben

Ein Q4-Modell kann weiterhin einen FP16-KV-Cache verwenden. Die Quantisierung der Gewichte komprimiert diesen Cache nicht automatisch. Ollama unterstützt unter den dokumentierten Voraussetzungen auch q8_0 und q4_0 für den KV-Cache. Das kann Speicher sparen, erfordert aber einen eigenen Qualitätstest, insbesondere bei langen Kontexten. Ollama zur KV-Cache-Quantisierung.

Wo lokale Modelle an Grenzen stoßen

Passend formuliert heißt nicht fachlich richtig

Auch lokal ausgeführte Modelle erfinden Quellen, verwechseln Begriffe oder erzeugen fehlerhaften Code. Quantisierung beseitigt diese Probleme nicht. Bei strukturierten Ausgaben sollten Schema und Pflichtfelder technisch validiert werden; beim Coding zählen ausführbare Tests und Review.

Für die Auswahl empfiehlt sich ein fester Satz eigener Aufgaben: normale Fälle, unvollständige Eingaben, lange Dokumente und Beispiele, bei denen die richtige Antwort ausdrücklich „nicht aus den Quellen ableitbar“ lautet. So werden Schwächen sichtbar, die allgemeine Benchmarks nicht abbilden.

Lokalität muss den ganzen Ablauf umfassen

Ein lokales Modell bedeutet nicht automatisch, dass auch Dokumentensuche, Embeddings und angebundene Werkzeuge lokal laufen. Wer Daten auf eigener Hardware halten möchte, muss den vollständigen Weg prüfen. Ollama unterscheidet lokale und cloudbasierte Modelle und bietet einen Modus zum Abschalten der Cloud-Funktionen. Ollama-FAQ zum lokalen Betrieb.

In einer Teamanwendung gehören außerdem Berechtigungen auf die Dokumente in die Suche selbst. Ein Assistent darf nicht allein deshalb interne Informationen ausgeben, weil sie technisch im gemeinsamen Index liegen.

Freie Gewichte bedeuten nicht einheitliche Lizenzen

Downloadbare Modelle haben unterschiedliche Nutzungsbedingungen. Qwen3-8B ist mit Apache 2.0 gekennzeichnet, Gemma 3 verwendet eigene Gemma-Bedingungen. Bei der Auswahl sollten daher die konkrete Modellversion und ihre Lizenz dokumentiert werden. Qwen3-Lizenzangabe, Gemma-Modellkarte und Nutzungsbedingungen.

Ein schneller Einzelchat ist noch kein Teamdienst

Sobald mehrere Menschen gleichzeitig arbeiten, verändern sich Warteschlangen, Speicherbedarf und Antwortzeiten. Anschaffung, Stromverbrauch, Updates und Betreuung gehören deshalb in die Bewertung. Ein kostenloser Modelldownload macht den Betrieb nicht kostenlos.

So entsteht eine belastbare Auswahl

Für ein digitales Team lohnt ein überschaubarer Pilot mit einem klaren Ziel: etwa Supportanfragen klassifizieren, interne Anleitungen durchsuchen oder Testentwürfe erstellen. Wie solche Routinen in den Alltag passen, beschreiben wir auch in AI im Alltag eines digitalen Teams.

1. Aufgabe festlegen: Reale Beispiele und fachliche Erfolgskriterien sammeln, einschließlich schwieriger Grenzfälle.
2. Klein anfangen: Ein passendes Instruktionsmodell mit moderater Quantisierung und begrenztem Kontext auswählen.
3. Betrieb messen: Exakte Modelldatei, Laufzeitversion, Quantisierung, Kontextlänge, Spitzenverbrauch und Antwortzeit dokumentieren.
4. Gezielt vergleichen: Jeweils eine Stellschraube verändern, etwa Q4 gegen Q5 oder ein kleines gegen ein größeres Modell.
5. Den echten Ablauf prüfen: Mit Dokumentensuche, mehreren gleichzeitigen Anfragen und den vorgesehenen Qualitätskontrollen testen.

Welche Konfiguration ist ein guter Einstieg?

Für Textarbeit und kleinere Coding-Aufgaben ist ein 7B- bis 8B-Modell in Q4 auf einer GPU mit 8–12 GB VRAM ein sinnvoller erster Versuch. Mit 16 GB entsteht Spielraum für Modelle der 12B- bis 14B-Klasse. Bei 24 GB werden größere Modelle interessant, allerdings weiterhin mit bewusst begrenztem Kontext.

Entscheidend ist, ob die Konfiguration die eigenen Aufgaben zuverlässig und schnell genug erledigt. Wer Gewichtsspeicher, Kontext und Parallelität getrennt betrachtet und Quantisierungen an echten Beispielen vergleicht, kann lokale KI wesentlich gezielter einsetzen.