Skip to main content
PromptQuorumBuilt for humans. Structured for AI.
Início/LLMs locais avançados
Overview & Reference

SGLang explicado: RadixAttention e serving estruturado de LLM (2026)

·13 min de leituraPor Hans Kuepper · Fundador do PromptQuorum · Mecanismo de descoberta de IA de pesos abertos e código aberto

SGLang é um framework de serving gratuito e de código aberto (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. Seu diferencial técnico principal é o RadixAttention, que armazena o cache KV de atenção de requisições concluídas e em andamento em uma árvore radix, de forma que qualquer nova requisição que compartilhe um prefixo — um prompt de sistema, exemplos few-shot ou um turno anterior da mesma conversa — possa reutilizar automaticamente as entradas de cache correspondentes em vez de recalculá-las. O SGLang também traz uma linguagem frontend embutida em Python (sgl.gen, sgl.select e primitivas relacionadas) para escrever programas de LLM com múltiplas chamadas, e aplica a saída estruturada — esquemas JSON e padrões regex — diretamente dentro do loop de decodificação em vez de como uma etapa de pós-processamento. Ele traz um servidor compatível com OpenAI (python -m sglang.launch_server), documenta GPUs NVIDIA como seu alvo principal e mais bem suportado, com backends adicionais de AMD, Intel e outros, e — assim como o vLLM — é construído para serving apoiado em GPU em vez do caso de uso de chat local de usuário único que ferramentas como Ollama e LM Studio visam.

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.

Ler em:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

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. Sua principal contribuição técnica é o RadixAttention, uma técnica de reutilização automática e granular do cache KV entre múltiplas chamadas de geração que compartilham um prefixo comum — como um prompt de sistema repetido, exemplos few-shot ou uma conversa de vários turnos. O SGLang combina esse backend com uma linguagem frontend embutida em Python para escrever programas de LLM com múltiplas chamadas, e com suporte a saída estruturada no nível do engine (esquemas JSON e restrições regex aplicadas durante a decodificação), posicionando-o tanto como um engine voltado à geração estruturada e cargas de trabalho agênticas quanto ao throughput bruto.

SGLang explicado: RadixAttention e serving estruturado de LLM (2026)

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.

O DSL frontend

O SGLang oferece primitivas em Python — incluindo sgl.gen para geração, sgl.select para escolher entre um conjunto fixo de opções, e sgl.fork para ramificar em caminhos de geração paralelos — que permitem a um desenvolvedor expressar um programa de LLM de múltiplas etapas (por exemplo: gerar um plano, depois ramificar em várias sub-gerações paralelas, depois combinar resultados) como código Python comum, com o runtime cuidando automaticamente do batching e da reutilização de cache entre os ramos.

Saída estruturada no nível do engine

Quando uma requisição especifica um esquema JSON ou uma expressão regular que a saída deve seguir, o SGLang aplica essa restrição dentro do loop de decodificação mascarando os logits de qualquer token que violaria o esquema ou padrão naquele passo — em vez de gerar texto sem restrições e validá-lo ou tentar novamente depois. O projeto documenta uma representação interna de máquina de estados finitos comprimida para essas restrições, projetada para permitir que o engine decodifique vários tokens em uma única passagem quando a restrição determina de forma unívoca o que vem a seguir.

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:30000 nos 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.

  1. 1
    Confirme 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).
  2. 2
    Crie um ambiente virtual Python e depois instale o SGLang, por exemplo: `pip install "sglang[all]"`.
  3. 3
    Inicie 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.
  4. 4
    Envie uma requisição de chat básica com qualquer cliente compatível com a API da OpenAI, por exemplo o pacote Python openai apontando para base_url="http://127.0.0.1:30000/v1".
  5. 5
    Para 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.
  6. 6
    Para serving multi-GPU, adicione uma flag tensor-paralela, por exemplo --tp-size 2 para dividir o modelo entre duas GPUs.
  7. 7
    Aponte 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.
Artigos sobre SGLang (5)

Também mencionado em:

+1 mais não exibidos

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.
Artigos sobre llama.cpp (10)

+168 mais não exibidos

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.
Artigos sobre TensorRT-LLM (6)

Também mencionado em:

+1 mais não exibidos

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.

Use o SGLang se

  • Você está implantando um LLM atrás de uma API que muitos usuários ou serviços downstream chamarão simultaneamente, especialmente com prompts de sistema repetidos, exemplos few-shot ou conversas multi-turno
  • Sua aplicação exige saída garantidamente conforme a um esquema JSON ou regex — function calling, agentes que usam ferramentas, ou extração de dados estruturados
  • Você quer escrever programas de LLM de múltiplas etapas (gerações ramificadas, sub-chamadas paralelas) usando um DSL embutido em Python em vez de orquestrar você mesmo chamadas de API separadas
  • Você tem acesso a uma ou mais GPUs NVIDIA (ou uma implantação AMD/Intel/TPU suportada) e quer um servidor de API compatível com OpenAI auto-hospedado
  • Você está confortável com um ambiente Python, configuração via linha de comando e configuração de GPU/CUDA

Evite o SGLang se

  • Você quer rodar um modelo no seu próprio notebook ou desktop para chat pessoal de usuário único — Ollama ou LM Studio atendem muito melhor a essa necessidade
  • Você não tem uma GPU suportada — o SGLang não é construído em torno de hardware exclusivamente CPU ou Apple Silicon como llama.cpp ou Ollama
  • Você quer uma interface gráfica para clicar em vez de um servidor de API, um DSL em Python e flags de linha de comando
  • Sua carga de trabalho não tem prefixos de prompt repetidos nem requisito de saída estruturada — nesse caso, RadixAttention e decodificação restrita oferecem pouca vantagem sobre qualquer outro engine de serving

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).
Artigos sobre SGLang (5)

Também mencionado em:

+1 mais não exibidos

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.
Artigos sobre vLLM (10)

+85 mais não exibidos

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.
Artigos sobre Ollama (10)

+313 mais não exibidos

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.
Artigos sobre llama.cpp (10)

+168 mais não exibidos

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.

Comparar no diretório

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.

Erro 1: tentar rodá-lo em um notebook sem GPU dedicada

O SGLang não é construído em torno de hardware exclusivamente CPU ou Apple Silicon como llama.cpp ou Ollama. Tentar rodá-lo em um notebook apenas com CPU ou um Mac com Apple Silicon tipicamente leva a desempenho ruim ou atrito de configuração que uma ferramenta local feita especificamente para isso evitaria completamente.

Erro 2: esperar que o RadixAttention acelere tráfego sem prefixos compartilhados

O benefício do RadixAttention vem especificamente da reutilização do estado do cache KV entre requisições que compartilham um prefixo de sequência de tokens. Se cada requisição na sua carga de trabalho é totalmente independente — prompts de sistema diferentes, sem exemplos few-shot, sem histórico de conversa —, há pouco ou nenhum prefixo compartilhado para o RadixAttention reutilizar, e o ganho em relação a um engine sem cache será pequeno.

Erro 3: pedir JSON no prompt em vez de usar os parâmetros de saída estruturada

Pedir a um modelo para "responder em JSON" sem usar os parâmetros de decodificação restrita por esquema do SGLang ainda permite que o modelo produza saída malformada ou não conforme. O benefício de confiabilidade da saída estruturada no nível do engine só se aplica quando o esquema JSON ou a restrição regex é realmente passado através dos campos de saída estruturada da API.

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.

Fontes

← Voltar para LLMs locais avançados

MCP