Больше интересного про инференс, AI-инфраструктуру и практику с LLM я публикую в Telegram-канале @fuckup_files.

TL;DR

Если очень коротко:

Главная мысль: нет одной "лучшей квантизации". Есть баланс между качеством, памятью, скоростью, kernel support и вашим железом. На RTX 3090 я бы обычно начинал с AWQ/GPTQ 4-bit для vLLM или GGUF Q4_K_M/Q5_K_M для llama.cpp. На H100/H200/B200 — сначала смотрел бы FP8/NVFP4/MXFP4 в TensorRT-LLM или FP8 в vLLM. На CPU и смешанном CPU+GPU — чаще всего GGUF.

Ниже разберёмся нормально: что именно квантуется, почему 4-bit бывает разным, почему FP8 не равно INT8, как грубо считать VRAM и какие форматы подходят под разное железо.

Что такое квантизация LLM простыми словами

Веса LLM — это огромные матрицы чисел. В обычном GPU-инференсе они часто хранятся в FP16 или BF16: примерно 2 байта на параметр. Для 70B-модели это уже около 140 ГБ только на веса, без KV cache, runtime overhead, CUDA graphs, буферов и батча.

Квантизация делает эти числа грубее:

• вместо 16 бит на вес — 8, 6, 5, 4, 3, 2 или даже около 1-2 бит;
• иногда квантуются только веса;
• иногда веса и активации;
• иногда отдельно квантуется KV cache;
• почти всегда рядом хранятся scale/min/metadata, поэтому "4-bit" на практике не всегда ровно 0.5 байта на параметр.

Интуиция такая: модель не одинаково чувствительна ко всем весам. Многие веса можно хранить грубо, а важные участки оставить точнее. Современные методы вроде AWQ, GPTQ и IQ-квантов в GGUF как раз пытаются не просто тупо округлить числа, а сохранить то, что сильнее влияет на ответ.

Что можно квантизовать: веса, активации и KV cache

Квантизация — не одна ручка. В LLM serving есть минимум три разных слоя.

1. Weight-only quantization

Квантуем только веса модели. Это самый частый путь для локальных LLM:

• GGUF Q4_K_M, Q5_K_M, Q6_K;
• AWQ W4A16;
• GPTQ W4A16;
• bitsandbytes 4-bit/8-bit.

В обозначении W4A16:

• W4 — веса в 4-bit;
• A16 — активации считаются в FP16/BF16.

Плюс: сильно уменьшается VRAM под веса.

Минус: не всегда ускоряется инференс. Если runtime каждый раз распаковывает 4-bit веса в FP16 перед матмулом, вы можете выиграть память, но не получить магического ускорения. Скорость появляется там, где есть хорошие fused kernels: Marlin, AWQ kernels, TensorRT-LLM kernels, BitBLAS, llama.cpp CUDA/Metal kernels и так далее.

2. Weight + activation quantization

Квантуем и веса, и активации: например W8A8, FP8, INT8.

Плюс: можно ускорить сами матричные операции, особенно на железе с нормальной поддержкой низкой точности.

Минус: сложнее сохранить качество. Активации зависят от входа, распределение может плавать, outlier-ы начинают портить праздник.

FP8 в современных GPU-serving стэках часто интереснее классического INT8, потому что он лучше ложится на тензорные ядра Hopper/Blackwell и часть актуальных runtime path. В TensorRT-LLM официально описаны рецепты FP8 per tensor, FP8 block scaling, FP8 rowwise, FP8 KV cache, FP4, NVFP4 KV cache и W4A16/W4A8-варианты AWQ/GPTQ. В vLLM 0.20 в таблице поддержки FP8 W8A8 отдельно отмечен для Ada/Hopper/AMD GPU, Marlin сейчас перечислен как Marlin (GPTQ/AWQ/FP8/FP4) для Turing*/Ampere/Ada/Hopper, а рядом появились отдельные пункты под NVIDIA Model Optimizer, AMD Quark, TorchAO, INT4 W4A16, Online Quantization и Quantized KV Cache.

3. KV cache quantization

KV cache — это память, куда модель складывает ключи и значения attention для уже обработанных токенов. Он растёт не от размера весов, а от:

