Ollama: kwantyzacja q4_K_M vs q8_0 vs fp16

Wpływ kwantyzacji w Ollama

Kwantyzacja w Ollama przechowuje każdą wagę modelu na mniejszej liczbie bitów niż w pliku, w którym model został wytrenowany. Tag kończący się na q4_K_M utrzymuje około czterech bitów na wagę, podczas gdy fp16 utrzymuje szesnaście, dzięki czemu pobierany plik jest w przybliżeniu cztery razy mniejszy, a maszyna odczytuje cztery razy mniej bajtów w celu wygenerowania każdego tokena. Wagi są zaokrąglane do zgrubnej siatki, a nie usuwane, dlatego przy czterech bitach większość modeli odpowiada w sposób zbliżony do pełnej precyzji.

To cały kompromis: znacznie mniejsze zapotrzebowanie na pamięć i więcej tokenów na sekundę w zamian za niewielką utratę dokładności. Poniżej opisano, jak przewidzieć oba te aspekty dla konkretnego modelu na konkretnej maszynie, zanim poświęci się dwadzieścia minut na pobieranie pliku, który się nie zmieści.

Jeśli Ollama nie jest jeszcze uruchomiona, należy zacząć od instalacji Ollama na VPS. Ta strona zakłada, że ollama ls już działa.

Jak interpretować tag kwantyzacji Ollama, np. q4_K_M

Modele lokalne są udostępniane jako pliki GGUF – format, którego llama.cpp używa do przechowywania wag na dysku. Ollama bazuje na llama.cpp, dlatego tagi Ollama zachowują nazwy kwantyzacji stosowane w llama.cpp bez zmian.

Liczba określa docelową szerokość bitową. q4 oznacza, że większość tensorów wag jest spakowana do czterech bitów każdy. q8 oznacza osiem bitów. fp16 oznacza brak kwantyzacji: model jest w formacie szesnastobitowej liczby zmiennoprzecinkowej, czyli precyzji, w jakiej publikowana jest większość modeli.

K oznacza kwantyzację typu K. Wagi są grupowane w małe bloki, a każdy blok przechowuje własną skalę obok spakowanych wartości. Blok, którego wagi znajdują się blisko 0.01, otrzymuje dokładną skalę. Blok zawierający jedną dużą wartość odstającą otrzymuje skalę zgrubną. Te skale dla poszczególnych bloków sprawiają, że plik czterobitowy nadaje się do użytku i są również powodem, dla którego plik czterobitowy nigdy nie ma dokładnie czterech bitów na wagę.

Ostatnia litera oznacza mieszankę. S, M oraz L określają, ile tensorów jest promowanych powyżej docelowej szerokości. W q4_K_M tensory, których zaokrąglenie powoduje największą utratę jakości, są przechowywane z większą precyzją, podczas gdy reszta pozostaje na poziomie czterech bitów. Dlatego q4_K_M generuje lepsze wyniki niż starsze q4_0 przy niemal identycznym rozmiarze pliku.

Zamiast zgadywać na podstawie wpisanej nazwy, sprawdź, co Ollama posiada na dysku:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show wyświetla architecture, parameters, quantization, context length oraz embedding length. Wiersz quantization stanowi wiarygodne źródło informacji o modelu, który został pobrany miesiące temu i którego wyboru użytkownik może już nie pamiętać.

Liczba bitów na wagę determinuje rozmiar pliku

Każde szacowanie rozmiaru rozpoczyna się od jednej wartości: średniej liczby bitów, jaką format przeznacza na wagę w całym pliku. Projekt llama.cpp publikuje zmierzone wartości dla modelu Llama 3.1 8B w dokumentacji kwantyzacji; dane te można z powodzeniem odnieść do każdego gęstego modelu o podobnej strukturze.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

Zaskoczeniem w powyższej tabeli jest druga kolumna. Q4_K_M nie oznacza czterech bitów na wagę. Wartość ta wynosi 4.89 bity, ponieważ skalowanie bloków oraz promowane tensory również zajmują miejsce. Q8_0 zajmuje 8.5 bity, a nie osiem, z tego samego powodu. Użycie zmierzonej wartości pozwala uzyskać wynik obliczeń zbliżony do rzeczywistego rozmiaru pliku z dokładnością do kilku procent:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Jest to plik Q4_K_M o rozmiarze 4.58 GiB, wyliczony na podstawie dwóch liczb. Wartość ta odpowiada również w przybliżeniu pamięci zajmowanej przez wagi po załadowaniu. Ollama nie dekompresuje danych podczas ładowania: skwantyzowane wagi pozostają w pamięci w tej samej spakowanej formie, a każdy blok jest konwertowany w momencie użycia.

