Przewodnik po kwantyzacji modeli: od podstaw do obsługi produkcyjnej

Viacheslav Dubrov

2026-07-05 · Zaktualizowano 2026-09-05 · 24 min · Inżynieria modeli · Infrastruktura AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Model może mieścić się w pamięci GPU, a mimo to być złym wyborem do obsługi. Kwantyzacja zmniejsza liczbę bitów używanych przez wagi, aktywacje lub KV cache, ale kompresowany element i kernel, który go wykonuje, wpływają na różne części obciążenia.

Zacznij od ustalenia, co sprawia, że żądanie jest zbyt wolne lub zbyt duże. Przetwarzanie wejściowego promptu nazywa się prefill, a generowanie odpowiedzi token po tokenie — decode. Prefill może być ograniczony przez moc obliczeniową GPU, natomiast decode może być ograniczony przez szybkość ładowania wag z pamięci. Wagi modelu i rosnący KV cache mogą również wyczerpać pamięć GPU. Pierwsza tabela mapuje te problemy na możliwe rozwiązania; kolejne sekcje wyjaśniają obliczenia i kontrole potrzebne przed wdrożeniem.

Niższa precyzja jest tylko kandydatem. Decyzja wymaga zarówno wyników jakości zadania, jak i pomiarów obsługi dla modelu, runtime’u i ruchu, których będziesz używać. Przedstawione tu benchmarki to opublikowane wyniki innych zespołów; repozytorium towarzyszące zawiera polecenia do planowania i ewaluacji, ale nie stanowi dowodu, że Twoje wdrożenie osiągnie takie same wyniki.

Skrócony materiał i porównanie metod znajdziesz w LLM Quantization Formats.

1. Zacznij od wąskiego gardła

Zanim wybierzesz precyzję, ustal, co ogranicza obciążenie. Może to być pamięć zajmowana przez wagi modelu, obliczenia prefill, przepustowość podczas decode albo KV cache, a nie sama precyzja numeryczna.

Typowe wąskie gardła i punkty wyjścia:

Potraktuj tę tabelę jak mapę. Poniższe sekcje wyjaśniają, dlaczego punkty wyjścia są różne.

Notacja używana w recepturach obsługi

• W{x}A{y} określa precyzję obsługiwanych wag i obliczeń aktywacji, zwykle w ścieżkach GEMM silników obsługi. W4A16 przechowuje wagi w postaci 4-bitowej i utrzymuje aktywacje w precyzji 16-bitowej. W8A8 używa 8-bitowych wag i aktywacji w obsługiwanych ścieżkach obliczeniowych, ale nie definiuje automatycznie trwałego typu danych każdego tensora runtime’u.
• FP8, INT8, INT4, NF4 to formaty liczbowe. Określają, jakie wartości można reprezentować.
• GPTQ, AWQ, SmoothQuant, QuaRot to algorytmy. Określają, jak odwzorować wytrenowany model na format o niższej precyzji.
• GGUF to format pliku przechowujący tensory i metadane dla runtime’ów w stylu GGML i llama.cpp. Plik GGUF może zawierać niekwantyzowane typy tensorów, takie jak F16, BF16 lub F32, a także kwantyzowane kodowania. Presety obejmują Q4_K_M, Q5_K_M, Q8_0, IQ*, TQ* i MXFP4. To kodowanie tensora określa wybór kwantyzacji. Samo GGUF nie opisuje receptury obsługi CUDA-style FP8 W8A8.
• KV cache to cache attention używany podczas generowania. Przechowuje wcześniejsze klucze i wartości, aby model nie musiał przeliczać całej rozmowy przy każdym tokenie.
• Kwantyzacja KV cache przechowuje buforowane tensory aktywacji key/value w formacie cache o niższej precyzji, takim jak FP8, INT8, INT4 lub INT2, zależnie od obsługi runtime’u. Różni się to od prefix caching, PagedAttention i offloadu, które określają odpowiednio, czy wpisy cache są ponownie wykorzystywane, jak są alokowane oraz gdzie się znajdują.
• GEMM oznacza mnożenie macierzy ogólnego przeznaczenia. Większość czasu inferencji transformera zajmuje mnożenie macierzy.

2. Kwantyzacja to kontrolowane zaokrąglanie

Kwantyzacja odwzorowuje wartości o wysokiej precyzji na mniejszy zbiór reprezentowalnych wartości. To podstawowa definicja używana zarówno przez Hugging Face Optimum, jak i TensorRT-LLM. Oszczędzasz pamięć i przepustowość. Jednocześnie wprowadzasz błąd zaokrąglenia.

INT4 zapewnia tylko 16 dyskretnych wartości, więc odwzorowanie wag BF16 na tę siatkę powoduje błąd zaokrąglenia. Metody takie jak GPTQ, AWQ i SVDQuant koncentrują się na zachowaniu wartości odstających i zmniejszeniu błędu rekonstrukcji. Dobre odwzorowanie oszczędza pamięć przy niewielkiej utracie jakości. Słabe może pogorszyć rozumowanie, wykonywanie instrukcji lub wierność wizualną.

Odwzorowanie symetryczne i asymetryczne

Zgodnie z odwzorowaniem afinicznym używanym w popularnych przewodnikach po kwantyzacji, kwantyzacja odwzorowuje ciągłą wartość float $x \in [\beta, \alpha]$ na dyskretną siatkę.

