Kwantyzacja LLM: porównanie 7 metod (z konkretnymi liczbami z benchmarków)

Kwantyzacja LLM: porównanie 7 metod (z konkretnymi liczbami z benchmarków)

Llama 3.3 70B w FP16 potrzebuje 140 GB samych wag. Dwie karty H100. Przy Q4_K_M ten sam model mieści się w około 42 GB, czyli w jednej używanej karcie RTX A6000 kupionej na eBayu. Ta różnica to cały powód, dla którego istnieje kwantyzacja LLM, a wybór złej metody kosztuje albo jakość, którą widać gołym okiem, albo VRAM, którego nie masz.

Ten przewodnik po kwantyzacji LLM porównuje 7 metod, które liczą się w 2026 roku, a każda liczba ma wskazane źródło.

Najważniejsze wnioski

• Kwantyzacja zamienia pamięć i przepustowość na mierzalny, zwykle niewielki spadek jakości.
• GPTQ i AWQ to metody przede wszystkim GPU-owe; GGUF to format, który działa też na CPU.
• Q4_K_M daje efektywnie około 4,8 bitu na wagę, nie 4. Nazewnictwo ukrywa ten narzut.
• Zgodnie z PR-em k-quants llama.cpp kwantyzacja 6-bitowa mieści się w granicach ~0,1% perpleksji FP16.

Co właściwie robi kwantyzacja z Twoim modelem?

Kwantyzacja LLM zapisuje wagi modelu z niższą precyzją numeryczną, zmniejszając zapotrzebowanie na pamięć i przepustowość kosztem błędów zaokrągleń. Model o 70 miliardach parametrów spada ze 140 GB w FP16 do około 42 GB przy 4 bitach. Inteligencja zostaje, miejsca po przecinku znikają. Każda metoda w tym przewodniku to wariant tej samej wymiany.

Drabina precyzji zaczyna się od FP32 (32 bity), przechodzi przez FP16 i BF16 (po 16 bitów), potem INT8, a na końcu INT4. Każdy stopień zmniejsza liczbę bajtów na parametr o połowę. Formaty zmiennoprzecinkowe definiuje standard IEEE 754, a artykuł Marka Horowitza z 2014 roku "Computing's Energy Problem" pokazał, dlaczego to przenoszenie tych bajtów, a nie operacje na nich, dominuje w koszcie energetycznym. To fizyczny powód, dla którego kwantyzacja przyspiesza inferencję.

Kwantyzację umożliwiają dwa parametry: współczynnik skali (mnożnik odwzorowujący zakres liczb całkowitych z powrotem na wartości rzeczywiste) i punkt zerowy (liczba całkowita reprezentująca 0,0). Kwantyzacja symetryczna wyśrodkowuje zakres na zerze i pomija punkt zerowy; asymetryczna przesuwa go, aby użyć pełnego zakresu liczb całkowitych, gdy wagi skupiają się z dala od zera.

Wagi kwantyzują się dobrze, bo są statyczne i mają rozkład zbliżony do normalnego. Aktywacje nie. Pojedyncze wartości aktywacji bywają stukrotnie większe od mediany i przy naiwnej kwantyzacji rozsadzają błąd zaokrąglenia. Ta asymetria to powód, dla którego większość metod tutaj kwantyzuje tylko wagi (W4A16), a aktywacje zostawia w FP16.

Kwantyzacja po treningu (PTQ) konwertuje gotowy model po zakończeniu uczenia. Kwantyzacja świadoma (QAT) symuluje zaokrąglenia w trakcie treningu, żeby model się do nich dostosował. Wszystko w tym artykule to PTQ. QAT kosztuje więcej obliczeń i wymaga pełnego przebiegu treningowego; to osobna decyzja.

Wiersze INT4 i NF4 to teoretyczne, czyste 4 bity: 4 bity na wagę i nic więcej. Prawdziwe formaty 4-bitowe niosą dodatkowo skale i minima bloków, więc wypadają wyżej. Model 70B w Q4_K_M zajmuje około 42 GB, nie 35. Tabela VRAM w dalszej części używa wartości efektywnych.