• длины контекста;
• числа активных запросов;
• числа слоёв;
• hidden size;
• числа KV-heads;
• dtype самого cache.

Это отдельная боль. Вы можете ужать веса 70B-модели до 4-bit, радостно запустить сервер, а потом словить OOM на 32k context и параллельных запросах, потому что KV cache живёт своей жизнью.

Подробнее про механику KV cache я уже разбирал отдельно: KV cache простыми словами: почему LLM ест столько памяти на длинном контексте. А если хочется померить это не на глаз, рядом есть статья про бенчмаркинг локальной LLM: TTFT, TPOT, context length и VRAM.

Грубая формула VRAM

Для первичной прикидки достаточно такой формулы:

VRAM ~= weights + KV_cache + runtime_overhead

weights ~= params * bits_per_weight / 8

Но это именно грубая оценка. Реальный размер будет больше из-за:

• scale/min/zero-point metadata;
• разных битностей по слоям;
• tensor parallel sharding;
• CUDA graphs;
• temporary buffers;
• scheduler overhead;
• LoRA adapters;
• fragmentation;
• выбранного attention backend.

Пример для плотной 70B-модели:

Для MoE-моделей считать сложнее. Параметров может быть 200B+, но активных на токен намного меньше. Однако в inference weights всё равно обычно должны где-то лежать: в VRAM, CPU RAM, на нескольких GPU или под offload. Поэтому "активные параметры" помогают скорости, но не отменяют вопрос размещения весов.

Уровни точности: что реально отличается

FP16 и BF16: базовая честная точка

FP16/BF16 — это не квантизация в бытовом смысле, а обычная половинная точность. На GPU это стандартная база для LLM inference.

Когда хорошо:

• модель помещается;
• нужна максимальная предсказуемость;
• вы сравниваете качество разных quant-версий;
• важна совместимость с любым runtime.

Когда плохо:

• 70B не помещается на одну 80GB GPU вместе с большим KV cache;
• на consumer-картах VRAM быстро заканчивается;
• вы платите за лишнюю память и bandwidth.

BF16 обычно приятнее для обучения и некоторых inference path из-за диапазона, FP16 часто встречается в older checkpoints и runtime. Для пользователя инференса разница чаще менее важна, чем вопрос: "влезает или нет".

FP8: современный sweet spot для сильных GPU

FP8 — это 8-bit floating point, не integer. Он сохраняет экспоненту, поэтому лучше переживает широкий диапазон значений, чем прямолинейный INT8, но тоже требует аккуратных scale-ов и kernel support.

Когда FP8 хорош:

• H100/H200/B200, а также некоторые Ada/Hopper path в serving engines;
• production serving, где нужна хорошая скорость и качество;
• большие модели, где FP16 слишком жирно;
• TensorRT-LLM / vLLM / NVIDIA Model Optimizer path.

Когда FP8 не лучший выбор:

• RTX 3090/A100 Ampere в конкретном runtime path без хорошей FP8-поддержки;
• llama.cpp/GGUF сценарии, где проще взять Q5_K_M или Q4_K_M;
• если под вашу модель нет нормального pre-quantized checkpoint и вы не готовы валидировать качество после PTQ.

Важный нюанс: "GPU поддерживает какую-то низкую точность" и "ваш runtime быстро гоняет именно этот quant format" — разные вещи. Поэтому в проде надо смотреть не только на маркетинговую таблицу железа, но и на таблицу поддержки vLLM/TensorRT-LLM/SGLang/llama.cpp.

INT8 / W8A8: консервативная экономия

INT8 обычно воспринимается как спокойная квантизация: памяти примерно вдвое меньше, качество часто близко к FP16, риски ниже, чем у 4-bit. Но для LLM это не всегда самая интересная точка.

Почему:

• если цель — просто влезть, 4-bit экономит намного сильнее;
• если цель — максимальная скорость на новых NVIDIA GPU, FP8 часто выглядит привлекательнее;
• если цель — локальный запуск в llama.cpp, GGUF Q8_0 даёт почти FP16-like качество, но не всегда лучший баланс размера.

INT8 имеет смысл, когда вам нужен аккуратный компромисс, есть хороший backend и вы не хотите рисковать качеством на 4-bit.

