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

Dass die Gewichte in den VRAM passen, heißt nicht, dass das System funktioniert

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 für erledigt zu halten. Diese Rechnung deckt nur näherungsweise die Gewichte ab. Während der Inferenz kommen außerdem der Schlüssel-Wert-Cache – der KV-Cache –, Aktivierungen und temporäre Puffer, der vom Runtime reservierte Speicher, der Kontext jeder Anfrage und bei einem Dienst gleichzeitig laufende Anfragen hinzu. Eine Konfiguration kann das Modell laden, auf eine kurze Frage antworten und trotzdem scheitern, sobald sie ein langes Dokument oder mehrere Anfragen gleichzeitig erhält.

Die praktische Konsequenz ist wichtig: „Passt“ sollte bedeuten, dass die erwartete Maximallast mit einem gemessenen Puffer abgeschlossen wird – nicht, dass eine isolierte Sitzung startet. Verschwindet dieser Puffer, kann die Folge ein Speicherfehler, eine automatische Verringerung des Kontexts, die Verlagerung eines Teils der Arbeit in den System-RAM oder eine stark unregelmäßige Latenz sein. Welches Verhalten eintritt, hängt vom Runtime und seiner Konfiguration ab; es darf nicht ohne Prüfung angenommen werden.

Quantisierung ist nur einer von mehreren Stellhebeln. Weniger Bits für die Gewichte geben meist Speicher frei und können ein größeres Modell ermöglichen, beseitigen aber nicht allein die wachsenden Kosten des KV-Cache bei größerem Kontext oder höherer Parallelität. Je nach Format und Backend können sich auch Qualität, Leistung oder verfügbare Ausführungspfade ändern. Deshalb gibt es keine allgemeingültige Entsprechung zwischen „4 Bit“, „6 Bit“ und „8 Bit“.

Dieser Leitfaden beginnt bei einer konkreten Arbeitslast: Welche Eingabelänge muss akzeptiert werden, wie viele Tokens werden erzeugt, wie viele Anfragen existieren gleichzeitig, welche Latenz ist brauchbar und welche Fehler wären unzulässig? Wenn Sie noch eine Modellfamilie auswählen, sollten Sie zuerst den Leitfaden zu lokalen Modellen konsultieren. Wenn die Frage zwischen unterschiedlichen Basismodellen liegt, nutzen Sie den Vergleichsbereich, bevor Sie Unterschiede der Quantisierung zuschreiben, die tatsächlich vom Modell stammen.

Die Speicherposten, die getrennt betrachtet werden müssen

Eine brauchbare Schätzung beginnt damit, den Speicher in getrennt beobachtbare Posten zu zerlegen. Der erste Posten sind die Modellgewichte. Ihre Größe hängt von der Parameterzahl, der quantisierten Darstellung und formatspezifischen Metadaten wie Skalen, Blöcken oder Hilfsstrukturen ab. Parameter einfach durch acht, sechs oder vier zu teilen, liefert daher eine Orientierung, ersetzt aber weder die tatsächliche Größe des Formats noch den vom Runtime gemeldeten Verbrauch.

Der zweite Posten ist der KV-Cache. In einem autoregressiven Decoder bewahrt das System Schlüssel und Werte bereits verarbeiteter Tokens auf, damit sie nicht bei jedem erzeugten Token neu berechnet werden müssen. Die Transformers-Dokumentation beschreibt Cache-Tensoren mit den Dimensionen Batch-Größe, Köpfe, Sequenzlänge und Kopfdimension. Es gibt Schlüssel und Werte, und dieser Speicher fällt in jeder Schicht an. Bei gleicher Architektur erhöhen Kontext, Batch-Größe oder Parallelität den benötigten Speicher.

Der dritte Posten umfasst Aktivierungen und temporäre Puffer. Seine Größe hängt vom Backend, von der Rechengenauigkeit, Kernels, dem Prefill langer Eingaben, der Generierungslänge und der Bündelung von Anfragen ab. Er sollte nicht durch eine universelle Konstante ersetzt werden. Die vierte Komponente ist Speicher, der nicht direkt dem Modell zuzuordnen ist, etwa Ausführungskontext, Bibliotheken, Allocators und Fragmentierung. Der fünfte Posten ist ein ausdrücklicher Betriebspuffer: Speicher, der bewusst nicht zugewiesen wird, um Spitzen, Messdifferenzen und reale Last abzufangen.

Bei einem Server verdienen Batch-Größe und Parallelität eine zusätzliche Präzisierung. Ein Batch kann die Anzahl der Sequenzen sein, die in einem Schritt gemeinsam verarbeitet werden, während Parallelität die Zahl aktiver Anfragen bezeichnet. Je nach Scheduler können beide Größen zusammenhängen, sind aber nicht austauschbar. Für die Cache-Schätzung muss die Summe der aktiven Tokens aller gleichzeitig bestehenden Sequenzen gezählt werden, nicht nur die Maximallänge einer einzelnen Anfrage.

