GGUF, Quantisierung und VRAM: Speicherbedarf für lokale Modelle berechnen

Quantisierung reduziert den Speicherbedarf der Gewichte, nicht den gesamten Speicherbedarf

Bei der Quantisierung werden Modellgewichte mit geringerer numerischer Genauigkeit dargestellt. Dadurch benötigen sie weniger Speicher; auf manchen Systemen kann sich auch die Inferenz beschleunigen. In GGUF-Dateien begegnen dir Bezeichnungen wie Q4_K_M, Q5_K_M oder Q8_0. Sie geben Hinweise auf die Quantisierung, beschreiben aber weder den gesamten Speicherbedarf noch garantieren sie eine bestimmte Qualität oder Geschwindigkeit.

GGUF ist ein Modellcontainer, der häufig mit llama.cpp und darauf aufbauenden Tools verwendet wird. Das Format ist nicht gleichbedeutend mit Quantisierung: Es kann Gewichte mit unterschiedlichen Datentypen und Genauigkeitsstufen enthalten. Auch bedeutet „Q4“ nicht, dass jeder Parameter exakt vier Bit belegt. Metadaten, Skalierungswerte und Teile, die mit höherer Genauigkeit gespeichert werden, vergrößern die Datei. Wenn möglich, solltest du deshalb die tatsächliche Größe der quantisierten Datei prüfen, die du laden möchtest.

Für die Planung eines Deployments solltest du mindestens vier Speicherposten getrennt betrachten: Gewichte, den Key-Value-Cache (KV-Cache), temporären Rechen- und Aktivierungsspeicher sowie den Overhead der Inferenz-Engine. Die Summe hängt von der Modellarchitektur, dem Kontext, der Batch-Größe, der Verteilung auf Geräte und der Software ab. Eine Schätzung, die nur die Parameterzahl berücksichtigt, kann eine tatsächlich passende Konfiguration fälschlich ausschließen oder eine Konfiguration als geeignet einstufen, die beim Reservieren von Speicher für den Kontext scheitert.

Die erste Frage lautet nicht: „Welche GPU ist die beste?“, sondern: „Welches Modell, welcher Kontext, welche Parallelität und welche Latenz sind erforderlich?“ Daraus lässt sich der Speicherbedarf abschätzen; anschließend werden passende Konfigurationen getestet. Wenn du Engines oder Modelle miteinander vergleichen möchtest, nutze einen Vergleich und lege einen einheitlichen Workload fest. Um Alternativen für lokale Inferenz zu finden, solltest du nach Aufgabe und verfügbarer Hardware filtern.

Was Q4_K_M, Q5_K_M und Q8_0 aussagen

Im Allgemeinen bedeutet Quantisierung, dass Gewichte mit geringerer numerischer Genauigkeit gespeichert werden. Der erwartete Vorteil ist ein geringerer Speicherbedarf für die Gewichte; der mögliche Nachteil sind Antworten, die stärker vom Referenzmodell abweichen. Das Verhältnis ist nicht bei allen Modellen gleich und lässt sich seriös nicht mit einem festen Verlustprozentsatz angeben.

Bei GGUF-Varianten bezeichnet die Zahl eine Quantisierungsklasse, aber nicht die vollständige Zusammensetzung der Datei. Suffixe kennzeichnen Verfahren und Genauigkeitszuweisungen. Bei Namen wie Q4_K_M gehören die K-Familie und die M-Variante zum Quantisierungsschema. Sie sind nicht als einfache, gleichmäßige Vier-Bit-Speicherung zu verstehen. Die Dateigröße ist verlässlicher, als den exakten Speicherbedarf allein aus der Bezeichnung abzuleiten.