• $x$ to oryginalna wartość o wysokiej precyzji.
• $x_q$ to wartość kwantyzowana.
• $s$ to skala, czyli rozmiar kroku.
• $z$ to punkt zerowy, czyli pozycja całkowita reprezentująca 0.0.
• $[q_{\min}, q_{\max}]$ to docelowy zakres liczb całkowitych. Ten symetryczny przykład używa $[-7, 7]$, które ma 15 wartości i dokładnie reprezentuje zero. Inne formaty INT4 ze znakiem wykorzystują wszystkie 16 wartości, na przykład $[-8, 7]$.

Kwantyzacja symetryczna centruje siatkę wokół zera i ustawia $z = 0$:

Jest to przyjazne sprzętowo, ponieważ obliczenia runtime’u nie wymagają odejmowania przesunięcia punktu zerowego. Stos kwantyzacji PyTorch udostępnia te afiniczne wybory skali i punktu zerowego jako podstawowe parametry kwantyzacji w torchao.

Kwantyzacja asymetryczna przesuwa siatkę, aby objąć zakresy o rozkładzie skośnym:

Przesunięta siatka może lepiej zachowywać aktywacje wyłącznie dodatnie, ale przesunięcie zwiększa nakład obliczeniowy, chyba że kernel dobrze je obsługuje.

Znaczenie granularności skali

Współczynnik skali może obejmować cały tensor wag, jeden kanał albo niewielką grupę wartości. Dokumentacja FP8 KV cache w vLLM stosuje to samo rozróżnienie między strategiami skali per-tensor i per-attention-head. Mniejsze grupy zwykle lepiej zachowują jakość, ale wymagają większej ilości metadanych skali.

Wagi są statyczne, więc ich skale można obliczyć offline przed załadowaniem modelu. Aktywacje zmieniają się przy każdym tokenie, przez co ich zakresy zależą od obciążenia.

KV cache znajduje się pomiędzy tymi przypadkami. Klucze i wartości zaczynają jako runtime’owe tensory aktywacji: każda warstwa oblicza je ze stanów ukrytych podczas przebiegu w przód. Po wygenerowaniu przestają być tymczasowymi wynikami pośrednimi matmul i stają się trwałym stanem obsługi, który attention odczytuje przy kolejnych tokenach.

Silnik obsługi może przechowywać ten stan w niższej precyzji i trzymać obok niego metadane skali. Quantized KV Cache w vLLM, FP8 KV Cache w TensorRT-LLM oraz QuantizedCache w Transformers udostępniają ten wybór przechowywania.

Precyzja przechowywania cache pozostaje odrębna od precyzji aktywacji używanej wewnątrz linearnych kerneli. „Kwantyzacja KV cache” oznacza jedną optymalizację cache, a nie każdą technikę ponownego wykorzystywania, alokowania lub przenoszenia wpisów cache.

PTQ i QAT zachodzą na różnych etapach

Post-training quantization, czyli PTQ, kompresuje wytrenowany model po zakończeniu treningu. Quantization-aware training, czyli QAT, wystawia model na szum kwantyzacji podczas treningu, aby mógł się do niego dostosować.

Dane kalibracyjne muszą przypominać ruch, który będziesz obsługiwać. Na przykład ścieżka kalibracji KV cache w vLLM używa wyselekcjonowanego zbioru danych przez llm-compressor. Jeśli produkcyjne prompty to długie ślady RAG, krótkie akapity z Wikipedii mogą nie uchwycić zakresów aktywacji generowanych przez te ślady. Kalibracja wybiera statyczne zakresy i skale aktywacji lub cache na podstawie rozkładu krótkich tekstów; nie dostraja stałych parametrów modelu. Rzeczywiste prompty z długim kontekstem mogą generować inne wzorce aktywacji. Ewaluacje kwantyzacji dla długiego kontekstu mierzą to ryzyko bezpośrednio.

3. Formaty liczbowe wyznaczają wymagania sprzętowe

Format liczbowy określa, jakie wartości model może reprezentować w pamięci. Wydajne obliczenia wymagają kerneli runtime’u i obsługi sprzętowej tej samej szerokości bitowej oraz formatu. TensorRT-LLM dokumentuje zarówno listę receptur, jak i macierz obsługi sprzętowej.

BF16 i FP16 używają po 16 bitów, ale rozdzielają precyzję w inny sposób, dlatego zawodzą w innych sytuacjach. BF16 zachowuje 8-bitowy zakres wykładnika FP32 i jest odporniejszy na overflow. FP16 ma więcej bitów mantysy i węższy zakres wykładnika, więc skoki aktywacji wymagają większej uwagi. Ewaluacja Kurtic et al. jawnie używa BF16 jako baseline’u przy porównywaniu formatów obsługi FP8, INT8 i INT4.

FP8 ma dwa popularne warianty. E4M3 zapewnia większą precyzję i zwykle jest używany dla wag oraz aktywacji w przebiegu w przód. E5M2 oferuje większy zakres dynamiczny i lepiej nadaje się do gradientów lub zmiennych ścieżek aktywacji. vLLM udostępnia oba typy danych FP8 E4M3 i E5M2 dla KV cache. W badaniu Kurtic et al. na ACL 2025, „Give Me BF16 or Give Me Death”, FP8 W8A8 było praktycznie bezstratne dla rodziny Llama-3.1 w ponad 500 000 ewaluacji. Wynik dotyczy tej rodziny modeli, zestawu ewaluacyjnego i konfiguracji obsługi. Każde wdrożenie wymaga własnej kontroli jakości przed wydaniem.

