Квантування LLM: порівняння 7 методів (з цифрами бенчмарків)

Квантування LLM: порівняння 7 методів (з цифрами бенчмарків)

Llama 3.3 70B у FP16 потребує 140 ГБ лише під ваги. Дві H100. У Q4_K_M та сама модель вкладається приблизно у 42 ГБ, а це одна вживана RTX A6000 з eBay. Саме цей розрив і є причиною існування квантування LLM, і неправильний вибір методу коштує або якості, яку видно одразу, або VRAM, якого у вас немає.

Цей посібник із квантування LLM порівнює 7 методів, які мають значення у 2026 році, і кожне число тут простежується до опублікованого джерела.

Головні висновки

• Квантування міняє пам'ять і пропускну здатність на вимірну, зазвичай невелику, втрату якості.
• GPTQ і AWQ орієнтовані на GPU; GGUF той формат, що працює ще й на CPU.
• Q4_K_M дає близько 4,8 біта на вагу, а не 4. Назва приховує накладні витрати.
• 6-бітове квантування тримається в межах ~0,1% від перплексії FP16, згідно з PR k-quants у llama.cpp.

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

Квантування LLM зберігає ваги моделі з нижчою числовою точністю, зменшуючи пам'ять і пропускну здатність ціною похибки округлення. Модель на 70B параметрів стискається зі 140 ГБ у FP16 до приблизно 42 ГБ у 4-бітному форматі. Інтелект залишається, зникають десяткові знаки. Кожен метод у цьому посібнику є варіацією цього компромісу.

Шкала точності йде від FP32 (32 біти) через FP16 і BF16 (по 16 бітів), далі INT8, потім INT4. Кожен крок удвічі зменшує кількість байтів на параметр. Стандарт IEEE 754 визначає формати чисел з рухомою комою, а стаття Марка Горовіца "Computing's Energy Problem" 2014 року показала, чому саме переміщення цих байтів, а не арифметика над ними, домінує в енерговитратах. Це фізична причина того, що квантування прискорює інференс.

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

Ваги квантуються добре, бо вони статичні й розподілені нормально. Активації ні. Викиди активацій, іноді у 100 разів більші за медіану, роздувають похибку округлення при наївному квантуванні. Через цю асиметрію більшість методів тут квантують лише ваги (W4A16) і лишають активації у FP16.

Післянавчальне квантування (PTQ) конвертує готову модель після навчання. Квантування з урахуванням навчання (QAT) імітує округлення під час навчання, щоб модель адаптувалася. Усе в цій статті це PTQ. QAT коштує більше обчислень і потребує прогону навчання, це окреме рішення.

Рядки INT4 і NF4 це теоретичні чисті 4 біти: 4 біти на вагу і нічого більше. Реальні 4-бітні формати несуть зверху ще й масштаби та мінімуми блоків, тому виходять більшими. Модель 70B у Q4_K_M це близько 42 ГБ, а не 35. Таблиця VRAM нижче використовує саме ефективні значення.

Квантування не зменшує інтелект моделі. Воно зменшує кількість десяткових знаків, у яких цей інтелект зберігається. А якщо ви платите за токени API-інференсу, скорочення рахунків за LLM API часто починається з запуску квантованої моделі власними силами.

7 методів квантування пліч-о-пліч

Сім методів нижче покривають усі виробничі шляхи квантування LLM у 2026 році. Два працюють лише на GPU (GPTQ, AWQ), один працює будь-де (GGUF), один квантує під час завантаження (BitsandBytes), два націлені на високопропускний сервінг (SmoothQuant, FP8), і один є рідним для PyTorch (TorchAO). Правильний вибір залежить від вашого заліза, а не від того, який метод посідає найвище місце в таблиці лідерів.

GPTQ квантує шар за шаром, використовуючи обернену матрицю Гессе для перерозподілу похибки округлення між вагами, що залишилися. Потрібен калібрувальний набір і GPU. Стаття про GPTQ повідомляє про квантування моделі 175B до 3-4 бітів приблизно за 4 GPU-години.