Gewichte und KV-Cache vor Download oder Deployment schätzen

Die Schätzung soll nicht jedes Byte vorhersagen. Sie soll nicht tragfähige Konfigurationen früh ausschließen und festlegen, welche Tests sich lohnen. Verwenden Sie für die Gewichte die angegebene Größe des konkreten Artefakts, das geladen werden soll, und keine generische Zahl für die Modellfamilie. Ist nur die Parameterzahl bekannt, behandeln Sie das Ergebnis als unvollständiges theoretisches Minimum. Quantisierungsformate speichern Zusatzinformationen, und manche Runtimes konvertieren oder duplizieren Strukturen beim Laden.

Für eine Llama-ähnliche Architektur lautet eine konzeptionelle Näherung für den KV-Cache pro Sequenz: Anzahl der Schichten mal zwei, mal Anzahl der Schlüssel-Wert-Köpfe, mal Sequenzlänge, mal Kopfdimension, mal Bytes je Cache-Element. Der Faktor zwei steht für K und V. Bei mehreren parallelen Sequenzen werden die im Speicher befindlichen Tokens jeder Sequenz addiert. Nutzt das Runtime einen statischen Cache, kann es Kapazität bis zu einem Maximum reservieren, selbst wenn die momentane Nutzung kleiner ist; bei einem dynamischen Cache kann der Verbrauch mit der Anfrage wachsen. Beide Strategien müssen gemessen werden.

Entscheidend ist die Zahl der Schlüssel-Wert-Köpfe, nicht zwingend die Gesamtzahl der Aufmerksamkeitsköpfe. Bei Multi-Query- oder Grouped-Query-Attention teilen sich mehrere Query-Köpfe KV-Projektionen. Das kann den Cache gegenüber einer Architektur mit einer KV-Projektion je Aufmerksamkeitskopf erheblich verkleinern. Die exakte Modellkonfiguration muss Schichten, KV-Köpfe und Kopfdimension liefern; sie dürfen nicht aus einem Handelsnamen abgeleitet werden.

Auch die Bytes pro Cache-Element müssen überprüft werden. Eine Quantisierung der Gewichte bedeutet nicht automatisch, dass auch der KV-Cache quantisiert wird. Einige Umgebungen erlauben einen quantisierten Cache-Datentyp, andere verwenden standardmäßig eine andere Genauigkeit, wieder andere wenden Offloading an. Diese Optionen verändern das Speicherbudget und können Leistung oder numerisches Verhalten beeinflussen. Notieren Sie die tatsächliche Runtime-Konfiguration, nicht nur die Bitzahl im Dateinamen.

Was sich beim Wechsel von 8 auf 6 oder 4 Bit tatsächlich ändert

Als allgemeine Regel gilt: Eine geringere Präzision der Gewichte reduziert ihren Speicherbedarf gegenüber einer höherpräzisen Darstellung desselben Modells. Das kann eine kleinere GPU nutzbar machen, mehr Budget für Kontext freilassen oder mehr parallele Anfragen erlauben. Die beobachtete Verringerung muss jedoch nicht exakt dem Verhältnis von acht zu sechs zu vier folgen. Verpackung, Skalen pro Gruppe, Dateiformat, interne Umwandlungen und Backend-Puffer verändern das Resultat.

Auch die Qualität hängt nicht allein von der Bitzahl ab. Entscheidend sind der Quantisierungsalgorithmus, die Gruppengröße, Tensoren mit Sonderbehandlung, das Basismodell und die Aufgabe. Eine 4-Bit-Quantisierung eines Verfahrens kann eine Aufgabe gut erhalten, während eine 6-Bit-Quantisierung eines anderen Verfahrens dies nicht tut; auch das Gegenteil ist möglich. Bits dienen deshalb dazu, Testhypothesen zu formulieren, nicht dazu, Genauigkeit zu bescheinigen.

Bei der Geschwindigkeit ist dieselbe Vorsicht nötig. Weniger Speicher kann Transfers reduzieren und die Nutzbarkeit auf einem begrenzten Gerät verbessern, doch ein Format kann auf einem bestimmten Backend keine effizienten Kernels besitzen oder Umwandlungen erfordern. Ein größerer Kontext kann den Engpass zur Cache-Verwaltung und zum Prefill verschieben. Die Leistung sollte mit zwei getrennten Kennzahlen gemessen werden: Zeit bis zum ersten Token bei repräsentativen Eingaben und anschließende Generierungsrate. Eine einzelne Tokens-pro-Sekunde-Zahl verbirgt relevante Unterschiede.

