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

Остання літера позначає суміш. 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 у документації до quantize, і вони добре підходять для будь-якої щільної моделі подібної структури.

[
  {
    "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 бітів, оскільки block scales і promoted tensors також займають місце. 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 — приблизно вчетверо менше. Це глобальна опція, тому однакове налаштування застосовується до кожної моделі на цьому сервері. На невеликому сервері з довгим вікном удвічі менший кеш звільняє більше пам’яті, ніж будь-яка інша окрема зміна. У розділі Налаштування 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 і two bit призначені для тих, хто намагається розмістити велику модель на слабкому обладнанні. Це реальний варіант, коли альтернативою є повна відсутність запуску моделі. Але це невдалий вибір за замовчуванням. Різниця між q4_K_M і q8_0 достатньо мала, щоб опублікована таблиця perplexity не дала відповіді саме для вашого робочого навантаження. Тому не намагайтеся вирішити питання таким способом. Перевірте обидва варіанти на тридцяти власних промптах і перегляньте результат.

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

Завантажуйте 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, а потім повільно генерує текст, працює нормально.

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

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

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. У цього способу імпорту є окрема проблема: невідповідність chat template, через яку модель відповідає нерозбірливим текстом. Докладні інструкції наведено в розділі імпорт файлу GGUF в Ollama. Рядок quantization із ollama show дає змогу перевірити, чи збірку виконано відповідно до заданих параметрів.

Що ви побачите в разі помилки

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

ollama ps

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

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

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 токенів cache додає 0.6 GB, тому мінімальна оцінка до врахування буферів обчислень і операційної системи становить близько 5.8 GB. За вікна на 32k токенів лише cache займає 4.83 GB. Плануйте 8 GB для короткого вікна і 16 GB для довгого.

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

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