AWQ знаходить ~1% найважливіших ваг (значущі ваги, визначені за амплітудами активацій) і масштабує їх, щоб захистити від округлення. Стаття про AWQ (найкраща стаття MLSys 2024) повідомляє про понад 3-кратне прискорення проти FP16-реалізації HuggingFace як на десктопних, так і на мобільних GPU.

GGUF це файловий формат, а не алгоритм. Алгоритм усередині це блокова схема k-quant із llama.cpp PR #1684. Це єдиний метод тут, що працює на CPU, тож він є типовим для локального інференсу. Що саме йому згодовувати, дивіться у відкриті моделі, варті квантування.

BitsandBytes квантує під час завантаження, а не заздалегідь. NF4 (4-бітний NormalFloat) його фірмовий формат, і це основа донавчання QLoRA. Калібрувальний набір не потрібен.

SmoothQuant переносить викиди активацій у ваги, щоб і ваги, і активації працювали в INT8. Стаття повідомляє про прискорення до 1,56x і вдвічі менше споживання пам'яті, і націлена на пропускну здатність при сервінгу великих батчів, де методи W4A16 лишають продуктивність на столі.

FP8 (W8A8) рідний шлях на GPU H100 і B200. Майже без втрат на 8 бітах, без головного болю з калібруванням, і vLLM підтримує його напряму.

TorchAO власна бібліотека квантування PyTorch, створена для роботи з torch.compile. Якщо ваш пайплайн уже на PyTorch, це шлях найменшого опору.

Насправді питань лише два: чи ваше залізо це потягне, і чи готові ви жити з ціною якості?

Що насправді показують опубліковані бенчмарки?

Опубліковані бенчмарки кажуть, що 4-бітове квантування коштує 1-2% перплексії на моделі 7B, а 6-бітове менше ніж 0,1%. Ці цифри походять із llama.cpp PR #1684 (2023), виміряні супровідниками llama.cpp на одній моделі 7B з RTX 4080. Це найбільш цитовані цифри у сфері квантування, і вони справжні. Але це також n = 1.

Джерело: llama.cpp PR #1684 (2023). Модель 7B, RTX 4080, виміряно супровідниками llama.cpp. n = 1 модель.

Щодо стовпчика біт/вагу: це номінальні значення для базового типу k-quant, а мікси з _K підвищують ефективне значення. Q2_K показовий приклад. Підставте номінальні 2,5625 і модель на 6,74B параметрів у формулу з цієї статті, і вийде ~2,0 ГБ, але в рядку файл 2,67 ГБ, що дає зворотним розрахунком ~3,4 біта на вагу. Далі ця стаття використовує ефективні значення, виведені з цих розмірів файлів.

Цифри для GPU-методів взяті безпосередньо зі статей. GPTQ повідомляє про прискорення інференсу відносно FP16 приблизно 3,25x на A100 і ~4,5x на A6000, з квантуванням моделі 175B до 3-4 бітів за приблизно 4 GPU-години. AWQ повідомляє про "понад 3-кратне прискорення проти FP16-реалізації HuggingFace як на десктопних, так і на мобільних GPU", а також про перший деплой Llama-2 70B на мобільному GPU через TinyChat. Ми цитуємо формулювання статті, а не перефразовуємо число до хибної точності.

Оригінальний внесок тут це арифметика. Пам'ять під ваги описується так: ваги (ГБ) ≈ параметри (B) × біт на вагу ÷ 8. Пастка в тому, яке саме значення біт на вагу ви підставите. PR #1684 публікує значення для базового типу k-quant (Q4_K = 4,5), а мікси _S/_M/_L лежать вище за базове, бо віддають додаткові біти тензорам уваги та прямого поширення. Тож ми вивели ефективні значення з розмірів файлів, які публікує сам PR, для моделі 7B, що насправді має 6,74B параметрів: Q2_K при 2,67 ГБ дає зворотним розрахунком ~3,4 біт/вагу, Q4_K_S при 3,56 ГБ ~4,5, Q6_K при 5,15 ГБ ~6,6. Q4_K_M виходить близько 4,8.

