Z.ai представила GLM-5.1 — новое флагманское поколение своей модели для агентной разработки. По заявлению компании, модель заметно прибавила именно в задачах программирования по сравнению с предыдущей версией.
Судя по опубликованным результатам, GLM-5.1 показывает лучший на текущий момент результат на SWE-Bench Pro, а также с большим отрывом опережает GLM-5 на NL2Repo, где оценивается генерация репозиториев, и на Terminal-Bench 2.0, который проверяет работу модели в реальных терминальных сценариях.
Разработчики делают акцент не только на качестве первого ответа, но и на работе модели вдолгую. По их словам, многие предыдущие модели, включая GLM-5, быстро упираются в потолок: сначала дают быстрый прирост, а затем почти перестают улучшать результат, даже если дать им больше времени.
GLM-5.1, как утверждает Z.ai, лучше приспособлена к длинным агентным сценариям. Модель дольше сохраняет продуктивность в многошаговых задачах: разбивает проблему на части, проводит эксперименты, анализирует результаты, находит ограничения и корректирует стратегию по ходу работы. За счет этого она может улучшать решение на протяжении сотен итераций и тысяч вызовов инструментов.
Этот подход компания показывает на трех типах задач: оптимизации векторного поиска с одной числовой метрикой, бенчмарке GPU-ядер с измеряемым ускорением и открытой задаче по созданию веб-приложения, где модель сама определяет, что именно стоит улучшать дальше.
Сценарий 1: Оптимизация векторной базы данных за 600 итераций
В первом сценарии разработчики взяли VectorDBBench — открытый бенчмарк, где модели нужно по заготовке на Rust собрать производительную векторную базу для приближенного поиска ближайших соседей. В стандартной версии теста на чтение и правку файлов, сборку, тесты и профилирование дается 50 вызовов инструментов, а итог оценивается на SIFT-1M по QPS при Recall не ниже 95%. Лучший результат в таком режиме ранее составлял 3547 QPS.
Z.ai проверила, что будет, если убрать жесткий лимит и дать модели работать в длинном цикле оптимизации. В этой постановке GLM-5.1 сама решала, когда отправлять новую версию на замер и что пробовать дальше. В итоге модель не вышла на плато ни после 50, ни после 100 попыток: более чем за 600 итераций и 6000+ вызовов инструментов она довела результат до 21,5 тыс. QPS, то есть примерно в шесть раз выше лучшего результата в стандартной 50-шаговой сессии.
По описанию авторов, прогресс шел не равномерно, а скачками: периоды точечной настройки сменялись более крупными архитектурными изменениями. Среди ключевых переходов — смена полного сканирования на IVF-кластеризацию с f16-сжатием, а затем переход к двухэтапному поиску с u8-предварительным отбором и f16-переранжированием. Всего за время прогона модель сделала шесть таких структурных перестроек, каждый раз опираясь на анализ собственных логов и поиск текущего узкого места.
Сценарий 2: Оптимизация рабочей нагрузки машинного обучения на протяжении более 1000 ходов
Во втором сценарии авторы использовали KernelBench — бенчмарк, который проверяет, может ли модель взять эталонную реализацию на PyTorch и получить более быструю реализацию GPU-ядра без изменения результата вычислений. Самый сложный уровень теста включает 50 задач на сквозную оптимизацию полноценных моделей, включая MobileNet, VGG, MiniGPT и Mamba.
Для ориентира авторы приводят результаты torch.compile: 1,15× ускорения с настройками по умолчанию и 1,49× в режиме max-autotune. На этом фоне GLM-5.1 в длинной серии итераций показала среднее ускорение в 3,6×. При этом, как отмечают разработчики, GLM-5 быстро прибавляет в начале, но рано выходит на плато, Claude Opus 4.5 держится дольше, но тоже замедляется, а GLM-5.1 сохраняет полезную динамику оптимизации заметно дольше. Лучший итоговый результат в этом сценарии остался за Claude Opus 4.6 — 4,2× ускорения.
Сценарий 3: создание Linux-подобного рабочего стола за 8 часов
Третий сценарий был уже без явной числовой метрики. Разработчики дали модели амбициозную задачу: собрать в браузере веб-приложение в виде Linux-подобного рабочего стола, без стартового кода, макетов и промежуточных подсказок. Как отмечают авторы, большинство моделей в такой постановке быстро останавливаются на базовом каркасе с панелью задач и парой окон-заглушек.
Для GLM-5.1 добавили внешний цикл самопроверки: после каждого этапа модель анализировала собственный результат, находила недостающие функции, проблемы со стилем и сломанные взаимодействия, а затем продолжала дорабатывать проект. Этот процесс продолжался восемь часов.
По итогам, если верить описанию Z.ai, модель прошла путь от простого макета до полноценной и визуально цельной среды, работающей в браузере. В интерфейсе постепенно появились файловый менеджер, терминал, текстовый редактор, системный монитор, калькулятор и игры, а сама среда стала заметно аккуратнее по стилю и поведению. Авторы используют этот пример как иллюстрацию своей основной идеи: важно не только то, сколько времени работает модель, но и остается ли это время продуктивным. При этом они признают, что длинная оптимизация все еще остается открытой задачей — в том числе из-за проблем с выходом из локальных оптимумов, удержанием целостности в длинных цепочках действий и самооценкой там, где нет формальной метрики качества.
GLM-5.1 выложена в открытый доступ под лицензией MIT. Модель также доступна через платформы api.z.ai и BigModel.cn и, по заявлению разработчиков, совместима с инструментами вроде Claude Code и OpenClaw.
Источник: z.ai
Если тема агентных систем и инженерных задач в ИИ откликается, можно посмотреть, как похожие задачи решаются на практике — от векторного поиска до архитектуры высоконагруженных AI-сервисов.
9 апреля 20:00. «PostgreSQL как векторная база данных: ИИ-поиск без лишних сервисов». Записаться
16 апреля 20:00. «Архитектура ИИ-сервисов для High-Load и Low-Latency инференса». Записаться
