Квантизація локальних LLM: Q8 дає запас, а обрив якості починається нижче Q4

Коротко (TL;DR)

• Від Q8 до Q5 якість майже не рухається. На моделі 7B приріст perplexity до вихідних 16 біт становить 0,0004 у Q8_0 і 0,0142 у Q5_K_M — це соті частки, яких у відповіді не видно.
• Обрив проходить не між Q4 і Q8, а нижче Q4. На Llama-3.1-8B шкільна математика GSM8K тримається на 77,4 бала в Q4_K_M проти 77,6 у вихідній точності, а на Q3_K_S падає до 68,3.
• Прискорення живе тільки в генерації. На M2 Ultra перехід із 16 біт на Q4_0 піднімає видачу з 41,0 до 94,3 токена за секунду, але обробку промпту опускає з 1401,9 до 1238,5 — квант не пришвидшує читання вашого запиту, він пришвидшує відповідь.
• Малій моделі втрачати нічого. На чотирьох бітах Qwen3-0.6B зберігає 70,8% власного результату, а Qwen3-14B — 98,1%.
• Першими ламаються математика, дотримання інструкції та рідкісні мови, останньою — побутова розмова. Розрив між автоматичними метриками та живою оцінкою на неанглійській сягає дев’ятикратного.
• KV-кеш квантизується окремо й додає свою втрату: у q8_0 вона вимірюється тисячними частками perplexity, у q4_0 на моделях з агресивною GQA відповіді починають ламатися.

Дані актуальні на 15 серпня 2026 року. Власних замірів у редакції з цієї теми немає: усі цифри нижче — чужі, і в кожної названо модель, тест і бекенд.

Що квантизація робить із вагами моделі: округлення блоками

Квантизація моделі — це округлення чисел (трапляється й варіант «квантування», це те саме). Навчена модель зберігає мільярди ваг, кожна вага — дробове число в 16 бітах. Квантизація переводить їх у цілі числа меншої розрядності: 8, 5, 4 або 3 біти на вагу. Файл стискається пропорційно, а разом із ним падає обсяг пам’яті, який модель займає під час роботи.

Округлюють не кожне число окремо, а блоками. Ваги ріжуться на короткі відрізки — наприклад, по 32 штуки, — і всередині відрізка шукається спільний множник (масштаб), на який множиться ціле число, щоб повернути приблизне вихідне значення. У найпростішій схемі вага відновлюється як w = d × q, де q — збережене ціле, d — масштаб блока. У схемі трохи складнішій до цього додається мінімум блока: w = d × q + m. Саме ці дві схеми в іменах файлів позначені нулем і одиницею: Q4_0, Q4_1.

Звідси два неочевидні наслідки.

Перший: «4-бітний» квант — не 4 біти на вагу. Масштаб і мінімум теж треба десь зберігати, і вони займають місце. У сучасного формату Q4_K реальна витрата — 4,5 біта на вагу, у Q5_K — 5,5, у Q6_K — 6,5625. Так влаштовані k-кванти, введені в llama.cpp: супер-блок із 8 блоків по 32 ваги, масштаби й мінімуми всередині супер-блока квантизуються шістьма бітами.

GLM-5.3 знайшла 1097 критичних багів — Z.ai притримала ваги на два тижні

Відеопам’ять під LLM: 10 моделей, 5 квантів і формула для KV-кешу

Ollama, LM Studio і llama.cpp на одній моделі: від 0,3% різниці до трьох разів

DGX Spark, Mac Studio і Strix Halo: 120B тримають усі три, 70B буксує у двох

RTX 5090, 4090 і 3090 у локальних LLM: чужі заміри в одній таблиці

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

Q4_K_M, Q5_K_S, Q8_0: як читати позначення GGUF

GGUF — це формат файлу, у якому модель лежить на диску; сам собою він нічого не квантизує. Квант задається суфіксом імені, і читається він за трьома частинами.