Це змінює головну цифру. Модель 70B у Q4_K_M: 70 × 4,8 ÷ 8 = 42 ГБ. Більшість статей кажуть 35 ГБ. Вони використовують 4,0 біт/вагу і повністю ігнорують накладні витрати блокових масштабів. Перевірка займає один клік: Llama-3.3-70B-Instruct-Q4_K_M.gguf важить 42,5 ГБ на HuggingFace, однаково в репозиторіях bartowski, lmstudio-community і second-state. Ми перерахували кожну клітинку таблиці VRAM нижче на цій основі.

Наше прочитання цих цифр: різниця перплексії між Q6_K (5,9110) і F16 (5,9066) становить 0,0044, а це менше за різницю між двома різними донавчаннями тієї самої базової моделі. Тому порада "просто беріть Q4_K_M або Q5_K_M" витримує зіткнення з реальним залізом. Стовпчик мс/токен також показує, що Q2_K не дає жодного виграшу швидкості над Q4_K_S (обидва 15,5 мс/токен), коштуючи 0,75 перплексії. Q2_K найгірший обмін у таблиці.

Чого цифри не кажуть: перплексія на wikitext не те саме, що якість на ваших промптах. Одна модель на одному GPU це n = 1. Показники швидкості залежать від розміру батчу. Ставтеся до них як до орієнтирів, а не універсальних істин.

6-бітове квантування тримається в межах приблизно 0,1% від перплексії повноточної моделі. На цьому рівні стиснення майже безкоштовне.

GPTQ проти AWQ: вибір між двома GPU-методами

GPTQ і AWQ обидва дають 4-бітні GPU-чекпойнти з калібрувального набору, і обидва добре підтримуються у vLLM. Різниця в тому, як вони поводяться з похибкою округлення. GPTQ перерозподіляє її між вагами, що залишилися, через обернену матрицю Гессе. AWQ захищає 1% ваг, які активації позначають як важливі. Обидва працюють. Вибір стосується вашого патерну сервінгу.

GPTQ працює шар за шаром. Для кожного шару він квантує по одній вазі, потім підлаштовує решту ваг у цьому шарі, щоб компенсувати щойно зроблене округлення. Підлаштування використовує інформацію другого порядку з матриці Гессе, тому й потрібен калібрувальний набір для обчислень. Результат сильний для пакетного інференсу, де пропускна здатність важливіша за затримку на токен.

AWQ обирає інший кут. Він знаходить значущі ваги, дивлячись на амплітуди активацій у калібрувальному наборі, приблизно верхній 1% каналів. Ці ваги отримують поканальний масштабний множник, що тримає їх у діапазоні вищої точності під час округлення. Калібрувальний набір може бути меншим, ніж для GPTQ, і AWQ менше перенавчається під нього, бо захищає структурні ознаки, а не підганяє під конкретні входи. Стаття повідомляє про сильні результати на сервінгу, чутливому до затримки.

Обирайте GPTQ, якщо: ви робите пакетний інференс на GPU, маєте хороший калібрувальний набір зі своєї предметної області, і метрика це пропускна здатність.

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

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Якщо ви ще й обираєте між рушіями сервінгу, vLLM проти SGLang розбирає це рішення окремо.

GGUF і K-Quants: що насправді означає Q4_K_M

GGUF це файловий формат, а не алгоритм квантування. Специфікація GGUF визначає контейнер для ваг моделі, метаданих і даних токенайзера. Алгоритм квантування всередині файлу GGUF це блокова схема k-quant (або i-quant) із llama.cpp PR #1684. Плутати контейнер з алгоритмом найпоширеніша помилка у цій сфері, і вона породжує питання на кшталт "що краще, GGUF чи GPTQ?", які не зовсім коректні.

