PyTorch Blog: NVIDIA Dynamo ganha suporte a sessões de agentes de IA

Aplicações baseadas em agentes mudam o perfil de carga de um servidor de inferência. É o que o PyTorch Blog afirma em um artigo sobre inferência orientada a sessões no NVIDIA Dynamo. O anúncio lista três características: um grande prefill inicial, várias chamadas ao modelo dentro da mesma sessão e subagentes que trabalham em paralelo. Cada uma delas é conhecida dos engenheiros, mas, combinadas, quebram o modelo habitual de "a requisição chegou, a requisição foi atendida".

O trecho disponível do post não traz benchmarks, por isso não há aqui números concretos de ganho de desempenho. A seguir, uma análise do que se sabe sobre o problema e sobre a plataforma.

Por que um agente não se parece com um chat

Um turno de chat é composto por prompt, resposta e uma pausa enquanto o usuário lê. O agente funciona de outra forma. Ele recebe uma instrução de sistema, a descrição das ferramentas, o histórico e, possivelmente, trechos grandes de código ou documentos. O modelo processa tudo isso no primeiro passo, e esse é um prefill pesado. Depois, o agente chama uma ferramenta, recebe o resultado, acrescenta-o ao contexto e volta a consultar o modelo. O prefixo quase não muda; só a parte final cresce.

Se o servidor trata cada chamada como independente, ele recalcula o mesmo prefixo repetidas vezes ou envia a requisição a um worker que não tem o KV-cache necessário. Subagentes paralelos agravam o problema: vários ramos compartilham o contexto comum, mas divergem na continuação e disputam a memória da GPU.

O que o Dynamo faz nesse cenário

O NVIDIA Dynamo é um framework aberto de inferência distribuída, apresentado pela empresa como sucessor do Triton Inference Server. Ele se baseia em ideias especialmente importantes para agentes: separar prefill e decode em pools distintos de GPUs, rotear requisições levando em conta o conteúdo do KV-cache e descarregar o cache da memória da GPU para camadas de armazenamento mais baratas. Roda sobre engines como vLLM, SGLang e TensorRT-LLM.

A ideia do post é somar a esses mecanismos o conceito de sessão. O scheduler sabe que uma série de chamadas pertence ao mesmo agente e pode manter o contexto dela perto da computação, em vez de tentar adivinhar coincidências a cada requisição.

O que muda para o servidor na passagem do chat para o agente:

• a unidade de agendamento é a sessão, e não a requisição individual;
• vale a pena calcular o grande prefill inicial uma só vez e reaproveitá-lo;
• chamadas repetidas com contexto crescente exigem roteamento orientado ao cache;
• subagentes paralelos geram picos de carga sobre o prefixo comum;
• manter o cache entre chamadas passa a ser uma questão de capacidade e de custo de memória.

O que verificar na sua stack

Se você roda agentes com modelos próprios, comece medindo. Veja que fatia dos tokens corresponde ao prefixo repetido e com que frequência a chamada seguinte da sessão cai no mesmo worker. Se essa fatia é alta e os acertos de cache são poucos, você está pagando por prefill desnecessário.

O segundo passo é a estabilidade do prefixo. Prompt de sistema, lista de ferramentas e ordem das mensagens devem permanecer inalterados: qualquer edição no início do contexto invalida o cache. O terceiro passo é decidir onde guardar o cache entre as chamadas e quanto você está disposto a pagar para mantê-lo enquanto o agente espera a resposta da ferramenta.

Para equipes que compram inferência como serviço, a conclusão é mais simples. Pergunte ao provedor como ele cobra e armazena o contexto em cache em sessões longas. Para agentes, essa linha da tabela de preços pesa mais na conta final do que o preço por milhão de tokens.

Os detalhes completos da implementação e as medições estão no post original do PyTorch Blog. Antes de levar as conclusões para a arquitetura, vale conferi-las com os números da fonte primária.