GGUF, Q4_K_M, FP8, MXFP4: что значат и сколько памяти экономят

Квантизация хранит веса модели не в 16 битах, а в 8, 6, 4 или 3, и файл уменьшается в 1,9–5,3 раза. Qwen3.8 27B весит 50,9 ГБ в исходном BF16 и 15,3 ГБ в Q4_K_M, поэтому с контекстом 8K ей нужна карта на 24 ГБ вместо 80 ГБ. Ниже — что значат GGUF, Q8_0, Q4_K_M, FP8 и MXFP4, таблица памяти для четырёх моделей, замеры качества и команды, как скачать нужный файл.

Что такое GGUF: формат файла или квантизация?

GGUF — это формат файла, а не способ сжатия. В одном файле лежат веса модели и метаданные: параметры архитектуры, токенизатор, шаблон чата. По описанию авторов, формат сделан для быстрой загрузки в llama.cpp и программах на его движке — Ollama и LM Studio.

Веса внутри GGUF могут храниться в разной точности — от F32 и BF16 до двух бит и ниже. Какая именно, говорит суффикс в имени файла: Q8_0, Q4_K_M. Для сравнения: safetensors хранит только тензоры, а GGUF — ещё и стандартный набор метаданных.

Поэтому «скачать GGUF» — неполный запрос: в репозитории десятки файлов одной модели, и выбирать нужно квантизацию.

Что значат Q8_0, Q6_K, Q4_K_M и Q2_K в названии файла?

Цифра после Q — примерно число бит на вес, буква K — семейство k-квантов, а M — вариант смеси.

• Q и цифра. Столько бит хранится на один вес; в исходной модели их 16.
• K. Веса делятся на блоки, у каждого свой масштаб; блоки собраны в супер-блоки (так их описывает автор в запросе №1684 к llama.cpp).
• 0 в Q8_0. Схема проще: блок из 32 весов и один множитель. Множитель добавляет полбита, поэтому Q8_0 — это 8,5 бита на вес, а не 8.
• S, M, L. Варианты смеси: в одной модели используются разные типы. В Q4_K_M большинство весов — в 4-битном Q4_K, половина тензоров attention.wv и feed_forward.w2 — в 6-битном Q6_K, выходной слой всегда в 6 битах.

Поэтому Q4_K_M — это 4,84 бита на параметр, а не 4. Он же выбор по умолчанию: Ollama берёт Q4_K_M, если файл есть в репозитории Hugging Face, и llama.cpp с флагом -hf поступает так же.

Все форматы статьи — в таблице. Биты измерены по опубликованным файлам; три последние строки — не k-кванты.

Чем FP8, MXFP4, AWQ и GPTQ отличаются от GGUF?

Это другие форматы для других программ. GGUF читают Ollama, LM Studio и llama.cpp. FP8, AWQ и GPTQ рассчитаны на GPU-серверы вроде vLLM, а MXFP4 — родной формат GPT-OSS. Как выбрать программу, разобрано в гайде Ollama, LM Studio, llama.cpp или vLLM.

• FP8 — 8-битные числа с плавающей запятой. По документации vLLM, память под модель сокращается вдвое; у Qwen3.8 27B файл меньше в 1,8 раза (28,7 ГБ против 50,9 ГБ). Считать в FP8 умеют карты с compute capability от 8.9 — Ada, Hopper и Blackwell, например RTX 4090 и H100. На RTX 3090 и A100 вы тоже сэкономите память, но вычисления пойдут в 16 битах.
• MXFP4 — 4-битные числа с общим масштабом на блок. OpenAI выпустила GPT-OSS сразу в нём: по карточке модели, веса экспертов занимают больше 90% параметров и хранятся в 4,25 бита. GPT-OSS 120B весит 59,0 ГБ вместо 217,6 ГБ в BF16 (оценка по числу параметров) и помещается на одну карту 80 ГБ.
• AWQ и GPTQ — 4-битные целые числа (INT4; GPTQ бывает и 8-битным). vLLM загружает готовые чекпойнты с Hugging Face; по его документации, выигрыш — меньше памяти и задержка. GGUF vLLM читает лишь экспериментально, поэтому для него берите FP8 или AWQ.
• UD-…_XL от Unsloth. Динамическая квантизация: тип подбирается для каждого слоя отдельно. Документация не расшифровывает «UD» и «XL». В наших таблицах у Qwen3.8 27B и Gemma 4 31B на месте Q2_K стоит UD-Q2_K_XL: простого файла нет.

Сколько памяти экономит квантизация на реальных моделях?

Q4_K_M уменьшает веса в 3,3 раза, а всю память — чуть меньше: кэш контекста и служебная память не сжимаются. Qwen3.8 27B с контекстом 8K занимает 52,8 ГБ в BF16 и 17,2 ГБ в Q4_K_M — в 3,1 раза меньше. Выбор среди моделей Qwen — в гайде «Какую модель Qwen выбрать».

