Квантування Ollama: порівняння Q4, Q8 та fp16

На що впливає квантування Ollama

Квантування в Ollama зберігає кожну вагу моделі з меншою кількістю бітів, ніж у файлі, на якому вона була навчена. Тег, що закінчується на q4_K_M, зберігає приблизно чотири біти на вагу, тоді як fp16 зберігає шістнадцять, тому розмір завантаження становить приблизно чверть від початкового, а машина зчитує вчетверо менше байтів для генерації кожного токена. Ваги округлюються до грубшої сітки, а не відкидаються, і при чотирьох бітах більшість моделей відповідають майже так само, як і при повній точності.

Це і є весь компроміс: значно менші вимоги до пам'яті та більше токенів за секунду в обмін на невелику втрату точності. Далі описано, як спрогнозувати обидва аспекти для конкретної моделі на конкретному сервері, перш ніж витрачати двадцять хвилин на завантаження файлу, який не поміститься в пам'ять.

Якщо Ollama ще не запущена, почніть із встановлення Ollama на VPS. Ця сторінка передбачає, що ollama ls вже працює.

Як читати тег квантування Ollama, наприклад q4_K_M

Локальні моделі постачаються як файли GGUF — це формат, який llama.cpp використовує для зберігання ваг на диску. Ollama побудована на базі llama.cpp, тому теги Ollama містять назви квантування llama.cpp без змін.

Число вказує на цільову розрядність. q4 означає, що більшість тензорів ваг упаковані по чотири біти кожен. q8 означає вісім бітів. fp16 означає відсутність квантування: це модель у форматі 16-бітного числа з рухомою комою, тобто з тією точністю, у якій публікується більшість моделей.

K позначає K-квантування. Ваги групуються у невеликі блоки, і кожен блок зберігає власний масштаб поруч із упакованими значеннями. Блок, у якому всі ваги близькі до 0.01, отримує точний масштаб. Блок, що містить одне велике відхилення, отримує грубий масштаб. Саме ці поблокові масштаби дозволяють використовувати 4-бітний файл, і саме тому 4-бітний файл ніколи не має рівно чотири біти на вагу.

Остання літера вказує на суміш. S, M та L визначають, скільки тензорів мають вищу розрядність, ніж цільова. У q4_K_M тензори, які найбільше втрачають при округленні, зберігаються з більшою розрядністю, тоді як основна маса залишається на рівні чотирьох бітів. Саме тому q4_K_M видає кращий результат, ніж старіший q4_0, при майже однаковому розмірі файлу.

Запитуйте Ollama про те, що саме знаходиться на диску, замість того, щоб вгадувати за назвою, яку ви ввели:

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

ollama show виводить architecture, parameters, quantization, context length та embedding length. Рядок quantization — це достовірні дані про модель, яку ви завантажили кілька місяців тому і вже не пам'ятаєте, яку саме обрали.

Біти на вагу визначають розмір файлу

Кожна оцінка розміру починається з одного числа: скільки бітів формат витрачає на вагу в середньому по всьому файлу. llama.cpp публікує виміряні показники для Llama 3.1 8B у своїй документації з квантування, і вони добре переносяться на будь-яку щільну модель аналогічної структури.

[
  {
    "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
  }
]

Несподіванкою в цій таблиці є другий стовпець. Q4_K_M — це не чотири біти на вагу. Він займає 4.89 бітів, оскільки масштаби блоків і підвищені тензори також потребують реального місця. Q8_0 займає 8.5 бітів, а не вісім, з тієї ж причини. Використовуйте виміряне число, і результат обчислень буде відрізнятися від реального розміру файлу лише на кілька відсотків:

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

Це файл Q4_K_M розміром 4.58 GiB, отриманий з двох чисел. Це також приблизно той обсяг пам'яті, який займають ваги після завантаження. Ollama нічого не розпаковує під час завантаження: квантовані ваги залишаються в пам'яті в тому ж упакованому вигляді, а кожен блок конвертується безпосередньо під час використання.

Що саме Ollama постачає для кожного розміру моделі

Бібліотека публікує теги q4_K_M, q8_0 та fp16 для більшості сімейств. Це розміри Qwen3 станом на серпень 2026 року, зчитані зі списку тегів на сторінці моделі.

[
  {
    "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
  }
]

