Квантование AI-моделей: GGUF, AWQ, GPTQ, EXL2 под ваш GPU

Оригинальные AI-модели от разработчиков обычно публикуются в весах FP16 или BF16. При этом модели имеют довольно большой объем, например, Qwen2.5-VL-72B-Instruct весит примерно 147 ГБ. Конвертация AI-моделей в сжатый формат (квантование), например, в GGUF позволяет запустить эту модель локально на обычном потребительском оборудовании. Правильно подобранный формат модели значительно снижает требования к VRAM и оперативной памяти, помогает оптимизировать процесс вычислений под конкретные аппаратные инструкции. Например, квантованная до 4 бит версия Qwen2.5-VL-72B-Instruct уменьшается в размере до 40-50 ГБ, позволяя запустить её на более доступном железе, в том числе в небольшой домашней сети под управлением llama.cpp.

Учитывая большое количество существующих форматов сжатия ИИ-моделей, иногда сложно разобраться, какой из них следует выбрать под свое оборудование.

В чем разница между стандартами сжатия/квантования AI-моделей?

Существует несколько популярных подходов и форматов для работы с «ужатыми» моделями. Они различаются архитектурой и тем, на каком железе они работают эффективнее всего:

GGUF (GPT-Generated Unified Format) — разработан на основе формата GGML специально для экосистемы llama.cpp. Его главная особенность — универсальность и возможность распределения нагрузки между CPU и GPU, в том числе в multiGPU-конфигурации и по сети. Это позволяет запускать даже нейросети, целиком не вмещающиеся в память одной видеокарты, хотя и медленнее, чем на одном дорогом «просторном» ускорителе.
AWQ (Activation-aware Weight Quantization) — продвинутый метод квантования, защищающий важные веса от сильного сжатия. Он дает минимум потерь и высокую скорость, но привязан к запуску исключительно на видеокартах (через vLLM, AutoAWQ).
GPTQ (Generalized Post-Training Quantization) — метод точечного 4-битного квантования для GPU. Работает очень быстро (через ExLlamaV2, vLLM), но, как и AWQ, не умеет эффективно задействовать оперативную память компьютера, что ограничивает возможности развертывания.
EXL2 (ExLlamaV2 format) — спеформат для видеокарт NVIDIA. Поддерживает нецелые форматы квантования (например, 3.5 или 4.25 бита на параметр), обеспечивая гибкую подгонку под конкретный объем VRAM.

В зависимости от выбранного формата и степени сжатия различается и скорость проведения AI-вычислений. Она значительно зависит от того, насколько эффективно используемый формат задействует аппаратно поддерживаемые инструкции GPU. Для достижения максимальной скорости инференса при локальном запуске AI-моделей нужно обращать внимание на следующие факторы:

1. Размер квантования (битность): модель в формате Q4_K_M (4 бита) будет работать значительно быстрее, чем Q8_0 (8 бит), так как процессору или видеокарте нужно обрабатывать значительно меньший объем данных. Платой за скорость является уменьшение IQ модели.

2. Локализация данных: если вся модель будет полностью перенесена в VRAM, скорость инференса будет наиболее высокой. Если часть слоев перенесена в более медленную RAM, быстродействие падает в разы. При работе в кластере дополнительное влияние оказывает пропускная способность сети, желательно использовать 10Гбитное соединение нод, как минимум хотя бы 2.5G.

3. Специфика алгоритмов: на GPU форматы EXL2 и AWQ обычно показывают лучшую скорость генерации в сравнении с GGUF за счет лучшей оптимизации под ядра CUDA.

Таблица с поддерживаемыми инструкциями для видеокарт Nvidia и AMD разных поколений:

О связи инструкций, аппаратно поддерживаемых видеокартой и скорости AI-инференса

Основные инструкции, аппаратно поддерживаемые видеокартами, можно узнать, например, на сайте techpowerup, а также командой `nvidia-smi -q` и по compute capability карты (например, sm_35 у Kepler). Эту информацию можно использовать, чтобы выбрать правильную AI-модель для скачивания или для ее конвертации в формат, более подходящий для своего компьютера.

