Ein lokales Modell ohne Rätselraten quantisieren: So wählen Sie 4, 6 oder 8 Bit nach VRAM, Kontext und akzeptablem Qualitätsverlust

Der häufigste Fehler bei der Auswahl eines lokalen Modells besteht darin, die Größe der quantisierten Datei mit dem Speicher der GPU zu vergleichen und die Entscheidung damit als erledigt zu betrachten. Diese Berechnung deckt nur näherungsweise die Gewichte ab. Während der Inferenz kommen außerdem der Cache für Schlüssel und Werte – der KV-Cache –, die Aktivierungen und temporäre Puffer, der vom Runtime reservierte Speicher, der Kontext jeder Anfrage und, bei einem Dienst, die gleichzeitigen Anfragen hinzu. Eine Konfiguration kann das Modell laden, auf eine kurze Frage antworten und dennoch scheitern, wenn sie ein langes Dokument oder mehrere gleichzeitige Anfragen erhält.

Die praktische Konsequenz ist erheblich: „passt“ muss bedeuten, dass die maximale geplante Last mit einem gemessenen Puffer abgeschlossen wird, nicht dass eine isolierte Sitzung gestartet wird. Wenn der Puffer verschwindet, kann das Ergebnis ein Speicherfehler, eine automatische Reduzierung des Kontexts, die Verlagerung eines Teils der Arbeit in den Systemspeicher (RAM) oder eine sehr unregelmäßige Latenz sein. Welches dieser Verhaltensweisen auftritt, hängt vom Runtime und seiner Konfiguration ab; es darf nicht ohne Überprüfung angenommen werden.

Die Quantisierung ist einer von mehreren Hebeln. Die Reduzierung der Bits der Gewichte spart oft Speicher und kann die Verwendung eines größeren Modells ermöglichen, beseitigt aber nicht allein die steigenden Kosten des KV-Caches bei der Erweiterung des Kontexts oder der Parallelität. Sie kann auch die Qualität, die Leistung oder die verfügbaren Ausführungspfade je nach Format und Backend verändern. Daher gibt es keine universelle Äquivalenz zwischen „4 Bits“, „6 Bits“ und „8 Bits“.

Dieser Leitfaden geht von einer konkreten Arbeitslast aus: Welche Eingabelänge muss akzeptiert werden, wie viele Token werden generiert, wie viele Anfragen koexistieren, welche Latenz ist nützlich und welche Fehler wären inakzeptabel. Wenn noch die Modellfamilie ausgewählt wird, sollte zuerst der Leitfaden für lokale Modelle überprüft werden und, wenn der Zweifel zwischen verschiedenen Basismodellen liegt, der Vergleichsabschnitt verwendet werden, bevor Unterschiede der Quantisierung zugeschrieben werden, die vom Modell stammen.

Adoptieren Sie keine Quantisierung, nur weil das Modell geladen wird. Adoptieren Sie sie nur, wenn sie den Zielkontext, die Parallelität und die Zielqualität unter einer wiederholbaren Last mit ausreichend freiem Speicher aufrechterhält, um Runtime-Schwankungen aufzufangen.

Quantisieren bedeutet, reelle Werte mit einer kleinen, diskreten Menge von Zahlen darzustellen, um weniger Bits zu verwenden und schneller mit ihnen zu arbeiten, auf Kosten eines Rundungsfehlers [1]. Bei der linearen 8-Bit-Quantisierung drückt die Dokumentation von ONNX Runtime dies als value_fp32 = scale × (quantized_value − zero_point) aus: Die Skala ist eine positive reelle Zahl und der Nullpunkt ist der quantisierte Wert, der genau null darstellt. In der symmetrischen Variante wird die Skala mit dem größten absoluten Wert berechnet; in der asymmetrischen mit dem Bereich zwischen Minimum und Maximum [3]. Die Arbeit von Wu et al. von NVIDIA untersucht, wie diese Parameter gewählt werden, und schlägt einen 8-Bit-Workflow vor, der die Präzision in allen untersuchten Netzen auf weniger als 1 % des Float-Referenzwerts hielt [2].

Bei einem LLM wird nicht nur eine Sache quantisiert, sondern drei, und jede verhält sich anders. Die Gewichte sind fest, können einmal konvertiert werden und belegen beim Laden den größten Teil des Speichers. Die Aktivierungen ändern sich mit jeder Eingabe und sind schwieriger zu quantisieren, weil sie sehr große Ausreißer enthalten. Der KV-Cache wächst mit dem Kontext und der Parallelität. Die Notation WxAy fasst die Kombination zusammen: W4A16 bedeutet 4-Bit-Gewichte mit 16-Bit-Aktivierungen, und W8A8 bedeutet 8-Bit-Gewichte und Aktivierungen; vLLM dokumentiert beispielsweise FP8 W8A8, INT8 W8A8 und INT4 W4A16 als verschiedene Schemata [27].

Nur die Gewichte zu quantisieren reduziert den Speicher und kann, da die Token-Generierung durch den Speicherzugriff und nicht durch die Berechnung limitiert ist, auch die Latenz reduzieren. GPTQ und AWQ dokumentieren dies: Der erste schreibt seine Beschleunigungen einer geringeren Datenbewegung zu, nicht der Arbeit mit Ganzzahlen [5], und der zweite weist darauf hin, dass die Generierung in FP16 eine arithmetische Intensität von ungefähr 1 Operation pro gelesenen Byte hat [6]. Auch die Aktivierungen zu quantisieren ermöglicht die Verwendung von Ganzzahl- oder FP8-Bereinigungseinheiten, zwingt aber dazu, die Ausreißer zu behandeln: Bei SmoothQuant sind einige Aktivierungen etwa 100-mal größer als die meisten Werte [7], und bei LLM.int8() das Aufheben der wenigen atypischen Dimensionen verschlechtert die Perplexität um 600 % bis 1000 % [4].

