Агентный ИИ упрётся в ограничения инфраструктуры раньше, чем в ограничения интеллекта

Модели совершенствуются быстрее, чем мы учимся обслуживать задачи, которые им поручают.

Большинство споров о будущем ИИ-агентов сводится к их возможностям. Способна ли модель надёжно планировать? Может ли она исправлять собственные ошибки? Можно ли доверить ей действия, последствия которых имеют значение?

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

Чат-бот и агент создают разные вычислительные нагрузки

Диалоговый запрос — это один цикл обмена данными: отправить запрос, получить токены — и соединение закрыто. Такие запросы можно обрабатывать пакетами, кэшировать префикс и оценивать пропускную способность одним показателем.

Запрос к агенту — это сеанс работы. Агент вызывает инструмент, ждёт, изучает результат, решает, что делать дальше, вызывает другой инструмент и в конце концов отвечает. Даже для несложной задачи может потребоваться шесть или восемь обращений к модели с ожиданием между ними.

Это различие важно по причинам, не связанным с интеллектом. Между этапами агент удерживает состояние — переписку, результаты работы инструментов и накопленные рассуждения. При обслуживании модели это состояние хранится в памяти графического процессора в виде кэша ключей и значений (KV cache) и занимает память на протяжении всего сеанса, в том числе в те секунды, когда агент ждёт ответа от API, который вам не принадлежит.

Поэтому вместо «запросов в секунду» пропускную способность теперь измеряют числом «одновременно работающих сеансов, размещённых в памяти». Система, которая без труда обрабатывала тысячу диалоговых запросов в секунду, на том же оборудовании может обслуживать лишь несколько десятков одновременных сеансов агентов.

Ожидание обходится дороже всего

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

Самое дорогое оборудование простаивает, будучи зарезервированным за запросом, который в этот момент ожидает ответа на запрос к базе данных.

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

Последовательное выполнение усугубляет проблему

Почти все платформы для агентов выполняют вызовы инструментов один за другим. Модель запрашивает прогноз погоды, получает его, запрашивает проверку календаря, получает результат, а затем ищет авиабилеты и получает результаты поиска.

Зачастую эти три вызова не зависят друг от друга и могли бы выполняться одновременно. При последовательном выполнении их задержки складываются. При параллельном — время ожидания определяется самым долгим вызовом.

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

Если вдвое сократить продолжительность сеанса, пропускная способность по числу одновременных сеансов примерно удвоится — на тех же графических процессорах и без изменений модели.

Повторы накапливаются непредусмотренным образом

Платформы для агентов наследуют настройки повторных попыток из лежащих в их основе HTTP-библиотек. Обычно таких попыток три.

Модель тоже повторяет попытки, но по-своему. Если инструмент возвращает бесполезный результат, рассуждающая модель часто пробует другой подход — то есть повторяет попытку, хотя никто этого не настраивал.

Если сложить эти механизмы, политика с тремя попытками, применяемая к модели, которая самостоятельно перебирает ещё три подхода, превращается в политику с девятью попытками — хотя никто её не задавал. Каждая такая попытка требует полноценного обращения к модели, расходуя токены и время работы графического процессора.

При замедлении работы зависимости это усиление нагрузки превращает сбой в полноценную аварию, причём стоимость каждой попытки на порядки выше, чем стоимость повторного REST-запроса.

Как выглядят эти ограничения на практике

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

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

На этом этапе многие многообещающие внутренние демонстрации незаметно заходят в тупик.

Что помогает отодвинуть этот предел

Ничего экзотического — всё это относится к инфраструктуре, а не к моделированию:

Выполняйте независимые вызовы инструментов параллельно. Это самый значительный единичный выигрыш, доступный уже сегодня и не требующий нового оборудования.

Оценивайте производительность по длительности сессии. Не по числу токенов в секунду. Не по загрузке графического процессора. Важно, как долго состояние остается в памяти и сколько сессий там помещается.

Устанавливайте общий лимит повторных попыток для всей системы, а не для каждого вызова. Общий предел — например, ограничение повторных попыток небольшой долей от всего трафика — предотвращает описанный выше эффект накопления. И практика SRE Google по обработке перегрузки, и бюджеты повторных попыток Envoy реализуют эту идею за пределами стека ИИ.

Отделяйте рассуждение от выполнения. Используйте большую модель для планирования, а гораздо меньшую — для механических действий. Большинству задач агента не нужна передовая модель.

Сделайте освобождение контекста недорогим. Квантованный KV-кэш, внимание с постраничной организацией и механизмы выгрузки неактивных сессий. Именно здесь сейчас ведется самая интересная работа по обслуживанию моделей.

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

Модель выполнения, лежащую в основе последнего тезиса, — параллельное выполнение зависимых вызовов моделей в рамках единого лимита задержки — я опубликовал в статье «Асинхронное выполнение графов инференса для маршрутизации моделей в системах машинного обучения», International Journal of Computer Trends and Technology 72(10), октябрь 2024 года. О применении генеративных моделей именно в системах принятия решений с жесткими ограничениями по задержке см. «Торговые и аналитические платформы с дополнением на основе больших языковых моделей: связь генеративного интеллекта с финансовыми системами принятия решений», Journal of Information Systems Engineering and Management 11(1s), 2026 год.