6-bit и 5-bit GGUF: когда хочется почти без боли

В мире GGUF это очень практичные уровни.

Q6_K и Q5_K_M часто дают заметно лучшее качество, чем 4-bit, при всё ещё разумном размере. Если у вас модель влезает в Q5_K_M, я бы часто начинал именно с него, а не с Q4, особенно для:

• кодинга;
• русского языка;
• длинных рассуждений;
• задач, где модель и так на грани качества;
• MoE-моделей, где деградация может проявляться странно.

На практике Q5_K_M — хороший "не хочу страдать" формат для homelab, если хватает VRAM/RAM. Q6_K — ещё ближе к исходнику, но размер растёт.

4-bit: главный рабочий компромисс

4-bit — самый популярный уровень, потому что он резко меняет доступность моделей.

70B в FP16 — это история про несколько GPU или большую server GPU. 70B в 4-bit — уже можно обсуждать одну H100, две RTX 3090/4090, несколько consumer GPU, CPU+GPU offload или аккуратный tensor parallel.

Но 4-bit бывает разным:

Если вы запускаете через llama.cpp/Ollama/LM Studio — вы почти наверняка выбираете GGUF.

Если вы поднимаете OpenAI-compatible сервер через vLLM на NVIDIA GPU — чаще смотрите AWQ/GPTQ/Marlin/FP8/INT4 W4A16 и конкретную таблицу поддержки.

Если вы делаете TensorRT-LLM под production NVIDIA — смотрите ModelOpt, FP8/FP4/AWQ/GPTQ и support matrix под конкретную модель.

3-bit, 2-bit и около 1-bit: когда главное — чтобы вообще завелось

Вот здесь начинается зона компромиссов.

3-bit и 2-bit могут быть удивительно полезны, если выбор такой:

• 70B в 2-3 bit;
• или 14B/32B в хорошем 5-6 bit.

Иногда большая модель в грубой квантизации всё равно отвечает лучше маленькой модели в красивой точности. Особенно если важны знания, multilingual, инструменты, широкий reasoning prior.

Но риски уже заметные:

• хуже точность фактов;
• хуже следование инструкциям;
• больше деградация на коде и математике;
• сильнее плавает стиль;
• reasoning-модели могут терять устойчивость;
• маленькая ошибка quantization dataset/imatrix заметнее.

Мой практический ориентир:

• Q3_K_M, IQ3_S, IQ3_M — можно тестировать, если надо ужаться;
• IQ2_M, IQ2_XS, Q2_K — только если иначе модель не помещается;
• IQ1_* — скорее эксперимент, демо или desperate mode, а не production default.

AWQ vs GPTQ vs GGUF: почему это не одно и то же

AWQ

AWQ расшифровывается как Activation-aware Weight Quantization. Идея: не все каналы одинаково важны. AWQ смотрит на активации и старается защитить наиболее чувствительные веса/каналы, чтобы 4-bit деградировал меньше.

Плюсы:

• часто хорошее качество на 4-bit;
• много pre-quantized моделей на Hugging Face;
• хорошо ложится на GPU-serving;
• в vLLM есть AWQ/Marlin path для современных NVIDIA GPU.

Минусы:

• если квантуете сами, нужен calibration dataset;
• зависит от kernel support;
• не каждый AWQ checkpoint одинаково хорош.

GPTQ

GPTQ — тоже post-training quantization, но с другой математикой: он использует приближение второго порядка, чтобы минимизировать ошибку после квантизации весов.

Плюсы:

• зрелый формат;
• много моделей;
• хорошая точность;
• поддержка в vLLM/Transformers/TensorRT-LLM ecosystem.

Минусы:

• calibration step;
• качество зависит от датасета;
• некоторые старые GPTQ-репаки могут быть хуже новых AWQ/GGUF/IQ вариантов.

GGUF

GGUF — это не один метод квантизации, а формат файла и экосистема вокруг llama.cpp. Внутри могут быть Q8_0, Q6_K, Q5_K_M, Q4_K_M, IQ4_XS, IQ3_S, IQ2_XS и так далее.

Плюсы:

• лучший путь для llama.cpp, Ollama, LM Studio, CPU+GPU offload;
• много готовых репаков;
• работает на NVIDIA, AMD, Apple Metal, CPU;
• удобно держать несколько quant-версий одной модели и быстро сравнивать.

Минусы:

• это не основной формат для vLLM production serving;
• разные репаки одной модели могут заметно отличаться;
• названия вроде Q4_K_M не переводятся напрямую в AWQ/GPTQ;
• скорость зависит от backend и того, сколько слоёв реально ушло на GPU.

Что выбрать под конкретное железо

CPU-only

Если совсем без GPU:

• берите GGUF;
• начинайте с Q4_K_M или Q5_K_M, если хватает RAM;
• для маленьких моделей можно Q8_0;
• для больших — Q3_K_M/IQ3/IQ2, если вы готовы к просадке качества.

CPU-only почти всегда будет медленнее GPU на decode, но для локальных задач, агентов, небольшого RAG, batch-offline и экспериментов это нормальная точка входа.

Apple Silicon

Тоже чаще GGUF/MLX, а не AWQ/GPTQ под vLLM.

Практически:

• 8-16GB unified memory: 7B/8B в Q4/Q5;
• 32GB: 14B/32B в Q4, иногда больше с компромиссами;
• 64GB+: можно играться с 70B в грубом quant, но скорость и context будут ограничивать.

Тут важно помнить: unified memory — не VRAM уровня HBM. Да, модель может влезть, но tokens/sec будут совсем другой историей.

RTX 3060 12GB / RTX 4060 Ti 16GB

Реалистичный диапазон:

• 7B/8B: Q5_K_M, Q6_K, иногда FP16;
• 14B: Q4_K_M/Q5_K_M;
• 32B: сильно зависит от context, чаще Q3/Q4 и offload;
• vLLM: маленькие AWQ/GPTQ модели, но VRAM быстро кончается.

Для одиночного локального ассистента llama.cpp/Ollama часто проще и приятнее.

RTX 3090 24GB / RTX 4090 24GB

Это самая интересная homelab-классика.

Хорошие стартовые точки:

• 7B/8B: FP16/BF16, FP8 где runtime поддерживает, или GGUF Q8_0;
• 14B: FP16 иногда влезает, но Q6_K/Q5_K_M практичнее;
• 32B: Q4_K_M/Q5_K_M, AWQ/GPTQ 4-bit;
• 70B: обычно multi-GPU, 4-bit, tensor parallel или CPU offload;
• MoE: считать отдельно, потому что размер весов и active params расходятся.

Если цель — OpenAI-compatible API с батчингом, смотрите vLLM + AWQ/GPTQ. Если цель — локальная интерактивная модель, длинный context, простота и много готовых репаков, llama.cpp + GGUF часто выигрывает по удобству.

Для RTX 3090 важный нюанс: это Ampere. В vLLM 0.20 FP8 W8A8 не отмечен для Ampere, зато Marlin для GPTQ/AWQ/FP8/FP4 отмечен с Ampere/Ada/Hopper (Turing — частично, без MXFP4). То есть для 3090 я бы не начинал с "давайте FP8", а сначала проверял AWQ/GPTQ/GGUF/INT4 W4A16 и конкретный runtime.

2x/4x RTX 3090

Тут появляется другой вопрос: не только quant, но и parallelism.

Например, 70B в 4-bit может влезть по весам в 2x24GB, но:

• KV cache тоже нужен;
• tensor parallel даёт communication overhead;
• PCIe без NVLink может стать bottleneck;
• batch size и context length быстро съедают запас.

С этим связана соседняя тема: распределенный инференс LLM с Ray и vLLM. Квантизация уменьшает память под веса, но не отменяет стоимость коммуникации между GPU.

Практический выбор:

• vLLM + AWQ/GPTQ, если нужен сервер и батчинг;
• llama.cpp tensor split / offload, если нужен локальный запуск и гибкость;
• Q4_K_M как старт, Q5_K_M если хватает памяти, Q3/IQ3 если не хватает.

A100 40/80GB

A100 сильная, но это Ampere. Для неё:

• BF16/FP16 хорошо;
• INT8/AWQ/GPTQ хорошо при поддержке kernels;
• FP8 надо проверять по runtime, не считать дефолтом;
• 80GB позволяет 70B в FP8/INT8-like весах или 4-bit с большим KV cache;
• 40GB часто толкает к 4-bit для 70B.

