Китайский ИИ GLM-5.1 разбил GPT в щепки. Весь фокус: он кодит 8 часов без тормозов

Китайская Z.ai выпустила в опенсорс GLM–5.1, и релиз получился громким не из–за общих обещаний, а из–за очень конкретных результатов. Новую модель позиционируют как флагман для агентной разработки, то есть для задач, где ИИ не просто дописывает пару строк, а сам читает проект, правит файлы, запускает сборку, тесты и профилирование, разбирает ошибки и часами дожимает решение.

По данным компании, на SWE–Bench Pro модель набрала 58,4 балла и обошла GPT–5.4 с 57,7, Claude Opus 4.6 с 57,3 и Gemini 3.1 Pro с 54,2. Для китайской модели это особенно заметный результат: разработчики прямо говорят, что GLM–5.1 вышла в лидеры на одном из самых жёстких тестов для реальных инженерных задач.

Но главный акцент в релизе сделан не на сухой таблице, а на другом. Разработчики утверждают, что обычные модели быстро снимают первые улучшения, а потом начинают буксовать: знакомые приёмы закончились, прогресс почти встал. GLM–5.1, по их версии, устроена иначе. Она дольше остаётся полезной на длинных автономных задачах, может много раз пересматривать собственный план, менять стратегию, проверять гипотезы и продолжать улучшения там, где более ранние системы уже выдохлись.

Самый эффектный пример - задача по сборке веб–приложения в виде рабочего стола Linux. Модели дали амбициозный запрос, но не дали ни стартового кода, ни макетов, ни промежуточных подсказок. В короткой сессии многие системы, включая прошлые версии GLM, обычно доходят только до каркаса: простая панель задач, пара окон–заглушек и на этом всё. GLM–5.1 запустили в цикле самопроверки на 8 часов. После каждого этапа модель смотрела на собственный результат, искала слабые места и решала, что улучшать дальше.

В итоге, в браузере появился уже не набросок, а полноценный рабочий стол с файловым менеджером, терминалом, текстовым редактором, системным монитором, калькулятором и играми. Причём всё это не выглядело как набор случайных модулей: разработчики отдельно подчёркивают цельный интерфейс, более аккуратный стиль, доработанные взаимодействия и обработку пограничных случаев.

Второй показательный кейс касается VectorDBBench - открытого испытания для оптимизации векторной базы данных. Задача выглядит так: модели дают каркас на Rust с HTTP API и пустыми заглушками, а дальше она сама должна писать код, собирать проект, тестировать его и искать узкие места. Финальный результат оценивают по числу запросов в секунду на наборе SIFT–1M, но с жёстким условием: полнота поиска должна оставаться не ниже 95%. В стандартной короткой сессии прежний лучший результат составлял 3547 QPS, и его держала Claude Opus 4.6. GLM–5.1 запустили уже не на 50 ходов, а в длинном внешнем цикле оптимизации, где она сама решала, когда отправлять новую версию на проверку и что пробовать дальше.

И здесь начинается самое интересное. Алгоритм не остановился ни после 50, ни после 100 попыток. Оптимизация тянулась более 600 итераций и потребовала свыше 6000 вызовов инструментов. Финальная производительность выросла до 21 500 запросов в секунду, то есть примерно в 6 раз выше прежнего лучшего результата для короткого прогона. Рост шёл не плавно, а рывками. Сначала модель долго выжимала мелкие улучшения из текущего подхода, потом находила структурное изменение и резко перескакивала на новый уровень. Около 90–й итерации она ушла от полного сканирования базы к кластерному поиску IVF и добавила сжатие векторов до f16, после чего производительность выросла до 6400 QPS.

Примерно к 240–й итерации появилась двухэтапная схема: сначала грубая предварительная оценка в формате u8, потом более точное ранжирование в формате f16. После этого результат поднялся до 13 400 QPS. Всего за весь прогон таких крупных перестроек было 6. Каждый раз ИИ сначала нащупывал новое направление, иногда временно проваливался ниже порога полноты поиска в 95%, а затем докручивал параметры и возвращался в допустимые рамки.

Ещё один важный тест - KernelBench, в котором нужно не просто написать код, а ускорить вычисления на графическом процессоре без изменения результата. Здесь GLM–5.1 получала эталонную реализацию на PyTorch и должна была выдать более быстрое ядро. На самом сложном уровне, где проверяются уже не отдельные операции, а целые архитектуры вроде MobileNet, VGG, MiniGPT и Mamba, модель дошла до среднего ускорения в 3,6 раза.

Это заметно лучше, чем у GLM–5, которая выдыхалась раньше, но не лучший результат в абсолюте: Claude Opus 4.6 закончила прогон на 4,2 раза и к финалу ещё не упёрлась в потолок. Разработчики это признают прямо.

На других тестах картина уже не такая однозначная, и это даже полезно для понимания, что именно здесь пытаются продавать. GLM–5.1 не подаётся как безусловный чемпион во всём подряд. Её сильная сторона, судя по релизу, не абстрактное лидерство в любой олимпиадной логике, а более приземлённый инженерный режим: читать код, работать через инструменты, возвращаться к задаче снова и снова и не терять связность после сотен шагов. Поэтому в релизе так много внимания уделено не красивым разовым победам, а тому, что модель якобы умеет часами не разваливаться на длинной задаче.

Технически GLM–5.1 выпустили под лицензией MIT. Веса выложили на HuggingFace и ModelScope, для локального запуска заявлена поддержка vLLM и SGLang. Модель совместима с Claude Code и OpenClaw, доступна через api.z.ai и BigModel.cn, а подписчикам Coding Plan её уже начали раскатывать. Есть и практическая оговорка: как самая сильная модель в линейке, GLM–5.1 расходует квоту быстрее. В часы пик расход идёт с коэффициентом 3, в непиковое время с коэффициентом 2, хотя до конца апреля непиковые часы обещают считать по обычной ставке.