Kwantyzacja nie zmniejsza inteligencji modelu. Zmniejsza liczbę miejsc po przecinku, w których tę inteligencję zapisano. A jeśli płacisz za tokeny w inferencji API, obniżanie rachunków za API LLM często zaczyna się od samodzielnego uruchomienia skwantyzowanego modelu.

7 metod kwantyzacji obok siebie

Siedem metod poniżej pokrywa wszystkie ścieżki produkcyjne kwantyzacji LLM w 2026 roku. Dwie są tylko GPU-owe (GPTQ, AWQ), jedna działa wszędzie (GGUF), jedna kwantyzuje w momencie ładowania (BitsandBytes), dwie celują w obsługę o wysokiej przepustowości (SmoothQuant, FP8), a jedna jest natywna dla PyTorch (TorchAO). Właściwy wybór zależy od Twojego sprzętu, nie od tego, która metoda ma najwyższy wynik w rankingu.

GPTQ kwantyzuje warstwa po warstwie, za pomocą odwrotności hesjanu redystrybuując błąd zaokrąglenia między pozostałe wagi. Potrzebuje zbioru kalibracyjnego i GPU. Artykuł o GPTQ opisuje kwantyzację modelu 175B do 3-4 bitów w około 4 GPU-godziny.

AWQ identyfikuje około 1% najważniejszych wag (wagi istotne, wyznaczane na podstawie amplitud aktywacji) i skaluje je, chroniąc przed zaokrągleniem. Artykuł o AWQ (najlepszy artykuł MLSys 2024) raportuje ponad 3-krotne przyspieszenie względem implementacji FP16 z HuggingFace, zarówno na GPU desktopowych, jak i mobilnych.

GGUF to format pliku, nie algorytm. Algorytmem w środku jest blokowy schemat k-quant z PR-a #1684 llama.cpp. To jedyna metoda tutaj działająca na CPU, co czyni ją domyślnym wyborem dla lokalnej inferencji. Co warto do niego wrzucić, podpowiada przegląd modeli open-weight wartych kwantyzacji.

BitsandBytes kwantyzuje przy ładowaniu, a nie z wyprzedzeniem. NF4 (4-bitowy NormalFloat) to jego flagowy format i fundament fine-tuningu QLoRA. Nie wymaga zbioru kalibracyjnego.

SmoothQuant przenosi wartości odstające aktywacji do wag, dzięki czemu oba składniki mogą działać w INT8. Artykuł raportuje do 1,56x przyspieszenia i 2-krotną redukcję pamięci, a celuje w przepustowość przy serwowaniu z dużym batchem, gdzie metody W4A16 zostawiają wydajność na stole.

FP8 (W8A8) to natywna ścieżka na GPU H100 i B200. Praktycznie bezstratna przy 8 bitach, bez bólu kalibracji, a vLLM wspiera ją bezpośrednio.

TorchAO to własna biblioteka kwantyzacji PyTorch, stworzona do współpracy z torch.compile. Jeśli Twój potok już działa w PyTorch, to ścieżka najmniejszego oporu.

Prawdziwe pytania są tylko dwa: czy Twój sprzęt to uciągnie i czy przeżyjesz koszt jakościowy?

Co naprawdę pokazują opublikowane benchmarki?

Opublikowane benchmarki mówią, że kwantyzacja 4-bitowa kosztuje 1-2% perpleksji na modelu 7B, a 6-bitowa mniej niż 0,1%. Te liczby pochodzą z PR-a #1684 llama.cpp (2023), zmierzone przez opiekunów llama.cpp na jednym modelu 7B i karcie RTX 4080. To najczęściej cytowane wyniki w świecie kwantyzacji i są prawdziwe. Tyle że n = 1.

Źródło: PR #1684 llama.cpp (2023). Model 7B, RTX 4080, pomiar opiekunów llama.cpp. n = 1.

Uwaga o kolumnie bitów na wagę: to wartości nominalne dla bazowego typu k-quant, a miksy _K podnoszą efektywną wartość. Q2_K to dobry przykład. Podstawiając nominalne 2,5625 i model o 6,74 miliarda parametrów do wzoru z tego artykułu, wychodzi ~2,0 GB, ale wiersz raportuje plik 2,67 GB, co po odwróceniu daje ~3,4 bitu na wagę. Reszta artykułu używa wartości efektywnych, wyliczonych z tych rozmiarów plików.

