Show HN: как запустить 744-миллиардную модель GLM-5.2 на ноутбуке с 25 ГБ памяти

Пользователь vforno (проект на GitHub, JustVugg/colibrì) опубликовал на Hacker News историю о том, как он запустил гигантскую языковую модель GLM-5.2 (744 миллиарда параметров, архитектура «смесь экспертов», Mixture-of-Experts, MoE) на собственном скромном ноутбуке, 12 ядер процессора, 25 ГБ оперативной памяти, NVMe-диск за виртуальным диском WSL2 с ограничением случайного чтения около 1 ГБ/с. Пост набрал 472 балла и 124 комментария на Hacker News.

Идея: на каждый токен GLM-5.2 реально задействует лишь около 40 млрд параметров, из которых от токена к токену меняется только часть, «маршрутизируемые» эксперты весом около 11 ГБ. Автор разделил модель на две части. «Плотная» часть (внимание, общие эксперты, эмбеддинги, около 17 млрд параметров) в 4-битном квантовании (int4) занимает около 9,9 ГБ и постоянно держится в оперативной памяти. Остальные 21 504 маршрутизируемых эксперта (75 слоёв MoE по 256 экспертов плюс голова для предсказания нескольких токенов, MTP, каждый эксперт около 19 МБ в int4) хранятся на диске, суммарно около 370 ГБ, и подгружаются по мере необходимости через LRU-кэш на каждый слой, с опциональным «закреплением» горячих экспертов в памяти и файловым кэшем ОС в роли бесплатного второго уровня кэша.

Весь движок, один C-файл (c/glm.c, около 1300 строк) плюс небольшие заголовочные файлы: без BLAS, без Python во время работы, без GPU. Автор проверил точность реализации: прямой проход модели токен-в-токен совпадает с эталонной реализацией на transformers (teacher-forcing 32 из 32, жадная генерация 20 из 20 на игрушечной модели с той же архитектурой, но случайными весами).

Среди технических решений: MLA-внимание (multi-head latent attention, многоголовое латентное внимание с LoRA-сжатием query/key/value и чередующимся частичным RoPE) со сжатым кэшем ключей-значений, 576 чисел на токен вместо 32 768, то есть в 57 раз меньше (у GLM-5.2 64 «головы» внимания и нет group-query attention); маршрутизатор экспертов в стиле DeepSeek-V3 с сигмоидой; общий эксперт и первые три «плотных» слоя без маршрутизации.

Отдельная фича, предсказание нескольких токенов (MTP, multi-token prediction) собственной «головой» GLM-5.2 (78-й слой): она делает черновые прогнозы токенов, которые основная модель проверяет за один проход. Голова MTP должна работать в 8-битном квантовании (int8), конвертер делает это по умолчанию: при 4-битном квантовании доля принятых черновых токенов падает до 0, 4% и ускорение не срабатывает, при 8-битном, 39, 59% принятых прогнозов, 2,2, 2,8 токена за один проход (по замерам сообщества). Метод не теряет в точности результата. Честная оговорка автора: на «холодном» кэше каждый проверенный черновой токен требует подгрузки дополнительных экспертов (примерно с 660 до 1100 подгрузок эксперта на токен), поэтому ускорение может обернуться замедлением, пока кэш не «прогреется», для этого есть адаптивная защита и режим отключения (DRAFT=0).

Другие оптимизации: целочисленные ядра умножения (int8-активации в стиле Q8_0, инструкции AVX2), умножения int8 быстрее в 1,4, 2,5 раза (119 GFLOP/с в замерах), int4 быстрее в 1,8 раза при пакетной обработке; приём «поглощения весов» MLA (трюк DeepSeek) для декодирования без восстановления key/value на каждом токене; асинхронная упреждающая подгрузка следующего блока экспертов, пока считается текущий; ядра квантования int8/int4/int2 с масштабами по строкам; разреженное внимание DSA, в разработке (веса «индексатора», около 108 ГБ, выгружаются из исходного FP8-репозитория, сам индексатор ещё не встроен, пока внимание работает как плотное и точное для контекста до 2048 токенов); объединение пакетов при MoE, если несколько позиций в пакете маршрутизируются к одному эксперту, он читается один раз; собственный байтовый BPE-токенизатор на C.

Безопасность по памяти: размер кэша экспертов автоматически подбирается под доступную RAM при старте, чтобы не сработал OOM-killer. Отдельный офлайн-конвертер (Python-скрипт) переводит модель из исходного формата FP8 в int4: он скачивает шард за шардом (~5 ГБ), деквантует, реквантует и удаляет шард, весь исходный чекпойнт на 756 ГБ никогда не лежит на диске целиком, процесс можно возобновить после прерывания.

Автор честно называет свой движок медленным: это не про скорость, а про то, что модель уровня фронтира на 744 млрд параметров вообще отвечает корректно на железе дешевле одного вентилятора для сервера H100. «Холодный» старт требует много случайных чтений (~11 ГБ на токен), но чтение почти не изнашивает SSD (стриминг colibrì, это только чтение); реальные риски, подкачка (swap), если не хватает оперативной памяти (запись уже изнашивает диск, поэтому бюджет RAM нужно выставлять с запасом), и длительный нагрев более дешёвых накопителей при постоянной нагрузке на чтение, автор советует следить за температурой и здоровьем диска.

