Агентний ШІ зіткнеться з інфраструктурною стіною раніше, ніж із межею інтелекту

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

Більшість дискусій про майбутнє ШІ-агентів точиться навколо їхніх можливостей. Чи здатна модель надійно планувати? Чи може вона виправляти власні помилки? Чи можна довірити їй дію, що матиме наслідки?

Це справді важливі питання. Але саме вони не визначатимуть, чи почнуть масово впроваджувати агентів упродовж найближчих кількох років, адже є ближче обмеження, яке дається взнаки швидше. Обслуговувати агентів економічно невигідно, і ця проблема загострюється саме через ті можливості, які всі хочуть додати.

Чат-бот і агент — це різні робочі навантаження

Розмова з моделлю — це один цикл запиту й відповіді. Надіслали запит, отримали токени — з’єднання закрито. Такий процес можна пакетувати, кешувати префікс, а пропускну здатність оцінювати одним числом.

Запит до агента — це сеанс роботи. Агент викликає інструмент, чекає, читає результат, вирішує, що робити далі, викликає інший інструмент і зрештою відповідає. Навіть нескладне завдання може вимагати шість або вісім викликів моделі з періодами очікування між ними.

Ця різниця важлива з причини, не пов’язаної з інтелектом. Між кроками агент зберігає стан — розмову, результати роботи інструментів, накопичені міркування. Під час обслуговування цей стан зберігається в пам’яті GPU як кеш ключів і значень і займає пам’ять протягом усього сеансу, зокрема й у ті секунди, коли агент чекає на відповідь від API, який належить не вам.

Тож одиницею вимірювання пропускної здатності стають уже не «запити за секунду», а «одночасні сеанси, що зберігаються в пам’яті». Система, яка без проблем обробляла тисячу розмовних запитів за секунду, на тому самому обладнанні може обслуговувати лише кілька десятків одночасних сеансів агентів.

Очікування — найдорожча частина

Ось у чому незручна особливість. Під час виклику інструмента агент нічого не робить. Токени не генеруються. Обчислювальні ресурси не використовуються. Однак пам’ять GPU і далі зайнята, адже вивільнення цього контексту й повторне його обчислення коштували б дорожче, ніж його зберігання.

Найдорожче обладнання простоює, обслуговуючи запит, який у цей момент чекає на результат запиту до бази даних.

У звичайних розподілених системах цю проблему розв’язали вже давно: ресурс звільняють, а роботу продовжують, коли надходить відповідь. Щоб так само організувати обслуговування моделей, потрібно перемістити кеш KV у пам’ять хоста або на диск, а потім відновити його. Витрати на передавання даних настільки високі, що більшість систем цього не робить. Дослідження саме цього питання активно тривають, адже проблема дорого обходиться.

Послідовне виконання ускладнює ситуацію

Майже всі агентні фреймворки виконують виклики інструментів один за одним. Модель запитує прогноз погоди, отримує його, запитує перевірку календаря, отримує її, запитує пошук авіарейсів і отримує результат.

Часто ці три виклики не залежать один від одного. Їх можна було б виконати одночасно. За послідовного виконання затримки додаються. За паралельного — визначальною стає найдовша з них.

Це не нове спостереження про агентів — той самий принцип стосується будь-якої системи, що запускає кілька моделей або сервісів у межах одного бюджету затримки. Загальна затримка має дорівнювати тривалості найдовшого шляху графом залежностей, а не сумі тривалості всіх етапів. Для агентів це важливіше, бо сеанс упродовж усього часу зберігається в пам’яті GPU. Тому скорочення реального часу виконання не лише покращує взаємодію з користувачем, а й безпосередньо збільшує кількість сеансів, які вміщуються на обладнанні.

Якщо вдвічі скоротити тривалість сеансу, кількість одночасних сеансів на тих самих GPU приблизно подвоїться — без жодних змін моделі.

Повторні спроби нагромаджуються непередбаченим чином

Агентні фреймворки успадковують стандартні налаштування повторних спроб від HTTP-бібліотек, на яких вони побудовані. Зазвичай таких спроб три.

Модель теж повторює спроби, але по-своєму. Коли інструмент повертає непридатний результат, модель, здатна міркувати, часто пробує інший підхід — тобто робить повторну спробу, хоча її ніхто не налаштовував.

Якщо поєднати ці механізми, політика трьох спроб, накладена на модель, яка самостійно доходить до ще трьох підходів, перетворюється на політику дев’яти спроб, якої ніхто не прописував. Кожна така спроба — це повний виклик моделі з окремими токенами й окремим часом використання GPU.

Коли робота залежності сповільнюється, саме це посилення навантаження перетворює погіршення роботи на збій. При цьому кожна спроба коштує на кілька порядків дорожче, ніж повторний виклик REST API.

Який вигляд насправді має ця стіна

Це не межа можливостей. Усе набагато прозаїчніше: проблема економічної доцільності, через яку проєкти зупиняються на переході від пілотного запуску до промислової експлуатації.

Пілотний запуск працює. Користувачів десять, затримка прийнятна, а рахунок — мізерна стаття витрат. Потім хтось моделює роботу системи для десяти тисяч користувачів, і необхідна кількість GPU виявляється нереалістичною — не тому, що модель повільна, а тому, що кожен одночасний сеанс займає пам’ять упродовж усього свого часу життя, включно з періодами очікування.

Саме на цьому етапі багатообіцяльні внутрішні демонстрації непомітно зупиняються.

Що відсуває межу

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

Виконуйте незалежні виклики інструментів паралельно. Це найбільший окремий виграш, доступний уже сьогодні й такий, що не потребує нового обладнання.

Вимірюйте пропускну здатність тривалістю сесій. Не кількістю токенів за секунду. Не завантаженістю GPU. А тим, як довго стан залишається в пам’яті та скільки сесій уміщується.

Встановлюйте ліміти повторних спроб для всієї системи, а не для кожного виклику. Загальне обмеження — повторні спроби як невеликий відсоток усього трафіку — запобігає описаному вище ефекту накопичення. І рекомендації Google SRE щодо обробки перевантаження, і бюджети повторних спроб Envoy реалізують цю ідею поза стеком ШІ.

Відокремлюйте міркування від виконання. Використовуйте велику модель для планування, а значно меншу — для механічних кроків. Більшість завдань агента не потребує передової моделі.

Зробіть витіснення контексту недорогим. Квантизований кеш KV, увага з розбиттям на сторінки та механізми вивантаження для неактивних сесій. Саме тут зараз відбувається найцікавіша робота над обслуговуванням моделей.

Моделі й надалі вдосконалюватимуться. У цьому можна не сумніватися. Чи стануть агенти частиною інфраструктури, чи так і залишаться демонстраціями, залежить від менш гучного питання: чи зможемо ми обслуговувати навантаження, за якого дорога пам’ять зайнята, поки система чекає, і чи перестанемо платити за суму тривалостей усіх кроків, якщо можемо платити лише за найдовший шлях.

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