GLM 5.2 на своём железе в 2026: оборудование, vLLM и сравнение цен с облаком

Релиз GLM 5.2 от Zhipu — это не просто очередной API. На этой неделе на HuggingFace выложили веса под лицензией MIT, и впервые frontier-модель класса 1M-контекста для кода можно реально скачать, проаудитить и запустить на собственном железе. Загвоздка в самом железе: 753B параметров под стол не влезают.

Что вы получаете, ставя GLM 5.2 у себя (короткий ответ за 30 секунд)

Ранние сторонние сигналы: бенчмарки + Code Arena Frontend

Zhipu выложил полную таблицу собственных бенчмарков прямо в релизе (см. README по адресу github.com/zai-org/GLM-5). Цифры, важные для решения по self-host:

(* = с инструментами / раскрытыми вариациями harness — см. сноски в исходной таблице.) GLM 5.2 отстаёт от Opus 4.8 по чистому SWE-bench Pro (62.1 против 69.2), но обгоняет на «Best Reported Harness» в Terminal-Bench 2.1 (82.7 против 78.9) и на агентной математике (AIME 99.2 против 95.7). Чего нет в публичном наборе: SWE-bench Verified, LiveCodeBench и Aider polyglot — три канонических бенчмарка для агентного кода, на которые обычно опирается open-weights-сообщество.

Две независимые сторонние таблицы от The Intelligence Company дали сигнал за 72 часа. На композите DesignArena Web Dev (Non-Agentic) GLM 5.2 на первом месте (Elo 1360, впереди Claude Fable 5 с 1350 и всего стека Claude Opus 4.6 / 4.7 / 4.7-Thinking). На отдельно хостящемся срезе Code Arena Frontend от Arena Intelligence — второе место (Elo 1595, позади Claude Fable 5 с 1654, у которого на этой странице явная пометка «not currently being sampled»).

Два угла на эти данные:

• Для решения по self-host: GLM 5.2 закрывает почти весь разрыв с Opus 4.8 в собственной таблице Zhipu и держится впереди GPT-5.5 на код-ориентированных эвалах, а на слепом голосовании DesignArena по web-dev — это вообще модель №1 в общем зачёте, обходящая все активно сэмплируемые версии Claude Opus в той же таблице. Отрыв от остального open-weights поля (Qwen 3.7 Max — 1310, Kimi K2.6 — 1328, GLM 5.1 — 1332) составляет 30–50 Elo на композите и 60+ Elo на frontend-срезе. Если вы уже выбирали open-weights под продакшен для кодинга, GLM 5.2 только что обогнал поле
• Для скептика: вендорская таблица бенчмарков остаётся вендорской — harness выбирал Zhipu. DesignArena меряет попарное слепое предпочтение на web-dev-выходах, а не end-to-end pass rate на отложенной выборке, а звёздочка на Fable 5 во frontend-срезе напоминает, что «ранг» может прыгнуть при возобновлении сэмплирования. Воспринимайте оба сигнала как сильные leading indicators, а не как замену собственным эвалам на своём коде

Когда self-host действительно ответ

Этот раздел позволяет закрыть пост и не читать остальное.

Когда GLM 5.2 стоит хостить у себя

• Data residency — код или промпты клиентов не имеют права покидать ваш VPC, регион или периметр железа
• Кастомный файнтюн — нужны LoRA или полный fine-tune на собственной кодовой базе, а хостинг такого API не даёт
• Air-gapped развёртывание — стенды, заводы, оборонка, изолированные сети, где любой исходящий трафик на api.z.ai уже non-starter
• Высокий устойчивый поток — вы выжигаете ≥3000 промптов/день, где амортизированное железо побеждает облачную ставку за промпт

Когда self-host НЕ ваш ответ

• Вы соло-разработчик или команда из двух человек. Pro Coding Plan у Z.ai за ~$30/мес покрывает ваш профиль за 1% от стоимости ноды 8x H200 в режиме 24/7. Читайте гайд по хостинг-доступу вместо этого
• У вас в продакшене ещё нет vLLM или SGLang. Стартовая стоимость (драйверный цикл, тюнинг KV-кэша, observability) — реальная и не отбивается минимум квартал
• Вам нужны именно благословлённые вендором цифры SWE-bench Verified, LiveCodeBench или Aider polyglot. Опубликованная таблица Zhipu покрывает SWE-bench Pro (62.1), Terminal-Bench 2.1 (81.0 / 82.7 best-harness), AIME 2026 (99.2), GPQA-Diamond (91.2), MCP-Atlas (76.8) и далее — таблица выше — но трёх бенчмарков, на которые опирается open-weights-сообщество при сравнении агентного кода, в ней пока нет. Независимых дельт качества по FP8 тоже ждать ещё несколько дней

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