Літери S, M, L — це не «маленький, середній, великий файл», а різна щедрість до різних частин моделі. У варіанті M матриці attention.wv, attention.wo і feed_forward.w2 квантизуються на щабель вище, ніж усе решта: ці тензори виявилися найчутливішими до округлення. У варіанті S вся модель квантизується одним типом. Різниця в розмірі при цьому невелика — на 8B-моделі між Q4_K_S і Q4_K_M усього 0,23 ГБ.

Наскільки k-кванти виграли в старих схем, видно на одному порівнянні. За таблицею llama.cpp для моделі 7B старий Q4_0 важить 3,50 ГБ і додає 0,2499 до perplexity, а Q4_K_M важить 3,80 ГБ і додає 0,0535. За 0,3 ГБ різниці в розмірі — майже п’ятикратне скорочення втрати. Завантажувати сьогодні Q4_0 сенсу немає, і саме тому в картках моделей на Hugging Face цей формат стоїть без позначки «рекомендовано».

Окрема практична порада для пошуку. Матеріалів із цифрами українською по темі майже немає, а живі запити в пошуку — переважно латинські: gguf quantization types шукають, коли треба розшифрувати суфікси, gguf quantization comparison — коли потрібне порівняння рівнів між собою, gguf quantization explained — коли потрібна механіка. Усі три питання закриті нижче, але якщо копатимете глибше, шукати варто саме цими формулюваннями.

Importance matrix: чому два різні Q4 одного розміру не рівні

Два файли з однаковим іменем Q4_K_M і однаковою вагою, викладені різними людьми, можуть поводитися по-різному. Причина — importance matrix, вона ж imatrix.

Без неї квантизація розв’язує просте завдання: округлити блок так, щоб середня помилка відновлення ваг була мінімальною. Усі ваги при цьому вважаються рівноцінними. Але вони не рівноцінні: частина ваг майже не бере участі в роботі, а частина спрацьовує на кожному другому токені.

imatrix — це таблиця, знята заздалегідь: модель проганяють по калібрувальному тексту й записують, наскільки сильно активувалася кожна ділянка вагової матриці. Далі квантизація мінімізує вже зважену помилку — береже те, що реально працює, і не витрачає точність на баласт.

Яким має бути калібрувальний текст — питання, у якому інтуїція підводить. Логічно припустити, що калібрувати треба на текстах тієї галузі, де модель працюватиме. Замір в обговоренні llama.cpp показав протилежне: 8 тисяч майже випадкових токенів дали результат кращий, ніж 90 тисяч «чистих» текстів у стилі навчального корпусу — на профільних даних perplexity 8,3157 проти 8,3577 за еталона q8_0 8,1901, і на сторонніх даних (тексти пісень) той самий порядок: 15,4084 проти 15,6798 за еталона 14,8318. Різниця невелика, але стійка й в обидва боки.

Практичні наслідки три:

1. Той самий рівень кванта в різних складальників дає різну якість — і за іменем файлу цього не видно. Дивитися треба в картку моделі: в акуратних складальників на кшталт bartowski прямо вказано, що квантизація йшла з imatrix і на якому калібрувальному наборі.
2. Що нижчий квант, то сильніший внесок калібрування. На восьми бітах вона майже не важлива, на трьох і нижче — визначальна.
3. «Каліброване нашою мовою» саме собою не гарантує кращого результату — судячи із заміру вище, склад калібрувального набору важливіший за його тематику. Перевіряти доводиться на своїх задачах, готової відповіді тут немає.

Методика замірів: чия модель, який тест, скільки прогонів

Кожна цифра в цій статті належить конкретному заміру, і без методики вона незіставна з іншою. Ось хто і що вимірював.

Тепер про метрику, яка трапляється частіше за всі інші разом узяті.