Als Ausgangspunkt testen Sie 8 Bit, wenn kritische Qualität und Budget dies zulassen; 6 Bit, wenn ein wesentlicher Teil des Speichers zurückgewonnen werden muss, ohne sofort die aggressivste Option zu wählen; und 4 Bit, wenn VRAM die dominante Einschränkung ist oder Tests zeigen, dass kein unzulässiger Verlust entsteht. Das sind Testprioritäten, keine universellen Empfehlungen.

Entscheidungsverfahren: von der Einschränkung zum tragfähigen Kandidaten

Definieren Sie zuerst den Betriebsvertrag. Schreiben Sie die maximale Eingabelänge auf, die tatsächlich unterstützt werden muss, eine Reserve an Ausgabe-Tokens, die maximale Zahl aktiver Anfragen, das Latenzziel und die kritischen Aufgaben. Unterscheiden Sie zwischen einem außergewöhnlichen Maximum und einem üblichen Ziel. Verarbeitet eine Anwendung lange Dokumente, bilden Tests mit kurzen Nachrichten weder ihr Speicherrisiko noch ihre nutzbare Qualität ab.

Erfassen Sie anschließend die Parameter von Architektur und Runtime. Notieren Sie für das Modell Schichten, KV-Köpfe, Kopfdimension und Gewichtsformat. Für das Runtime halten Sie Cache-Datentyp, statische oder dynamische Cache-Reservierung, verfügbare Offloading-Optionen, GPU-Speicherlimit sowie Batch- oder Tokens-in-Flight-Einstellungen fest. In Serving-Werkzeugen kann das Cache-Budget ausdrücklich konfiguriert werden oder aus einem Anteil des verfügbaren Speichers abgeleitet sein; beides muss im Experiment dokumentiert werden.

Berechnen Sie ein Band statt einer einzelnen Zahl: beobachtete oder geschätzte Gewichte, KV-Cache für die Ziellast, eine Reserve für Temporäres und einen Puffer. Überschreitet die Summe den verfügbaren VRAM schon vor Anwendung des Puffers, schließen Sie die Kombination aus. Passt sie nur knapp, stufen Sie sie als Risikokandidaten ein und testen Sie sie unter Maximallast. Passt sie mit Puffer, ist sie dennoch erst nach Validierung von Qualität und Latenz freigegeben.

Wählen Sie mindestens drei Kandidaten, die unterschiedliche Hypothesen abdecken: das gewünschte Modell mit 8, 6 und 4 Bit oder, wenn ein Kandidat unsinnig ist, ein kleineres Modell mit höherer Präzision. Halten Sie Basismodell, Revision, Prompt, maximalen Kontext, Ausgabelimit, Seed soweit unterstützt, Decodierungsparameter, Hardware und Runtime-Version konstant. Werden mehrere Variablen zugleich verändert, lässt sich eine Differenz nicht der Quantisierung zuordnen.

Minimaler Test, um einen relevanten Verlust zu erkennen

Ein brauchbarer Test muss nicht riesig sein, aber er muss repräsentativ sein. Stellen Sie eine kleine Fallmenge zusammen, die die Arbeit abdeckt, welche das Deployment begründet: strukturierte Extraktion, Klassifikation, Dokumentzusammenfassung, Code-Unterstützung oder Antworten mit Einschränkungen, je nach Anwendungsfall. Nehmen Sie Eingaben üblicher Länge und einige nahe der Betriebsgrenze auf. Lange Eingaben sind nötig, weil sie sowohl Speicherfehler als auch Verlust beim Befolgen von Anweisungen oder beim Abrufen von Details sichtbar machen können.

Definieren Sie vor der Ausführung des Modells, was je Fall validiert wird. Manche Aufgaben erlauben einen exakten Vergleich: ein gültiges JSON-Schema, zulässige Labels, Pflichtfelder, eine Abfrage mit konkreten Werten oder automatisierte Tests für Code. Andere erfordern menschliche Prüfung anhand einer Rubrik: Dokumenttreue, Abdeckung, Abwesenheit von Erfindungen, Formateinhaltung und Nutzen. Verwechseln Sie Sprachflüssigkeit nicht mit Korrektheit.

Legen Sie eine ausdrückliche Schwelle fest. Beispielsweise kann eine Konfiguration ausgeschlossen werden, wenn sie mehr kritische Fälle verfehlt als der Referenzkandidat, die strukturierte Validität über eine vom Team bestimmte Grenze hinaus verschlechtert oder neue Fehler bei sensiblen Daten erzeugt. Die Schwelle gehört zum Risiko der Anwendung; sie lässt sich nicht aus der Bitzahl ableiten. Bei einer kreativen Entwurfsaufgabe kann mehr Variation zulässig sein als bei der Datenextraktion für einen nachgelagerten Prozess.

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

Drei Betriebsprofile und ihre Prioritäten