Die Granularität ist genauso wichtig wie die Bitanzahl. Ein einzelner Skalierungsfaktor pro Tensor ist billig, aber ein einzelner extremer Wert zerstört die Auflösung aller anderen. Deshalb verwenden praktische Formate eine Skala pro Kanal oder pro Gewichtsgruppe, beispielsweise alle 128 [5][6]. Dettmers und Zettlemoyer stellten fest, dass die Reduzierung der Blockgröße, d. h. die Aufteilung der Parameter in Blöcke, die separat quantisiert werden, eine der wenigen klaren Verbesserungen des Gleichgewichts zwischen Bits und Präzision ist [9]. Die Konsequenz ist, dass „4 Bits“ nie genau 4 Bits sind: Q4_K speichert 4,5 Bits pro Gewicht und Q6_K 6,5625 [22], und das von llama.cpp bei Llama 3.1 8B gemessene Q4_K_M erreicht 4,8944 Bits pro Gewicht [21].

Eine nützliche Schätzung beginnt damit, den Speicher in Posten zu zerlegen, die separat beobachtet werden können. Der erste sind die Modellgewichte. Ihre Größe hängt von der Anzahl der Parameter, der quantisierten Darstellung und Format-Metadaten ab, wie Skalen, Blöcke oder Hilfsstrukturen. Daher bietet das einfache Dividieren der Parameter durch acht, sechs oder vier eine Orientierung, ersetzt aber nicht die tatsächliche Größe, die vom Format und Runtime gemeldet wird.

Der zweite Posten ist der KV-Cache. In einem autoregressiven Dekoder bewahrt das System Schlüssel und Werte der bereits verarbeiteten Token, um sie bei jedem generierten Token nicht neu berechnen zu müssen. Die Dokumentation von Transformers beschreibt Caches-Tensoren mit Dimensionen für Batch, Köpfe, Sequenzlänge und Kopfdimension. Es gibt Schlüssel und Werte, und dieser Speicher wird pro Schicht wiederholt. Bei gleicher Architektur erhöhen Kontext, Batch oder Parallelität den benötigten Speicher.

Der dritte Posten fasst Aktivierungen und temporäre Puffer zusammen. Ihre Größe hängt vom Backend, der Berechnungspräzision, Kernels, dem Prefill langer Eingaben, der Generierungslänge und der Gruppierung von Anfragen ab. Es ist nicht ratsam, sie durch eine universelle Konstante zu ersetzen. Der vierte Bestandteil ist der Speicher, der nicht direkt dem Modell zugeordnet ist, wie Ausführungskontext, Bibliotheken, Zuweiser und Fragmentierung. Der fünfte ist ein expliziter operationeller Puffer: Speicher, der absichtlich nicht zugewiesen wird, um Spitzen, Unterschiede zwischen Messungen und reale Last zu tolerieren.

Auf einem Server verdienen Batch und Parallelität zusätzliche Präzision. Ein Batch kann die Anzahl der Sequenzen sein, die in einem Schritt gemeinsam verarbeitet werden, während die Parallelität die Anzahl der aktiven Anfragen ist. Je nach Planer können sich beide Zahlen beziehen, sind aber nicht austauschbar. Um den Cache zu schätzen, muss die Summe der aktiven Token der koexistierenden Sequenzen gezählt werden, nicht nur die maximale Länge einer Anfrage.

Posten, die vor der Entscheidung erfasst werden müssen

Die Schätzung zielt nicht darauf ab, jedes Byte vorherzusagen: Sie zielt darauf ab, nicht durchführbare Konfigurationen auszuschließen und zu definieren, welche Tests ausgeführt werden sollten. Für die Gewichte verwenden Sie die gemeldete Größe für das konkrete Artefakt, das geladen werden soll, nicht eine generische Zahl für die Modellfamilie. Wenn nur die Anzahl der Parameter bekannt ist, behandeln Sie das Ergebnis als unvollständige theoretische Untergrenze. Quantisierungsformate speichern zusätzliche Informationen und einige Runtimes konvertieren oder duplizieren Strukturen beim Laden.

Für eine Llama-artige Architektur ist eine konzeptionelle Näherung des KV-Caches pro Sequenz: Schichten multipliziert mit zwei, multipliziert mit Schlüssel-Wert-Köpfen, multipliziert mit Sequenzlänge, multipliziert mit Kopfdimension und mit Bytes pro Cache-Element. Der Faktor zwei repräsentiert K und V. Für mehrere gleichzeitige Sequenzen werden die residenten Token jeder Sequenz addiert. Wenn der Runtime einen statischen Cache verwendet, kann er Kapazität bis zu einem Maximum reservieren, selbst wenn die momentane Nutzung geringer ist; wenn er einen dynamischen Cache verwendet, kann die Nutzung mit der Anfrage wachsen. Beide Strategien erfordern Messung.

Es ist entscheidend, die Anzahl der Schlüssel-Wert-Köpfe zu verwenden, nicht immer die Gesamtzahl der Aufmerksamkeitsköpfe. Bei Multi-Query- oder Grouped-Query-Attention teilen sich mehrere Abfrageköpfe KV-Projektionen. Dies kann den Cache im Vergleich zu einer Architektur mit einer KV-Projektion pro Aufmerksamkeitskopf erheblich reduzieren. Die genaue Konfiguration des Modells muss Schichten, KV-Köpfe und Kopfdimension liefern; sie dürfen nicht aus einem Markennamen abgeleitet werden.

Die Bytes pro Cache-Element müssen ebenfalls überprüft werden. Die Quantisierung der Gewichte impliziert nicht automatisch die Quantisierung des KV-Caches. Einige Umgebungen ermöglichen die Wahl eines quantisierten Cache-Datentyps, andere verwenden standardmäßig eine andere Präzision, und andere wenden Offloading an. Diese Optionen ändern das Speicherbudget und können Leistung oder numerisches Verhalten beeinflussen. Notieren Sie die tatsächliche Runtime-Konfiguration, nicht nur die Bits, die im Dateinamen erscheinen.

Konzeptionelles Beispiel für die Cache-Berechnung

