Ollama: porownanie kwantyzacji q4_K_M, q8_0 oraz fp16

Zmiany wynikające z kwantyzacji Ollama

Kwantyzacja Ollama przechowuje każdą wagę w 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, więc pobierany plik jest mniej więcej 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ę, okupione 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 zapisana przy użyciu czterech bitów. q8 oznacza osiem bitów. fp16 oznacza brak kwantyzacji: model jest zapisany w formacie szesnastobitowej liczby zmiennoprzecinkowej (FP16), czyli w 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, w którym wszystkie wagi oscylują wokół 0.01, otrzymuje precyzyjną 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; są one również powodem, dla którego plik czterobitowy nigdy nie ma dokładnie czterech bitów na wagę.

Ostatnia litera oznacza mieszankę (mixture). S, M oraz L określają, ile tensorów jest przechowywanych z większą precyzją niż szerokość docelowa. W q4_K_M tensory, których zaokrąglenie powoduje największą utratę jakości, są przechowywane w szerszym formacie, 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, należy sprawdzić, co Ollama przechowuje 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 nie można już odtworzyć z pamięci.

Liczba bitów na wagę determinuje rozmiar pliku

Każde szacowanie rozmiaru zaczyna 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, 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 bita, ponieważ skalowanie bloków oraz promowane tensory również zajmują miejsce. Q8_0 zajmuje 8.5 bita, a nie osiem, z tego samego powodu. Użycie zmierzonej wartości pozwala uzyskać wynik obliczeń, który różni się od rzeczywistego rozmiaru pliku o zaledwie kilka 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 zajmowanej przez wagi po załadowaniu. Ollama nie dekompresuje 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 dostarcza 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 rozmiarze. 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 zajętości miejsca na dysku przed załadowaniem do pamięci RAM. Zestawienie dwóch lub trzech takich modeli może zapełnić partycję root na małym serwerze VPS, dlatego warto wiedzieć, gdzie Ollama przechowuje pobrane modele, zanim rozpocznie się pobieranie kolejnych 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 kluczowe znaczenie. ollama pull qwen3:8b pobiera dokładnie taką samą liczbę 5.2 GB 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 pozwala. Jest to wybór domyślny dokonany przez twórców, więc dopasowanie się do niego jest najbardziej rozsądnym pierwszym krokiem dla każdego modelu, który nie został wcześniej przetestowany 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 dokładnie 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 maszyny z 16 GB pamięci RAM przy jakimkolwiek oknie kontekstowym. Aby uzyskać szerszy pogląd na to, co mieści się na konkretnej 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 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

Liczby te pochodzą z konfiguracji modelu: 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 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 dolny limit dla całego modelu wynosi 10 GB. Nazywamy to dolnym limitem, ponieważ bufory obliczeniowe i system operacyjny wymagają dodatkowych zasobów. Rzeczywistą wartość można odczytać z kolumny SIZE w 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ć rozmiar okna, z jakim faktycznie załadowano model. OLLAMA_KV_CACHE_TYPE kwantyzuje samą pamięć podręczną: 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. Kwantyzacja pamięci podręcznej działa tylko wtedy, gdy włączone jest Flash Attention, co Ollama robi automatycznie, jeśli backend to wspiera, a OLLAMA_FLASH_ATTENTION=1 wymusza to działanie. Na małym serwerze 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. Pamięć podręczna jest również rozmiarowana raz na slot jednoczesnego żądania, a nie raz na serwer, więc zezwolenie Ollama na odpowiadanie na dwa zapytania jednocześnie podwaja wyliczoną kwotę, co stanowi podstawę matematyczną dla wyboru liczby równoległych slotów i limitu kolejki.

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

Należy uwzględnić wagę modelu, pamięć podręczną KV oraz zapas pamięci dla systemu operacyjnego i pozostałych procesów. Zapas 2 GB jest wartością bezpieczną 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 kwantyzacji q4_K_M mieści się przy domyślnym oknie 4k, z bardzo małym marginesem. Nie należy planować uruchomienia modelu 8B z oknem 32k, ponieważ wymagane minimum 10 GB przekracza zasoby serwera.

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

32 GB. Modele 14B w kwantyzacji q8_0 (16 GB) oraz 32B w kwantyzacji q4_K_M (20 GB) ładują się poprawnie. Konfiguracja modelu 32B z dużym oknem kontekstowym będzie obciążać pamięć w znacznym stopniu, dlatego należy monitorować ollama ps zamiast zakładać poprawność działania.

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 tworzy poprawne gramatycznie zdania. W pierwszej kolejności cierpi precyzja. Dokładne odtwarzanie 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. Rygorystyczne 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, dlatego skierowanie agenta na serwer Ollama ujawni zbyt agresywną kwantyzację w ciągu jednego popołudnia.

