Otimização TensorRT-LLM: Dominando a Stack de Inferência da NVIDIA

Atualizado em 11 de dezembro de 2025

Atualização de dezembro de 2025: TensorRT-LLM alcançando mais de 10.000 tokens de saída/seg em H100 com FP8, TTFT abaixo de 100ms. Implantações em produção reportando 4x de throughput vs PyTorch nativo. Fusão de kernels combinando LayerNorm, matmuls e ativações em kernels CUDA únicos. Batching em tempo real maximizando a utilização da GPU. Atenção FP8 em Hopper/Blackwell entregando acelerações adicionais.

O TensorRT-LLM da NVIDIA oferece desempenho bruto de inferência que alternativas têm dificuldade em igualar. Em GPUs H100 com precisão FP8, o framework alcança mais de 10.000 tokens de saída por segundo em throughput máximo com latências de tempo até o primeiro token abaixo de 100 milissegundos.¹ Implantações em produção reportam melhorias de throughput de até 4x sobre inferência PyTorch nativa. O desempenho tem um custo: TensorRT-LLM requer mais expertise em configuração e ciclos de otimização mais longos do que alternativas mais amigáveis como vLLM.

Para organizações comprometidas com hardware NVIDIA e dispostas a investir tempo de engenharia em otimização, o TensorRT-LLM extrai o máximo desempenho de infraestrutura GPU cara. Compreender a arquitetura do framework, opções de quantização e parâmetros de ajuste permite que equipes construam sistemas de inferência que justificam investimentos em hardware premium através de economia de tokens superior.

Arquitetura e otimizações principais

O TensorRT-LLM é construído sobre o otimizador de inferência TensorRT da NVIDIA, estendendo o framework de compilação com otimizações específicas para transformers. A biblioteca fornece APIs Python para definição de modelos junto com componentes runtime C++ para implantação em produção.

Fusão de kernels: O TensorRT-LLM combina múltiplas operações de transformer em kernels CUDA otimizados únicos. LayerNorm, multiplicações de matrizes, adições de bias e funções de ativação executam juntas em vez de requerer lançamentos de kernel separados e transferências de memória. A fusão reduz o overhead de lançamento de kernel e elimina a materialização de tensores intermediários.²

Kernels de atenção customizados: Implementações otimizadas manualmente de atenção multi-head e grouped-query aproveitam instruções Tensor Core para throughput máximo. Variantes de Flash Attention reduzem requisitos de largura de banda de memória enquanto mantêm precisão numérica. Kernels de atenção FP8 em GPUs Hopper e Blackwell fornecem acelerações adicionais.

Batching em tempo real: O batching estático tradicional força todas as requisições em um batch a esperar pela sequência mais longa completar. O batching em tempo real adiciona novas requisições a batches em execução a cada passo de geração, processando fases de contexto e geração juntas.³ A abordagem maximiza a utilização da GPU mantendo unidades de computação ocupadas mesmo quando requisições individuais completam.

Cache KV paginado: Inspirado pela memória virtual de sistemas operacionais, a atenção paginada aloca cache KV em blocos não contíguos em vez de requerer regiões de memória contínuas.⁴ A alocação em nível de bloco permite compartilhamento de cache KV entre requisições com prefixos comuns e alcança desperdício de memória quase zero por fragmentação interna.

Comparação de desempenho: TensorRT-LLM vs vLLM

Ambos os frameworks visam inferência LLM em produção, mas diferenças arquiteturais criam perfis de desempenho distintos:

O TensorRT-LLM consistentemente supera o vLLM com configurações padrão, entregando 1.34x maior throughput em sequências curtas e 2.72x melhor tempo por token de saída em sequências longas.⁵ Em GPUs B200, a otimização mais profunda do TensorRT-LLM para arquitetura Blackwell estende ainda mais a diferença de desempenho.

O vLLM oferece vantagens em experiência do desenvolvedor:⁶ - API compatível com OpenAI para substituição direta - Implantação mais simples sem etapa de compilação - Otimização automática de modelo com padrões sensatos - Suporte de hardware mais amplo além de GPUs NVIDIA