Liczby dla metod GPU-owych pochodzą wprost z artykułów. GPTQ raportuje przyspieszenie inferencji end-to-end względem FP16 rzędu 3,25x na A100 i ~4,5x na A6000, przy kwantyzacji modelu 175B do 3-4 bitów w około 4 GPU-godziny. AWQ raportuje „ponad 3-krotne przyspieszenie względem implementacji FP16 z HuggingFace, zarówno na GPU desktopowych, jak i mobilnych", a do tego pierwsze uruchomienie Llama-2 70B na mobilnym GPU przez TinyChat. Cytujemy sformułowania z artykułów, zamiast parafrazować liczby z fałszywą precyzją.

Nasz własny wkład tutaj to arytmetyka. Pamięć na wagi liczy się tak: wagi (GB) ≈ parametry (B) × bity na wagę ÷ 8. Haczyk tkwi w tym, jaką wartość bitów na wagę podstawisz. PR #1684 publikuje wartość dla bazowego typu k-quant (Q4_K = 4,5), a miksy _S/_M/_L leżą powyżej tej bazy, bo przydzielają dodatkowe bity tensorom uwagi i warstwom feed-forward. Wyprowadziliśmy więc wartości efektywne z rozmiarów plików publikowanych w samym PR-ze, na modelu 7B, który ma naprawdę 6,74 miliarda parametrów: Q2_K przy 2,67 GB daje po odwróceniu ~3,4 bpw, Q4_K_S przy 3,56 GB ~4,5, Q6_K przy 5,15 GB ~6,6. Q4_K_M wypada w okolicach 4,8.

To zmienia główną liczbę. Model 70B w Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Większość artykułów podaje 35 GB. Używają 4,0 bpw i całkowicie pomijają narzut skal bloków. Weryfikacja zajmuje jedno kliknięcie: Llama-3.3-70B-Instruct-Q4_K_M.gguf waży 42,5 GB na HuggingFace, tak w repozytoriach bartowski, lmstudio-community, jak i second-state. Przeliczyliśmy na tej podstawie każdą komórkę tabeli VRAM poniżej.

Nasza interpretacja tych liczb: różnica perpleksji między Q6_K (5,9110) a F16 (5,9066) wynosi 0,0044, czyli mniej niż różnica między dwoma różnymi fine-tunami tego samego modelu bazowego. Dlatego rada „po prostu użyj Q4_K_M albo Q5_K_M" najlepiej znosi zderzenie z prawdziwym sprzętem. Kolumna ms/token pokazuje też, że Q2_K nie daje żadnego przyspieszenia względem Q4_K_S (oba 15,5 ms/token), a kosztuje 0,75 perpleksji. Q2_K to najgorsza wymiana w tabeli.

Czego liczby Ci nie powiedzą: perpleksja na wikitext to nie to samo co jakość na Twoich promptach. Jeden model na jednym GPU to n = 1. Wyniki prędkości zależą od rozmiaru batcha. Traktuj je kierunkowo, nie uniwersalnie.

Kwantyzacja 6-bitowa ląduje w granicach około 0,1% perpleksji modelu pełnoprecyzyjnego. Na tym poziomie kompresja jest praktycznie darmowa.

GPTQ vs AWQ: wybór między dwiema metodami GPU

GPTQ i AWQ tworzą 4-bitowe punkty kontrolne GPU ze zbioru kalibracyjnego i obie są dobrze wspierane w vLLM. Różnica leży w obsłudze błędu zaokrąglenia. GPTQ redystrybuuje go między pozostałe wagi za pomocą odwrotności hesjanu. AWQ chroni 1% wag, które aktywacje wskazują jako ważne. Obie działają. Wybór zależy od wzorca serwowania.

