Квантование модели простыми словами: что теряется в Q4

MAATRIX

Скачали модель в Q4, она отвечает нормально — но где-то в голове сидит вопрос: а что именно она теперь делает хуже? Термин «квантование» звучит как чёрная магия с процентами точности из чужих таблиц, которые непонятно как применить к своей задаче. На деле механика простая: разберём, что физически происходит с весами модели при сжатии, почему это почти не портит обычный диалог и портит именно то, что портит, — а не всё подряд.

Что физически происходит при квантовании

Модель — это десятки или сотни миллиардов чисел (весов), подобранных при обучении. Изначально они хранятся в высокой точности — обычно 16-битный формат с плавающей точкой (FP16 или его вариант BF16), у части моделей ещё до сжатия встречается и 32-битный FP32. Каждое число занимает ячейку фиксированного размера в памяти, и именно от размера этой ячейки зависит, сколько гигабайт весит вся модель.

Квантование — это округление каждого веса до значения, которое можно записать меньшим числом бит: Q8 — до 8-битных чисел, Q4 — до 4-битных. Не путайте с «уровнем сложности модели» — это не другая модель и не урезанная архитектура, а та же самая, где числа записаны грубее. Условно: вместо «3,14159265» храните «3,14» — форма осталась, часть знаков после запятой пропала.

Технически это не наивное округление до ближайшего значения. Веса группируют в блоки (обычно по 32 или 256 значений) и на каждый блок считают свой масштабный коэффициент — так диапазон значений в блоке используется полнее, а не «размазывается» на всю шкалу разом. Это даёт заметно лучший результат, чем обрубание каждого числа до N бит независимо от соседей, но сути не меняет: чем меньше бит на вес, тем грубее приближение к оригиналу.

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

Почему размер и память сокращаются почти пропорционально биту

Здесь арифметика прямая, и её полезно держать в голове, а не верить на слово чужим таблицам. Размер весов равен количеству параметров, умноженному на биты на вес, делённому на 8 (перевод бит в байты). Модель на 7 миллиардов параметров в 16-битном формате — это условно 7 × 16 / 8 = 14 гигабайт с небольшим довеском на служебные тензоры. В 4-битном квантовании та же модель — это уже около 7 × 4 / 8 = 3,5 гигабайта плюс тот же довесок. Округление не линейное на уровне «плюс-минус процент», а почти прямое — вдвое меньше бит означает вдвое меньше памяти на веса, с поправкой в несколько процентов на те части модели, которые из соображений устойчивости часто держат точнее заявленной цифры (эмбеддинги, финальный слой).

Отсюда прямое следствие: требования к оперативной или видеопамяти падают в те же разы, что и размер файла. Модель, которая в FP16 не влезала ни в одну доступную видеокарту, в Q4 внезапно помещается в 6–8 гигабайт видеопамяти или в оперативную память обычного сервера. Это и есть главная практическая причина, зачем вообще квантуют модели для локального запуска — не ради абстрактной «оптимизации», а чтобы модель в принципе поместилась в железо, которое у вас есть.

Второе следствие касается скорости и оно менее очевидно. На CPU (и часто на GPU тоже) генерация токенов почти всегда упирается не в то, насколько быстро процессор считает умножения, а в то, насколько быстро он успевает прочитать все веса модели из памяти — для каждого нового токена веса читаются заново. Чем меньше физический вес модели, тем меньше данных гонять через шину памяти на токен, и тем быстрее в среднем генерация при прочих равных. Правило не абсолютное — на очень низких битностях декодирование усложняется и часть выигрыша съедается на распаковку, — но общее направление именно такое: более лёгкий квант почти всегда быстрее тяжёлого варианта того же семейства на одном железе.

Почему в большинстве задач Q4 почти не заметен

Округление добавляет к каждому весу небольшую ошибку — шум. У современной нейросети огромное число параметров работает совместно, распределённо: одна и та же способность (понимание грамматики, общая логика текста, стиль) размазана по множеству весов сразу, а не сосредоточена в одном конкретном числе. Небольшой шум в отдельных весах в среднем взаимно гасится, а не накапливается в заметный сбой — примерно как лёгкое зерно на фотографии не мешает узнать, что на ней изображено.

