Запуск GLM 5.2 локально (2026): 2-bit на 256 GB Mac или коробке с 4090

GLM 5.2 (753B) на своём железе: 2-bit влезает в Mac Studio на 256 GB, 4-bit просит 512 GB, ~3-9 tok/s. GGUF-кванты для llama.cpp, LM Studio и 4090.

Запуск GLM 5.2 локально (2026): 2-bit на 256 GB Mac или коробке с 4090

Zhipu выложила веса GLM 5.2 на HuggingFace под лицензией MIT, и вопрос перестал быть «смогу ли я скачать frontier-модель для кода» и стал «заведётся ли она на машине, которая у меня уже есть». Для одного Mac Studio или десктопа с одним GPU и кучей RAM ответ — условное да. Условие — это квант.

Что можно запустить локально (а что нельзя)

Это руководство про запуск GLM 5.2 на одной вашей машине с квантизованными GGUF-весами и llama.cpp, LM Studio или Unsloth Studio. Это другая задача, чем обслуживание команды на стойке H200, которую разбирает гайд по железу и стоимости self-host GLM 5.2, и снова другая задача, чем вызов хостингового API, который покрывает гайд по доступу к GLM 5.2.

GLM 5.2 — это модель на 753B параметров с контекстом 1M токенов, выпущенная под MIT. В полной точности BF16 веса занимают ~1.5 TB, что не влезает ни в один десктоп. Локальный инференс означает квантизацию: вы меняете часть качества на объём, который помещается в вашу RAM. Вот 30-секундная версия того, что куда влезает.

Ваша машинаКакой квант влезаетНужно диска / RAMЧего ждать
Mac Studio M3 Ultra, 512 GB4-bit UD-Q4_K_XL~376-475 GBЛучшее локальное качество, почти без потерь, рабочая скорость кодинга
Mac Studio M3 Ultra, 256 GB2-bit UD-IQ2_M~240 GBХорошо пишет код, ~3-9 tok/s, типовая локальная сборка
Десктоп + 4090 + 256 GB DDR52-bit UD-IQ2_M~240 GBРаботает через оффлоад, единицы tok/s
Стойка 8x H200 или 4x H100FP8 / Q4376-750 GBProduction-масштаб, см. гайд по self-host
MacBook / коробка на 64-128 GBнетn/aБерите хостинговый план

Честный заголовок: Mac Studio на 256 GB с 2-bit квантом — это реалистичная сборка «GLM 5.2 на моём столе». 4-bit квант — оптимум по качеству, но он просит машину на 512 GB или тяжёлый оффлоад. Всё, что меньше 256 GB, — это задача для хостингового API, а не локальная.

Рамка решения: когда локальная GLM 5.2 оправдана (а когда НЕТ)

Запускайте квант локально по правильным причинам. Неправильная причина — экономия денег, потому что почти для всех хостинговый план дешевле.

Когда запускать локально

  • Офлайн или air-gapped работа. Исходящий трафик на api.z.ai запрещён, так что модель обязана жить на вашем железе.
  • Приватность на одной коробке. Ваши промпты и код никогда не покидают машину, и один Mac Studio — это весь периметр.
  • Железо у вас уже есть. Mac Studio на 256 GB или 512 GB, купленный под видео или ML, простаивает по ночам, и локальный квант не стоит вам ничего сверху.
  • Эксперименты и обучение. Вы хотите почувствовать, как ведёт себя MoE на 753B, протестировать настройки сэмплинга или построить решение поверх локального OpenAI-совместимого endpoint без rate-лимитов.

Когда НЕ запускать локально

  • Вам нужно дёшево и быстро. Z.ai Coding Plan стоит ~$30/месяц и работает на полной скорости. 2-bit локальный квант на 3-9 tok/s не сравнится с этим даже по цене одного электричества. Прочитайте гайд по доступу.
  • Нужно обслуживать больше одного человека. Один Mac Studio — это машина на одну сессию. Два разработчика, долбящие её одновременно, оба ощутят, как она еле ползёт. Это путь дата-центра.
  • У вас машина меньше 256 GB. Нет кванта, который уместил бы GLM 5.2 в коробку на 128 GB на качестве, которое стоит использовать. Не сжигайте выходные на попытки.
  • Вам нужен полный контекст 1M. KV-кэш под длинный контекст не влезает в потребительское железо. Локально на практике потолок около 16K-64K.