GPTQ działa warstwa po warstwie. Dla każdej warstwy kwantyzuje jedną wagę naraz, a potem koryguje pozostałe wagi w tej warstwie, kompensując właśnie wykonane zaokrąglenie. Korekta korzysta z informacji drugiego rzędu z macierzy hesjanu, dlatego do jej obliczenia potrzebny jest zbiór kalibracyjny. Wynik jest mocny w inferencji wsadowej, gdzie przepustowość liczy się bardziej niż opóźnienie pojedynczego tokenu.

AWQ podchodzi inaczej. Identyfikuje wagi istotne, patrząc na amplitudy aktywacji w zbiorze kalibracyjnym, mniej więcej górnego 1% kanałów. Te wagi dostają kanałowy współczynnik skali, który utrzymuje je w zakresie wyższej precyzji podczas zaokrąglania. Zbiór kalibracyjny może być mniejszy niż w GPTQ, a AWQ mniej się do niego dopasowuje nadmiarowo, bo chroni cechy strukturalne, a nie konkretne dane wejściowe. Artykuł raportuje mocne wyniki w serwowaniu wrażliwym na opóźnienia.

Wybierz GPTQ, jeśli: robisz inferencję wsadową na GPU, masz dobry zbiór kalibracyjny dopasowany do Twojej domeny, a metryką jest przepustowość.

Wybierz AWQ, jeśli: obsługujesz żądania pojedynczych użytkowników z niskim opóźnieniem, chcesz mniejszego zbioru kalibracyjnego albo wdrażasz na brzegowych/mobilnych GPU.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Jeśli wybierasz też między silnikami serwującymi, vLLM kontra SGLang omawia tę decyzję osobno.

GGUF i K-Quants: co właściwie znaczy Q4_K_M

GGUF to format pliku, nie algorytm kwantyzacji. Specyfikacja GGUF definiuje kontener na wagi modelu, metadane i dane tokenizera. Algorytm kwantyzacji wewnątrz pliku GGUF to blokowy schemat k-quant (lub i-quant) z PR-a #1684 llama.cpp. Mylenie kontenera z algorytmem to najczęstszy błąd w tej dziedzinie i prowadzi do pytań w stylu „co jest lepsze, GGUF czy GPTQ?", które nie do końca mają sens.

Schemat nazewnictwa rozszyfrowuje się tak. Q oznacza blokowy schemat k-quant; IQ oznacza i-quant z macierzą istotności (nowszy wariant używający macierzy istotności dla lepszej jakości przy tej samej głębokości bitowej). Liczba to nominalna głębokość bitowa. _K odróżnia rodzinę k-quant od starszych formatów jak Q4_0. _S, _M, _L sterują tym, które grupy tensorów dostają dodatkowe bity: small, medium, large. Wyższy przyrostek oznacza więcej bitów dla tensorów uwagi i feed-forward, które liczą się najbardziej.

Wartości efektywne, wyliczone wstecz z rozmiarów plików 7B (6,74 miliarda parametrów) opublikowanych w PR-ze #1684, nie z liczb dla typów bazowych. Wiersze legacy są dokładne z konstrukcji: blok Q4_0 to 32 wagi po 4 bity plus jedna skala FP16, co daje 4,5 bitu na wagę, a Q8_0 to 32 wagi po 8 bitów plus skala FP16, czyli 8,5. PR to potwierdza, wymieniając pliki Q4_0 i Q4_K_S dla 7B z tym samym rozmiarem 3,56 GB.

Q4_K_M to nie 4 bity na wagę. To około 4,8. Skale i minima bloków muszą gdzieś mieszkać, a miks _M dokłada dodatkowe bity do tensorów uwagi i feed-forward, co dokładnie tłumaczy, dlaczego Q4_K_M leży wyżej niż Q4_K_S, a Q3_K_M wyżej niż Q3_K_S, zamiast mu dorównywać.

Dlaczego GGUF działa tam, gdzie GPTQ nie może: wspiera inferencję CPU i offloading warstw między VRAM karty a RAM systemu. Model 32B, który nie mieści się w całości na GPU, może działać z połową warstw przeniesioną poza kartę, wolno, ale działając. GPTQ nie ma ścieżki CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Nowy w lokalnych modelach? Zacznij od uruchomienia pierwszego lokalnego modelu, zanim cokolwiek skwantyzujesz. A jeśli chcesz interfejs w przeglądarce, Open WebUI na Ollamie zajmuje około dziesięciu minut. Dokumentacja GGUF HuggingFace wyjaśnia, jak Hub eksponuje nazewnictwo typów kwantyzacji.