Co Ollama faktycznie udostępnia dla każdego rozmiaru modelu

Biblioteka publikuje tagi q4_K_M, q8_0 oraz fp16 dla większości rodzin modeli. Kilka nowszych rodzin odbiega od tego schematu i pojawia się w bibliotece wyłącznie jako tagi chmurowe, których nie można pobrać w żadnym wariancie. Jest to bariera, na którą trafia się podczas próby uruchomienia GLM 5.2 na VPS. Poniżej przedstawiono rozmiary Qwen3 według stanu na sierpień 2026 roku, odczytane z listy tagów na stronie modelu. Każda z poniższych wartości odnosi się do miejsca na dysku przed załadowaniem do pamięci RAM. Zestawienie dwóch lub trzech takich modeli zapełni mały wolumin root na VPS, dlatego warto wiedzieć, gdzie Ollama przechowuje pobrane modele, zanim rozpocznie się gromadzenie tagów.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

Domyślny tag ma tutaj znaczenie. ollama pull qwen3:8b pobiera dokładnie taką samą liczbę 5.2 GB danych co ollama pull qwen3:8b-q4_K_M, ponieważ tag bez przyrostka jest kompilacją q4_K_M. Wariant q4_K_M nie jest kompromisem, na który biblioteka niechętnie przystaje. Jest to ustawienie domyślne wybrane przez twórców, więc dopasowanie się do niego jest najbardziej rozsądnym pierwszym krokiem dla każdego modelu, którego nie przetestowano samodzielnie. Ta sama logika kieruje wyborem tagów przy uruchamianiu Qwen 3 na VPS.

Proporcje zachowują się w każdym wierszu. Przejście z q4_K_M na q8_0 zwiększa zapotrzebowanie o około siedemdziesiąt procent, a nie dwukrotnie, ponieważ tensory osadzeń (embedding) i wyjściowe nie skalują się w ten sam sposób co reszta modelu. Wariant fp16 jest mniej więcej trzy razy większy od q4_K_M. Model 32B w wersji q4_K_M zajmuje 20 GB wag, co przekracza możliwości serwera 16 GB RAM przy jakimkolwiek oknie kontekstowym. Aby uzyskać szerszy pogląd na to, co mieści się na danej maszynie, zobacz jakie modele można hostować samodzielnie.

Dlaczego pamięć podręczna KV stanowi drugi, zależny od kontekstu koszt

Wagi stanowią koszt stały. Pamięć podręczna KV (key and value cache) jest kosztem zmiennym. Każdy token w oknie kontekstowym przechowuje swoje wektory klucza i wartości dla każdej warstwy, więc rozmiar pamięci podręcznej rośnie liniowo wraz z dopuszczalnym oknem. Jest ona alokowana dla całego okna w momencie ładowania modelu, a nie w miarę zapełniania konwersacji, dlatego długie okno zajmuje pamięć nawet przy zapytaniu składającym się z jednego słowa.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Te liczby modelu pochodzą z jego własnej konfiguracji: 36 warstw, 8 głowic klucza/wartości oraz wymiar głowicy równy 128. ollama show dostarcza informacji o architekturze i liczbie parametrów, a config.json modelu w serwisie Hugging Face dostarcza reszty danych. Pomnóż koszt na token przez rozmiar okna, a pamięć podręczna przestanie być pomijalnym błędem zaokrąglenia.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Przy domyślnym oknie Ollama wynoszącym 4096 tokenów, pamięć podręczna dodaje 0.6 GB ponad wagami. Zwiększ okno do 32k, a sama pamięć podręczna osiągnie 4.83 GB, co stanowi niemal tyle samo pamięci, co skwantyzowane wagi, a dolny limit dla całego modelu wyniesie 10 GB. Nazywamy to dolnym limitem, ponieważ bufory obliczeniowe i system operacyjny wymagają dodatkowych zasobów. Rzeczywistą wartość odczytasz z kolumny SIZE narzędzia ollama ps po załadowaniu modelu.

Okno jest ustawiane na serwerze, a nie dla każdego żądania, gdy Ollama działa jako usługa:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

