vLLM ou SGLang: qual escolher para agentes e RAG?

vLLM vs SGLang: qual escolher?

vLLM é a recomendação padrão para uma nova implantação. SGLang merece ser avaliado primeiro quando o contexto compartilhado domina a carga de trabalho. Essas recomendações se baseiam nas formas de implantação e nos controles de cache documentados. Não significam que um dos motores seja mais rápido em qualquer cenário.

Para quem atende muitas conversas curtas, um prompt de sistema compartilhado justifica avaliar o SGLang, mas não descartar o vLLM. Ambos reaproveitam o processamento de prompts. Se você está lançando um produto com uma API simples e tem pouco tempo para cuidar da infraestrutura, comece com vLLM e só considere a troca diante de uma melhoria comprovada no serviço ou no custo.

RAG, ou geração aumentada por recuperação, acrescenta documentos recuperados ao prompt de um modelo. É a repetição do início desse prompt, e não o rótulo RAG, que torna o cache de prefixos útil.

Data da verificação: 14 de outubro de 2026. As versões estáveis mais recentes identificadas nesta apuração foram vLLM 0.31.0, lançado em 5 de outubro, e SGLang 0.5.21, lançado em 2 de outubro. As descrições de recursos abaixo seguem a documentação dos projetos disponível na data da verificação; valide a combinação de que você precisa na versão que pretende fixar. Não foi executado nenhum benchmark de inferência para esta comparação.

As licenças foram conferidas na licença do vLLM e no repositório do SGLang. Licenças dos pesos dos modelos, infraestrutura e engenharia são custos separados. Nenhum dos motores de código aberto oferece uma tarifa de serviço hospedado por token que permita essa comparação.

O que cada motor faz e onde estão seus limites

vLLM: ponto de partida para servir modelos de uso geral

vLLM é um motor de inferência e de disponibilização de modelos que carrega os pesos e organiza a execução das requisições no seu hardware. Entre seus componentes documentados estão o processamento contínuo em lotes, que admite novas requisições conforme outras terminam, e o PagedAttention, que gerencia o cache de chaves e valores do modelo em blocos, em vez de reservar uma grande área contígua por requisição. O cache KV armazena estados intermediários de atenção para que o modelo continue gerando sem recalcular todo o histórico. Documentação do vLLM

O motivo para começar por aqui é a clareza do que será implantado: um modelo, uma imagem oficial de servidor, uma API e instruções de instalação específicas para cada plataforma. Para uma equipe de produto que está criando um endpoint de atendimento ao cliente, essa é uma base administrável para medir capacidade.

O limite está na configuração validada. Ter uma GPU compatível é só o começo; arquitetura do modelo, quantização, backend de atenção e recursos solicitados precisam funcionar em conjunto. Uma exceção concreta no cache importa para serviços de avaliação: segundo o vLLM, requisições que pedem as probabilidades logarítmicas dos tokens do prompt ignoram o cache de prefixos e reprocessam o prompt. Por isso, um endpoint de pontuação pode se comportar de forma diferente de um endpoint de chat que usa o mesmo documento. Guia do vLLM V1

O motor custa $0. Escolha-o para servir modelos de uso geral e operar com hardware variado; não migre para ele se sua instalação atual de SGLang já cumpre a meta de serviço e oferece todos os recursos necessários.

SGLang: uma boa primeira opção para agentes com contexto repetido

SGLang é um framework de inferência de código aberto para modelos de linguagem e multimodais, com cargas de trabalho de agentes entre suas prioridades declaradas. RadixAttention organiza o estado reutilizável dos prompts em torno de prefixos compartilhados. A extensão HiCache acrescenta memória do host e armazenamento como camadas de apoio ao cache da GPU. O atrativo prático é um conjunto documentado de ferramentas para manter e reaproveitar contexto entre requisições repetidas. Repositório do SGLang, arquitetura do HiCache

Imagine um agente que consulta repetidamente a mesma política de atendimento e, a partir dela, responde a perguntas diferentes dos clientes. Esse cenário justifica uma avaliação do SGLang muito mais do que prompts sem relação entre si que apenas chegam com alta concorrência.

