Квантование моделей GGUF и vLLM 2026 практический гайд

Квантование моделей — это сжатие весов нейросети с 16-битной точности до 8, 5 или 4 бит, чтобы модель поместилась в доступную видеопамять и работала быстрее. GGUF решает эту задачу для локального запуска через llama.cpp: скачал файл, запустил на своём GPU или даже на CPU. vLLM решает другую задачу — отдаёт модель по API сразу десяткам пользователей с максимальной скоростью. Разберём, чем отличаются Q4, Q8 и FP16, как читать имена файлов вроде Q4_K_M и какой формат выбрать под свою видеокарту в 2026 году.

Квантование сжимает веса модели до 4-8 бит почти без потери качества: Q5_K_M даёт около 96% точности FP16 при 40% исходного размера файла. GGUF через llama.cpp — стандарт для локального запуска на своём железе, vLLM — для серверного инференса на десятки пользователей одновременно. Ниже — таблица выбора квантования под VRAM.

Что такое квантование моделей простыми словами?

Квантование — округление весов нейросети до меньшей точности: вместо 16 бит на число берут 8 или 4. Модель весит меньше, работает быстрее, качество падает незначительно.

Модель на 7 миллиардов параметров в исходном формате FP16 весит около 14 ГБ. После квантования в Q4_K_M она сжимается примерно до 4 ГБ и помещается в видеокарту с 8 ГБ VRAM вместе с кэшем контекста. Экономия почти в 3.5 раза при потере качества в районе 2%.

Каждое число в нейросети — это вес, и он хранится в памяти видеокарты. При генерации модель читает эти веса из VRAM миллионы раз в секунду, и узкое место почти всегда — не вычислительная мощность GPU, а пропускная способность памяти. Чем меньше весит число, тем быстрее его читать и тем больше чисел помещается в те же 8 или 24 гигабайта.

Отсюда и вся логика: сжимаем 16-битное число (FP16) до 8 бит (INT8) или 4 бит (INT4), теряем часть точности, выигрываем в размере и скорости генерации токенов. Крупные модели переносят сжатие легче маленьких — у них больше параметров, а значит больше избыточности, которая поглощает шум округления.

На практике это выглядит так: Llama 3 70B в FP16 не влезет ни в одну потребительскую видеокарту, а в Q4_K_M квантовании помещается в две RTX 3090 или одну A100 на 80 ГБ.

Чем отличаются FP16 Q8 и Q4 квантование по качеству и памяти?

FP16 — эталон качества без потерь. Q8 почти неотличим от него и весит вдвое меньше. Q4 теряет 2-4% точности, зато режет размер модели на 70%.

На модели 7B при переходе с FP16 (13.5 ГБ) на Q4_K_M (4.1 ГБ) размер падает почти в 3.5 раза, а качество по перплексии на тестовых датасетах держится на уровне 98% от исходного. Q2 квантование экономит памяти ещё больше, но качество проседает уже до 84%, и для рабочих задач такой уровень обычно не годится.

Золотая середина для большинства случаев — Q5_K_M: около 96-99% качества при 40% от размера FP16. Если видеопамяти впритык, берите Q4_K_M и закладывайте небольшой запас под контекст. Ниже Q4, на Q3 и Q2, оставляйте только для экспериментов и совсем слабых карт — там точность падает резко, а не плавно.

Отдельно стоит QAT — Quantization-Aware Training. В отличие от постквантования (PTQ), модель изначально обучается с учётом будущего сжатия и на 4 битах ведёт себя почти как в BF16. Из массовых открытых моделей такой подход применили к Gemma-3, и это заметно поднимает планку для 4-битных версий.

GGUF для локального запуска что это и как выбрать квант?

GGUF — формат файла для llama.cpp, который хранит квантованные веса, токенизатор и метаданные модели в одном файле. Разработал его Георгий Герганов, формат сменил GGML в августе 2023 года.

K-quants (Q4_K_M, Q5_K_S и подобные) используют двухуровневую схему: квантуются не только сами веса, но и служебные константы масштабирования, из-за чего накладные расходы ниже, чем у старых Legacy-квантов (Q4_0, Q4_1). Буквы S, M, L после K обозначают степень смешанной точности внутри модели: где-то слои держат выше, где-то — ниже, в зависимости от чувствительности к ошибке округления.