Angenommen, ein Modell mit 32 Schichten, 8 KV-Köpfen, Kopfdimension 128 und Cache von 2 Bytes pro Element. Für eine Sequenz von 8.192 Token: 32 × 2 × 8 × 8.192 × 128 × 2 Bytes, ungefähr 1 GiB KV-Cache. Zwei gleichzeitige Sequenzen mit dieser Länge würden diesen Posten ungefähr verdoppeln. Dies ist eine Schätzung des Caches, nicht der gesamten VRAM: Es fehlen Gewichte, Temporaries, Runtime-Speicher und Puffer. Wenn der Cache mit einem anderen Datentyp gespeichert oder vorreserviert wird, ändert sich das effektive Ergebnis.

Die obige Formel ergibt den KV-Cache mit 2 Bytes pro Element. Um die Größenordnung mit realen Architekturen zu sehen, wendet die folgende Tabelle die gleiche Formel auf die in den Konfigurationsdateien jedes Modells veröffentlichten Parameter an [30]. Der Unterschied zwischen Llama 2 7B (32 KV-Köpfe) und Llama 3 8B (8 KV-Köpfe) ist ein Faktor 4 pro Token, was der Grouped-Query-Attention (GQA) entspricht: Mehrere Abfrageköpfe teilen sich jeden Schlüssel- und Wertkopf [20].

KV-Cache pro Sequenz in 16 Bits, berechnet mit der Formel dieses Artikels

Ein Detail der Tabelle ist für die Dimensionierung wichtig: Mit 131.072 Token Kontext belegt der Cache einer einzelnen Sequenz von Llama 3.1 8B mehr als die Gewichte desselben Modells in Q4_K_M (4,58 GiB), sodass die Reduzierung der Bits der Gewichte den langen Kontext nicht löst. Bei Llama 3.1 70B entsprechen 40 GiB Cache pro Sequenz etwas mehr als der Hälfte einer 80-GB-GPU.

Die Quantisierung des Caches greift diesen Term an. KIVI schlägt eine asymmetrische 2-Bit-Quantisierung ohne Feinabstimmung vor: Die Schlüssel werden pro Kanal und die Werte pro Token quantisiert, weil ihre Verteilungen unterschiedlich sind. Ihre Autoren berichten von einer 2,6-mal geringeren maximalen Speichernutzung, einschließlich der Gewichte, Batches bis zu 4-mal größer und einer Leistung von 2,35- bis 3,47-fach unter realen Lasten [17]. KVQuant kombiniert Kanal-Quantisierung der Schlüssel, Quantisierung vor der rotatorischen Position und isolierte Ausreißer pro Vektor; mit 3 Bits berichtet es von einer Perplexitätsdegradation von weniger als 0,1 in Wikitext-2 und C4 und davon, dass LLaMA-7B einen Kontext von 1 Million Token auf einer einzelnen A100 mit 80 GB bedienen kann [18]. Dies sind Ergebnisse der Autoren mit ihren eigenen Kernels und Modellen: Sie dienen dazu zu wissen, was möglich ist, nicht um zu versprechen, was Sie in Ihrem Runtime erhalten werden.

Die Tools zeigen dies bereits. Transformers enthält einen quantisierten Cache mit den Backends hqq (1 bis 8 Bits) und quanto (2 und 4 Bits) und warnt, dass dies die Latenz verschlechtern kann, wenn der Kontext kurz ist und die GPU über genügend Speicher verfügt [25]. TensorRT-LLM ermöglicht einen KV-Cache in FP8 und, mit vorheriger Quantisierung, in NVFP4 [28], und vLLM listet den quantisierten KV-Cache unter seinen Optionen auf [27]. Wenn Ihr Problem die Fragmentierung und Verschwendung des Caches ist und nicht die Größe jedes Elements, ist der Ansatz ein anderer: PagedAttention verwaltet den KV-Cache in Blöcken, um den Speicher im Dienst besser auszunutzen [19]. In jedem Fall bleibt die Regel des Artikels bestehen: Prüfen Sie separat, ob die Quantisierung die Gewichte, den KV-Cache oder beide betrifft, und messen Sie die Qualität mit langem Kontext.

Es gibt zwei Familien. Die Post-Training-Quantisierung (PTQ) konvertiert ein bereits trainiertes Modell, mit wenig oder keinem erneuten Training und manchmal mit einem kleinen Kalibrierungsdatensatz. Die Training-Aware-Quantisierung (QAT) trainiert oder destilliert das Modell neu, indem sie die Quantisierung simuliert. ONNX Runtime empfiehlt, auf QAT zurückzugreifen, wenn keine PTQ die gewünschte Präzision erreicht [3]. Für LLMs beobachten LLM-QAT, dass PTQ-Methoden bis zu 8 Bits gut funktionieren und darunter brechen, und schlagen eine datenlose Destillation mit Generationen des eigenen Modells vor [31]. Für diejenigen, die Modelle Dritter lokal ausführen, ist die praktische Entscheidung fast immer, zwischen bereits mit PTQ quantisierten Artefakten zu wählen.

Die Baseline ist das Runden auf den nächsten Wert (RTN). Die anderen Methoden versuchen, den Fehler zu reduzieren, den RTN bei den wenigen Gewichten oder Aktivierungen macht, die am wichtigsten sind. Die Tabelle fasst die am häufigsten zitierten zusammen und welchen überprüfbaren Datenpunkt ihre Quelle liefert.

LLM-Quantisierungsmethoden und was jede Quelle dokumentiert

Drei Lektionen wiederholen sich in diesen Arbeiten. Die erste ist, dass die Gewichte der einfache Teil und die atypischen Aktivierungen der schwierige Teil sind: LLM.int8() und SmoothQuant starten von diesem gleichen Problem und lösen es auf entgegengesetzte Arten, indem sie die Ausreißer isolieren oder ihre Größe mit den Gewichten verteilen [4][7]. Die zweite ist, dass der Schutz eines winzigen Bruchteils der Kanäle ausreicht, um einen Großteil der 4-Bit-Qualität wiederherzustellen [6]. Die dritte ist, dass die Präzisionsverbesserung oft Komplexität kostet: Je weniger Bits verwendet werden, desto mehr benötigt die Methode Kalibrierung, spezialisierte Kernels oder beides, und deshalb muss das Format mit Ihrer Engine kompatibel sein, wie später detailliert wird.