Готовая конвертированная в int4 модель GLM-5.2 для colibrì выложена на Hugging Face (jlnsrk/GLM-5.2-colibri-int4), это позволяет пропустить конвертацию из FP8. Требования к железу: Linux или WSL2, gcc с OpenMP, поддержка AVX2, от 16 ГБ RAM и около 370 ГБ под int4-модель на локальном NVMe с файловой системой ext4 (не сетевой или 9p-монтированный диск).

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

Автор признаёт: он ещё не измерил, сколько точности теряется из-за 4-битного квантования, инструмент для замера (бенчмарки MMLU, HellaSwag, ARC) готов и встроен в проект, но на его собственном диске (~1 ГБ/с) полный прогон занимает большую часть дня; опубликованные оценки полноточной GLM-5.2 на этих задачах, около 85, 95%, и если int4-версия окажется в пределах нескольких пунктов от них, квантование можно будет считать оправданным. Автор прямо просит владельцев более быстрого железа прислать цифры через issues на GitHub.

colibrì, проект одного человека, написанный и протестированный целиком на ноутбуке с 12 ядрами и 25 ГБ RAM; сам движок распространяется по лицензии Apache 2.0, веса GLM-5.2 выпущены компанией Z.ai по лицензии MIT.

Ключевые факты

• colibrì, движок на чистом C (около 1300 строк, без BLAS, Python и GPU в рантайме), который запускает модель GLM-5.2 на 744 млрд параметров (MoE) на потребительском железе с ~25 ГБ RAM.
• Идея: «плотная» часть модели (~17 млрд параметров, ~9,9 ГБ в int4) держится в памяти постоянно, а 21 504 маршрутизируемых эксперта (~370 ГБ на диске) подгружаются по требованию через LRU-кэш и упреждающее чтение.
• Встроено предсказание нескольких токенов (MTP) с ускорением декодирования, 39, 59% принятых черновых токенов при int8-голове, без потери точности, хотя на холодном кэше эффект может быть отрицательным.
• Оптимизации: сжатый в 57 раз KV-кэш (MLA-внимание), целочисленные ядра умножения (int8/int4), офлайн-конвертер FP8→int4, который скачивает и обрабатывает модель шард за шардом без необходимости хранить все 756 ГБ разом.
• Автор, разработчик-одиночка, тестировавший всё на ноутбуке с 12 ядрами и 25 ГБ RAM; готовая int4-модель выложена на Hugging Face, точность квантования пока не измерена и остаётся открытым вопросом проекта.

Почему это важно

Проект показывает, что для запуска модели «уровня фронтира» с сотнями миллиардов параметров необязателен парк GPU: если хранить на диске только те веса, которые реально нужны для конкретного токена, а не всю модель целиком, гигантскую MoE-модель можно «прокормить» с обычного NVMe-накопителя. Это смещает границу между «модель для дата-центра» и «модель для энтузиаста», не по качеству ответов, а по минимально необходимому железу.

Кому это важно

Разработчикам и исследователям, которые хотят экспериментировать с открытыми крупными моделями без аренды GPU-кластера; авторам инструментов для локального инференса, которым интересны конкретные приёмы (MTP-ускорение, сжатие KV-кэша, потоковая подгрузка экспертов); а также всем, кто следит за тем, как открытые веса (GLM-5.2 от Z.ai) конвертируются в практичные локальные форматы силами сообщества, а не только производителя модели.

Как это применить

Проект открытый (Apache 2.0 для движка, веса GLM-5.2, MIT), исходники и готовая int4-модель на Hugging Face доступны сразу. Для запуска нужны Linux или WSL2, gcc с OpenMP, поддержка AVX2, от 16 ГБ RAM и около 370 ГБ свободного места на локальном NVMe с ext4. Автор прикладывает пошаговую инструкцию: сборка и самопроверка движка, замер скорости своего диска отдельной утилитой, затем чат с моделью и запись статистики для «прогрева» кэша экспертов.

Можно ли доверять

Автор подтвердил корректность реализации сравнением с эталонной моделью на transformers (точное совпадение прогонов на игрушечной модели той же архитектуры) и отдельно проверил математические трюки (сжатие внимания, «поглощение» весов) на точное совпадение. При этом он сам честно отмечает главный пробел: точность после 4-битного квантования по стандартным бенчмаркам (MMLU, HellaSwag, ARC) ещё не измерена на реальном масштабе, только заявлен инструмент для такого измерения и обещание сравнить с опубликованными 85, 95% полноточной модели, когда появится более быстрое железо для прогона.

Риски и подводные камни

Производительность далека от GPU-инференса: холодный старт требует около 11 ГБ случайного чтения с диска на каждый токен, и на медленном накопителе (у автора ~1 ГБ/с) это ощутимо ограничивает скорость ответа. Ускорение через предсказание нескольких токенов может, наоборот, замедлить систему на непрогретом кэше экспертов из-за дополнительных подгрузок. При исчерпании оперативной памяти возможна подкачка на диск, которая уже реально изнашивает накопитель, а долгая работа на постоянном чтении нагревает более дешёвые SSD, автор рекомендует следить за бюджетом RAM и температурой диска.

«Колибри весит несколько граммов, зависает на месте и облетает тысячу цветков в день. Этот движок держит живым 744-миллиардного гиганта на колибриных пайках: 25 ГБ оперативной памяти, двенадцать процессорных ядер и много дискового терпения.»

— vforno, автор проекта colibrì