Если ваш пик — меньше 100 промптов/день и нет compliance-требования, которое исключает хостинг, не хостите сами. Берите Coding Plan, экономьте квартал инженерного времени и возвращайтесь, когда сработает один из четырёх триггеров выше.

Что реально доступно в день релиза

flowchart LR
  HF[huggingface.co/zai-org] --> BF16[GLM-5.2 BF16<br/>~1.5 TB]
  HF --> FP8[GLM-5.2-FP8<br/>~750 GB]
  US[huggingface.co/unsloth] --> GGUF[GLM-5.2-GGUF<br/>Q4 376 GB / Q2 241 GB]
  BF16 --> vLLM[vLLM 0.23+]
  FP8 --> vLLM
  FP8 --> SGLang[SGLang 0.5.13+]
  GGUF --> Llama[llama.cpp]
  GGUF --> LMS[LM Studio]

Замечание про тег Ollama: на 17 июня 2026 запись glm-5.2:cloud на ollama.com/library/glm-5.2 — только облачная (суффикс :cloud маршрутизирует через хостинг Ollama, не на ваше железо). Тегов glm-5.2:latest или локального квантованного варианта в официальной библиотеке Ollama пока нет. Если хочется именно ollama-style эргономики для локального инференса, поднимите llama.cpp с Unsloth GGUF и оберните в Ollama-совместимый прокси.

Ещё стоит отметить: репозиторий Unsloth GGUF выложили за несколько часов до публикации этого поста; конкретные размеры файлов по квантам в UI HuggingFace на момент проверки ещё не показывались. Диапазон 188–376 GB выше посчитан по чистой арифметике битов-на-вес (188 GB при 2-bit, 376 GB при 4-bit на 753B параметров). Реальные размеры на диске могут оказаться на 10–20% больше из-за overhead — смотрите вкладку «Files and versions» перед загрузкой.

Сайзинг железа по уровню квантизации

Правильный уровень определяется тем, что влезает в VRAM после загрузки весов. KV-кэш — тихий убийца на контексте 1M.

Несколько правил, как применять эту таблицу:

• Оставляйте 20% запаса VRAM сверх суммы весов и KV. CUDA-фрагментация съест остаток, и отлаживать OOM на 90% prefill при запросе на 900K токенов вам точно не нужно
• KV-кэш растёт линейно с длиной контекста. Числа на 256K выше — иллюстративные; на 1M ждите ~4x по KV. Для продакшена на 1M почти всегда нужен FP8 KV (--kv-cache-dtype fp8 в vLLM)
• GGUF на llama.cpp использует RAM хоста, а не VRAM — M3 Ultra работает потому, что его 256 GB UMA адресуются и CPU, и GPU. Рабочая станция с 256 GB DDR5 и GPU на 24 GB делает то же самое, только медленнее

Настройка vLLM (FP8 на 8x H200)

Этот путь выберет большинство продакшен-команд. vLLM v0.23.0 — минимум; патч-релизы выше дают прирост throughput, но FP8-путь GLM 5.2 работает уже на 0.23 GA.

Шаг 1: скачать веса

# Около 750 GB; на 10 GbE заложите 30–60 минут
huggingface-cli download zai-org/GLM-5.2-FP8 \
  --local-dir /models/glm-5.2-fp8 \
  --local-dir-use-symlinks False

Ожидаемый результат: 750 GB safetensors-шардов плюс config в /models/glm-5.2-fp8. Проверьте через du -sh /models/glm-5.2-fp8 и убедитесь, что в директории есть config.json и *.safetensors.index.json.

Шаг 2: запустить vLLM-сервер

vllm serve "zai-org/GLM-5.2-FP8" \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching \
  --port 8000

Зачем эти флаги:

• --tensor-parallel-size 8 шардит 753B весов по 8 GPU. На H200 у вас 1,13 TB суммарной HBM — комфортно под FP8-веса плюс рабочий KV-кэш
• --max-model-len 262144 стартует с 256K контекста. Поднимайте до 1048576 (1M) только после прогонов под реальную нагрузку, чтобы оценить давление KV-кэша
• --kv-cache-dtype fp8 режет KV-кэш вдвое относительно дефолтного BF16, и это разница между 256K и 128K контекста на параллельный запрос
• --enable-prefix-caching переиспользует посчитанный KV для общих префиксов промпта — обязательная вещь для кодинг-агентов, которые гоняют один и тот же системный промпт сотни раз