Als allgemeine Regel reduziert die Verringerung der Präzision der Gewichte ihre Speicherbelegung im Vergleich zu einer Darstellung mit höherer Präzision desselben Modells. Dies kann eine kleinere GPU machbar machen, mehr Budget für den Kontext freisetzen oder mehr parallele Anfragen ermöglichen. Die beobachtete Reduzierung muss jedoch nicht einem exakten Verhältnis von acht zu sechs zu vier folgen. Das Packen, die Gruppenskalen, das Dateiformat, interne Konvertierungen und die Puffer des Backends ändern das Ergebnis.

Die Qualität hängt auch nicht nur von der Bitanzahl ab. Wichtig sind der Quantisierungsalgorithmus, die Gruppengröße, welche Tensoren eine Sonderbehandlung erhalten, das Basismodell und die Aufgabe. Eine 4-Bit-Quantisierung einer Methode kann eine Aufgabe gut erhalten und eine andere 6-Bit-Quantisierung einer anderen Methode nicht; das Umgekehrte ist auch möglich. Aus diesem Grund dienen Bits dazu, Testhypothesen zu formulieren, nicht um Präzision zu zertifizieren.

Die Geschwindigkeit erfordert die gleiche Vorsicht. Weniger Speicher kann Übertragungen reduzieren und die Machbarkeit auf einem begrenzten Gerät verbessern, aber ein Format kann in einem bestimmten Backend über keine effizienten Kernels verfügen oder Konvertierungen erfordern. Die Erhöhung des Kontexts kann den Flaschenhals zur Cache-Verwaltung und zum Prefill verschieben. Die Leistung muss mit zwei separaten Metriken gemessen werden: Zeit bis zum ersten Token für repräsentative Eingaben und anschließende Generierungsraten. Eine einzelne Zahl an Token pro Sekunde verdeckt relevante Unterschiede.

Als Ausgangspunkt testen Sie 8 Bits, wenn die Qualität kritisch ist und das Budget es zulässt; 6 Bits, wenn ein erheblicher Teil des Speichers zurückgewonnen werden muss, ohne direkt zur aggressivsten Option zu springen; und 4 Bits, wenn die VRAM die dominante Einschränkung ist oder wenn die Tests zeigen, dass es keinen inakzeptablen Verlust gibt. Dies sind Testprioritäten, keine universellen Empfehlungen.

Die folgenden Zahlen sind veröffentlichte Messungen, keine Schätzungen dieses Artikels. Sie beginnen mit der Größe: Die Tabelle reproduziert die Dokumentation von llama.cpp für Llama 3.1 8B. Die Spalte für die Generierung stammt aus demselben README, das den Hardware für diese Tests nicht angibt, sodass sie nur zum Vergleich der Zeilen untereinander dient.

Llama 3.1 8B in GGUF: Von llama.cpp gemessene Größe und Geschwindigkeit [21]

Zwei Beobachtungen. Die erste ist, dass Q8_0 etwas mehr als die Hälfte von F16 belegt und Q4_K_M weniger als ein Drittel: Die Speichereinsparung folgt den Bits pro Gewicht. Die zweite ist, dass die Geschwindigkeit nicht den Bits folgt: IQ1_S und Q2_K generieren fast gleich schnell (79,73 und 79,85 Token/s), obwohl Q2_K 1,2 Bits mehr pro Gewicht verwendet, und Q3_K_M generiert mit einer fast identischen Geschwindigkeit wie Q4_K_M (71,68 und 71,93). Dennoch übertreffen alle quantisierten Versionen F16 deutlich, das in diesemselben Test 29,17 Token/s generiert. Die Studie von Jin et al. fasst dies zusammen: Quantisierung spart Speicher, kann aber auch die Inferenz verlangsamen, und um sie auszunutzen, sind Ingenieursarbeit und Hardware-Unterstützung erforderlich [12].

Ein zweiter Satz von Messungen, durchgeführt mit Transformers auf einem Modell mit etwa 15,5 Milliarden Parametern, zeigt den tatsächlichen maximalen Speicher gegenüber der Regel von zwei Bytes pro Parameter.

Maximaler GPU-Speicher von bigcode/octocoder in Transformers [26]

Der Hugging Face-Leitfaden, der diese Tabelle enthält, legt eine nützliche Regel offen: Die Gewichte eines Modells mit X Milliarden Parametern belegen etwa 2 × X GB in bfloat16 und etwa 4 × X GB in float32 [26]. Durch Arithmetik sinkt der Faktor bei 8 Bits auf 1 × X und bei 4 Bits auf 0,5 × X, bevor Skalen, KV-Cache und Runtime-Speicher hinzugefügt werden.

Nun der Qualitätsverlust. Die Tabelle fasst vier Studien mit verschiedenen Metriken zusammen, sodass ihre Zeilen nicht miteinander vergleichbar sind: Jede Zeile vergleicht die Methode mit ihrer eigenen 16-Bit-Referenz.

Von den Autoren jeder Methode veröffentlichter Qualitätsverlust

