Формати квантизації LLM: INT8, INT4, GPTQ, AWQ, GGUF — що вибрати?

Чому квантування LLM ламає якість відповідей

Квантування LLM переводить ваги з 16-бітного представлення в 8 або 4 біти. Стиснення ваг моделі скорочує її обсяг у два-чотири рази: вона перестає вимагати кількох прискорювачів, уміщується в пам’ять одного й відповідає помітно швидше. Плата за це — округлення кожної ваги, а помилки округлення накопичуються по всій глибині мережі.

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

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

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

Формат відповіді за низької розрядності дотримується — модель упевнено повертає потрібну структуру, але факти всередині неї підмінюються правдоподібними.

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

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

Що дає стиснення ваг: швидкість відповіді та обсяг пам’яті

Вага моделі займає основну частину пам’яті під час її роботи в режимі інференсу — і стискається першою. Перехід із повної точності на INT8 зменшує його приблизно вдвічі, на INT4 — утричі-вчетверо.

Звільнений обсяг іде під кеш контексту та збільшений розмір пакета запитів: економія пам’яті перетворюється на той запас, якого зазвичай не вистачало на піковому навантаженні.

Час відгуку падає не тому, що обчислення стали «швидшими», а тому що на кожен крок генерації з пам’яті читається менше даних.

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

Щільність розміщення моделей зростає кратно: там, де вміщалася одна велика модель, укладаються дві-чотири, включно з окремими під вузькі задачі — класифікацію, вилучення сутностей, переказ.

Замість однієї перевантаженої моделі на все виходить набір спеціалізованих, у кожної свій бюджет пам’яті та свій профіль навантаження.

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

За агресивного стиснення без калібрування на своєму домені якість відповідей може просідати, тому формат — GPTQ, AWQ, GGUF — вибирають під задачу та профіль трафіку, а не за принципом «чим менше біт, тим краще».

Порівняння форматів стиснення ваг: точність і обмеження

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

Нижче — реальні альтернативи, між якими вибирають на стенді.

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

Набори для калібрування та описи методів зручно брати в Hugging Face — там же видно, на яких даних формат перевіряли.

Як проходить впровадження: аудит, схема, перевірка, передача

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

1. Аудит моделі. Знімаємо базові метрики на повній точності: частка правильних відповідей на вашому наборі запитів, час відгуку, споживання пам’яті. Окремо позначаємо сценарії, де помилка коштує найдорожче — вони стануть контрольними.
2. Підбір режиму стиснення. Зіставляємо вимоги до якості та до доступних ресурсів: INT8 — обережний варіант, INT4 з груповим квантуванням (GPTQ, AWQ) — коли важливіша пам’ять, GGUF — для локального запуску.
3. Налаштування стиснення. Збираємо калібрувальний набір із реальних запитів, задаємо розмір групи й залишаємо чутливі шари в підвищеній точності — це дешевше, ніж втрачати якість на всьому діапазоні.
4. Тестування якості. Прогоняємо стиснений варіант за контрольними сценаріями та порівнюємо з базою: частка збігів, зв’язність відповідей, поведінка на довгому контексті. Розходження вище порогу — повертаємося до налаштування, а не списуємо на особливості стиснення.
5. Захист і відкат. Зберігаємо повновагову копію та версіонуємо ваги, щоб повернення до попередньої збірки займало хвилини.
6. Передача рішення. Віддаємо ваги, конфігурації, скрипти збірки та регламент: як оновлювати модель, чим міряти якість, за яких метрик відкочуватися. Ваші інженери відтворюють збірку без нас.

Усі заміри та обрані параметри фіксуємо у звіті — видно, чому підійшов саме цей режим стиснення і що зміниться при переході на інший.

Перелік артефактів: конфігурації, схеми, регламенти

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

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