Als grobe Orientierung benötigen Q4-Gewichte normalerweise weniger Speicher als Q5- oder Q8-Gewichte desselben Modells. Q5 und Q8 bewahren mehr Genauigkeit in den Gewichten, beanspruchen aber mehr Speicher. Daraus folgt nicht, dass sie bei jeder Aufgabe bessere Antworten liefern: Das musst du für die konkrete Anwendung messen. Ein Klassifikator, ein Codegenerator und ein allgemeiner Chatbot können auf dieselbe Quantisierung unterschiedlich reagieren.

GGUF ermöglicht verschiedene Quantisierungsvarianten innerhalb derselben Modellfamilie. Die Kompatibilität hängt jedoch von Engine und Implementierung ab. Geh nicht davon aus, dass zwei ähnlich bezeichnete Dateien gleich schnell laufen oder dieselben Ergebnisse liefern. Prüfe, ob das Modell für die jeweilige Engine vorgesehen ist, ob das erwartete Backend geladen wurde und ob bei der Auswertung dieselbe Modellversion verwendet wird.

Gewichte, KV-Cache und Reserven getrennt berechnen

Für eine erste Näherung kannst du den Speicherbedarf der residenten Gewichte anhand der tatsächlich geladenen Modelldatei abschätzen. Ist nur die Parameterzahl bekannt, lässt sich überschlägig rechnen: Parameterzahl multipliziert mit den durchschnittlichen Bytes pro Parameter. Der Durchschnittswert muss jedoch zur tatsächlichen Quantisierung passen; die Ziffer im Dateinamen darf nicht so behandelt werden, als sei sie ein exakter Wert. Bei GGUF kann diese Vereinfachung wegen der Mischung verschiedener Genauigkeitsstufen zu Abweichungen führen.

Der KV-Cache speichert Informationen zu vorherigen Tokens, die das Modell während der Generierung benötigt. Seine Größe wächst in der Regel mit Sequenzlänge und Batch-Größe und hängt von der Architektur ab: von der Zahl der Layer, den KV-Heads, der Head-Dimension und dem Datentyp des Caches. Allgemein lässt er sich so ausdrücken: zweimal die Anzahl der Layer, multipliziert mit KV-Heads, Head-Dimension, gespeicherten Tokens, Batch-Größe und Bytes pro Element. Die Formel muss an die Implementierung und Architekturen mit anderen Aufmerksamkeitsmechanismen angepasst werden.

Die relevanten Dimensionen solltest du der Modellkonfiguration und der Dokumentation der Engine entnehmen, statt sie nur aus der Parameterzahl oder der Anzahl der Query-Heads abzuleiten. Bei Grouped-Query-Attention kann es weniger KV-Heads als Query-Heads geben. Eine Berechnung, die für jeden Query-Head einen eigenen Cache annimmt, kann den Speicherbedarf daher überschätzen. Andere Architekturentwürfe können eine andere Formel erfordern.

Temporärer Speicher und Overhead entsprechen keinem festen Prozentsatz der Gewichte. Für das Prefill langer Prompts können größere Puffer nötig sein als für die Token-für-Token-Generierung. Auch Fragmentierung, Backend, Speicherreservierung, Bibliotheken und Zahl der GPUs spielen eine Rolle. Die Berechnungsmethode von AIMultiple trennt Gewichte, KV-Cache, Aktivierungen und Overhead. Sie ist als Struktur für eine Schätzung hilfreich; ihre Ergebnisse müssen aber mit dem konkreten Modell, der Engine und der Konfiguration abgeglichen werden.

Auf die Frage „Wie viel VRAM braucht ein 7B-Modell in Q4_K_M bei 4096 Tokens?“ gibt es keine verifizierbare, allgemeingültige Antwort, solange Modell, Batch-Größe, KV-Datentyp, Engine, Geräteverteilung und Reserve nicht festgelegt sind. 4096 beschreibt die Sequenzlänge, legt den Cachebedarf aber nicht allein fest: Dafür fehlen Architekturparameter und weitere Angaben. Die Dateigröße kann eine Grundlage für die Gewichte liefern, nicht für den Gesamtbedarf.

