LLM Motores de Inferência: vLLM vs LMDeploy vs SGLang
Benchmarkamos 3 principais LLM motores de inferência em NVIDIA H100: vLLM, LMDeploy e SGLang. Cada motor processou cargas de trabalho idênticas: 1.000 prompts ShareGPT usando Llama 3.1 8B-Instruct para isolar o verdadeiro impacto de desempenho de suas escolhas arquiteturais e estratégias de otimização.
Motores | Melhor para |
|---|---|
vLLM | -Prototipagem e experimentação em 100+ arquiteturas de modelo -Ambientes multi GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Implantações de produção que exigem desempenho H100 com complexidade mínima -Equipes que priorizam simplicidade de instalação (instalação pip de uma linha) |
SGLang | -Organizações que precisam de throughput absoluto máximo (16.215 tok/s) -Clusters de inferência dedicados |
Resultados do benchmark de motores de inferência
Medimos o throughput de lote offline em 10.000 operações de inferência totais (1.000 prompts × 10 execuções por motor) para garantir estabilidade estatística.
- Throughput: Tokens de saída gerados por segundo no modo de inferência em lote. Mede quão eficientemente cada motor utiliza as capacidades de computação do H100.
Todos os motores foram configurados para seu desempenho teórico máximo: Llama 3.1 8B-Instruct, precisão bfloat16 e 0,8 GPU utilização de memória em hardware H100 80GB.
Para entender como calculamos as taxas de throughput, consulte nossa metodologia de benchmark de inferência.
Principais descobertas
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 lacuna arquitetural é de 29%: Mesmo quando o vLLM é otimizado com os mesmos kernels exatos (FlashInfer) que o SGLang, ele ainda fica significativamente atrás dos líderes. SGLang (16.215 tok/s) e 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 cai dentro da margem de erro. Isso sugere que tanto a abordagem "Python + Kernels Nativos" (SGLang) quanto a abordagem "Engine Pura C++" (LMDeploy) são estratégias igualmente válidas para alcançar o desempenho máximo nas arquiteturas Hopper.
GPU zona "segura" de memória em 80% de utilização: Tentativas de alocar 95% GPU memória causou travamentos imediatos durante a compilação do CUDA Graph em todos os motores, apesar da capacidade de 80GB. A causa raiz foi identificada como exaustão do sistema RAM durante a captura do gráfico, não GPU limites de memória. Uma fração de 0,8 forneceu o equilíbrio ideal de estabilidade e tamanho do lote.
Entendendo a hierarquia de desempenho
As diferenças de throughput revelam uma distinção clara entre as arquiteturas de motor em H100:
SGLang & LMDeploy: Esses motores atingem ~16.200 tok/s. O SGLang atinge isso via RadixAttention, um gerenciador de memória especializado projetado para padrões de serviço complexos. O LMDeploy atinge isso via TurboMind, um backend C++ personalizado que elimina completamente a sobrecarga do Python.
vLLM: Mesmo com o backend FlashInfer habilitado, o vLLM atinge o pico de ~12.500 tok/s. Embora isso seja uma melhoria massiva em relação às configurações padrão, a lacuna restante destaca o custo da arquitetura flexível e baseada em plugins do vLLM (PagedAttention) versus os designs hiper-especializados dos líderes.
Diferenças na filosofia de arquitetura: SGLang e LMDeploy co-projetam 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 de otimizações específicas em hardware de ponta.
Otimização de padrão de acesso à memória: A lacuna de 29% sugere que SGLang e LMDeploy otimizam o coalescimento de memória, a localidade do cache e o agendamento de lote de forma mais agressiva do que o agendador do vLLM permite, particularmente na forma como lidam com o H100 Tensor Memory Accelerator (TMA).
Metodologia do benchmark
Ambiente de teste
Configuração de hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: Instância de nuvem RunPod
- Docker base: 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 habilitado)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Conjunto de dados e carga de trabalho
Fonte: ShareGPT_Vicuna_unfiltered conjunto de dados de Hugging Face
Critérios de seleção:
Por que este conjunto de dados: ShareGPT contém conversas reais usuário-chatbot com variação natural de comprimento, representando com mais precisão cargas de trabalho de chatbot de produção do que benchmarks sintéticos.
Configurações do motor
Todos os motores foram configurados para máximo desempenho mantendo a justiça:
Configuração vLLM (Backend FlashInfer):
Configuração LMDeploy:
Configuração 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 relógios GPU.
- Execuções de benchmark: Executar 10 passagens completas de todos os 1.000 prompts.
- Metodologia de temporização:
- Contagem de tokens: Extrair contagens reais de tokens de formatos de saída específicos do motor.
- Cálculo de throughput: total_output_tokens / duration.
Rigor estatístico:
- 10.000 operações de inferência totais (1.000 prompts × 10 execuções por motor).
- ~1,5 milhão 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 de Llama 3.1 8B em hardware H100, a eficiência arquitetural dita o vencedor. Mesmo com os melhores kernels possíveis (FlashInfer), o vLLM não pode igualar o throughput do SGLang ou LMDeploy. A lacuna de 29% representa o custo da orquestração Python versus otimização nativa C++.
A hierarquia de desempenho se aplica a este cenário exato: processamento em lote de 1.000 prompts simultaneamente. SGLang e LMDeploy são escolhas robustas que entregam ~45% mais valor por GPU hora do que implantações padrão e ~29% mais do que implantações altamente otimizadas do vLLM.
O que você não pode generalizar:
- Modelos diferentes: Resultados específicos para Llama 3.1 8B. Modelos maiores (por exemplo, 70B) ou arquiteturas diferentes (por exemplo, Mixtral, Qwen) apresentarão padrões de dimensionamento diferentes.
- Hardware diferente: Essas classificações se aplicam a H100 80GB. Em A100 ou V100, a portabilidade do vLLM pode superar a especialização do SGLang.
- Métricas diferentes: Isso mede apenas o throughput. 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 prefixo. Prompts de sistema repetidos ou conversas de várias voltas deslocam drasticamente o cenário de desempenho em favor do SGLang.
Comparação de experiência do desenvolvedor
Números de desempenho não capturam a imagem completa de implantação. Cada motor oferece fluxos de trabalho distintos para desenvolvedores:
vLLM: Padrão da indústria por uma boa razão
Simplicidade encontra ampla compatibilidade. Instalação única pip vllm suporta 100+ arquiteturas de modelo em NVIDIA, AMD e Intel hardware. Uma comunidade enorme significa que o Stack Overflow tem suas respostas. OpenAI-compatível API servidor incluído.
- Escolha vLLM para: Prototipagem rápida, ambientes heterogêneos GPU, cobertura máxima de modelos ou aproveitar o maior ecossistema.
LMDeploy: Pronto para produção com atrito mínimo
Instalação de uma linha (pip install lmdeploy) entrega 99,5% do pico H100 desempenho. Backend C++ nativo significa zero sobrecarga Python. Suporte de primeira classe à quantização (AWQ, GPTQ) para otimização adicional. Sem inferno de dependência.
- Escolha LMDeploy para Implantações de produção que exigem máximo H100 desempenho sem sacrificar simplicidade de instalação ou estabilidade.
SGLang: Teto de desempenho com custo de complexidade
O throughput absoluto máximo (16.215 tok/s) vem a um preço: 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é-construídas. RadixAttention brilha em cargas de trabalho conversacionais.
- Escolha SGLang para: Clusters de inferência dedicados onde uma equipe especializada pode gerenciar dependências e você precisa de cada último ponto percentual de throughput.
Adicionar como fonte preferencialDesafios de instalação e implantação
A comparação justa exigiu superar obstáculos de engenharia significativos:
Desafio 1: Conflitos de dependência FlashInfer
Problema: As rodas FlashInfer do SGLang esperam versões específicas do PyTorch, mas H100-contêineres otimizados muitas vezes enviam versões diferentes.
Resolução:
Investimento de tempo: 6 horas identificando versões compatíveis.
Conclusão: Rodas ML pré-compiladas muitas vezes escondem restrições de versão que só surgem em tempo de execução.
Desafio 2: Habilitando FlashInfer no vLLM
Problema: Versões padrão do vLLM muitas vezes não têm suporte FlashInfer ou exigem compilação complexa de origem.
Avanço: Utilizamos a versão vLLM 0.11.0 no PyTorch 2.8 Nightly. Isso habilitou com sucesso o suporte nativo do FlashInfer via pip install "vllm[flashinfer]==0.11.0", contornando as barreiras de compilação de versões mais antigas.
Impacto: Isso forneceu 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 GPU utilização de memória causou std::bad_alloc travamentos.
Progressão dos testes:
Descoberta: A captura do CUDA Graph aloca sistema temporário RAM proporcional ao uso de memória do GPU. Em 0,9 × 80GB = 72GB GPU alocação, o sistema RAM é esgotado durante a compilação.
Limite prático: 0,8 GPU utilização é a "zona segura" apesar da capacidade de hardware de 80GB.
Conclusão
Para Llama 3.1 8B inferência em lote em H100, a hierarquia de desempenho tem dois níveis claros: vLLM (otimizado com FlashInfer) fornece uma base sólida, enquanto as arquiteturas nativas C++ do SGLang e LMDeploy desbloqueiam um adicional 29% em throughput.
SGLang (16.215 tok/s) e LMDeploy (16.132 tok/s) atingem throughput quase idêntico, sugerindo que ambos os motores saturam a largura de banda de memória do H100. A lacuna mínima entre eles é ruído estatístico.
Para implantações de produção: LMDeploy surge como o vencedor prático, entregando 99,5% do throughput máximo do SGLang com instalação trivial (pip install lmdeploy) versus resolução complexa de dependências do SGLang.
vLLM com FlashInfer (12.553 tok/s) oferece um meio-termo atraente: desempenho respeitável enquanto mantém compatibilidade total de hardware e a maior matriz de suporte de modelos da indústria. No entanto, para H100 clusters dedicados, deixar 29% de desempenho na mesa é um custo alto.
Para padronização em infraestrutura heterogênea ou experimentação rápida de modelos, o vLLM permanece a escolha racional. Para H100 implantações dedicadas onde o throughput é primordial, a combinação de desempenho máximo e simplicidade de instalação do LMDeploy é inigualável.
Perguntas frequentes
Um LLM motor de inferência é um software especializado que otimiza como grandes modelos de linguagem 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 juntas e GPU otimizações de kernel. Essas melhorias podem aumentar drasticamente o throughput (tokens gerados por segundo) e reduzir custos, potencialmente entregando 3-5x melhor desempenho no mesmo hardware.
A inferência em lote offline processa muitos prompts simultaneamente sem requisitos em 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 estritos de latência, onde métricas como Time To First Token (TTFT) importam mais do que o throughput bruto. O motor que vence no throughput em lote pode não ser ideal para chatbots interativos, então escolha com base no padrão real de sua carga de trabalho
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}
}
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.