BitsandBytes, Marlin, SmoothQuant i TorchAO

Te cztery pokrywają pozostałe ścieżki produkcyjne. Żadna nie jest „lepszym GPTQ". Rozwiązują różne problemy.

BitsandBytes kwantyzuje w momencie ładowania, nie z wyprzedzeniem. Wskazujesz mu punkt kontrolny FP16, a on w locie konwertuje do NF4 lub FP4. Bez zbioru kalibracyjnego, bez kroku offline. Zasłynął przede wszystkim dzięki QLoRA: zamrożonemu modelowi bazowemu w 4 bitach z trenowanymi na wierzchu adapterami LoRA, co umożliwia fine-tuning modelu 65B na jednej karcie z 48 GB VRAM. QLoRA to technika treningowa, nie inferencyjna, ale to przez nią większość ludzi poznaje BitsandBytes jako pierwsze.

Marlin nie jest metodą kwantyzacji. To kernel GEMM mieszanej precyzji INT4xFP16, który przyspiesza istniejące 4-bitowe punkty kontrolne przy umiarkowanych rozmiarach batcha. Artykuł o Marlinie raportuje przyspieszenia na A100 i H100. Jeśli Twój stos serwujący go wspiera, włączasz go na już skwantyzowanym modelu. Nie „kwantyzuje się Marlinem".

SmoothQuant przesuwa wartości odstające aktywacji do wag poprzez kanałowy współczynnik skalowania, czyniąc W8A8 (wagi i aktywacje w INT8) wykonalnym. Artykuł celuje w serwowanie z dużym batchem, gdzie metody W4A16 zostawiają przepustowość na stole. Jeśli obsługujesz setki równoległych żądań, to jest ten ruch.

TorchAO to natywna dla PyTorch kwantyzacja działająca z torch.compile. Bez zewnętrznych zależności, bez konwersji formatów. Jeśli Twój potok inferencyjny już działa w PyTorch, to opcja o najniższym tarciu. Do lokalnego uruchamiania modeli embeddingowych ścieżka przez Ollamę jest zwykle prostsza, ale TorchAO pasuje do własnych stosów pytorchowych.

Ile VRAM potrzebuje skwantyzowany model?

Wzór to wagi (GB) ≈ parametry (B) × bity na wagę ÷ 8. Model 70B w Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Wartości poniżej są efektywne, wyliczone wstecz z rozmiarów plików publikowanych w PR-ze #1684 llama.cpp, nie z liczb typów bazowych, bo miksy _M zawsze pracują powyżej swojej bazowej wartości k-quant. Przeliczyliśmy, zamiast kopiować zwykły skrót 4,0 bpw.

Wyliczone z efektywnych bitów na wagę: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Wyprowadzone z rozmiarów plików 7B (6,74 miliarda parametrów) z PR-a #1684, a następnie zweryfikowane z opublikowanym buildem 70B: Llama-3.3-70B-Instruct-Q4_K_M.gguf ma 42,5 GB na HuggingFace, wobec przewidywanych tutaj 42,0 GB.

Uczciwe zastrzeżenie: to same wagi. Cache KV, długość kontekstu i narzut frameworka dokładają się na wierzchu. Cache KV skaluje się z długością kontekstu i rozmiarem batcha. Sesja z kontekstem 32k na modelu 70B może dołożyć kilka GB. Tabela wag to podłoga, nie budżet. Twoje okno kontekstu też wynajmuje VRAM. Pełny obraz znajdziesz w szczegółowych wymaganiach VRAM per model.

Której metody kwantyzacji powinieneś użyć?

Twój sprzęt decyduje, zanim zdążą zdecydować preferencje. Metoda, która nie działa na Twoim GPU, nie jest wyborem, jest życzeniem. Tabela poniżej mapuje popularne konfiguracje na metody, które faktycznie na nich działają, w oparciu o ograniczenia sprzętowe i kompromisy jakościowe omówione wyżej.

