Ollama: kwantyzacja q4_K_M, q8_0 czy fp16 – co wybrać?

Wpływ kwantyzacji w Ollama

Kwantyzacja w Ollama przechowuje każdą wagę modelu przy użyciu mniejszej liczby bitów niż w pliku, w którym model został wytrenowany. Tag kończący się na q4_K_M zachowuje około czterech bitów na wagę, podczas gdy fp16 zachowuje szesnaście. Dzięki temu rozmiar pobieranego pliku jest około 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 zużycie pamięci 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ą wydawane jako pliki GGUF, czyli format używany przez llama.cpp do przechowywania wag na dysku. Ollama bazuje na llama.cpp, dlatego tagi Ollama zachowują nazewnictwo kwantyzacji z llama.cpp bez zmian.

Liczba oznacza 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 zmiennoprzecinkowym szesnastobitowym, czyli precyzji, w której 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ź w Ollama, co znajduje się 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 zaczyna się od jednej liczby: ś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, a 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 tej tabeli jest druga kolumna. Q4_K_M nie oznacza czterech bitów na wagę. Wartość ta wynosi 4.89 bity, ponieważ skale 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

To jest plik Q4_K_M o rozmiarze 4.58 GiB, wyliczony na podstawie dwóch liczb. Jest to również, w przybliżeniu, ilość pamięci zajmowana przez wagi po załadowaniu. Ollama nie rozpakowuje niczego 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. Są to rozmiary Qwen3 na sierpień 2026, odczytane z listy tagów na stronie modelu.