Например, видеокарта Nvidia Tesla K40m (архитектура Kepler) на уровне железа поддерживает инструкции FP32 (до 5 TFLOPS) и FP64 (до 1.7 TFLOPS). Теоретически для неё лучше всего подходили бы модели в формате FP32. Но, учитывая, что оригинальные базовые AI-модели поставляются разработчиками в несжатом формате FP16 или BF16, конвертация в FP32 привела бы к увеличению размера файла в два раза (~280 ГБ для 70B-модели!) и не дала бы никакого практического выигрыша. Из-за этого при использовании подобных видеокарт следует ориентироваться на объём модели, которая должна целиком помещаться в VRAM с учётом размера контекста. Во время инференса ядра CUDA видеокарты будут распаковывать сжатые веса в аппаратно поддерживаемый формат FP32, что лишь незначительно снижает общее быстродействие по сравнению с влиянием пропускной способности подсистемы памяти. При этом при выборе исходной модели для квантования предпочтительнее брать версию в FP16, а не BF16: чип GK110B на архитектуре Kepler физически не поддерживает инструкции BF16. Работа с BF16-данными требует программной эмуляции этих вычислений, что даёт большее падение скорости, чем работа с FP16, — с ними чип совместим на уровне архитектуры, и при инференсе их конвертация в аппаратно поддерживаемый FP32-формат происходит без потери производительности.

Практическая деталь для тех, кто собирает узел на Kepler-картах (K40, K80, K20): актуальные драйверы Nvidia уже не поддерживают эту архитектуру. Последняя ветка, где Kepler ещё работает, — legacy-драйверы 470.xx в связке с CUDA toolkit 11.x. При сборке llama.cpp/CUDA-тулкита под такой узел это нужно закладывать заранее (пины пакетов, маски версий), иначе сборка либо не найдёт GPU, либо не соберётся вовсе. Опыт настройки и запуска llama.cpp на подобных картах описывается в цикле статей:

Потребительские видеокарты Nvidia GeForce GTX 1000-й серии на архитектуре Pascal (от GT 1030 до GTX 1080 Ti) аппаратно оптимизированы для вычислений стандартной точности FP32. Скорость операций двойной точности (FP64) у них урезана до соотношения 1:32, а половинная точность (FP16) очень мала (работает в режиме 1:64 к FP32). В то же время эти чипы поддерживают векторные инструкции INT8 (DP4A), которые выполняют базовые логические операции в 4 раза быстрее, чем FP32. Пиковая производительность этих адаптеров на базовых частотах в операциях FP32 составляет, в TFLOPS (базовые частоты):

GeForce GTX 1050 Ti (4 ГБ): ~1.98
GeForce GTX 1060 (6 ГБ): ~3.85
GeForce GTX 1070 (8 ГБ): ~5.78
GeForce GTX 1070 Ti (8 ГБ): ~7.82
GeForce GTX 1080 (8 ГБ): ~8.26
GeForce GTX 1080 Ti (11 ГБ): ~10.61

Исходя из характеристик серии GTX 1000, искать оригинальные модели в FP16 или FP32 для неё бессмысленно — они не поместятся в видеопамять. Использовать современные форматы вроде FP8 тоже не получится: старая архитектура Pascal аппаратно их не поддерживает. Оптимальным решением остаются квантованные модели GGUF низкой битности, например Q4_K_M (4 бита) или Q5_K_M (5 бит). Такое сжатие позволяет полностью уместить нейросеть в VRAM старых видеокарт; при работе ядра CUDA будут «на лету» деквантовать веса в аппаратно оптимизированный формат FP32 для финальных расчётов. Вычисления при этом идут в основном в FP32, так как архитектура Pascal не имеет аппаратной поддержки инструкций INT4/INT5, и сжатые форматы Q4/Q5 используются исключительно ради экономии видеопамяти.

Профессиональный ускоритель серверного класса NVIDIA Tesla V100 является первой видеокартой, получившей специализированные тензорные ядра для ускорения искусственного интеллекта. Чип этого адаптера аппаратно поддерживает инструкции FP32, FP64, а также INT8, INT4 и аппаратный FP16. Благодаря тензорным ядрам пиковая производительность в вычислениях половинной точности совершила колоссальный скачок и составляет, в TFLOPS:

Tesla V100 PCIe (16/32 GB): ~112.0 (Tensor FP16) / ~14.0 (векторный FP32)
Tesla V100 SXM2 (16/32 GB): ~125.0 (Tensor FP16) / ~15.7 (векторный FP32)