Blackwell dodaje formaty microscaling, takie jak MXFP8 i NVFP4. Zamiast jednej skali dla całego tensora lub wiersza microscaling używa bardzo małych bloków. Objaśnienie NVFP4 firmy NVIDIA opisuje 4-bitowe wartości zmiennoprzecinkowe w blokach po 16, ze współczynnikami skali FP8 i skalą wyższego poziomu FP32. Podejście to ma zapewniać rozmiar zbliżony do INT4 przy zachowaniu charakterystyki liczb zmiennoprzecinkowych. Wymaga jednak zgodnej architektury sprzętowej, kompilatora i obsługi runtime’u, dlatego TensorRT-LLM wymienia obsługę FP4 i FP8 według generacji GPU.

4. Weight-only a kwantyzacja wag i aktywacji

Notacja WxAy opisuje precyzję wag i aktywacji, które podczas inferencji obciążają GPU w różny sposób.

Podczas prefill model przetwarza wejściowy prompt. Ta faza jest zwykle ograniczona obliczeniowo, ponieważ GPU wykonuje duże mnożenia macierzy, dlatego receptury W8A8 FP8/INT8 mają znaczenie w obsłudze ukierunkowanej na przepustowość.

Podczas decode model generuje po jednym tokenie. Ta faza jest często ograniczona przepustowością pamięci, ponieważ GPU stale ładuje wagi z VRAM, aby wygenerować kolejny token. Prace dotyczące weight-only, takie jak GPTQ i AWQ, celują w to ograniczenie przez zmniejszenie liczby bajtów wag.

W4A16 kompresuje wagi i utrzymuje aktywacje w BF16 lub FP16. GPU ładuje mniej bajtów wag, a następnie dekwantyzuje wagi z powrotem do wyższej precyzji na potrzeby mnożenia. Pomaga to podczas decode i w problemach z dopasowaniem modelu do pamięci. Prefill ograniczony obliczeniowo może odnieść niewielką korzyść, ponieważ obliczenia macierzowe nadal działają w 16 bitach.

W8A8 kompresuje wagi i tensory aktywacji używane przez obsługiwane kernele matmul. Jeśli sprzęt ma natywne tensor cores niskiej precyzji, silnik obsługi może wykonywać obliczenia macierzowe bezpośrednio w FP8 lub INT8. FP8 może więc pomóc w obsłudze z wysoką przepustowością, zmniejszając ruch pamięci i wykorzystując szybszą arytmetykę. KV cache ma własne ustawienie przechowywania, dlatego osobno sprawdź typ cache lub implementację cache w runtime’ie.

Jeśli model ledwo mieści się w VRAM, zacznij od kwantyzacji weight-only, aby zmniejszyć zajmowaną pamięć. Jeśli model się mieści, ale ma problemy z przepustowością przy dużych batchach, oceń FP8 lub INT8 W8A8, aby przyspieszyć fazę obliczeniową. Jeśli problemy z pamięcią pojawiają się tylko podczas długich rozmów, najpierw oszacuj składnik KV cache. Przetestuj kwantyzację KV cache, gdy ten składnik dominuje. Włącz prefix caching, gdy dominują powtarzające się prefiksy.

5. Algorytmy a kernele runtime’u

Algorytmy kwantyzacji, takie jak GPTQ lub AWQ, definiują sposób odwzorowania wag modelu na niższą precyzję. Kernele runtime’u, takie jak Marlin lub własne kernele vLLM, to niskopoziomowy kod GPU wykonujący mnożenie macierzy. Silnie skompresowany model będzie działał szybko tylko wtedy, gdy istnieje zoptymalizowany kernel dla jego konkretnego formatu kwantyzacji.

Benchmark vLLM firmy JarvisLabs dla Qwen2.5-32B-Instruct na NVIDIA H200 dobrze pokazuje wpływ kernela:

Nie przenoś tych liczb bezpośrednio do własnego stosu. Pochodzą z jednego modelu, jednej klasy GPU i jednej konfiguracji oprogramowania. Pokazują węższą, ale ważną rzecz: nazwa algorytmu na checkpointcie nie mówi, jak szybko będzie działać obsługa.

Na przykład AWQ i Marlin-AWQ używają tych samych 4-bitowych wag. Implementacja Marlin jest znacznie szybsza, ponieważ jej kernel CUDA łączy dekwantyzację i mnożenie macierzy w jedną, silnie zoptymalizowaną operację GPU.

Benchmarkuj baseline i warianty skompresowane przy tej samej mieszance promptów i za pomocą tego samego narzędzia. Uruchom każdy wariant jako serwer i nadaj mu stabilną nazwę modelu API; vllm bench serve wysyła żądania do tego API, zamiast samodzielnie ładować checkpoint:

vllm serve ./outputs/Qwen2.5-32B-Instruct-AWQ-W4A16 \
  --served-model-name qwen2.5-32b-awq \
  --host 127.0.0.1 \
  --port 8000

