Ollama quantization: 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-quant. Ваги об’єднуються в невеликі блоки, і кожен блок зберігає власний scale поруч з упакованими значеннями. Для блоку, у якому всі ваги близькі до 0.01, використовується точний scale. Для блоку з одним великим викидом використовується грубіший scale. Саме ці scale для окремих блоків дають змогу використовувати чотирибітний файл. Водночас через них чотирибітний файл ніколи не містить рівно чотири біти на одну вагу.

Остання літера вказує на суміш. 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. Деякі новіші сімейства відхиляються від цієї схеми й доступні в бібліотеці лише як cloud-теги, з яких немає що завантажувати за жодної ширини. Саме з такою ситуацією ви стикаєтеся, намагаючись запустити GLM 5.2 на VPS. Нижче наведено розміри Qwen3 станом на August 2026. Дані взято зі списку тегів на сторінці моделі. Усі наведені значення — це розмір на диску, а не в RAM. Дві або три такі моделі можуть заповнити root volume невеликого VPS, тому перед збиранням тегів варто дізнатися, де Ollama зберігає завантажені моделі.

[
  {
    "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 GB, — скільки й ollama pull qwen3:8b-q4_K_M, оскільки тег без суфікса — це збірка q4_K_M. Q4_K_M — не компроміс, який бібліотека пропонує неохоче. Саме цей варіант вибрав upstream як типовий, тому для будь-якої моделі, яку ви ще не тестували самостійно, розумно почати з нього. Це саме міркування визначає вибір тегів у матеріалі про запуск Qwen 3 на VPS.

Співвідношення однакові в кожному рядку. Перехід із q4_K_M на q8_0 збільшує розмір приблизно на сімдесят відсотків, а не рівно вдвічі, оскільки embedding- і output-тензори масштабуються не так само, як решта тензорів. fp16 займає приблизно втричі більше за q4_K_M. Ваги моделі 32B у форматі q4_K_M займають 20 GB. Цього вже забагато для машини з 16 GB, якщо потрібно залишити місце хоча б для мінімального context window. Щоб отримати ширше уявлення про те, які моделі поміщаються на різних машинах, див. які моделі можна розмістити на власній інфраструктурі.

Чому 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 GB до обсягу пам’яті, який займають ваги. Збільште вікно до 32k, і лише кеш сягне 4.83 GB. Це майже стільки ж пам’яті, скільки займають квантизовані ваги, а мінімальний обсяг пам’яті для всієї моделі становитиме 10 GB. Це мінімальне значення, оскільки поверх нього потрібні буфери обчислень і пам’ять для операційної системи. Фактичне значення після завантаження моделі дивіться у стовпці 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 — приблизно вчетверо менше. Це глобальний параметр, тому однаково застосовується до всіх моделей на цьому сервері. Квантизація кешу працює лише тоді, коли ввімкнено Flash Attention. Ollama вмикає його автоматично, якщо бекенд його підтримує, а OLLAMA_FLASH_ATTENTION=1 примусово вмикає цю функцію. На малопотужному сервері з довгим вікном удвічі менший кеш вивільняє більше пам’яті, ніж будь-яка інша окрема зміна. У розділі Налаштування num_ctx і його вартість докладно описано саме вікно. Кеш також виділяється окремо для кожного паралельного слота запитів, а не один раз на сервер. Тому дозвіл Ollama одночасно обробляти два запити подвоює щойно розрахований обсяг пам’яті. Саме на цьому розрахунку ґрунтується вибір кількості паралельних слотів і ліміту черги.

Що поміститься на VPS із 8, 16 або 32 GB

Враховуйте обсяг ваг, KV cache, запас пам’яті для операційної системи та всіх інших запущених компонентів. Для невеликого VPS комфортним є запас у 2 GB.

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

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

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

Що погіршується внаслідок квантизації насамперед

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

Останній випадок є практичним тестом. Якщо модель має повертати JSON, який розбирає ваш код, пошкодження від квантизації проявляється як помилка розбору, а не як просто менш якісний текст. Тому ви побачите проблему того самого дня. Coding agent є найсуворішим варіантом такого тесту, оскільки він послідовно виконує виклик за викликом. Тому підключення agent до вашого сервера Ollama виявить надмірну квантизацію протягом одного дня.

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

Коли q8_0 або fp16 виправдані за обсягом RAM

Завантажуйте q8_0, коли пам’яті справді достатньо, а завдання чутливе навіть до невеликих помилок: структуроване вилучення даних, виклики інструментів, код, який має компілюватися. У цьому разі ви купуєте додаткову надійність, а не модель, яка помітно краще розуміє завдання.

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

Надійніше правило за фіксованого бюджету пам’яті таке: більша модель у q4_K_M зазвичай краща за меншу модель у q8_0. 9.3 GB ваг моделі 14B проти 8.9 GB ваг моделі 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

П’ятдесят GB/s — це приблизне теоретичне значення для хоста з двоканальною DDR4-3200. Ваша доступна частка менша, оскільки VPS використовує цю шину спільно з усіма іншими орендарями машини. Тому сприймайте ці числа як верхню межу, якої ніхто не досягає. Важлива сама залежність: на CPU зменшення кількості бітів на вагу приблизно вдвічі збільшує швидкість генерації токенів. Квантизація — це найефективніший спосіб підвищити швидкість на машині без GPU. Чи буде отримана швидкість прийнятною, залежить від моделі, а Nemotron 3.5 Lightning на VPS розглядає цей розрахунок для конкретної збірки, тега та обсягу RAM. Інша частина часу очікування залежить від обсягу тексту, який модель вирішує згенерувати: за швидкості десять токенів на секунду відповідь на шістсот токенів займає повну хвилину. Тому обмеження відповіді через num_predict часто скорочує час очікування сильніше, ніж ще один крок до меншої точності.

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

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

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

Це важливо, якщо ви виконали fine-tuning моделі, але для неї не існує тегу бібліотеки. Спосіб залежить від кінцевого формату, оскільки Ollama більше не створює GGUF K-quants, які вимірюються на цій сторінці.

Для K-quant, наприклад q4_K_M, виконайте квантування до того, як файл потрапить в Ollama. Ollama не квантує моделі GGUF під час імпорту та відхиляє --quantize для джерела GGUF. Квантуйте неквантований GGUF за допомогою llama-quantize з llama.cpp, а потім імпортуйте готовий файл. Цей спосіб імпорту також має окрему проблему: невідповідність chat template, через яку модель відповідає некоректним текстом. Її розглянуто в матеріалі імпорт файлу GGUF в Ollama. Рядок quantization з ollama show дає змогу перевірити, що імпортований файл є потрібною збіркою.

Власний --quantize в Ollama працює лише з імпортом safetensors. Вкажіть у Modelfile каталог, що містить неквантовані ваги safetensors:

FROM /path/to/safetensors/directory

Потім виконайте build:

ollama create --quantize int4 mymodel

Станом на Ollama v0.40.0 (перевірено 2026-10-09), --quantize приймає int4, int8, nvfp4, mxfp4 і mxfp8, а q4 та q8 використовуються як псевдоніми для int4 і int8. Назви GGUF, зокрема q4_K_M, q4_K_S, q8_0, q6_K і q5_K_M, відхиляються з помилкою unsupported quantize type. Ці типи не є GGUF K-quants, наведеними в таблицях вище, тому не використовуйте показники bits per weight і розміру файлу на цій сторінці як прогноз для них.

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

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

ollama ps

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

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

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 лише за наявності вільної пам’яті та якщо завдання чутливе до невеликих помилок, наприклад виклику інструментів або формування структурованого JSON. Якщо обсяг пам’яті обмежений, більша модель на q4_K_M зазвичай працює краще, ніж менша модель на q8_0. Тому спочатку протестуйте саме таку пару, перш ніж витрачати RAM на вищу точність.

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

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

Скільки RAM потребує модель 8B на VPS лише з CPU?

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

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

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