TurboQuant : Quantifizierung großer Modelle, um sie lokal zu halten lokal

#Warum TurboQuant?

Die GGUF-K-Quants (Q4_K_M, Q5_K_M…) sind seit 2023 die Referenz: Sie werden von llama.cpp, Ollama und LM Studio umfassend unterstützt und lassen sich leicht erzeugen. Bei sehr großen Modellen stoßen sie jedoch an ihre Grenzen. Ein dichtes 70B-Modell in Q4_K_M benötigt etwa 40 GB VRAM – zu viel für eine RTX 4090 mit 24 GB. Der Wechsel zu Q3 oder Q2 lässt die Qualität einbrechen.

Die TurboQuant-Quantisierung setzt gezielt an dieser Lücke an. Es handelt sich um eine Familie von Techniken, die eine Kalibrierung anhand eines Datensatzes, eine ungleichmäßige Bitzuweisung pro Schicht und eine blockweise Kompression mit gemeinsamem Wörterbuch kombinieren. Das Ergebnis: 2,5 bis 3 effektive Bits pro Gewicht bei geringerem Qualitätsverlust als bei einem Q3_K_M-GGUF.

#So funktioniert die Kompression

Drei Mechanismen wirken zusammen. Für sich genommen ist keiner revolutionär; ihre Kombination macht den Unterschied.

Kalibrierung anhand von Daten

Einige hundert repräsentative Prompts werden durch das Modell geschickt, um zu messen, welche Gewichte die Ausgaben wirklich beeinflussen. Die übrigen können aggressiv quantisiert werden.

Bitzuweisung pro Schicht

Statt eines festen Budgets (überall 4 Bit) weist TurboQuant kritischen Attention-Schichten 5–6 Bit zu und geht bei redundanten MLPs auf 2 Bit herunter. Der Durchschnitt sinkt insgesamt auf 2,7–3,2 bpw.

Blockkompression

Die Gewichte werden in Blöcke aus 32 oder 64 Werten gruppiert, die sich einen Skalierungsfaktor und einen Offset teilen, mit einem komprimierten Codebook pro Gruppe. Dadurch wird der bei K-Quants anfallende Overhead pro Parameter vermieden.

#TurboQuant vs. klassisches GGUF

Bei einem dichten 70B-Modell ist folgende Größenordnung typisch:

GGUF Q4_K_M (~4,5 bpw)

~40 GB, nahezu FP16-Qualität, überall unterstützt. Der Referenzstandard.

GGUF Q3_K_M (~3,4 bpw)

~32 GB, spürbare Einbußen bei langen Schlussfolgerungsketten, Halluzinationen treten auf.

GGUF Q2_K (~2,6 bpw)

~26 GB, deutlich beeinträchtigte Modellqualität, für den ernsthaften Einsatz zu vermeiden.

TurboQuant ~3.0 bpw

~28 GB, Qualität nahe an Q4_K_M. Passt bei kurzem Kontext auf 1×RTX 3090 oder 1×4090.

TurboQuant ~2,5 bpw

~23 GB, leicht unter dem Q4, aber deutlich über dem Q3. Eignet sich für den 70B auf 24 GB VRAM.

#Gemessene VRAM-Einsparung nach Modellgröße

Die folgenden Zahlen sind grobe Größenordnungen für neuere dichte Modelle (Qwen 3.5, Granite 4.2) bei einem 4k-Kontext, ohne Flash Attention. Rechnen Sie 10–20 % Reserve für den KV-Cache und den Laufzeit-Overhead hinzu.

7B — Q4_K_M: 4,4 GB

TurboQuant 3.0 bpw: ~2,9 GB. Begrenzter Nutzen, das 7B-Modell passt bereits überall in den Speicher.

13B — Q4_K_M : 7,8 GB

TurboQuant 3.0 bpw: ~5,1 GB. Erlaubt einen Kontext von 16k+ auf 8 GB VRAM.

32B — Q4_K_M: 19 GB

TurboQuant 3.0 bpw: ca. 13 GB. Passt mit einem Kontext von 8k bequem in den Speicher einer RTX 4080 mit 16 GB.

70B — Q4_K_M: 40 GB

TurboQuant 2,5 bpw: ~23 GB. Ermöglicht den Betrieb eines 70B-Modells auf 1×RTX 4090 mit 24 GB oder 1×3090 mit 24 GB.

120B MoE — Q4_K_M : ~70 GB