Die jüngsten Vergleichsstudien betrachten Modelle und Aufgaben, die dem realen Gebrauch näher kommen. Kurtic et al., mit über 500.000 Bewertungen über die gesamte Llama 3.1-Familie, schließen, dass FP8 (W8A8) bei jeder Größe praktisch verlustfrei ist, dass gut abgestimmtes INT8 W8A8 zwischen 1 % und 3 % Genauigkeit verliert und dass INT4 nur für Gewichte wettbewerbsfähiger ist als erwartet, auf Augenhöhe mit 8 Bits [10]. Lee et al., mit Modellen von 1 Milliarde bis 405 Milliarden Parametern und 13 Datensätzen, beobachten, dass kleine Modelle bei 4 Bits schwere Einbrüche erleiden können, dass die mit 70 Milliarden stabil bleiben, dass AWQ bei der nur-Gewichte-Quantisierung tendenziell GPTQ übertrifft und dass quantisierte Modelle häufiger beim Befolgen von Anweisungen und bei der Erkennung von Halluzinationen scheitern [11]. Dettmers und Zettlemoyer, mit über 35.000 Experimenten, schließen, dass 4 Bits fast universell die optimale Präzision für die Gesamtbits des Modells und seine Zero-Shot-Genauigkeit ist: Ein Modell mit 30 Milliarden Parametern bei 8 Bits und eines mit 60 Milliarden bei 4 Bits belegen dasselbe, können aber sehr unterschiedlich performen, sodass sowohl die Modellgröße als auch die Bits wichtig sind [9].

Diese Zahlen dürfen nicht einfach so angewendet werden. Die von GPTQ, AWQ und SmoothQuant stammen aus Modellen von 2022 und 2023; die Perplexität in WikiText misst weder das Befolgen von Anweisungen noch das Fehlen von Halluzinationen; und die Unterschiede zwischen Methoden können sich mit jeder Modellfamilie ändern. Ihr Nutzen besteht darin, eine Größenordnung festzulegen – 8 Bits fast verlustfrei, 4 Bits akzeptabel in großen Modellen, 3 Bits oder weniger nur mit spezifischen Methoden –, die Ihr eigener Test bestätigen muss.

Zusammengefasster Entscheidungsbaum

Definieren Sie zuerst den operationellen Vertrag. Schreiben Sie die maximale Eingabelänge, die tatsächlich unterstützt werden muss, eine Reservierung von Ausgabetoken, die maximale Anzahl aktiver Anfragen, das Latenzziel und die kritischen Aufgaben. Unterscheiden Sie ein außergewöhnliches Maximum von einem üblichen Ziel. Wenn eine Anwendung lange Dokumente verarbeitet, repräsentiert das Messen nur kurzer Nachrichten weder ihr Speicher- noch ihr nützliches Qualitätsrisiko.

Sammeln Sie dann die Parameter der Architektur und des Runtimes. Für das Modell registrieren Sie Schichten, KV-Köpfe, Kopfdimension und das Gewichtsformat. Für den Runtime registrieren Sie den Cache-Datentyp, ob er statischen oder dynamischen Cache reserviert, ob er Offloading erlaubt, das GPU-Speicherlimit und jede Batch- oder In-Flight-Token-Einstellung. In Dienst-Tools kann das Cache-Budget explizit konfiguriert oder aus einem Bruchteil des verfügbaren Speichers abgeleitet werden; beide Fälle müssen im Experiment festgehalten werden.

Berechnen Sie einen Band, nicht eine einzelne Zahl: Beobachtete oder geschätzte Gewichte, KV-Cache für die Ziellast, eine Reservierung für Temporaries und ein Puffer. Wenn die Summe den verfügbaren VRAM überschreitet, bevor der Puffer angewendet wird, schließen Sie die Kombination aus. Wenn sie knapp hineinpasst, klassifizieren Sie sie als Risikokandidat und testen Sie sie unter maximaler Last. Wenn sie mit Puffer hineinpasst, geben Sie sie nicht als genehmigt frei, bis Qualität und Latenz validiert sind.

Wählen Sie mindestens drei Kandidaten, die auf verschiedene Hypothesen antworten: Das gewünschte Modell bei 8 Bits, 6 Bits und 4 Bits; oder, wenn ein Kandidat keinen Sinn ergibt, ein kleineres Modell mit höherer Präzision. Halten Sie Basismodell, Revision, Prompt, maximalen Kontext, Ausgabelimit, Seed (wenn kompatibel), Dekodierungsparameter, Hardware und Runtime-Version konstant. Das Ändern mehrerer Variablen gleichzeitig verhindert, dass ein Unterschied der Quantisierung zugeschrieben wird.

Reproduzierbarer Prozess in sieben Schritten

1. Definieren Sie Eingabekontext, reservierte Ausgabe, Parallelität und Latenzziel.

2. Registrieren Sie Architektur, Gewichtsartefakt und Cache-Konfiguration.

3. Schätzen Sie Gewichte, KV-Cache und Puffer für das Maximum an aktiven Token.

4. Schließen Sie Kandidaten aus, die vor dem Puffer nicht hineinpassen oder unüberprüfte Annahmen erfordern.

5. Führen Sie vergleichbare Kandidaten mit identischen Parametern aus.

6. Messen Sie Speicher, Zeit bis zum ersten Token, Generierung, Fehler und Ausgabequalität.

7. Bewahren Sie die Konfiguration nur auf, wenn sie den Qualitätsschwellenwert überschreitet und unter maximaler Last Puffer aufrechterhält.

Ein nützlicher Test muss nicht riesig sein, aber repräsentativ. Erstellen Sie eine kleine Menge von Fällen, die die Arbeit einschließt, die die Bereitstellung motiviert: Strukturierte Extraktion, Klassifizierung, Dokumentzusammenfassung, Code-Assistenz oder Antworten mit Einschränkungen, je nach Fall. Schließen Sie Eingaben von üblicher Länge und einige nahe am operationellen Limit ein. Lange Eingaben sind notwendig, weil sie sowohl Speicherfehler als auch Verluste im Befolgen von Anweisungen oder in der Detailwiederherstellung aufdecken können.

Definieren Sie für jeden Fall, was vor der Ausführung des Modells validiert werden soll. Einige Aufgaben erlauben exakte Vergleiche: Ein gültiges JSON-Schema, erlaubte Etiketten, obligatorische Felder, eine Abfrage, die konkrete Werte enthalten muss, oder automatisierte Tests für Code. Andere erfordern menschliche Überprüfung mit einem Raster: Treue zum Dokument, Abdeckung, Abwesenheit von Erfindungen, Formatkonformität und Nützlichkeit. Verwechseln Sie Flüssigkeit nicht mit Korrektheit.

