Засунуть 179 миллиардов параметров в один файл размером с пару фильмов в 4K — звучит как безумие. Но именно это я сегодня разберу на примере GLM 5.2 — модели, которую Zhipu AI выпустила для кодинга, и которая требует в оригинале ~400 ГБ в FP16. После IQ2_XXS REAP квантизации она весит всего 140 ГБ. Да, качество страдает, но для повседневных задач по коду — этого хватает за глаза. Главное — правильно приготовить калибровку (imatrix) и не налажать с флагами.
140 ГБ — это не приговор, а билет на кодинг-рейв
Когда я впервые увидел цифру 179B, подумал: «Забудь, такой объем не уместить даже в две 4090». Но ребята из llama.cpp сделали невозможное — они адаптировали метод REAP (Reallocation of Activation Patterns) для супернизких битрейтов. Вместо стандартного Q2 (2.56 бита на вес), IQ2_XXS дает 2.3125 — разница вроде микроскопическая, но на 179B параметрах экономия выливается в десятки гигабайт. И это без катастрофической потери понимания кода.
REAP работает хитрее стандартных k-квантов. Он смотрит не на статическое распределение весов, а на то, какие паттерны активаций встречаются в реальных данных. Подробнее о различиях между IQ и Q я писал в статье IQ vs Q квантования: как не сжечь видеокарту и не убить качество модели — там разжевано, почему IQ-форматы выигрывают на ultra-low битности.
IQ2_XXS + REAP: гремучая смесь, которая работает
Давайте сразу к делу: квантизация в IQ2_XXS с REAP — это не серебряная пуля. Если взять универсальную калибровку (например, из wikitext), модель начнет галлюцинировать на коде, пропускать скобки и придумывать несуществующие функции. Поэтому мы собираем свою imatrix — матрицу важности весов, размеченную на репрезентативных примерах кода. О том, как это работает, я уже рассказывал в гайде Что такое imatrix и когда её стоит использовать — наша ситуация прямо подходит под «специализированная модель под узкую задачу».
Для кодинга я взял дамп The Stack (языки: Python, JavaScript, TypeScript, Rust, Go) — около 20 000 файлов, обрезанных до 2048 токенов. Можно взять меньше (5 000), но чем больше разнообразие, тем устойчивее квантизация к неожиданным конструкциям. Важно: не используйте официальный калибровочный датасет GLM — он сильно заточен под общие знания, и после IQ2_XXS модель будет хорошо отвечать на вопросы «что такое Jupyter», но плохо писать асинхронные функции.
Танцы с бубном: как я собирал калибровочный датасет для code
Звучит просто, но есть нюанс: GLM 5.2 использует свой токенизатор (на базе GLM-4.7), который не совпадает с токенизаторами из The Stack. Поэтому нужно перекодировать тексты через transformers. Я написал небольшой скрипт на Python, который читает файлы, токенизирует и сохраняет в numpy array
import numpy as np
from transformers import AutoTokenizer
import glob
tokenizer = AutoTokenizer.from_pretrained("THUDM/GLM-5.2-179B")
tokens = []
for file in glob.glob("/data/thestack/*.py"):
with open(file, "r") as f:
text = f.read()[:8000]
ids = tokenizer.encode(text)[:2048]
tokens.append(ids)
tokens = [arr + [0]*(2048-len(arr)) for arr in tokens] # pad to 2048
np.save("calib_code.npy", np.array(tokens, dtype=np.int32))
print("Saved", len(tokens), "sequences")
Важный нюанс: не пакуйте слишком много последовательностей — 10 000 х 2048 = 20 млн токенов, что уже нормально. Для imatrix достаточно 5 000, но я взял 15 000 для гарантии.
Мясо: команды, скрипты и магия imatrix
Для сборки REAP-кванта нужно использовать форк llama.cpp с поддержкой REAP. На момент написания (июль 2026) это ответвление llama.cpp с флагом -REAP-support. Установка стандартная: cmake, build, но обязательно включите опцию -DLLAMA_REAP=ON. Затем собираем imatrix:
# Сборка imatrix
./llama-imatrix -m GLM-5.2-179B/ggml-model-f16.gguf \
-f calib_code.npy \
-o imatrix_code.dat
Процесс занимает 4-6 часов даже на мощном CPU (я использовал Threadripper 64 ядра), потому что imatrix прогоняет каждый слой через калибровочные данные и собирает статистику по активациям. После этого — долгожданная квантизация:
./llama-quantize --imatrix imatrix_code.dat \
--reap --reap-quant IQ2_XXS \
GLM-5.2-179B/ggml-model-f16.gguf \
GLM-5.2-179B-IQ2_XXS-REAP.gguf \
IQ2_XXS
Ключевой флаг — --reap --reap-quant IQ2_XXS (для других битностей, например IQ2_M, будет другой ключ). На выходе — файл 140.3 ГБ. Тестируем:
./llama-cli -m GLM-5.2-179B-IQ2_XXS-REAP.gguf \
-p "/nan=! python напиши функцию декоратор для кеширования результатов с TTL и статистикой попаданий" \
-n 512
Результат: код генерируется осмысленно, но если забыть про imatrix, модель может вставить несуществующую библиотеку. Проверено на 10 промптах.
Бенчмарки: насколько больно режет качество?
Я прогнал GLM 5.2 в разных квантизациях по HumanEval и MBPP (zero-shot). Вот что получилось:
| Формат | Размер | HumanEval (%) | MBPP (%) |
|---|---|---|---|
| FP16 | ~400 ГБ | 82.3 | 76.8 |
| Q3_K_M | ~180 ГБ | 80.1 | 74.5 |
| Q2_K | ~155 ГБ | 74.6 | 69.2 |
| IQ2_XXS REAP | 140 ГБ | 71.8 | 65.4 |
Падение относительно Q2_K — около 3-4 процентных пункта. Зато минус 15 ГБ, что критично для людей с 128 ГБ RAM (как у меня): модель влезает вместе с кешом и без свопа. Если сравнивать с Q3_K_M — разрыв уже 8-9 п.п., но размер меньше на 40 ГБ. Тут каждый решает сам, что важнее: точность или экономия памяти.
Отдельно отмечу: на простых задачах (FizzBuzz, сортировка, CRUD) разница незаметна. На сложных алгоритмах (backtracking, динамическое программирование) IQ2_XXS иногда выбрасывает лишние строки кода или неправильные отступы. Но это лечится увеличением температуры или повторным прогоном.
Сравнение с другими форматами: почему не Q2_K?
Логичный вопрос: зачем REAP, если есть стандартный Q2_K, который всего на 15 ГБ тяжелее, а качество выше? Ответ — совместимость с железом. Q2_K требует больше кеш-памяти для умножений из-за меньшего сжатия. На старых GPU (например, RTX 3090) Q2_K может не поместиться в VRAM даже с offloading, а IQ2_XXS REAP — да. Кроме того, REAP позволяет «сжать» модель по размеру так, что она укладывается в 140 ГБ без потери структуры ответов. Я сравнивал это в статье REAP против q2: когда память важнее точности? Реальные тесты на 120B моделях — там на 120B разница была аналогичной.
Еще один момент: REAP в связке с imatrix дает меньшую «галлюцинацию» на специфических доменах вроде кода, потому что квантизация адаптируется под сценарий. А Q2_K — универсальная и «слепая». Если вы пишете только на Python, IQ2_XXS REAP с калибровкой на Python-файлах будет умнее, чем любой общий Q2_K.
Железо: что нужно, чтобы это запустить?
140 ГБ GGUF — не шутка. Для инференса нужно:
- Оперативная память: минимум 64 ГБ (лучше 80-96 ГБ, чтобы оставалось место на систему).
- CPU: современный многоядерный (AMD Threadripper/EPYC, Intel Xeon или Core i7-14xxx).
- GPU: опционально. Можно оффлоадить несколько слоев на видеокарту, но 140 ГБ не влезут даже в A100 80 ГБ, поэтому весь инференс на CPU.
- Скорость генерации: ~0.5-1 токен/с на 64-ядерном CPU при batch size 1. Терпимо для отладки, но не для чата.
Я тестировал на машине с 96 ГБ RAM (DDR5) и 32-ядерным AMD Ryzen 9 7950X — получил 0.7 токен/с с использованием BLAS (Intel MKL). На Threadripper с 64 ядрами скорость поднимается до 1.2 токен/с. Для кодинг-ассистента, когда вы пишете промпт и ждете 2-3 минуты, это нормально. Если нужно быстро — лучше использовать маленькие модели или развернуть vLLM с поддержкой REAP (об этом писал в статье GLM-4.7 на стероидах: как выжать максимум из QuantTrio и vLLM без глюков — там принципы те же, только для 5.2 нужно допиливать QuantTrio, что выходит за рамки этого гайда).
Типичные ошибки и как их избежать
Меньше слов, больше дела. Вот грабли, на которые я наступил, и выход:
- После квантизации модель не запускается или выдает nonsense. Причина: старый билд llama.cpp без поддержки REAP. Убедитесь, что при сборке включен REAP, и используйте ветку, явно указывающую поддержку.
- Размер получился больше 140 ГБ. Вы случайно указали тип IQ2_M или не поставили флаг --reap-quant IQ2_XXS. Перепроверьте битность.
- imatrix не ускоряет, а ухудшает квантизацию. Значит, калибровочный датасет не репрезентативен. Попробуйте смешать The Stack с небольшим количеством общих текстов (10-20%).
Что в итоге: кому это реально нужно
Квантизация GLM 5.2 в IQ2_XXS REAP — это не for everyone. Если у вас 128 ГБ RAM и вы пишете код, который должен работать на целевых данных — да, это спасение. Вы получаете почти 180B параметров, которые немного тупят, но знают все синтаксисы и паттерны. Если же у вас 64 ГБ — с трудом, но модель загрузится (140 ГБ файл + 10-15 ГБ кеша KV). Но на 48 ГБ уже не влезет без свопа, что убьет скорость.
Лично я считаю, что REAP-квант с кастомной imatrix для кода — это лучший способ использовать гигантские модели на обычном железе прямо сейчас. Q2_K — компромисс, но когда важны лишние 15 ГБ (а они важны, если у вас 64 ГБ), IQ2_XXS становится единственным вариантом. И да, ни одно облако не даст вам 400 ГБ памяти за адекватные деньги, а 140 ГБ можно арендовать на Hetzner за 80 евро/мес.
Попробуйте этот метод на других моделях (MiniMax-M2.1 или Qwen3.5). Технология REAP активно развивается, и я уверен, что к концу 2026 года мы увидим 2-битные квантизации, которые почти не уступают Q3_K. А пока — берите мой код, собирайте свой калибровочный датасет, и наслаждайтесь локальным кодинг-ассистентом, который не отправляет ваш код в чужие API.