Perplexity — це міра «здивування» моделі текстом, а не міра якості відповіді. Моделі дають прочитати еталонний текст і дивляться, наскільки впевнено вона передбачала кожне наступне слово. Число зручне: обчислюється швидко, порівнюється легко, зростає монотонно в міру стиснення моделі. Але перекладається в «стала гірше відповідати» воно погано, і цьому є два прямі докази.

Перший — із тієї самої роботи, де обчислювалися бенчмарки Llama-3.1-8B. Формати Q5_0 і Q5_K_S дають одну й ту саму perplexity 7,43, а на шкільній математиці розходяться на 3,42 бала: 79,08 проти 75,66. Однакове «здивування» текстом, різна поведінка на задачі.

Другий — із розбору KL-дивергенції на Mistral 7B, опублікованого на Хабрі. У Q3_K_M середній приріст розходження з вихідною моделлю становить 0,037, а в найгірших 5% токенів — 0,263, розрив у сім разів. У Q2_K — 0,082 проти 0,713, розрив у 8,6 раза. Інакше кажучи, середня цифра ховає рівно ті випадки, де модель ламається: на дев’яти токенах із десяти квант непомітний, а на десятому дає інше рішення.

Третій доказ — багатомовний, і про нього окремий розділ нижче.

Таблиця втрат: скільки якості коштує кожен крок униз від Q8

Почнемо з формату, який цитують найчастіше. Історична таблиця llama.cpp знята на моделі 7B і показує приріст perplexity до вихідних 16 біт.

Читати її треба із застереженням, якого немає майже ні в кого з тих, хто її передруковує: це LLaMA першого покоління, модель 2023 року. Архітектури відтоді змінилися, і переносити конкретні значення на свіжу 8B не можна. Що переноситься — форма кривої: від Q8 до Q5 втрата вимірюється сотими, між Q5 і Q4 подвоюється, нижче Q4 росте кратно.

Свіжий замір на Llama-3.1-8B-Instruct — робочій конячці локального запуску в сімействі Llama — цю форму підтверджує й додає те, чого в таблиці perplexity немає: поведінку на задачах.

Розміри файлів — із картки готових збірок на Hugging Face; відсотки стиснення в самій роботі їм відповідають (у Q8_0 файл менший за вихідний на 46,9%, у Q4_K_M — на 69,4%).

Що тут видно.

Від Q8 до Q4 різниці майже немає, і вона не завжди на користь старшого кванта. На математиці Q5_K_M і Q6_K обійшли вихідну модель у 16 бітах, а Q4_K_S поставив найкращий результат на дотриманні інструкції. Це не «квантизація покращує модель» — це шум вимірювання в один прогін. Саме так і треба читати різницю в частки бала: як нуль.

Обрив починається на трьох бітах. Від Q4_K_S до Q3_K_M математика втрачає 4,2 бала, а до Q3_K_S — 9,0. Perplexity за той самий шлях росте з 7,62 до 8,96.

Джерела не сходяться, і це варто сказати прямо. Робота з оцінкою десяти моделей і робота IJCAI дають одне: великі моделі тримають удар краще. Замір компанії Latitude дає протилежний приклад — Llama 3.3 70B втрачає 7,8 бала MMLU під час переходу на чотири біти. Усереднювати таке не можна: у замірів різні методи квантизації та різні набори задач. Висновок, який витримують усі три, — втрата нелінійна й сильно залежить від конкретної моделі, а не лише від кількості біт.

Самостійний прогін на Хабрі на тій самій Llama-3.1-8B, де perplexity обчислювалася на російськомовному тексті, показує ту саму картину в інших абсолютних числах: Q5_K_S дає +1% до perplexity відносно 32 біт, Q2_K — +49%. Абсолютні значення з англомовними таблицями незіставні, бо текст інший, — а от форма кривої збігається.

Швидкість упирається в шину пам’яті, а не в обчислення

Поширене пояснення «Q4 швидший, бо менше обчислень» неправильне. Обчислень під час квантизації стає навіть більше: перед множенням цілі числа треба розгорнути назад у дробові. Виграш береться з іншого місця.