Seus limites estão na localização do cache e na equivalência de recursos entre backends. As camadas de GPU e de memória do host do HiCache pertencem a uma instância de inferência. O armazenamento só passa a ser compartilhado quando o backend escolhido é configurado para isso. Aumentar o cache na memória do host não cria automaticamente um cache para toda a frota. Camadas extras também trazem alocações de memória, transferências e configurações para administrar. Escopo de compartilhamento do HiCache

O motor custa $0. Escolha-o quando a repetição de contexto for relevante o bastante para justificar ajustes; não troque apenas por causa da palavra “agentes” se seus prompts raramente compartilham um prefixo idêntico.

Cache de prefixos e RadixAttention: avalie SGLang primeiro

SGLang tem prioridade na avaliação de cargas com ramificações e contexto repetido; vLLM já oferece o recurso essencial de cache. A comparação não é entre PagedAttention e a capacidade de usar cache. PagedAttention trata da organização da memória; cache de prefixos trata de reaproveitamento. O Automatic Prefix Caching do vLLM cobre explicitamente perguntas repetidas sobre documentos longos e conversas com várias rodadas. Cache de prefixos do vLLM

Prefill é o processamento de leitura do prompt antes de a geração começar. Decode é o processamento que gera novos tokens. Encontrar o prefixo no cache pode evitar a repetição do prefill; isso não elimina o trabalho de decode necessário para escrever uma nova resposta. Por isso, uma resposta longa com pouca entrada compartilhada pode se beneficiar pouco do reaproveitamento de prefixos em qualquer um dos motores.

Em um produto de conversas curtas, coloque políticas estáveis e descrições de ferramentas antes do conteúdo variável da requisição, sempre que o formato de prompt esperado pelo modelo permitir. Mantenha estáveis a serialização e a ordem dos documentos. Um horário diferente perto do início pode impedir o reaproveitamento de todo o material idêntico que vem depois. Pense em um trajeto compartilhado: depois que os caminhos se separam, encontrar a mesma paisagem mais adiante não torna idêntico o percurso anterior.

RAG com contexto longo exige mais uma verificação: o contexto é reutilizável ou apenas longo? Perguntas repetidas sobre um manual que não mudou são um bom caso para cache. Um produto de busca que reúne trechos diferentes, em uma ordem diferente a cada requisição, talvez preserve apenas o prefixo curto do sistema. Meça esses cenários separadamente antes de investir em armazenamento hierárquico.

Segundo a documentação do SGLang, RadixAttention vem ativado por padrão e é controlado por --disable-radix-cache; HiCache exige uma escolha adicional de configuração. Nos dois motores, confira a configuração efetiva em vez de deduzir o comportamento do cache pelo nome do projeto. Argumentos do servidor SGLang

Recursos para agentes: empate em JSON; adaptadores e geração especulativa exigem validação

Precisar de JSON, por si só, não dá vantagem a nenhum dos motores. Ambos permitem restringir a geração a um esquema. Deixe o modelo escolher os valores, mas restrinja a estrutura e valide o resultado antes de executar uma ação.

Saída estruturada em JSON

vLLM oferece suporte a JSON Schema por meio de response_format e das opções de structured_outputs. SGLang também oferece JSON Schema, com XGrammar como backend padrão de gramática. São restrições aplicadas à decodificação, não apenas instruções para o modelo “retornar JSON”. Saídas estruturadas do vLLM, saídas estruturadas do SGLang

Em um agente de atendimento, um esquema pode exigir uma ação e um identificador de chamado. Ele não consegue garantir que o chamado pertença ao usuário que fez a solicitação nem que a ação escolhida seja justificada. Mantenha essas verificações no código da aplicação. Teste seus esquemas reais, o modo de raciocínio e o comportamento em streaming juntos; o suporte isolado a cada item não comprova que a combinação funciona corretamente.

Resultado: empate para a necessidade comum de JSON. Continue com o motor que você já opera, a menos que requisições representativas com seus esquemas revelem uma diferença concreta.

Decodificação especulativa

A decodificação especulativa é uma opção de otimização nos dois projetos, não uma garantia de ganho de velocidade. Um mecanismo de rascunho propõe tokens, e o modelo principal os verifica. Propostas úteis e aceitas podem reduzir o trabalho sequencial de geração; produzir o rascunho, verificá-lo e manter a memória necessária ainda têm custo.