Именно поэтому обычный диалог, пересказ текста своими словами, ответ на вопрос по смыслу, черновой перевод, суммаризация длинного документа — задачи, где важен общий смысл, а не конкретное число или символ, — переносят Q4 хорошо. Формулировки могут местами звучать чуть проще, чем в полноразмерной модели, но фактическая суть ответа обычно не меняется. Направление подтверждается опытом сообщества: многие в слепом сравнении не отличают ответ Q4 от FP16 на бытовых задачах, хотя точный процент «неотличимости» зависит от модели, задачи и того, кто оценивает, и мы не станем выдавать конкретную цифру за универсальный факт.

Вторая причина мягкой деградации: чем крупнее исходная модель, тем лучше она обычно переносит агрессивное квантование — в модели на 70 миллиардов параметров та же способность продублирована избыточнее, чем в модели на 3 миллиарда, есть что «жертвовать» без фатальных потерь. Это стоит учитывать при выборе между «маленькая модель без сжатия» и «крупная модель в Q4»: второй вариант нередко даёт лучший результат при сопоставимом весе на диске.

Где потеря заметна сильнее: числа, редкие факты, код

Есть класс задач, где та же самая ошибка округления бьёт куда болезненнее, и природа этого — зеркальное отражение предыдущего раздела. Там, где ответ размазан по множеству весов, шум гасится. Там, где правильный ответ зависит от одного конкретного, точно воспроизводимого значения, шум может это значение сдвинуть — и тогда результат либо неверный, либо неверный так, что это не сразу заметно.

Точные числовые расчёты — первый такой случай. Модель не «вычисляет» арифметику как калькулятор — она предсказывает наиболее вероятное продолжение на основе паттернов, увиденных при обучении. В FP16 у неё больше внутреннего запаса точности, чтобы эти паттерны воспроизвести аккуратно; в Q4 запас у́же, и на многошаговых или нетипичных числовых цепочках вероятность сбоя выше. Модель в Q4 не перестаёт считать вовсе — простая арифметика обычно работает, — но полагаться на точность многошаговых вычислений без внешней проверки (калькулятора, реально выполняемого кода) рискованно вне зависимости от квантования, а в Q4 риск ощутимо выше.

Редкие факты и специфичные детали — второй случай. Информация, встретившаяся в обучающих данных один-два раза (узкоспециализированный термин, малоизвестное имя, редкая дата), закодирована в весах куда менее избыточно, чем общеязыковые паттерны. Округление может «стереть» именно этот слабо продублированный сигнал, тогда как частотные факты выживают почти всегда. Чем экзотичнее вопрос, тем осторожнее стоит относиться к ответу сильно сжатой модели — и в целом к любому ответу, если факт можно проверить.

Код и структурированный вывод (строгий JSON, вызовы функций, конфиги) — третий и самый неприятный случай на практике. Проблема не в том, что модель «не понимает» синтаксис, а в том, что ошибка не выглядит как явный сбой. Лишняя скобка, неверно закрытая кавычка, чуть изменённое имя параметра — выглядит как правдоподобный текст, а не как что-то заведомо неправильное, и парсер на другом конце падает молча или тихо получает не то значение. В диалоге такая же по масштабу ошибка незаметна на глаз; в пайплайне, где вывод модели идёт в код без ревью человеком, она может стоить сломанного продакшена.

GGUF-схемы квантования на практике: что значат буквы после Q

Для локального запуска (Ollama, LM Studio, llama.cpp) почти везде используется формат GGUF, и в имени файла или тега вида Q4_K_M каждая часть имеет смысл — но вникать в математику для практики не обязательно, достаточно понимать логику.

Первое поколение схем — «legacy»: Q4_0, Q5_0, Q8_0 и им подобные. Здесь все веса модели сжимаются одинаково грубо, без разбора, какие из них важнее. Схема простая и предсказуемая, но не самая экономная по соотношению «размер к качеству» — сегодня встречается реже, разве что на процессорах, для которых старые схемы считаются заметно быстрее новых.

Второе поколение — K-кванты: Q3_K, Q4_K, Q5_K, Q6_K, обычно с буквой _S, _M или _L. Смысл буквы K — модель разбирают на тензоры, и часть из них, обычно сильнее влияющую на качество, квантуют бережнее заявленной цифры, а остальные грубее. _S экономит агрессивнее, _M оставляет больше слоёв точными, _L бережёт ещё сильнее ценой размера. Из-за этого Q4_K_M, при формально той же цифре «4», на практике заметно ближе к оригиналу, чем старый Q4_0, — это разные схемы упаковки, а не два варианта одной и той же грубости.

