NVIDIA Dynamo: gerenciamento de infraestrutura baseado em sessões para inferência agêntica

Cargas agênticas estão remodelando a arquitetura de serving

As cargas de trabalho agênticas mudaram radicalmente o formato do tráfego que chega aos servidores de inferência. Uma sessão se abre com um prefill massivo — muitas vezes dezenas de milhares de tokens de prompts de sistema, descrições de ferramentas e instruções específicas do usuário. Após a primeira chamada, o modelo recebe contexto anexado, que a sessão volta a enviar por completo em cada novo turno.

A diferença em relação a um chatbot está em como o trabalho se desenrola: uma única tarefa gera múltiplas chamadas paralelas ao modelo, subagentes paralelos com vidas curtas e longas, e ferramentas que são executadas entre turnos. A maior parte do tempo real de uma sessão não é gasta com geração, e sim com a execução de ferramentas e chamadas externas, enquanto o contexto permanece residente no cache KV, ocupando espaço na HBM sem ser usado. O serving ideal depende de quanto contexto o sistema mantém residente e reutiliza, e de quantas sessões consegue atender simultaneamente sem violar os SLAs de latência.

Session ID como primitiva unificada para uma infraestrutura orientada

a programas

A maioria das stacks de serving open source foi construída para o caso padrão do chatbot: roteiam, admitem e armazenam em cache cada requisição de forma independente, sem entender a sessão que a conecta a turnos anteriores. O NVIDIA Dynamo unificou o gerenciamento em torno de um identificador em nível de sessão, transformando uma infraestrutura orientada a requisições em uma orientada a programas.

Cada requisição na trajetória de um agente contém:

• session_id — um identificador único e estável para uma cadeia de raciocínio e chamadas de ferramentas • parent_session_id — o identificador da sessão pai (para rastrear a hierarquia de agentes e subagentes)

Suporte nativo a agentes de codificação (funciona sem configuração):

• O Claude Code envia `x-claude-code-session-id` (raiz) e `x-claude-code-agent-id` (filhos) junto com `x-claude-code-parent-agent-id` • O Codex usa `thread-id` e `x-codex-parent-thread-id` • O OpenCode envia `x-opencode-session-id` e `x-opencode-parent-session-id`

Plugins para outros harnesses (repositório agent-plugins):

• Pi provider — para o endpoint compatível com OpenAI do Dynamo • Middleware Hermes — mapeia o `session_id` do Hermes • Provider OpenClaw — mapeia o `sessionId` do OpenClaw

Harnesses personalizados simplesmente enviam `X-Dynamo-Session-ID` (e, opcionalmente, `X-Dynamo-Parent-Session-ID`), e o Dynamo os normaliza em `agent_context`, que é lido por toda a stack.

Rastreamento, replay e backtesting

Com a flag `DYN_REQUEST_TRACE=1`, o Dynamo registra automaticamente cada requisição sem armazenar prompts e respostas (isso pode ser habilitado separadamente). Após o encerramento do stream de resposta, é emitido um registro `request_end` contendo:

• Campos da sessão (session_id, parent_session_id) • Contagem de tokens de saída e motivo de finalização • Métricas do cache KV e nomes das ferramentas • Um bloco de replay com o comprimento da entrada e hashes de sequência (formato parecido com o do Mooncake)

Como cada registro contém timestamps e motivos de finalização, é possível observar a distribuição das chamadas de ferramentas e sua relação com o comportamento de eviction. O Dynamo usa esses dados para backtesting e para otimizar implantações.

Um trace capturado se transforma em um benchmark reutilizável: pode ser reproduzido quantas vezes forem necessárias, sem sobrecarregar o modelo, as ferramentas ou APIs externas. O trace permanece livre de conteúdo graças aos hashes de sequência, que se tornam IDs de bloco sintéticos, preservando o prefix sharing entre turnos e sessões.

O AISimulate executa o grafo de requisições contra um scheduler, router e cache KV simulados para comparar workers, topologias, políticas de roteamento e capacidade sem consumir GPU. O AIPerf reproduz o mesmo grafo em um endpoint real para obter métricas finais de latência, throughput e cache.

Roteamento consciente de sessão e gerenciamento de throughput

Um router padrão em nível de requisição (incluindo o KvRouter nativo) decide o posicionamento requisição por requisição: qual worker tem o maior overlap de cache. Essa é a unidade correta para um único turno, mas é a errada para um agente sob alta concorrência, porque ela ignora dois fatores:

• Explosão de ocupação de cache: entre turnos, o cache do agente não é liberado — ele permanece na HBM, ocupando blocos enquanto o agente executa uma ferramenta fora da GPU. Com N agentes no passo k, o working set agregado é N × context_k, mas um router em nível de requisição vê apenas um turno. Quando o working set excede a HBM e a DRAM, o engine despeja o cache de sessões ativas, e cada turno seguinte paga por um re-prefill completo em vez de um cache hit.

• Ausência de backpressure: quando um worker está sobrecarregado, um router em nível de requisição só pode cancelar ou colocar em fila as requisições em andamento — ambas as opções são piores do que a alternativa: pausar a sessão em um ponto natural de interrupção, justo antes do próximo turno, quando ela está prestes a ficar inativa.

O Dynamo adaptou o scheduler do paper ThunderAgent (Kang et al., 2026) sobre o router KV-aware. Implementado em Rust, ele controla o KvRouter diretamente e rastreia os valores reais de prompt_tokens + completion_tokens de cada resposta, em vez de estimá-los a partir de bytes brutos. Como plugin nativo do Dynamo, pode ser adaptado ao formato de cada carga de trabalho sem modificar o router subjacente.