Setzen Sie einen expliziten Schwellenwert. Zum Beispiel kann eine Konfiguration ausgeschlossen werden, wenn sie mehr kritische Fälle verletzt als der Referenzkandidat, wenn sie die strukturelle Gültigkeit über ein vom Team festgelegtes Limit hinaus verschlechtert oder wenn sie neue Fehler in sensiblen Daten erzeugt. Der Schwellenwert gehört zum Risiko der Anwendung; er kann nicht aus den Bits abgeleitet werden. In einer kreativen Entwurfsaufgabe kann mehr Variation akzeptiert werden als bei der Datenerxtraktion für einen nachgelagerten Prozess.

Wiederholen Sie die Tests. Bei stochastischer Dekodierung helfen mehrere Ausführungen, Generierungsvariation und systematische Degradation zu trennen. Bei deterministischer Dekodierung sind Wiederholungen immer noch nützlich, um Leistungsstabilität und Speicherfehler zu beobachten. Berichten Sie Ergebnisse nach Aufgabentyp und Eingabelänge, nicht nur einen globalen Durchschnitt. Eine Quantisierung, die im Durchschnitt äquivalent erscheint, kann ihre Fehler in den längsten Dokumenten oder in der Aufgabe mit dem größten Einfluss konzentrieren.

Faire Vergleichbarkeit

Vergleichen Sie keine Quantisierung mit einem Kontext von 4.000 Token mit einer anderen mit 16.000, noch eine mit Offloading mit einer ohne, wenn Sie Unterschiede den Gewichten zuschreiben wollen. Wenn eine Bedingung aus Speicherbedarf geändert wird, melden Sie sie als eine andere operationelle Konfiguration.

Die Perplexität misst die durchschnittliche Überraschung des Modells gegenüber einem Referenztext; sie wird mit dem Originalmodell und dem quantisierten Modell über denselben Text berechnet, und die zitierten Arbeiten berichten sie über WikiText und C4 [5][6][18]. Die Dokumentation von llama.cpp empfiehlt die Perplexität und die KL-Divergenz zwischen den Verteilungen des Original- und des quantisierten Modells als Präzisionsmetriken des Quantisierten [21]. Jin et al. beobachten, dass die Perplexität in den meisten getesteten Benchmarks als Surrogatindikator dient [12], aber Lee et al. zeigen, dass das Befolgen von Anweisungen und die Erkennung von Halluzinationen mehr leiden, als es die Klartextmetriken andeuten [11]. Deshalb dient die Perplexität dazu, Kandidaten auszuschließen, und der minimale Test mit eigenen Fällen bleibt die endgültige Entscheidung.

Die Kalibrierung ist eine andere Variable. GPTQ kalibriert mit 128 zufälligen Segmenten von 2.048 Token aus C4 [5] und AWQ mit 16 Sequenzen [6]; llama.cpp bietet eine Wichtigkeitsmatrix (imatrix), um die Quantisierung zu leiten [21]. Nicht verifiziert: Die konsultierten Quellen messen nicht, wie sich die Kalibrierung mit hauptsächlich englischem Text auf die Qualität in Spanisch oder anderen Sprachen auswirkt; überprüfen Sie es mit Ihrem Korpus.

Eine praktische Warnung von llama.cpp: Die erneute Quantisierung eines bereits quantisierten Modells mit der Option --allow-requantize erzeugt einen schweren Qualitätsverlust [21]. Gehen Sie immer von 16-Bit-Gewichten aus und notieren Sie, welches konkrete Artefakt Sie heruntergeladen haben, im minimalen Ausführungsprotokoll.

Auf einem Laptop mit begrenzter GPU besteht die Priorität oft darin, eine Konfiguration zu vermeiden, die kontinuierlich von System-RAM oder Offloading abhängt, für eine interaktive Erfahrung. Beginnen Sie mit einem realistischen Kontext, einer einzelnen Anfrage und einem Modell oder einer Quantisierung, die Puffer lässt. Wenn 4 Bits die einzige Möglichkeit ist, das Modell zu laden, vergleichen Sie auch ein kleineres Modell bei 6 oder 8 Bits. Das zweite kann stabiler und nützlicher in der konkreten Aufgabe sein, obwohl es weniger Parameter hat.

An einer Workstation mit einer GPU gibt es mehr Puffer, um zwischen Qualität, Kontext und Geschwindigkeit zu wählen, aber das Limit wird immer noch von Gewichten, Cache und Temporaries geteilt. Es ist eine geeignete Umgebung, um 4, 6 und 8 Bits unter demselben Korpus zu vergleichen und zu entscheiden, ob VRAM für lange Kontexte reserviert wird. Wenn zwischen kurzen Sitzungen und Dokumentenanalyse gewechselt werden soll, messen Sie beide Profile: Das Ergebnis eines kurzen Gesprächs dimensioniert das zweite nicht.

Auf einem Server mit moderater Parallelität ist die Planungseinheit nicht mehr die Modelldatei, sondern die Gesamtkapazität an aktiven Token. Der Cache-Manager und der Anfrageplaner sind Teil der Entscheidung. Eine Konfiguration, die für eine einzelne Sitzung funktioniert, kann den Speicher erschöpfen, wenn lange Prefills zusammenfallen. Definieren Sie Zulassungslimits, maximale Länge, Ausgaberesserve und Parallelität; testen Sie dann Stöße und Mischungen aus kurzen und langen Anfragen. Warteschlangenmetriken und Latenz-Perzentile sind informativer als das beste isolierte Ergebnis.

In jedem der drei Profile ist Offloading eine Option, die deklariert werden muss, keine unsichtbare Lösung. Es kann die scheinbare Kapazität erweitern, indem es einen Teil der Daten verlagert, kann aber auch die Latenz verändern und vom Link zwischen CPU und GPU abhängen. Entscheiden Sie mit Messungen, ob dieser Kompromiss für den Anwendungsfall akzeptabel ist.

