NVIDIA Dynamo: сессионное управление инфраструктурой для агентского вывода

Агентские нагрузки меняют архитектуру serving'а

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

Отличие от чатбота — в развёртывании работы: одна задача порождает множество параллельных вызовов модели, параллельные подагенты с короткой и длинной жизненью, и инструменты, которые выполняются между ходами. Большая часть стены времени сессии уходит не на генерацию, а на выполнение инструментов и исходящих вызовов, пока контекст сидит резидентным в KV cache, занимая место в HBM без использования. Оптимальное обслуживание зависит от того, сколько контекста система держит резидентным и переиспользует, и сколько сессий может одновременно обслуживать без нарушения SLA по latency.

Session ID как единый примитив для program-aware инфраструктуры

Большинство open-source serving стеков построены для стандартного чатбота: маршрутизируют, допускают и кэшируют каждый запрос независимо, без понимания сессии, которая связывает его с предыдущими ходами. NVIDIA Dynamo унифицировала управление вокруг session-level identifier, трансформируя request-aware инфраструктуру в program-aware.

Каждый запрос в траектории агента содержит:

• session_id — уникальный стабильный идентификатор одной цепочки рассуждений и вызовов инструментов
• parent_session_id — идентификатор родительской сессии (для отслеживания иерархии агентов и подагентов)

Встроенная поддержка кодировочных агентов (работает без конфигурации):

• Claude Code передаёт x-claude-code-session-id (корневые) и x-claude-code-agent-id (дочерние) с x-claude-code-parent-agent-id
• Codex использует thread-id и x-codex-parent-thread-id
• OpenCode отправляет x-opencode-session-id и x-opencode-parent-session-id

Плагины для других harnesses (репозиторий agent-plugins):

• Pi provider — для OpenAI-compatible endpoint Dynamo
• Hermes middleware — маппирует session_id Hermes
• OpenClaw provider — маппирует sessionId OpenClaw

Custom harnesses просто передают X-Dynamo-Session-ID (и опционально X-Dynamo-Parent-Session-ID), Dynamo нормализует их в agent_context, которую читает весь стек.

Трассировка, replay и backtesting

С флагом DYN_REQUEST_TRACE=1 Dynamo автоматически регистрирует каждый запрос без хранения промптов и ответов (их можно включить отдельно). После завершения потока ответа эмитируется request_end запись с:

• Полями сессии (session_id, parent_session_id)
• Выходным token count и finish reason
• Метриками KV cache и названиями инструментов
• Replay блоком с входной длиной и хешами последовательностей (формат, похожий на Mooncake)

Так как каждая запись содержит timestamps и finish reasons, видны распределения вызовов инструментов и связь с eviction-поведением. Dynamo использует эти данные для backtesting и оптимизации развёртываний.

Захваченная трасса становится переиспользуемым бенчмарком: воспроизводится столько раз, сколько нужно, без переполнения модели, инструментов или внешних API. Трасса остаётся content-free благодаря sequence hashes, которые становятся синтетическими block ID, сохраняя prefix sharing через ходы и сессии.

AISimulate запускает граф запросов против симулированного scheduler, router и KV cache для сравнения воркеров, топологий, политик маршрутизации и ёмкости без затрат GPU. AIPerf воспроизводит тот же граф на реальном endpoint для финальных latency, throughput и cache метрик.

Session-aware routing и управление пропускной способностью

Стандартный request-level router (включая KvRouter из коробки) решает размещение запроса за запросом: какой воркер имеет максимальный overlap кэша. Это правильная единица для одного хода, но неправильная для агента при высокой конкурентности, потому что упускает два фактора:

• Cache-occupancy blowup: между ходами кэш агента не освобождается, сидит в HBM, занимая блоки, пока агент запускает инструмент вне GPU. При N агентах на шаге k совокупный working set = N × context_k, но request-level router видит только один ход. Как только working set превышает HBM и DRAM, движок evict'ит кэш живых сессий, и каждый следующий ход платит полный re-prefill вместо cache hit.

• Отсутствие backpressure: когда воркер переполнен, request-level router может только отменить или встать в очередь in-flight запросы — оба варианта хуже альтернативы: отложить сессию в точке паузы перед следующим ходом, когда она вот-вот будет idle.

Dynamo адаптировала scheduler из paper ThunderAgent (Kang et al., 2026) поверх KV-aware router. Реализованный на Rust, владеет KvRouter напрямую, отслеживает реальный prompt_tokens + completion_tokens с каждого ответа вместо оценки из raw bytes. Как native Dynamo plugin, можно адаптировать исходный код под форму своей рабочей нагрузки без изменения базового router.