Несмотря на наличие тензорных ядер, использование AI-моделей на Tesla V100 в формате FP16 все равно ограничивается размером VRAM. К сожалению, архитектура Volta физически не поддерживает современный формат BF16 и на уровне железа не умеет работать с FP8. Поэтому для Tesla V100 оптимальным выбором также являются квантованные модели GGUF.

Видеокарты Nvidia GeForce GTX 1600-й серии на архитектуре Turing (GTX 1650 — 1660 разных модификаций) поддерживают инструкции FP32, FP64, FP16, а также INT32, INT8 и INT4. Важный нюанс: в отличие от «полноценного» Turing (RTX 20xx), чипы TU116/TU117 в GTX 16xx не имеют тензорных ядер — вместо них Nvidia встроила выделенные FP16-блоки, которые дают удвоенную по сравнению с FP32 скорость на CUDA-ядрах, но без ускорения матричных операций тензорами. Пиковая производительность FP16, в TFLOPS (базовые частоты):

GeForce GTX 1650 (4 GB): ~5.96;
GeForce GTX 1650 SUPER (4 GB): ~8.82;
GeForce GTX 1660 (6 GB): ~10.06;
GeForce GTX 1660 SUPER (6 GB): ~10.06;
GeForce GTX 1660 Ti (6 GB): ~10.88.

Таблица соотношения скорости проведения вычислений на видеокартах GTX 1600-й серии относительно инструкций FP32:

Инференс AI-моделей на FP16-инструкциях у GTX 1600 теоретически должен быть в два раза быстрее, чем на FP32. Но, учитывая скромный объём видеопамяти (4–6 ГБ), тяжёлые оригинальные модели в этот лимит не влезут, а современное сжатие FP8 само железо не позволяет. Поэтому лучшим выбором для серии GTX 1600 остаются квантованные модели GGUF низкой битности (например, Q4_K_M). Главный плюс здесь в том, что при локальном запуске движок инференса будет «на лету» деквантовать сжатые веса в аппаратно ускоряемый формат FP16, а не в FP32 — это одновременно экономит видеопамять и задействует максимальную пиковую скорость GPU.

Полноценные видеокарты на Nvidia-архитектуре Turing (от RTX 2060 до RTX 2080 Ti) имеют тензоры и аппаратно поддерживают инструкции FP32, FP64, FP16, а также INT32, INT8 и INT4. Пиковая производительность вычислений в формате FP16 с учетом использования тензорных ядер второго поколения у них на порядок выше, чем у видеокарт 1000-1600-й серий и составляет, в TFLOPS:

GeForce RTX 2060 (6 GB): ~44.0
GeForce RTX 2070 (8 GB): ~59.0
GeForce RTX 2080 (8 GB): ~76.0
GeForce RTX 2080 Ti (11 GB): ~107.0

Главным ограничением для этих видеокарт также является объем видеопамяти, плюс отсутствие аппаратной поддержки FP8 и BF16. Для достижения лучшей скорости инференса на RTX 2000-х разумно запускать квантованные модели GGUF низкой битности. Задействование аппаратных тензорных ядер и распаковка весов сразу в FP16 дают на них большой прирост производительности по сравнению с Pascal и 1600-й серией.

Поколение видеокарт Nvidia на архитектуре Ampere (от RTX 3050 до RTX 3090 Ti) имеет тензорные ядра третьего поколения и полноценную аппаратную поддержку формата BF16, а также TF32 и разреженных матриц (Sparsity), что удваивает темп вычислений. Эти карты аппаратно поддерживают инструкции FP32, FP64, FP16, BF16, INT8 и INT4. Пиковая производительность тензорных вычислений FP16/BF16 (с учетом разреженности) у них составляет, в TFLOPS:

GeForce RTX 3060 (12 GB): ~102.0
GeForce RTX 3070 (8 GB): ~163.0
GeForce RTX 3080 (10 GB): ~238.0
GeForce RTX 3090 (24 GB): ~285.0

Поскольку эти GPU имеют аппаратные блоки BF16, они могут без потери скорости работать с оригинальными весами многих современных моделей, изначально обученных в BF16. К сожалению, формат сжатия FP8 на этих видеокартах аппаратно не поддерживается. Для карт с небольшим объемом VRAM (8–10 ГБ) трехтысячной серии лучшим выбором остаются модели GGUF. Для RTX 3090 с 24 ГБ памяти, помимо GGUF можно использовать модели в формате AWQ и GPTQ (в бэкендах vLLM и ExLlamaV2), которые обрабатываются тензорными ядрами на максимальной скорости.