W przypadku instalacji systemd, umieść ustawienie w pliku typu drop-in:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Zrestartuj usługę za pomocą sudo systemctl restart ollama, a następnie sprawdź kolumnę CONTEXT w ollama ps, aby potwierdzić, z jakim oknem faktycznie załadował się uruchomiony model. OLLAMA_KV_CACHE_TYPE kwantyzuje samą pamięć podręczną: f16 jest wartością domyślną, q8_0 zużywa około połowę pamięci względem f16, a q4_0 około jedną czwartą. Jest to opcja globalna, więc każdy model na danym serwerze jest traktowany w ten sam sposób. Na małej maszynie z długim oknem, zmniejszenie pamięci podręcznej o połowę zwalnia więcej pamięci niż jakakolwiek inna pojedyncza zmiana. Ustawianie num_ctx i jego koszty szczegółowo omawia samo okno. Pamięć podręczna jest również wymiarowana raz na slot jednoczesnego żądania, a nie raz na serwer, więc pozwolenie Ollama na odpowiadanie na dwa zapytania jednocześnie podwaja wyliczoną kwotę, co stanowi podstawę matematyczną dla wyboru liczby slotów równoległych i limitu kolejki.

Co mieści się na VPS o pojemności 8, 16 lub 32 GB

Wagi modelu, pamięć podręczna KV oraz zapas pamięci dla systemu operacyjnego i pozostałych procesów. Dwa GB zapasu to bezpieczna wartość dla małego serwera VPS.

8 GB. Model 4B w kwantyzacji q4_K_M zajmuje 2.6 GB i pozostawia miejsce na długie okno kontekstowe. Model 8B w q4_K_M mieści się przy domyślnym oknie 4k, z bardzo niewielkim marginesem. Nie należy planować uruchomienia modelu 8B z oknem 32k, ponieważ bazowe zużycie 10 GB przekracza dostępne zasoby.

16 GB. Model 8B w q4_K_M z oknem 16k lub 32k działa stabilnie. Model 14B w q4_K_M zajmuje 9.3 GB i mieści się z umiarkowanym oknem kontekstowym. Model 8B w q8_0 zajmuje 8.9 GB, więc również się mieści. Porównanie tych dwóch wariantów na własnych promptach to najbardziej wartościowe ćwiczenie w tym zakresie.

32 GB. Modele 14B w q8_0 (16 GB) oraz 32B w q4_K_M (20 GB) ładują się poprawnie. Model 32B z dużym oknem kontekstowym zbliży się do limitu pamięci, dlatego należy monitorować ollama ps, zamiast zakładać dostępność zasobów.

Co ulega degradacji w pierwszej kolejności przy kwantyzacji

Błąd kwantyzacji nie rozkłada się równomiernie na wszystkie działania modelu. Płynność wypowiedzi utrzymuje się najdłużej i właśnie dlatego łatwo przeoczyć uszkodzenia: źle skwantyzowany model nadal tworzy poprawne gramatycznie zdania. Jako pierwsza cierpi precyzja. Dokładne odtworzenie numeru wersji, sygnatury API czy daty. Długie łańcuchy rozumowania, w których niewielki błąd na drugim etapie prowadzi do błędnej odpowiedzi na ósmym. Ścisłe formaty wyjściowe, w których jeden błędny nawias powoduje niepowodzenie wywołania narzędzia.

Ten ostatni przypadek stanowi test praktyczny. Gdy model musi zwrócić JSON, który jest parsowany przez kod, uszkodzenia wynikające z kwantyzacji objawiają się jako błąd parsowania, a nie jako nieznacznie gorsza jakość tekstu, więc zauważysz to tego samego dnia. Agent programistyczny jest najbardziej surową wersją tego testu, ponieważ wymusza na modelu kolejne wywołania narzędzi, więc skierowanie agenta na serwer Ollama ujawni zbyt agresywną kwantyzację w ciągu jednego popołudnia.

Poniżej czterech bitów utrata jakości staje się wyraźna. Typy q3 oraz dwubitowe istnieją dla użytkowników próbujących zmieścić duży model na ograniczonym sprzęcie i stanowią realną opcję, gdy alternatywą jest całkowity brak możliwości uruchomienia modelu. Nie są one jednak dobrym wyborem domyślnym. Różnica między q4_K_M a q8_0 jest na tyle mała, że opublikowana tabela perplexity nie rozstrzygnie, co jest lepsze dla danego obciążenia, więc nie należy próbować oceniać tego w ten sposób. Uruchom oba warianty dla trzydziestu własnych promptów i sprawdź wyjście.

Kiedy q8_0 lub fp16 są warte zajętej pamięci RAM

Pobieraj q8_0, gdy dysponujesz nadmiarem pamięci, a zadanie jest wrażliwe na drobne błędy: ekstrakcja ustrukturyzowana, wywoływanie narzędzi (tool calling) czy kod, który musi się skompilować. Jest to forma ubezpieczenia, a nie zauważalnie inteligentniejszy model.