vllm bench serve \
  --backend openai \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/completions \
  --model qwen2.5-32b-awq \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256

Śledź przepustowość, TTFT, opóźnienie między tokenami, zużycie pamięci i jakość zadania. Gdy niektóre z tych parametrów zmieniają się w przeciwnych kierunkach, właśnie ten kompromis trzeba zobaczyć przed wdrożeniem.

Lista algorytmów

Potraktuj tę tabelę jak mapę, a nie ranking:

Toolchain aktywnie się zmienia. AutoGPTQ zostało zarchiwizowane w kwietniu 2025, a AutoAWQ zostało zarchiwizowane i oficjalnie uznane za przestarzałe w maju 2025. Dla nowych checkpointów compressed-tensors używanych przez vLLM zacznij od llm-compressor. Użyj GPTQModel, gdy potrzebujesz aktywnej ścieżki GPTQ z Marlin, Machete, opcjami pamięci MoE lub offloadem na dysk.

Pruning i distillation również zmniejszają koszt obsługi, ale za pomocą odrębnych workflow. Ustrukturyzowana rzadkość 2:4 usuwa wagi według wzorca obsługiwanego przez rzadkie tensor cores NVIDIA. Distillation trenuje mniejszy model student, aby naśladował większy, co może dobrze działać dla wąskich zadań. Uwzględnij którąkolwiek z tych ścieżek na krótkiej liście tylko wtedy, gdy projekt może obsłużyć dodatkową pracę związaną z pruningiem lub treningiem.

6. Pamięć obsługi to nie tylko wagi

Skompresowany checkpoint jest tylko częścią śladu pamięci obsługi. Oszacuj cały runtime, zanim zdecydujesz, czy sama kwantyzacja wag wystarczy. PagedAttention wskazuje KV cache jako istotny składnik pamięci obsługi.

Kwantyzacja offline może być ograniczona do pojedynczej warstwy. Narzędzia takie jak llm-compressor mogą załadować blok transformera, wykonać kalibrację i obliczenia kwantyzacji, zapisać skompresowany blok i przejść dalej. Dzięki temu szczytowe zużycie pamięci GPU pozostaje bliżej rozmiaru największej aktywnej warstwy powiększonego o bufory kalibracyjne. Nadal potrzebujesz RAM CPU i miejsca na dysku dla źródłowego checkpointu, ale GPU nie zawsze musi przechowywać cały model BF16.

Szczytowe zużycie pamięci GPU podczas kwantyzacji offline może wyglądać raczej tak:

Obsługa jest bardziej wymagająca. Cały skompresowany checkpoint musi pozostać w pamięci razem z KV cache i buforami runtime’u. KV cache rośnie wraz z długością kontekstu i rozmiarem aktywnego batcha:

Gdzie:

• $L$ to liczba warstw.
• $H_{\text{kv}}$ to liczba głów key-value attention. Grouped-query attention zmniejsza tę wartość, pozwalając wielu głowom query współdzielić mniejszą liczbę głów KV.
• $D$ to wymiar każdej głowy, często 128 lub 256.
• $S_{\text{ctx}}$ to liczba tokenów promptu plus wygenerowanych tokenów.
• $B_{\text{batch}}$ to aktywny batch obsługi.
• $\text{BytesPerValue}$ to 2 dla BF16 lub FP16 oraz 1 dla FP8 lub INT8. Tryb FP8 KV cache w vLLM jest przykładem stosu obsługi używanym w tym artykule.

Kwantyzacja KV cache zmienia przechowywanie, a ponowne użycie zmienia alokację

KV cache można kwantyzować podczas inferencji. Każdy krok decode generuje tensory aktywacji K i V dla nowego tokena. Model W8A8 może już używać FP8 lub INT8 w obsługiwanych obliczeniach projekcji, ale cache pozostaje odrębnym obiektem przechowywania.

Wiele stosów obsługi przechowuje ten obiekt w typie danych modelu lub cache. Aby to zmienić, włącz typ danych KV cache, użyj checkpointu ze skalami cache albo wybierz implementację kwantyzowanego cache.

Po włączeniu kwantyzacji KV cache silnik zapisuje wpisy jako reprezentację o niższej precyzji wraz ze skalami. Późniejszy attention albo dekwantyzuje cache wewnątrz kernela, albo — w niektórych backendach — wykonuje część operacji attention w domenie kwantyzowanej.

Stabilna dokumentacja Quantized KV Cache w vLLM udostępnia to bezpośrednio za pomocą kv_cache_dtype="fp8" lub --kv-cache-dtype fp8. vLLM obsługuje formaty cache FP8 E4M3 i E5M2 oraz strategie skali per-tensor i per-attention-head. Może używać skal domyślnych lub kalibracji zbioru danych przez llm-compressor. W połączeniu z FlashAttention 3 vLLM może również wykonywać operacje attention w domenie FP8, kwantyzując query oprócz key i value.

TensorRT-LLM udostępnia FP8 KV cache przez KvCacheConfig(dtype='fp8') i wymienia FP8 KV cache oraz NVFP4 KV cache jako osobne receptury kwantyzacji, niezależne od kwantyzacji wag i aktywacji. Hugging Face Transformers również ma ścieżkę QuantizedCache przez cache_implementation="quantized", gdzie hqq obsługuje formaty cache int2, int4 i int8, a quanto obsługuje int2 i int4.