Zwischen VRAM, RAM und teilweisem Offloading wählen

Der verfügbare VRAM bestimmt, wie viel auf der GPU liegen kann. Wenn die Engine partielles Offloading unterstützt, kann der System-RAM zum Laden weiterer Modellteile dienen. Viel RAM macht eine Konfiguration aber nicht automatisch interaktiv: Der Datentransfer zwischen RAM und GPU kann die Leistung verringern. Das Ergebnis hängt von der Verbindung und der Verteilung der Layer ab.

Bei Anforderungen an schnelle und wiederholte Antworten solltest du darauf achten, dass Gewichte und aktiver KV-Cache mit Reserve in den GPU-Speicher passen. Soll hingegen ein Modell überhaupt erst ausführbar werden, das sonst nicht hineinpasst, kann Offloading in den RAM eine Kapazitätslösung sein – allerdings mit möglichen Latenzkosten. „Das Modell lässt sich laden“ ist nicht dasselbe wie „es erfüllt die Geschwindigkeitsanforderung“.

Bei Apple Silicon wird der Unified Memory von CPU und GPU gemeinsam genutzt. Das Betriebssystem und andere Anwendungen benötigen jedoch ebenfalls Speicher. Der installierte RAM entspricht daher nicht automatisch dem für das Modell verfügbaren Speicher. Auch bei mehreren GPUs reicht es nicht, ihre Kapazitäten einfach zu addieren: Kommunikation und gerätespezifische Reserven verursachen zusätzliche Kosten, und die Software muss die vorgesehene Aufteilung unterstützen.

Die Speicherbandbreite beeinflusst besonders die Generierung, bei der Gewichte wiederholt gelesen werden. Die Kapazität beantwortet die Frage, ob die Daten hineinpassen; Bandbreite und Implementierung beeinflussen die Geschwindigkeit, sobald sie geladen sind. Engine, Kernel-Unterstützung, Quantisierungsart und Parallelität können das Ergebnis verändern. Die Hardware nur anhand des VRAM oder einer theoretischen Bandbreitenzahl auszuwählen, lässt deshalb entscheidende Faktoren außer Acht.

Für 7B Q4 bei 4096 Tokens gibt es keinen universellen Mindestwert

Ein Modell mit 7 Milliarden Parametern in Q4_K_M benötigt für seine Gewichte gewöhnlich weniger Speicher als dasselbe Modell in Q5 oder Q8. Daraus lässt sich jedoch kein allgemeingültiger Mindestwert für VRAM oder RAM ableiten. Die Parameterzahl beschreibt weder die Architektur vollständig noch die Tensoren, die mit einer anderen Genauigkeit gespeichert werden, noch die genaue Größe der Datei.

Auch 4096 Tokens reichen nicht aus, um den KV-Cache zu berechnen. Mindestens bekannt sein müssen Architektur, Layer-Zahl, KV-Heads, Head-Dimension, Datentyp des KV-Caches und Batch-Größe. Wird ein Sliding Window oder ein anderer Mechanismus eingesetzt, ändert sich die Berechnung. Verantwortungsbewusst lässt sich nur eine konkrete Konfiguration messen, statt zu versprechen, dass jedes 7B-Modell in Q4_K_M mit einem festen Speicherbetrag funktioniert.

Als praktisches Vorgehen dient die konkrete Dateigröße als Ausgangswert für die Gewichte. Berechne den KV-Cache anhand der Architekturparameter und addiere temporären Speicher sowie Engine-Reserve. Prüfe anschließend die Speicherspitze beim Laden und Generieren. Mit einem kompatiblen Backend kann die Ausführung auch ausschließlich im RAM möglich sein; die Geschwindigkeit lässt sich aus der Modellgröße jedoch nicht ableiten.