vLLM documenta EAGLE, predição de múltiplos tokens, modelos de rascunho separados, métodos de n-gramas e de sufixos. SGLang também documenta EAGLE, predição de múltiplos tokens, modelos de rascunho e NGRAM. A combinação entre mecanismo de rascunho, modelo principal, hardware e volume de tráfego importa mais do que a simples presença do recurso. Métodos do vLLM, métodos do SGLang

Vence o motor cuja configuração de rascunho foi validada para o seu modelo. Ative a especulação depois de estabelecer uma medição de referência e compare a latência das respostas e a capacidade total. Deixe o recurso desativado se o trabalho extra não compensar sob sua carga de produção.

Multi-LoRA para personalizar o comportamento por cliente

Os dois motores podem servir múltiplos adaptadores LoRA, pequenos conjuntos adicionais de pesos de ajuste fino que personalizam um modelo-base compartilhado. vLLM permite registrar adaptadores com --lora-modules e oferece controles de concorrência e rank. SGLang usa --lora-paths e --max-loras-per-batch; o padrão documentado por lote é de 8 adaptadores. Isso não é um limite total de clientes. LoRA no vLLM, LoRA no SGLang

Em um produto de escrita personalizado por cliente, teste a distribuição esperada de uso dos adaptadores, incluindo aqueles que ainda não estão carregados e trocas frequentes. A opção de carregamento sobreposto do SGLang pode ocultar o tempo das transferências, mas a documentação também alerta que ela pode reduzir o agrupamento de prefill de múltiplos adaptadores e aumentar a latência até o primeiro token. Mais opções de configuração não significam automaticamente mais capacidade.

Resultado: mantenha o motor no qual você já validou o uso dos adaptadores. Multi-LoRA, isoladamente, não justifica uma troca. Vale testar SGLang quando o carregamento de adaptadores ou uma carga muito dependente de cache for o gargalo. Para TPU, consulte a matriz de recursos do próprio backend: o guia do SGLang-JAX ainda marca multi-LoRA como em desenvolvimento. Matriz de recursos do SGLang para TPU

Suporte a hardware: vLLM é o ponto de partida para uma infraestrutura variada

Os dois projetos declaram suporte a NVIDIA, AMD, TPU e CPU. O limite real está na combinação de backend e modelo. A lista geral de hardware de um projeto não garante que toda configuração de GPU, adaptador ou método de decodificação possa ser transferida sem mudanças.

• NVIDIA: vLLM documenta a instalação em GPUs CUDA; o repositório do SGLang lista famílias de datacenter e RTX. As imagens da versão atual e o driver do host precisam ser compatíveis. Instalação do vLLM em GPU, lista de hardware do SGLang
• AMD: ambos documentam a implantação com ROCm. SGLang lista Instinct MI300X, MI325X, MI350X e MI355X, com um guia de instalação separado. Use a imagem ROCm e a configuração de modelo correspondentes. Guia do SGLang para AMD
• Google TPU: vLLM aponta para a instalação separada de tpu-inference. O guia de TPU do SGLang usa o backend separado SGLang-JAX e lista v6e e v7. São caminhos distintos de implantação, cada um exigindo suas próprias verificações de recursos. Instalação do vLLM em TPU, guia do SGLang para TPU
• CPU: vLLM documenta Intel/AMD x86 e ARM AArch64 entre suas opções para CPU. O guia de servidor em CPU do SGLang é voltado especificamente ao Intel AMX em processadores Xeon Scalable de quarta geração ou mais recentes. “Suporte a CPU” não significa a mesma abrangência. Guia do vLLM para CPU, guia do SGLang para CPU

Uma diferença operacional concreta pode decidir sua próxima implantação: vLLM 0.31.0 publica uma imagem CUDA 12.9 além da imagem padrão com CUDA 13.0. O guia de instalação atual do SGLang exige CUDA 13 e informa que a linha de imagens CUDA 12 terminou na versão 0.5.19. Se sua infraestrutura ainda não pode migrar para um ambiente com drivers compatíveis, investigue isso antes de comparar qualquer resultado de vazão. Artefatos da versão do vLLM, instalação do SGLang

Servidores compatíveis com OpenAI: migrar o cliente é mais fácil que migrar a carga