Правило остановки

Если у вас нет хотя бы 256 GB unified memory или системной RAM — остановитесь здесь и берите хостинговый план. Никакая квантизация этот порог не сдвинет.

Системные требования

flowchart TD
  A[Сколько памяти?] -->|Mac на 512 GB| B[4-bit UD-Q4_K_XL<br/>лучшее локальное качество]
  A -->|Mac на 256 GB или DDR5| C[2-bit UD-IQ2_M<br/>типовая сборка]
  A -->|меньше 256 GB| D[Берите хостинговый план<br/>это не локальная задача]
  B --> E[llama.cpp / LM Studio / Unsloth Studio]
  C --> E

Прежде чем тянуть 240 GB весов, убедитесь, что у вас есть:

  • Память. Минимум 256 GB (unified memory на Apple silicon или системный DDR5 на CUDA-коробке). 2-bit квант — это ~240 GB, так что на машине с 256 GB запас реально впритык: закройте другие приложения и оставьте macOS его долю unified memory, иначе упрётесь в своп. 512 GB, чтобы комфортно гонять 4-bit.
  • Диск. Квант плюс запас: ~240 GB свободно под 2-bit, ~376-475 GB под 4-bit. SSD, а не вращающийся диск, иначе время загрузки становится мучительным.
  • Раннер. llama.cpp, собранный из свежего коммита, LM Studio или Unsloth Studio. Архитектура (GLM MoE DSA) достаточно новая, чтобы старая сборка llama.cpp не смогла загрузить тензоры.
  • Правильный репозиторий. Community GGUF-кванты лежат по адресу huggingface.co/unsloth/GLM-5.2-GGUF. Официальный репозиторий zai-org/GLM-5.2 — только BF16 и для локального инференса не то, что вам нужно.

Пошагово: запуск GLM 5.2 локально

Шаг 1: скачайте GGUF-квант

Качайте только нужный квант, а не весь репозиторий. Фильтр --include спасёт вас от загрузки 750 GB шардов, которыми вы не воспользуетесь.

# 2-bit для машины на 256 GB (~240 GB на диске)
hf download unsloth/GLM-5.2-GGUF \
  --local-dir ~/models/glm-5.2-gguf \
  --include "*UD-IQ2_M*"

В итоге у вас должен оказаться набор шардов GLM-5.2-UD-IQ2_M-0000X-of-0000Y.gguf в ~/models/glm-5.2-gguf. Поменяйте фильтр на *UD-Q4_K_XL*, если вы на машине с 512 GB. Сверьтесь с актуальной вкладкой «Files and versions» на HuggingFace на предмет точных имён шардов, поскольку Unsloth правит метки квантов по мере улучшения динамических квантов.

Шаг 2: запустите через llama.cpp

Это путь командной строки и тот, в котором больше всего контроля. Сначала соберите свежий llama.cpp (Metal компилируется автоматически на Mac; добавьте -DGGML_CUDA=ON на коробке Nvidia).

# Сборка однократно
cmake -B build && cmake --build build --config Release -j

# Поднять OpenAI-совместимый endpoint на порту 8080
./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 999 \
  --temp 1.0 --top-p 0.95 --min-p 0.01 \
  --host 0.0.0.0 --port 8080

Каждый флаг здесь не зря:

  • --ctx-size 32768 задаёт окно 32K. Поднятие быстро съедает память на машине с 256 GB; начните отсюда и растите только если запрос этого требует.
  • --n-gpu-layers 999 оффлоадит на GPU все слои, какие может. На Mac благодаря unified memory это почти бесплатно; на 4090 оффлоадит ту долю, что влезает в 24 GB, а остальное оставляет на CPU.
  • --temp 1.0 --top-p 0.95 --min-p 0.01 — рекомендованные Zhipu дефолты сэмплинга. Ошибка здесь — самая частая причина жалоб «локальная модель тупее хостинговой».

После загрузки llama-server логирует число слоёв и затем печатает server listening on http://0.0.0.0:8080. Первая загрузка с SSD занимает минуту-другую.