Видеокарты NVIDIA GeForce RTX 4000-й серии (архитектура Ada Lovelace) (RTX 4060 — RTX 4090) имеют тензорные ядра четвертого поколения. Их ключевая особенность — полноценная аппаратная поддержка формата FP8 через движок Transformer Engine. Кроме того, они поддерживают FP32, FP64, FP16, BF16, FP8, INT8 и INT4. Пиковая производительность тензорных вычислений FP16/BF16 (с учетом разреженности) у этого поколения видеокарт поднялась до следующих значений, TFLOPS:

GeForce RTX 4060 (8 GB): 150–240 (оценки различаются в зависимости от методики подсчёта)
GeForce RTX 4070 (12 GB): ~466.0
GeForce RTX 4080 (16 GB): ~780.0
GeForce RTX 4090 (24 GB): ~1321.0

Появление аппаратной поддержки FP8 позволяет использовать формат EXL2 (ExLlamaV2). Он считается одним из лучших решений для локального инференса, так как позволяет сжимать модели с нецелой битностью (например, 3.5 или 4.25 бита), подгоняя их под объем VRAM конкретной карты. Также для этих карт отлично подходят модели, квантованные в FP8.

Потребительская линейка видеокарт NVIDIA GeForce RTX 5000-й серии (архитектура Blackwell) с тензорными ядрами пятого поколения имеет аппаратную поддержку формата FP4 (4-битное число с плавающей запятой), а также FP32, FP64, FP16, BF16, FP8, FP4 и INT8-инструкций. Благодаря этому, а также использованию высокоскоростной GDDR7-памяти, пиковые показатели производительности RTX 5000-й серии составляют, в TFLOPS:

GeForce RTX 5070 (12 GB): ~310.0 (Тензорный FP16) / ~620.0 (Тензорный FP8)
GeForce RTX 5080 (16 GB): ~510.0 (Тензорный FP16) / ~1020.0 (Тензорный FP8)
GeForce RTX 5090 (32 GB): ~838.0 (Тензорный FP16) / ~1676.0 (Тензорный FP8) / ~3352.0 (Тензорный FP4)

Для видеокарт RTX 5000-й серии скорость инференса упирается уже не в вычислительную мощность чипа, а в пропускную способность памяти, поэтому сжатие для них также критически важно. Благодаря аппаратной поддержке FP4-инструкций, эти видеокарты могут выполнять инференс без промежуточного деквантования, что обеспечивает высочайший уровень производительности при меньших размерах одной и той же модели. Лучшим выбором для серии RTX 5000 являются модели в форматах FP8 и FP4.

Пара слов про AMD

Видеокарты AMD не поддерживаются AWQ/GPTQ/EXL2-бэкендами (vLLM, ExLlamaV2 заточены под CUDA), поэтому для них практически безальтернативный путь — GGUF через llama.cpp с бэкендом Vulkan или ROCm/HIP. Vulkan-сборка чуть медленнее «родного» ROCm, зато собирается проще и не требует установки полного ROCm-стека — это рабочий вариант для смешанного кластера с картами разных производителей.

Учитывая разницу в скорости работы при использовании моделей разных форматов вызывает интерес возможность их конвертации под конкретное железо. К сожалению, единого «конвертера всего во всё» пока в природе не существует. Инструмент llama-convert-llama2c-to-ggml из комплекта llama.cpp решает узкую задачу — переносит чекпоинты формата llama2.c (учебный проект Андрея Карпатого) в GGUF, и никак не связан с квантованием в AWQ, GPTQ или EXL2.

Возможные способы конвертации AI-моделей в разные форматы:

оригинальные веса HF safetensors преобразовываются в GGUF скриптом convert_hf_to_gguf.py из репозитория llama.cpp, затем квантование утилитой llama-quantize в нужный формат (Q4_K_M, Q5_K_M, Q8_0 и т.д.).
для AWQ: используется библиотека AutoAWQ (или llm-compressor), работающая поверх PyTorch/Transformers.
Для GPTQ: AutoGPTQ / GPTQModel.
Для EXL2: скрипт convert.py из репозитория ExLlamaV2, с указанием целевой средней битности.

Конвертация модели Qwen3.8-27B в разные форматы рассматривается в следующей статье.