Z.ai выпустила GLM‑5.1 и делает ставку на «длинные» агентные сценарии — когда модель не просто отвечает, а много шагов подряд улучшает решение. В примерах разработчики показывают ускорение в задачах векторного поиска и GPU‑оптимизаций, а также демонстрируют многочасовую сборку веб‑приложения без стартового кода.
Z.ai представила GLM‑5.1 — новое поколение модели, которое компания позиционирует как более сильное именно для задач разработки и агентной работы. Ключевая идея релиза — не столько «первый ответ», сколько способность оставаться полезной в длинной цепочке действий, где нужно пробовать, измерять результат и менять стратегию.
Что заявляют про качество на бенчмарках
По данным, которые публикует Z.ai, GLM‑5.1 улучшила результаты в задачах, близких к реальной инженерной работе: где нужно разбираться в репозиториях, выполнять команды в терминале и доводить решение до состояния «работает и проходит проверки». В материале упоминаются, в частности, SWE‑Bench Pro, NL2Repo и Terminal‑Bench 2.0 — тесты, ориентированные на практику программирования и взаимодействие с окружением.
Почему акцент сместили на «длинные» сценарии
Разработчики описывают типичную проблему многих моделей: сначала они быстро улучшают результат, но затем «упираются в потолок» — даже если дать больше времени и разрешить делать больше шагов. В GLM‑5.1, по заявлению Z.ai, сделали упор на режим, где модель может долго вести задачу: дробить проблему на части, запускать эксперименты, анализировать логи и возвращаться с корректировками в следующей итерации.
Три демонстрационных сценария: что именно показывали
1) Векторный поиск: оптимизация в сотнях итераций
В первом сценарии Z.ai использовала открытый бенчмарк VectorDBBench: модели дают заготовку на Rust, а цель — собрать и ускорить векторную базу для приближённого поиска ближайших соседей. В «стандартной» постановке теста обычно ограничивают число инструментальных вызовов (чтение/правка файлов, сборка, тесты, профилирование) — и приводят ориентир лучшего результата в режиме короткой сессии.
В демонстрации Z.ai сняла жёсткий лимит на длину цикла и дала модели самостоятельно решать, когда фиксировать очередной результат и что пробовать дальше. В итоге, как описано в материале, GLM‑5.1 провела более 600 итераций и сделала 6000+ вызовов инструментов, увеличив показатель до 21,5 тыс. QPS (при сохранении условия по Recall), то есть примерно в шесть раз относительно лучшего результата, который упоминается для стандартного «короткого» режима.
Важно, что ускорение, по описанию авторов, происходило не только «подкручиванием параметров»: модель несколько раз меняла структуру решения. Среди перечисленных шагов — переход от полного сканирования к IVF‑кластеризации с f16‑сжатием, а затем к двухэтапному поиску с u8‑предотбором и f16‑переранжированием.
2) GPU‑ядра: серия попыток вместо одной «магической» оптимизации
Во втором сценарии использовали KernelBench: это проверка, может ли модель ускорить выполнение GPU‑ядра для эталонной реализации на PyTorch, не меняя результат вычислений. В качестве ориентира приводятся результаты автоматических оптимизаций (torch.compile), а для GLM‑5.1 — среднее ускорение в 3,6× в длинной серии итераций.
При этом в материале отдельно отмечено сравнение с другими моделями на траектории оптимизации: у одних прирост быстро замедляется, у других держится дольше. Лучший итоговый результат в этом сценарии, по описанию авторов, показал Claude Opus 4.6 — 4,2×.
3) «Рабочий стол» в браузере: когда нет строгой метрики
Третий пример — намеренно менее формализованный. Задача звучала как сборка веб‑приложения в виде Linux‑подобного рабочего стола прямо в браузере: без стартового кода, макетов и промежуточных подсказок. Авторы подчёркивают, что многие модели в таком формате быстро останавливаются на каркасе (панель задач и несколько окон‑заглушек).
В случае GLM‑5.1, как описывает Z.ai, добавили внешний цикл самопроверки: после каждого этапа модель оценивает, что получилось, отмечает поломки и недостающие функции и продолжает доводку. Процесс занял около восьми часов, а среди появившихся компонентов перечислены файловый менеджер, терминал, текстовый редактор, системный монитор, калькулятор и игры. Этот кейс используют как иллюстрацию: ценность даёт не просто «дольше работать», а уметь оставаться продуктивной, когда задача разрастается и усложняется.
Что это даёт обычным командам разработки
- Меньше «одноразовых» ответов: если модель действительно держит длинную цепочку действий, она может быть полезнее там, где нужна серия измеримых улучшений (производительность, тесты, профилирование), а не единичная подсказка.
- Лучше для задач «с обратной связью»: примеры построены вокруг циклов «изменил → собрал/прогнал → посмотрел метрики → исправил». Это ближе к рабочей рутине инженеров, чем генерация куска кода в вакууме.
- Понятнее ограничения: сами авторы признают, что длинная оптимизация остаётся сложной зоной — из‑за локальных оптимумов, потери целостности в длинных цепочках и трудностей самооценки без формальной метрики качества.
Доступность
GLM‑5.1, как указано в публикации, выложена в открытый доступ под лицензией MIT. Также модель доступна через платформы api.z.ai и BigModel.cn; совместимость заявлена с инструментами вроде Claude Code и OpenClaw.