Шаг 3: или используйте GUI (LM Studio / Unsloth Studio)

Если возиться со сборочным тулчейном не хочется, те же GGUF-кванты грузят два приложения с GUI.

LM Studio запускает те же GGUF-кванты из десктопного приложения. Найдите unsloth/GLM-5.2-GGUF во встроенном браузере моделей, выберите 2-bit или 4-bit квант, и оно само разберётся с загрузкой и запуском, выставив тот же OpenAI-совместимый endpoint на локальном порту.

Unsloth Studio — это веб-интерфейс с автоматическим оффлоадом памяти, ставится в одну строку.

curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -H 0.0.0.0 -p 8888

Оба — лучший выбор, если вы хотите менять кванты и настройки без перенабора длинной команды llama.cpp каждый раз.

Шаг 4: smoke-тест

Направьте любой OpenAI-клиент на локальный порт и убедитесь, что он отвечает.

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [{"role":"user","content":"Reply with only the string OK."}],
    "max_tokens": 16
  }' | jq -r '.choices[0].message.content'

После короткой паузы вы должны получить обратно OK. Если ответ искажён или зациклился — у вас сбиты параметры сэмплинга, так что перепроверьте --temp 1.0 --top-p 0.95 --min-p 0.01 против значений в huggingface.co/zai-org/GLM-5.2/generation_config.json.

Реальные tokens/sec: чего ждать по уровням

Скорость генерации на локальном железе ограничена пропускной способностью памяти, а не голым вычислением, — поэтому Mac Studio с unified memory на 800 GB/s обгоняет десктоп с DDR5, у которого RAM работает ближе к 80-100 GB/s. Вот цифры, под которые стоит планировать.

СборкаКвантРеалистичная скорость генерацииДля чего годится
Mac Studio M3 Ultra, 256 GB2-bit UD-IQ2_M~3-9 tok/sСоло кодинг-агент, одна сессия
Mac Studio M3 Ultra, 512 GB4-bit UD-Q4_K_XLнесколько tok/s, выше качествоСоло-работа, где корректность важнее скорости
Десктоп, 4090 + 256 GB DDR52-bit UD-IQ2_MединицыЭксперименты, офлайн
Стойка 4x H100 / 8x H200Q4 / FP8десятки tok/s на потокКоманды (см. гайд по self-host)

Закономерность: локальная GLM 5.2 — это инструмент на один поток и одного разработчика. Скорости хватает на один кодинг-агент, прорабатывающий задачу. Её не хватает на общий endpoint, и никакой потребительский квант этого не меняет. Если вам нужен throughput на команду, гайд по железу для self-host проходит путь vLLM и SGLang на дата-центровых GPU.

Частые ошибки при локальной настройке (и их лечение)

ОшибкаВероятная причинаЛечение
tensor not found: blk.X.attn_q.weightСборка llama.cpp слишком старая для GLM MoE DSAПодтяните свежий коммит llama.cpp и пересоберите cmake --build build
Процесс убит / своп-трэш при загрузкеКвант больше свободной RAMСбросьте на квант поменьше или закройте другие приложения; 2-bit нужно ~240 GB свободно, а не просто установлено
Вывод повторяется или бессвязныйПараметры сэмплинга не выровнены под дефолты ZhipuЗадайте --temp 1.0 --top-p 0.95 --min-p 0.01; не оставляйте top_k на низком дефолте
Мучительно медленная генерация на коробке с 4090Большинство слоёв работает из DDR5, а не VRAMОжидаемо на 24 GB VRAM; снизьте --ctx-size или перейдите на Mac с 256 GB ради лучшей пропускной способности
failed to allocate KV cache при высоком ctx-sizeОкно контекста велико для оставшейся памятиСнизьте --ctx-size или квантизуйте KV-кэш через --cache-type-k q4_1 --cache-type-v q4_1
Модель «думает» вечно перед ответомВключён режим мышления на задаче, которой он не нуженОтключите через --chat-template-kwargs '{"enable_thinking":false}'
Ollama pull предлагает только glm-5.2:cloudЛокального тега Ollama пока нетИспользуйте llama.cpp или LM Studio с Unsloth GGUF вместо этого

