Почему IBM вообще пошла в сторону агентов
Корпоративный клиент редко покупает модель ради красивых демо. Ему нужно, чтобы софт что-то делал: разбирал тикеты, сверял счета, дергал внутренние API, писал сводки по документам. Именно эту нишу и занимает агентная логика — когда модель не просто отвечает на вопрос, а сама решает, какой инструмент вызвать следующим.
Granite 4.2 в этой истории — не «ещё одна большая модель», а попытка IBM достроить линейку так, чтобы она одинаково уверенно работала и в облаке, и в закрытом контуре заказчика. Ставка делается на связку трёх вещей: открытые веса, скромные требования к железу и предсказуемое поведение при вызове внешних функций.
Что вообще представляет собой линейка Granite
IBM ведёт семейство открытых моделей под общим именем Granite не первый год. За это время сложилась узнаваемая философия: модели выпускаются в нескольких размерах, ориентированы в первую очередь на код, работу с таблицами, извлечение данных из документов и корпоративные сценарии, а не на соревнование в общих чат-бенчмарках.
Размеры имеют значение
Линейка строится лестницей — от совсем небольших вариантов, которые помещаются на одну видеокарту или даже работают на процессоре, до моделей среднего класса. Смысл в том, чтобы под каждую задачу можно было взять минимально достаточный размер. Для агента, который в основном маршрутизирует запросы и вызывает функции, гигантская модель часто избыточна: она дороже в inference и медленнее отвечает.
Гибридная архитектура
В четвёртой ветке семейства IBM перешла к гибридной схеме, где часть слоёв построена на Mamba, а часть — на классическом внимании трансформера. Практический выигрыш тут прозаичный: длинный контекст обрабатывается дешевле, память расходуется экономнее, а пропускная способность на том же железе выше. Для агентных сценариев это критично, потому что в контекст постоянно подгружаются результаты вызовов инструментов, фрагменты документов и история шагов.
Лицензия без сюрпризов
Модели Granite распространяются по лицензии Apache 2.0. Для корпоративного юриста это скучная новость, а это как раз хорошая новость: можно дообучать, встраивать в коммерческий продукт, разворачивать внутри периметра и не отчитываться перед вендором о том, сколько заработал продукт.
Главный аргумент: это можно держать у себя
Облачные API удобны ровно до того момента, пока данные не окажутся под регуляторными ограничениями. Банк, клиника, промышленное предприятие или госструктура часто физически не могут отправлять часть документов наружу. Тут и начинается разговор про «своё железо».
Что реально нужно для запуска
Ключевое здесь — не топовые ускорители, а разумный минимум. Малые версии Granite поднимаются на одной потребительской карте, в контейнере на сервере без GPU или на ноутбуке разработчика. Средние размеры требуют уже нескольких карт или квантования. Запуск обычно идёт через стандартные инструменты вроде vLLM или Ollama, что снимает问题 с привязкой к эксклюзивному стеку вендора.
Безопасность и предсказуемость
Второй слой аргумента — контроль. Когда модель живёт в вашем контуре, вы сами решаете, какие логи писать, какие данные попадают в prompt, что кэшируется и как долго хранится. Для агентов это особенно важно: они умеют выполнять действия, а не только генерировать текст, и каждое такое действие желательно пропускать через собственные правила и аудит.
IBM здесь продаёт не только модель, но и обвязку: платформу watsonx, набор моделей-«стражей» для фильтрации нежелательного контента и инструменты дообучения на собственных данных. Модель в такой схеме — деталь, пусть и центральная.
Как выглядит агентный сценарий на практике
Идея агента проста: модель получает задачу, решает, каких данных ей не хватает, вызывает нужный инструмент, читает ответ и продолжает, пока не дойдёт до результата. Разница между «просто чатом» и агентом — в наличии цикла и прав.
Типичные роли, под которые затачивают такие модели:
- Маршрутизатор. Разбирает входящее обращение и решает, какому сценарию его передать.
- Извлекатель. Достаёт поля из счетов, договоров, выписок и складывает их в структуру.
- Исполнитель. Дергает API внутренних систем: создаёт заявку, обновляет статус, отправляет письмо.
- Ревьюер. Проверяет результат предыдущего шага и решает, можно ли его принимать.
Маленькая модель на каждом из этих шагов часто выгоднее одной большой: дешевле, быстрее, легче тестируется и, что немаловажно, проще заменить, если качество перестало устраивать.
На что смотреть и где ограничения
Открытые модели — не волшебная таблетка, и честный разговор про ограничения полезнее маркетинга.
Размер против качества рассуждений
Малые модели экономны, но на сложных многошаговых задачах всё ещё уступают крупным. Компромисс обычно ищут архитектурно: разделяют роли между несколькими небольшими моделями, добавляют детерминированные проверки на код, оставляют человеку право финального решения.
Экосистема вокруг
Открытые веса значат, что модель легко переносится между фреймворками — от LangChain до самописных оркестраторов. Обратная сторона: готовых «коробочных» решений под конкретную отрасль меньше, чем у проприетарных платформ, и часть работы по интеграции ложится на команду заказчика.
Железо и стоимость владения
Своё железо — это не только экономия на API, но и капитальные затраты, электричество, охлаждение и люди, которые всё это обслуживают. Для небольшой компании облако почти всегда окажется дешевле; для крупной с чувствительными данными — наоборот, и порог этот сдвигается в зависимости от объёмов.
Оценка качества
Главная ловушка — мерить агента общими бенчмарками. Работающий агент проверяется на своих сценариях: наборе реальных задач с известным правильным ответом, на устойчивости к мусорным входным данным и на поведении, когда вызванный инструмент вернул ошибку. Без такого набора любая цифра из релизной заметки остаётся цифрой из релизной заметки.
Что из этого следует
Реакция IBM на текущий момент рынка выглядит логично. Пока одни гонятся за предельным качеством в облаке, другие закрывают нишу, где важнее контроль, цена за токен и возможность развернуть всё внутри периметра. Открытые веса плюс скромные требования к ресурсам плюс акцент на вызов инструментов — именно тот набор, который нужен корпоративному заказчику, уставшему согласовывать отправку данных наружу.
Ключевой вопрос не в том, обгонит ли новая версия лидеров по общим тестам. Вопрос в том, хватит ли у команды дисциплины построить вокруг модели нормальный агентный контур: с ограниченными правами, аудитом, тестами и понятным откатом. Если да — держать такого агента на своём железе становится вполне рабочей стратегией, а не компромиссом.
