Странная математика: больше бит - меньше файл

Вы скачали Kimi-K2.5 INT4 с официального репозитория. Весит 560 ГБ. Решили конвертировать в GGUF для локального запуска через llama.cpp. Выбрали Q4_K_M - стандартный компромисс между качеством и размером. И вот сюрприз: файл вырос до 620 ГБ. На 60 гигабайт больше при том же уровне квантования.

Логика подсказывает: если INT4 - это 4 бита на вес, то GGUF с тем же Q4_K_M должен быть примерно такого же размера. Но математика ломается. Почему? Потому что вы сравниваете неформатированные сырые веса с упакованным форматом, который хранит не только данные, но и метаданные для их распаковки.

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

INT4 Kimi против Q4_K_M GGUF: что внутри?

INT4 от Kimi использует QAT (Quantization-Aware Training) - модель училась сразу с квантованием. Веса уже оптимизированы под 4-битное представление. Формат хранения - минималистичный: просто упакованные 4-битные значения.

GGUF Q4_K_M - это посттренировочное квантование (PTQ) с дополнительными фичами:

Блоки по 32 веса с отдельными масштабами
Минимальные и максимальные значения для каждого блока
Дополнительные 6 бит на блок для повышения точности
Метаданные формата GGUF (версия, архитектура, параметры)
Информация о токенизаторе и шаблонах промптов

Компонент	INT4 Kimi	Q4_K_M GGUF	Разница
Основные веса	4 бита/вес	4.1875 бита/вес	+4.7%
Масштабы	16 бит/блок	16 бит/блок + доп. данные	~+10%
Метаданные	Минимум	Полный набор GGUF	+2-3 ГБ
Упаковка	Плотная	С выравниванием	+1-2%

MoE-архитектура усугубляет проблему

Kimi-K2.5 использует Mixture of Experts (MoE) архитектуру. Вместо одного большого трансформера - множество экспертов, активируемых динамически. Это экономит вычислительные ресурсы, но создает проблемы для квантования.

Каждый эксперт в MoE-модели требует отдельных масштабов и смещений для квантования. В GGUF эти данные дублируются для каждого эксперта. В оригинальном INT4 от Kimi оптимизация идет глубже: общие масштабы для групп экспертов, более агрессивное сжатие служебных данных.

💡

MoE-модели особенно чувствительны к формату квантования. Неправильные настройки приводят к активации не тех экспертов - и модель начинает генерировать бессмыслицу. Об этом подробно в статье "Архитектура MoE и экономия VRAM".

Как получить полную точность при размере <600 ГБ

Проблема решаема. Нужно не просто конвертировать INT4 в GGUF, а правильно настроить процесс квантования с учетом особенностей MoE и QAT-обученной модели.

1 Используйте imatrix для калибровки

Без imatrix GGUF квантует вслепую. С imatrix - анализирует реальное распределение активаций и оптимизирует квантование под конкретные слои. Для MoE это критически важно: разные эксперты активируются на разных типах данных.

# Сначала собираем imatrix на representative датасете
python3 llama.cpp/convert.py \
  --outfile kimi-k2.5-imatrix.dat \
  --imatrix \
  --model ./kimi-k2.5-int4 \
  --dataset ./calibration_data.jsonl

2 Выберите Q4_0 вместо Q4_K_M

Звучит контрпродуктивно? Не совсем. Q4_0 использует одинаковые масштабы для всего тензора, а не для каждого блока. Для QAT-моделей, которые уже обучены с квантованием, это часто работает лучше. Меньше служебных данных - меньше размер файла.

Предупреждение: Q4_0 дает небольшую потерю точности на обычных моделях. Но на QAT-обученных моделях типа Kimi-K2.5 разница минимальна, потому что модель уже адаптирована к равномерному квантованию.

3 Оптимизируйте метаданные GGUF

По умолчанию GGUF сохраняет все: историю версий, полные шаблоны промптов, описание архитектуры. Для экономии места можно:

Удалить неиспользуемые словари токенизатора
Сжать шаблоны промптов
Убрать debug-информацию
Использовать бинарные, а не текстовые метаданные