Если у вас A100 80GB и 70B-модель, главный вопрос: хотите ли вы качество/простоту или throughput/плотность. Для одного-двух пользователей BF16 может быть норм. Для serving нагрузки уже хочется quant и batching.

H100/H200

Вот здесь FP8 становится очень серьёзным вариантом.

Для Hopper:

• TensorRT-LLM FP8 / NVIDIA ModelOpt — сильный production path;
• vLLM FP8 W8A8 поддерживается в актуальной матрице;
• KV cache FP8 может сильно помочь длинному контексту;
• AWQ/GPTQ всё ещё полезны, если нужно ужаться сильнее.

Если модель доступна в нормальном FP8 checkpoint — я бы начинал с него. Потом уже сравнивал с INT4 AWQ/GPTQ, если нужно поднять плотность или уместить модель/батч.

B200/GB200 и Blackwell

Для Blackwell важны FP4/NVFP4/MXFP4 и новые TensorRT-LLM path. Но это уже не "скачал любой GGUF и поехали", а скорее production optimization:

• ModelOpt;
• TensorRT-LLM support matrix;
• pre-quantized checkpoints;
• проверка качества на своих данных;
• бенчмарки TTFT/TPOT/throughput.

Если у вас такое железо, лучший ответ обычно не "берите Q4", а "берите официальный fast path под ваш serving engine". В vLLM 0.20 Marlin уже умеет FP4 — это даёт практический мост между GGUF/AWQ-миром и Blackwell-серверами.

AMD GPU

Тут картина зависит от ROCm, модели и runtime.

Практически:

• llama.cpp + GGUF часто проще;
• vLLM поддерживает часть quantization path на AMD, но не все;
• в таблице vLLM 0.20 GGUF и FP8 W8A8 отмечены для AMD GPU, а AWQ/GPTQ — нет;
• для AMD-only пути появился AMD Quark как отдельный quantization toolkit, интегрированный в vLLM;
• всегда проверяйте конкретную версию runtime и backend.

Для домашнего AMD — GGUF. Для production AMD — Quark или FP8 как первые серьёзные кандидаты, без веры в абстрактные совместимости.

Что выбрать по размеру модели

7B/8B

Если есть нормальная GPU:

• FP16/BF16, если помещается;
• Q8_0/Q6_K, если llama.cpp;
• FP8, если production runtime и GPU поддерживают;
• 4-bit только если очень ограничена память или нужен большой батч/context.

Не надо автоматически жать 8B в 2-bit. У маленьких моделей меньше "запаса интеллекта", и грубая квантизация бьёт больнее.

14B/32B

Здесь 4-6 bit — золотая зона:

• Q5_K_M или Q6_K для качества;
• Q4_K_M как практичный default;
• AWQ/GPTQ для vLLM;
• FP8 на подходящем железе.

Если у вас 24GB VRAM, 32B в 4-bit — уже интересный рабочий уровень.

70B

Тут квантизация почти обязательна, если нет большой server GPU или multi-GPU.

Стартовые варианты:

• H100/H200: FP8 или INT4 AWQ/GPTQ, в зависимости от нагрузки;
• 2x/4x RTX 3090/4090: 4-bit AWQ/GPTQ или GGUF Q4_K_M/Q5_K_M;
• CPU+GPU offload: GGUF Q4_K_M, если терпите скорость;
• меньше 48GB суммарной быстрой памяти: Q3/IQ3/IQ2 и честное ожидание просадки.

100B+ и MoE

Здесь нельзя смотреть только на "B".

Нужно проверять:

• total params;
• active params;
• размер checkpoint;
• число экспертов;
• expert parallel / tensor parallel support;
• можно ли разнести веса;
• какие quant-версии вообще существуют;
• не упрётся ли всё в сеть/PCIe.

Иногда MoE в 4-bit выглядит "должно влезть", а потом оказывается, что runtime path, sharding и KV cache не оставили вам воздуха.

Почему квантизация не всегда ускоряет

Это частая ловушка.

Квантизация почти всегда уменьшает память под веса. Но скорость зависит от того, где бутылочное горлышко.

