GLM-4.7 — это не очередная большая модель «для разговоров», а попытка переосмыслить, какой должна быть основа для coding-агентов и инженерных AI-контуров. Z.ai (Zhipu AI) выпустила её 22 декабря 2025 года без громкой кампании, но с набором цифр, которые трудно игнорировать, если вы работаете с кодом, инструментами и длинным контекстом. Модель позиционируется как ядро агентных систем: с терминалом, вызовом функций и многошаговыми действиями. Сразу уточним: в API GLM-4.7 остаётся текстовой моделью, а все «мультимодальные» истории относятся к платформе и обвязке. Ниже — спокойный разбор без маркетинга: что она умеет, где сильна и где у неё границы.
Кому пригодится этот разбор
Материал рассчитан на тех, кто использует LLM как рабочий инструмент и принимает по нему инженерные решения:
- ML/LLM-инженеры, выбирающие модель под кодинг, агентов и длинный контекст;
- техлиды и архитекторы, встраивающие LLM в SDLC и корпоративные системы;
- разработчики IDE-плагинов и агентных приложений с tool use и терминалом;
- DevOps и SRE, автоматизирующие диагностику и эксплуатационные задачи;
- продуктовые и R&D-команды, оценивающие реальную пользу бенчмарков и reasoning;
- специалисты по on-prem AI, которые считают стоимость владения и инфраструктурные риски.
Если вы решаете, включать ли модель в рабочий контур, а не просто «поиграть» с ней, дальше — для вас.
Важные оговорки перед оценкой
Вокруг новых моделей много искажений, поэтому зафиксируем несколько принципов.
- Open-weights не равно open-source. Лицензии и ограничения могут заметно различаться.
- Цифры вендора — ориентир, а не доказательство. Без собственного PoC они ничего не гарантируют.
- Режим «w/ Tools» нельзя напрямую сравнивать с режимом без инструментов. Это разные классы задач.
- Агентность — свойство всей системы. Это комбинация модели и обвязки, а не только весов.
- GLM-4.7 в API — Text → Text. Визуальные сценарии описаны на уровне платформы.
- «Multimodal interaction» не означает приём изображений endpoint'ом.
Эти рамки помогают не завышать ожидания при внедрении.
Что изменилось по сравнению с GLM-4.6
GLM-4.7 — не смена поколения, а целенаправленная доводка под инженерные и агентные сценарии. Если 4.6 воспринималась как сильная универсальная LLM, то новая версия сместила акцент на роль основы для coding-агентов, терминальных задач и многошаговых пайплайнов.
Core coding
Основной прирост виден там, где модель должна действовать, а не рассуждать абстрактно: исправлять баги, работать с репозиториями, выполнять цепочки команд. Параллельно подтянули «vibe coding» — генерацию более аккуратного фронтенда, документов и слайдов, которые меньше похожи на сырые макеты.
Tool use
Развитие получил инструментарий для агентов. Function calling и structured output (JSON) стали стабильнее, снизилось число ошибок при строгой валидации схем, а кеширование контекста помогает экономить токены и время в длинных диалогах и циклах агента.
Reasoning
Рассуждения в GLM-4.7 меньше завязаны на «красивую» цепочку мыслей и больше — на устойчивое выполнение длинных последовательностей действий с инструментами. Наиболее показательны отличия от 4.6 именно в режимах «w/ Tools», где модель работает как часть системы.
Кодинг и терминальные задачи
По ключевым инженерным бенчмаркам прирост заметный:
- SWE-bench Verified — 73.8 (+5.8 к GLM-4.6);
- SWE-bench Multilingual — 66.7 (+12.9);
- Terminal Bench 2.0 — 41.0 (+16.5).
Эти значения указывают на усиление именно агентных сценариев, где мало написать код — нужно корректно работать с окружением и инструментами. Все цифры заявлены вендором и приведены в model card. Их стоит проверять на собственных репозиториях, языках и типовых задачах; особенно это касается Terminal Bench, где результат сильно зависит от политики инструментов и окружения.
Vibe coding
Отдельно подчёркивается качество генерации интерфейсов и визуальных артефактов. Речь не о дизайне с нуля, а о более чистых современных веб-страницах, аккуратной вёрстке и адекватных пропорциях элементов. То же относится к презентациям и документам: улучшены layout, отступы и sizing, содержимое меньше «расползается».
Это удобно для быстрых прототипов, внутренних инструментов и черновых слайдов: модель чаще попадает в ожидаемую структуру и требует меньше ручной правки. Но для production-интерфейсов ничего принципиально не меняется — без дизайн-системы, линтеров и визуальных тестов результат остаётся нестабильным. GLM-4.7 ускоряет старт, но не заменяет фронтенд-контроль.
Tool use и агентные фреймворки
В model card заявлены улучшения на τ²-Bench и BrowseComp, что говорит о более предсказуемой работе в сценариях поиска и многошагового взаимодействия с инструментами. При этом важно разделять уровни ответственности: модель умеет корректно вызывать инструменты, но реальные действия всегда лежат на агентном приложении. Без оркестратора, песочницы и политик безопасности даже улучшенный tool use не превращается в надёжную систему.
Thinking-режимы
Одно из главных отличий — развитие режимов рассуждения. Поддерживаются:
- interleaved thinking — рассуждение вперемешку с действиями;
- preserved thinking — сохранение логики между шагами;
- turn-level thinking — включение и отключение рассуждения на уровне отдельных запросов.
Это даёт больше контроля над стоимостью, латентностью и поведением модели. Характерный пример — HLE (w/ Tools): 42.8 (+12.4 к GLM-4.6). Такой прирост важен именно для режимов с инструментами: на практике это меньше «срывов» в середине сценария и более предсказуемое выполнение сложных задач.
Технический профиль и API
В API GLM-4.7 строго определена как Text → Text: на вход текст, на выход текст, без нативной поддержки изображений или аудио. Ставка сделана на масштаб контекста и управляемость поведения.
| Параметр | Значение |
|---|---|
| Контекстное окно | 200K токенов |
| Максимальный вывод | до 128K токенов |
| Модальности | Text → Text |
| Заявленные возможности | streaming, thinking mode, function calling, context caching, structured output |
В совокупности это делает модель не столько «умным собеседником», сколько предсказуемым компонентом системы: её можно использовать как ядро агентов, IDE-ассистентов и автоматизированных инженерных процессов, где важны контроль, повторяемость и масштабируемость.
Что даёт контекст 200K и вывод 128K
Большое окно позволяет загружать целые репозитории, наборы требований, логи инцидентов или многофайловые диффы без агрессивной нарезки. Это упрощает анализ связей между файлами и снижает риск потери важных деталей; агент может держать в памяти историю шагов и состояние задачи.
Но растут и риски: длинный контекст напрямую влияет на стоимость запроса и латентность, особенно при повторных вызовах. Поэтому в боевых системах не обойтись без контекст-менеджмента — суммаризации, выборочных окон и явного управления памятью. Простор есть, но дисциплину он не отменяет.
Structured output, function calling и кеширование
Structured output позволяет задавать строгие JSON-схемы и получать валидируемые ответы, пригодные для автоматической обработки. Вместе с function calling это упрощает построение агентов, которые принимают решения и передают параметры в инструменты без ручного разбора текста.
Контекст-кеширование не требует пересылать неизменные части контекста при каждом запросе, что снижает стоимость и ускоряет отклик. В продакшене это особенно важно при retry-политиках и контроле идемпотентности инструментов, когда один и тот же шаг может выполняться повторно.
Где на самом деле «мультимодальность»
Endpoint GLM-4.7 остаётся текстовым и не принимает изображения. Все упоминания «multimodal interaction» относятся к прикладным кейсам на платформе Z.ai, где задействованы камера, жесты или интерактивные интерфейсы. Для понимания изображений у Z.ai есть отдельные релизы, например GLM-4.6V. Для GLM-4.7 мультимодальность — это уровень приложения, а не свойство самой модели.
Бенчмарки и методология
Основной акцент сделан на метриках, близких к реальным задачам dev-агентов. SWE-bench и Terminal Bench проверяют не абстрактные знания, а способность исправлять код, ориентироваться в проекте и взаимодействовать с окружением.
Ключевое различие — режимы «w/ Tools» и без инструментов. В первом часть работы выполняют внешние системы (терминал, браузер, поиск), поэтому результат отражает эффективность связки «модель + инструменты». Напрямую сравнивать его с чистым reasoning некорректно.
| Метрика | Что измеряет | Как интерпретировать |
|---|---|---|
| SWE-bench Verified | Исправление реальных багов | Близко к задачам code review и bugfix |
| SWE-bench Multilingual | Кодинг на разных языках | Важно для polyglot-репозиториев |
| Terminal Bench 2.0 | Работа с CLI и окружением | Ключевой индикатор агентного кодинга |
| HLE (w/ Tools) | Многошаговые задачи с инструментами | Показывает устойчивость пайплайна |
Эти показатели подсказывают, где модель потенциально сильна, но не отвечают на вопрос, как она поведёт себя в вашем проекте.
GLM-4.7 и GLM-4.6: ключевые дельты
| Метрика | GLM-4.6 | GLM-4.7 | Дельта |
|---|---|---|---|
| SWE-bench Verified | ~68.0 | 73.8 | +5.8 |
| SWE-bench Multilingual | ~53.8 | 66.7 | +12.9 |
| Terminal Bench 2.0 | ~24.5 | 41.0 | +16.5 |
| HLE (w/ Tools) | ~30.4 | 42.8 | +12.4 |
Даже по цифрам вендора видно: основной прирост сосредоточен в агентных и терминальных сценариях, а не в «общих» текстовых задачах.
Сравнение с другими моделями
Для витринного сравнения с другими крупными моделями в model card обычно публикуют следующие метрики:
| Метрика | Назначение |
|---|---|
| MMLU-Pro | Общая академическая подготовка |
| GPQA-Diamond | Сложные вопросы и reasoning |
| LiveCodeBench-v6 | Современные coding-задачи |
| SWE-bench Verified | Исправление багов |
| Terminal Bench 2.0 | Терминальные и агентные сценарии |
| BrowseComp | Поиск и навигация с инструментами |
| HLE (w/ Tools) | Многошаговые агентные задачи |
На сравнительной диаграмме по восьми бенчмаркам GLM-4.7 лидирует по большинству метрик reasoning, кодинга и агентного поведения; особенно выделяются AIME 25, GPQA и τ²-Bench. Для первого скрининга это полезно, но выводы всё равно нужно подтверждать PoC на своих задачах.
Когда брать GLM-4.7, а когда смотреть альтернативы
- Coding-агенты, репозитории, терминал. Логичный кандидат: улучшенные coding-бенчмарки, стабильный tool use, structured output и thinking-режимы работают именно в агентных пайплайнах. Альтернативы — другие code-модели, но часто без длинного контекста или с менее зрелым инструментальным API.
- DevOps и терминальная автоматизация (runbooks, диагностика, анализ логов). Связка reasoning и tools позволяет строить цепочки действий, а большой контекст упрощает работу с логами и конфигами. Если важны минимальная латентность или жёстко заданные шаблоны команд, иногда разумнее lightweight-модели.
- Длинный контекст. 200K на входе и 128K на выходе выигрывают у моделей с меньшим окном, где приходится усложнять контекст-менеджмент и мириться с риском ошибок.
- Строгие форматы, function calling, JSON. Structured output и caching делают поведение предсказуемее.
- Простые FAQ и чаты без инструментов. Возможности GLM-4.7 избыточны; проще и дешевле взять более базовую модель.
- Стоимость владения и on-prem. Веса доступны, и модель можно встроить в собственный MLOps-контур. Но при ограниченной инфраструктуре или нехватке ресурсов на эксплуатацию облачные варианты с меньшими требованиями могут оказаться практичнее.
Мини-сравнение классов моделей
| Модель / класс | Ключевой сценарий | Модальности | Контекст / вывод | Сильные стороны | Ограничения |
|---|---|---|---|---|---|
| GLM-4.7 | Coding-агенты, tool use, длинный контекст | Text → Text | 200K / 128K | Агентные сценарии, structured output, reasoning с инструментами | Нет image input, выше требования к инфраструктуре |
| GLM-4.6 | Общие текстовые задачи, кодинг без агентов | Text → Text | 200K / 128K | Более простое внедрение, ниже нагрузка | Слабее в агентных и терминальных задачах |
| GLM-4.6V | Визуальные и мультимодальные задачи | Text + Image | Зависит от режима | Понимание изображений, vision-кейсы | Слабее в чисто кодовых агентных сценариях |
| Другие vision-модели | Компьютерное зрение, анализ изображений | Image / Multimodal | Зависит от модели | Специализация под vision | Не подходят для agentic coding |
| Lightweight LLM | FAQ, простые чаты | Text → Text | Ограниченный | Низкая стоимость, простота | Не тянут сложные пайплайны |
Вывод простой: GLM-4.7 стоит рассматривать там, где важны код, инструменты и длинный контекст, а для визуальных задач сразу смотреть на GLM-4.6V или специализированные vision-модели.
Практический взгляд на инфраструктуру
Главное практическое следствие для on-prem — требования к железу. Модель с окном 200K и выводом до 128K, работающая в агентных циклах с повторными вызовами, нагружает и память, и вычисления сильнее, чем компактная модель для чата. Поэтому до запуска пилота полезно заранее решить, какие нагрузки вы собираетесь держать локально, какая латентность допустима и сколько параллельных агентов нужно обслуживать. Конкретные характеристики потребуемых ресурсов в model card мы здесь не приводим и не додумываем — их нужно уточнять по документации и проверять замерами на своём стенде.
Если вы планируете развернуть подобную модель у себя, имеет смысл посмотреть на серверы и AI-серверы в каталоге «СервакМастер», а подобрать конфигурацию под ваш сценарий можно через контакты: специалисты помогут сопоставить задачу, нагрузку и бюджет.
Итоги
GLM-4.7 — флагманская текстовая модель, нацеленная на кодинг, агентные сценарии и работу с инструментами. Её сильные стороны проявляются в многошаговых действиях, терминальных задачах и устойчивых цепочках function calling. Контекст 200K и вывод до 128K упрощают работу с крупными кодовыми базами, требованиями и логами, а thinking-режимы добавляют управляемости.
Универсальной её не назвать. Для vision-задач и мультимодального ввода нужны отдельные модели вроде GLM-4.6V; в safety-критичных сценариях без песочницы, строгих политик и аудита использовать её нужно особенно осторожно. Заявленные бенчмарки — ориентир, а не гарантия результата.
Практическая рекомендация: оценивайте GLM-4.7 на одном и том же наборе собственных задач, фиксируя качество, стоимость и латентность, а не опираясь только на витринные цифры.