Serving stacks: vLLM, SGLang e TensorRT-LLM

1

Conceito

Um serving engine é mais que biblioteca de multiplicação de matrizes. Ele carrega checkpoints, escolhe kernels, distribui pesos, aloca KV state, agrupa requisições mutáveis, aplica decoding, expõe APIs, faz streaming, registra métricas e recupera falhas. vLLM, SGLang e TensorRT-LLM cobrem peças sobrepostas com centros de design diferentes.

vLLM cresceu ao redor de PagedAttention e scheduling por iteração. KV em blocos e continuous batching buscam utilização alta com comprimentos variáveis. Oferece APIs familiares e ecossistema amplo de modelos abertos. Features como tensor parallelism, prefix caching, adapters, quantização e speculation dependem da versão e arquitetura; confira a matriz de suporte da versão fixada.

SGLang combina linguagem frontend para programas estruturados com runtime. Aplicações executam prompts repetidos, geração ramificada, ferramentas ou workflows multi-call com prefixos comuns. Representar essa estrutura permite reuse e scheduling entre etapas. SGLang também serve APIs convencionais; sua ideia distinta é que programas de inferência têm estrutura além de strings isoladas.

TensorRT-LLM é stack centrado em NVIDIA com kernels otimizados, building de engines, quantização, in-flight batching e multi-GPU. Integração apertada libera features do hardware, mas exige GPUs, CUDA, drivers, definições de modelo, plugins e build compatíveis. Uma engine otimizada para certo shape talvez precise ser refeita quando as premissas mudam.

Esses resumos envelhecem depressa. Compare capacidades na documentação oficial e na versão implantada. “Suporta modelo X” pode excluir uma variante, adapter, cache dtype, decoder restrito ou formato. Fallback silencioso pode ser correto e lento; combinação sem suporte deve falhar claramente, não gerar saída sutilmente errada.

Seleção começa por corretude. Verifique tokenizer e chat template, logits ou saídas determinísticas, stops, tool schemas, constraints e posições longas. Depois teste o workload: distribuição de prompts e saídas, concorrência, streaming, cancelamento, repetição de prefixos e adapters.

Performance tem vários eixos. TTFT premia admissão e prefill. Inter-token latency importa na leitura. Request throughput define capacidade. Goodput conta somente requisições dentro do SLO. Folga de memória determina tolerância a rajadas. Um batch ou máximo do fabricante não responde tudo.

Operação decide muito. Examine métricas, traces, request IDs, health checks, rolling upgrades, model load, cleanup, backpressure, admission, multi-tenancy e isolamento. Tamanho do container e cold start pesam em autoscaling. Um pequeno ganho de kernel não compensa uma engine impossível de diagnosticar.

A arquitetura pode misturar stacks. Batch offline valoriza throughput; interação valoriza tail latency. Um router direciona modelos a engines, mas cada runtime amplia testes e observabilidade. Padronize o contrato da aplicação e mantenha testes específicos.

Planeje também upgrades. Checkpoints, drivers, kernels e formatos evoluem em ritmos diferentes. Faça canary com tráfego representativo, compare distribuição das saídas e preserve rollback do runtime e do artefato. Um upgrade que melhora média e piora cancelamento, uso de cache ou percentis de uma classe crítica não cumpre o contrato. Capacidade declarada só vale junto com evidência da versão exata.

A regra durável é empírica. Primeiro confirme features e corretude. Depois meça versões fixas no hardware-alvo com carga representativa e decoding igual. Por fim avalie ownership operacional. A melhor stack não é a do maior número de pico, mas a que cumpre previsivelmente qualidade e latência.