Тег за замовчуванням тут має значення. ollama pull qwen3:8b завантажує рівно ті самі 5.2 ГБ, що й ollama pull qwen3:8b-q4_K_M, оскільки тег без суфікса і є збіркою q4_K_M. Q4_K_M — це не компроміс, на який бібліотека йде неохоче. Це стандарт, обраний розробниками, тому відповідність йому є логічним першим кроком для будь-якої моделі, яку ви ще не тестували самостійно. Ті самі міркування визначають вибір тегів у запуску Qwen 3 на VPS.

Ці співвідношення зберігаються для кожного рядка. Перехід від q4_K_M до q8_0 коштує приблизно на сімдесят відсотків дорожче, а не рівно вдвічі, оскільки тензори ембедингів та виводу масштабуються не так, як решта. fp16 приблизно втричі більший за q4_K_M. Модель 32B у форматі q4_K_M важить 20 ГБ, що вже перевищує обсяг, який може вмістити сервер на 16 ГБ з будь-яким контекстним вікном. Для ширшого огляду того, що підходить для конкретної машини, див. які моделі можна розмістити самостійно.

Чому KV cache — це додаткові витрати, що залежать від контексту

Ваги — це фіксовані витрати. KV cache (кеш ключів та значень) — це змінні витрати. Кожен токен у вікні контексту зберігає свої вектори ключів та значень для кожного шару, тому обсяг кешу зростає лінійно залежно від дозволеного розміру вікна. Пам'ять під кеш виділяється для всього вікна під час завантаження моделі, а не в міру наповнення діалогу. Саме тому велике вікно контексту споживає пам'ять навіть при запиті з одного слова.

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

Ці параметри моделі беруться з її власної конфігурації: 36 шарів, 8 голів ключів/значень та розмірність голови 128. ollama show надає архітектуру та кількість параметрів, а config.json моделі на Hugging Face — решту даних. Помножте вартість одного токена на розмір вікна, і кеш перестане бути похибкою округлення.

[
  {
    "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
  }
]

При стандартному вікні Ollama у 4096 токенів кеш додає 0.6 ГБ до ваги моделі. Збільште вікно до 32k, і лише кеш сягне 4.83 ГБ, що майже дорівнює обсягу пам'яті для квантованих ваг, а мінімальний поріг споживання для всієї моделі становитиме 10 ГБ. Це мінімальний поріг, оскільки обчислювальні буфери та операційна система потребують додаткових ресурсів. Перегляньте реальне значення у стовпці SIZE команди ollama ps після завантаження моделі.

Розмір вікна встановлюється на рівні сервера, а не для кожного запиту окремо, якщо ви запускаєте Ollama як сервіс:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Для інсталяції через systemd додайте налаштування у drop-in файл:

sudo systemctl edit ollama

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

Перезапустіть сервіс за допомогою sudo systemctl restart ollama, а потім перевірте стовпець CONTEXT у ollama ps, щоб підтвердити розмір вікна, з яким фактично завантажилася модель. OLLAMA_KV_CACHE_TYPE дозволяє квантувати сам кеш: f16 є стандартним значенням, q8_0 використовує приблизно вдвічі менше пам'яті, ніж f16, а q4_0 — приблизно чверть. Це глобальна опція, тому вона застосовується до всіх моделей на сервері. На малопотужному обладнанні з великим вікном контексту зменшення кешу вдвічі звільняє більше пам'яті, ніж будь-яка інша окрема зміна. Налаштування num_ctx та його вартість детально описує роботу з вікном контексту.

Що можна розмістити на VPS обсягом 8, 16 або 32 ГБ

Враховуйте вагу моделі, KV cache, а також запас оперативної пам'яті для операційної системи та інших процесів. 2 ГБ запасу є достатніми для невеликого VPS.

8 ГБ. Модель 4B у форматі q4_K_M займає 2.6 ГБ і залишає місце для довгого контекстного вікна. Модель 8B у форматі q4_K_M поміщається зі стандартним вікном 4k, але з мінімальним запасом. Не розраховуйте на 8B з вікном 32k, оскільки мінімальний поріг у 10 ГБ вже перевищує можливості сервера.

16 ГБ. Модель 8B у форматі q4_K_M з вікном 16k або 32k працює стабільно. Модель 14B у форматі q4_K_M має вагу 9.3 ГБ і поміщається з помірним вікном. Модель 8B у форматі q8_0 займає 8.9 ГБ, тому вона також поміститься; порівняння цих двох варіантів на власних запитах — це найкорисніша практика, яку можна провести в цій темі.

32 ГБ. Моделі 14B у форматі q8_0 (16 ГБ) та 32B у форматі q4_K_M (20 ГБ) завантажуються успішно. Збірка 32B з великим вікном буде працювати на межі можливостей, тому моніторте ollama ps, замість того щоб покладатися на припущення.

