vLLM vs SGLang 2026: Testámos Ambos em H100s

vLLM vs SGLang 2026: Testámos Ambos em H100s

A Hugging Face colocou o TGI em modo de manutenção em dezembro de 2025 e agora orienta as equipas para o vLLM ou o SGLang para novas implementações. Se está a montar uma stack de inferência hoje, a verdadeira questão não é «devo abandonar o TGI?», mas sim qual destes dois motores se adapta realmente à sua carga de trabalho.

Resumo Rápido

Escolha o vLLM se quiser o suporte de hardware mais abrangente, a maior comunidade e um caminho testado para produção na AWS, GCP e Azure.

Escolha o SGLang se a sua carga de trabalho for intensiva em conversas multi-turno, saídas estruturadas ou pipelines com muitos prefixos, como RAG, e se estiver confortável com um ecossistema mais pequeno.

Vamos agora detalhar onde cada motor realmente se destaca.

Como Chegámos Aqui? A Saída do TGI

O Text Generation Inference (TGI) sustentou o ecossistema da Hugging Face durante anos, mas desde dezembro de 2025 apenas aceita correções de bugs, sem novas funcionalidades. Os Inference Endpoints da própria Hugging Face usam agora o vLLM por defeito, com o SGLang como alternativa.

Isso deixa dois verdadeiros candidatos para o serving de LLM autoalojado. Ambos são de código aberto, ambos falam a API OpenAI e ambos funcionam em GPUs NVIDIA. As diferenças aparecem sob carga.

Veredito: Tanto o vLLM como o SGLang são substitutos do TGI prontos para produção. Se está a migrar, qualquer um deles é uma aposta segura; o resto deste guia ajuda-o a escolher qual.

Benchmarks de Throughput e Latência

Os benchmarks variam conforme o modelo, a GPU e a concorrência, por isso aqui estão números de testes independentes no mesmo hardware. Os dados seguintes provêm dos benchmarks H100 da Spheron usando o Llama 3.3 70B Instruct em FP8 e dos testes da PremAI com o Llama 3.1 8B.

Llama 3.3 70B em H100 (FP8)

Llama 3.1 8B em H100

Em modelos mais pequenos, a diferença aumenta. A PremAI mediu o SGLang em cerca de 16.200 tok/s contra 12.500 tok/s do vLLM, uma vantagem de throughput de 29% para o SGLang. O LMDeploy empatou com o SGLang aqui, mas isso é outra conversa.

O Que Significam os Números

Na escala de 70B, a diferença é modesta (3-5%). Na escala de 8B, é significativa. O padrão faz sentido: o RadixAttention do SGLang compensa mais quando o prefill representa uma fração maior do custo total, o que acontece com modelos mais pequenos e saídas mais curtas.

A latência de cauda conta uma história semelhante. O TTFT p95 do SGLang foi consistentemente 5-8% mais baixo que o do vLLM em todos os níveis de concorrência testados. Se está a construir uma interface de chat em tempo real onde cada 50ms importa, essa diferença acumula-se entre utilizadores.

Veredito: O SGLang vence em throughput bruto, especialmente para modelos mais pequenos. O vLLM fica perto na escala de 70B+. Para a maioria das cargas de trabalho de produção, a diferença é de dígitos únicos, significativa à escala, mas não um impeditivo em nenhum dos casos.

Cache de Prefixos: RadixAttention vs Cache Automático de Prefixos

Ambos os motores armazenam em cache os cálculos KV para prefixos repetidos, mas os mecanismos diferem de formas importantes para certas cargas de trabalho. Se já está familiarizado com cache de prompts ao nível da API, pense nisto como a versão do lado do servidor.

O vLLM usa hashing ao nível do bloco. Divide a cache KV em blocos de tamanho fixo, cria hashes e procura correspondências em novos pedidos. É previsível, eficiente e fácil de compreender, mas precisa de limites de bloco consistentes para obter acertos na cache.

O SGLang usa uma árvore radix indexada ao nível do token. Descobre automaticamente prefixos partilhados entre pedidos sem configuração manual. Se 50 utilizadores enviarem mensagens no mesmo fio de conversa, o SGLang encontra e reutiliza o prefixo comum automaticamente.

Onde Realmente Importa

