Як обрати формат квантизації LLM: порівняння INT8, INT4, GPTQ, AWQ, GGUF
70B модель у fp16 важить 140 ГБ — не вміщається на дві RTX 3090. Квантизація LLM — єдиний спосіб стиснути до 35 ГБ з мінімальною втратою якості. За понад 5 років ми допомогли більш ніж 100 проектів оптимізувати інференс, скоротивши витрати на обладнання до 75% (економія до $10,000 на місяць на оренді GPU). Гарантія якості — сертифіковані фахівці.
Чому квантизація LLM критична для деплою?
Нестача VRAM — головна проблема при деплої великих мовних моделей. Модель 70B у fp16 не вміщається в одну consumer GPU, а дві RTX 3090 дають 48 ГБ — після квантизації до INT4 залишається запас для пакетної обробки. Швидкість інференсу зростає з 50 до 200+ tok/s, а вартість оренди GPU (наприклад, 8×A100) знижується в 4 рази — достатньо 2×L40. Економія обладнання — ключовий драйвер: квантизація 70B моделі до INT4 дозволяє розгорнути її на двох RTX 3090 замість восьми A100, знижуючи капітальні витрати в 4 рази. Зниження витрат на оренду GPU при переході з fp16 на INT4 складає до 75% за рахунок скорочення необхідної кількості прискорювачів.
Порівняння форматів квантизації
Таблиця форматів
| Формат | Точність | Стиснення (vs fp16) | Якість (perplexity) | Застосування |
|---|---|---|---|---|
| fp16 | 16-bit float | 1× | Baseline | GPU inference |
| INT8 (bitsandbytes) | 8-bit int | 2× | -0.5–1% | GPU, легко |
| GPTQ INT4 | 4-bit group-quant | 4× | -1–2% | GPU, production |
| AWQ INT4 | 4-bit activation-aware | 4× | -0.5–1.5% | GPU, краще GPTQ на 20% по perplexity |
| GGUF Q4_K_M | 4-bit mixed | 4× | -1–2% | CPU/GPU llama.cpp |
| GGUF Q8_0 | 8-bit | 2× | -0.3–0.5% | CPU/GPU llama.cpp |
| GGUF Q2_K | 2-bit | 8× | -5–10% | Крайній випадок |
| EXL2 | 2–8 bit mixed | 2–8× | Configurable | GPU, ExLlamaV2 |
Кожен формат вимагає calibration dataset (128–512 прикладів), репрезентативного для задач моделі. Неправильний calibration погіршує якість — ми підбираємо його під проект.
Який формат квантизації обрати?
GPTQ: Post‑Training Quantization з корекцією помилок
GPTQ квантизує пошарово, мінімізуючи помилку на невеликому calibration датасеті:
from transformers import AutoModelForCausalLM, GPTQConfig gptq_config = GPTQConfig( bits=4, dataset="c4", desc_act=True, group_size=128, damp_percent=0.1, ) model = AutoModelForCausalLM.from_pretrained( "meta-llama/Meta-Llama-3.1-8B-Instruct", quantization_config=gptq_config, device_map="auto" ) model.save_pretrained("./llama3-8b-gptq-int4") Calibration займає 30–120 хвилин на CPU або GPU. Як показано в GPTQ (https://github.com/IST-DASLab/gptq), цей метод забезпечує якість, близьку до fp16, при 4-кратному стисненні.
AWQ: Activation‑Aware Weight Quantization
AWQ визначає «важливі» ваги по активаціях і захищає їх від агресивної квантизації:
from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model = AutoAWQForCausalLM.from_pretrained("meta-llama/Meta-Llama-3.1-8B-Instruct") tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3.1-8B-Instruct") quant_config = { "zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM" } model.quantize(tokenizer, quant_config=quant_config) model.save_quantized("./llama3-8b-awq") AWQ дає приріст ~0.5–1% по perplexity на задачах reasoning порівняно з GPTQ (див. AWQ (https://github.com/mit-han-lab/awq)).
GGUF: універсальний формат для llama.cpp
GGUF — формат для деплою через llama.cpp, що підтримує CPU-інференс і partial GPU offloading:
# Конвертація HuggingFace моделі в GGUF python convert_hf_to_gguf.py \ --model meta-llama/Meta-Llama-3.1-8B-Instruct \ --outtype f16 \ --outfile llama3-8b-f16.gguf # Квантизація в Q4_K_M (рекомендується) ./quantize llama3-8b-f16.gguf llama3-8b-q4km.gguf Q4_K_M Варіанти квантизації GGUF (від найкращої якості до меншого розміру):
- Q8_0: 8-bit, ~8.5GB для 8B моделі, відмінна якість
- Q6_K: 6-bit, ~6.1GB, висока якість
- Q5_K_M: 5-bit mixed, ~5.1GB, хороша якість
- Q4_K_M: 4-bit mixed, ~4.1GB, рекомендується для більшості задач
- Q3_K_M: 3-bit, ~3.2GB, помітна деградація
Покроковий алгоритм вибору формату
Алгоритм вибору
- Визначте залізо: яка GPU, скільки VRAM, чи допустимий CPU-інференс.
- Виміряйте baseline: latency та throughput на fp16/bf16.
- Оберіть 2–3 кандидати: для NVIDIA GPU — AWQ та GPTQ; для CPU/гібриду — GGUF.
- Проведіть квантизацію та протестуйте на ваших даних: perplexity, метрики задачі, latency P95.
- Порівняйте та оберіть оптимум. Якщо різниця непомітна — беріть формат з кращою підтримкою (AWQ або GGUF).
Практичний приклад: деплой на 2×RTX 3090
Задача: деплой fine-tuned Llama 3.1 8B на сервері з 2×RTX 3090 (48GB VRAM сумарно) для 50 concurrent users.
Вимоги: latency P95 < 3с, throughput > 100 tok/s.
Результати тестування
| Формат | VRAM | Throughput (vLLM) | Latency P95 | Якість (perplexity) |
|---|---|---|---|---|
| bf16 | 16 GB | 180 tok/s | 1.8с | Baseline |
| AWQ INT4 | 5 GB | 280 tok/s | 1.2с | 98.5% baseline (perplexity 0.5% вище) |
| GPTQ INT4 | 5 GB | 260 tok/s | 1.3с | 98% baseline |
| GGUF Q4_K_M | 4.1 GB (CPU) | 40 tok/s | 8с | 98% baseline |
Вибір: AWQ INT4 — вміщується в одну 3090 24GB з резервом, throughput 280 tok/s перекриває вимогу, якість мінімально деградує.
Інференс квантизованої моделі через vLLM
from vllm import LLM, SamplingParams # AWQ модель llm = LLM( model="./llama3-8b-awq", quantization="awq", dtype="auto", gpu_memory_utilization=0.85, ) # GPTQ модель llm = LLM( model="./llama3-8b-gptq-int4", quantization="gptq", dtype="auto", ) outputs = llm.generate(["Привіт, як справи?"], SamplingParams(max_tokens=200)) Коли квантизація неефективна?
Якщо модель вже працює з прийнятним часом відповіді і не впирається в VRAM — квантизація надлишкова. Також вона не підходить для задач, де критична кожна десята відсотка якості (medical, legal). У таких випадках залишають fp16 або bf16, але жертвують швидкістю.
Що входить в роботу та терміни
- Аналіз моделі та заліза, підбір 2–3 форматів для тесту
- Квантизація (GPTQ/AWQ/GGUF) з calibration на ваших даних
- Інтеграція через vLLM, llama.cpp або Triton Inference Server
- Тестування latency P50/P95/P99, throughput, якості (perplexity + метрики задачі)
- Документація по розгортанню та експлуатації
- Навчання команди роботі з квантизованою моделлю
Орієнтовні терміни:
- GPTQ/AWQ для 8B моделі: 1–3 години. Для 70B: 6–18 годин.
- GGUF конвертація: 15–60 хвилин.
- Тестування та вибір формату: 1–3 дні.
- Разом: 2–5 днів під ключ.
Оцінимо ваш проект за 1 день — зв'яжіться з нами, ми підберемо оптимальний формат квантизації. Замовте аудит моделі та отримайте рекомендацію по квантизації. Досвід — понад 5 років і 100+ успішних кейсів.