Lokale 200B-Modelle: Bonsai und TurboQuant

1-Bit-Gewichte und KV-Cache-Kompression: Der Weg zu lokalen 200B+-Modellen

Das lokale Ausführen von KI-Modellen mit 200B+ Parametern wird dank PrismMLs Bonsai 8B und Google Researchs TurboQuant zu einem realistischen Ziel. Diese Technologien reduzieren den Speicherbedarf für Gewichte und KV-Cache drastisch, während eine akzeptable Qualität erhalten bleibt. Eine Analyse der Prinzipien, Benchmarks und Skalierungspotenziale.

Bonsai 8B: 1-Bit-Gewichtsdarstellung

PrismML hat das Open-Source-Modell Bonsai 8B unter Apache 2.0 veröffentlicht. Die Basisarchitektur ist Qwen3-8B dicht, aber alle Gewichte (Embeddings, Attention-Projektionen, MLP-Projektionen, LM-Head) sind in ein end-to-end 1-Bit-Format quantisiert. Die GGUF-Dateigröße beträgt 1,15 GB im Vergleich zu 16,38 GB in FP16, ein Kompressionsverhältnis von 14,2x.

Leistung:

• M4 Pro: ~131 Token/Sek.
• RTX 4090: ~368 Token/Sek.
• iPhone 17 Pro Max: ~44 Token/Sek.

Auf der RTX 4090 ist die Generierungsgeschwindigkeit bis zu 6,2x schneller als FP16, mit 4–5x höherer Energieeffizienz. Benchmarks (Durchschnitt über 6 Kategorien): 70,5 (Bonsai) vs. 79,3 (Qwen3 8B), 71,0 (Mistral 3 8B), 67,1 (Llama 3.1 8B). Die Qualität bleibt trotz extremer Kompression wettbewerbsfähig.

Quantisierungsprinzip:

Jedes Gewicht ist 1 Bit (0 ≈ -Skala, 1 ≈ +Skala), mit einem FP16-Skalenwert pro Gruppe von 128 Gewichten. Effektiv 1,125 Bits/Gewicht. Die Inferenz verwendet Inline-Dequantisierungskernel ohne Materialisierung zu FP16. Erfordert Forks von llama.cpp und MLX mit benutzerdefinierten Kerneln.

Einschränkung: Das vollständige Trainingsrezept ist nicht offengelegt, es wird ein proprietäres mathematisches Framework zur Erhaltung der Logikfähigkeit erwähnt.

TurboQuant: KV-Cache-Kompression auf 3,5 Bits/Kanal

Google Research schlug TurboQuant für extreme Quantisierung des KV-Cache ohne erneutes Training des Modells vor. Das Ziel ist die Minimierung der Speichernutzung während der Inferenz, die mit der Kontextlänge wächst.

Wesentliche Ergebnisse:

• 3,5 Bits/Kanal: Qualitätsneutralität (kein Verlust in Googles Tests)
• 2,5 Bits/Kanal: minimale Verschlechterung
• KV-Cache-Speicherreduktion um mindestens 6x

Beispiel für Qwen3-235B-A22B (128k Kontext):

• FP16 KV-Cache: 23,5 GiB
• TurboQuant 3,5 Bits: ~5,1 GiB

Einsparungen >18 GiB nur beim Cache.

Mechanismus:

• Datenrotation in einen für die Kompression günstigen Raum.
• Kompensation von Quantisierungsfehlern zur Erhaltung der Berechnungen.

Der Ansatz ist mathematisch fundiert und am KV-Cache getestet.

Kombination der Ansätze für 200B+-Modelle

Die Kombination von Bonsai-ähnlicher 1-Bit-Gewichtskompression (14,2x) und TurboQuant für den KV-Cache eröffnet Perspektiven für lokale Inferenz.

Berechnung für Qwen3-235B-A22B (bfloat16 Gewichte 437,7 GiB, 128k Kontext):

| Komponente | FP16/bfloat16 | Komprimiert |

|-----------|---------------|------------|

| Gewichte | 437,7 GiB | ~30,8 GiB (14,2x) |

| KV-Cache | 23,5 GiB | ~5,1 GiB (3,5 Bits) |

| Gesamt | ~461 GiB | ~36 GiB |

Verbleibende Herausforderungen:

• Laufzeit-Overhead
• Speicherbandbreite
• Skalierbarkeit von 1-Bit auf 200B+
• Integration der Kernel in Upstream-Frameworks

Diese Kombination verschiebt die Grenze: Server-klasse 235B-Modelle nähern sich Consumer-Hardware.

Wichtige Erkenntnisse

• Bonsai 8B reduziert die Gewichte eines 8B-Modells auf 1,15 GB (14,2x), Geschwindigkeit auf RTX 4090 ist 368 Token/Sek., Qualität nahe am Basis-8B.
• TurboQuant komprimiert den KV-Cache auf 3,5 Bits/Kanal ohne Qualitätsverlust, spart 18+ GiB bei 128k Kontext für 235B.
• Die Kombination ergibt ~36 GiB für ein 235B-Modell statt 461 GiB – ein Schritt zu lokalen Giganten.
• Einschränkungen: proprietäre Trainingsdetails, Bedarf an benutzerdefinierten Kerneln.
• Ausblick: Entwicklung von Open-Source-Alternativen für mittlere/senior Entwickler.

— Editorial Team