Формат GGUF часто сравнивают с MP3 в мире аудио: тот же принцип управляемого сжатия с потерями, только применён к весам нейросети, а не к звуковой волне. Дополнительно можно применить importance matrix (imatrix) — она выделяет больше точности тем весам, которые сильнее влияют на итоговый результат. Это почти бесплатный прирост качества на низких битах, если у вас есть время прогнать калибровочный датасет.

Базовый рабочий процесс:

# конвертация из HuggingFace формата в GGUF
python convert_hf_to_gguf.py ./model --outfile model-f16.gguf --outtype f16

# квантование в Q4_K_M
./llama-quantize model-f16.gguf model-q4km.gguf Q4_K_M

# опционально: imatrix для лучшего качества на низких битах
./llama-imatrix -m model-f16.gguf -f calibration.txt -o imatrix.dat
./llama-quantize --imatrix imatrix.dat model-f16.gguf model-iq4.gguf IQ4_XS

Квантовать нужно всегда из исходных F16/F32 весов. Если квантовать уже квантованную модель (например, Q8 в Q4), ошибки округления накапливаются и качество падает сильнее, чем при прямом сжатии из полной точности. Актуальную документацию и полный список поддерживаемых квантов удобнее смотреть прямо в репозитории llama.cpp на GitHub — она обновляется быстрее любых сторонних гайдов.

vLLM что это и зачем нужен для серверного инференса?

vLLM — Python-сервер для обслуживания LLM через OpenAI-совместимый API. PagedAttention управляет памятью GPU почти как виртуальная память в операционной системе, и это даёт в разы больше параллельных запросов на той же видеокарте.

На NVIDIA A10 vLLM обслуживает 32 параллельных запроса со временем до первого токена около 87 миллисекунд, тогда как обычный однопоточный сервер справляется с той же нагрузкой в 10-14 раз медленнее. Continuous batching устраняет простой GPU между запросами разной длины: пока одна генерация ждёт следующий токен, слот занимает другой запрос.

Развернуть модель можно буквально одной командой, а взаимодействовать с ней — через обычную библиотеку openai, просто указав base_url вашего сервера вместо адреса OpenAI. Удобно, что vLLM поднимает именно OpenAI-совместимый endpoint: туда можно подключить хоть Cursor, хоть Claude Code — меняете один параметр в настройках, и агент работает через вашу локальную модель вместо облачного API.

Из практики: параметр gpu_memory_utilization ограничивает, сколько VRAM vLLM заберёт себе, а tensor_parallel_sizeраспределяет одну модель на несколько GPU в одном сервере. Для длинных диалогов пригодится KV_CACHE_HOST_SIZE — контроль над тем, сколько памяти уходит под кэш контекста при множественных запросах.

vLLM или llama.cpp что выбрать для продакшена?

Для одного пользователя на своём железе быстрее и проще llama.cpp. Для сервера с десятком и больше одновременных запросов vLLM обходит его по throughput в разы за счёт батчинга запросов.

На RTX 4090 разница в скорости для одного запроса небольшая: около 62-71 токена в секунду что через vLLM, что через llama.cpp на модели уровня Llama 3.1 8B. Но при 32 и более одновременных запросах на серверных GPU vLLM обгоняет наивный подход в 2-3 раза, а против нативного llama.cpp разница растёт с ростом конкурентной нагрузки — потому что PagedAttention и continuous batching как раз про параллельные запросы, а не про скорость одного диалога.

Сильные стороны каждого подхода

GGUF и llama.cpp выигрывают в портативности: один бинарник, поддержка CUDA, Metal и Vulkan, гибридный запуск CPU плюс GPU. На одной видеокарте с одним пользователем это часто экономит около 35% VRAM против эквивалентной по качеству модели в vLLM — просто за счёт более тонкой сетки квантований GGUF.