Kaufe eine Grafikkarte daher nicht anhand einer allgemeinen Tabelle nach dem Muster „7B = X GB“. Lege zuerst das genaue Modell und das Betriebsziel fest: Einzelperson oder parallele Nutzer, üblicher und maximaler Kontext, Echtzeitantworten oder Batch-Verarbeitung. Mit einem klar definierten Workload lässt sich dimensionieren; eine Parameterangabe allein genügt nicht.

Leistung messen: Geschwindigkeit, erste Antwort und Parallelität

Tokens pro Sekunde beschreibt nur einen Teil der Leistung. Dabei muss klar sein, ob die Messung das Prefill des Prompts oder die Generierung betrifft. Die Zeit bis zum ersten Token umfasst Empfang, Prefill und Vorbereitung. Bei langen Prompts kann sie steigen, selbst wenn die anschließende Generierung schnell ist. Für interaktive Anwendungen sind beide Werte wichtig.

Für einen Vergleich müssen Modell, Prompt, Ausgabelänge, Kontext, Batch-Größe, Engine, Softwareversion und Temperatur des Geräts gleich sein. Führe mehrere Wiederholungen durch und erfasse Median und Schwankung sowie den maximalen Speicherbedarf. Vergleiche keinen Test mit kurzer Antwort und einen anderen mit langem Kontext: Sie messen unterschiedliche Workloads.

Die vorliegenden Quellen reichen nicht aus, um die erwartbare Zahl der Tokens pro Sekunde oder die Latenz für ein 13B-Modell in Q5_K_M auf einer 16-GB-GPU anzugeben. Das Ergebnis hängt von der konkreten GPU, der Bandbreite, dem Modell und seiner Architektur, der Engine, ausgelagerten Layern, dem Kontext und der Konfiguration ab. Eine Kapazitätsschätzung ersetzt keinen Benchmark auf dem betreffenden System.

Für den Mehrbenutzerbetrieb solltest du unter Parallelität auch den aggregierten Durchsatz und die Latenz pro Anfrage messen. Eine für gleichzeitige Anfragen optimierte Engine kann sich anders verhalten als eine lokale Engine für einzelne Gespräche. Der Test muss die tatsächliche Nutzung abbilden: Eine einzelne Codegenerierung steht nicht für einen Server mit mehreren Sitzungen und langen Prompts.

Qualitätsverlust mit den tatsächlich relevanten Aufgaben messen

Es gibt keinen einzelnen Verlustwert, der den Wechsel von Q8 zu Q4 für alle Modelle und Aufgaben beschreibt. Das Ergebnis hängt von der Architektur, dem Quantisierungsverfahren, dem Testdatensatz und der Bewertungsmethode ab. Die Aussage „verliert 2 Prozent“ ist ohne Angaben zu Metrik, Daten, Version und Testbedingungen nicht aussagekräftig.

Erstelle eine Evaluation mit repräsentativen Beispielen und erwarteten Antworten oder vorab festgelegten Bewertungskriterien. Für Klassifikation verwendest du einen gelabelten Datensatz und vergleichst Genauigkeit, Präzision, Recall oder F1 – je nachdem, welche Kosten falsch-positive und falsch-negative Ergebnisse haben. Bei Textgenerierung bewertest du Anweisungsbefolgung, überprüfbare Fakten, Format und kritische Fehler anhand eines einheitlichen Rasters. Für Code solltest du automatisierte Tests für die Ausgaben ausführen; der subjektive Eindruck, etwas sehe „richtig“ aus, reicht nicht.

Vergleiche jede Quantisierung mit demselben Referenzmodell und verwende identische Prompts, Gesprächsvorlagen und Generierungsparameter. Behalte Seeds bei, sofern die Engine das erlaubt, und wiederhole stochastische Aufgaben. Berichte sowohl den Durchschnitt als auch schwerwiegende Fehler: Ähnliche Mittelwerte können einen deutlichen Einbruch bei einer kleinen Fallgruppe verdecken.