TurboQuant 2.7 bpw: ca. 42 GB. Machbar auf 2×3090 oder einem Mac Studio mit 64 GB.

#Auswirkungen auf die Qualität

Bei den üblichen Benchmarks (MMLU, HellaSwag, HumanEval) liegt ein mit TurboQuant auf 3,0 bpw quantisiertes 70B-Modell nur 0,5 bis 1,5 Punkte von FP16 entfernt. Bei mehrstufigem Schlussfolgern und langem Code zeigen sich erste deutlichere Unterschiede. Der Test, der die Methoden am klarsten voneinander unterscheidet: ein langer Python-Codeauszug mit wechselseitigen Abhängigkeiten.

Allgemeine Kenntnisse

Kaum wahrnehmbar. Wenn Sie Fragen zum Allgemeinwissen stellen, werden Sie keinen Unterschied bemerken.

Kurze Gedankengänge

Geringer Verlust. Die Gedankenketten bleiben über 5 bis 10 Schritte hinweg kohärent.

Lange Schlussfolgerungsketten (Mathematik/Beweise)

Spürbarer Qualitätsverlust. Das Modell kann einen Schritt überspringen oder nach mehr als 20 Denk­runden den Faden verlieren. Bevorzugen Sie 3,5 bpw oder mehr, wenn dies Ihr Anwendungsfall ist.

Code

Empfindlich gegenüber aggressiven Quantisierungen. Unter 3,0 bpw müssen Sie mit mehr subtilen Fehlern rechnen (falsche Indizes, umgekehrte Bedingungen). Bleiben Sie für Aider/Continue bei Q4_K_M oder TurboQuant ≥3,5 bpw.

Seltene Sprachen

Französisch wird bis zu 2,5 bpw gut unterstützt. Sprachen, die im Kalibrierkorpus weniger vertreten sind, leiden stärker.

#Hardware- und Softwarevoraussetzungen

Ein Modell selbst zu quantisieren, bleibt aufwendig. Es bereits quantisiert von Hugging Face herunterzuladen, ist fast immer einfacher. Wenn Sie dennoch Ihre eigene Version erstellen möchten:

GPU für die Kalibrierung

Der Modell-Load muss während der Analyse in FP16 oder BF16 erfolgen. Für ein 70B erfordert das 2×A100 80 GB oder einen Mac Studio M2 Ultra 192 GB. Für ein 32B reicht eine RTX 4090 24 GB mit teilweiser Offloadung.

Grundmodell

Die nicht quantisierten Gewichte (safetensors), heruntergeladen aus dem ursprünglichen Hugging-Face-Repository. Rechnen Sie bei einem 70B-Modell in FP16 mit 140 GB.

Kalibrierungsdatensatz

256 bis 1024 Beispiele, die für Ihre Nutzung repräsentativ sind. Die französischsprachige Wikipedia, Code, Ihre eigenen Prompts. Vermeiden Sie allgemeine Datensätze, wenn Sie in einem bestimmten Fachgebiet arbeiten.

Zielruntime

Entscheiden Sie im Voraus: ExLlamaV3 (am schnellsten auf Nvidia), llama.cpp mit turbo-Backend oder ein bestimmter Fork. Das Dateiformat unterscheidet sich je nach Runtime.

Python 3.10+ und CUDA 12+

Standard-Toolchain. Bei AMD funktioniert ROCm 6.x mit llama.cpp, aber (noch) nicht mit allen Turbo-Forks.

#Workflow zur selbstständigen Quantisierung

Der typische Ablauf von einem Hugging-Face-Modell in FP16 bis zu einer Datei, die sich in Ollama oder llama.cpp ausführen lässt.

1. 01
   Die ursprünglichen Gewichte abrufen

   Das Hugging-Face-Repository des nicht quantisierten Modells klonen. Für ein 70B-Modell bei einer guten Verbindung mindestens eine Stunde einplanen. Verwenden Sie huggingface-cli download, um den Download nach einer Unterbrechung fortsetzen zu können.
2. 02
   Das Kalibrierungsdatenset vorbereiten

   Eine JSONL-Datei mit 256–1024 Prompts erstellen. Vielfalt ist wichtiger als Quantität: Code, französische Prosa, Dialoge, technische Fragen. Eine Datei von 5–20 MB reicht völlig aus.