Zwykłe KV caching przechowuje wcześniejsze klucze i wartości, aby uniknąć ich ponownego obliczania. Prefix caching ponownie wykorzystuje bloki cache między żądaniami z tym samym prefiksem. PagedAttention zmniejsza fragmentację i poprawia alokację, natomiast offload KV przenosi bloki cache między warstwami pamięci. Te połączenia zależą od runtime’u. QuantizedCache w Hugging Face nie obsługuje offloadu. vLLM dokumentuje kwantyzowany KV cache osobno od prefix caching i innych funkcji zarządzania cache. Zweryfikuj każdą kombinację w runtime’ie, który wdrażasz.

Ryzyko jakości różni się również od weight-only PTQ. Kwantyzacja KV cache wprowadza błąd do stanu attention odczytywanego przy każdym kolejnym kroku decode. Osobno testuj wyszukiwanie w długim kontekście, zachowanie wieloturowe, bezpieczeństwo i odmowy, formatowanie korzystania z narzędzi oraz opóźnienie wyjścia. KVQuant, KIVI i badanie FP8 KV cache w vLLM traktują kwantyzację KV cache jako osobny problem.

Porównaj, ile pamięci zaoszczędzi każda zmiana. Użyj powyższego równania cache przy tym samym batchu i długości kontekstu dla bieżącego i proponowanego typu danych cache; odejmij proponowany rozmiar od bieżącego. Zrób to samo dla dwóch rozważanych formatów wag. Przykładowo porównaj oszczędność wynikającą ze zmiany cache z BF16 na FP8 z oszczędnością wynikającą ze zmiany wag z BF16 na INT4. Najpierw przetestuj opcję o większej szacowanej oszczędności, jeśli runtime ją obsługuje. Następnie zmierz rzeczywiste zużycie pamięci i jakość; żadne z tych oszacowań nie uwzględnia każdej alokacji wykonywanej przez runtime.

7. Sprzęt zawęża wybór

Rozmiar wag łatwo oszacować na podstawie liczby parametrów i precyzji przechowywania — to ta sama idea wymiarowania, która jest używana w dyskusjach o pamięci obsługi KV cache:

Modele mixture-of-experts mogą aktywować mniej parametrów na token, ale pełny zestaw wag nadal musi znajdować się gdzieś, chyba że runtime obsługuje offload. Macierz obsługi kwantyzacji TensorRT-LLM traktuje rodziny modeli MoE jako cele wdrożeniowe z własnymi obsługiwanymi recepturami.

Sprzęt docelowy ogranicza formaty kwantyzacji, które są wykonalne:

• Obsługa na CPU zależy od instrukcji wektorowych, takich jak AVX-512 lub AMX. Plik GGUF załadowany przez llama.cpp to praktyczna ścieżka.
• Apple Silicon używa pamięci zunifikowanej, więc modele lokalne mogą korzystać z dużej współdzielonej puli RAM zamiast dedykowanej pamięci VRAM. GGUF i llama.cpp pozostają typową ścieżką lokalnego runtime’u, ponieważ GGUF jest tworzony dla executorów GGML.
• NVIDIA Ampere obsługuje ścieżki obsługi tensor cores INT8, ale nie natywne obliczenia tensor cores FP8 W8A8. Typowe wybory to kwantyzacja weight-only W4A16 lub statyczne INT8, zgodnie z macierzą obsługi sprzętowej TensorRT-LLM.
• NVIDIA Ada i Hopper obsługują ścieżki obsługi FP8 w TensorRT-LLM. Warto przetestować obsługę FP8 W8A8 na tych GPU.
• NVIDIA Blackwell dodaje NVFP4 i obsługę microscaling, ale ścieżka programowa nadal ma znaczenie. Wczesne stosy niskobitowych liczb zmiennoprzecinkowych traktuj jako wrażliwe na wersję.

8. Kalibracja i ewaluacja przed wdrożeniem

Model, który się ładuje, przeszedł smoke test. Wdrożenie wymaga kontroli jakości i obsługi dla docelowego obciążenia. Najnowsze ewaluacje kwantyzacji raportują różne wyniki dla obsługi LLM, zadań z długim kontekstem oraz modeli intensywnie wykorzystujących rozumowanie.

Do kalibracji używaj promptów przypominających produkcję:

• Uwzględnij ślady RAG, zapytania SQL, historie agentów, zadania koderskie, payloady wywołań narzędzi i prompty systemowe z docelowego obciążenia. Static PTQ zależy od zgodności danych kalibracyjnych z rozkładem produkcyjnym.
• Dopasuj długości sekwencji. Krótkie prompty jednokrokowe nie ujawnią zachowania aktywacji dla długiego kontekstu.
• Pozostaw embed_tokens i lm_head w wyższej precyzji, jeśli metoda lub runtime na to pozwala — to typowy wzorzec wykluczeń w recepturach LLM Compressor.
• Użyj wystarczającej liczby próbek, aby ustabilizować zakresy aktywacji. Przykład KV cache w vLLM ustawia NUM_CALIB_SAMPLES = 512. Potraktuj to jako jeden udokumentowany przykład, a nie uniwersalną liczbę. Właściwa liczba próbek zależy od metody, modelu, długości sekwencji i obciążenia produkcyjnego.
• Przed użyciem logów produkcyjnych usuń sekrety i prywatne dane użytkowników.