Схема назв розшифровується так. Q означає блокову схему k-quant; IQ означає i-quant з матрицею важливості (новіший варіант, що використовує матрицю важливості для кращої якості на тій самій бітовій глибині). Число це номінальна бітова глибина. _K позначає родину k-quant на противагу застарілим форматам як Q4_0. _S, _M, _L визначають, які групи тензорів отримують додаткові біти: small, medium, large. Вищий суфікс означає більше бітів для тензорів уваги та прямого поширення, які найважливіші.

Ефективні значення, виведені зворотним розрахунком із розмірів файлів 7B (6,74B параметрів), опублікованих у PR #1684, а не з цифр базового типу. Рядки legacy точні за побудовою: блок Q4_0 це 32 ваги по 4 біти плюс один масштаб FP16, тобто 4,5 біта на вагу, а Q8_0 це 32 ваги по 8 бітів плюс масштаб FP16, тобто 8,5. PR це підтверджує, вказуючи однаковий розмір 3,56 ГБ для файлів 7B Q4_0 і Q4_K_S.

Q4_K_M це не 4 біти на вагу. Це приблизно 4,8. Блокові масштаби й мінімуми мають десь жити, а мікс _M ще й витрачає додаткові біти на тензори уваги та прямого поширення, саме тому Q4_K_M лежить вище за Q4_K_S, а Q3_K_M вище за Q3_K_S, а не збігається з ним.

Чому GGUF працює там, де GPTQ не може: він підтримує інференс на CPU та офлоадінг шарів між VRAM GPU і системною RAM. Модель 32B, що не вміщується повністю на вашому GPU, може працювати з половиною офлоаджених шарів, повільно, але функціонально. GPTQ шляху на CPU не має.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Уперше з локальними моделями? Почніть із запуску першої локальної моделі, перш ніж квантувати що-небудь. А якщо хочете браузерний інтерфейс, Open WebUI поверх Ollama ставиться приблизно за десять хвилин. Документація HuggingFace GGUF пояснює, як Hub виставляє назви типів квантування.

BitsandBytes, Marlin, SmoothQuant і TorchAO

Ці чотири покривають решту виробничих шляхів. Жоден з них не є "кращим GPTQ". Вони розв'язують різні задачі.

BitsandBytes квантує під час завантаження, а не заздалегідь. Ви вказуєте йому на FP16-чекпойнт, і він конвертує на льоту в NF4 або FP4. Без калібрувального набору, без офлайн-кроку. Його головна слава QLoRA: заморожена 4-бітова базова модель з адаптерами LoRA, навченими зверху, що робить донавчання моделі 65B на одному GPU можливим у 48 ГБ VRAM. QLoRA це техніка навчання, а не інференсу, але саме через неї більшість уперше стикається з BitsandBytes.

Marlin не метод квантування. Це GEMM-ядро зі змішаною точністю INT4xFP16, яке робить наявні 4-бітні чекпойнти швидшими на помірних розмірах батчу. Стаття про Marlin повідомляє про прискорення на A100 і H100. Якщо ваш стек сервінгу його підтримує, ви вмикаєте його на вже квантованій моделі. Не буває "квантувати через Marlin".

SmoothQuant зсуває викиди активацій у ваги через поканальний масштабний множник, роблячи W8A8 (і ваги, і активації в INT8) життєздатним. Стаття націлена на сервінг великих батчів, де методи W4A16 лишають пропускну здатність на столі. Якщо ви обслуговуєте сотні одночасних запитів, це ваш хід.

TorchAO квантування, рідне для PyTorch, що працює з torch.compile. Без зовнішніх залежностей, без конвертації форматів. Якщо ваш пайплайн інференсу вже на PyTorch, це опція з найменшим тертям. Для запуску моделей ембедінгів локально шлях через Ollama зазвичай простіший, але TorchAO пасує кастомним стекам PyTorch.