vLLM выигрывает там, где нужно кормить моделью много клиентов одновременно: continuous batching, multi-LoRA serving (несколько дообученных адаптеров поверх одной базовой модели) и полноценный tensor parallelism на кластере из GPU.

Слабые стороны

У llama.cpp нет нормального батчинга под нагрузкой: под десятками одновременных запросов throughput проседает, потому что архитектура заточена под одного пользователя за раз. У vLLM обратная проблема — тяжелее поднять (Python, CUDA, зависимости), и поддержка GGUF в нём вторична: путь существует ради экономии памяти, а не ради пиковой скорости. Если модель уже лежит у вас в GGUF и вы гоняете её на своём железе, часто быстрее оставить её в родном llama.cpp, чем тащить в vLLM ради красивого API.

Таблица квантования качество скорость VRAM

Для наглядности — как меняются размер и качество модели на 7 миллиардов параметров при разных уровнях GGUF-квантования.

Цифры качества — усреднённые по community-бенчмаркам на перплексии, они немного гуляют от модели к модели, но порядок величин стабилен на любой архитектуре 2026 года: Qwen 3, Llama 4, DeepSeek V4, MiniMax M3.

Как выбрать квантование под свою видеокарту?

Ниже 8 ГБ VRAM берите Q3_K_M. От 8 до 12 ГБ — Q4_K_M, безопасный дефолт для большинства. От 12 до 16 ГБ — Q5_K_M или Q6_K. От 16 ГБ и выше можно себе позволить Q8_0 или даже FP16.

Хороший ориентир — Qwen3.6 27B, дальняя модель, которая в апреле 2026 обошла по SWE-bench Verified предыдущий флагман Qwen на MoE-архитектуре при кратно меньшем железе. В Q4_K_M она требует около 16.8 ГБ VRAM и укладывается в RTX 4080. В Q5_K_M — уже 19.5 ГБ, в Q6_K — 22.5 ГБ, а в Q8_0 — 28.6 ГБ, при этом полные BF16-веса весят 55.6 ГБ.

Правило на будущее простое: лучше запускать модель поменьше, но в хорошем кванте, чем модель побольше в убитом Q2. 7B в Q6 почти всегда выигрывает у 13B в Q2 — и по качеству, и по скорости, и по запасу памяти под длинный контекст.

Важно и то, что открытые веса сейчас есть не только у Llama. DeepSeek V4 Pro Max распространяется по MIT-лицензии и его можно квантовать и держать на своём сервере целиком, то же с Qwen3.7 Max и MiniMax M3 — у последнего SWE-bench Verified на уровне Gemini 3.1 Pro при цене и открытости совсем другого порядка. Claude или GPT так не сожмёшь: это API-only модели без доступа к весам.

Как запустить квантованную модель через vLLM пошагово?

На своём сервере с GPU процесс укладывается в несколько шагов. Сначала — подготовка: ставите Docker и Nvidia Container Toolkit, чтобы контейнер видел видеокарту, берёте LTS-версию Ubuntu 24.04 для стабильности на долгий срок.

Дальше запуск сервера одной командой с указанием модели с Hugging Face и лимита памяти:

docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3.6-27B-Instruct \
  --quantization awq \
  --gpu-memory-utilization 0.9 \
  --tensor-parallel-size 1

Если модель не помещается, первым делом уменьшайте gpu-memory-utilization, а не режьте контекст вслепую — ошибка Out of Memory чаще всего лечится именно так. Для серверных GPU на архитектуре Blackwell (RTX 50-серия, H100) выигрышнее квантование FP8: оно оптимальнее по скорости, хотя и требует чуть больше VRAM, чем AWQ. Для GPU классом младше AWQ остаётся разумным балансом качества и потребления памяти.

Мониторить нагрузку удобно связкой nvidia-smi для видеокарты и htop для процессора. Если карта не тянет полную модель, tensor_parallel_size распределит её на несколько GPU в одном сервере — это самый эффективный параметр для масштабирования именно вширь, а не вниз по квантованию.

Максим: «Мог просто засесть до пяти ночи и просто там править одну функцию, которая не работала. В моменте уже испотел, хотелось всё закрыть. Но понимал, что это можно и нужно решить, чтобы идти дальше.»