Таблица — четыре модели: Qwen3.8 27B, Llama 3.3 70B, Gemma 4 31B и Qwen3 8B. В ячейке, в ГБ: память с контекстом 8K, веса и самая маленькая карта; прочерк — такого файла нет.

Карты бывают только ступенями — 12, 16, 24, 32, 48, 80 ГБ, — поэтому важно не сколько вы сэкономили, а перешагнули ли ступень. У Qwen3.8 27B Q4_K_M, Q5_K_M и Q6_K идут на карту 24 ГБ, Q8_0 и FP8 — на 32 ГБ, BF16 — на 80 ГБ. Llama 3.3 70B в Q4_K_M идёт на 48 ГБ, в Q8_0 — на 80 ГБ. Про Gemma 4 — в гайде об её видеопамяти.

Почему файл не равен «параметры × биты ÷ 8»?

Формула даёт порядок величины, но ошибается на несколько процентов. В таблице — расчёт по битам из таблицы выше и реальный размер файла.

Расхождение — от −5,6 % до +9,7 %. У Llama 3.3 70B в Q4_K_M оно всего 0,4 %, а файл Qwen3 8B в FP8 больше формулы на 9,7 %. Скорее всего, дело в тензорах, которые остаются точнее: выходной слой k-квантов хранится в 6 битах, а у небольшой модели его доля больше. Файлы Qwen3.8 27B и Gemma 4 31B, наоборот, меньше формулы; причину по таблице не угадать. Поэтому в калькуляторе стоят размеры настоящих файлов, а не расчёт.

Что теряется в качестве при квантизации?

По двум публикациям авторов, Q8_0 и Q6_K почти не отличаются от исходной модели, Q4_K_M теряет немного, Q3_K_M — заметнее, Q2_K — явно. Это чужие замеры: мы качество не измеряли.

Источники: документация Unsloth Dynamic 2.0 (Gemma 3 27B) и запрос №1684 к llama.cpp (LLaMA 7B; чем ниже перплексия, тем лучше). Перплексия растёт медленно до Q4_K_M (5,96 против 5,91) и резко у Q2_K (6,78).

У замеров есть границы. Обе модели старые, тест у каждой один, и он не покажет, как формат скажется на коде, математике или русском языке. Различия в десятые доли пункта — шум: Q6_K набрал больше Q8_0. Проверьте файл на своих запросах: на арендованной карте это час работы.

Что даёт квантизация кэша контекста?

Кэш контекста тоже можно сжать вдвое, не трогая веса. Кэш — это память, где модель хранит ключи и значения уже прочитанных токенов; он растёт вместе с диалогом. У Llama 3.3 70B в Q4_K_M кэш на 32K токенов занимает 10,0 ГБ в FP16 и 5,3 ГБ в q8.

С контекстом 32K Llama 3.3 70B занимает 50,6 ГБ и идёт на карту 80 ГБ. С кэшем q8 — 45,9 ГБ: хватает 48 ГБ, но впритык. При 128K выигрыш ещё нагляднее: карта 96 ГБ превращается в 80 ГБ.

Если кэш мал, выгода скромнее. У Qwen3.8 27B кэш q8 экономит при 8K всего 0,23 ГБ, при 128K — 3,8 ГБ, и этого хватает, чтобы перейти с карты 32 ГБ на 24 ГБ.

# llama.cpp
llama-server -hf unsloth/Qwen3-8B-GGUF:Q4_K_M -ctk q8_0 -ctv q8_0 -fa on

# vLLM
vllm serve <модель> --kv-cache-dtype fp8

# Ollama: переменные окружения сервера
OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_FLASH_ATTENTION=1

Цена — точность. Документация Ollama называет потерю у q8_0 «очень небольшой», у q4_0 — «малой или средней»; тип кэша там один на все модели. vLLM предупреждает, что слои со скользящим окном, как у Gemma 4, к сжатию чувствительнее.

Какой формат выбрать?

Начните с Q4_K_M. Если памяти хватает, берите Q8_0 или FP8; ниже Q4 опускайтесь, только когда иначе файл не помещается.

• Памяти хватает. Q8_0 в замерах выше почти не отличается от исходной модели; аналог для vLLM — FP8, его в замерах нет. Qwen3.8 27B с 8K: Q8_0 — 28,9 ГБ, FP8 — 30,6 ГБ, карта 32 ГБ.
• Обычный случай. Q4_K_M. Qwen3 8B занимает 6,8 ГБ, Gemma 4 31B — 19,7 ГБ, Qwen3.8 27B — 17,2 ГБ, Llama 3.3 70B — 43,1 ГБ: это карты 8 ГБ, 24 ГБ, 24 ГБ и 48 ГБ.
• Карты не хватает. Ниже Q4_K_M имеет смысл спускаться, только если файл перешагнёт ступень. Llama 3.3 70B в Q3_K_M (35,4 ГБ) всё равно идёт на 48 ГБ, как и Q4_K_M: выигрыша нет. Q2_K (28,1 ГБ) помещается на 32 ГБ, но потери у него самые большие.
• vLLM. Берите FP8 на картах Ada, Hopper и Blackwell и AWQ, когда нужны 4 бита. Для GPT-OSS выбирать не из чего: модель вышла в MXFP4.