Если decode memory-bandwidth bound, меньшие веса могут помочь: меньше данных читать из VRAM на каждый токен.

Если runtime делает dequantize неэффективно, выгода может уйти на распаковку.

Если batch большой, GPU уже хорошо загружен матмулами, и 4-bit weight-only может быть не таким чудом.

Если модель ушла в CPU offload, вы можете сэкономить VRAM, но потерять latency из-за PCIe/CPU memory.

Если context огромный, bottleneck может быть уже не в весах, а в KV cache.

Поэтому правильный вопрос не "какая квантизация быстрее", а:

1. Я упираюсь в веса, KV cache, compute или memory bandwidth?
2. Есть ли быстрый kernel под мой quant format?
3. Что важнее: latency одного запроса или throughput сервера?
4. Какой batch/concurrency у реальной нагрузки?
5. Как качество падает на моих задачах?

Практический decision tree

Если модель помещается в FP16/BF16

Начните с FP16/BF16 baseline. Он нужен хотя бы для сравнения качества и скорости.

Потом:

• для production throughput попробуйте FP8/INT8;
• для большего context — KV cache quantization;
• для большей модели — переходите к 4-bit.

Если модель не помещается

Сначала выберите runtime:

Потом выберите уровень:

• хватает памяти: Q5/Q6 или FP8;
• почти хватает: Q4;
• совсем не хватает: Q3/IQ3/IQ2;
• нужен production на H100/B200: FP8/FP4 path раньше GGUF.

Если качество просело

Проверяйте по порядку:

1. Поднимите quant level: Q4 -> Q5 -> Q6.
2. Смените репак: разные GGUF одной модели бывают разного качества.
3. Для GGUF попробуйте IQ/imatrix-варианты.
4. Для AWQ/GPTQ проверьте calibration dataset и свежесть checkpoint.
5. Не сравнивайте на одном красивом промпте. Нужен свой маленький eval-set.

Мини-чеклист перед скачиванием quant-модели

Перед тем как тянуть 200 ГБ файлов с Hugging Face:

• какая целевая задача: чат, код, RAG, agents, reasoning?
• какой runtime: vLLM, llama.cpp, TensorRT-LLM, Transformers?
• сколько VRAM/RAM реально свободно?
• какой context length нужен?
• сколько параллельных запросов?
• есть ли fast kernels под этот quant format?
• есть ли готовая quant-версия именно этой модели?
• кто сделал репак и чем он квантизовал?
• есть ли eval/README/known issues?
• нужен ли OpenAI-compatible serving или просто локальный интерактив?

Частые вопросы

Q4_K_M — это лучший формат?

Это хороший default для GGUF, но не универсально лучший формат. Если хватает памяти, Q5_K_M часто спокойнее. Если качество критично — Q6_K или Q8_0. Если памяти мало — IQ3/Q3. Если вы запускаете vLLM — вам вообще может быть нужен AWQ/GPTQ/INT4 W4A16, а не GGUF.

AWQ или GPTQ?

Для 4-bit GPU-serving я бы выбирал не по названию метода, а по конкретному checkpoint, runtime support и eval на своих задачах. AWQ часто очень хорош и быстро квантуется, GPTQ зрелый и широко поддержан. Плохой AWQ хуже хорошего GPTQ, и наоборот.

FP8 лучше INT4?

Для качества и production simplicity на H100/H200/B200 FP8 часто приятнее. Для максимальной экономии памяти INT4 сильнее. Если модель в FP8 не помещается, вопрос решён. Если помещается — FP8 может быть лучшим первым кандидатом.

Можно ли квантизовать KV cache отдельно?

Да, и иногда это важнее, чем ещё сильнее жать веса. Особенно при длинном контексте и высокой concurrency. В vLLM 0.20 Quantized KV Cache идёт как отдельная фича, в TensorRT-LLM есть FP8 KV cache и NVFP4 KV cache. Качество и скорость надо проверять: KV cache quantization может менять numerical behavior.

Почему модель влезла, но сервер всё равно падает с OOM?

Потому что веса — не вся память. Есть KV cache, CUDA graphs, temporary buffers, fragmentation, scheduler state, batch и runtime overhead. На эту тему полезен отдельный чеклист по vLLM memory/OOM debugging.