Що деградує першим при квантуванні

Помилка квантування не розподіляється рівномірно по всіх функціях моделі. Найдовше зберігається плавність мовлення, і саме тому пошкодження легко пропустити: погано квантована модель все одно пише граматично правильні речення. Першою страждає точність. Точне відтворення номера версії, сигнатури API або дати. Довгі ланцюжки міркувань, де невелика помилка на другому кроці призводить до неправильної відповіді на восьмому. Суворі формати виводу, де одна помилкова дужка призводить до збою виклику інструменту.

Останній пункт є практичним тестом. Коли модель має повернути JSON, який парсить ваш код, пошкодження від квантування проявляється як помилка парсингу, а не як дещо гірший текст, тому ви помітите це того ж дня. Агент для написання коду — це найсуворіша версія такого тесту, оскільки він змушує модель виконувати виклик за викликом, тому тестування агента на вашому сервері Ollama виявить занадто агресивне квантування протягом кількох годин.

Нижче чотирьох бітів втрати стають суттєвими. Типи q3 та двобітові формати існують для випадків, коли потрібно розмістити велику модель на слабкому обладнанні, і це реальний вибір, коли альтернативою є повна неможливість запуску моделі. Вони є поганим вибором за замовчуванням. Між q4_K_M та q8_0 розрив настільки малий, що опублікована таблиця перплексії не допоможе визначитися для вашого робочого навантаження, тому не намагайтеся оцінювати їх таким чином. Запустіть обидва варіанти на тридцяти власних запитах і проаналізуйте результат.

Коли q8_0 або fp16 варті використання оперативної пам'яті

Використовуйте q8_0, коли пам'яті дійсно вдосталь, а завдання критичне до дрібних помилок: структуроване видобування даних, виклик інструментів, написання коду, який має компілюватися. Ви купуєте страховку, а не помітно розумнішу модель.

Використовуйте fp16 лише з двох причин. Або ви самостійно квантуєте модель і вам потрібен вихідний файл, або ви вимірюєте базові показники, щоб зрозуміти, чим довелося пожертвувати у 4-бітній збірці. Робота з fp16 споживає втричі більше пам'яті, ніж q4_K_M, при різниці, яку більшість людей не помітить під час сліпого тестування, а на системі лише з CPU це також знижує швидкість генерації токенів утричі.

Головне правило при фіксованому обсязі пам'яті: більша модель у форматі q4_K_M зазвичай перевершує меншу модель у форматі q8_0. 9.3 ГБ ваг моделі 14B проти 8.9 ГБ ваг моделі 8B займають майже однакову кількість RAM (оперативної пам'яті), але більша модель має ширші знання. Перевірте це на власних запитах, замість того щоб приймати на віру.

Виведення лише на CPU обмежене пропускною здатністю пам'яті

Більшість тарифних планів VPS не мають GPU, тому модель працює в системній пам'яті на CPU хоста. Генерація в такому разі обмежена пропускною здатністю пам'яті, а не обчислювальною потужністю, оскільки для створення одного токена потрібно щоразу зчитувати всі ваги. Це створює верхню межу продуктивності, яка не залежить від кількості придбаних ядер.

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 ГБ/с — це приблизний теоретичний показник для двоканальної пам'яті DDR4-3200. Ваша частка менша, оскільки VPS ділить цю шину з усіма іншими орендарями на машині, тому сприймайте ці цифри як недосяжну межу. Важлива закономірність: на CPU зменшення кількості бітів на вагу вдвічі приблизно подвоює швидкість генерації токенів. Квантування — це найефективніший важіль прискорення на сервері без GPU.

Обробка промпту працює інакше. Читання довгого промпту обмежене обчислювальними ресурсами, а не пропускною здатністю, тому додаткові ядра допомагають у цьому процесі, майже не впливаючи на швидкість генерації. Якщо сервер швидко обробляє промпт на 4k, а потім генерує відповідь повільно — це нормальна поведінка.

Не сприймайте жодні розрахунки на віру. Виміряйте кількість токенів за секунду на власному сервері з однаковим промптом для кожного рівня квантування, і нехай ваші результати будуть пріоритетними.

Самостійне квантування моделі

Ollama може створити квантовану модель із вихідного файлу у форматі fp16 або fp32. Це необхідно, якщо ви виконали fine-tuning моделі, для якої ще немає готового тегу в бібліотеці. Вкажіть у Modelfile шлях до неквантованих ваг:

FROM /path/to/my/model/f16

Після цього виконайте збірку та перевірте результат:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize підтримує q8_0, q4_K_S та q4_K_M. Тут немає опцій q6_K або q5_K_M, тому для них слід використовувати власний інструмент llama.cpp, а потім імпортувати готовий файл GGUF. Рядок quantization з ollama show дозволяє переконатися, що збірка виконана згідно з вашими параметрами.

Що ви побачите, коли щось піде не так

Усе працює на CPU, хоча ви очікували роботу на GPU. Перегляньте стовпець PROCESSOR:

ollama ps

Він виводить 100% GPU, 100% CPU або розділення, наприклад 48%/52% CPU/GPU. Розділення означає, що ваги разом із KV cache не помістилися у VRAM (відеопам'ять, пам'ять на графічній карті), тому частину моделі було розміщено в системній пам'яті. Швидкість у такому разі падає майже до рівня роботи лише на CPU, оскільки кожен токен очікує на повільну частину. Зменште контекстне вікно, квантуйте кеш або завантажте меншу збірку. Додавання ядер не допоможе.

Модель завершується (killed) під час завантаження. Перевірте ядро та журнал сервісу:

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

Рядок, що містить Out of memory: Killed process, означає, що сумарний обсяг ваг, KV cache та буферів перевищив обсяг пам'яті на сервері. На VPS без налаштованого swap уся машина може зависнути на кілька секунд перед появою цього рядка.

Відповіді стали гіршими, хоча ви нічого не змінювали. Дві збірки однієї моделі можуть знаходитися поруч у ollama ls під різними тегами, і скрипт, що завантажує ім'я без суфікса, буде слідувати за тим, на що зараз вказує бібліотека. Виконайте ollama show для конкретного тегу, який запитує ваш клієнт, і прочитайте рядок quantization, замість того щоб довіряти імені у вашому конфігураційному файлі.

FAQ

Яку квантизацію Ollama обрати?

Почніть із q4_K_M. Це стандартний тег, який Ollama пропонує за замовчуванням для більшості моделей, тому ollama pull qwen3:8b та ollama pull qwen3:8b-q4_K_M завантажують один і той самий файл. Переходьте до q8_0 лише тоді, коли маєте надлишок пам'яті, а завдання вимагає високої точності, наприклад, при роботі з інструментами (tool calling) або структуруванні JSON. Якщо обсяг пам'яті обмежений, більша модель із квантизацією q4_K_M зазвичай працює краще, ніж менша модель із q8_0. Протестуйте це поєднання, перш ніж виділяти додаткову оперативну пам'ять на вищу точність.

Чи означає q4_K_M справді чотири біти на вагу?

Ні. Для моделі Llama 3.1 8B цей показник становить 4.89 біт на вагу. Це пояснюється тим, що кожен блок ваг зберігає власний масштаб, а найбільш чутливі тензори зберігаються у ширшому форматі. З тієї ж причини Q8_0 має 8.5 біт, а не вісім. Використовуйте цей показник для розрахунків: кількість параметрів, помножена на кількість біт на вагу та поділена на вісім, дає розмір файлу в байтах.

Скільки оперативної пам'яті потрібно для моделі 8B на VPS лише з CPU?

Підсумуйте ваги, KV-кеш та запас пам'яті. Модель Qwen3 8B із квантизацією q4_K_M займає 5.2 ГБ. При стандартному вікні контексту 4096 токенів кеш додає ще 0.6 ГБ, що створює мінімальну вимогу близько 5.8 ГБ без урахування обчислювальних буферів та операційної системи. При вікні 32k лише кеш займає 4.83 ГБ. Плануйте 8 ГБ для короткого вікна та 16 ГБ, якщо вам потрібен довгий контекст.

Чому модель завантажує CPU на 100%, якщо на сервері є GPU?

Виконайте ollama ps і перевірте стовпець PROCESSOR. Значення 100% CPU або розподіл, наприклад 48%/52% CPU/GPU, означають, що ваги разом із KV-кешем не вмістилися у VRAM, тому Ollama перенесла частину або всю модель у системну пам'ять. Найчастіша причина — вікно контексту, яке перевищує можливості відеокарти, оскільки кеш виділяється під повний розмір вікна під час завантаження моделі. Зменште вікно за допомогою OLLAMA_CONTEXT_LENGTH, встановіть OLLAMA_KV_CACHE_TYPE=q8_0, щоб скоротити кеш удвічі, або завантажте меншу квантизацію.