3. 03
   Die Kalibrierung starten

   Das Tool (zum Beispiel das Skript quantize, das vom gewählten TurboQuant-Projekt bereitgestellt wird) lädt das Modell, führt für jeden Prompt einen Vorwärtsdurchlauf aus und sammelt Schicht für Schicht Aktivierungsstatistiken. Rechnen Sie bei einem 70B-Modell je nach GPU mit 1–4 Stunden.
4. 04
   Quantisieren und exportieren

   Die Bitzuweisung wird aus den Statistiken berechnet und jeder Tensor wird dann kodiert. Ausgabe: eine Datei im .safetensors- oder .gguf-Format entsprechend dem Laufzeitumfeld. Planen Sie zusätzliche 30 Minuten bis 2 Stunden ein.
5. 05
   In das Runtime-Format umwandeln

   Für Ollama: Ein Modelfile erstellen, das auf die quantisierte Datei verweist, dann ollama create monmodele -f Modelfile ausführen. Für llama.cpp: Die ausführbare Datei main akzeptiert die .gguf-Datei direkt.
6. 06
   Qualität validieren

   Eine kleine Testreihe durchführen: 20 bis 30 Prompts, die Ihre Anwendungsfälle abdecken. Die Ergebnisse direkt nebeneinander mit denen der GGUF-Referenzversion Q4_K_M vergleichen. Wenn der Qualitätsverlust zu groß ist, den Vorgang mit mehr Bits oder einem besseren Datensatz wiederholen.

# Une fois le .gguf TurboQuant produit
cat > Modelfile <<EOF
FROM ./glm-4.7-turboquant-3.0bpw.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF

ollama create glm-4.7-turbo -f Modelfile
ollama run glm-4.7-turbo "Explique le théorème de Bayes en 3 phrases."

#Häufige Fehler und Troubleshooting

Die Laufzeitumgebung erkennt die Datei nicht

TurboQuant ist kein einheitliches Standardformat. Prüfen Sie, ob Sie die Datei mit der zur verwendeten Methode passenden Laufzeitumgebung laden (ExLlamaV3 für EXL3, eine aktuelle Version von llama.cpp für Turbo-GGUF-Dateien).

VRAM-Kapazität bei der Inferenz überschritten, obwohl die Datei hineinpasste

Sie vergessen den KV-Cache. Bei einem Kontext von 32k kann der KV-Cache zusätzliche 4–8 GB verbrauchen. Verringern Sie num_ctx oder aktivieren Sie Flash Attention über OLLAMA_FLASH_ATTENTION=1.

Katastrophale Qualität bei Ihrem Anwendungsfall

Der Kalibrierungsdatensatz deckt Ihr Fachgebiet nicht ab. Wiederholen Sie den Vorgang und fügen Sie dabei 100 bis 200 repräsentative Prompts hinzu. Das ist mit Abstand der wirksamste Hebel.

Das quantisierte Modell ist langsamer als die Q4_K_M-Version

Das ist bei bestimmten Architekturen normal: Die Turbo-Dekomprimierung verursacht zusätzlichen Aufwand. Bei älteren Karten (RTX 20xx) kann die VRAM-Einsparung auf Kosten der Tokens pro Sekunde gehen. Messen Sie die Leistung, bevor Sie sich dafür entscheiden.

Unterschiede zwischen Durchläufen

Die Kalibrierung führt zu nichtdeterministischem Verhalten. Zwei Quantisierungen desselben Modells mit demselben Datensatz können sich in ihrer Qualität leicht unterscheiden. Führen Sie mehrere Durchläufe durch und behalten Sie die beste Quantisierung.

#Weiterführende Informationen

TurboQuant ist eines von mehreren Werkzeugen, um die Grenzen dessen zu erweitern, was in den Speicher eines lokalen Systems passt. Einige ergänzende Ansätze:

Quantisierung wählen (Q4, Q5, Q8, FP16)

Um TurboQuant im Vergleich zu den klassischen GGUF-K-Quants richtig einzuordnen und je nach Einzelfall die passende Quantisierung zu wählen.

Lokales LLM-Fine-Tuning: LoRA und QLoRA

Wenn Sie über die Quantisierung hinausgehen und ein Modell an Ihr Fachgebiet anpassen möchten — oft ein wirksamerer Hebel als eine aggressivere Quantisierung.

GPU für lokale KI auswählen

Um zu entscheiden, welche Karte zu wählen ist, da die VRAM die entscheidende Einschränkung bleibt, selbst bei TurboQuant.