Mecanismos de inferência LLM: vLLM vs LMDeploy vs SGLang
Realizamos testes comparativos com 3 mecanismos de inferência LLM líderes no H100: vLLM, LMDeploy e SGLang. Cada mecanismo processou cargas de trabalho idênticas: 1.000 solicitações ShareGPT usando Llama 3.1 8B-Instruct para isolar o verdadeiro impacto de desempenho de suas escolhas arquitetônicas e estratégias de otimização.
Motores | Ideal para |
|---|---|
vLLM | -Prototipagem e experimentação em mais de 100 arquiteturas de modelos -Ambientes com múltiplas GPUs (NVIDIA, AMD, Intel) |
LMDeploy | -Implantações de produção que exigem desempenho H100 com complexidade mínima -Equipes priorizando a simplicidade de instalação (instalação pip em uma linha) |
SGLang | -Organizações que necessitam de taxa de transferência máxima absoluta (16.215 tok/s) -Clusters de inferência dedicados |
Resultados de benchmark de mecanismos de inferência
Medimos a taxa de transferência em lote offline em um total de 10.000 operações de inferência (1.000 solicitações × 10 execuções por mecanismo) para garantir a 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 mecanismo utiliza os recursos 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 utilização de memória da GPU de 0,8 em hardware H100 de 80 GB.
Para entender como calculamos as taxas de transferência, consulte nossa metodologia de benchmark de inferência.
Principais conclusões
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 a verdadeira contribuição da arquitetura de cada mecanismo.
A diferença arquitetônica é de 29%: mesmo quando o vLLM é otimizado com os mesmos kernels (FlashInfer) do 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 mecanismo.
SGLang e LMDeploy estão praticamente 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 máximo desempenho em arquiteturas Hopper.
Zona segura de memória da GPU com 80% de utilização: Tentativas de alocar 95% da memória da GPU causaram travamentos imediatos durante a compilação de grafos CUDA em todos os mecanismos, apesar da capacidade de 80 GB. A causa raiz foi identificada como esgotamento da RAM do sistema durante a captura do grafo, e não como limites de memória da GPU. Uma fração de 0,8 proporcionou o equilíbrio ideal entre estabilidade e tamanho do lote.
Entendendo a hierarquia de desempenho
As diferenças de desempenho revelam uma clara distinção entre as arquiteturas de motor no H100:
SGLang e LMDeploy: Esses mecanismos atingem aproximadamente 16.200 tok/s. O SGLang alcança isso por meio do RadixAttention , um gerenciador de memória especializado projetado para padrões de serviço complexos. O LMDeploy alcança isso por meio do TurboMind , um backend personalizado em C++ que elimina completamente a sobrecarga do Python.
vLLM: Mesmo com o backend FlashInfer ativado, o vLLM atinge um pico de aproximadamente 12.500 tok/s. Embora isso represente uma melhoria significativa em relação às configurações padrão, a diferença restante evidencia o custo da arquitetura flexível e baseada em plugins do vLLM (PagedAttention) em comparação com os designs hiperespecializados dos líderes de mercado.
Diferenças na filosofia de arquitetura: SGLang e LMDeploy projetam seus mecanismos de atenção em conjunto com base em pressupostos do 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 do padrão 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 agendamento em lote de forma mais agressiva do que o agendador do vLLM permite, particularmente na forma como lidam com o Acelerador de Memória Tensorial (TMA) do H100.
Metodologia de referência
Ambiente de teste
Configuração de hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: instância de nuvem RunPod
- Base do 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
Fonte: Conjunto de dados ShareGPT_Vicuna_unfiltered da Hugging Face
Critérios de seleção:
Por que este conjunto de dados: O ShareGPT contém conversas reais entre usuários e chatbots com variação natural de duração, representando com mais precisão as cargas de trabalho de chatbots em produção do que benchmarks sintéticos.
Configurações do motor
Todos os motores foram configurados para obter o máximo desempenho, mantendo a imparcialidade:
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: Faça o download e inicialize o modelo com precisão bfloat16.
- Fase de aquecimento: Processa 20 solicitações para acionar a compilação JIT e estabilizar os clocks da GPU.
- Testes de desempenho: Execute 10 ciclos completos de todos os 1.000 prompts.
- Metodologia de cronometragem:
- Contagem de tokens: Extrai a contagem real de tokens a partir de formatos de saída específicos do mecanismo.
- Cálculo da taxa de transferência: total_de_tokens_de_saída / duração.
Rigor estatístico:
- Total de 10.000 operações de inferência (1.000 solicitações × 10 execuções por mecanismo).
- Aproximadamente 1,5 milhão de tokens gerados por mecanismo.
- O desvio padrão foi consistentemente inferior a 1% da média em todos os motores.
Interpretação dos resultados
Ao 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 o desempenho do SGLang ou do LMDeploy. A diferença de 29% representa o custo da orquestração em Python em comparação com a otimização nativa em C++.
A hierarquia de desempenho se aplica exatamente a este cenário: processamento em lote de 1.000 solicitações simultaneamente. SGLang e LMDeploy são opções robustas que oferecem cerca de 45% mais valor por hora de GPU do que as implementações padrão e cerca de 29% mais do que as implementações vLLM altamente otimizadas.
O que não se pode generalizar:
- Diferentes modelos: 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 escala diferentes.
- Hardware diferente: Essas classificações se aplicam ao H100 de 80 GB. No A100 ou V100, a portabilidade do vLLM pode superar a especialização do SGLang.
- Métricas diferentes: Esta métrica mede apenas a taxa de transferência. O atendimento online requer TTFT (Tempo até a Primeira Fase) e percentis de latência, cujos resultados diferem significativamente.
- Diferentes cargas de trabalho: Solicitações aleatórias minimizam os benefícios do cache de prefixos. Solicitações repetidas do sistema ou conversas com várias interações alteram drasticamente o cenário de desempenho em favor do SGLang.
Comparação da experiência do desenvolvedor
Os números de desempenho não capturam o panorama completo da implementação. Cada mecanismo oferece fluxos de trabalho de desenvolvimento distintos:
vLLM: Padrão da indústria por um bom motivo.
Simplicidade aliada à ampla compatibilidade. Uma única instalação com pip do vllm suporta mais de 100 arquiteturas de modelos em hardware NVIDIA, AMD e Intel. Uma comunidade enorme significa que o Stack Overflow tem as suas respostas. Servidor de API compatível com OpenAI incluído.
- Escolha o vLLM para: prototipagem rápida, ambientes de GPU heterogêneos, cobertura máxima do modelo ou aproveitamento do maior ecossistema.
LMDeploy: Nível de produção com o mínimo de atrito
A instalação com uma única linha (pip install lmdeploy) oferece 99,5% do desempenho máximo do H100. O backend nativo em C++ significa zero sobrecarga de Python. Suporte de quantização de primeira classe (AWQ, GPTQ) para otimização adicional. Sem dependências complexas.
- Escolha o LMDeploy para implantações de produção que exigem o máximo desempenho do H100 sem sacrificar a simplicidade de instalação ou a estabilidade.
SGLang: Limite de desempenho com custo de complexidade
A taxa de transferência máxima absoluta (16.215 tok/s) tem um preço: um esforço considerável na depuração da instalação do FlashInfer. Requer uma versão específica do PyTorch. Apresenta incompatibilidades binárias com alguns pacotes pré-compilados. O RadixAttention se destaca em cargas de trabalho conversacionais.
- Escolha o SGLang para: Clusters de inferência dedicados onde uma equipe especializada pode gerenciar dependências e você precisa de cada ponto percentual de throughput.
Desafios de instalação e implantação
Uma comparação justa exigiu a superação de obstáculos de engenharia significativos:
Desafio 1: Conflitos de dependência do FlashInfer
Problema: Os pacotes FlashInfer do SGLang esperam versões específicas do PyTorch, mas os contêineres otimizados para H100 geralmente incluem versões diferentes.
Resolução:
Tempo investido: 6 horas para identificar versões compatíveis.
Conclusão: Pacotes ML pré-compilados frequentemente ocultam restrições de versão que só aparecem em tempo de execução.
Desafio 2: Habilitando o FlashInfer no vLLM
Problema: As versões padrão do vLLM geralmente não possuem suporte para FlashInfer ou exigem compilação complexa do código-fonte.
Inovação: Utilizamos a versão vLLM 0.11.0 no PyTorch 2.8 Nightly. Isso habilitou com sucesso o suporte nativo ao FlashInfer por meio do comando `pip install “vllm[flashinfer]==0.11.0”`, contornando as barreiras de compilação das versões anteriores.
Impacto: Isso proporcionou a comparação mais justa possível, confirmando que, embora os kernels ajudem, eles não resolvem o gargalo arquitetônico.
Desafio 3: Descoberta do ponto ideal de utilização da memória
Problema: A recomendação padrão de utilização de memória da GPU de 0,9 causou std::bad_alloc falhas.
Progresso dos testes:
Descoberta: A captura de grafos CUDA aloca RAM temporária do sistema proporcional ao uso de memória da GPU. Com uma alocação de 0,9 × 80 GB = 72 GB para a GPU, a RAM do sistema se esgota durante a compilação.
Limite prático: 0,8 de utilização da GPU é a "zona segura", apesar da capacidade de hardware de 80 GB.
Conclusão
Para inferência em lote de 8 bits do Llama 3.1 no H100, a hierarquia de desempenho tem dois níveis claros : o vLLM (otimizado com FlashInfer) fornece uma base sólida, enquanto as arquiteturas nativas em C++ do SGLang e do LMDeploy desbloqueiam um adicional de 29% na taxa de transferência .
SGLang (16.215 tok/s) e LMDeploy (16.132 tok/s) atingem taxas de transferência quase idênticas, sugerindo que ambos os mecanismos saturam a largura de banda da memória do H100. A pequena diferença 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) versus a complexa resolução de dependências do SGLang.
O 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 de modelos do setor. No entanto, para clusters H100 dedicados, abrir mão de 29% de desempenho representa um custo elevado.
Para padronização em infraestruturas heterogêneas ou experimentação rápida de modelos, o vLLM continua sendo a escolha racional. Para implantações dedicadas do H100, onde a taxa de transferência é fundamental, a combinação de desempenho máximo e simplicidade de instalação do LMDeploy é incomparável.
Perguntas frequentes
Um mecanismo de inferência LLM é um software especializado que otimiza a forma como grandes modelos de linguagem geram respostas. Embora seja possível executar modelos com PyTorch ou TensorFlow básicos, os mecanismos de inferência adicionam otimizações críticas, como gerenciamento eficiente de memória, agrupamento de múltiplas solicitações e otimizações de kernel de GPU. Essas melhorias podem aumentar drasticamente a taxa de transferência (tokens gerados por segundo) e reduzir custos, potencialmente oferecendo um desempenho de 3 a 5 vezes melhor no mesmo hardware.
A inferência em lote offline processa várias solicitações simultaneamente sem requisitos de tempo real, como 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 de latência rigorosos, onde métricas como Tempo até o Primeiro Token (TTFT) importam mais do que a taxa de transferência bruta. O mecanismo que se destaca na 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.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.