Скільки VRAM потрібно квантованій моделі?

Формула: ваги (ГБ) ≈ параметри (B) × біт на вагу ÷ 8. Модель 70B у Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 ГБ. Значення нижче ефективні, виведені зворотним розрахунком із розмірів файлів, які публікує llama.cpp PR #1684, а не з цифр базового типу, бо мікси _M завжди працюють вище за базове значення k-quant. Ми перераховували, а не копіювали звичне скорочення 4,0 біт/вагу.

Обчислено з ефективних біт на вагу: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Виведено з розмірів файлів 7B (6,74B параметрів) у PR #1684, потім звірено з опублікованою збіркою 70B: Llama-3.3-70B-Instruct-Q4_K_M.gguf важить 42,5 ГБ на HuggingFace проти передбачених тут 42,0 ГБ.

Чесне застереження: це лише ваги. KV-кеш, довжина контексту й накладні витрати фреймворку додаються зверху. KV-кеш масштабується з довжиною контексту та розміром батчу. Сеанс із контекстом 32k на моделі 70B може додати кілька ГБ. Таблиця ваг це підлога, а не бюджет. Ваше контекстне вікно теж орендує VRAM. Повну картину дивіться у вимоги VRAM для кожної моделі детально.

Який метод квантування обрати?

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

Для більшості читачів на споживчому залізлі правильна відповідь це готовий квантований GGUF Q4_K_M або Q5_K_M. Завантажте з HuggingFace, запустіть в Ollama або llama.cpp і припиніть оптимізувати. Різниця якості між Q4_K_M і Q5_K_M достатньо мала, щоб обирати за тим, чи вміщується файл, а не за таблицею перплексії. Усе, що виходить за ці межі, оптимізація заради оптимізації, і вона варта зусиль, лише коли ви переконалися, що модель у Q4 реально розв'язує вашу задачу.

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

П'ять способів зламати квантування

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

1. Калібрувальний набір не з вашої області. GPTQ і AWQ обидва підлаштовуються під калібрувальні дані. Якщо калібруєте на Wikipedia, а деплоїте на медичних транскриптах, квантована модель програє на токенах, яких ніколи не бачила. Виправлення: використовуйте калібрувальний набір із реального розподілу ваших входів, навіть 128 зразків допомагають.

2. Завеликий розмір групи. Розмір групи GPTQ визначає, скільки ваг ділять один масштабний множник. Стандарт 128. Значення 256 або 512 економлять обчислення під час квантування, але впираються в прірву якості на менших моделях. Виправлення: тримайтеся 128, якщо не підтвердили, що якість тримається на ваших промптах.

3. Очікування, що Q2_K придатний. За даними PR #1684, Q2_K коштує ~0,87 перплексії проти F16 і не дає жодного виграшу швидкості над Q4_K_S (обидва 15,5 мс/токен на бенчмарку 7B). Ви отримуєте менший файл і гірший вивід без виграшу затримки. Виправлення: Q4_K_S це підлога, якщо розмір файлу не є жорстким обмеженням.

4. Бенчмаркинг на перплексії wikitext замість власних промптів. Перплексія метрика мовного моделювання. Вона не вимірює, чи модель дотримується вашого системного промпту, коректно формує JSON або володіє лексикою вашої області. Виправлення: проженіть 20-30 реальних промптів через квантовану й неквантовану модель і порівняйте вивід.

5. Плутанина між контейнером GGUF і алгоритмом квантування всередині. Це веде до порівнянь "GGUF проти GPTQ", наче вони однієї категорії. Це не так. GGUF це файловий формат. Схема k-quant усередині нього це алгоритм. Виправлення: порівнюйте рівні k-quant (Q4_K_M проти Q5_K_M), а не формати файлів.

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

Що таке квантування LLM?

