Wpływ kwantyzacji na wyjściowe odpowiedzi Llama 3

How To Quantize a Vision Language Model Locally
https://www.youtube.com/watch?v=2xtFMsSOuiw

How To Quantize a Vision Language Model LocallyThis video installs LMDeploy locally. LMDeploy is a toolkit for compressing, deploying, and serving LLM, developed by the MMRazor and MMDeploy teams. 🔥 Buy ...YouTube

Który plik wybrać?

Świetny opis z wykresami przedstawiającymi różne wyniki można znaleźć w Artefact2
https://gist.github.com/Artefact2/b5f810600771265fc1e39442288e8ec9

Pierwszą rzeczą, którą należy ustalić, jest to, jak duży model możesz uruchomić. Aby to zrobić, musisz dowiedzieć się, ile masz pamięci RAM i/lub VRAM.

Jeśli chcesz, aby Twój model działał tak SZYBKO, jak to możliwe, zmieść całość w pamięci VRAM swojego procesora graficznego. Celuj w plik ilościowy o rozmiarze 1-2 GB mniejszym niż całkowita ilość pamięci VRAM Twojego procesora graficznego.

Jeśli chcesz uzyskać absolutnie maksymalną jakość, dodaj razem pamięć systemową RAM i pamięć VRAM procesora graficznego, a następnie w podobny sposób pobierz plik ilościowy o rozmiarze pliku o 1-2 GB mniejszym niż całkowita suma.

GGUF quantizations overviewGGUF quantizations overview. GitHub Gist: instantly share code, notes, and snippets.Gist

Oto kilka dodatkowych formatów modeli językowych, ich zalety i wady:

FP32 (Float32):

Zalety: Oferuje wysoką precyzję i stabilność, dzięki czemu idealnie nadaje się do trenowania dużych modeli językowych. Jest szeroko obsługiwany na różnych platformach sprzętowych i programowych.
Wady: Wymaga znacznej pamięci i zasobów obliczeniowych, co może być kosztowne.

FP16 (Float16):

Zalety: Zmniejsza zużycie pamięci i obciążenie obliczeniowe, przyspieszając procesy szkoleniowe przy minimalnym wpływie na precyzję.
Wady: Może prowadzić do niestabilności numerycznej i wymaga sprzętu obsługującego operacje FP16.

BF16 (BFloat16):

Zalety: Równoważy dynamiczny zakres FP32 ze zmniejszonym śladem pamięciowym FP16, dzięki czemu jest wydajny w aplikacjach głębokiego uczenia. Obsługiwany przez TPU i nowsze GPU.
Wady: Niższa precyzja może wpływać na dokładność niektórych obliczeń.

INT8:

Zalety: Oferuje znaczne zmniejszenie zużycia pamięci i wymagań obliczeniowych, znacznie przyspieszając procesy wnioskowania.
Wady: Wymaga starannej kalibracji i szkolenia z uwzględnieniem kwantyzacji w celu utrzymania dokładności, co może być skomplikowane w implementacji.

safetensors:

Zalety: Szybki czas ładowania, zaprojektowany z myślą o bezpieczeństwie, aby uniknąć wykonania dowolnego kodu.
Wady: Nie obsługuje wszystkich typów tensorów, ograniczona adopcja w porównaniu do innych formatów.

Hugging Face Transformers (.bin)

Zalety: Prosty format, szeroko stosowany w różnych aplikacjach.
Wady: Może być duży i nieefektywny do przechowywania, brakuje funkcji optymalizacji modelu.
Może być używany z różnymi frameworkami, takimi jak PyTorch i TensorFlow.

GGUF:

Zalety: Zoptymalizowany pod kątem wydajności na określonym sprzęcie, takim jak Apple Silicon i architektury x86. Obsługuje różne poziomy kwantyzacji.
Wady: Nowszy format z mniejszą elastycznością i wsparciem społeczności (premai).

exl2:

Zalety: Zaprojektowany z myślą o wydajnym wnioskowaniu i niższym zużyciu zasobów.
Wady: Ograniczone wsparcie społeczności i dokumentacja.

hqq:

Zalety: Wysokiej jakości kwantyzacja, równowaga między redukcją rozmiaru modelu a zachowaniem dokładności.
Wady: Kwantyzacja może w niektórych przypadkach prowadzić do zmniejszenia dokładności modelu.

TFRecord:

Zalety: Zoptymalizowany do użytku z TensorFlow, obsługuje wydajne przechowywanie i równoległe operacje we / wy dla dużych zbiorów danych.
Wady: Złożony w konfiguracji i mniej elastyczny w użyciu z frameworkami innymi niż TensorFlow.

ONNX (Open Neural Network Exchange):

Zalety: Ułatwia interoperacyjność między różnymi frameworkami głębokiego uczenia, upraszczając wdrażanie modeli na różnych platformach.
Wady: Konwersja między formatami może powodować wzrost wydajności i potencjalną utratę dokładności.

PyTorch (.pt, .pth, .bin)

Zalety: Natywny dla PyTorch, dzięki czemu zapisywanie i ładowanie modeli jest proste w ramach PyTorch.
Wady: Ograniczona interoperacyjność z innymi frameworkami bez dodatkowych kroków konwersji.

HDF5 (.h5):

Zalety: Wszechstronny format zdolny do przechowywania dużych ilości danych numerycznych, obsługuje złożone zestawy danych i struktury.
Wady: Wysoki narzut pamięci masowej i złożoność operacji we/wy, co czyni go mniej wydajnym w przypadku bardzo dużych modeli.

TensorFlow (.pb, .h5, .hdf5)

Zalety: Rozbudowany ekosystem z wieloma narzędziami do szkolenia i wdrażania modeli, wysoce zoptymalizowany pod kątem różnych urządzeń.
Wady: Wysokie zużycie zasobów, co może być nieefektywne w przypadku mniejszych modeli lub aplikacji (Analytics Vidhya).

MLmodel (MLflow):

Zalety: Standaryzowane opakowanie dla modeli, dobrze integruje się z MLflow do śledzenia eksperymentów i wdrożeń.
Wady: Dodatkowy narzut związany ze śledzeniem i metadanymi, co może komplikować użytkowanie w prostszych aplikacjach.

JSON:

Zalety: Czytelny dla człowieka, łatwy do debugowania i manipulacji.
Wady: Nieefektywny dla dużych modeli ze względu na gadatliwość i brak kodowania binarnego.

BERT:

Zalety: Specjalnie zoptymalizowany dla szerokiego zakresu zadań NLP, zapewniający wysoką dokładność.
Wady: Duży rozmiar modelu, wymagający znacznych zasobów obliczeniowych do szkolenia i wnioskowania.

Kwantyzacja modeli lamy za pomocą GGUF i llama.cpp

https://mlabonne.github.io/blog/posts/Quantize_Llama_2_models_using_ggml.html

Poglądowa tabelka z wielkością modelu Llama 3-8B ze względu na kwantyzację:

I jeszcze poglądowa tabelka z wielkością modelu Llama 3-70B ze względu na kwantyzację:

O ile dobrze rozumiem wyliczenia, wychodzi na to, że kwantyzowanie (kompresowanie) modeli 8B powoduje o wiele większy spadek jakości odpowiedzi niż kwantyzowanie modeli 70B. A najbardziej skwantyzowany model 70B jest na poziomie najmniej skwantyzowanego modelu 8B.

Próbując zrozumieć, o co chodzi z tą kwantyzacją, natknąłem się na takie oto wyliczenie.

Zgrubne wyliczenia wyboru kwantyzacji dla modelu językowego o wielkości 34B dla karty graficznej z 12GB VRAM:
34B oznacza 34 miliardy parametrów. Jeśli chcesz mieć 34B w 12GB, to masz 12*8 = 96 miliardów bitów do dopasowania wag. 96 miliardów/34 miliardy = ~2,8 bitów na wagę.

Potrzebujesz więc Q2_K_S lub mniejszego. (To ~2,55 bitów na wagę, co pozostawia trochę
miejsca na kontekst).

Wielkość okna kontekstu wpływa na szybkość generowania odpowiedzi w tokenach na sekundę.
*
Z dołączonych tabelek wynika też, że dokładność najmniej skwantyzowanego modelu 8B jest o ok 20-30% niższa niż modelu full 70B.