Что брать для RTX 3090?

Для одной 3090:

• 7B/14B: Q5_K_M/Q6_K или FP16 для маленьких;
• 32B: Q4_K_M/Q5_K_M;
• vLLM: AWQ/GPTQ 4-bit или INT4 W4A16;
• 70B: одна 3090 — тяжело, лучше multi-GPU или aggressive GGUF/offload.

Для 2-4x3090:

• 70B 4-bit уже реалистичнее;
• смотрите tensor parallel и PCIe/NVLink;
• не забывайте KV cache под context.

Что брать для H100?

Сначала FP8, если есть хороший checkpoint/runtime path. Потом INT4 AWQ/GPTQ, если нужна большая плотность. Для TensorRT-LLM смотрите ModelOpt и support matrix; для vLLM — актуальную таблицу quantization support.

Что я бы делал на практике

Мой порядок выбора такой:

1. Сначала baseline. Если есть возможность, запускаю BF16/FP16 или максимально качественный quant (Q8_0/Q6_K) на коротком eval-set.
2. Потом целевой runtime. Для vLLM не выбираю GGUF как основной формат. Для llama.cpp не думаю в терминах AWQ/GPTQ.
3. Потом память. Считаю веса + KV cache + overhead, а не только размер файла.
4. Потом качество. Сравниваю на своих задачах: русский, код, RAG, function calling, reasoning, длинные контексты.
5. Потом throughput. Смотрю TTFT, TPOT, tokens/sec, batch/concurrency и GPU memory bandwidth.

Если нужен универсальный старт:

• llama.cpp/Ollama на домашнем железе: Q5_K_M, если хватает; Q4_K_M, если нужен баланс; IQ3/Q3, если иначе не влезает.
• vLLM на RTX 3090/4090: AWQ/GPTQ 4-bit или INT4 W4A16, проверить Marlin path, отдельно считать KV cache.
• vLLM/TensorRT-LLM на H100/H200: FP8 как первый серьёзный кандидат, INT4 если нужно ужаться.
• CPU-only: GGUF, без иллюзий по скорости.
• production: не верить названию quant-формата без eval и бенчмарка.

Источники и что сверялось

На 14 мая 2026 я сверял актуальные таблицы и форматы по официальным документациям:

• vLLM Quantization — список поддерживаемых quantization methods и hardware compatibility (AWQ, GPTQ, Marlin, FP8 W8A8, INT4 W4A16, bitsandbytes, GGUF, NVIDIA ModelOpt, AMD Quark, TorchAO, Quantized KV Cache).
• TensorRT-LLM Quantization — FP8 per tensor / block scaling / rowwise, FP8 KV cache, FP4, NVFP4 KV cache, W4A16/W4A8 AWQ/GPTQ и ModelOpt path.
• Hugging Face Transformers: selecting a quantization method — bitsandbytes, AWQ, GPTQModel, torchao и сценарии выбора.
• Hugging Face GGUF docs — GGUF quantization types вроде Q6_K, Q5_K, Q4_K, IQ4_XS, IQ3_S, IQ2_XS, MXFP4.
• bitsandbytes docs — 8-bit inference, 4-bit QLoRA и memory-saving подходы.

Практические выводы

Квантизация — это не кнопка "сделать модель маленькой". Это выбор всей serving-траектории.

Для домашнего локального инференса чаще всего побеждает GGUF, потому что он практичный, гибкий и живёт в llama.cpp/Ollama/LM Studio. Для vLLM и production API чаще важнее AWQ/GPTQ/FP8/INT4 W4A16 и наличие fast kernels. Для H100/B200 мир всё сильнее двигается в FP8/FP4/NVFP4, но это требует нормального runtime path и проверки качества. Для RTX 3090/4090 4-bit остаётся рабочей лошадью.

И последнее: не выбирайте quant по названию файла. Выбирайте по связке модель + формат + runtime + железо + context + нагрузка + свой eval. Вот там и находится настоящая "лучшая квантизация".

---

Заинтересовало? Больше практических разборов про LLM, инференс и AI-инфраструктуру — в моём Telegram-канале @fuckup_files.