- Дата публикации
GLM-5.1: ИИ, который не выдыхается на длинных задачах
Что появилось / что изменилось
Zhipu AI представила GLM-5.1 — флагманскую модель, заточенную под долгие, многошаговые инженерные задачи.
Главное по цифрам:
- SWE-Bench Pro (сложные задачи промышленной разработки): GLM-5.1 показывает 58,4 балла. Это результат уровня state-of-the-art и шаг вперёд по сравнению с GLM-5 (55,1).
- На задачах генерации репозиториев (NL2Repo) и реальных терминальных сценариях (Terminal-Bench 2.0) GLM-5.1 заметно опережает GLM-5. Точные числа разработчики не раскрывают, но подчёркивают «широкий отрыв».
- В бенчмарке VectorDBBench модель разгоняет векторную базу с 3 547 QPS (лучший прошлый результат у Claude Opus 4.6) до 21,5k QPS при Recall ≥ 95%. Это примерно в 6 раз быстрее, чем лучший односессионный запуск на 50 ходов.
- Для этого GLM-5.1 понадобилось 600+ итераций и 6 000+ вызовов инструментов. Модель продолжала улучшать код и после 100-й попытки.
- В бенчмарке KernelBench (уровень 3) GLM-5.1 достигает 3,6× ускорения GPU-вычислений относительно базовой реализации PyTorch. Для сравнения:
torch.compileдаёт 1,15×, а с max-autotune — 1,49×.
Ключевое изменение: GLM-5.1 не «задыхается» после первых десятков шагов, а сохраняет продуктивность на сотни раундов оптимизации и тысяч вызовов инструментов.
Как это работает
GLM-5.1 проектировали как «агента», который не просто пишет код, а ведёт долгую сессию: планирует, экспериментирует, анализирует метрики и меняет стратегию.
На примере VectorDBBench:
- Модели дают каркас сервиса на Rust с HTTP-API и пустыми заглушками.
- GLM-5.1 через инструментальные вызовы читает и правит файлы, компилирует, запускает тесты и профилирование.
- В классической версии бенчмарка у модели есть лимит в 50 ходов, и большинство систем после этого перестают прогрессировать.
- Команда Zhipu оборачивает задачу во внешний цикл оптимизации: на каждом шаге GLM-5.1 может делать сколько угодно действий, а затем сама решает, когда отправить новую версию на бенчмарк.
Траектория улучшений выглядит как лестница:
- До примерно 90-й итерации модель выжимает максимум из исходного подхода.
- Около итерации 90 GLM-5.1 сама переходит от полного сканирования корпуса к IVF-кластеризации с f16-компрессией векторов и поднимает производительность до 6,4k QPS.
- Около итерации 240 модель перестраивает архитектуру на двухступенчатый пайплайн: предварительное ранжирование векторами
u8, затем уточняющее ранжированиеf16. Результат — 13,4k QPS. - Всего за 600+ итераций происходит шесть крупных архитектурных поворотов, каждый раз после анализа логов бенчмарка и поиска узкого места.
Когда GLM-5.1 пробует новые идеи, Recall иногда падает ниже 95%. Эти «красные крестики» на графике группируются вокруг крупных переходов: модель сознательно ломает текущие ограничения, исследует пространство решений, а затем возвращает метрику в допустимый диапазон.
В KernelBench картина похожая:
- Есть 50 задач трёх типов: отдельные операторы, цепочки операторов и полные модели (MobileNet, VGG, MiniGPT, Mamba).
- GLM-5 быстро набирает улучшение, но рано выходит на плато.
- Claude Opus 4.5 держится чуть дольше, но тоже замедляется.
- GLM-5.1 продолжает находить оптимизации и выходит на 3,6× ускорение по геометрическому среднему.
Фактически под капотом — система, которая не ограничивается одним прогоном, а строит и пересматривает стратегию много раз, используя профилировщики, бенчмарки и собственные логи как обратную связь.
Что это значит для вас
GLM-5.1 рассчитан на тех, кто работает с длинными инженерными циклами, а не только с одноразовыми промптами.
Где модель особенно полезна:
- Оптимизация инфраструктуры и низкоуровневого кода. Если вы разгоняете векторные базы, пишете поисковые движки, работаете с SIMD и GPU — GLM-5.1 может выступать «сопроцессором», который неделями крутится в фоне и постепенно улучшает производительность.
- Автоматизация сложных ML-пайплайнов. KernelBench показывает, что модель умеет трогать не только отдельные ядра, но и целые архитектуры: MobileNet, VGG, MiniGPT, Mamba.
- Долгие агентные сессии. Если вы строите своих ИИ-агентов, которые должны жить часами, править репозиторий, запускать тесты и профилирование — GLM-5.1 как раз под такие сценарии.
- Исследовательские прототипы. Модель удобно использовать как «автооптимизатор» для внутренних библиотек и сервисов, где важен не один красивый коммит, а месяцы постепенных улучшений.
Где ожидания лучше снизить:
- Разовые запросы «напиши скрипт» или «объясни код» GLM-5.1 тоже умеет, но его сильная сторона — именно длинные сессии.
- Если вам важна полная воспроизводимость и жёсткий контроль над каждым шагом, многоходовые агентные сценарии придётся тщательно обвязывать логированием и ограничениями.
- Для бытового использования вроде «сочинить текст» или «ответить на письмо» есть более простые и дешёвые модели.
О доступности для России и необходимости VPN разработчики в материале не уточняют, поэтому к GLM-5.1 стоит относиться как к инструменту уровня облачного сервиса: возможны геоограничения и нюансы с регистрацией.
Место на рынке
По тестам GLM-5.1 играет в одной лиге с крупными моделями от OpenAI и Anthropic.
- На SWE-Bench Pro рядом с GLM-5.1 (58,4) находятся GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro и GLM-5. Точные их баллы разработчики не приводят, но GLM-5.1 держится на уровне лучших.
- В VectorDBBench предыдущий рекорд 3 547 QPS принадлежал Claude Opus 4.6. GLM-5.1 выходит на 21,5k QPS при тех же условиях по Recall — это серьёзный зазор.
- В KernelBench Level 3 по скорости относительно базовой реализации PyTorch:
torch.compile— 1,15×;torch.compileс max-autotune — 1,49×;- GLM-5.1 — 3,6×.
Цены, скорость отклика и максимальный контекст авторы не раскрывают, поэтому сравнивать экономику запросов с GPT-5 или Claude Opus честно нельзя.
Позиционирование у GLM-5.1 достаточно чёткое: это не просто «ещё одна LLM», а инструмент для тех, кто готов доверить модели долгую, многошаговую оптимизацию кода и инфраструктуры. Если вы строите агентные системы, которые должны не уставать на сотнях итераций, GLM-5.1 — один из немногих кандидатов, который демонстрирует реальный прогресс на таких дистанциях.