Os dois motores podem atender um cliente que usa chat completions no padrão da OpenAI. Ambos documentam /v1/chat/completions e /v1/completions, o que reduz o trabalho de integração a substituir na aplicação. Isso não torna intercambiáveis todos os endpoints, extensões, parsers de ferramentas ou comportamentos dos modelos. Servidor do vLLM, API do SGLang

Um template de chat transforma mensagens identificadas por papel na sequência de tokens esperada pelo modelo. Preserve esse template ao comparar motores. Caso contrário, você pode estar comparando dois prompts sem perceber. Mantenha também a mesma revisão do modelo, o mesmo tokenizador, as mesmas configurações de amostragem e o mesmo limite de saída.

Se você já tem um cliente vLLM, confira os campos antigos de restrição de saída antes de migrar ou atualizar. A documentação informa que guided_json e campos relacionados foram removidos na versão 0.12.0; o código atual deve usar o formato aceito de structured_outputs ou response_format. Um corpo de requisição desatualizado pode parecer uma incompatibilidade entre motores. Nota de migração do vLLM

Resultado: empate na interface básica do cliente; vLLM continua sendo a recomendação padrão para operação. Seu teste de aceitação deve cobrir turnos completos do agente, incluindo argumentos de ferramentas em streaming, erros e novas tentativas, em vez de parar na primeira resposta de texto bem-sucedida.

Como executar cada motor em uma GPU na nuvem

Comece com um contêiner de versão fixa e um modelo pequeno para um teste básico de funcionamento; depois, substitua pelo modelo de produção e ajuste a memória disponível. Os exemplos a seguir adaptam os comandos documentados de Docker e de inicialização dos projetos para um host Linux com GPU NVIDIA, Docker, o runtime de contêineres da NVIDIA e um driver compatível com a imagem. Foram conferidos na documentação, mas não executados em uma GPU alugada. Docker no vLLM, guia rápido do SGLang

O modelo Qwen/Qwen3-0.6B abaixo serve para verificar a integração, não como recomendação de qualidade de resposta para seu agente. Execute um motor de cada vez na mesma porta. O limite de contexto é uma configuração explícita do exemplo, não o máximo anunciado para o modelo.

Contêiner do vLLM

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

Contêiner do SGLang

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

Depois da inicialização, execute esta requisição no host da GPU:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

Os exemplos vinculam a porta do host à interface de loopback. Antes de atender usuários remotos, coloque um gateway de aplicação com autenticação na frente do servidor. Isso é especialmente relevante no vLLM: sua documentação informa que --api-key não autentica todas as rotas do servidor HTTP. Escopo de autenticação do vLLM

O worker vLLM documentado pela Runpod

A Runpod oferece pelo Hub um worker vLLM documentado e pronto para implantação. Esse atalho na nuvem sustenta a recomendação padrão para operação. O pacote do worker é um artefato de implantação separado; confira a versão do motor incluída, em vez de presumir que seja a mais recente do projeto original. Guia de implantação da Runpod

Para SGLang, o caminho reproduzível na nuvem descrito aqui é executar seu contêiner oficial em um host com GPU compatível. O atalho da Runpod acima se refere especificamente ao worker vLLM documentado pela empresa.

Diferença de preço: a mesma GPU gera a mesma conta

Com a mesma capacidade alugada, nenhum dos motores é mais barato. Em 14 de outubro de 2026, a página de preços da Runpod listava uma A100 PCIe com 80 GB por $1.79/hora para Pods. Esse é o preço de uma GPU dedicada, não a tarifa de cobrança do worker Serverless. Ele é o custo comum de infraestrutura usado no cálculo abaixo. Preços da Runpod

Considerando um mês de 730 horas para orçamento, uma GPU provisionada continuamente custa $1,306.70/mês tanto com vLLM quanto com SGLang. Duas custam $2,613.40/mês. Esses valores não incluem armazenamento, cobranças de rede, redundância e engenharia.

Considere uma carga hipotética de atendimento: 50,000 requisições por mês, cada uma com 2,000 tokens de entrada e 200 tokens de saída. Isso equivale a 100 milhões de tokens de entrada e 10 milhões de tokens de saída entregues. Se essa carga couber em uma GPU respeitando o tempo de resposta exigido, a conta de GPU de qualquer um dos motores será de $0.13067 por 1,000 tokens de saída entregues. O denominador é a quantidade de tokens de saída; a conta também paga pelo processamento da entrada.

