Principais conclusões
- Gratuito e de código aberto sob licença Apache 2.0, originado de pesquisas ligadas à UC Berkeley, Stanford e LMSYS
- O RadixAttention reutiliza automaticamente entradas de cache KV entre requisições que compartilham um prefixo, usando uma árvore radix em vez de isolamento de cache por requisição
- A saída estruturada — esquemas JSON e restrições regex — é aplicada durante a decodificação via uma máquina de estados finitos comprimida, não como filtro de pós-processamento
- Traz um DSL frontend embutido em Python (
sgl.gen,sgl.select,sgl.fork) para escrever programas de LLM com múltiplas chamadas - Servidor de API compatível com OpenAI embutido, iniciado com
python -m sglang.launch_server - Suporta batching contínuo, paralelismo de tensores e formatos de quantização incluindo FP8, INT4, AWQ e GPTQ
- O hardware principal e mais bem suportado são as GPUs NVIDIA; o projeto também documenta backends AMD, Intel e outros com cobertura real mais restrita
- Não é um app de desktop de usuário único — sem instalador gráfico, e não construído em torno de hardware exclusivamente CPU ou Apple Silicon como llama.cpp e Ollama
📍 Em uma frase
SGLang é um framework de serving gratuito, licenciado sob Apache 2.0, para LLMs e modelos de visão-linguagem, originado de pesquisas ligadas à UC Berkeley, Stanford e LMSYS, que usa RadixAttention para reutilizar automaticamente o estado do cache KV entre requisições que compartilham um prefixo comum e aplica saída estruturada dentro do loop de decodificação.
💬 Em termos simples
Em vez de um app de chat de desktop, o SGLang é um software de servidor feito para duas coisas ao mesmo tempo: atender com eficiência muitas requisições simultâneas — especialmente as que repetem um prompt de sistema ou histórico de conversa — e garantir que a saída do modelo realmente corresponda a um esquema JSON ou padrão especificado.
📌Nota: Este artigo é baseado no repositório oficial no GitHub do SGLang e em sua documentação pública, não em benchmarks independentes. Os próprios materiais do SGLang citam multiplicadores de aceleração específicos para RadixAttention e decodificação JSON em benchmarks de lançamentos específicos; este artigo não repete esses números como valores universais, já que dependem da carga de trabalho, do hardware e da versão testada, e tanto SGLang quanto vLLM publicam benchmarks favoráveis a si mesmos.
O que é o SGLang?
SGLang é um framework de serving gratuito, licenciado sob Apache 2.0, para modelos de linguagem grandes e modelos de visão-linguagem. Ele se originou de pesquisas ligadas à UC Berkeley, Stanford e à organização LMSYS — a mesma comunidade por trás do Chatbot Arena — e hoje é desenvolvido sob a organização sgl-project no GitHub. Diferentemente de ferramentas construídas principalmente para um único usuário conversando localmente com um modelo, o SGLang mira em dois problemas sobrepostos: atender com eficiência muitas requisições simultâneas, e garantir que a saída de um modelo siga um formato estruturado como JSON, o que importa para function calling, pipelines de agentes e outras saídas consumidas por máquinas.
- Originado de pesquisas ligadas à UC Berkeley, Stanford e LMSYS; desenvolvido hoje sob a organização de código aberto
sgl-project - Licenciado sob Apache 2.0: o código-fonte está publicamente disponível para uso, modificação e redistribuição conforme os termos da licença
- Combina um DSL frontend embutido em Python para escrever programas de LLM com um runtime de backend co-projetado (o SGLang Runtime, frequentemente abreviado como SRT)
- Carrega checkpoints de modelos compatíveis com Hugging Face Transformers, cobrindo famílias de modelos incluindo Llama, Qwen, Mistral e DeepSeek sem uma etapa de conversão separada para a maioria dos modelos
- Documenta implantações em produção que geram grandes volumes de tokens diariamente, e cita em seus próprios materiais diversas empresas e instituições de pesquisa como adotantes
O que é o RadixAttention, e por que ele importa?
RadixAttention é a técnica de gerenciamento de memória pela qual o SGLang é mais conhecido. Muitas cargas de trabalho reais de LLM emitem múltiplas chamadas de geração que compartilham um prefixo comum — o mesmo prompt de sistema em cada requisição, os mesmos exemplos few-shot, ou turnos anteriores de uma conversa em andamento. Recalcular o cache chave-valor (KV) de atenção para esse prefixo compartilhado a cada chamada desperdiça computação e memória de GPU. O RadixAttention, em vez disso, armazena entradas de cache KV tanto de requisições concluídas quanto em andamento em uma árvore radix — uma estrutura de árvore indexada por sequências de tokens — de forma que uma nova requisição possa encontrar e reutilizar automaticamente o cache de qualquer prefixo que compartilhe com requisições anteriores, sem que um desenvolvedor precise rastrear ou gerenciar manualmente essa reutilização.
- Encontra e reutiliza automaticamente entradas de cache KV entre requisições que compartilham um prefixo de sequência de tokens, usando uma estrutura de dados em árvore radix
- Cobre prefixos de prompts de sistema repetidos, exemplos few-shot compartilhados e histórico de conversa multi-turno — não apenas a mesma requisição exata repetida literalmente
- Aplica uma política de despejo LRU (menos recentemente usado) à árvore radix para que a memória de cache possa ser recuperada e reutilizada à medida que a árvore cresce
- Funciona junto com batching contínuo e alocação de cache KV paginada em blocos, o que permite ao SGLang adicionar e remover requisições de um batch em andamento à medida que chegam e terminam
O que o DSL frontend e a saída estruturada realmente fazem?
Além do serving central, o SGLang traz duas capacidades relacionadas, mas distintas: uma linguagem frontend embutida em Python para escrever programas de LLM, e a aplicação no nível do engine de formatos de saída estruturados.
Que hardware o SGLang precisa?
O alvo principal e mais bem suportado do SGLang são as GPUs NVIDIA, e a maioria das implantações em produção descritas nos próprios materiais do projeto roda em hardware NVIDIA. O projeto também documenta backends adicionais, embora a cobertura e a adoção real não sejam iguais em todos eles.
GPUs NVIDIA (CUDA)
- Detalhes:
- O alvo principal e mais maduro, desde GPUs de data center até placas recentes de consumo/workstation. O serving tensor-paralelo em várias GPUs NVIDIA é bem documentado.
GPUs AMD (ROCm)
- Detalhes:
- Documentado como backend suportado para aceleradores AMD Instinct via ROCm, com adoção real e cobertura de comunidade mais restrita que o caminho CUDA.
CPUs Intel Xeon e aceleradores Gaudi
- Detalhes:
- Backends adicionais documentados pelo projeto para hardware Intel; trate como um caminho de implantação menor e menos testado que as GPUs NVIDIA.
TPUs do Google e NPUs Ascend
- Detalhes:
- Backends documentados voltados a times que já rodam sobre infraestrutura Google Cloud TPU ou Huawei Ascend.
Apple Silicon (Mac)
- Detalhes:
- Não é um caminho de primeira classe oficialmente mantido. O SGLang é construído em torno de hardware de data center e workstation apoiado em GPU, não para uso local em um único Mac.
Se seu objetivo é rodar um modelo em um único Mac ou uma máquina exclusivamente com CPU, o SGLang não é a ferramenta feita para isso — llama.cpp e ferramentas construídas sobre ele, como Ollama e LM Studio, miram diretamente em hardware CPU e Apple Silicon e são melhores para esse cenário.
Quais formatos de quantização o SGLang suporta?
O SGLang suporta o serving de modelos com precisão numérica reduzida para diminuir o uso de memória e, em muitos casos, aumentar o throughput, documentando vários formatos de quantização estabelecidos.
FP8
- Detalhes:
- Precisão em ponto flutuante de 8 bits, suportada em gerações de GPU NVIDIA com suporte de hardware para FP8, trocando um pouco de precisão por menor uso de memória e execução mais rápida que FP16/BF16.
FP4
- Detalhes:
- Um formato de ponto flutuante mais novo e de precisão ainda menor, documentado pelo projeto para o hardware NVIDIA de geração mais recente que o suporta.
AWQ
- Detalhes:
- Activation-aware Weight Quantization, um método de quantização de pesos de 4 bits amplamente usado, com modelos pré-quantizados publicados pela comunidade no Hugging Face.
GPTQ
- Detalhes:
- Um método de quantização pós-treinamento comumente distribuído como checkpoints pré-quantizados, também tipicamente em 4 bits.
INT4
- Detalhes:
- Um caminho de quantização inteira de precisão mais baixa, documentado pelo projeto ao lado de AWQ e GPTQ para redução adicional de memória.
Este artigo não inclui números de perda de qualidade medidos de forma independente para cada formato — eles variam conforme a arquitetura do modelo e a tarefa, então comparar saídas de alguns formatos com seus próprios prompts é a forma mais confiável de avaliar o trade-off para sua carga de trabalho.
O que o servidor do SGLang compatível com OpenAI oferece?
Executar python -m sglang.launch_server inicia um servidor HTTP que implementa o protocolo da API da OpenAI, de forma que aplicações e SDKs já construídos contra a API da OpenAI frequentemente podem apontar para uma instância do SGLang auto-hospedada mudando apenas a URL base e o nome do modelo.
- Endpoints de chat completions e completions compatíveis com OpenAI, utilizáveis como substituto direto de código cliente baseado na API da OpenAI
- Host e porta configuráveis (comumente
http://localhost:30000nos próprios exemplos do projeto) - Parâmetros de saída estruturada em nível de requisição para geração restrita por esquema JSON ou regex, expostos via API
- Flags do engine para tamanho tensor-paralelo, alocação de memória e formato de quantização, definidos na inicialização do servidor
- Suporte para servir múltiplos adaptadores LoRA sobre um único modelo base carregado
Como instalar e executar o SGLang?
O SGLang é distribuído como um pacote Python e tipicamente instalado em um ambiente Python com uma GPU NVIDIA e drivers CUDA compatíveis disponíveis.
- 1Confirme que você tem uma GPU NVIDIA suportada com drivers CUDA atuais instalados (ou consulte a documentação do projeto para instruções de instalação específicas de AMD/Intel/TPU caso esteja mirando um desses backends).
- 2Crie um ambiente virtual Python e depois instale o SGLang, por exemplo: `pip install "sglang[all]"`.
- 3Inicie o servidor compatível com OpenAI com um modelo do Hugging Face, por exemplo:
python -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 127.0.0.1 --port 30000. - 4Envie uma requisição de chat básica com qualquer cliente compatível com a API da OpenAI, por exemplo o pacote Python
openaiapontando parabase_url="http://127.0.0.1:30000/v1". - 5Para uma resposta restrita por JSON, passe um esquema JSON nos parâmetros de saída estruturada da requisição para que o servidor aplique o esquema durante a decodificação em vez de apenas pedir JSON no prompt.
- 6Para serving multi-GPU, adicione uma flag tensor-paralela, por exemplo
--tp-size 2para dividir o modelo entre duas GPUs. - 7Aponte o código cliente de API da OpenAI existente para o seu servidor auto-hospedado mudando apenas a URL base e o nome do modelo.
Preciso de uma GPU para executar o SGLang?
Para qualquer coisa além de testes, sim — o alvo principal e mais bem suportado do SGLang são as GPUs NVIDIA. O projeto documenta outros backends de aceleradores, mas eles não são o caminho de implantação principal.
Posso obter saída JSON garantida do SGLang?
Sim — passe um esquema JSON nos parâmetros de saída estruturada da sua requisição, e o SGLang o aplica durante a decodificação mascarando tokens que violariam o esquema, em vez de apenas pedir ao modelo que produza JSON no prompt.
Como o SGLang se compara ao vLLM?
SGLang e vLLM são os dois engines de serving de LLM de código aberto apoiados em GPU mais discutidos, ambos licenciados sob Apache 2.0 e voltados ao serving de produção multiusuário em vez do chat de desktop de usuário único. Ambos os projetos publicam benchmarks que se comparam favoravelmente entre si; este artigo não julga essa comparação e, em vez disso, descreve o design e as afirmações documentadas de cada projeto.
Técnica de cache principal
- SGLang:
- RadixAttention — reutilização automática de cache KV baseada em árvore radix entre requisições que compartilham qualquer prefixo.
- vLLM:
- PagedAttention — blocos de cache KV do tamanho de uma página, não contíguos, que reduzem o desperdício de memória por alocações super-reservadas.
Saída estruturada
- SGLang:
- A aplicação de esquema JSON e regex no nível do engine é um recurso central e fortemente documentado, construído sobre uma máquina de estados finitos comprimida.
- vLLM:
- Também suporta decodificação estruturada/guiada via backends de gramática integrados, documentada como parte de seu conjunto de recursos mais amplo em vez de recurso principal.
Modelo de programação
- SGLang:
- Traz um DSL frontend embutido em Python (
sgl.gen,sgl.select,sgl.fork) para programas de LLM com múltiplas chamadas, além do servidor de API. - vLLM:
- Acessado principalmente como servidor de API ou chamada de biblioteca Python; não traz um DSL de autoria de programas comparável.
Origem
- SGLang:
- Pesquisa ligada à UC Berkeley, Stanford e à organização LMSYS por trás do Chatbot Arena.
- vLLM:
- Originado no Sky Computing Lab da UC Berkeley.
Afirmações de throughput
- SGLang:
- Publica benchmarks de lançamento citando multiplicadores para RadixAttention e decodificação JSON em cargas de trabalho específicas.
- vLLM:
- Publica seus próprios benchmarks de lançamento; descreve o raciocínio de eficiência de memória do PagedAttention em vez de um único número de velocidade universal.
Nenhum benchmark de marketing de qualquer um dos engines deve ser tomado como um veredito neutro — ambos são feitos pelo projeto cujo resultado parece mais favorável, sobre cargas de trabalho escolhidas por esse projeto. Se o throughput é decisivo, testar ambos os engines com seu próprio modelo, hardware e padrão de tráfego é mais confiável do que o número de um único artigo, incluindo este.
Como o SGLang se compara ao llama.cpp e ao TensorRT-LLM?
SGLang, llama.cpp e TensorRT-LLM ficam em pontos diferentes do espectro entre flexibilidade de hardware e otimização máxima.
SGLang
- Detalhes:
- Licenciado sob Apache 2.0, baseado em Python, construído em torno do RadixAttention e da saída estruturada no nível do engine. Carrega modelos compatíveis com Hugging Face Transformers diretamente; GPUs NVIDIA são o alvo principal, com backends adicionais documentados.
llama.cpp
- Detalhes:
- Engine de inferência em C/C++ licenciado sob MIT, construído em torno do formato de modelo GGUF, rodando em CPU, Apple Silicon e GPU. Mira em implantação de máquina única e edge em vez de clusters de produção multi-GPU.
TensorRT-LLM
- Detalhes:
- O engine da NVIDIA, construído especificamente para GPUs NVIDIA. Os modelos são compilados antecipadamente em um engine TensorRT otimizado para a GPU alvo, o que pode gerar forte desempenho nesse hardware específico ao custo de uma etapa de compilação e menor flexibilidade entre hardwares que o SGLang.
Este artigo não fez benchmark independente desses três engines entre si e não afirma que um seja universalmente mais rápido — o throughput depende fortemente do modelo, do hardware, das características do batch e da versão de cada engine. Veja o guia de servidores de inferência empresariais para uma comparação voltada à implantação que também cobre vLLM, TGI e NVIDIA NIM.
Para quem é o SGLang?
O SGLang se encaixa com times que atendem um modelo a muitos usuários ou aplicações simultâneas em infraestrutura de GPU — particularmente cargas de trabalho com prefixos de prompt repetidos ou um requisito rígido de saída estruturada —, não com pessoas buscando a forma mais rápida de conversar com um modelo no próprio computador.
SGLang vs. alternativas em resumo
Essas ferramentas ficam em pontos diferentes do espectro entre usuário único e serving de produção, e do espectro entre throughput e ênfase em saída estruturada.
SGLang
- Interface e configuração:
- Pacote Python; servidor de API compatível com OpenAI iniciado com
python -m sglang.launch_server. Espera uma GPU NVIDIA e CUDA na maioria das implantações. - Melhor para:
- Serving de GPU de alta concorrência com forte reutilização de prefixo e/ou requisito rígido de saída estruturada (JSON/regex).
vLLM
- Interface e configuração:
- Pacote Python; servidor de API compatível com OpenAI iniciado com
vllm serve. Espera uma GPU NVIDIA e CUDA na maioria das implantações. - Melhor para:
- Serving de GPU de alto throughput multiusuário em produção, de forma geral, sem um design focado primeiro em saída estruturada.
Ollama
- Interface e configuração:
- CLI e API REST, comumente relatado como rodando sobre o llama.cpp como backend na maioria das plataformas. Um comando o instala; um comando baixa e roda um modelo.
- Melhor para:
- O caminho mais rápido para um modelo local funcionando para um único usuário, sem etapa de build ou GPU necessária.
llama.cpp
- Interface e configuração:
- CLI, interface web embutida e API compatível com OpenAI via llama-server. Compile a partir do código-fonte ou use um binário pré-construído; roda em CPU ou GPU.
- Melhor para:
- Controle direto no nível do engine, implantação embarcada/edge, e hardware CPU ou Apple Silicon.
Este artigo não fez benchmark independente de velocidade ou qualidade de saída entre essas ferramentas e não afirma que uma seja tecnicamente superior — a comparação acima cobre apenas fatos documentados de arquitetura, configuração e modelo de acesso. Veja a comparação llama.cpp vs. Ollama vs. vLLM para uma comparação dedicada de throughput e complexidade de configuração entre esses três, e o guia de servidores de inferência empresariais para um olhar voltado à implantação sobre vLLM, TGI e NVIDIA NIM.
O que este artigo não cobre?
Este é um artigo explicativo construído a partir da documentação pública e do repositório do SGLang, não um relatório de benchmark prático.
- Nenhum número de throughput, latência ou requisições por segundo medido de forma independente para o SGLang ou suas comparações — esses dependem fortemente da GPU, do modelo, da composição do batch e da versão
- Nenhuma verificação independente dos multiplicadores de aceleração que o próprio SGLang afirma para RadixAttention ou decodificação JSON — eles vêm dos benchmarks de lançamento do projeto, não de medição de terceiros
- Nenhuma auditoria de segurança linha por linha da base de código do SGLang — ela é de código aberto e licenciada sob Apache 2.0, então o próprio código está disponível para revisão
- Nenhuma cobertura completa de cada backend de hardware suportado, flag de engine ou opção de orquestração de implantação (Kubernetes, configurações específicas de nuvem) — este artigo foca nos conceitos e flags que a maioria dos times avalia primeiro
- Nenhuma cobertura de acordos de suporte comercial ou ofertas de hospedagem gerenciada do SGLang, já que o próprio SGLang é um projeto de código aberto comunitário, não um produto de fornecedor com contrato de suporte
Erros comuns ao experimentar o SGLang
A maior parte do atrito com o SGLang vem de tratá-lo como uma ferramenta de desktop de usuário único, ou de esperar que o RadixAttention ajude uma carga de trabalho que na verdade não compartilha prefixos.
Perguntas frequentes
O que é o SGLang?
SGLang é um framework de serving gratuito, licenciado sob Apache 2.0, para modelos de linguagem grandes e modelos de visão-linguagem, originado de pesquisas ligadas à UC Berkeley, Stanford e à organização LMSYS por trás do Chatbot Arena. É mais conhecido pelo RadixAttention, uma técnica de reutilização automática de cache KV entre requisições que compartilham um prefixo comum.
O SGLang é gratuito?
Sim. O SGLang é software gratuito e de código aberto, lançado sob a licença Apache 2.0, sem necessidade de assinatura ou conta para executá-lo você mesmo.
O que é o RadixAttention?
RadixAttention é a técnica do SGLang para armazenar o cache KV de atenção de requisições concluídas e em andamento em uma árvore radix, de forma que novas requisições que compartilham um prefixo de sequência de tokens — prompt de sistema, exemplos few-shot ou turnos de conversa anteriores — possam reutilizar automaticamente o cache correspondente em vez de recalculá-lo.
O SGLang garante saída JSON válida?
Quando uma requisição inclui um esquema JSON nos parâmetros de saída estruturada do SGLang, o engine mascara em cada passo de decodificação os tokens que violariam o esquema, o que é projetado para tornar a saída conforme ao esquema por construção em vez de por validação posterior. Simplesmente pedir JSON no texto do prompt sem usar esses parâmetros não oferece essa garantia.
O SGLang precisa de uma GPU?
Para qualquer carga de trabalho real, sim — o alvo principal e mais bem suportado do SGLang são as GPUs NVIDIA. O projeto documenta backends AMD, Intel e outros aceleradores, mas eles não são o caminho de implantação principal, e não há suporte de primeira classe para Apple Silicon.
Quais formatos de quantização o SGLang suporta?
O SGLang suporta vários formatos incluindo FP8, FP4 em hardware mais novo, AWQ, GPTQ e INT4, com muitos modelos pré-quantizados nesses formatos publicados no Hugging Face.
O SGLang é melhor que o vLLM?
Os benchmarks próprios de nenhum dos dois projetos são um veredito neutro sobre isso — ambos publicam resultados favoráveis a si mesmos. O SGLang destaca a reutilização de cache baseada em prefixo do RadixAttention e a saída estruturada no nível do engine como seus recursos principais; o vLLM destaca a eficiência de memória do PagedAttention. Qual se encaixa melhor depende do padrão de compartilhamento de prefixo da sua carga de trabalho e de se a saída estruturada é um requisito rígido — veja a tabela comparativa acima.
O SGLang tem uma API compatível com OpenAI?
Sim. Executar python -m sglang.launch_server inicia um servidor que implementa o protocolo da API da OpenAI, de forma que muitas aplicações construídas para a API da OpenAI podem apontar para uma instância do SGLang auto-hospedada mudando apenas a URL base e o nome do modelo.
Para que serve o DSL frontend do SGLang?
É um conjunto de primitivas Python — incluindo sgl.gen, sgl.select e sgl.fork — para escrever programas de LLM de múltiplas etapas, como ramificar em várias sub-gerações paralelas e combinar os resultados, como código Python comum em vez de orquestrar manualmente chamadas de API separadas.
Quem criou o SGLang, e o que e a RadixArk?
O SGLang surgiu de pesquisas que conectam a UC Berkeley, Stanford e a organizacao LMSYS por tras do Chatbot Arena. Em 2026, os cocriadores do SGLang Ying Sheng e Banghua Zhu fundaram a RadixArk, uma startup de infraestrutura de IA que captou US$ 100 milhoes em uma rodada seed liderada pela Accel para comercializar servicos em torno do SGLang, mantendo seu desenvolvimento open source — o framework principal continua sob licenca Apache 2.0 e gratuito.