Квантування LLM зменшує числову точність ваг моделі, зазвичай з 16-бітних чисел з рухомою комою до 4- або 8-бітних цілих. Це скорочує споживання пам'яті й прискорює інференс за рахунок зменшення пропускної здатності. Модель 70B стискається зі 140 ГБ до приблизно 42 ГБ на 4 бітах. Ціна якості зазвичай 1-2% перплексії на 4 бітах, менше на 6 бітах.

Чи знижує квантування точність моделі?

Так, але менше, ніж більшість очікує. За бенчмарками llama.cpp PR #1684, Q4_K_S на моделі 7B коштує близько 2% перплексії проти F16, а Q6_K менше ніж 0,1%. Практичний вплив на реальних промптах часто менший, ніж підказує число перплексії, особливо від Q4_K_M і вище.

Що краще, GPTQ чи AWQ?

Жоден не є універсально кращим. GPTQ використовує перерозподіл похибки через обернену матрицю Гессе і пасує пакетному інференсу на GPU. AWQ захищає значущі ваги через масштабування з урахуванням активацій і пасує сервінгу, чутливому до затримки. AWQ потребує меншого калібрувального набору й менше під нього перенавчається. Якщо обслуговуєте одно-користувацькі запити з низькою затримкою, починайте з AWQ.

Що означає Q4_K_M?

Q4_K_M це рівень квантування k-quant GGUF. "Q4" означає номінальну 4-бітову глибину, "K" позначає блокову схему k-quant (на противагу застарілому Q4_0), а "M" означає medium: тензори уваги та прямого поширення отримують додаткові біти. Ефективна кількість біт на вагу близько 4,8, а не 4,0, бо блокові масштаби й мінімуми додають накладні витрати, а мікс medium витрачає ще більше зверху.

Чи можна запустити квантовану модель на CPU?

Так, але лише через GGUF. GPTQ і AWQ це формати тільки для GPU. Моделі k-quant у GGUF працюють на CPU через llama.cpp або Ollama і підтримують офлоадінг шарів між VRAM GPU та системною RAM. Q4_K_M стандартне квантування для CPU. Розраховуйте на повільнішу генерацію токенів, ніж на GPU, але робочий інференс.

У чому різниця між GGUF і GGML?

GGML це старіша бібліотека тензорів і файловий формат, який спочатку використовувала llama.cpp. GGUF замінив його у серпні 2023 року як гнучкіший формат контейнера з кращою підтримкою метаданих. Файли GGUF це те, що ви завантажуєте з HuggingFace сьогодні. Файли GGML це спадщина, і їх майже не поширюють.

Квантувати модель самостійно чи завантажити готову?

Спочатку завантажте готову. Спільноти llama.cpp і HuggingFace уже квантували більшість популярних моделей на кожному рівні. Квантувати самотужки має сенс, лише якщо потрібен специфічний калібрувальний набір для вашої області або якщо готової версії для вашої моделі не існує.

Коли обирати квантування замість меншої моделі?

Обирайте квантування, коли потрібні можливості більшої моделі, але вона не вміщується в пам'ять. Квантована модель 70B зазвичай перевершує неквантовану 13B на складних задачах міркування. Беріть меншу модель, коли обмеження це затримка, бо менші моделі генерують токени швидше незалежно від квантування.

У чому різниця між квантуванням і дистилляцією?

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

Коротка версія: квантування це спосіб вмістити бажану модель у наявне залізо. Для більшості людей на споживчих GPU або Apple Silicon готовий квантований GGUF Q4_K_M із HuggingFace це весь розв'язок. GPTQ і AWQ це відповіді для GPU-сервінгу. FP8 і SmoothQuant це відповіді для виробничої пропускної здатності. Усе інше оптимізація після того, як ви переконалися, що модель працює.

Якщо вирішуєте, що тримати на власному сервері, і хочете другу думку щодо пари залізо-метод, ми раді поговорити.