Recomendação: Implante TensorRT-LLM quando maximizar eficiência de hardware justifica investimento em engenharia. Escolha vLLM para tempo de produção mais rápido ou quando operando em escala menor onde desempenho absoluto importa menos que velocidade de desenvolvimento.

Estratégias de quantização

O TensorRT-LLM suporta opções extensivas de quantização para trocar precisão por desempenho e eficiência de memória. Escolher o método de quantização certo depende do tamanho do batch, requisitos de precisão e hardware alvo.

Quantização FP8 (recomendada primeiro)

FP8 fornece o melhor equilíbrio de melhoria de desempenho com degradação mínima de precisão:⁷

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat fp8 \
    --kv_cache_dtype fp8 \
    --output_dir $OUTPUT_PATH

A quantização FP8 requer calibração para determinar fatores de escala apropriados. O processo de calibração executa inferência em amostras representativas para medir intervalos de ativação:

from tensorrt_llm.quantization import QuantConfig, CalibConfig

quant_config = QuantConfig(
    quant_algo="fp8",
    kv_cache_quant_algo="fp8"
)

calib_config = CalibConfig(
    calib_dataset="cnn_dailymail",
    calib_batch_size=8,
    calib_num_samples=512
)

FP8 entrega melhoria de desempenho média com impacto muito baixo na precisão e requer apenas minutos para calibração. GPUs Hopper e Blackwell fornecem suporte de hardware FP8; GPUs Ada suportam FP8 com eficiência reduzida.

INT4 AWQ para implantações com restrição de memória

Quando limites de memória restringem o tamanho do modelo, INT4 Activation-aware Weight Quantization comprime pesos para 4 bits enquanto mantém precisão aceitável:⁸

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int4_awq \
    --awq_block_size 64 \
    --tp_size 4 \
    --output_dir $OUTPUT_PATH

INT4 AWQ se destaca em cenários de batch pequeno (tamanho de batch ≤ 4) onde a inferência se torna limitada por memória. O tempo de carregamento de pesos domina a computação, então compressão agressiva de pesos fornece acelerações substanciais. Para batches grandes, a vantagem de desempenho do INT4 AWQ diminui à medida que a densidade computacional aumenta.

INT8 SmoothQuant para otimização equilibrada

SmoothQuant migra a dificuldade de quantização das ativações para os pesos, permitindo quantização INT8 efetiva sem perda significativa de precisão:

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int8_sq \
    --kv_cache_dtype int8 \
    --output_dir $OUTPUT_PATH

INT8 SmoothQuant fornece melhoria de desempenho média com impacto médio na precisão. Organizações devem tentar FP8 primeiro, voltando para INT8 SQ se os resultados FP8 não atenderem aos requisitos.

Framework de seleção de quantização

A NVIDIA recomenda a seguinte ordem de prioridade:⁹

1. FP8 - Melhor tradeoff desempenho/precisão, requer Hopper/Blackwell
2. INT8 SmoothQuant - Boa alternativa para GPUs Ada ou quando precisão FP8 for insuficiente
3. INT4 AWQ/GPTQ - Compressão máxima para cenários com restrição de memória

Para cache KV especificamente, quantização FP8 é recomendada sobre INT8 em GPUs Hopper e Ada devido ao menor impacto na precisão na maioria dos casos.

Configuração de implantação em produção

A implantação otimizada do TensorRT-LLM requer ajuste de múltiplos parâmetros baseado nas características da carga de trabalho:

Configuração de build do engine

trtllm-build \
    --checkpoint_dir $CHECKPOINT_PATH \
    --output_dir $ENGINE_PATH \
    --max_batch_size 256 \
    --max_num_tokens 8192 \
    --max_input_len 4096 \
    --max_seq_len 8192 \
    --gemm_plugin auto \
    --use_paged_context_fmha enable \
    --workers 8

max_batch_size: Padrão 256 em versões recentes. Implantações em produção alcançando throughput máximo frequentemente aumentam para 2048, aproveitando totalmente as capacidades de batching em tempo real.¹⁰

max_num_tokens: Controla o total de tokens processados por iteração de batch. Padrão 8192 equilibra throughput com consumo de memória. Reduza para implantações com restrição de memória; aumente cautelosamente com monitoramento.