Essa é uma conta de custo, não uma medição de capacidade. Se a carga não couber, o resultado para uma GPU não se aplica.

O ponto de virada é aquele em que uma configuração precisa de uma réplica adicional para cumprir a mesma meta de serviço. Se SGLang precisar de uma GPU e vLLM de duas, SGLang economiza $1,306.70/mês. Se a relação de capacidade medida se inverter, vLLM economiza o mesmo valor. Se ambos precisarem de uma, a economia de infraestrutura é zero.

Com um orçamento de migração de 8 horas a um custo hipotético de $100/hora, o gasto é de $800. Eliminar uma dessas GPUs recupera esse valor em cerca de 0.61 meses, antes de considerar qualquer diferença na operação contínua. Sem eliminar uma réplica ou obter uma melhoria de serviço com valor para o negócio, ser “mais rápido” pode não gerar retorno financeiro algum.

Vence em preço a configuração que cumpre a meta com o menor custo operacional total. Não há como indicar honestamente um volume de tráfego a partir do qual um motor fica mais barato sem medir antes a capacidade segura para sua carga.

Vazão: escolha pelo trabalho concluído dentro da meta de latência

Esta comparação não estabelece um vencedor universal em vazão. Um resultado publicado por um projeto vale para aquele modelo, hardware, precisão, comprimento de requisições e versão. Melhorar um kernel não equivale a melhorar o serviço de ponta a ponta, e vazão de prefill não é vazão de tokens de saída. Nenhuma dessas métricas deve virar uma afirmação geral de que “SGLang é mais rápido” ou “vLLM é mais rápido”.

Use as ferramentas dos próprios projetos como ponto de partida: a CLI de benchmark do vLLM e o guia de benchmark de serviço do SGLang. A comparação precisa de execuções com cache quente e frio, além de reproduzir o perfil de carga do seu produto.

Meça quatro condições separadamente: conversas curtas que compartilham um prompt de sistema estável; perguntas repetidas sobre o mesmo documento longo; prompts longos de RAG com trechos recuperados que mudam; e sua combinação real de esquemas, chamadas de ferramentas e adaptadores. Preserve os intervalos de chegada das requisições, além da concorrência. Uma rajada de requisições simultâneas e um fluxo constante podem revelar gargalos diferentes.

Registre requisições concluídas, tokens de saída entregues, erros e latência até o primeiro token. Examine também a latência p95 e p99, os percentis 95 e 99, porque uma boa média pode esconder respostas muito lentas no extremo da distribuição. Conte como falhas, e não como capacidade útil, as saídas que não passam nas verificações de esquema ou de correção da aplicação.

Vence a implantação de menor custo que se mantém dentro desses critérios de aceitação. Uma alegação de velocidade obtida com outro modelo ou uma versão antiga é motivo para fazer essa comparação, não uma resposta para ela.

Como trocar de motor preservando o contrato e a possibilidade de voltar

Só migre a camada que serve os modelos quando o benefício medido superar os custos de migração e operação. Em geral, os dados da aplicação e a base usada na recuperação podem ficar onde estão quando apenas o backend de geração muda. O trabalho se concentra no empacotamento do modelo, nas extensões das requisições, na interpretação das saídas e no comportamento da implantação.

Não troque uma implantação saudável de vLLM apenas para obter cache de prefixos ou restrições de JSON; ela já oferece os dois. Também não troque uma implantação saudável de SGLang só porque vLLM é a recomendação padrão aqui. O conhecimento operacional que sua equipe já tem faz parte da comparação de custos.

Se a dúvida ainda é se você precisa de um servidor compartilhado em produção, leia Ollama vs vLLM. Essa comparação trata da decisão anterior: escolher entre a praticidade de trabalhar com modelos localmente e uma camada de serviço para requisições simultâneas.

O próximo passo é capturar tráfego de pico representativo, definir os tempos máximos de resposta e a taxa de erros aceitáveis e comparar versões fixas dos motores no mesmo hardware antes de ampliar a infraestrutura.

Perguntas frequentes

Use o checklist de auditoria de fluxos de trabalho empresariais com IA para identificar qual fluxo merece um servidor compartilhado de modelos e assine a newsletter para acompanhar as próximas mudanças nas ferramentas.