Ожидаемый результат: в логах vLLM появится Available KV cache memory: X GB и Maximum concurrency for Y tokens: Z requests в течение ~3–5 минут после старта. Первый запрос займёт 30–90 секунд (компиляция + прогрев KV-кэша); последующие — субсекундно на коротких промптах.

Шаг 3: smoke-тест

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

Ожидаемый результат: OK или OK. за ~1 секунду. Если приходит 500 с out of memory или device-side assert, бюджет KV-кэша слишком тесен под выбранную длину — сбросьте --max-model-len до 131072 и повторите.

Настройка SGLang (FP8, RadixAttention)

SGLang — альтернативный продакшен-движок, и он обычно выигрывает по throughput на длинных контекстах, когда у вас тяжёлое переиспользование префиксов (многоходовые кодинг-агенты, RAG со стабильными system-промптами).

python -m sglang.launch_server \
  --model-path zai-org/GLM-5.2-FP8 \
  --tp 8 \
  --context-length 262144 \
  --kv-cache-dtype fp8_e4m3 \
  --enable-mixed-chunk \
  --port 30000

RadixAttention в SGLang — главный выигрыш на длинном контексте: для кодинг-агента, который переиспользует 100K токенов системного промпта на каждом ходе, вы увидите ~3x запросов в секунду против vLLM 0.23 на том же железе. Цена — чуть выше инженерная поверхность (у RadixAttention своя история с observability).

Путь llama.cpp / Mac Studio (Q4 или Q2 GGUF)

Для возни, разработки прямо на ноутбуке или single-node air-gapped развёртывания llama.cpp с GGUF-квантами от Unsloth — самый дешёвый путь к «GLM 5.2 уже работает».

# Скачать 4-битный квант — подставьте имя файла под тот шард Q4_K_M, который опубликован
huggingface-cli download unsloth/GLM-5.2-GGUF \
  GLM-5.2-Q4_K_M.gguf \
  --local-dir /models/glm-5.2-gguf

# Собрать llama.cpp с CUDA (на Mac пропустите — Metal соберётся автоматически)
cmake -B llama.cpp/build -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j

# Поднять OpenAI-совместимый API на порту 8080
./llama.cpp/build/bin/llama-server \
  --model /models/glm-5.2-gguf/GLM-5.2-Q4_K_M.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 999 \
  --host 0.0.0.0 --port 8080

На M3 Ultra Mac Studio с 256 GB unified memory 2-bit UD-IQ2_XXS даёт ~3–9 токенов/сек в зависимости от длины контекста. Хватит для соло-работы с кодинг-агентом; не хватит для команды разработчиков. Для максимальной интерактивности на Mac сбросьте --ctx-size до 16K.

Цена: self-host против Z.ai Coding Plan

Утверждение «self-host экономит деньги» почти всегда ложно. Вот математика на ценах облака июня 2026.

Точки безубыточности, которые стоит знать:

• Хостинг Pro против своего M3 Ultra: M3 Ultra выигрывает по амортизированной цене выше ~$30/мес хостинговой нагрузки, но только если 3–9 токенов/сек устраивает ваш рабочий процесс
• Хостинг Max против облачного 8x H200: нужно ~3000+ промптов/день и ~30%+ загрузки H200-ноды, чтобы облако обошло хостинг за $80/мес. Это команда из 20 разработчиков, постоянно гоняющая кодинг-агентов
• Свои 8x H200: побеждают по цене выше ~10000 промптов/день только если у вас реально есть дата-центровая ёмкость и операционная команда. Для большинства компаний это полугодовой цикл закупки до первого промпта

Закономерность: хостинг побеждает у 95% команд. Self-host выигрывает у тех 5%, у кого compliance, residency или устойчивый throughput перевешивают цену.

Частые ошибки при self-host-настройке

Когда self-host — неправильный ответ: альтернативы на ofox

Если математика self-host не сходится, но всё же хочется китайскую coding-модель за одним OpenAI-совместимым эндпоинтом, ofox перечисляет три альтернативы, доступных в день релиза (сверено 17 июня 2026 по каталогу ofox.ai/en/models):

Та же форма обвязки, что и для self-host-эндпоинта — меняется только base URL и model ID:

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="ofox-..."
export OPENAI_MODEL="deepseek/deepseek-v4-pro"

GLM 5.2 пока не числится в каталоге ofox на 17 июня 2026. Когда модель появится, переход с deepseek-v4-pro на будущий z-ai/glm-5.2 — это смена одной строки в этом конфиге. По хостинг-пути через Z.ai сегодня смотрите парный гайд по доступу к GLM 5.2 — там форма эндпоинта Z.ai Coding Plan, API-ключи и та же модель на официальном Anthropic-совместимом эндпоинте для пользователей Claude Code.

