1-bitowe wagi i kompresja KV-cache: droga do lokalnych modeli 200B+
Lokalne uruchamianie modeli AI o rozmiarze 200B+ przestaje być nieosiągalnym celem dzięki Bonsai 8B od PrismML i TurboQuant od Google Research. Te technologie radykalnie zmniejszają wymagania pamięciowe dla wag i KV-cache, zachowując akceptowalną jakość. Analiza zasad, benchmarków i potencjału skalowania.
Bonsai 8B: 1-bitowa reprezentacja wag
PrismML wydało otwarty model Bonsai 8B na licencji Apache 2.0. Podstawowa architektura to Qwen3-8B dense, ale wszystkie wagi (embeddings, attention projections, MLP projections, LM head) są skwantowane w end-to-end 1-bitowym formacie. Rozmiar pliku GGUF to 1,15 GB w porównaniu do 16,38 GB w FP16, współczynnik kompresji 14,2x.
Wydajność:
- M4 Pro: ~131 tokenów/s
- RTX 4090: ~368 tokenów/s
- iPhone 17 Pro Max: ~44 tokenów/s
Na RTX 4090 przyspieszenie generowania do 6,2x względem FP16, efektywność energetyczna 4–5x wyższa. Benchmarki (średnia z 6 kategorii): 70,5 (Bonsai) vs 79,3 (Qwen3 8B), 71,0 (Mistral 3 8B), 67,1 (Llama 3.1 8B). Jakość konkurencyjna przy ekstremalnej kompresji.
Zasada kwantyzacji:
Każda waga to 1 bit (0 ≈ -scale, 1 ≈ +scale), na grupę 128 wag przypada jeden FP16 scale. Efektywnie 1,125 bitu/waga. Inferencja wykorzystuje inline dequantization kernels bez materializacji w FP16. Wymagane forki llama.cpp i MLX z niestandardowymi jądrami.
Ograniczenie: pełny przepis treningowy nieujawniony, wspomniano o proprietarnym frameworku matematycznym dla zachowania reasoning.
TurboQuant: kompresja KV-cache do 3,5 bitu/kanał
Google Research zaproponowało TurboQuant do ekstremalnego kwantowania KV-cache bez dodatkowego trenowania modelu. Cel to minimalizacja pamięci podczas inferencji, rosnącej z długością kontekstu.
Kluczowe wyniki:
- 3,5 bitu/kanał: neutralność jakości (bez utraty jakości w testach Google)
- 2,5 bitu/kanał: minimalna degradacja
- Zmniejszenie pamięci KV-cache co najmniej 6x
Przykład dla Qwen3-235B-A22B (kontekst 128k):
- KV-cache FP16: 23,5 GiB
- TurboQuant 3,5 bitu: ~5,1 GiB
Oszczędność >18 GiB tylko na cache.
Mechanizm:
- Rotacja danych w przestrzeń dogodną do kompresji.
- Kompensacja błędów kwantyzacji dla zachowania obliczeń.
Podejście matematycznie uzasadnione, przetestowane na KV-cache.
Kombinacja podejść dla modeli 200B+
Połączenie Bonsai-podobnej 1-bitowej kompresji wag (14,2x) i TurboQuant dla KV-cache otwiera perspektywy lokalnej inferencji.
Obliczenia dla Qwen3-235B-A22B (wagi bfloat16 437,7 GiB, kontekst 128k):
| Komponent | FP16/bfloat16 | Skompresowany |
|-----------|---------------|---------------|
| Wagi | 437,7 GiB | ~30,8 GiB (14,2x) |
| KV-cache | 23,5 GiB | ~5,1 GiB (3,5 bitu) |
| Razem | ~461 GiB | ~36 GiB |
Pozostałe wyzwania:
- Narzuty runtime
- Przepustowość pamięci
- Skalowalność 1-bitowa na 200B+
- Integracja jąder w upstream frameworki
Taka kombinacja przesuwa granicę: serwerowe modele 235B zbliżają się do sprzętu konsumenckiego.
Co ważne
- Bonsai 8B zmniejsza wagi modelu 8B do 1,15 GB (14,2x), prędkość na RTX 4090 — 368 tokenów/s, jakość bliska bazowym 8B.
- TurboQuant kompresuje KV-cache do 3,5 bitu/kanał bez utraty jakości, oszczędność 18+ GiB na kontekście 128k dla 235B.
- Kombinacja daje ~36 GiB na model 235B zamiast 461 GiB — krok do lokalnych gigantów.
- Ograniczenia: proprietarne szczegóły treningu, konieczność niestandardowych jąder.
- Perspektywa: rozwój open-source analogów dla middle/senior dev.
— Editorial Team
Brak komentarzy.