NVIDIA explica como reduzir o custo de memória de agentes de IA em produção

NVIDIA explica como reduzir o custo de memória de agentes de IA em produção

Em vídeo publicado em 6 de novembro, a NVIDIA detalha cinco técnicas para que GPUs, CPUs e armazenamento parem de reservar memória cara para contexto que está parado entre uma chamada de ferramenta e outra.

Nota da redação: a data de 6 de novembro citada aqui corresponde à publicação da reportagem do The Neuron que serviu de fonte para esta matéria, não necessariamente à data de publicação do vídeo da NVIDIA, que a fonte não especifica. O leitor deve considerar a cronologia exata do vídeo como não confirmada; o conteúdo técnico descrito abaixo, porém, foi verificado na fonte.

Em vídeo publicado em 6 de novembro, a NVIDIA detalha cinco técnicas para que GPUs, CPUs e armazenamento parem de reservar memória cara para contexto que está parado entre uma chamada de ferramenta e outra.

Em vídeo recente, a NVIDIA detalha cinco técnicas para que GPUs, CPUs e armazenamento parem de reservar memória cara para contexto que está parado entre uma chamada de ferramenta e outra.

O problema: memória cara parada enquanto o agente espera

Um agente de IA escreve código, chama uma ferramenta externa e espera o resultado voltar. Durante essa espera, o contexto que ele acumulou até ali pode continuar ocupando um dos tipos de memória mais caros do data center: a HBM (memória de alta largura de banda), que fica dentro ou ao lado da GPU.

Multiplique isso por milhares de agentes lendo documentos, testando software e carregando informação de um passo para o outro, e surge um problema que comprar GPU mais rápida sozinha não resolve: memória cara demais guardando trabalho que, naquele instante, não está fazendo nada. Essa é a leitura central de um vídeo explicativo da NVIDIA sobre sua estratégia de memória para inferência, segundo reportagem do The Neuron publicada em 6 de novembro de 2026.

O argumento da empresa é que GPU, CPU, rede, armazenamento e o software que serve o modelo (a camada chamada de serving) precisam ser projetados juntos, para que mais memória sobre para trabalho ativo em vez de contexto parado.

Dois tipos de memória que todo agente consome

Rodar um modelo de linguagem exige memória para duas coisas diferentes. A primeira são os pesos do modelo (weights): os valores numéricos aprendidos durante o treinamento, que ficam fixos durante a inferência.

A segunda é o cache KV (key-value cache), que guarda cálculos intermediários de atenção dos tokens já processados, permitindo que o modelo reaproveite esse trabalho ao continuar gerando a resposta. Pense nos pesos como o equipamento fixo do modelo e no cache como o material de trabalho espalhado pela mesa.

Essa mesa fica cheia rápido. Um agente lê um documento, chama uma ferramenta, confere o resultado e decide o próximo passo, e cada etapa pode acrescentar contexto que as etapas seguintes vão precisar. Isso é diferente da função de "memória" de produto que lembra seu estilo de escrita entre conversas: aqui o assunto é a engrenagem que torna uma sessão de inferência ativa eficiente.

Cinco técnicas para não pagar por memória ociosa

O vídeo da NVIDIA descreve cinco frentes de trabalho. Nenhuma delas sozinha resolve o problema: elas se combinam na pilha de hardware e software.

Quantização (NVFP4). Representar os valores numéricos com menos bits reduz o espaço ocupado pelos pesos do modelo. O formato NVFP4 da NVIDIA usa valores de quatro bits com informação de escala adicional, e onde o modelo e o software de serving suportam, a compressão também encolhe o cache KV, sobrando mais memória de GPU para contexto e requisições simultâneas. O ganho de espaço vem com uma pergunta que pesa mais que a taxa de compressão: o modelo continua bom o bastante nas tarefas que importam?

Ainda temos que verificar.

We still have to check.NVIDIA, vídeo explicativo sobre arquitetura de memória

Para agentes isso é especialmente sensível: uma pequena perda de qualidade pode sair cara se gerar chamadas de ferramenta extras, repetições ou tarefas que falham.

