Запуск 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, и подходящих столов станет куда больше.

Часто задаваемые вопросы

Можно ли запустить GLM 5.2 на Mac?
Да, на Mac Studio с достаточным объёмом unified memory. 2-bit GGUF-квант (~240 GB) работает на M3 Ultra с 256 GB unified memory на скорости примерно 3-9 токенов/сек. 4-bit квант (~376 GB) требует машины на 512 GB. MacBook или Mac mini на 64-128 GB веса не вместит даже в 2-bit. Apple silicon тут годится потому, что GPU адресует весь пул unified memory на скорости около 800 GB/s — это сильно выше пропускной способности десктопного DDR5.
Сколько оперативной памяти нужно, чтобы запустить GLM 5.2 локально?
Подбирайте RAM (или unified memory) под квант: ~240 GB для 2-bit, ~376 GB для 4-bit и ~750 GB для 8-bit. На CUDA-рабочей станции веса живут в системном DDR5, а llama.cpp оффлоадит в VRAM столько слоёв, сколько влезает — так что коробка на 256 GB DDR5 с GPU на 24 GB тянет 2-bit квант. Конфигурации, которая уместила бы GLM 5.2 в 64 GB или 128 GB на пригодном качестве, не существует.
Какой GGUF-квант для GLM 5.2 лучший?
Для работы с кодом на машине с 512 GB оптимум по качеству — 4-bit квант UD-Q4_K_XL. Unsloth сообщает, что он почти без потерь относительно весов BF16. Если у вас только 256 GB, реалистичный минимум — 2-bit квант UD-IQ2_M (~82% top-1 точности на внутренней проверке Unsloth), который всё ещё хорошо пишет код. Ниже 2-bit падение качества резкое и для агентного кодинга не стоит того.
Насколько быстро GLM 5.2 работает на Mac Studio?
На M3 Ultra с 256 GB unified memory 2-bit квант выдаёт примерно 3-9 токенов/сек в зависимости от длины контекста: быстрее на коротких промптах, медленнее по мере роста KV-кэша. Этого комфортно хватает на одну сессию кодинг-агента и слишком мало, чтобы обслуживать команду. Сброс окна контекста до 16K держит интерактивную задержку минимальной.
Потянет ли GLM 5.2 одна RTX 4090?
Только с оффлоадом в системную RAM и медленно. У 4090 24 GB VRAM, то есть в неё помещается примерно десятая часть даже 2-bit кванта. llama.cpp грузит остальное в DDR5, и узким местом становится пропускная способность памяти — это уводит вас в диапазон единиц токенов/сек, обычно ниже Mac Studio на 256 GB. 4090 помогает обработке промпта больше, чем генерации. Под десктопную сборку дайте ей минимум 256 GB DDR5.
Запускается ли GLM 5.2 в LM Studio или Ollama?
LM Studio запускает GGUF-кванты от Unsloth напрямую, как только у вас есть RAM, с графическим интерфейсом вместо командной строки. У Ollama сегодня есть только тег glm-5.2:cloud, который маршрутизирует на хостинговый инференс, а не на вашу машину, — настоящей локальной загрузки через Ollama пока нет. Собственное приложение Unsloth Studio — третий вариант с GUI и автоматическим оффлоадом памяти.
Достаточно ли 2-bit кванта для кодинга?
Для большинства задач кодинг-агента у одиночного разработчика — да. Динамический 2-bit квант Unsloth держит важные слои в более высокой точности и показывает около 82% top-1 точности против полной модели, чего хватает на генерацию кода и рефакторинги. Разрыв вы почувствуете на длинных многошаговых агентных цепочках и тяжёлом рассуждении. Если корректность на них важнее запуска локально — хостинговый план или 4-bit на машине покрупнее будет лучшим выбором.
Теряю ли я контекст 1M при локальном запуске?
По факту да, на потребительском железе. GLM 5.2 поддерживает 1M токенов, но KV-кэш для такого длинного контекста требует сотен гигабайт поверх весов. На машине с 256 GB вы реально работаете на 16K-64K контекста. Квантизация KV-кэша через --cache-type-k q4_1 --cache-type-v q4_1 в llama.cpp растягивает его дальше, ценой небольшой потери качества. Полный 1M оставьте под путь дата-центра.