Dla większości czytelników na sprzęcie konsumenckim gotowy skwantyzowany GGUF Q4_K_M lub Q5_K_M to właściwa odpowiedź. Pobierz z HuggingFace, uruchom w Ollamie lub llama.cpp i przestań optymalizować. Różnica jakości między Q4_K_M a Q5_K_M jest na tyle mała, że powinieneś wybierać na podstawie tego, czy plik się mieści, a nie tabeli perpleksji. Wszystko ponad to jest optymalizacją dla samej optymalizacji i ma sens dopiero, gdy potwierdzisz, że model faktycznie rozwiązuje Twój problem w Q4.

Przewodnik po narzędziach, które faktycznie uruchamiają te modele lokalnie pokrywa stronę serwującą, gdy wybierzesz już poziom kwantyzacji.

Pięć sposobów, na jakie kwantyzacja idzie źle

Awarie kwantyzacji to prawie zawsze problemy konfiguracji, nie metody. Te pięć pojawia się bez przerwy.

1. Zbiór kalibracyjny nie pasuje do Twojej domeny. GPTQ i AWQ dopasowują się do danych kalibracyjnych. Jeśli kalibrujesz na Wikipedii, a wdrażasz na transkrypcjach medycznych, skwantyzowany model działa gorzej na tokenach, których nigdy nie widział. Rozwiązanie: użyj zbioru kalibracyjnego z Twojego rzeczywistego rozkładu wejściowego, pomaga nawet 128 próbek.

2. Zbyt duży rozmiar grupy. Rozmiar grupy w GPTQ steruje tym, ile wag współdzieli współczynnik skali. Standardem jest 128. Wartość 256 lub 512 oszczędza obliczenia podczas kwantyzacji, ale uderza w ścianę jakościową na mniejszych modelach. Rozwiązanie: zostań przy 128, chyba że potwierdzisz, iż jakość trzyma się na Twoich promptach.

3. Oczekiwanie, że Q2_K będzie używalny. Według danych z PR-a #1684 Q2_K kosztuje ~0,87 perpleksji względem F16 i nie daje żadnego przyspieszenia względem Q4_K_S (oba 15,5 ms/token w benchmarku 7B). Dostajesz mniejszy plik i gorszy wynik bez zysku z opóźnień. Rozwiązanie: Q4_K_S to podłoga, chyba że rozmiar pliku jest twardym ograniczeniem.

4. Benchmarkowanie na perpleksji wikitext zamiast na własnych promptach. Perpleksja to metryka modelowania języka. Nie mierzy, czy model trzyma się Twojego system promptu, formatuje JSON poprawnie ani obsługuje słownictwo Twojej domeny. Rozwiązanie: przepuść 20-30 swoich prawdziwych promptów przez model skwantyzowany i nieskwantyzowany i porównaj wyniki.

5. Mylenie GGUF-kontenera z algorytmem kwantyzacji w środku. To prowadzi do porównywania „GGUF vs GPTQ", jakby były tą samą kategorią. Nie są. GGUF to format pliku. Schemat k-quant w środku jest algorytmem. Rozwiązanie: porównuj poziomy k-quant (Q4_K_M vs Q5_K_M), nie formaty plików.

Często zadawane pytania

Czym jest kwantyzacja LLM?

Kwantyzacja LLM zmniejsza precyzję numeryczną wag modelu, zwykle z 16-bitowej zmiennoprzecinkowej do 4- lub 8-bitowych liczb całkowitych. To obcina zużycie pamięci i przyspiesza inferencję przez redukcję przepustowości. Model 70B spada ze 140 GB do około 42 GB przy 4 bitach. Koszt jakościowy to zwykle 1-2% perpleksji przy 4 bitach, mniej przy 6 bitach.

Czy kwantyzacja obniża dokładność modelu?

Tak, ale mniej, niż większość osób się spodziewa. Według benchmarków z PR-a #1684 llama.cpp Q4_K_S na modelu 7B kosztuje około 2% perpleksji względem F16, a Q6_K mniej niż 0,1%. Praktyczny wpływ na realne prompty jest często mniejszy, niż sugeruje liczba perpleksji, szczególnie od Q4_K_M wzwyż.