Die Wahl von 4 Bits ist keine Entscheidung über das Modell, sondern über das Trio Modell, Format und Engine. GGUF ist ein binäres Format, das Tensoren und einen standardisierten Satz von Metadaten speichert, entworfen für llama.cpp und abgeleitete Tools wie LM Studio, GPT4All und Ollama [22]. Die anderen Formate leben in anderen Engines mit eigenen Hardwareanforderungen. Die Tabelle fasst zusammen, was ihre offiziellen Seiten dokumentieren, konsultiert am 17. Oktober 2026; dieses Feld ändert sich schnell und es lohnt sich, die aktuelle Version zu überprüfen.

Was jede Engine über Quantisierung dokumentiert

Zwei Konsequenzen für die Entscheidung. Die erste: Auf Hardware ohne die geeigneten Anweisungen kann Quantisierung die Leistung durch die Kosten des Quantisierens und Dequantisierens verschlechtern, wie ONNX Runtime warnt [3]. Die zweite: Das beste Format hängt vom Nutzungsmuster ab. Kurtic et al. finden, dass W4A16 bei synchronen Anfragen am rentabelsten ist und dass W8A8 bei asynchroner kontinuierlicher Batch-Verarbeitung dominiert [10]. Es ist dieselbe Unterscheidung, die dieser Artikel zwischen dem Laptop mit einer einzelnen Sitzung und dem Server mit Parallelität macht.

Notieren Sie: Identifikator und Revision des Basismodells; Artefakt und Quantisierungsmethode; Version und Backend des Runtimes; GPU und verfügbarer Speicher; KV-Cache-Typ; Kontextlimit; Ausgaberesserve; Batch, Parallelität und In-Flight-Token-Limit; Offloading; Dekodierungsparameter; Korpus und Raster; minimaler freier Speicher; Zeit bis zum ersten Token; Generierungsraten; Fehler und Qualitätsresultat. Ohne dieses Protokoll ist ein späterer Vergleich kaum reproduzierbar.

Schließen Sie eine Konfiguration aus, wenn sie intermittierende Speicherfehler erzeugt, auch wenn eine kurze Demonstration funktioniert. Intermittenz deutet oft darauf hin, dass der verfügbare Speicher von der Form der Anfragen, dem Prefill-Peak, der Fragmentierung oder anderen Lasten des Prozesses abhängt. Auch ein Grund für den Ausschluss ist, dass der Runtime den effektiven Kontext stillschweigend reduziert, dass das System nur mit einer Last unter der geplanten stabil ist oder dass der beobachtete Puffer in wiederholten Tests verschwindet.

Die Qualitätsdegradation muss nach Muster analysiert werden. Fehler, die sich in Extraktion, Berechnungen, obligatorischen Feldern, Befolgen von Anweisungen oder umfangreichen Dokumenten konzentrieren, haben mehr Gewicht als stilistische Änderungen, wenn diese Aufgaben kritisch sind. Eine scheinbar vernünftige Ausgabe mit erfundenen Werten sollte nicht nur aufgrund eines Durchschnittswerts genehmigt werden. Überprüfen Sie außerdem die Formatgültigkeit, wenn die Ausgabe nachgelagerte Software speist.

Bevor Sie eine Standardoption festlegen, überprüfen Sie Datenschutz und Betrieb. Die Inferenz auf dem Gerät auszuführen garantiert nicht von selbst, dass keine Daten es verlassen: Modell-Downloads, Telemetrie, Prompt-Protokollierung, Abhängigkeitsupdates und Observability-Tools sind separate Aspekte. Welche Daten gespeichert werden und welche Kommunikation jeder Komponente durchführt, muss in der Konfiguration und im gewählten Netzwerkumfeld überprüft werden.

Das Endergebnis muss nicht „die größtmögliche Quantisierung“ sein. Es kann 6 Bits für ein interaktives Profil, 4 Bits für ein Analyseprofil mit großem Kontext oder 8 Bits für eine Aufgabe sein, bei der der erkannte Verlust nicht akzeptabel ist. Bewahren Sie die Alternativen zusammen mit ihrem Testprotokoll auf. Wenn sich der Runtime, die Hardware, das Gewichtsformat oder die Arbeitslast ändern, messen Sie erneut: Der vorherige Schluss ist keine Garantie mehr.

Checkliste vor der Adoption einer Quantisierung

• Die Gewichte, der KV-Cache, Temporaries und der Puffer wurden separat gemessen oder begründet.

• Der Kontext, die reservierte Ausgabe und die Parallelität spiegeln die geplante maximale Last wider.

• Es wurde überprüft, ob die Quantisierung die Gewichte, den KV-Cache oder beide betrifft.

• Die verglichenen Konfigurationen verwenden dasselbe Basismodell und äquivalente Bedingungen.

• Das Korpus enthält kritische Aufgaben und repräsentative lange Eingaben.

• Es gibt einen definierten akzeptablen Verlustschwellenwert, bevor Ergebnisse überprüft werden.

• Der minimale freie Speicher, die Fehler und die Latenz-Perzentile wurden protokolliert.

• Die Konfiguration für Offloading, Telemetrie, Downloads und Protokolle wurde überprüft.

• Die Entscheidung kann aus dem vollständigen technischen Protokoll reproduziert werden.

Die Zahlen von GPTQ, AWQ, SmoothQuant und LLM.int8() wurden an OPT, BLOOM und Llama 2 gemessen; sie werden nicht auf aktuelle Modelle extrapoliert. Kurtic et al. und Lee et al. verwenden Llama 3.x und sind näher, aber sie decken nicht alle Modelle oder Sprachen ab.

Die Geschwindigkeitsverbesserungen von KIVI, KVQuant und AWQ (TinyChat) stammen von den Kernels und GPUs ihrer Autoren. Im README von llama.cpp wird die Hardware der Geschwindigkeitsmessungen und die Präzision der ursprünglichen Größenspalte nicht angegeben, obwohl ihre Zahlen (32,1 GB für 8B) mit etwa 4 Bytes pro Parameter übereinstimmen; diese Lesart ist eine unserer Inferenzen und steht nicht in der Quelle.