use_paged_context_fmha: Habilita atenção paginada para gerenciamento eficiente de cache KV. Necessário ao usar batching em tempo real. A implementação pré-aloca memória de cache KV, requerendo aproximadamente 60% mais VRAM do que apenas os pesos do modelo.¹¹

Integração com Triton Inference Server

Implantações em produção tipicamente usam o NVIDIA Triton Inference Server com o backend TensorRT-LLM:

model_repository/
└── llama-70b/
    ├── 1/
    │   └── model.py
    ├── config.pbtxt
    └── tensorrt_llm/
        └── 1/
            ├── config.json
            └── engine/

Triton fornece orquestração multi-modelo, enfileiramento de requisições, coleta de métricas e escalabilidade nativa de Kubernetes. O container NGC pré-construído inclui backend TensorRT-LLM com batching em tempo real e suporte a cache KV paginado habilitados.

Planejamento de memória

Estime requisitos de memória antes da implantação:

VRAM Total = Pesos do Modelo + Cache KV + Memória de Ativação + Overhead de Runtime

Pesos do Modelo (FP8): Parâmetros × 1 byte
Pesos do Modelo (INT4): Parâmetros × 0.5 bytes
Cache KV: batch_size × seq_len × num_layers × 2 × hidden_dim × precision_bytes

Um modelo de 70B parâmetros em FP8 requer aproximadamente: - Pesos: 70GB - Cache KV (batch 256, seq 8192): ~120GB - Ativações + overhead: ~30GB - Total: ~220GB (3x H100 80GB ou 2x H200 141GB)

Fluxo de trabalho de ajuste de desempenho

Otimização sistemática extrai desempenho máximo de implantações TensorRT-LLM:

Fase 1: Medição de linha base

Use trtllm-bench para avaliação rápida de desempenho:

python -m tensorrt_llm.bench \
    --model_dir $ENGINE_PATH \
    --input_len 512 \
    --output_len 256 \
    --batch_size 32 \
    --num_requests 1000

O utilitário de benchmarking define parâmetros de engine ótimos automaticamente, fornecendo desempenho de linha base sem complexidade total de implantação Triton.¹²

Fase 2: Seleção de quantização

Teste FP8 primeiro contra requisitos de precisão. Se a precisão degradar além de limiares aceitáveis, avalie INT8 SQ ou INT4 AWQ. Execute benchmarks de avaliação em tarefas representativas, não apenas medições de perplexidade.

Fase 3: Otimização de tamanho de batch

Perfil de throughput através de tamanhos de batch de 1 até max_batch_size. Identifique o ponto de inflexão da curva de throughput onde batching adicional fornece retornos decrescentes. Defina max_batch_size 20-30% acima deste ponto para acomodar picos de tráfego.

Fase 4: Ajuste de cache KV

Monitore utilização de cache KV durante cargas de trabalho de produção. Se a utilização consistentemente exceder 80%, aumente max_num_tokens ou reduza max_batch_size. Se a utilização permanecer abaixo de 50%, reduza a alocação para liberar memória para batches maiores.

Fase 5: Monitoramento contínuo

Rastreie métricas chave em produção: - Tokens por segundo (throughput) - Tempo até primeiro token (latência) - Profundidade da fila (capacidade) - Utilização de cache KV (memória) - Utilização de GPU (eficiência)

Otimizações avançadas

Decodificação especulativa

TensorRT-LLM suporta decodificação especulativa usando modelos draft menores para prever múltiplos tokens verificados pelo modelo principal. A técnica fornece aceleração de 1.5-2x para cargas de trabalho compatíveis:

# Habilitar decodificação especulativa no build do engine
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

A decodificação especulativa beneficia aplicações sensíveis à latência onde tempo de conclusão importa mais que throughput. A otimização requer manter tanto modelos draft quanto alvo em memória.

Configurações multi-GPU

TensorRT-LLM suporta paralelismo de tensor (TP), paralelismo de pipeline (PP) e paralelismo de especialistas (EP) para inferência distribuída:

# Paralelismo de tensor 4 vias
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

TP divide cada camada entre GPUs, requerendo operações all-reduce em cada fronteira de camada. PP divide camadas entre GPUs em estágios de pipeline. Para inferência, TP tipicamente fornece melhor latência enquanto PP permite

[Conteúdo truncado para tradução]