Запуск 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.
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 GB | 4-bit UD-Q4_K_XL | ~376-475 GB | Лучшее локальное качество, почти без потерь, рабочая скорость кодинга |
| Mac Studio M3 Ultra, 256 GB | 2-bit UD-IQ2_M | ~240 GB | Хорошо пишет код, ~3-9 tok/s, типовая локальная сборка |
| Десктоп + 4090 + 256 GB DDR5 | 2-bit UD-IQ2_M | ~240 GB | Работает через оффлоад, единицы tok/s |
| Стойка 8x H200 или 4x H100 | FP8 / Q4 | 376-750 GB | Production-масштаб, см. гайд по 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 GB | 2-bit UD-IQ2_M | ~3-9 tok/s | Соло кодинг-агент, одна сессия |
| Mac Studio M3 Ultra, 512 GB | 4-bit UD-Q4_K_XL | несколько tok/s, выше качество | Соло-работа, где корректность важнее скорости |
| Десктоп, 4090 + 256 GB DDR5 | 2-bit UD-IQ2_M | единицы | Эксперименты, офлайн |
| Стойка 4x H100 / 8x H200 | Q4 / 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, обе сессии замедлятся до ползка, потому что у потребительского железа нет лишней пропускной способности на разделение. Хитрого флага, который это чинит, не существует.
Два реальных варианта, когда локальный перестаёт масштабироваться:
- Перейти на дата-центровые GPU. Нода 8x H200, обслуживающая FP8, тянет множество параллельных потоков по десятки токенов в секунду каждый. Это другая история по стоимости и эксплуатации, полностью проработанная в гайде по vLLM и стоимости self-host, включая математику точки безубыточности против хостингового плана.
- Использовать хостинговый 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 Pro | deepseek/deepseek-v4-pro | 1M | Нужна более длинная история в комьюнити и опубликованные цифры SWE-bench Verified |
| Kimi K2.6 | moonshotai/kimi-k2.6 | 262K | Нужен независимо отбенчмаркнутый длинный контекст, а не локальный потолок 16K |
| Qwen 3 Coder Next | bailian/qwen3-coder-next | 256K | Многоязычные кодовые базы, где локальная скорость слишком мала для итераций |
Чтобы прочитать GLM по цене и качеству против закрытой модели, прежде чем коммититься на локальное железо или хостинговую подписку, см. сравнение стоимости GLM 5.2 против GPT-5.5.
Источники, проверенные для этого апдейта
- Официальная карточка модели HuggingFace,
zai-org/GLM-5.2(753B параметров, лицензия MIT, контекст 1M), проверено 2026-06-23: https://huggingface.co/zai-org/GLM-5.2 - Community GGUF-кванты Unsloth и таблица памяти по квантам, проверено 2026-06-23: https://huggingface.co/unsloth/GLM-5.2-GGUF
- Руководство Unsloth по запуску GLM 5.2 (размеры квантов, дефолты сэмплинга, флаги KV-кэша, установка Unsloth Studio): https://unsloth.ai/docs/models/glm-5.2
- Проект llama.cpp: https://github.com/ggml-org/llama.cpp
- LM Studio: https://lmstudio.ai
- Парные гайды ofox: железо и стоимость self-host, хостинговый доступ, GLM 5.2 против GPT-5.5 по цене
Интересный сдвиг не в том, что frontier-модель работает локально, а в том, как мало теперь стоит это выяснить. Mac Studio на 256 GB, который у вас уже есть, и вечер на загрузку — вот и весь эксперимент. Дальше стоит следить за FP4 и более плотными динамическими квантами: в день, когда хороший 4-bit опустится ниже 200 GB, локальный порог сдвинется с Mac на 256 GB до машины на 128 GB, и подходящих столов станет куда больше.