Щоб видати один токен, модель зобов’язана прочитати з пам’яті всі свої ваги. Не частину, а всі. Отже, швидкість генерації впирається не в потужність чипа, а в пропускну здатність шини пам’яті: скільки гігабайтів за секунду залізо здатне прокачати. Стиснули файл удвічі — удвічі менше даних на токен — швидша відповідь.

З обробкою промпту все навпаки. Ваш запит модель обробляє пачкою токенів одразу, ваги при цьому читаються один раз на всю пачку, і вузьким місцем стає арифметика. Тут квантизація не допомагає, а заважає — деквантизація забирає такти.

Саме це видно в загальній таблиці замірів llama.cpp на Apple Silicon. Стовпець pp512 — обробка промпту, tg128 — генерація; інструмент llama-bench, усі шари на GPU, модель 7B.

Генерація від кванта росте у 2,2–3,3 раза, обробка промпту падає на 4–12%. Той самий ефект незалежно отримано на процесорному сервері з двома Xeon Platinum: генерація 8B-моделі йде 2,83 токена за секунду в 16 бітах і 4,65 у Q4_K_S, а обробка промпту — 79,6 проти 92,5 за 61,4 у Q5_0, тобто скаче без жодного зв’язку з розміром файлу.

Тепер наш розрахунок, якого немає в жодного з розібраних матеріалів. Візьмемо M2 Ultra з шиною 800 ГБ/с і помножимо розмір файлу на швидкість генерації — отримаємо, скільки гігабайтів за секунду реально прокачується.

Розміри взяті з таблиці llama.cpp для 7B, тому розрахунок дає порядок величини, а не точне значення. Але висновок стійкий: файл стискається у 3,7 раза, а швидкість росте лише у 2,3. Що нижчий квант, то гірше залізо утилізує власну шину — накладні витрати на розгортання чисел з’їдають частину виграшу. Практичний сенс простий: не чекайте від Q4 чотирикратного прискорення відносно 16 біт, чекайте дво-трикратного, а між Q8 і Q4 — приблизно півторакратного.

Скільки гігабайтів за секунду прокачує конкретно ваша машина — питання вже не до моделі: цифри по відеокартах, Mac і міні-ПК зібрані в гіді по залізу для локального ШІ.

Де втрата помітна: код, математика й українська проти балачки

Середня цифра по моделі марна, бо ви не користуєтеся моделлю «в середньому». Розкладемо втрату за типами задач — це і є та частина, заради якої зазвичай і шукають відповідь.

Переживають Q4 спокійно. Здоровий глузд і побутова розмова: на HellaSwag падіння від 16 біт до Q3_K_S становить 0,64 бала — менше за розкид між прогонами. Переказ, переформулювання, чернетка листа, рольовий діалог — та сама зона. Тут Q4_K_M справді еквівалентний старшим квантам.

Ламаються першими. Порядок деградації на Llama-3.1-8B під час переходу на Q3_K_S обчислюється прямо за таблицею вище:

• шкільна математика GSM8K — мінус 9,32 бала;
• дотримання інструкції IFEval — мінус 5,04;
• фактичні знання MMLU — мінус 4,19;
• здоровий глузд HellaSwag — мінус 0,64.

Той самий порядок незалежно підтверджує робота з деградації на десяти моделях: на трьох бітах задачі на здоровий глузд зберігають помітно більше, ніж задачі на знання та міркування. Робота IJCAI додає нюанс, який варто проговорити: квантизація не так б’є по «складному», як посилює власні слабкі місця конкретної моделі — складні задачі не завжди втрачають більше за всіх. Окремо там же відзначені проблеми з дотриманням інструкції та з розпізнаванням власних вигадок.