Команда / несколько разработчиков: когда одного Mac мало

Одна локальная машина обслуживает одного человека. В момент, когда второй разработчик направит агента на тот же llama-server, обе сессии замедлятся до ползка, потому что у потребительского железа нет лишней пропускной способности на разделение. Хитрого флага, который это чинит, не существует.

Два реальных варианта, когда локальный перестаёт масштабироваться:

  1. Перейти на дата-центровые GPU. Нода 8x H200, обслуживающая FP8, тянет множество параллельных потоков по десятки токенов в секунду каждый. Это другая история по стоимости и эксплуатации, полностью проработанная в гайде по vLLM и стоимости self-host, включая математику точки безубыточности против хостингового плана.
  2. Использовать хостинговый endpoint и перестать гонять железо. Для большинства команд это выигрывает по всем осям, кроме residency данных.

Локальный квант — правильный инструмент для одного разработчика, который хочет модель на своей машине. Он неправильный инструмент для общего сервиса.

Продвинуто: длинный контекст и режим мышления

Две ручки стоит знать, как только базовая настройка заработала.

Квантизация KV-кэша. Контекст 1M реален в архитектуре, но недостижим на коробке с 256 GB, потому что один только KV-кэш потребовал бы сотен гигабайт. Его квантизация возвращает место:

./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 65536 \
  --cache-type-k q4_1 --cache-type-v q4_1 \
  --n-gpu-layers 999 --port 8080

Это примерно вдвое урезает память KV-кэша, позволяя продвинуть контекст дальше на том же железе, ценой небольшой потери качества на очень длинных входах.

Режим мышления. У GLM 5.2 есть режим рассуждения, который тратит токены на размышление перед ответом. На быстрых правках и коротких промптах он добавляет задержку, которая вам может быть не нужна. Отключайте его на запрос через --chat-template-kwargs '{"enable_thinking":false}' и оставляйте включённым на тяжёлых многошаговых задачах, где лишнее рассуждение себя окупает.

Когда локальный — неправильный ответ: хостинг и альтернативы на ofox

Если порог в 256 GB или скорость на одну сессию исключают локальный путь, отказываться от GLM 5.2 совсем не обязательно. Та же модель есть в каталоге ofox как z-ai/glm-5.2 по цене $1.40/M на вход и $4.40/M на выход, так что вы можете гонять её на хостинге на полной скорости, поменяв только base URL и model ID, без железа, которое надо покупать и нянчить. Вы прототипируете против локального llama-server, а затем направляете тот же клиент на хостинговую модель:

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="ofox-..."
export OPENAI_MODEL="z-ai/glm-5.2"   # та же самая модель, теперь на хостинге

Гайд по хостинговому доступу разбирает также путь через Z.ai Coding Plan к той же модели. А если вам нужны ещё пара open-weights coding-моделей за тем же OpenAI-совместимым endpoint, ofox перечисляет и эти с первого дня:

Модельmodel ID на ofoxКонтекстКогда выбрать вместо GLM 5.2
DeepSeek V4 Prodeepseek/deepseek-v4-pro1MНужна более длинная история в комьюнити и опубликованные цифры SWE-bench Verified
Kimi K2.6moonshotai/kimi-k2.6262KНужен независимо отбенчмаркнутый длинный контекст, а не локальный потолок 16K
Qwen 3 Coder Nextbailian/qwen3-coder-next256KМногоязычные кодовые базы, где локальная скорость слишком мала для итераций

Чтобы прочитать GLM по цене и качеству против закрытой модели, прежде чем коммититься на локальное железо или хостинговую подписку, см. сравнение стоимости GLM 5.2 против GPT-5.5.

Источники, проверенные для этого апдейта

Интересный сдвиг не в том, что frontier-модель работает локально, а в том, как мало теперь стоит это выяснить. Mac Studio на 256 GB, который у вас уже есть, и вечер на загрузку — вот и весь эксперимент. Дальше стоит следить за FP4 и более плотными динамическими квантами: в день, когда хороший 4-bit опустится ниже 200 GB, локальный порог сдвинется с Mac на 256 GB до машины на 128 GB, и подходящих столов станет куда больше.