LLM Motores de Inferência: vLLM vs LMDeploy vs SGLang
Avaliamos o desempenho de 3 dos principais motores de inferência de LLM em NVIDIA H100: vLLM, LMDeploy e SGLang. Cada motor processou cargas de trabalho idênticas: 1.000 prompts do ShareGPT usando Llama 3.1 8B-Instruct para isolar o verdadeiro impacto de desempenho das suas escolhas arquiteturais e estratégias de otimização.
Motores | Melhor para |
|---|---|
vLLM | -Prototipagem e experimentação em mais de 100 arquiteturas de modelos -Ambientes com várias GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Implantações em produção que exigem desempenho H100 com complexidade mínima -Equipes que priorizam simplicidade na instalação (instalação com um único comando pip install) |
SGLang | -Organizações que necessitam da máxima taxa de transferência absoluta (16.215 tok/s) -Clusters dedicados de inferência |
Resultados do benchmark dos motores de inferência
Medimos a taxa de transferência em lote offline em 10.000 operações de inferência totais (1.000 prompts × 10 execuções por motor) para garantir estabilidade estatística.
- Taxa de transferência: Tokens de saída gerados por segundo no modo de inferência em lote. Mede a eficiência com que cada motor utiliza os recursos de computação da H100.
Todos os motores foram configurados para o seu desempenho teórico máximo: Llama 3.1 8B-Instruct, precisão bfloat16 e 0.8 de utilização da memória da GPU em hardware H100 80GB.
Para entender como calculamos as taxas de transferência, consulte nossa metodologia de benchmark de inferência.
Principais conclusões
A nossa abordagem minimiza variáveis de confusão: modelo idêntico, hardware, conjunto de dados, configuração de amostragem, limites de memória e protocolo de aquecimento. Esse isolamento revela o que a arquitetura de cada motor realmente contribui.
A diferença arquitetural é de 29%: Mesmo quando o vLLM é otimizado com exatamente os mesmos kernels (FlashInfer) que o SGLang, ele ainda fica significativamente atrás dos líderes. O SGLang (16.215 tok/s) e o LMDeploy (16.132 tok/s) mantêm uma vantagem de 29% sobre o vLLM totalmente otimizado (12.553 tok/s). Isso indica que o gargalo não é mais o kernel matemático, mas a sobrecarga de orquestração interna do motor.
SGLang e LMDeploy estão efetivamente empatados: a diferença de desempenho entre eles é inferior a 0,6%, o que está dentro da margem de erro. Isso sugere que tanto a abordagem “Python + Kernels Nativos” (SGLang) quanto a abordagem “Motor C++ Puro” (LMDeploy) são estratégias igualmente válidas para alcançar o desempenho máximo nas arquiteturas Hopper.
GPU “zona segura” de memória com 80% de utilização: As tentativas de alocar 95% da memória da GPU causaram falhas imediatas durante a compilação do CUDA Graph em todos os motores, apesar da capacidade de 80GB. A causa raiz foi identificada como esgotamento da RAM do sistema durante a captura do gráfico, não os limites de memória da GPU. Uma fração de 0.8 proporcionou o equilíbrio ideal entre estabilidade e tamanho do lote.
Compreendendo a hierarquia de desempenho
As diferenças de taxa de transferência revelam uma clara distinção entre as arquiteturas dos motores na H100:
SGLang e LMDeploy: Esses motores alcançam ~16.200 tok/s. O SGLang consegue isso através do RadixAttention, um gerenciador de memória especializado projetado para padrões de serviço complexos. O LMDeploy consegue isso através do TurboMind, um backend C++ personalizado que elimina totalmente a sobrecarga do Python.
vLLM: Mesmo com o backend FlashInfer habilitado, o vLLM atinge picos de ~12.500 tok/s. Embora isso represente uma melhoria significativa em relação às configurações padrão, a diferença restante destaca o custo da arquitetura flexível e baseada em plugins do vLLM (PagedAttention) em comparação com os designs hiperespecializados dos líderes.
Diferenças na filosofia de arquitetura: O SGLang e o LMDeploy projetam conjuntamente seus mecanismos de atenção com suposições de kernel. O vLLM mantém uma camada de compatibilidade mais ampla que exige que os algoritmos de atenção funcionem com vários backends, o que limita a profundidade das otimizações específicas em hardware de ponta.
Otimização de padrões de acesso à memória: A diferença de 29% sugere que o SGLang e o LMDeploy otimizam a coalescência de memória, a localidade de cache e o escalonamento de lotes de forma mais agressiva do que o escalonador do vLLM permite, particularmente na forma como lidam com o Acelerador de Memória Tensor (TMA) da H100.
Metodologia do benchmark
Ambiente de teste
Configuração de hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: instância de nuvem RunPod
- Base Docker: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Versões de software:
- CUDA: 12.8.1
- PyTorch: 2.8.0
- vLLM: 0.11.0 (FlashInfer ativado)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Conjunto de dados e carga de trabalho
Origem: conjunto de dados ShareGPT_Vicuna_unfiltered do Hugging Face
Critérios de seleção:
Porquê este conjunto de dados: O ShareGPT contém conversas reais entre usuários e chatbots com variação natural de comprimento, representando com mais precisão as cargas de trabalho de chatbots em produção do que benchmarks sintéticos.
Configurações dos motores
Todos os motores foram configurados para o desempenho máximo, mantendo a justiça:
Configuração do vLLM (Backend FlashInfer):
Configuração do LMDeploy:
Configuração do SGLang:
Procedimento de medição
Protocolo padrão aplicado a todos os motores:
- Carregamento do modelo: Baixar e inicializar o modelo com precisão bfloat16.
- Fase de aquecimento: Processar 20 prompts para acionar a compilação JIT e estabilizar os clocks da GPU.
- Execuções de benchmark: Executar 10 passagens completas de todos os 1.000 prompts.
- Metodologia de cronometragem:
- Contagem de tokens: Extrair contagens reais de tokens dos formatos de saída específicos de cada motor.
- Cálculo da taxa de transferência: total_output_tokens / duração.
Rigor estatístico:
- 10.000 operações de inferência totais (1.000 prompts × 10 execuções por motor).
- ~1,5 milhões de tokens gerados por motor.
- Desvio padrão consistentemente 1% da média em todos os motores.
Interpretando os resultados
O que você pode concluir:
Para inferência em lote offline do Llama 3.1 8B em hardware H100, a eficiência arquitetural determina o vencedor. Mesmo com os melhores kernels possíveis (FlashInfer), o vLLM não consegue igualar a taxa de transferência do SGLang ou do LMDeploy. A diferença de 29% representa o custo da orquestração em Python versus a otimização nativa em C++.
A hierarquia de desempenho aplica-se exatamente a este cenário: processamento em lote de 1.000 prompts simultaneamente. O SGLang e o LMDeploy são escolhas robustas que proporcionam ~45% mais valor por hora de GPU do que as implantações padrão e ~29% mais do que as implantações altamente otimizadas do vLLM.
O que você não pode generalizar:
- Modelos diferentes: Resultados específicos para o Llama 3.1 8B. Modelos maiores (por exemplo, 70B) ou arquiteturas diferentes (por exemplo, Mixtral, Qwen) apresentarão padrões de escalonamento diferentes.
- Hardware diferente: Essas classificações aplicam-se à H100 80GB. Em A100 ou V100, a portabilidade do vLLM pode superar a especialização do SGLang.
- Métricas diferentes: Isso mede apenas a taxa de transferência. O serviço online requer TTFT e percentis de latência, onde os resultados diferem significativamente.
- Cargas de trabalho diferentes: Prompts aleatórios minimizam os benefícios do cache de prefixos. Prompts de sistema repetidos ou conversas de várias voltas alteram drasticamente o cenário de desempenho a favor do SGLang.
Comparação da experiência do desenvolvedor
Os números de desempenho não capturam o quadro completo da implantação. Cada motor oferece fluxos de trabalho de desenvolvimento distintos:
vLLM: Padrão da indústria por boas razões
Simplicidade encontra ampla compatibilidade. Um único pip install vllm suporta mais de 100 arquiteturas de modelos em hardware NVIDIA, AMD e Intel. Uma comunidade massiva significa que o Stack Overflow tem suas respostas. Servidor de API compatível com OpenAI incluído.
- Escolha o vLLM para: Prototipagem rápida, ambientes heterogêneos de GPU, cobertura máxima de modelos ou aproveitar o maior ecossistema.
LMDeploy: Produção sem atritos
A instalação com uma única linha (pip install lmdeploy) oferece 99,5% do desempenho máximo da H100. O backend nativo em C++ significa zero sobrecarga do Python. Suporte de primeira classe à quantização (AWQ, GPTQ) para otimização adicional. Sem inferno de dependências.
- Escolha o LMDeploy para implantações de produção que exigem o desempenho máximo da H100 sem sacrificar a simplicidade ou estabilidade da instalação.
SGLang: Desempenho máximo com custo de complexidade
A taxa de transferência máxima absoluta (16.215 tok/s) tem um preço: um esforço significativo na depuração da instalação do FlashInfer. Requer uma versão específica do PyTorch. Incompatibilidades binárias com algumas rodas pré-compiladas. O RadixAttention se destaca em cargas de trabalho conversacionais.
- Escolha o SGLang para: Clusters de inferência dedicados onde uma equipa especializada pode gerir as dependências e você precisa de cada último ponto percentual de taxa de transferência.
Desafios de instalação e implantação
Uma comparação justa exigiu superar obstáculos de engenharia significativos:
Desafio 1: Conflitos de dependência do FlashInfer
Problema: As rodas FlashInfer do SGLang esperam versões específicas do PyTorch, mas os contentores otimizados para H100 geralmente vêm com versões diferentes.
Resolução:
Investimento de tempo: 6 horas identificando versões compatíveis.
Conclusão: As rodas ML pré-compiladas frequentemente ocultam restrições de versão que só aparecem em tempo de execução.
Desafio 2: Habilitar o FlashInfer no vLLM
Problema: As versões padrão do vLLM geralmente não têm suporte ao FlashInfer ou exigem compilação de fonte complexa.
Avanço: Utilizamos a compilação vLLM 0.11.0 no PyTorch 2.8 Nightly. Isso permitiu com sucesso o suporte nativo ao FlashInfer via pip install “vllm[flashinfer]==0.11.0”, contornando as barreiras de compilação das versões mais antigas.
Impacto: Isso proporcionou a comparação mais justa possível, confirmando que, embora os kernels ajudem, eles não resolvem o gargalo arquitetural.
Desafio 3: Descoberta do ponto ideal de utilização de memória
Problema: A recomendação padrão de 0.9 de utilização da memória da GPU causou travamentos std::bad_alloc.
Progressão dos testes:
Descoberta: A captura do CUDA Graph aloca RAM temporária do sistema proporcional ao uso de memória da GPU. Com uma alocação de 0.9 × 80GB = 72GB de GPU, a RAM do sistema esgota-se durante a compilação.
Limite prático: 0.8 de utilização da GPU é a “zona segura” apesar da capacidade de 80GB do hardware.
Conclusão
Para a inferência em lote do Llama 3.1 8B na H100, a hierarquia de desempenho tem dois níveis claros: o vLLM (otimizado com FlashInfer) fornece uma linha de base sólida, enquanto as arquiteturas C++ nativas do SGLang e LMDeploy desbloqueiam um adicional 29% de taxa de transferência.
O SGLang (16.215 tok/s) e o LMDeploy (16.132 tok/s) alcançam taxas de transferência quase idênticas, sugerindo que ambos os motores saturam a largura de banda da memória da H100. A diferença mínima entre eles é ruído estatístico.
Para implantações em produção: O LMDeploy surge como o vencedor prático, oferecendo 99,5% da taxa de transferência máxima do SGLang com instalação trivial (pip install lmdeploy) em comparação com a complexa resolução de dependências do SGLang.
vLLM com FlashInfer (12.553 tok/s) oferece um meio-termo atraente: desempenho respeitável mantendo total compatibilidade de hardware e a maior matriz de suporte a modelos da indústria. No entanto, para clusters dedicados H100, deixar 29% de desempenho na mesa é um custo elevado.
Para padronização em infraestruturas heterogêneas ou experimentação rápida de modelos, o vLLM continua a ser a escolha racional. Para implantações dedicadas H100 onde a taxa de transferência é primordial, a combinação de desempenho máximo e simplicidade de instalação do LMDeploy é inigualável.
Adicionar como fonte preferencialPerguntas frequentes
Um motor de inferência de LLM é um software especializado que otimiza a forma como os modelos de linguagem grandes geram respostas. Embora você possa executar modelos com PyTorch ou TensorFlow básicos, os motores de inferência adicionam otimizações críticas, como gerenciamento eficiente de memória, agrupamento de várias solicitações e otimizações de kernel da GPU. Essas melhorias podem aumentar drasticamente a taxa de transferência (tokens gerados por segundo) e reduzir custos, potencialmente oferecendo um desempenho 3-5x melhor no mesmo hardware.
A inferência em lote offline processa muitos prompts simultaneamente sem requisitos de tempo real, pense em analisar milhares de documentos ou gerar embeddings para um conjunto de dados. O serviço online lida com solicitações individuais de usuários com requisitos rigorosos de latência, onde métricas como Time To First Token (TTFT) importam mais do que a taxa de transferência bruta. O motor que vence em taxa de transferência em lote pode não ser o ideal para chatbots interativos, portanto, escolha com base no seu padrão de carga de trabalho real.
Cite esta pesquisa
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{LLM Motores de Inferência: vLLM vs LMDeploy vs SGLang}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/inference-engines}},
note = {AIMultiple. Acessado em 15 Abril 2026}
}
A seguir, leia
Top 10 Software de Segurança de Endpoint
GPU Software para IA: CUDA vs. ROCm
Top 10 Soluções PAM com Alternativas Gratuitas
Top 5 Ferramentas de Monitoramento de Banco de Dados Open Source
Melhores Ferramentas de Monitoramento de Desempenho de Banco de Dados: Top 5 Plataformas Comparadas
Benchmark e Análise de Documentação de TI
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.