A RunPod testou conversas multi-turno e descobriu que o SGLang entregava consistentemente ~30-31 tok/s sob alta concorrência, enquanto o vLLM caía de 22 para 16 tok/s à medida que a pressão na cache aumentava. Essa é uma diferença significativa para cargas de trabalho de chatbots e agentes.

Para inferência em lote com prompts modelados, onde cada pedido usa o mesmo prompt de sistema, a abordagem do vLLM funciona bem. Os limites da cache alinham-se naturalmente com a estrutura do seu modelo.

Veredito: O SGLang vence para cargas de trabalho dinâmicas e multi-turno. O vLLM é perfeitamente adequado para inferência em lote e prompts modelados onde os prefixos são previsíveis.

Saídas Estruturadas

Se precisa de imposição de esquema JSON ou geração condicionada, esta secção é muito importante. Ambos os motores suportam saídas estruturadas através de backends de gramática como XGrammar e LLGuidance, mas a história de desempenho é muito diferente.

A SqueezeBits realizou benchmarks detalhados e descobriu que o vLLM mostra degradação significativa do throughput com a decodificação guiada ativada, especialmente em tamanhos de lote de 8 e superiores. O SGLang, por outro lado, sobrepõe a geração de máscaras com a etapa de inferência na GPU, mantendo a sobrecarga mínima.

Esquemas Repetitivos vs Dinâmicos

A escolha do backend também importa:

Sem imposição estruturada, as saídas caem para ~61% de correção em esquemas complexos. Com ela, a correção salta 20-25 pontos percentuais. Portanto, isto não é opcional para fluxos de trabalho de agentes de produção, e o motor que escolher determina quanto throughput sacrifica.

Veredito: O SGLang vence para saídas estruturadas. Se o seu pipeline depende da imposição de esquema JSON (e a maioria dos fluxos de trabalho de agentes depende), a abordagem sobreposta do SGLang significa que não paga um imposto de throughput.

Serving de Modelos Multi-LoRA e Ajustados

Ambos os motores suportam o serving de múltiplos adaptadores LoRA a partir de um único modelo base, o que é essencial se ajustar modelos para diferentes inquilinos ou tarefas.

O SGLang trata o multi-LoRA como uma funcionalidade de primeira classe com loteamento nativo; os pedidos direcionados a diferentes adaptadores podem partilhar o mesmo lote. O vLLM também suporta, mas a implementação do SGLang tem sido ligeiramente mais polida nas versões recentes.

A diferença prática? Se estiver a servir 5-10 adaptadores LoRA a partir de um modelo base Llama 70B, ambos funcionam. Se estiver a executar 50+ adaptadores com padrões de tráfego heterogéneos, o loteamento nativo do SGLang gere o agendamento com mais graça.

Veredito: O SGLang tem uma ligeira vantagem para multi-LoRA à escala. Para um punhado de adaptadores, ambos os motores funcionam igualmente bem.

Decodificação Especulativa

Ambos os motores suportam decodificação especulativa, que usa um pequeno modelo de «rascunho» para prever tokens que o modelo principal verifica depois em paralelo. O resultado é uma inferência 2-3x mais rápida em cenários limitados pela memória.

O vLLM introduziu recentemente o Unified Parallel Drafting, e a decodificação especulativa funciona agora em conjunto com saídas estruturadas. A implementação do SGLang é similar em capacidade, com desempenho ligeiramente melhor em níveis de concorrência moderados.

O verdadeiro diferenciador não é o motor, mas sim se a decodificação especulativa se adequa à sua carga de trabalho. Ajuda mais com saídas longas de modelos grandes onde o gargalo é a largura de banda da memória, não o computo.

Veredito: Empate. Ambos os motores oferecem acelerações comparáveis na decodificação especulativa.

Suporte de Hardware e Implementação

É aqui que o vLLM se destaca significativamente.

vLLM

• GPUs NVIDIA (A100, H100, H200, B200)
• GPUs AMD (MI250, MI300X)
• GPUs Intel (via vllm-xpu-kernels)
• AWS Trainium e Inferentia
• Google TPUs
• Documentação Kubernetes madura com gráficos Helm, sondas de arranque/prontidão/vitalidade
• Integração com NVIDIA Container Toolkit pronta a usar

SGLang