Код. Прямий замір на HumanEval і MBPP по дванадцяти варіантах моделей чотирьох сімейств дає падіння «чистої» точності на 0,36% при восьми бітах і 1,19% при чотирьох. Цифра маленька, але в неї є два застереження: замір зроблено на bitsandbytes, а не на GGUF, і він про середню за набором задач точність. Оцінка моделлю-суддею в роботі IJCAI фіксує по коду і STEM помітне падіння там, де автоматичний рахунок його майже не показує. Практичний висновок: якщо модель пише код в агенті, де помилка в одному рядку руйнує запуск, зайвий біт вартий своїх гігабайтів.

Довгі ланцюжки міркувань. Окремого чистого заміру на GGUF-квантах тут немає, але механізм очевидний із математики: що довший ланцюжок кроків, то більше шансів, що хоча б на одному кроці округлення відведе вибір убік, а далі помилка не виправляється.

Рідкісні мови — включно з українською. Тут найбільша знахідка ресерчу. Робота Cohere порівняла три види оцінки квантизованих багатомовних моделей і отримала розрив: падіння в японській 1,7% за автоматичними тестами обертається 16,0% за оцінкою живих людей на реальних промптах. Найгірше страждають мови з нелатинським письмом, а із задач найшвидше деградує математичне міркування. Другою незалежною роботою з машинного перекладу підтверджено: що менше мова представлена в навчальних даних, то сильніший удар.

Українську в цих роботах прямо не вимірювали, тому конкретного числа для неї немає. Але клас визначається: кирилиця, не топ навчальних корпусів, калібрування складальників — англомовне. Якщо модель потрібна вам для українських текстів, орієнтуватися на англомовні графіки perplexity не можна — вони занижують шкоду. Розумний практичний хід: тримати на один щабель більше запасу, ніж радять англомовні гайди, тобто там, де англійцю вистачає Q4_K_M, брати Q5_K_M.

Велика модель у Q4 проти маленької у Q8 за рівної пам’яті

Питання звучить так: у 16 ГБ пам’яті влазить або модель на 14B у восьми бітах, або на 27B у чотирьох. Що брати?

Відповідь на нього дано не думкою, а законом масштабування. Робота Тіма Деттмерса й Люка Зеттлмоєра прогнала понад 35 000 експериментів на моделях від 19 млн до 176 млрд параметрів у розрядностях від трьох до восьми біт і сформулювала висновок одним рядком: за фіксованої загальної кількості біт чотири біти майже завжди оптимальні для якості. Тобто за рівної пам’яті велика модель у Q4 обіграє меншу в Q8.

Робота IJCAI на моделях від 1B до 405B приходить до того самого з іншого боку: квантизовані моделі часто обходять FP16-версії моделей меншого розміру.

Межі в правила дві, і обидві важливі.

Знизу. Нижче трьох біт правило розвертається: 70B-модель у двох бітах гірша, ніж 7B у чотирьох. Практична стеля стиснення — Q3, і то із застереженнями; Q2 беруть, коли альтернатива — не запускати взагалі.

Зверху по дрібних моделях. У маленької моделі немає запасу міцності, і це видно в цифрах — нижче лінійка Qwen3, найзручнішого сімейства для локального запуску за кількістю розмірів. Частка від власного результату в 16 бітах:

Замір зроблено на GPTQ, а не на GGUF K-квантах, тому переносити сюди абсолютні відсотки не можна — переноситься закономірність. А вона однозначна: що менша модель, то раніше в неї обрив. Для 0,6B чотири біти вже майже катастрофа, для 14B — плата у два відсотки.

Звідси робоче правило вибору:

1. Модель до 4B — беріть Q6_K або Q8_0, економія на квантах тут безглузда: файл і так маленький, а втрата велика.
2. Модель 7–14B — Q4_K_M базовий вибір, Q5_K_M якщо пам’яті вистачає і задачі складні. Це діапазон, у якому живе більшість робочих моделей під одну відеокарту, включно з Gemma 3 від Google.
3. Модель 27B і вище — Q4_K_M майже завжди вигідніший, ніж модель менша у Q8. Нижче Q4 спускайтеся, тільки якщо інакше не запуститься. Окремо варто тримати на думці архітектури з експертів на кшталт Solar Open 2 на 250 млрд параметрів: у роботі активна лише частина ваг, і переносити на таку модель цифри щільних моделей не можна.
4. Ніколи не оцінюйте вибір за однією цифрою біт: Q4_K_M із калібруванням і Q4_0 без нього — різні речі за однакової четвірки в імені.

Яка саме модель стане у ваш бюджет пам’яті — питання окреме, і розібране воно в добірці локальних моделей під задачу та залізо.

KV-кеш квантизується окремо — і це друге джерело втрат

Про кванти ваг пишуть усі. Про те, що поруч є другий, незалежний контур стиснення, не пише майже ніхто.

Поки модель працює з контекстом, вона тримає в пам’яті KV-кеш — проміжні ключі та значення по кожному вже обробленому токену. Цей кеш не має стосунку до файлу моделі: він живе окремо, росте лінійно з довжиною контексту і на довгих діалогах спокійно з’їдає більше пам’яті, ніж самі ваги. У 8B-моделі з контекстом 32 тисячі токенів кеш у 16 бітах займає близько 6 ГБ.

Кеш можна квантизувати окремим ключем запуску, і ціна цього виміряна. На Qwen 2.5 Coder 7B за довжини тексту 6114 токенів perplexity з кешем у 16 бітах становила 8,3891 ± 0,02016, а з кешем у q8_0 — 8,3934 ± 0,02017. Різниця 0,0043 не виходить за межі довірчого інтервалу. Пам’ять при цьому падає вдвічі: ті самі 6 ГБ перетворюються на 3 ГБ, а на q4_0 — приблизно на 2 ГБ.

Що важливо знати до того, як вмикати:

• Flash Attention обов’язковий. Без нього квантизація кешу не працює.
• q8_0 безпечний, q4_0 — ні. На моделях з агресивним груповим пакуванням голів уваги (у Qwen2 воно восьмикратне) чотирибітний кеш дає помітно зіпсовані відповіді там, де восьмибітний працює нормально. Робочий компроміс, який знайшли в обговоренні, — ключі тримати в q8_0, значення в q4_0.
• Замір один. Це не серія: одна модель, один прогін, зроблений автором самої реалізації. Незалежної перевірки у відкритому доступі я не знайшов.
• Порядок дій теж має значення. Якщо пам’яті не вистачає, спершу є сенс опустити кеш до q8_0 і залишити ваги на Q5_K_M, а не навпаки: судячи з цифр, восьмибітний кеш коштує дешевше, ніж крок униз по вагах.

Слабкі місця чужих замірів: де методики не сходяться між собою

Це не наші заміри, і ставитися до них треба відповідно.

Власного стенду в нас немає. Жодної з машин, на яких зняті наведені числа, у редакції немає; усе, що тут є, — зведення чужих публікацій із названою методикою в одну картину. Жанр матеріалу — порівняння, а не бенчмарк.

Канонічна таблиця застаріла. Ряд «Q4_K_M +0,0535, Q8_0 +0,0004» знято на LLaMA першого покоління. Його передруковують у 2026 році як актуальний, і це неправильно: у сучасних архітектур із розрідженими експертами й агресивним груповим пакуванням уваги чутливість інша.

Дані про розмір моделі отримані на іншому інструменті. Таблиця Qwen3 за розрядностями знята на GPTQ, AWQ, RTN і SPQR, а не на GGUF K-квантах. Закономірність переноситься, відсотки — ні.

Замір KV-кешу єдиний. Одна модель, один прогін, автор — розробник самої функції. Це краще, ніж нічого, але це не серія.