Третье поколение — IQ-кванты (IQ2_XXS, IQ3_S, IQ4_XS и другие): вместо простого масштаба на блок используется более изощрённая кодовая книга, а перед сжатием часто считают матрицу важности (imatrix) — прогоняют через модель калибровочный текст и смотрят, какие веса реально влияют на ответ, а какие можно огрублять безболезненно. Это позволяет уйти в очень низкую битность с меньшей просадкой качества, чем дала бы наивная схема того же размера, но ценой более тяжёлой распаковки — на процессорах без нужных инструкций выигрыш в размере иногда съедается более медленной генерацией.

Практический вывод: не сравнивайте кванты по одной цифре после Q. Q4_K_M и Q4_0 — не одно и то же, а Q4_K_M от разных авторов сборки тоже может отличаться качеством калибровки — смотрите на полное имя схемы. Более детальный разбор конкретных тегов и того, какой уровень выбирать для чата, кода и агентов, — в статье про Q4, Q5 и Q8 в GGUF.

Как выбрать степень квантования под своё железо

Практическая последовательность выбора обычно такая: сначала считаете, сколько памяти реально доступно, и от этого отталкиваетесь, а не наоборот.

1. Посчитайте бюджет памяти. Для GPU — доступная видеопамять минус занятое системой и другими процессами. Для CPU-инференса — оперативная память минус запас для ОС и остальных сервисов (не выделяйте под модель 100% RAM). Ориентировочный размер весов — параметры модели (в млрд) × биты на вес / 8, плюс запас на контекстный кэш (KV-кэш), который растёт с длиной диалога и у длинных контекстов может сравняться по объёму с весами.
2. Определите тип задачи. Разговорный ассистент, суммаризация, черновой перевод — смело начинайте с Q4 (обычно K-квант вроде Q4_K_M, а не старый Q4_0). Код, function calling, строгий JSON, агентные цепочки — закладывайте более тяжёлый уровень (Q5–Q6) там, где памяти хватает, а Q4 в таких задачах воспринимайте как вариант, который обязательно нужно проверить, а не безопасный дефолт.
3. Проверьте на своих промптах, а не на чужих бенчмарках. Чужие таблицы показывают направление, но не гарантируют результат для вашей модели — архитектуры и данные обучения разные. Возьмите 10–20 реальных примеров из своего сценария и прогоните через кандидата на квант перед продакшеном.
4. Заложите путь наверх. Если сервер позволяет, держите под рукой более тяжёлый квант той же модели для случаев, когда ответ критичен, — и переключайтесь на него точечно, а не постоянно.

Пример прикидки: модель на 8 миллиардов параметров в Q4_K_M (примерно 4,5–5 бит на вес с учётом более точных отдельных тензоров) весит по формуле около 8 × 4,8 / 8 ≈ 4,8 гигабайта весов, плюс запас на контекст и систему — с типичным запасом комфортно укладывается в сервер с 8 гигабайтами оперативной памяти для одной модели без соседей, и с большим запасом — в 16 гигабайт, если нужно держать вторую модель или более длинный контекст. Точные цифры под конкретную модель и объём RAM удобнее свести в одну таблицу — она уже есть отдельно: сколько RAM нужно под конкретные модели Ollama. Вопрос «а нужен ли вообще GPU для локальной модели или хватит CPU» — тоже отдельная тема, и она напрямую влияет на то, каким запасом по квантованию вы располагаете: см. CPU или GPU для локальной LLM.

Держать в уме простое правило: если сомневаетесь между двумя соседними уровнями (например, Q4 и Q5) и памяти хватает на оба — берите более тяжёлый, разница в занятой памяти обычно не критична, а запас точности не помешает. Если памяти впритык и выбор стоит между «влезет Q4» и «не влезет вообще» — Q4 почти всегда лучше, чем не запустить модель совсем, при условии, что задача из тех, где Q4 достаточно.

Проверить это на своих примерах несложно: соберите 10–15 реальных запросов из своего сценария, для задач с проверяемым ответом (код, JSON, вычисления) заранее зафиксируйте правильный результат, прогоните набор через два кандидата на квант (скажем, Q4_K_M и Q6_K) и сравните конкретные расхождения, а не общее впечатление. Если модель встроена в пайплайн с автоматической обработкой вывода — проверяйте именно через этот пайплайн целиком, а не через отдельный чат: там, где ломается парсер, проблема видна, а в чате та же ошибка может остаться незамеченной. Более подробная методика — с метриками и автоматизацией сравнения — в статье про проверку качества ответов своей модели.

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