Pobieraj fp16 tylko z dwóch powodów. Albo samodzielnie kwantyzujesz model i potrzebujesz pliku źródłowego, albo mierzysz punkt odniesienia, aby sprawdzić, ile jakości utraciła wersja czterobitowa. Serwowanie z fp16 zużywa trzykrotnie więcej pamięci niż q4_K_M przy różnicy, której większość osób nie jest w stanie wykryć w ślepym teście, a na maszynie opartej wyłącznie na CPU dodatkowo obniża szybkość generowania tokenów trzykrotnie.

Obowiązuje ważniejsza zasada: przy ustalonym budżecie pamięci większy model w q4_K_M zazwyczaj przewyższa mniejszy model w q8_0. 9.3 GB wag modelu 14B kontra 8.9 GB wag modelu 8B to niemal ta sama ilość pamięci RAM (random access memory), a większy model posiada szerszą wiedzę. Przetestuj to na własnych promptach, zamiast przyjmować to na wiarę.

Wnioskowanie wyłącznie na CPU jest ograniczone przepustowością pamięci

Większość planów VPS nie posiada GPU, więc model działa w pamięci systemowej na CPU hosta. Generowanie jest zatem ograniczone przepustowością pamięci, a nie mocą obliczeniową, ponieważ wygenerowanie jednego tokena wymaga jednokrotnego odczytania wszystkich wag. Wyznacza to górny limit, który nie zależy od liczby zakupionych rdzeni.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

Pięćdziesiąt GB/s to w przybliżeniu teoretyczna wartość dla dwukanałowej pamięci DDR4-3200. Twój udział jest mniejszy, ponieważ VPS współdzieli tę magistralę z każdym innym użytkownikiem na maszynie, więc traktuj te liczby jako nieosiągalny pułap. Istotny jest tutaj wzorzec: na CPU zmniejszenie liczby bitów na wagę o połowę w przybliżeniu podwaja szybkość generowania tokenów. Kwantyzacja jest najskuteczniejszym narzędziem optymalizacji szybkości na maszynie bez GPU. To, czy uzyskana szybkość jest akceptowalna, zależy od modelu, a Nemotron 3.5 Lightning na VPS przedstawia te obliczenia dla konkretnej kompilacji, tagu i ilości pamięci RAM. Druga połowa czasu oczekiwania zależy od tego, ile model ma zapisać, ponieważ przy dziesięciu tokenach na sekundę odpowiedź o długości sześciuset tokenów zajmuje pełną minutę, więc ograniczenie odpowiedzi za pomocą num_predict często pozwala zaoszczędzić więcej czasu niż kolejny krok redukcji precyzji.

Przetwarzanie promptu zachowuje się inaczej. Odczytywanie długiego promptu jest ograniczone mocą obliczeniową, a nie przepustowością, więc dodatkowe rdzenie pomagają w tym procesie, niemal nie wpływając na szybkość generowania. Maszyna, która szybko przetwarza prompt o długości 4k, a następnie generuje tekst powoli, zachowuje się w sposób typowy.

Nie przyjmuj żadnych obliczeń na wiarę. Zmierz liczbę tokenów na sekundę na własnej maszynie przy użyciu tego samego promptu dla każdej kwantyzacji i pozwól, aby Twoje wyniki przeważyły nad tymi szacunkami.

Samodzielna kwantyzacja modelu

Ollama umożliwia budowę skwantyzowanego modelu ze źródła w formacie fp16 lub fp32. Jest to istotne w przypadku własnego dostrajania modelu, dla którego nie istnieje jeszcze tag w bibliotece. Należy wskazać plik Modelfile na niekwantyzowane wagi:

FROM /path/to/my/model/f16

Następnie należy zbudować i zweryfikować model:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize akceptuje q8_0, q4_K_S oraz q4_K_M. W tym miejscu nie ma opcji q6_K ani q5_K_M, dlatego w takich przypadkach kwantyzację przeprowadza się za pomocą narzędzia llama.cpp, a następnie importuje gotowy plik GGUF. Ta ścieżka importu wiąże się z ryzykiem niedopasowania szablonu czatu, co powoduje generowanie przez model nieczytelnych treści. Zagadnienie to zostało opisane w sekcji importowanie pliku GGUF do Ollama. Linia quantization z ollama show służy do weryfikacji, czy proces budowy przebiegł zgodnie z założeniami.

Co zobaczysz, gdy coś pójdzie nie tak