Die auf alphaXiv gehostete Arbeit zu Qwen3.5-4B beschreibt einen konkreten Fall mit INT4-Inferenz, quantisierungsbewusster Destillation, spekulativer Dekodierung und einer A10G-GPU. Sie belegt nur dieses System und diese Konfiguration – nicht, dass beliebige GGUF-Q4-Dateien dieselbe Qualität oder Beschleunigung erreichen. Die vorliegenden Auszüge erlauben außerdem keine Verallgemeinerung auf ein 13B-Modell oder eine andere GPU.

Quantisierung und Hardware nach klaren Kriterien auswählen

Wähle zunächst das für die Aufgabe erforderliche Qualitätsniveau – nicht die kleinste Quantisierung, die gerade noch hineinpasst. Ist die Referenzqualität unverzichtbar und ausreichend Speicher vorhanden, behalte eine höhere Genauigkeit bei und prüfe den Unterschied zu Q4. Ist Speicher der Engpass, teste Q4_K_M, miss die Leistung und vergleiche die Qualität. Reicht sie nicht aus, ziehe Q5, einen kleineren Kontext oder ein anderes Modell in Betracht, bevor du einen Hardwarekauf als einzige Lösung annimmst.

Bei der Hardwarewahl zählen Speicherkapazität, Bandbreite, Engine-Kompatibilität und Wartbarkeit des Deployments. Eine GPU mit ausreichend VRAM kann trotzdem langsam sein, wenn für die Quantisierung effiziente Kernel fehlen oder Teile des Modells ausgelagert werden. Umgekehrt kann ein Modell, das in den RAM passt, für Tests oder nicht interaktive Workloads nützlich sein, auch wenn es die Latenz einer GPU nicht erreicht.

Bewerte jede Kombination in einer eigenen Entscheidungstabelle: Modell, Quantisierung, Kontext, Batch-Größe, maximale Speichernutzung, Zeit bis zum ersten Token, Generierungsgeschwindigkeit und Qualitätswert. So lässt sich eine Investition begründen, weil sichtbar wird, welche Anforderung tatsächlich noch nicht erfüllt ist. Außerdem ersetzt der Preis einer Grafikkarte keinen Test.

Behalte beim Vergleich von Engines und Konfigurationen dasselbe Testprotokoll bei und nutze einen technischen Vergleich als Orientierung. Um kompatible Modelle zu finden, filtere nach Architektur, Format, Lizenz und tatsächlicher Dateigröße. Geh nicht davon aus, dass alle Varianten gleich funktionieren.

Fazit: Eine erste Schätzung muss auf dem tatsächlichen System geprüft werden

GGUF erleichtert die Bereitstellung lokaler Modelle mit unterschiedlichen Quantisierungen. Die Bezeichnungen Q4, Q5 oder Q8 reichen jedoch nicht aus, um ein Deployment zu dimensionieren. Verwende die tatsächliche Dateigröße als Anhaltspunkt für die Gewichte, berechne den KV-Cache mit der vorgesehenen Architektur und Konfiguration und addiere Puffer und Engine-Reserve.

Ohne weitere Angaben gibt es weder einen universellen VRAM-Wert für ein 7B-Modell in Q4_K_M bei 4096 Tokens noch eine zuverlässige Vorhersage der Tokens pro Sekunde für ein 13B-Modell in Q5_K_M auf einer 16-GB-GPU. Solche Zahlen als Garantie darzustellen, würde die Variablen verschleiern, die das Ergebnis bestimmen.

Die endgültige Entscheidung erfordert zwei Prüfungen: Speicherbedarf und Leistung mit dem tatsächlichen Workload sowie Qualität bei den Aufgaben, die das Deployment rechtfertigen. Protokolliere Kontext, Batch-Größe, Engine, Versionen, Speicherspitze, Latenz und Qualitätsmetriken. So kannst du anhand vergleichbarer Daten zwischen Quantisierung, kürzerem Kontext, partiellem Offloading, einem anderen Modell oder einer Hardwareerweiterung entscheiden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.