W ewaluacji testuj zarówno jakość językową, jak i zachowanie podczas obsługi:

• Perplexity na standardowym korpusie wykrywa ogólne pogorszenie języka, ale benchmark JarvisLabs przypomina, że perplexity i przepustowość mogą zmieniać się niezależnie.
• Zadania domenowe wykrywają problemy, które ukrywa perplexity. Użyj HumanEval do kodowania, MMLU dla szerokiej wiedzy oraz AIME lub MATH-500 dla rozumowania matematycznego, jeśli te domeny mają znaczenie.
• Kontrole formatu są ważne dla systemów agentowych. Testuj zgodność z JSON Schema, wyjście Markdown, kształt wywołań narzędzi i zachowanie przy odmowie, ponieważ ewaluacje modeli kwantyzowanych mogą nie wykryć problemów na poziomie aplikacji, nawet gdy zagregowana dokładność benchmarku pozostaje stabilna.
• Testy długiego kontekstu wykrywają uszkodzenia spowodowane kwantyzacją KV cache. Needle-in-a-haystack jest prymitywny, ale wyniki kwantyzacji dla długiego kontekstu pokazują, dlaczego takie kontrole należy wykonać przed wdrożeniem.
• Testy obciążeniowe powinny raportować przepustowość, TTFT, opóźnienie między tokenami, maksymalną pojemność batcha i szczytowe zużycie pamięci. vLLM udostępnia te pomiary przez vllm bench serve.

W aplikacji RAG podczas porównywania baseline’u i kwantyzowanego generatora nie zmieniaj pytań ani pobranych dowodów. Takie porównanie izoluje zmianę generatora. Następnie uruchom cały pipeline, aby sprawdzić wynik obsługi, korzystając z przewodnika po ewaluacji RAG do oddzielenia błędów wyszukiwania od odpowiedzi niepopartych dowodami. W przypadku agenta uwzględnij, czy te same zadania kończą się poprawnymi wywołaniami narzędzi i akceptowalnymi efektami ubocznymi. Sam mniejszy checkpoint nie odpowiada na żadne z tych pytań.

Modele intensywnie wykorzystujące rozumowanie ewaluuj rygorystycznie. Kwantyzacja poniżej 4 bitów lub nierektyfikowane W4A4 może pogorszyć dokładność rozumowania, nawet gdy bazowe perplexity wygląda stabilnie — to główne ostrzeżenie z badania modeli rozumujących po kwantyzacji.

9. Workflow repozytorium towarzyszącego

Repozytorium towarzyszące, slavadubrov/model-compression-demo, ma ułatwić odtwarzalność procesu decyzyjnego. Używa uv i koncentruje się na planowaniu, recepturach, dry runach oraz konfiguracjach benchmarków opartych na tych samych źródłach, które wykorzystano tutaj: vLLM, LLM Compressor, TensorRT-LLM i pracach dotyczących algorytmów.

Publiczny README w rewizji 8b45003849e830bed2ff341a9f027b017d932c1f został sprawdzony 2026-08-16. Poniższe polecenia mają charakter ilustracyjny i nie zostały zweryfikowane przez wykonanie na potrzeby tego artykułu. Uruchom je z tego przypiętego checkoutu; plan benchmarku wymaga docelowego sprzętu obsługi.

Nie kopiuj wyniku receptury FP8 z tej przypiętej rewizji. Jej polecenie recipe --algorithm fp8-dynamic generuje wewnętrznie niespójny model i ścieżkę wyjściową. Polecenie pozostaje pominięte, dopóki repozytorium towarzyszące nie zostanie naprawione.

Sklonuj repozytorium i sprawdź obsługiwane algorytmy:

git clone https://github.com/slavadubrov/model-compression-demo.git
cd model-compression-demo
git checkout 8b45003849e830bed2ff341a9f027b017d932c1f
uv run python demo.py list-algorithms

Zacznij od planowania i wymiarowania:

uv run python demo.py plan \
  --model-preset qwen3-8b \
  --goal fit-memory \
  --hardware ampere \
  --context 4096 \
  --concurrency 4

uv run python demo.py estimate \
  --model-preset qwen3-8b \
  --scheme w4a16 \
  --context 4096 \
  --concurrency 4

uv run python demo.py plan \
  --model-preset qwen3-0.6b \
  --hardware cpu

Następnie wygeneruj recepturę i wyświetl podgląd kwantyzacji, zanim zużyjesz czas GPU:

uv run python demo.py recipe --algorithm gptq-w4a16

uv run python demo.py quantize --dry-run
uv run python demo.py quantize \
  --algorithm gptq-w4a16 \
  --model Qwen/Qwen3-8B \
  --dry-run

Pierwsze polecenie przygotowuje polecenie obsługi GPTQ W4A16. Drugie planuje porównanie z 8-bitowym baseline’em round-to-nearest (RTN), dzięki czemu możesz zmierzyć, czy mniejszy model 4-bitowy jest wart kompromisów jakości i szybkości:

uv run python demo.py serve-command \
  --algorithm gptq-w4a16

uv run python demo.py benchmark-plan \
  --model Qwen/Qwen3-8B \
  --algorithms gptq-w4a16,rtn-w8a16 \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256 \
  --output-json reports/quantization-benchmark-plan.json