Die Architekturparameter der KV-Cache-Tabelle stammen von öffentlichen Repliken der config.json-Dateien auf Hugging Face (NousResearch und unsloth), weil die offiziellen Meta-Repositorien Authentifizierung erfordern. Die Kopfdimension von Llama 3.1 70B (128) wird abgeleitet, indem die versteckte Größe durch die Anzahl der Aufmerksamkeitsköpfe geteilt wird.

Die Kompatibilitätstabelle reflektiert die Dokumentation, die am 17. Oktober 2026 konsultiert wurde, einschließlich der Entwicklungsversion von vLLM. Nicht verifiziert: Die Wirkung der Kalibrierungssprache, das Verhalten jedes Quantisierers mit Mixture-of-Experts-Architekturen und die Leistung auf Ihrer konkreten GPU; diese drei Dinge erfordern Ihre eigene Messung.

• [1] Gholami, A. et al. (2021). A Survey of Quantization Methods for Efficient Neural Network Inference. arXiv:2103.13630. https://arxiv.org/abs/2103.13630

• [2] Wu, H. et al. (2020). Integer Quantization for Deep Learning Inference: Principles and Empirical Evaluation. arXiv:2004.09602. https://arxiv.org/abs/2004.09602

• [3] ONNX Runtime. Quantize ONNX models. https://onnxruntime.ai/docs/performance/model-optimizations/quantization.html

• [4] Dettmers, T., Lewis, M., Belkada, Y., Zettlemoyer, L. (2022). LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale. arXiv:2208.07339. https://arxiv.org/abs/2208.07339

• [5] Frantar, E., Ashkboos, S., Hoefler, T., Alistarh, D. (2022). GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. arXiv:2210.17323. https://arxiv.org/abs/2210.17323

• [6] Lin, J. et al. (2023). AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. arXiv:2306.00978. https://arxiv.org/abs/2306.00978

• [7] Xiao, G. et al. (2022). SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. arXiv:2211.10438. https://arxiv.org/abs/2211.10438

• [8] Dettmers, T., Pagnoni, A., Holtzman, A., Zettlemoyer, L. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. arXiv:2305.14314. https://arxiv.org/abs/2305.14314

• [9] Dettmers, T., Zettlemoyer, L. (2022). The case for 4-bit precision: k-bit Inference Scaling Laws. arXiv:2212.09720. https://arxiv.org/abs/2212.09720

• [10] Kurtic, E. et al. (2024). «Give Me BF16 or Give Me Death»? Accuracy-Performance Trade-Offs in LLM Quantization. arXiv:2411.02355. https://arxiv.org/abs/2411.02355

• [11] Lee, J. et al. (2024). Exploring the Trade-Offs: Quantization Methods, Task Difficulty, and Model Size in Large Language Models From Edge to Giant. arXiv:2409.11055. https://arxiv.org/abs/2409.11055

• [12] Jin, R. et al. (2024). A Comprehensive Evaluation of Quantization Strategies for Large Language Models. arXiv:2402.16775. https://arxiv.org/abs/2402.16775

• [13] Micikevicius, P. et al. (2022). FP8 Formats for Deep Learning. arXiv:2209.05433. https://arxiv.org/abs/2209.05433

• [14] Rouhani, B. D. et al. (2023). Microscaling Data Formats for Deep Learning. arXiv:2310.10537. https://arxiv.org/abs/2310.10537

• [15] Ma, S. et al. (2024). The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits. arXiv:2402.17764. https://arxiv.org/abs/2402.17764

• [16] Egiazarian, V. et al. (2024). Extreme Compression of Large Language Models via Additive Quantization. arXiv:2401.06118. https://arxiv.org/abs/2401.06118

• [17] Liu, Z. et al. (2024). KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache. arXiv:2402.02750. https://arxiv.org/abs/2402.02750

• [18] Hooper, C. et al. (2024). KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization. arXiv:2401.18079. https://arxiv.org/abs/2401.18079

• [19] Kwon, W. et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv:2309.06180. https://arxiv.org/abs/2309.06180

• [20] Ainslie, J. et al. (2023). GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints. arXiv:2305.13245. https://arxiv.org/abs/2305.13245

• [21] ggml-org. llama.cpp, tools/quantize/README.md. https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md

• [22] Hugging Face. GGUF (Hub-Dokumentation). https://huggingface.co/docs/hub/gguf

• [23] Hugging Face. Quantization (Transformers-Dokumentation). https://huggingface.co/docs/transformers/main/en/quantization/overview

• [24] Hugging Face. bitsandbytes (Transformers-Dokumentation). https://huggingface.co/docs/transformers/main/en/quantization/bitsandbytes

• [25] Hugging Face. KV cache strategies (Transformers-Dokumentation). https://huggingface.co/docs/transformers/en/kv_cache

• [26] Hugging Face. Optimizing LLMs for speed and memory. https://huggingface.co/docs/transformers/main/en/llm_tutorial_optimization

• [27] vLLM. Quantization. https://docs.vllm.ai/en/latest/features/quantization/

• [28] NVIDIA. TensorRT LLM: Quantization. https://nvidia.github.io/TensorRT-LLM/features/quantization.html

• [29] PyTorch. Quantization (Dokumentation 2.14). https://docs.pytorch.org/docs/2.14/quantization.html

• [30] Hugging Face. config.json-Dateien für Llama 2 7B, Llama 3 8B, Llama 3.1 8B und 70B (Spiegel von NousResearch und unsloth). https://huggingface.co/unsloth/Meta-Llama-3.1-8B/blob/main/config.json

• [31] Liu, Z. et al. (2023). LLM-QAT: Data-Free Quantization Aware Training for Large Language Models. arXiv:2305.17888. https://arxiv.org/abs/2305.17888