• Конфігурації збірки та стиснення — розрядність, калібрувальний набір, закріплені версії залежностей: повторна збірка дає той самий артефакт.
• Схеми розгортання — розкладка моделі за прискорювачами, вимоги до пам’яті, точки балансування та запас на пікове навантаження.
• Політики доступу — ролі на читання та на зміну параметрів, порядок видачі ключів до сервісу виводу відповідей, журнал звернень.
• Регламенти експлуатації — що робити при просіданні якості, як відкотити попередню збірку, коли потрібна перезбірка.
• Інструкції для команди — як підняти стенд, відтворити заміри якості, додати новий формат стиснення в обв’язку.
• Документація — паспорт моделі, заміри точності до й після стиснення, журнал змін із відповідальним за кожну правку.
• Еталонні набори перевірок — питання, на яких видно деградацію після переходу на INT4: формати порівнюються на ваших даних, а не за загальними відгуками.

Комплект розрахований на самостійну роботу: перезібрати модель в іншій розрядності або повернути попередню версію можна без нашої участі.

Кейс: скоротили парк обладнання без втрати якості

Як міряли і що сталося

Модель з відкритими вагами Llama у повній точності займала чотири карти, а піковий трафік змушував масштабуватися горизонтально.

Навантажувальне тестування зібрали на записі реального трафіку з двома профілями — короткі типові питання та довгі звернення з вкладеннями: витрата пам’яті та час відповіді поводяться на них по-різному.

Метрики знімали до квантування і після кожного формату, від INT8 до групового квантування з калібруванням, на одному залізі й одному наборі запитів.

Змішана схема — INT4 на лінійних шарах, INT8 на шарах уваги та ембедингах — скоротила час відповіді майже втричі та підняла пропускну здатність у 2,6 раза на тих самих картах.

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

Що не спрацювало з першого разу

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

Оцінка відповідей розміткою операторів упала з 91% до 82% — помітніше й швидше, ніж просідання за швидкістю.

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

На виході — 90% збігів із відповідями повної моделі при пропускній здатності в 2,6 раза вищій за вихідну.

Чим відрізняється квантування LLM для сервісу і для пристрою?

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

Локальний запуск відповідає одному користувачеві в спільному пулі пам’яті пристрою, тому вирішує не швидкість, а сама можливість укласти модель.

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

INT4 беруть, коли модель не вміщається інакше, — тоді груповий розмір і калібрувальний набір підбирають під задачу.

На пристрої логіка зворотна: спочатку вкладаються в пам’ять, потім дивляться на якість. GGUF допускає часткове вивантаження шарів на процесор — модель запускається там, де цілком не розміщується, ціною затримки.

Рішення ухвалюють за замірами на своєму наборі питань, а не за таблицями з мережі: готові збірки в каталозі Hugging Face економлять час, але втрати якості в кожного сценарію свої.

Часті технічні сумніви перед стартом

Перед стартом виринають одні й ті самі питання: чи не просяде якість відповідей, що робити при оновленні моделі, чи витримає стиснена версія пікове навантаження. Формат ваг — INT8, INT4, GPTQ, AWQ чи GGUF — змінює спосіб стиснення, але самі сумніви залишаються спільними.

Відповіді нижче ми перевіряємо на ваших даних, а не на усереднених метриках.

Що відбувається при оновленні моделі?

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

Як стиснена модель поводиться під піковим навантаженням?

Виграш у пам’яті дає запас на кеш контексту та розмір одночасної обробки, тому пропускна здатність на одному сервері зростає. Але межа є: при переповненні черги зростає час відповіді. Ми знімаємо навантажувальний профіль і показуємо точку, після якої додається друга копія моделі.

Уже розгорнуто повну версію — доведеться все переробляти?

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

Обговоримо задачу і повернемося з оцінкою та планом

Щоб оцінка була предметною, а не «на око», для старту достатньо трьох речей: профілю запитів (тип задач, середня та пікова довжина контексту, співвідношення генерації та коротких відповідей), вимог до якості (які відповіді вважаються недопустимими і чи є еталонний набір питань для порівняння) та обмежень за обладнанням — на чому модель має працювати в результаті. Якщо вже є заміри часу відповіді та обсягу моделі, додайте: вони знімають цілий етап узгоджень.

У відповідь ми повертаємо:

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

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