Observability, которую стоит иметь с первого дня

Три сигнала на продакшен-self-host GLM 5.2 не подлежат обсуждению:

• Tokens-per-second под нагрузкой — следите за p50 и p95 отдельно: один запрос с 900K контекста может утянуть p99 на порядок
• Утилизация KV-кэша — vLLM отдаёт vllm:gpu_cache_usage_perc на /metrics; как только устойчиво пробивается 90%, throughput схлопывается
• Total tokens на запрос — кодинг-агенты дрейфуют в сторону прожига токенов на бесцельных рефакторингах; инструментируйте на уровне PR или сессии, чтобы поймать ушедший в петлю агент до того, как он съест бюджет

Прикрутите это к тому стеку, который у вас уже есть (Datadog, Honeycomb, Grafana — выберите один, не строите четвёртый). Для SGLang эквивалентные метрики живут на /metrics_collect.

Что проверяли при подготовке материала

• Официальная карточка модели HuggingFace — https://huggingface.co/zai-org/GLM-5.2 (сверено 17 июня 2026: 753B параметров, GLM MoE DSA, IndexShare, MTP, vLLM 0.23+ / SGLang 0.5.13+)
• Карточка FP8-модели HuggingFace — https://huggingface.co/zai-org/GLM-5.2-FP8 (сверено 17 июня 2026: F8_E4M3 поддерживается, пример vllm serve)
• README репозитория GLM-5 от Zhipu — https://github.com/zai-org/GLM-5 (сверено 17 июня 2026: полная таблица бенчмарков, включая SWE-bench Pro 62.1, Terminal-Bench 2.1 = 81.0 / Best-Harness 82.7, AIME 2026 99.2, GPQA-Diamond 91.2, MCP-Atlas 76.8, флаг reasoning_effort)
• Лидерборд DesignArena — https://www.designarena.ai/leaderboard (сверено 17 июня 2026: композит Web Dev Non-Agentic — GLM 5.2 на 1-м месте, Elo 1360, впереди Claude Fable 5 с 1350 и семейства Claude Opus 4.6/4.7. Управляется The Intelligence Company)
• Arena Intelligence Code Arena Frontend — https://arena.ai/leaderboard/code (сверено 17 июня 2026: GLM 5.2 Max на 2-м месте, Elo 1595; Claude Fable 5 на 1-м с явной пометкой «not currently being sampled». Домен отличается от DesignArena выше, также под брендом Arena Intelligence)
• Страница библиотеки Ollama — https://ollama.com/library/glm-5.2 (сверено 17 июня 2026: существует только тег glm-5.2:cloud; локального кванта в официальной библиотеке нет)
• Комьюнити-кванты Unsloth GGUF — https://huggingface.co/unsloth/GLM-5.2-GGUF (сверено 17 июня 2026: репозиторий опубликован, шарды квантов подъезжают на выходных)
• Снимок каталога моделей ofox — https://ofox.io/en/models (сверено 17 июня 2026: GLM 5.2 ещё не указан; подтверждены z-ai/glm-5.1, deepseek/deepseek-v4-pro, moonshotai/kimi-k2.6, bailian/qwen3-coder-next)
• Парный гайд по доступу на ofox — https://ofox.io/ru/blog/glm-5-2-access-guide-2026/ (сверено 17 июня 2026; покрывает хостинг-путь Z.ai Coding Plan)
• Тред обсуждения на Reddit r/LocalLLaMA — https://www.reddit.com/r/LocalLLaMA/comments/1u7o9vp/glm_52_api_is_live_weights_are_on_hf_and_ollama/ (комьюнити-сигнал по выкладке весов; Reddit блокирует наш автоматический fetcher, так что откройте ссылку и почитайте тред руками)
• Кросс-проверки на PyPI (сверено 17 июня 2026): pypi.org/pypi/transformers/json → последний 5.12.1; pypi.org/pypi/ktransformers/json → последний 0.6.2.post4 (релиза 0.5.12 не существует, поэтому upstream-строка «v0.5.12+» считается приблизительной)

Самое интересное в этом релизе — не контекст 1M и не FP8-сборка, а то, что впервые open-weights frontier-модель с реальной репутацией на коде влезает в закупочный бюджет средней исследовательской лаборатории. Следующие 90 дней покажут, сможет ли комьюнити выкатить FP4-кванты и снизить продакшен-стойку с 8x H200 до 4x H100. Если получится — математика self-host перевернётся.