Nie dodawaj fp8-dynamic do tego workflow, dopóki repozytorium towarzyszące nie naprawi wyniku receptury FP8. Powyższe polecenia nie walidują wdrożenia FP8.

Na koniec porównaj modele bazowy i skompresowany względem jawnych progów:

uv run python demo.py quality-eval \
  --base-model Qwen/Qwen3-8B \
  --compressed-model outputs/Qwen3-8B-W4A16 \
  --mode all \
  --lm-eval-task hellaswag \
  --lm-eval-limit 50 \
  --max-perplexity-delta-pct 5 \
  --output-json reports/qwen3-8b-w4a16-quality.json

Wykonuj pracę w kolejności: zaplanuj cel, oszacuj pamięć, wykonaj dry run receptury, zbenchmarkuj obsługę, a następnie porównaj jakość z progami. Ta sekwencja odzwierciedla rozdzielenie opisane w tym artykule między wymiarowaniem pamięci, benchmarkami runtime’u i ewaluacją jakości.

10. Modele dyfuzyjne wymagają osobnej ścieżki

Pipeline’y dyfuzyjne i diffusion-transformer mają inną charakterystykę aktywacji niż autoregresywne LLM. SVDQuant traktuje kwantyzację modeli dyfuzyjnych jako osobny problem wartości odstających aktywacji.

Autoregresywne LLM generują po jednym tokenie. Modele dyfuzyjne wykonują powtarzające się kroki odszumiania, a rozkłady ich aktywacji przesuwają się w trakcie procesu. Standardowy przebieg kwantyzacji LLM do 4 bitów może zmniejszyć pamięć modelu dyfuzyjnego, ale jednocześnie wprowadzić poważne artefakty wizualne. Metody skoncentrowane na diffusion, takie jak SVDQuant / Nunchaku oraz kwantyzacja diffusion w NVIDIA ModelOpt, uwzględniają ten odmienny wzorzec aktywacji.

Poniższe zasady traktuj jako konserwatywne heurystyki, a nie uniwersalne ustawienia domyślne. Pipeline, komponent, model i runtime wymagają osobnych testów:

1. Na potrzeby pierwszego porównania pozostaw VAE w 16 bitach. Ta konserwatywna heurystyka ogranicza jedno ze źródeł artefaktów obrazu. Niższą precyzję testuj tylko wtedy, gdy potwierdzają ją metoda i docelowy pipeline.
2. Najpierw wypróbuj backbone DiT lub U-Net, ponieważ często zawiera największą część parametrów. To heurystyka, dlatego dla docelowego pipeline’u zweryfikuj pamięć, opóźnienie i jakość obrazu. Metody kwantyzacji modeli dyfuzyjnych stosują to samo podejście na poziomie komponentów.
3. Traktuj enkodery tekstu osobno. Kwantyzacja T5-XXL lub CLIP może wpływać na zgodność z promptem albo renderowanie tekstu w konkretnym pipeline’ie, dlatego oceniaj je niezależnie, zamiast zakładać zachowanie typowe dla transformerów.
4. Gdy głównym problemem są wartości odstające aktywacji, używaj metod uwzględniających diffusion, takich jak SVDQuant.
5. Oceniaj obrazy, nie metryki tekstowe. Sprawdzaj zgodność z promptem, renderowanie tekstu, odcienie skóry, balans kolorów, drobne szczegóły, opóźnienie i VRAM.

Jeśli zbiór ewaluacyjny zawiera tylko proste lub częste prompty, przeoczysz błędy brzegowe. Uwzględnij trudne przypadki: mały tekst, dłonie, powtarzające się obiekty, ustrukturyzowane układy oraz prompty z ograniczeniami negatywnymi, ponieważ błędy kwantyzacji diffusion są widoczne wizualnie, a nie w perplexity modelu językowego.

11. Ustawienia produkcyjne

W przypadku obsługi LLM w przedsiębiorstwie zacznij od baseline’u BF16 w dokładnie tym silniku obsługi, którego planujesz użyć. Jeśli celem jest przepustowość, a sprzęt ją obsługuje, przetestuj FP8 W8A8. Jeśli model się nie mieści, przetestuj AWQ lub GPTQ W4A16 z kernelami klasy Marlin. Jeśli problemem jest długi kontekst lub współbieżność, przetestuj kwantyzację FP8 KV cache. Jeśli problemem są powtarzające się prefiksy, włącz także prefix caching. Wydaj wersję skompresowaną dopiero wtedy, gdy przejdzie zarówno benchmarki jakości, jak i obsługi.

W przypadku inferencji lokalnej i edge zacznij od pliku GGUF z Q4_K_M lub Q5_K_M. Przejdź na Q8_0 GGUF, gdy pamięć na to pozwala, a jakość jest ważniejsza niż rozmiar. Zejście poniżej 4 bitów to ostateczność, a nie ustawienie domyślne.

W przypadku fine-tuningu użyj NF4 z QLoRA, aby tanio trenować adaptery. Oceń adapter w aplikacji przed scaleniem. Po scaleniu eksportuj do artefaktu obsługi, którego rzeczywiście potrzebujesz: pliku GGUF zgodnego z llama.cpp, checkpointu AWQ/GPTQ/compressed-tensors, checkpointu obsługi FP8 albo BF16.