Co jest lepsze: GPTQ czy AWQ?

Żadna metoda nie jest uniwersalnie lepsza. GPTQ używa redystrybucji błędu przez odwrotność hesjanu i pasuje do wsadowej inferencji GPU. AWQ chroni wagi istotne przez skalowanie świadome aktywacji i pasuje do serwowania wrażliwego na opóźnienia. AWQ potrzebuje mniejszego zbioru kalibracyjnego i mniej się do niego dopasowuje nadmiarowo. Jeśli obsługujesz żądania pojedynczych użytkowników z niskim opóźnieniem, zacznij od AWQ.

Co oznacza Q4_K_M?

Q4_K_M to poziom kwantyzacji k-quant GGUF. „Q4" oznacza nominalną głębokość 4 bitów, „K" oznacza blokowy schemat k-quant (w odróżnieniu od legacy Q4_0), a „M" oznacza medium: tensory uwagi i feed-forward dostają dodatkowe bity. Efektywne bity na wagę to około 4,8, nie 4,0, bo skale i minima bloków dodają narzut, a miks medium dokłada więcej na wierzchu.

Czy mogę uruchomić skwantyzowany model na CPU?

Tak, ale tylko przez GGUF. GPTQ i AWQ to formaty tylko GPU. Modele k-quant GGUF działają na CPU przez llama.cpp lub Ollamę i wspierają offloading warstw między VRAM karty a RAM systemu. Q4_K_M to standardowy kwant CPU. Spodziewaj się wolniejszej generacji tokenów niż na GPU, ale inferencja działa.

Jaka jest różnica między GGUF a GGML?

GGML to starsza biblioteka tensorów i format pliku, którego llama.cpp używało pierwotnie. GGUF zastąpił go w sierpniu 2023 jako bardziej elastyczny format kontenera z lepszą obsługą metadanych. Pliki GGUF to to, co pobierasz dziś z HuggingFace. Pliki GGML są legacy i praktycznie już niedystrybuowane.

Skwantyzować model samemu czy pobrać gotowy?

Najpierw pobierz gotowy. Społeczności llama.cpp i HuggingFace skwantyzowały już większość popularnych modeli na każdym poziomie. Samodzielna kwantyzacja ma sens tylko, gdy potrzebujesz konkretnego zbioru kalibracyjnego dla swojej domeny albo gdy nie istnieje gotowa wersja dla Twojego modelu.

Kiedy użyć kwantyzacji zamiast mniejszego modelu?

Użyj kwantyzacji, gdy potrzebujesz możliwości większego modelu, ale nie mieści się w pamięci. Skwantyzowany model 70B generalnie przewyższa nieskwantyzowany model 13B w złożonych zadaniach rozumowania. Użyj mniejszego modelu, gdy ograniczeniem jest opóźnienie, bo mniejsze modele generują tokeny szybciej niezależnie od kwantyzacji.

Jaka jest różnica między kwantyzacją a destylacją?

Kwantyzacja zmniejsza precyzję numeryczną wag istniejącego modelu. Destylacja trenuje mniejszy model tak, by naśladował większy, tworząc prawdziwie inną (mniejszą) architekturę. Kwantyzacja zachowuje architekturę oryginału i w zasadzie jest odwracalna. Destylacja tworzy nowy model i wymaga przebiegu treningowego.

Wersja krótka: kwantyzacja to sposób, żeby zmieścić model, którego chcesz, w sprzęcie, który masz. Dla większości osób na konsumenckich GPU lub Apple Silicon gotowy skwantyzowany GGUF Q4_K_M pobrany z HuggingFace to całe rozwiązanie. GPTQ i AWQ to odpowiedzi dla serwowania GPU. FP8 i SmoothQuant to odpowiedzi dla produkcyjnej przepustowości. Wszystko inne jest optymalizacją, gdy potwierdzisz już, że model działa.

Jeśli decydujesz, co hostować samemu, i chcesz drugiej opinii o parowaniu sprzętu z metodą, chętnie pogadamy.