Настройка сервера редко заводится с первого раза, и это нормальная часть процесса, а не признак того, что вы что-то делаете не так.

Развёртывание собственных агентов на такой инфраструктуре — отдельная тема, и она напрямую касается DevOps-специалистов, которые чаще всего и настраивают подобные серверы для команды.

Итог какой формат выбрать в 2026 году

Если модель нужна лично вам на ноутбуке или домашнем ПК — берите GGUF и llama.cpp, начните с Q4_K_M и поднимайтесь до Q5-Q6, если видеопамять позволяет. Если модель обслуживает продукт с реальными пользователями и нагрузка выше 10-20 запросов одновременно — vLLM с AWQ или FP8 квантованием на серверном GPU. Смешивать подходы тоже нормально: разработка и тесты на GGUF локально, продакшен на vLLM в облаке.

Полный каталог инструментов для разработки с AI, включая варианты для локального и облачного инференса, собран в каталоге VibeCoderz. Если нужна помощь с выбором конфигурации под конкретную задачу, запишитесь на консультацию к Максиму.

Глоссарий

• Квантование — сжатие весов модели до меньшей битности (16, 8, 5 или 4 бита на число) ради экономии памяти и роста скорости.
• GGUF — формат файла для llama.cpp, хранит квантованные веса, токенизатор и метаданные в одном файле.
• K-quants — семейство квантов (Q4_K_M, Q5_K_S и другие) с двухуровневой схемой сжатия, точнее старых Legacy-квантов.
• imatrix — importance matrix, калибровочные данные, которые выделяют больше точности важным весам при квантовании.
• VRAM — видеопамять GPU, в которую должны поместиться веса модели и кэш контекста.
• KV cache — кэш ключей и значений внимания, растёт с длиной контекста и занимает VRAM отдельно от весов модели.
• PagedAttention — механизм vLLM, который управляет KV cache постранично, как виртуальная память в ОС.
• Continuous batching — постоянная подмешка новых запросов в текущий батч на GPU без ожидания завершения предыдущих.
• AWQ / GPTQ — методы квантования для serving-форматов (в отличие от GGUF, ориентированы на GPU-инференс через vLLM и подобные движки).
• Tensor parallelism — распределение одной модели на несколько GPU одновременно.

Часто задаваемые вопросы

Что лучше: Q4 или Q8 для локального запуска? Q4_K_M — безопасный дефолт, если VRAM в обрез: экономит около 70% размера при потере качества в пределах 2%. Q8_0 берите, если памяти хватает с запасом и важна максимальная точность, например для кода или структурированных JSON-ответов.

Сколько VRAM нужно для модели на 70B параметров? В Q4_K_M примерно 39 ГБ, то есть две карты по 24 ГБ или одна A100. В Q8_0 — уже около 70 ГБ, здесь без серверного GPU не обойтись.

Можно ли квантовать уже квантованную модель повторно? Технически да, но не стоит: ошибки округления накапливаются, и итоговое качество будет хуже, чем при прямом квантовании из исходных F16-весов.

Работает ли GGUF в vLLM? Поддержка есть, но она вторична и добавлена в первую очередь ради экономии памяти, а не скорости. Для GGUF-весов почти всегда быстрее нативный llama.cpp, а для vLLM разумнее брать модели в AWQ, GPTQ или FP8.

Какой квант лучше для генерации кода: Q4_K_M или Q5_K_M? Для кода и структурированных выводов лучше Q5_K_M или выше — там важна точность в деталях синтаксиса. Q4_K_M годится для казуального чата и коротких сводок, но на сложных задачах теряет чуть больше, чем хотелось бы.

Что быстрее для одного пользователя: vLLM или llama.cpp? На одном запросе разница минимальна, около 62-71 токена в секунду на одинаковом железе. Разница появляется только под конкурентной нагрузкой от нескольких клиентов сразу.

Нужно ли использовать imatrix при квантовании? Если есть время прогнать калибровочный датасет, да. Это почти бесплатный прирост качества на низких битах, особенно заметный на Q3-Q4.

Обновлено: август 2026.