Прямого порівняння Q4 проти Q8 на одній GeForce з опублікованою методикою знайти не вдалося. Відкрита база замірів викладає RTX 4090 лише у Q4_K medium, і зіставити її з вісьмома бітами немає з чим. Механіка швидкості в статті показана на Apple Silicon і на процесорному сервері — там доступні обидві точки.

Один прогін — це один прогін. У роботі по Llama-3.1-8B декодування детерміноване і прогін єдиний. Різниця в частки бала між сусідніми квантами всередині такого заміру нічого не означає.

Локальні розбори містять прямі помилки. У матеріалі з конвертації в GGUF на форумі DOU написано, що Q8_0 погіршує якість приблизно на 50% відносно 16 біт. Насправді вдвічі падає розмір файлу, а виміряна дельта perplexity становить 0,0004. Якщо ви зустрічаєте відсотки якості без зазначення моделі й тесту — це майже завжди переказ переказу.

Що застаріє першим. Найшвидше — конкретні значення по моделях: нове сімейство виходить раз на кілька тижнів, і Unsloth викладає GGUF-збірки в день релізу. Механіка — блоки, шина пам’яті, порядок деградації задач — тримається довше. Свіжі цифри завжди варто дивитися в картці конкретної моделі на Hugging Face і в обговореннях llama.cpp.

Часті запитання

Який квант обрати, якщо відеопам’яті всього 8 ГБ?

Модель на 7–8B у Q4_K_M займає близько 4,9 ГБ, і це залишає запас під контекст — базовий робочий варіант. Якщо задачі розмовні, можна опуститися до Q4_K_S і заощадити ще 0,2 ГБ. Спускатися до Q3 на такій моделі не варто: саме там починається обрив, а виграш у пам’яті менший за гігабайт.

Q4_K_M чи Q4_K_S — чи є між ними різниця на практиці?

Різниця в розмірі — близько 0,23 ГБ на моделі 8B, різниця в perplexity в замірі на Llama-3.1-8B — 0,06 (7,56 проти 7,62). У варіанті M на щабель вище квантизуються найчутливіші тензори уваги. Якщо 0,23 ГБ у вас є, беріть M. Якщо не вистачає буквально цих гігабайтів під контекст, S — чесний компроміс.

Чи варто брати Q6_K замість Q8_0, якщо пам’яті вистачає на обидва?

Як правило, так. На 8B-моделі Q6_K важить 6,60 ГБ проти 8,54 ГБ у Q8_0, а приріст perplexity становить 0,0044 проти 0,0004 на семимільярдній моделі — різниця між двома способами не втратити нічого. Майже два гігабайти, що звільнилися, корисніше витратити на довжину контексту, ніж на восьмий біт.

Чому той самий Q4_K_M від різних авторів на Hugging Face працює по-різному?

Через калібрування. Квантизація з importance matrix береже ті ваги, які реально активуються на калібрувальному тексті, а без неї всі ваги вважаються рівноцінними. Ім’я файлу і його розмір при цьому збігаються. Дивіться в картці моделі, чи вказано imatrix і на якому наборі його знято; що нижчий квант, то сильніша ця різниця.

Чи потрібно квантизувати KV-кеш, якщо контекст невеликий?

Немає сенсу. На коротких діалогах кеш займає небагато, і виграш у пам’яті буде символічним, а ризик ненульовий. Квантизація кешу окупається на довгих контекстах, де він зрівнюється за обсягом із самою моделлю. Починати завжди варто з q8_0: його ціна в якості виміряна в тисячних частках perplexity.

Чи псується українська мова в моделі сильніше, ніж англійська?

За наявними даними — так, у неанглійських мов втрати більші, і особливо в мов із нелатинським письмом. Прямого заміру українською немає, але на японській розрив показовий: 1,7% падіння за автоматичними тестами проти 16,0% за оцінкою людей. Практичний висновок — тримати на один щабель кванта більше запасу, ніж радять англомовні гайди.