• GPUs NVIDIA (A100, H100, H200, B200)
• GPUs AMD (MI300X, via ROCm)
• Implementação com prioridade ao Docker
• Kubernetes é possível, mas menos documentado

Se está a implementar em qualquer coisa que não seja NVIDIA ou AMD, o vLLM é a sua única opção. Especificamente na AWS, o suporte para Trainium significa que pode reduzir significativamente os custos de inferência, e o SGLang não consegue aceder a esse hardware.

Para equipas a operar em GPUs NVIDIA standard, a história de implementação é similar. Ambos fornecem imagens Docker e endpoints compatíveis com OpenAI. O vLLM apenas tem mais guias de produção testados e gráficos Helm contribuídos pela comunidade.

Se está a explorar ferramentas para executar LLMs localmente ou quer uma visão mais ampla da inferência autoalojada, ambos os motores suportam implementação local em GPUs de consumo também, embora sejam projetados para hardware de datacenter.

Veredito: O vLLM vence em amplitude de hardware e maturidade de implementação. O SGLang serve se estiver em NVIDIA ou AMD. Em qualquer outro lugar, o vLLM é a única escolha.

Serving Desagregado

Ambos os motores suportam a separação do prefill (intensivo em computo) do decode (intensivo em memória) em pools de workers diferentes. Isto permite escalar cada fase independentemente: mais workers de prefill durante picos de prompts, mais workers de decode para gerações longas.

O SGLang suporta Mooncake e NIXL como backends de transferência para desagregação e publicou resultados mostrando 2,7x mais throughput de decodificação em clusters NVIDIA GB200 NVL72. O serving desagregado do vLLM também é funcional, embora menos documentado proeminentemente.

Esta funcionalidade importa mais à escala muito grande (96+ GPUs). Se está a executar um punhado de GPUs, provavelmente ainda não precisa disto.

Veredito: O SGLang tem uma ligeira vantagem na maturidade do serving desagregado. Ambos suportam; o SGLang publicou mais resultados do mundo real.

Quando Usar Cada Um: Framework de Decisão

A resposta honesta para muitas equipas: experimente ambos. São ambos de código aberto, ambos expõem a mesma API OpenAI, e mudar entre eles é trocar um contentor. Execute a sua carga de trabalho real em cada um durante um dia e compare as métricas que importam para si.

Se está a encaminhar tráfego através de múltiplos backends de inferência, um gateway LLM pode ficar à frente de qualquer motor e lidar com failover, limitação de taxa e observabilidade.

Como a Techsy Aborda a Seleção de Servidor de Inferência

Quando ajudamos equipas a implementar funcionalidades alimentadas por LLM, a escolha do motor de inferência resume-se a três perguntas:

1. Em que hardware está preso? Se for Trainium ou TPUs, é vLLM. Para todo o resto, ambos funcionam.
2. Qual é a forma da sua carga de trabalho? Chat multi-turno e loops de agentes favorecem a cache de prefixos do SGLang. Processamento em lote e conclusões simples funcionam bem em qualquer um.
3. Quanta capacidade operacional tem? A comunidade maior do vLLM significa mais respostas no StackOverflow e gráficos Helm quando algo falha às 3 da manhã.

Executámos cargas de trabalho de produção em ambos. Estão genuinamente próximos. A resposta certa depende das suas restrições, não de um ser «melhor» no abstrato.

Precisa de ajuda para escolher ou implementar um servidor de inferência? Contacte-nos, avaliaremos a sua carga de trabalho e recomendaremos a stack certa.

Escolher uma ferramenta é a parte fácil. Fazê-la funcionar de forma fiável dentro de um produto real é onde a maioria das equipas empaca, e é exatamente isso que a nossa equipa de integração de IA constrói para clientes, desde pipelines RAG até agentes personalizados.

Perguntas Frequentes

O SGLang é mais rápido que o vLLM?

Em modelos mais pequenos (7B-8B), o SGLang mostra cerca de 29% mais throughput em GPUs H100. Em modelos de 70B+, a diferença reduz-se para 3-5%. O SGLang também tem menor latência de cauda (TTFT p95) em todos os níveis de concorrência testados.

Posso usar vLLM e SGLang com o formato da API OpenAI?

Sim. Ambos expõem endpoints compatíveis com OpenAI prontos a usar. Pode trocar um pelo outro sem alterar o código do seu cliente. As suas chamadas /v1/chat/completions funcionam identicamente em qualquer um.