[
  {
    "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 te same 5.2 GB co ollama pull qwen3:8b-q4_K_M, ponieważ tag bez przyrostka jest kompilacją q4_K_M. Q4_K_M nie jest kompromisem, który biblioteka oferuje niechętnie. Jest to wartość domyślna wybrana przez twórców, więc dopasowanie się do niej jest rozsądnym pierwszym krokiem w przypadku każdego modelu, którego nie przetestowano samodzielnie. To samo rozumowanie kieruje wyborem tagów w uruchamianiu Qwen 3 na VPS.

Proporcje zachowują się w każdym wierszu. Przejście z q4_K_M na q8_0 kosztuje około siedemdziesiąt procent więcej, a nie dokładnie dwa razy tyle, ponieważ tensory osadzeń (embedding) i wyjściowe nie skalują się w ten sam sposób co reszta. Wersja fp16 jest mniej więcej trzy razy większa od q4_K_M. Model 32B w wersji q4_K_M zajmuje 20 GB wag, co już przekracza możliwości maszyny 16 GB 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 rozmiarem okna. Jest ona alokowana dla całego okna w momencie ładowania modelu, a nie w miarę zapełniania konwersacji, dlatego długie okno obciąża 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

Wspomniane parametry modelu pochodzą z jego własnej konfiguracji: 36 warstw, 8 głowic klucza/wartości oraz wymiar głowicy wynoszący 128. ollama show dostarcza informacji o architekturze i liczbie parametrów, a config.json modelu w serwisie Hugging Face zawiera resztę 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ększenie okna do 32k powoduje, że sama pamięć podręczna osiąga 4.83 GB, co stanowi niemal tyle samo pamięci, co skwantyzowane wagi, a minimalne zapotrzebowanie dla całego modelu wynosi 10 GB. Nazywamy to wartością minimalną, ponieważ bufory obliczeniowe oraz system operacyjny wymagają dodatkowych zasobów. Rzeczywistą wartość odczytasz z kolumny SIZE narzędzia ollama ps po załadowaniu modelu.

Rozmiar okna ustawia się na serwerze, a nie dla każdego żądania z osobna, gdy Ollama działa jako usługa:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

W przypadku instalacji systemd, należy użyć 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ładowano działający model. OLLAMA_KV_CACHE_TYPE pozwala na kwantyzację samej pamięci podręcznej: f16 jest ustawieniem domyślnym, q8_0 zużywa około połowę pamięci w porównaniu do 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 związane z tym koszty szczegółowo omawia kwestię samego okna.

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

Wagi modelu, pamięć podręczna KV oraz zapas dla systemu operacyjnego i pozostałych procesów. Dwa GB zapasu to komfortowa wartość na małym 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 małym marginesem. Nie należy planować użycia 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 płynnie. Model 14B w q4_K_M wymaga 9.3 GB na wagi i mieści się przy umiarkowanym oknie. 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ściowa godzina, jaką można poświęcić na ten temat.

32 GB. Modele 14B w q8_0 (16 GB) oraz 32B w q4_K_M (20 GB) ładują się bez problemu. Wariant 32B z dużym oknem kontekstowym będzie zbliżał się do limitu pamięci, dlatego należy monitorować ollama ps, zamiast polegać na założeniach.

Co ulega degradacji w pierwszej kolejności przy kwantyzacji

Błąd kwantyzacji nie rozkłada się równomiernie na wszystkie funkcje modelu. Płynność wypowiedzi utrzymuje się najdłużej i właśnie dlatego łatwo przeoczyć uszkodzenia: nieprawidłowo skwantyzowany model nadal generuje poprawne gramatycznie zdania. Jako pierwsza cierpi precyzja. Dokładne przywoływanie numerów wersji, sygnatur API czy dat. 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, gdzie 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ę gwałtowna. 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 będzie lepsze dla danego obciążenia, więc nie należy polegać na tej metodzie. Należy uruchomić oba warianty dla trzydziestu własnych promptów i ocenić wygenerowane wyniki.

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

Pobierz q8_0, gdy dysponujesz nadmiarem pamięci, a zadanie jest wrażliwe na drobne błędy: ekstrakcja strukturalna, wywoływanie narzędzi lub generowanie kodu, który musi się skompilować. Jest to forma ubezpieczenia, a nie zauważalnie inteligentniejszy model.

Pobierz 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 traci 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 zauważy w ślepym teście, a na maszynie z samym CPU dodatkowo redukuje szybkość generowania tokenów do jednej trzeciej.

Obowiązuje silniejsza zasada przy stałym 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 wówczas ograniczone przepustowością pamięci, a nie mocą obliczeniową, ponieważ wygenerowanie jednego tokena wymaga jednokrotnego odczytania wszystkich wag. Wyznacza to górny limit wydajności, 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

50 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 górny limit, którego nikt nie osiąga. 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 zwiększania wydajności na maszynie bez GPU.

Przetwarzanie promptu zachowuje się inaczej. Odczyt długiego promptu jest ograniczony 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 to Twoje wyniki były rozstrzygające.

Samodzielna kwantyzacja modelu

Ollama umożliwia budowę skwantyzowanego modelu ze źródła w formacie fp16 lub fp32. Jest to istotne w przypadku modeli dostrojonych (fine-tuned), dla których nie istnieje jeszcze biblioteczny tag. Należy wskazać plik Modelfile na niekwantyzowane wagi:

FROM /path/to/my/model/f16

Następnie należy przeprowadzić budowę i weryfikację:

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ę wykonuje się za pomocą narzędzia llama.cpp, a gotowy plik GGUF importuje się do systemu. 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 że oczekiwano 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 pamięcią podręczną KV nie zmieściły się w VRAM (pamięci wideo na karcie graficznej), więc część modelu została umieszczona w pamięci systemowej. Szybkość działania spada wówczas do poziomu zbliżonego do pracy wyłącznie na CPU, ponieważ generowanie każdego tokena oczekuje na wolniejszą część. Należy zmniejszyć okno kontekstowe, skwantyzować pamięć podręczną lub pobrać mniejszą wersję modelu. Dodawanie 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, pamięci podręcznej KV oraz buforów przekroczyła dostępną pamięć RAM serwera. Na serwerze VPS bez skonfigurowanego pliku wymiany (swap), cała maszyna może zawiesić się na kilka sekund przed pojawieniem się tego komunikatu.

Jakość odpowiedzi spadła, mimo braku zmian w konfiguracji. Dwie wersje tego samego modelu mogą znajdować się obok siebie w ollama ls pod różnymi tagami, a skrypt pobierający nazwę bez przyrostka zawsze pobierze to, 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 dostarczany przez bibliotekę Ollama 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 ustrukturyzowanego 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 tę 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 najważniejsze tensory są zapisywane w szerszym formacie. Q8_0 z tego samego powodu zajmuje 8.5 bita, a nie osiem. Używaj 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 z kwantyzacją 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 łącznie około 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 wymagasz dłuższego.

Dlaczego model obciąża procesor 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 alokowana 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ę.