Короткий ответ: какой квант брать под задачу
Для большинства локальных задач базовый выбор — 4-битный квант: Q4_K_M или IQ4_XS. Он уменьшает память под веса примерно вчетверо относительно FP16 и сохраняет поведение модели достаточно близко к оригиналу, чтобы работать и в чате, и в кодинге, и в агентных цепочках.
3-бит (Q3_K_M, IQ3_XXS, IQ3_S) — компромисс, когда 4-бит крупной модели не влезает в VRAM. Для чата, пересказа и черновиков его обычно хватает. Для кодинга и агентов запас тоньше: ошибки формата и синтаксиса становятся чаще, поэтому такой квант стоит проверять на своих промптах, а не принимать на веру.
2-бит (Q2_K, IQ2_XS, IQ2_M) — крайняя мера. Его берут, когда нужно запустить модель, которая иначе не помещается, и готовы платить деградацией. Простой чат иногда терпит, tool-calling и многошаговые агенты — плохо.
Расклад выведен из механики квантования и бюджета памяти. Обсуждение в r/LocalLLaMA фиксирует те же развилки (2, 3, 4 бита и порог KLD), но готовых ответов сообщества в нём нет, поэтому ниже — ориентиры и способ проверить их на своём железе.
| Задача | Рабочий старт | Когда можно ниже | Что проверять |
|---|---|---|---|
| Чат, пересказ, черновики | 4-бит, при нехватке памяти 3-бит | 2-бит, если модель иначе не влезает | Связность, повторы, удержание темы |
| Кодинг | 4-бит | 3-бит на крупной модели, после проверки | Синтаксис, следование API, длина контекста |
| Агенты, tool-calling | 4-бит | 3-бит только с тестом формата | Валидный JSON, выбор инструмента, устойчивость цепочки |
Что означают 2-, 3- и 4-бит и почему цифра в имени файла обманчива
Модель хранит веса в FP16 или BF16: 16 бит на параметр. Квантование снижает эту точность, упаковывает веса плотнее и добавляет служебные коэффициенты масштаба. Цифра в имени файла показывает среднее число бит на вес.
Память под веса считается просто: число параметров × биты / 8. Для модели на 27 млрд параметров это около 13,5 ГБ в 4-бит, 10,1 ГБ в 3-бит и 6,8 ГБ в 2-бит. Реальный файл GGUF чуть больше арифметики: коэффициенты и тензоры, которые остаются в повышенной точности, добавляют несколько процентов.
Отсюда практическое правило экономии: 3-бит даёт около 25% памяти относительно 4-бит, 2-бит — около 50%. Разница между 4-бит и 3-бит на модели 27B составляет примерно 3,4 ГБ, и этих гигабайт часто не хватает как раз на KV-кэш под длинный контекст.
Почему Q4_K_M и Q4_0 — не одно и то же
K-кванты делят тензор на суперблоки, хранят отдельные масштабы для групп весов и часть тензоров оставляют в более высокой точности. Q4_0 кодирует блоки по 32 веса с одним масштабом и без такого перераспределения битов. При одинаковой заявленной битности K-квант аккуратнее обходится с качеством и весит немного больше.
IQ-варианты (IQ4_XS, IQ3_XXS, IQ2_M) добавляют матрицу важности, посчитанную на калибровочном тексте, и векторные кодовые книги. На низких битах это выигрывает у наивных схем: IQ3_XXS при близком размере обычно устойчивее простого Q3_0, а IQ4_XS конкурирует с Q4_K_M при меньшем весе файла.
Смотрите на тег в имени файла: Q4_K_M, Q4_K_S, IQ4_XS, Q3_K_M, IQ3_XXS, Q2_K. Битность без тега ничего не говорит о качестве сборки.
2-бит на практике: когда спасает, а когда ломает модель
2-бит оправдан одной причиной: модель иначе не помещается. Экономия ради экономии здесь не работает, потому что платите вы качеством на задачах, где модель ошибается редко, но дорого.
Сравнение всегда одно и то же: крупная модель в 2-бит против модели поменьше в 4-бит на ваших промптах. У 27B в 2-бит остаётся около 6,8 ГБ весов, и в те же 12–16 ГБ VRAM спокойно войдёт модель на 12–14 млрд параметров в 4-бит с запасом на контекст. Что полезнее, решает задача, а не число параметров.
Для простого чата, пересказа статьи, черновика письма и ролевых сценариев 2-бит иногда остаётся рабочим: модель держит тему, хотя формулировки грубеют. Как только появляется строгая структура, картина меняется. Разбор сильного квантования на примере IQ3_XXS против Q8_0 показывает, чем рискует компактная сборка и почему сравнение строят вокруг требований задачи, а не среднего качества.
Где 2-бит чаще всего терпит поражение
Строгий JSON и tool-calling: модель теряет кавычки, добавляет пояснения вокруг объекта, путает имена полей. Для агента это фатально, цепочка рвётся на первом невалидном ответе.
Многошаговые агентные сценарии: небольшая ошибка на каждом шаге накапливается, и к пятому шагу модель уходит от исходной задачи.
Код с длинным контекстом: агрессивное квантование сильнее искажает распределение вероятностей, и модель начинает повторять шаблонные конструкции, терять имена переменных из начала файла, смешивать стили.
Точное следование инструкциям: ограничения вида "ответь одним словом" или "не используй списки" держатся хуже. Чем меньше бит, тем грубее сетка значений и тем сильнее редкие, но важные вероятности сдвигаются в сторону типичных ответов. Модель становится предсказуемее и шаблоннее, а на нестандартной задаче это выглядит как потеря сообразительности.
3-бит против 4-бит: хватает ли 3-бит для кодинга и сложных задач
3-бит разумен как способ запустить модель, которая в 4-бит не влезает. Для чата, суммаризации, ответов на вопросы по документу и черновиков его обычно достаточно: смысловые ошибки редки, стиль остаётся узнаваемым.
Для кодинга запас тоньше. Важны точность синтаксиса, следование конкретному API и удержание контекста файла. 3-бит на модели среднего размера чаще ошибается в мелочах: забывает аргумент, путает метод, теряет импорт. На крупной модели, где базовый навык выше, потери частично компенсируются, и 3-бит крупной модели может обогнать 4-бит меньшей. Это стоит проверять, а не предполагать.
Для агентов критична стабильность формата. 4-бит снижает риск срывов tool-calling, но не отменяет их. Выбор между IQ3_XXS на плотной модели и Q4_K_M на MoE приходится делать одновременно по трём осям: битность, архитектура и требования задачи. Одна и та же битность на разных архитектурах ведёт себя по-разному.
Когда 3-бит оправдан
- 4-бит нужной модели не влезает с рабочим контекстом, а 3-бит влезает.
- Задача сводится к чату, пересказу, черновикам и простым вопросам.
- Модель крупная: 3-бит 70B на общих задачах нередко полезнее 4-бит 30B.
- Остаётся запас VRAM под KV-кэш и есть время прогнать квант на своих промптах.
Возвращаться к 4-бит стоит, если на 3-бит поехал формат вывода, посыпался tool-calling или код перестал проходить тесты. Тогда честнее взять модель поменьше в 4-бит, чем терпеть нестабильность крупной.
KLD: как читать метрику и что считать «почти без потерь»
KL-дивергенция показывает, насколько распределение вероятностей следующего токена у квантованной модели отличается от исходной. Считают её на калибровочном тексте: прогоняют обе модели по одним и тем же последовательностям, сравнивают логиты и усредняют расхождение по токенам. Меньше значение — ближе поведение.
В исходном вопросе из сообщества обсуждают два ориентира: 0.1 и 0.01–0.03. Первое значение читается как заметное расхождение: модель ещё работает, но ведёт себя иначе. Диапазон 0.01–0.03 ближе к тому, что называют практически без потерь. Официального стандарта здесь нет, и пороги стоит воспринимать как договорённость сообщества, а не как сертификат качества.
Сравнивать KLD из разных источников рискованно. Значение зависит от калибровочного датасета, длины последовательностей, версии рантайма и того, какие слои сравнивали. Цифра 0.02 из одного отчёта и 0.02 из другого могут означать разное.
Почему низкий KLD не гарантирует хороший код
KLD — средняя величина. Ошибка в имени функции или лишняя кавычка в JSON занимает доли процента токенов и почти не двигает среднее, но ломает результат целиком. Для кодинга и агентов важнее поведение на редких критичных токенах: закрывающая скобка, имя поля, выбор инструмента.
Практический вывод: KLD годится как фильтр, чтобы отбросить явно испорченный квант, и как способ сравнить две сборки одной модели на одном калибровочном тексте. Решение о пригодности кванта для работы принимается на ваших задачах.
Как квант связан с VRAM и железом
Бюджет памяти складывается из трёх частей: веса, KV-кэш и оверхед рантайма. Веса считаются по формуле выше. KV-кэш растёт линейно с длиной контекста и зависит от числа слоёв, голов и размерности голов. Буферы вычислений добавляют ещё немного.
Типичная ошибка: проверить, что модель запускается на 4K контекста, и удивиться, когда на 32K она падает или уходит в swap. KV-кэш в F16 на длинном контексте занимает гигабайты; перевод кэша в Q8 сокращает его примерно вдвое и часто даёт больше, чем переход с 4-бит на 3-бит. Расчёт на 20 ГБ VRAM, где пришлось выбирать между высоким квантом и длинным контекстом, хорошо показывает этот компромисс.
На CPU и при частичном offload скорость падает на порядки: часть слоёв считается на процессоре. Иногда меньшая модель в 4-бит целиком на GPU быстрее и полезнее большой в 2-бит, половина которой живёт в системной памяти.
Почему бенчмарки не равны реальному опыту
Бенчмарки усредняют. MMLU и похожие наборы состоят из коротких вопросов с выбором ответа, а вы работаете с длинными промптами, своим языком, своими инструментами и своим форматом вывода. Модель, потерявшая 2% на тесте, может развалиться на вашем шаблоне JSON и не потерять ничего на пересказе.
Perplexity и KLD полезны как грубый фильтр: они ловят откровенно испорченные кванты. Тонкие различия между Q4_K_M и IQ4_XS на конкретной модели они показывают слабо. Опыт сообщества страдает тем же: у людей разные модели, железо, версии рантайма и ожидания, а свежий пост вообще содержит вопросы без ответов.
Воспроизводимая личная проверка решает больше, чем чужая таблица. Одинаковые промпты, одинаковая температура, одинаковая длина контекста, записанный результат по каждому пункту.
Практический чек-лист: как выбрать квант под свои задачи
- Определите тип задачи: чат, кодинг или агенты. От этого зависит допустимый уровень деградации.
- Посчитайте бюджет VRAM: параметры × биты / 8 плюс запас на KV-кэш и оверхед. Оставьте 1–2 ГБ свободными.
- Возьмите самый высокий квант, который влезает с нужным контекстом. Для 4-бит это Q4_K_M или IQ4_XS.
- Если не влезает, сравните два варианта: модель поменьше в 4-бит и модель побольше в 3-бит. На 5–10 своих реальных промптах.
- Для кодинга и агентов приоритет — стабильность формата и следование инструкциям. Проверяйте валидность JSON и выбор инструмента, а не красоту текста.
- 2-бит берите только если другие варианты не помещаются, и заранее примите деградацию.
Записывайте результаты: модель, квант, контекст, номер промпта, что именно сломалось. Через неделю память подведёт, а записи останутся.
Мини-набор промптов для личной проверки
- Жёсткий формат: попросите вернуть JSON по схеме с 4–5 полями и проверьте его валидатором, а не глазами.
- Код с конкретным API: задача на 30–50 строк с библиотекой, которую модель должна знать, и проверка запуском.
- Tool-calling: два-три инструмента с описаниями и сценарий, где нужен последовательный вызов. Смотрите, вызывает ли модель нужный инструмент и не путает ли аргументы.
- Длинный контекст: файл на 10–20 тысяч токенов и вопрос по фрагменту из середины.
- Следование ограничениям: "ответь одним абзацем", "не используй списки", "приведи ровно три примера".
Это шаблон проверки, а не готовый результат: цифры и выводы вы получаете сами. Пример похожего подхода — прогон нескольких квантов Qwen 3.8 на задачах AtCoder, где автор смотрел, как квант и режим размышлений влияют на число решённых задач.
Итог: что выбрать под чат, кодинг и агентов
4-бит остаётся дефолтом: Q4_K_M или IQ4_XS закрывают чат, кодинг и большинство агентных сценариев, если модель влезает в память с рабочим контекстом. 3-бит берите, когда это единственный способ запустить крупную модель: для чата и пересказа его хватает, для кодинга и агентов проверяйте на своих промптах. 2-бит — вариант "иначе никак", с ожидаемой деградацией формата и следования инструкциям.
KLD 0.01–0.03 читайте как ориентир "почти без потерь", 0.1 — как заметное расхождение. Пороги не заменяют проверку на ваших задачах и не отменяют разницу в методиках подсчёта.
Считайте бюджет памяти до скачивания файла, оставляйте запас на KV-кэш, смотрите на тег кванта, а не только на цифру бит. Дальше 5–10 своих промптов и запись результатов. Полчаса такой проверки отвечают на вопрос точнее любой чужой таблицы.