Por que razão a Hugging Face descontinuou o TGI?

O TGI entrou em modo de manutenção em dezembro de 2025. A Hugging Face decidiu contribuir para o vLLM e SGLang em vez de manter um motor de inferência separado. O TGI ainda funciona para implementações existentes, mas não virão novas funcionalidades.

O SGLang suporta GPUs NVIDIA e AMD?

O SGLang suporta GPUs NVIDIA (A100, H100, H200, B200) e GPUs AMD (MI300X via ROCm). Não suporta GPUs Intel, AWS Trainium, Inferentia ou Google TPUs. O vLLM tem uma cobertura de hardware mais ampla.

O que é o RadixAttention e por que importa?

RadixAttention é o mecanismo de cache de prefixos do SGLang. Armazena entradas da cache KV numa árvore radix indexada ao nível do token, descobrindo automaticamente prefixos partilhados entre pedidos. Isto torna as conversas multi-turno e os pipelines RAG significativamente mais rápidos porque o contexto repetido não precisa de ser recalculado.

Qual motor é melhor para saídas JSON estruturadas?

SGLang. Sobrepõe a geração de máscaras de gramática com a inferência na GPU, por isso a imposição de saída estruturada mal impacta o throughput. O vLLM mostra degradação notável em tamanhos de lote de 8 e superiores quando a decodificação guiada está ativada.

Posso servir múltiplos adaptadores LoRA a partir de um modelo base?

Ambos os motores suportam serving multi-LoRA. O SGLang trata-o como uma funcionalidade nativa com loteamento entre diferentes adaptadores no mesmo lote de pedidos. O vLLM também suporta, mas o agendamento do SGLang é mais eficiente com contagens elevadas de adaptadores.

O que é o serving prefill/decode desagregado?

Significa executar a fase de prefill (processamento do prompt) em workers GPU separados da fase de decode (geração de tokens). O prefill é limitado pelo computo; o decode é limitado pela memória. Separá-los permite escalar cada um independentemente. Ambos os motores suportam isto, com o SGLang a ter mais resultados de produção publicados.

Como migro do TGI para vLLM ou SGLang?

Como todos os três expõem APIs compatíveis com OpenAI, a migração é principalmente uma troca de contentor. Aponte a sua implementação Docker Compose ou Kubernetes para a nova imagem, ajuste as flags de carregamento do modelo e atualize os endpoints de verificação de saúde. O código do cliente mantém-se igual.

Devo usar vLLM ou SGLang para um pipeline RAG?

O SGLang é a escolha mais forte para RAG. O seu RadixAttention armazena em cache e reutiliza automaticamente os longos prompts de sistema e contextos de documento que os pipelines RAG enviam repetidamente. A cache ao nível do bloco do vLLM também funciona, mas verá melhores taxas de acerto na cache com a abordagem ao nível do token do SGLang quando os fragmentos de documento variam ligeiramente entre pedidos.

Veredito Final

O SGLang vence mais categorias, mas as vantagens do vLLM, amplitude de hardware e maturidade do ecossistema, são o tipo de coisas que importam às 3 da manhã quando um nó falha.

Se está em hardware NVIDIA e a sua carga de trabalho envolve conversas multi-turno, agentes com saídas estruturadas ou pipelines RAG com prefixos partilhados, comece com o SGLang. Obterá melhor throughput e menor latência onde mais conta.

Se precisa de flexibilidade multi-cloud, suporte de hardware não-NVIDIA ou o conforto da maior comunidade de serving LLM de código aberto, comece com o vLLM. É o padrão mais seguro que servirá bem a maioria das equipas.

De qualquer forma, ambos os motores são excelentes e melhoram rapidamente. Escolha um, implemente-o, meça a sua carga de trabalho real e mude se os números lhe disserem para o fazer. A API compatível com OpenAI torna essa mudança indolor.

Fontes

• Benchmarks H100 da Spheron: vLLM vs TensorRT-LLM vs SGLang
• PremAI: Benchmarks vLLM vs SGLang vs LMDeploy
• SqueezeBits: Desempenho de Decodificação Guiada no vLLM e SGLang
• RunPod: Reutilização de Cache KV SGLang vs vLLM
• Documentação Oficial do SGLang
• Documentação Oficial do vLLM