PyTorch Blog: NVIDIA Dynamo учат работать с сессиями ИИ-агентов

Агентные приложения меняют картину нагрузки на инференс-сервер. Об этом PyTorch Blog пишет в материале про сессионно-ориентированный инференс на NVIDIA Dynamo. В анонсе перечислены три признака: крупный начальный prefill, многократные обращения к модели внутри одной сессии и субагенты, которые работают параллельно. Каждый из них по отдельности знаком инженерам, но вместе они ломают привычную модель «запрос пришёл, запрос обслужен».

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

Почему агент не похож на чат

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

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

Что здесь делает Dynamo

NVIDIA Dynamo — открытый фреймворк распределённого инференса, который компания представила как преемника Triton Inference Server. В его основе идеи, которые для агентов особенно важны: разделение prefill и decode по разным пулам GPU, маршрутизация с учётом содержимого KV-кэша и вынос кэша из памяти GPU на более дешёвые уровни хранения. Работает он поверх движков вроде vLLM, SGLang и TensorRT-LLM.

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

Что меняется для сервера при переходе от чата к агенту:

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

Что проверить на своём стеке

Если вы запускаете агентов на собственных моделях, начните с измерений. Посмотрите, какую долю токенов составляет повторяющийся префикс и как часто следующий вызов сессии попадает на тот же воркер. Если доля высокая, а попаданий в кэш мало, вы платите за лишний prefill.

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

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

Полные подробности реализации и измерения опубликованы в оригинальном посте PyTorch Blog. Перед тем как закладывать выводы в архитектуру, их стоит сверить с цифрами из первоисточника.