Посчитайте свою конфигурацию

Выберите модель, формат и длину контекста — калькулятор покажет память и карты каталога, на которых модель запустится дешевле всего. Правило расчёта — в гайде про VRAM для LLM, таблица по 35 моделям — в статье «Сколько видеопамяти нужно открытым LLM».

Как скачать нужный квант на арендованной видеокарте

Шаблон Open WebUI + Ollama берёт GGUF прямо с Hugging Face: имя пишется как hf.co/организация/репозиторий:квант. Примеры — для Qwen3 8B: в Q8_0 ей нужно 10,3 ГБ (карта 12 ГБ), в Q4_K_M — 6,8 ГБ (карта 8 ГБ).

1. 1

   Выберите карту по таблице памяти

   Найдите в таблице выше свою модель и формат, откройте каталог и нажмите «Арендовать». Выберите шаблон Open WebUI + Ollama: он работает на картах от 8 ГБ.

2. 2

   Впишите модель и квант в поле «Модель»

   Диск возьмите от 40 ГБ и с запасом сверх размера файла. Если нужного тега нет, подставьте имя файла целиком: Ollama принимает и его.

   hf.co/unsloth/Qwen3-8B-GGUF:Q8_0

3. 3

   Подождите, пока файл скачается

   Шаблон скачивает модель при первом старте, обычно за 3–10 минут; крупный квант дольше. О готовности чата придёт сообщение.

4. 4

   Сравните другой квант той же модели

   Подключитесь по SSH, скачайте второй файл и запустите его. Лишнюю модель удалите командой ollama rm.

   ollama pull hf.co/unsloth/Qwen3-8B-GGUF:Q4_K_M
   ollama run hf.co/unsloth/Qwen3-8B-GGUF:Q4_K_M
   ollama rm hf.co/unsloth/Qwen3-8B-GGUF:Q8_0

5. 5

   Остановите сервер, когда закончили

   Остановка прекращает оплату GPU, а диск с файлами тарифицируется, пока вы не удалили сервер.

Для vLLM возьмите FP8-чекпойнт и включите FP8-кэш. Запуск — как в шаблоне vLLM, с другой моделью и флагом:

pkill -f api_server
nohup python3 -m vllm.entrypoints.openai.api_server --host 0.0.0.0 --port 8000 \
  --model Qwen/Qwen3-8B-FP8 --kv-cache-dtype fp8 --max-model-len 8192 \
  --api-key <токен аренды> > /var/log/vllm.log 2>&1 &

Что может пойти не так

• Квант не поместился в видеопамять. Ollama и llama.cpp положат часть слоёв в оперативную память, и ответы станут заметно медленнее. Долю видно в колонке Processor команды ollama ps.
• Пересжатие чужого файла. README llama.cpp предупреждает: повторная квантизация (--allow-requantize) «может сильно ухудшить качество» по сравнению с квантизацией из 16 бит. Берите готовый файл.
• Одно имя, разные файлы. Q4_K_M у разных авторов отличается рецептом и размером. Сверяйте размер файла в репозитории, а не только название.
• LM Studio пишет «No LM Runtime found for model format gguf». Судя по тексту, дело в рантайме, а не в файле. GGUF там запускает движок llama.cpp: откройте менеджер рантаймов (Ctrl+Shift+R) и проверьте, что подходящий установлен. Официального разбора ошибки мы не нашли.

Как мы считали

Веса — реальные размеры файлов: GGUF и FP8 из репозиториев Hugging Face (в основном unsloth и Qwen), BF16 — из оригинальных. У Qwen3.8 27B в репозитории unsloth нет простых Q4_K_M, Q5_K_M и Q6_K (список файлов проверен 2026-10-20). В таблицах стоят их динамические варианты: UD-Q4_K_M, UD-Q5_K_M и UD-Q6_K. Кэш контекста посчитан по config.json модели; кэш q8 — как 8,5 бита на значение (q8_0 в llama.cpp), а у FP8-кэша vLLM 8 бит, то есть на 6% меньше. 1 ГБ здесь — 1024³ байт, как у видеокарт; Hugging Face показывает десятичные гигабайты, и его цифры примерно на 7% больше. Данные на 2026-10-19; методика — в калькуляторе.

Описания форматов сверены с первоисточниками 2026-10-20: README и запрос №1684 llama.cpp, спецификация GGUF, документация Hugging Face, Ollama, vLLM и Unsloth, карточка модели GPT-OSS. Для сверки: в таблице README llama.cpp Q4_K_M у Llama 3.1 8B — 4,89 бита на вес, по нашим файлам у Qwen3 8B выходит 4,91, у Llama 3.3 70B — 4,82.