Databricks GLM 5.2: почему AI-кодинг считают по задаче
Databricks показала, почему для AI-кодинга важнее цена за выполненную задачу, чем стоимость токена: GLM 5.2 стала кандидатом на daily coding model.
Databricks GLM 5.2: почему AI-кодинг считают по задаче
Факты проверены 11 июля 2026 года. Databricks GLM 5.2 стала заметной благодаря внутреннему бенчмарку на реальной кодовой базе Databricks, а не очередному публичному рейтингу. Компания сравнила coding agents на задачах из своих pull request и увидела, что GLM 5.2 попадает в верхний класс качества, по качеству статистически не отличается от Opus 4.8 и стоит дешевле на уровне выполненной задачи.
Короткий ответ: GLM 5.2 - открытая LLM от Z.AI для длинных инженерных задач, а Databricks проверила её на своих coding tasks, а не на абстрактном leaderboard. Для команд здесь полезнее всего практический вывод: в AI-кодинге надо считать цену за закрытую задачу, а не только цену токена.
Для контекста по самой модели можно открыть наш обзор GLM-5.2. Этот материал уже про другой интент: как Databricks выбирает coding engine для ежедневной разработки и почему внутренний benchmark меняет разговор о стоимости AI-агентов.
Что именно проверила Databricks
8 июля 2026 года Databricks опубликовала разбор собственного benchmark для coding agents. Задачи брали из реальных PR инженеров Databricks, а не из публичных наборов вроде SWE-Bench. Это важная разница: публичные задачи со временем попадают в обучающие данные, а внутренняя кодовая база показывает, как модель справляется с живыми соглашениями, тестами, legacy-кодом и смешанным стеком.
Databricks описывает кодовую базу как multi-million-line: Python, Go, Typescript, Scala и другие языки. Для задач оставляли свежие human-written PR, связанные тесты, самодостаточные изменения и типичные участки стека. Ответы оценивали тестами, а не LLM-судьёй. Ещё одна защитная мера звучит почти комично, но она практична: на время run отрезали git history, потому что ранние агенты могли найти правильное решение в истории репозитория.
Почему GLM 5.2 стала рабочей моделью для кодинга
На графике Databricks GLM 5.2 оказалась в верхнем capability tier. По формулировке компании, результаты показывают, что GLM может быть daily driver model для многих разработчиков. Числа такие: GLM 5.2 по качеству статистически не отличается от Opus 4.8 и стоит $1.28 за задачу против $1.94 у Opus 4.8.
Databricks не пишет, что выключает Claude, OpenAI или другие закрытые модели. В том же разборе компания говорит, что Pareto frontier для coding tasks включает OpenAI, Anthropic и open source. Сильная стратегия здесь похожа на маршрутизацию: простые и средние задачи отдаём более дешёвым моделям, сложные архитектурные задачи оставляем верхнему tier.
Цена токена плохо предсказывает цену задачи
Самая полезная часть материала Databricks - не место GLM 5.2 на графике, а отказ от грубой метрики «дешевле за токен значит дешевле в работе». На coding tasks модель может читать больше контекста, дольше рассуждать, делать лишние проходы по репозиторию и в итоге стоить дороже, хотя прайс за миллион токенов выглядит ниже.
Databricks приводит хороший пример: Sonnet 5 примерно в 1.7 раза дешевле Opus 4.8 за токен. Но на их задачах Sonnet 5 стоил $2.09 за задачу против $1.94 у Opus 4.8, набрал 81% pass-rate против 87% и потребил примерно в 1.9 раза больше токенов. Для финансового директора, платформенной команды и руководителя разработки это одна и та же мысль: считать надо не входные токены, а стоимость закрытого изменения.
| Что сравнивать | Что показала Databricks | Редакционный вывод |
|---|---|---|
| GLM 5.2 vs Opus 4.8 | GLM 5.2 по качеству статистически не отличается от Opus 4.8; $1.28/task против $1.94/task. | Открытая модель может попасть в верхний tier, если считать на реальных задачах. |
| Sonnet 5 vs Opus 4.8 | Sonnet 5 дешевле за токен примерно в 1.7 раза, но на задачах Databricks вышел $2.09/task против $1.94/task у Opus. | Дешёвый токен не гарантирует дешёвую задачу. |
| Harness | Один и тот же model class в разных harness давал разницу стоимости больше чем в 2 раза. | Цена зависит от того, сколько контекста инструмент скармливает модели и как держит рабочий набор. |
| Сложность задач | У Databricks 61.1% сессий AI-кодинга относятся к medium complexity, 12.1% - к high complexity. | Один default model для всех задач почти наверняка переплачивает или недодаёт качество. |
Где здесь место Z.AI GLM-5.2
Z.AI в документации позиционирует GLM-5.2 как flagship model для long-horizon tasks. По состоянию на 11 июля 2026 года в официальных docs указаны 1M context length и 128K maximum output tokens. Для больших репозиториев это не косметическая характеристика: агенту нужно держать архитектурные ограничения, тесты, контракты API и историю решений дольше, чем в обычном чате.
Текущая pricing-страница Z.AI указывает для GLM-5.2 $1.40 за 1M input tokens, $0.26 за 1M cached input tokens и $4.40 за 1M output tokens. Эти цены сами по себе не объясняют результат Databricks. Внутренний benchmark как раз показывает, что итоговая экономика складывается из трёх слоёв: цена токена, токеновая эффективность модели и поведение harness.
У Toolarium уже есть отдельный разбор про стоимость coding agents. История Databricks добавляет к нему практический слой: если у команды есть поток merged PR, тесты и история review, она уже сидит на материале для собственного benchmark. Не обязательно ждать, пока публичный leaderboard скажет, какой агент «лучше».
Почему harness решает почти так же много, как модель
Databricks сравнивала модели вместе с обвязками, через которые они работают: Claude Code, Codex, Pi и другие варианты. Результат неприятный для простых сравнений. При одной модели и похожем thinking effort стоимость задачи могла различаться больше чем в два раза, а качество оставалось сопоставимым. В одном из примеров Pi отправлял примерно в три раза меньше контекста за ход, лучше держал рабочий набор и завершал задачи за меньшее число проходов.
Это объясняет, почему Databricks связывает benchmark с Omnigent и маршрутизацией. Для платформенной команды недостаточно выбрать «лучшую модель». Надо уметь менять model + harness под класс задачи, бюджет и риск. Подробнее про этот слой мы разбирали в материале про маршрутизацию моделей и harness в Databricks Omnigent.
Что это меняет для команд разработки
Если читать кейс Databricks как инструкцию, порядок действий получается приземлённым.
- Соберите набор реальных PR: свежих, человеческих, с тестами и понятным intent.
- Уберите подсказки, которые раскрывают готовое решение, и закройте доступ к истории git на время прогона.
- Оценивайте pass-rate тестами, а не тем, насколько уверенно агент объяснил ответ.
- Считайте cost per task, а не только input/output price.
- Разделите задачи по сложности: config changes, обычные feature edits, сложные design explorations.
- Проверяйте model + harness вместе, потому что обвязка может съесть экономию модели.
Главное ограничение: benchmark Databricks не стоит читать как универсальную таблицу «какую LLM купить всем». Он ценен именно потому, что привязан к их коду, тестам и рабочим привычкам. Для другой компании порядок моделей может поменяться. Метод, скорее всего, останется полезным.
FAQ
Databricks полностью заменила Claude или OpenAI на GLM 5.2?
Нет. По открытым источникам корректная формулировка мягче: Databricks увидела, что GLM 5.2 можно разворачивать как daily driver для части coding work. В их верхнем tier остаются модели разных провайдеров.
Почему Databricks сравнивает цену за задачу, а не цену токена?
Потому что агентная разработка тратит токены неравномерно. Одна модель может быть дешевле за токен, но читать больше файлов, дольше рассуждать и делать больше шагов. В итоге задача выходит дороже.
Можно ли переносить результат Databricks на любую кодовую базу?
Нет. Бенчмарк построен на задачах Databricks. Его главный урок - методика: брать реальные PR, держать тесты как судью, считать pass-rate и cost per task на своём коде.
Вывод
Databricks GLM 5.2 - хороший сигнал для рынка открытых моделей для кода, но ещё более сильный сигнал для инженерных руководителей. Выбор AI coding engine переезжает из плоскости «у кого выше leaderboard» в плоскость операционной экономики: какие задачи у команды повторяются каждый день, сколько стоит закрыть одну задачу, какой harness не раздувает контекст и где дорогая модель действительно нужна.
Если в компании AI-кодинг уже стал рабочим процессом, следующий зрелый шаг - свой benchmark на собственных PR. Без него default model легко превращается в дорогую привычку.
Источники и дата проверки
Факты, цены и характеристики проверены 11 июля 2026 года. Данные по моделям, pricing и benchmark быстро меняются; перед закупкой или изменением корпоративной политики их нужно перепроверить по первоисточникам.
- Databricks Blog: Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase, 8 июля 2026 года.
- Z.AI Docs: GLM-5.2 overview, проверено 11 июля 2026 года.
- Z.AI Docs: Pricing, проверено 11 июля 2026 года.
- The Decoder: Databricks makes Chinese open-source model GLM 5.2 its default coding engine, 9 июля 2026 года.