Poniżej czterech bitów spadek jakości staje się gwałtowny. 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 niewielka, że opublikowana tabela perplexity nie rozstrzygnie, co będzie lepsze dla Twojego obciążenia, więc nie próbuj podejmować decyzji w ten sposób. Uruchom oba warianty dla trzydziestu własnych promptów i oceń wyjście.

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, kod wymagający kompilacji. Kupujesz w ten sposób ubezpieczenie, 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 trzy razy 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 opartej wyłącznie na CPU dodatkowo redukuje szybkość generowania tokenów trzykrotnie.

Ogólna 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 identyczne zużycie 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 hosta, wykorzystując CPU. 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 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 nieosiągalny sufit. Istotny jest tutaj trend: 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, jak dużo model musi zapisać; przy szybkości 10 tokenów na sekundę odpowiedź o długości 600 tokenów zajmuje pełną minutę, dlatego 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, mimo że niemal nie wpływają 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

Jest to istotne w przypadku modeli dostrojonych (fine-tuned), dla których nie istnieje znacznik biblioteki. Ścieżka postępowania zależy od docelowego formatu, ponieważ Ollama nie tworzy już kwantyzacji typu GGUF K-quants, które są mierzone na tej stronie.

W przypadku kwantyzacji typu K-quant, takiej jak q4_K_M, należy przeprowadzić kwantyzację przed zaimportowaniem pliku do Ollama. Ollama nie kwantyzuje modeli GGUF podczas importu i odrzuca --quantize w przypadku źródła GGUF. Należy skwantyzować nieprzetworzony plik GGUF za pomocą narzędzia llama-quantize z pakietu llama.cpp, a następnie zaimportować gotowy plik. Ta ścieżka importu wiąże się z ryzykiem niedopasowania szablonu czatu, co powoduje generowanie przez model nieczytelnych odpowiedzi; zagadnienie to opisano w sekcji importowanie pliku GGUF do Ollama. Wiersz quantization z polecenia ollama show pozwala zweryfikować, czy zaimportowany plik jest właściwą wersją.

Własne polecenie --quantize narzędzia Ollama działa tylko w przypadku importu plików safetensors. Należy wskazać w pliku Modelfile katalog zawierający nieprzetworzone wagi w formacie safetensors:

FROM /path/to/safetensors/directory

Następnie należy wykonać budowanie:

ollama create --quantize int4 mymodel

W wersji Ollama v0.40.0 (stan na 2026-10-09), --quantize akceptuje int4, int8, nvfp4, mxfp4 oraz mxfp8, przy czym q4 i q8 są traktowane jako aliasy dla int4 oraz int8. Nazwy GGUF, takie jak q4_K_M, q4_K_S, q8_0, q6_K oraz q5_K_M, są odrzucane z błędem unsupported quantize type. Typy te nie są kwantyzacjami GGUF K-quants wymienionymi w powyższych tabelach, dlatego nie należy traktować wartości bitów na wagę oraz rozmiarów plików z tej strony jako prognoz dla tych formatów.

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 modelu wraz z pamięcią podręczną KV nie zmieściły się w VRAM (pamięci wideo karty graficznej), więc część modelu została umieszczona w pamięci systemowej. Szybkość działania spada wtedy do poziomu zbliżonego do pracy wyłącznie na CPU, ponieważ każdy token czeka na wolniejszą część danych. Należy zmniejszyć okno kontekstowe, zastosować kwantyzację pamięci podręcznej lub pobrać mniejszą wersję modelu. Dodawanie rdzeni nie pomoże.

Model jest zabijany 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 podąży 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 wybrać?

Należy zacząć od q4_K_M. Jest to domyślny tag, z którym Ollama udostępnia większość modeli, dlatego ollama pull qwen3:8b oraz ollama pull qwen3:8b-q4_K_M pobierają ten sam plik. Na q8_0 warto przejść tylko wtedy, gdy dostępna jest nadmiarowa pamięć, a zadanie jest wrażliwe na drobne błędy, na przykład przy wywoływaniu narzędzi (tool calling) 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 warto przetestować taką konfigurację przed przydzieleniem większej ilości pamięci RAM na rzecz precyzji.

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łasny współczynnik skali, a najważniejsze tensory są zapisywane w szerszym formacie. Z tego samego powodu Q8_0 zajmuje 8.5 bita, a nie osiem. Wartość tę należy stosować przy szacowaniu: liczba parametrów pomnożona przez liczbę bitów na wagę i podzielona przez osiem daje rozmiar pliku w bajtach.

Ile pamięci RAM potrzebuje model 8B na serwerze VPS bez GPU?

Należy zsumować wagi, pamięć podręczną KV oraz margines bezpieczeństwa. Model 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. Należy zaplanować 8 GB RAM dla krótkiego okna i 16 GB dla długiego.

Dlaczego model obciąża CPU w 100%, mimo że serwer posiada GPU?

Należy uruchomić ollama ps i sprawdzić 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 VRAM, przez co 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. Należy zmniejszyć okno za pomocą OLLAMA_CONTEXT_LENGTH, ustawić OLLAMA_KV_CACHE_TYPE=q8_0, aby zmniejszyć pamięć podręczną o połowę, lub pobrać model z mniejszą kwantyzacją.