W przypadku diffusion zacznij od tych konserwatywnych heurystyk i wizualnie testuj każdą kombinację pipeline’u, modelu i runtime’u. Perplexity tekstu nie powie, czy pipeline obrazowy uległ awarii, dlatego używaj dowodów specyficznych dla diffusion, takich jak SVDQuant i ewaluacja wizualna.

Referencje

• Benchmarki vLLM firmy JarvisLabs: JarvisLabs, vLLM Quantization Complete Guide and Benchmarks, 2026. JarvisLabs.
• Przewodnik po kwantyzacji Hugging Face Optimum: Hugging Face, Quantization conceptual guide. Docs.
• Dokumentacja kwantyzacji vLLM: projekt vLLM, Quantization. Docs.
• Dokumentacja Quantized KV Cache w vLLM: projekt vLLM, Quantized KV Cache. Docs.
• Dokumentacja benchmarków vLLM: projekt vLLM, vllm bench serve. Docs.
• Dokumentacja LLM Compressor: projekt vLLM, LLM Compressor. Docs.
• GPTQModel: ModelCloud, GPTQModel. GitHub.
• Kwantyzacja TensorRT-LLM: NVIDIA, TensorRT-LLM Quantization. Docs.
• NVIDIA NVFP4: NVIDIA, Introducing NVFP4 for Efficient and Accurate Low-Precision Inference. Blog.
• Hugging Face QuantizedCache: Hugging Face, Cache strategies: Quantized cache. Docs.
• NVIDIA Model Optimizer: NVIDIA, Model Optimizer. GitHub.
• Kwantyzacja torchao: PyTorch, torchao quantization overview. Docs.
• Kwantyzacja bitsandbytes: Hugging Face, bitsandbytes. Docs.
• HQQ: Dropbox, Half-Quadratic Quantization. GitHub.
• PEFT: Hugging Face, Parameter-Efficient Fine-Tuning. Docs.
• Ollama: lokalny runtime modeli Ollama. Website.
• LM Studio: lokalny runtime AI LM Studio. Website.
• Status AutoGPTQ: repozytorium AutoGPTQ, zarchiwizowane w kwietniu 2025. GitHub.
• Status AutoAWQ: repozytorium AutoAWQ, zarchiwizowane i uznane za przestarzałe w maju 2025. GitHub.
• GPTQ: Frantar et al., GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers, NeurIPS 2023. arXiv:2210.17323.
• Marlin: Frantar et al., MARLIN: Mixed-Precision Auto-Regressive Parallel Inference on Large Language Models, arXiv:2408.11743. arXiv:2408.11743.
• AWQ: Lin et al., AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration, MLSys 2024. arXiv:2306.00978.
• SmoothQuant: Xiao et al., SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models, ICML 2023. arXiv:2211.10438.
• QuaRot: Ashkboos et al., QuaRot: Outlier-Free 4-Bit Inference in Rotated LLMs, NeurIPS 2024. arXiv:2404.00456.
• SpinQuant: Meta AI Research, SpinQuant: LLM Quantization with Learned Rotations, arXiv:2405.16406. arXiv:2405.16406.
• QLoRA / NF4: Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs, NeurIPS 2023. arXiv:2305.14314.
• SVDQuant / Nunchaku: MIT HAN Lab, SVDQuant: Absorbing Outliers by Low-Rank Components for 4-Bit Diffusion Models, ICLR 2025. arXiv:2411.05007, Nunchaku.
• PagedAttention w vLLM: Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023. arXiv:2309.06180.
• Grouped-Query Attention: Ainslie et al., GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints, EMNLP 2023. arXiv:2305.13245.
• FP8 KV Cache w vLLM: Kubler, Kurtic, Wilkinson et al., The State of FP8 KV-Cache and Attention Quantization in vLLM, vLLM Blog, kwiecień 2026. vLLM Blog.
• KIVI: Liu et al., KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache, ICML 2024. arXiv:2402.02750.
• KVQuant: Hooper et al., KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, NeurIPS 2024. arXiv:2401.18079.
• Ewaluacja obsługi LLM: Kurtic et al., “Give Me BF16 or Give Me Death”? Accuracy-Performance Trade-Offs in LLM Quantization, ACL 2025. arXiv:2411.02355.
• Ewaluacja kwantyzacji dla długiego kontekstu: Mekala et al., Does quantization affect models’ performance on long-context tasks?, arXiv:2505.20276. arXiv:2505.20276.
• Ewaluacja rozumowania: Quantization Hurts Reasoning? An Empirical Study on Quantized Reasoning Models, arXiv:2504.04823. arXiv:2504.04823.
• SlideSparse: SlideSparse: Fast and Flexible (2N-2):2N Structured Sparsity, arXiv:2603.05232v1. arXiv:2603.05232v1.
• HumanEval: OpenAI, HumanEval. GitHub.
• MMLU: Hendrycks et al., Measuring Massive Multitask Language Understanding. arXiv:2009.03300.
• MATH-500: Hugging Face H4, MATH-500. Dataset.
• GGUF i llama.cpp: ggml-org, GGUF file format i llama.cpp. GGUF, llama.cpp.
• Dokumentacja GGUF w Hugging Face: Hugging Face, GGUF. Docs.
• Repozytorium referencyjne: slavadubrov/model-compression-demo.