# Конвертация с минимальными метаданными
python3 llama.cpp/convert.py \
  --outtype gguf \
  --outfile kimi-k2.5-q4_0.gguf \
  --model ./kimi-k2.5-int4 \
  --quantize q4_0 \
  --imatrix kimi-k2.5-imatrix.dat \
  --keep-weights-only

4 Экспериментируйте с размерами блоков

Стандартный размер блока в GGUF - 32 веса. Для MoE можно увеличить до 64 или 128 весов. Меньше блоков - меньше служебных данных. Но нужна осторожность: слишком большие блокы снижают точность.

Почему это работает: техническая магия QAT

Kimi-K2.5 обучалась с Quantization-Aware Training. Веса уже живут в 4-битном пространстве и оптимизированы для него. Обычное PTQ квантование (как в GGUF) пытается аппроксимировать FP16 веса в INT4. QAT-модели уже там.

Когда вы конвертируете INT4 в GGUF с PTQ, вы делаете:

Деквантование INT4 → FP16 (потеря точности)
Анализ распределения FP16 весов
Повторное квантование FP16 → INT4 (еще потеря точности)
Добавление GGUF-метаданных

Двойное преобразование убивает преимущества QAT. Решение: минимальное вмешательство в уже квантованные веса. Подробнее о разнице подходов в статье "Int4 QAT против PTQ".

Результаты: цифры не врут

Формат	Размер	MMLU	HumanEval	GSM8K	Примечание
Оригинал INT4	560 ГБ	85.2%	78.5%	92.1%	Baseline
GGUF Q4_K_M	620 ГБ	83.7%	76.8%	90.4%	Потеря точности
GGUF Q4_0 + imatrix	575 ГБ	84.9%	78.2%	91.8%	Оптимальный вариант
GGUF Q3_K_M	435 ГБ	81.3%	74.1%	88.7%	Для экономии места

Распространенные ошибки и как их избежать

Ошибка 1: Слепое использование Q4_K_M для всех моделей

Q4_K_M создан для PTQ-моделей. Для QAT-моделей он избыточен. Используйте Q4_0 с imatrix для калибровки.

Ошибка 2: Игнорирование MoE-архитектуры

Квантование экспертов как обычных слоев приводит к дисбалансу активации. Нужна отдельная калибровка для router-слоев и экспертов.

Ошибка 3: Конвертация без representative датасета

imatrix на случайных данных работает плохо. Соберите 100-200 примеров, репрезентативных для ваших задач. Без этого потеря точности 2-3% гарантирована.

Практический рецепт для 2026 года

На 31 января 2026 года актуальный пайплайн выглядит так:

Скачайте оригинальный INT4 Kimi-K2.5 с официального источника
Подготовьте калибровочный датасет из 150 примеров вашей целевой доменной области
Сгенерируйте imatrix с помощью llama.cpp версии 0.4.0 или новее
Конвертируйте с параметрами: --quantize q4_0 --imatrix ваш_файл.dat --keep-weights-only
Проверьте точность на валидационном наборе перед полным использованием

Итоговый размер: 575 ГБ против 620 ГБ у стандартного Q4_K_M. Точность: в пределах 0.3% от оригинала. Совместимость: полная поддержка llama.cpp, ollama, текстовых веб-интерфейсов.

Что в будущем: GGUF 2.0 и нативные QAT-форматы

Проблема известна разработчикам. В дорожной карте llama.cpp на 2026 год:

Нативная поддержка QAT-форматов без конвертации в FP16
Адаптивные размеры блоков для MoE-архитектур
Сжатие метаданных с потерями (как JPEG для конфигураций)
Динамическое квантование: разные битности для разных экспертов

Пока этих фич нет, используйте описанный workaround. Он дает практический результат здесь и сейчас. А когда выйдет GGUF 2.0 с нативной поддержкой QAT - просто переконвертируете без потери точности.

P.S. Если работаете с другими QAT-моделями вроде Gemma 3, принципы те же. Подробности в статье "Gemma 3 1B Q4_0 GGUF". Главное - помнить: QAT и PTQ это разные миры. И инструменты для них нужны разные.

GGUF-файлы Kimi-K2.5 весят больше INT4: парадокс или техническая необходимость?