Distribuir o modelo entre mais GPUs. Modelos de mixture-of-experts (mistura de especialistas) têm grupos de parâmetros especializados, os "experts", mas ativam só uma parte deles por token. Ainda assim, todos esses experts precisam morar em algum lugar. Espalhá-los entre várias GPUs reduz a fatia da memória de cada GPU ocupada pelos pesos dos experts, sobrando espaço para contexto ativo. O custo é a comunicação: os tokens precisam chegar até a GPU que tem o expert escolhido e o resultado precisa voltar, algo que interconexões rápidas como o NVLink ajudam a viabilizar, mas que não elimina o custo de mover dado entre placas.

Reaproveitar prefixos repetidos. Muitas requisições de agente compartilham material: instruções de sistema, definição de ferramentas ou o início de um documento. Reprocessar esses trechos idênticos é trabalho jogado fora. O framework de serving Dynamo, da NVIDIA, usa roteamento ciente de cache KV (KV-aware routing) para mandar a requisição para o worker que já tem o cache compatível, levando em conta também o quanto esse worker está ocupado. Mandar tudo para a máquina com melhor cache não ajuda se ela virar fila.

CPU Vera e memória de sistema. A CPU Vera, usada ao lado das GPUs Rubin, acelera a execução de chamadas de ferramenta, o que permite ao agente retomar o trabalho mais cedo. Como CPU hospedeira, ela também oferece memória de sistema próxima que pode guardar contexto descarregado, quando o software de serving está configurado para isso.

CMX e armazenamento flash compartilhado. Além de um servidor individual, o CMX da NVIDIA adiciona armazenamento flash compartilhado para contexto de inferência: servidores compatíveis podem recuperar trabalho já em cache em vez de reprocessar a mesma entrada de novo. O vídeo deixa dois limites claros: o cache precisa corresponder ao que o modelo exige, e o servidor que pede precisa ter permissão de uso. Mover contexto também leva tempo, e descarregar só compensa quando recuperar o estado salvo é mais rápido do que mantê-lo em HBM ou recalculá-lo dentro do orçamento de latência da resposta.

O número que a NVIDIA divulga, e o que ele não prova

A NVIDIA cita um resultado específico: na carga de trabalho AgentX DeepSeek V4 Pro, da SemiAnalysis, a empresa reporta até 30 vezes mais throughput por dólar para o Vera Rubin NVL72 em comparação ao GB300 NVL72, a 125 tokens por segundo por usuário, com cerca de 3% a mais de capacidade de HBM por GPU.

É um número relatado pelo próprio fabricante, para uma carga de trabalho e um ponto de operação específicos. Ele não garante que descarregar contexto para armazenamento vai tornar qualquer aplicação 30 vezes mais barata. A lição arquitetural, porém, se sustenta: capacidade de memória sozinha é um péssimo guia para economia de sistema. Isso conecta com o que a NVIDIA já havia detalhado no GTC 2026, quando apresentou a pilha Vera Rubin como conjunto, não como peça isolada.

O que muda para quem constrói agente em produção

Para times avaliando infraestrutura de agentes, as perguntas práticas importam mais que o anúncio em si:

• A quantização preserva a qualidade da tarefa, ou só reduz o custo de memória às custas de mais retries?
• Com que frequência o contexto pode ser reaproveitado de fato, dado o padrão real de prompts da aplicação?
• Descarregar contexto para CPU ou flash melhora o tempo de resposta sob concorrência real, ou só move o gargalo?
• O sistema termina mais tarefas com sucesso pelo mesmo dinheiro, ou só processa mais tokens sem terminar mais trabalho útil?

Há também um esforço paralelo acontecendo dentro dos próprios modelos: o DeepSeek V4.1 Flash, por exemplo, reduz a exigência de memória pela arquitetura do modelo, não pela infraestrutura de serving. Arquitetura de modelo e infraestrutura de serving são duas alavancas diferentes para o mesmo problema, e quem monta agente em produção provavelmente vai precisar mexer nas duas.

O recado de fundo é que esperar, lembrar e recuperar contexto viraram problemas de engenharia centrais para quem roda agente, não detalhe de implementação. Um serviço de agente bem-sucedido precisa fazer mais do que gerar token rápido: precisa carregar contexto útil durante todo o trabalho sem transformar cada pausa em uma vaga de estacionamento cara.

Fonte: The Neuron