Olá, é um prazer inenarrável estar mais uma vez escrevendo este post.
Tempo de leitura: 5 minutos
À medida que modelos de linguagem passam a processar prompts privados, dados empresariais e informações reguladas, proteger os dados durante a inferência deixa de ser uma preocupação distante. Em um artigo publicado em 22 de setembro de 2026, a NVIDIA mostrou como a computação confidencial pode ser aplicada à inferência de IA em produção sem transformar segurança em um obstáculo inevitável ao desempenho.
A questão é que ativar uma camada de proteção não funciona como apertar um botão. A criptografia da memória, as mudanças no transporte de dados e as limitações na comunicação entre GPUs alteram premissas que os frameworks de inferência normalmente assumem. O resultado depende, portanto, de uma combinação entre hardware protegido e software preparado para trabalhar nesse ambiente.
Por que a computação confidencial importa na inferência de IA
A computação confidencial busca proteger os dados enquanto eles estão sendo processados, e não apenas quando estão armazenados ou sendo transmitidos. No cenário descrito pela NVIDIA, a arquitetura combina máquinas virtuais confidenciais, GPUs confidenciais Blackwell e comunicação criptografada por NVIDIA NVLink.
Essa abordagem pode ser relevante para empresas que executam modelos próprios, atendem setores regulados ou precisam enviar informações sensíveis a um serviço de inferência. O objetivo é reduzir a exposição de prompts, contexto empresarial e pesos de modelos durante a execução.
Mas existe uma contradição interessante: quanto mais protegido é o caminho dos dados, menos o sistema pode depender de atalhos tradicionais de desempenho. É nesse ponto que a computação confidencial deixa de ser apenas uma configuração de infraestrutura e passa a exigir ajustes no framework de inferência.
Como a computação confidencial altera o caminho da inferência
Para avaliar o impacto da computação confidencial, a equipe de engenharia de desempenho da NVIDIA comparou a mesma carga com o recurso desativado e ativado. O modelo, o hardware, a versão do framework, os tamanhos das sequências, o paralelismo e a concorrência foram mantidos constantes.
O teste usou um sistema NVIDIA DGX B200 com oito GPUs NVIDIA B200, Intel TDX, TensorRT LLM e paralelismo tensorial com TP=8. A carga tinha uma entrada longa de 32 mil tokens, saída de mil tokens e níveis de concorrência entre 1 e 16. Esse tipo de configuração torna mais visíveis os custos de movimentação de dados e o pequeno atraso acumulado a cada token.
A escolha da carga é importante. Muitas requisições simultâneas podem esconder parte do custo da criptografia ao sobrepor diferentes tarefas. Já uma entrada extensa, uma geração prolongada e baixa concorrência expõem melhor os efeitos da proteção, como uma lanterna apontada para as partes mais estreitas do sistema.
Resultados medidos com a computação confidencial ativada
Nos testes apresentados, a computação confidencial manteve entre 96,1% e 98,2% do throughput de tokens de saída observado com o recurso desativado, considerando os níveis de concorrência avaliados.
O tempo médio por token de saída, conhecido como TPOT, apresentou uma sobrecarga de 1,2% a 4,3%. Em outras palavras, houve perda de desempenho, mas ela permaneceu abaixo de 5% nessa configuração específica com oito GPUs B200.
Esses números não devem ser interpretados como uma garantia para qualquer aplicação. Eles representam uma medição controlada, baseada em um modelo, uma versão de software, um hardware e uma carga de trabalho determinados. Uma implantação diferente pode produzir resultados distintos, especialmente se houver outros tamanhos de contexto, padrões de concorrência ou formas de paralelismo.
Quais ajustes reduzem o custo da computação confidencial
Movimentação entre memória da CPU e da GPU
Na configuração analisada, as transferências entre host e dispositivo passam por um buffer intermediário protegido porque a GPU não acessa diretamente a memória protegida da máquina virtual confidencial. Isso muda o comportamento esperado da memória fixada, que normalmente ajuda a realizar transferências assíncronas.
Como resposta, o TensorRT LLM seleciona tipos de memória de forma consciente em relação à computação confidencial, usando memória paginável em caminhos afetados. Para transferências da GPU de volta ao host, o framework desloca leituras repetidas de tokens e dados de amostragem para um trabalhador assíncrono, evitando bloquear o agendador principal durante a geração.
Estabilidade do autotuner
O autotuner do kernel compara diferentes estratégias de execução usando medições de tempo. Segundo a NVIDIA, os registros produzidos por eventos CUDA podem se tornar instáveis nesse ambiente protegido e levar o sistema a escolher uma alternativa mais lenta.
Para contornar o problema, o TensorRT LLM usa o %globaltimer da GPU para medir as estratégias quando a computação confidencial está ativa, mantendo os eventos CUDA fora desse modo.
Comunicação entre múltiplas GPUs
Outro ponto envolve a comunicação entre GPUs. O multicast NVLS, associado ao NVLink SHARP, não está disponível nas configurações B200 avaliadas com proteção confidencial. Além disso, determinados caminhos de comunicação podem continuar pagando custos de registro de memória e sincronização sem obter o benefício esperado do multicast.
Por isso, frameworks preparados para computação confidencial precisam detectar os recursos disponíveis e escolher algoritmos de comunicação de acordo com o tamanho das mensagens, a topologia e as características da carga.
O que os resultados significam para projetos de computação confidencial
A principal conclusão é que segurança e desempenho não devem ser tratados como decisões separadas. Ativar a computação confidencial sem verificar o comportamento do framework pode produzir custos desnecessários, enquanto adaptar o software ao ambiente protegido ajuda a preservar boa parte do desempenho original.
Para equipes que planejam colocar inferência privada em produção, a NVIDIA recomenda habilitar a proteção, atestar o ambiente e comparar os modos ativado e desativado usando exatamente a carga que será atendida. Também é importante registrar versões de driver, sistema operacional, CUDA, TensorRT LLM, NCCL e configuração de hardware, pois pequenas mudanças podem alterar o resultado.
Essa preocupação com throughput e comunicação também aparece em soluções de inferência multi-GPU com TensorRT e Dynamo-Triton, nas quais a distribuição do modelo exige que o caminho entre GPUs seja planejado com cuidado.
Conclusão: computação confidencial exige engenharia de ponta a ponta
Os testes divulgados pela NVIDIA indicam que a computação confidencial pode proteger modelos, prompts e contexto sensível mantendo mais de 96% do throughput de referência e uma sobrecarga de latência inferior a 5% na configuração avaliada. O resultado é promissor, mas não elimina a necessidade de medir cada implantação.
A resposta à pergunta do início é, portanto, menos simples do que “segurança custa desempenho”. A computação confidencial muda o funcionamento interno da inferência, mas frameworks adaptados podem reduzir boa parte desse impacto. O caminho mais seguro é tratar proteção, atestação, comunicação entre GPUs e otimização do runtime como um único problema de engenharia.
Antes de levar uma solução privada para produção, vale testar o workload real, comparar métricas com e sem proteção e confirmar se as otimizações escolhidas continuam válidas no hardware disponível. Em IA, o ambiente seguro não é o fim da otimização: é o novo ponto de partida.