Wszystko działa na CPU, mimo oczekiwania użycia GPU. Sprawdź kolumnę PROCESSOR:

ollama ps

Wyświetla ona 100% GPU, 100% CPU lub podział, taki jak 48%/52% CPU/GPU. Podział oznacza, że wagi wraz z KV cache nie zmieściły się w VRAM (pamięci wideo na karcie graficznej), więc część modelu została umieszczona w pamięci systemowej. Prędkość spada wtedy do poziomu zbliżonego do pracy wyłącznie na CPU, ponieważ każdy token czeka na wolniejszą część. Należy zmniejszyć okno kontekstowe, skwantyzować cache lub pobrać mniejszą wersję modelu. Dodanie rdzeni nie pomoże.

Model zostaje zamknięty podczas ładowania. Sprawdź jądro systemu oraz dziennik usługi:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Wiersz zawierający Out of memory: Killed process oznacza, że suma wag, KV cache i buforów przekroczyła dostępną pamięć urządzenia. Na serwerze VPS bez skonfigurowanego swap, cała maszyna może zawiesić się na kilka sekund przed pojawieniem się tego wiersza.

Jakość odpowiedzi spadła, mimo braku zmian. Dwie wersje tego samego modelu mogą znajdować się obok siebie w ollama ls pod różnymi tagami, a skrypt pobierający nazwę bez przyrostka będzie podążał za tym, na co aktualnie wskazuje biblioteka. Uruchom ollama show dla konkretnego tagu, którego wymaga klient, i odczytaj wiersz quantization, zamiast polegać na nazwie w pliku konfiguracyjnym.

FAQ

Którą kwantyzację Ollama powinienem pobrać?

Zacznij od q4_K_M. Jest to domyślny tag, który biblioteka Ollama udostępnia dla większości modeli, więc ollama pull qwen3:8b oraz ollama pull qwen3:8b-q4_K_M pobierają ten sam plik. Przejdź na q8_0 tylko wtedy, gdy dysponujesz nadmiarem pamięci, a zadanie jest wrażliwe na drobne błędy, na przykład przy wywoływaniu narzędzi lub generowaniu strukturalnego formatu JSON. Przy ograniczonym budżecie pamięci, większy model z kwantyzacją q4_K_M zazwyczaj przewyższa mniejszy model z q8_0, dlatego przetestuj taką konfigurację przed przeznaczeniem pamięci RAM na wyższą precyzję.

Czy q4_K_M faktycznie oznacza cztery bity na wagę?

Nie. W przypadku modelu Llama 3.1 8B jest to 4.89 bita na wagę, ponieważ każdy blok wag przechowuje własną skalę, a najbardziej istotne tensory są zapisywane w szerszym formacie. Q8_0 zajmuje 8.5 bita, a nie osiem, z tego samego powodu. Użyj zmierzonej wartości podczas szacowania: liczba parametrów pomnożona przez liczbę bitów na wagę, podzielona przez osiem, daje rozmiar pliku w bajtach.

Ile pamięci RAM potrzebuje model 8B na serwerze VPS tylko z procesorem CPU?

Zsumuj wagi, pamięć podręczną KV oraz margines bezpieczeństwa. Qwen3 8B w wersji q4_K_M zajmuje 5.2 GB wag. Przy domyślnym oknie kontekstowym 4096 tokenów pamięć podręczna dodaje 0.6 GB, co daje łączne minimum w okolicach 5.8 GB przed uwzględnieniem buforów obliczeniowych i systemu operacyjnego. Przy oknie 32k sama pamięć podręczna zajmuje 4.83 GB. Zaplanuj 8 GB dla krótkiego okna i 16 GB, jeśli potrzebujesz długiego.

Dlaczego mój model obciąża procesor CPU w 100%, skoro serwer posiada GPU?

Uruchom ollama ps i sprawdź kolumnę PROCESSOR. Wartość 100% CPU lub podział typu 48%/52% CPU/GPU oznacza, że wagi wraz z pamięcią podręczną KV nie zmieściły się w pamięci VRAM, więc Ollama przeniosła część lub całość modelu do pamięci systemowej. Najczęstszą przyczyną jest okno kontekstowe większe niż pojemność karty, ponieważ pamięć podręczna jest przydzielana dla całego okna w momencie ładowania modelu. Zmniejsz okno za pomocą OLLAMA_CONTEXT_LENGTH, ustaw OLLAMA_KV_CACHE_TYPE=q8_0, aby zredukować pamięć podręczną o połowę, lub pobierz mniejszą kwantyzację.