Bei einem Laptop mit begrenzter GPU besteht die Priorität meist darin, eine Konfiguration zu vermeiden, die für eine interaktive Nutzung fortlaufend vom System-RAM oder Offloading abhängt. Beginnen Sie mit einem realistischen Kontext, einer einzelnen Anfrage und einem Modell oder einer Quantisierung mit Puffer. Ist 4 Bit die einzige Möglichkeit, das Modell zu laden, vergleichen Sie auch ein kleineres Modell bei 6 oder 8 Bit. Letzteres kann bei der konkreten Aufgabe stabiler und nützlicher sein, obwohl es weniger Parameter hat.

Auf einer Workstation mit einer GPU gibt es mehr Spielraum zwischen Qualität, Kontext und Geschwindigkeit, doch Gewichte, Cache und Temporäres teilen sich weiterhin dieselbe Grenze. Dieses Umfeld eignet sich, um 4, 6 und 8 Bit mit demselben Korpus zu vergleichen und zu entscheiden, ob VRAM für lange Kontexte reserviert werden soll. Wenn zwischen kurzen Sitzungen und Dokumentanalysen gewechselt werden soll, messen Sie beide Profile: Das Ergebnis einer kurzen Unterhaltung dimensioniert nicht das zweite Profil.

Auf einem Server mit moderater Parallelität ist die Planungseinheit nicht mehr die Modelldatei, sondern die Gesamtkapazität aktiver Tokens. Cache-Manager und Anfrage-Scheduler sind Teil der Entscheidung. Eine Konfiguration, die für eine einzelne Sitzung funktioniert, kann bei gleichzeitig eintreffenden langen Prefills den Speicher ausschöpfen. Definieren Sie Zulassungsgrenzen, maximale Länge, Ausgabereserve und Parallelität; testen Sie anschließend Bursts sowie Mischungen aus kurzen und langen Anfragen. Warteschlangenmetriken und Latenzperzentile sind aussagekräftiger als das beste Einzelergebnis.

In allen drei Profilen ist Offloading eine Option, die erklärt werden muss, keine unsichtbare Lösung. Es kann die scheinbare Kapazität erhöhen, indem es Daten verlagert, doch es kann auch die Latenz verändern und vom Verbindungsweg zwischen CPU und GPU abhängen. Entscheiden Sie anhand von Messungen, ob dieser Kompromiss für den Anwendungsfall akzeptabel ist.

Signale zum Ausschluss einer Konfiguration und Checkliste für die Übernahme

Schließen Sie eine Konfiguration aus, wenn sie intermittierende Speicherfehler erzeugt, auch wenn eine kurze Demonstration funktioniert. Intermittenz deutet häufig darauf hin, dass verfügbarer Speicher von der Form der Anfragen, der Prefill-Spitze, Fragmentierung oder weiteren Prozesslasten abhängt. Ebenfalls ein Ausschlussgrund ist, wenn das Runtime den wirksamen Kontext stillschweigend reduziert, das System nur unter geringerer als der geplanten Last stabil ist oder der beobachtete Puffer in Wiederholungstests verschwindet.

Qualitätsverschlechterung muss nach Mustern analysiert werden. Fehler bei Extraktion, Berechnungen, Pflichtfeldern, Befolgen von Anweisungen oder umfangreichen Dokumenten wiegen stärker als stilistische Änderungen, wenn diese Aufgaben kritisch sind. Eine scheinbar plausible Ausgabe mit erfundenen Werten darf nicht allein wegen eines Durchschnittswerts freigegeben werden. Prüfen Sie zusätzlich die Formatgültigkeit, wenn die Ausgabe nachfolgende Software versorgt.

Prüfen Sie vor dem Festlegen einer Standardoption Datenschutz und Betrieb. Lokale Inferenz garantiert für sich genommen nicht, dass keine Daten das Gerät verlassen: Modelldownloads, Telemetrie, Prompt-Protokollierung, Abhängigkeitsupdates und Observability-Werkzeuge sind getrennte Aspekte. Welche Daten aufbewahrt werden und welche Kommunikation jede Komponente durchführt, muss in der gewählten Konfiguration und Netzwerkumgebung geprüft werden.

Das Endergebnis muss nicht „die höchstmögliche Quantisierung“ sein. Es kann 6 Bit für ein interaktives Profil, 4 Bit für ein Analyseprofil mit großem Kontext oder 8 Bit für eine Aufgabe sein, bei der der festgestellte Verlust unzulässig ist. Bewahren Sie die Alternativen zusammen mit ihren Testprotokollen auf. Ändern sich Runtime, Hardware, Gewichtsformat oder Arbeitslast, messen Sie erneut: Die frühere Schlussfolgerung ist dann keine Garantie mehr.

Weiter entdecken

Korrekturen und Transparenz

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