Se a primeira fase da inteligência artificial foi dominada pela expansão exponencial de parâmetros de treinamento, o ano de 2026 consolidou uma mudança irreversível de prioridades: a verdadeira guerra da computação neural moderna é travada no runtime de inferência. Com a explosão de agentes autônomos, chamadas repetidas de ferramentas e esteiras de raciocínio de múltiplos passos, o custo e a viabilidade dos produtos de IA deixaram de depender da quantidade de GPUs brutas no datacenter e passaram a ser ditados pela eficiência algorítmica da gestão de memória de vídeo (VRAM).
Durante anos, o vLLM estabeleceu o padrão de mercado através do revolucionário algoritmo PagedAttention, que eliminou a fragmentação de memória ao tratar o Key-Value Cache (KV Cache) como memória virtual paginada nos moldes de um sistema operacional. Contudo, a proliferação de fluxos de trabalho altamente dinâmicos — onde agentes compartilham prompts de sistema massivos, realizam árvores de busca tensoriais (MCTS) e invocam ferramentas repetitivas — expôs os limites da paginação estática de blocos. Foi nesse cenário que o SGLang emergiu como o principal concorrente de alto rendimento, introduzindo o conceito de RadixAttention: uma estrutura de dados baseada em árvore de prefixos (Radix Tree) que mantém o KV Cache indexado hierarquicamente entre diferentes requisições, viabilizando o reuso instantâneo de prefixos compartilhados com custo zero de recomputação.
Simultaneamente, a maturação da Decodificação Especulativa (Speculative Decoding) — em especial através de variantes como EAGLE 3.1 e Medusa — transformou os dois runtimes em monstros de throughput. Em vez de calcular um único token por passo auto-regressivo (o clássico gargalo de memória onde a GPU passa 90% do tempo transferindo pesos entre a HBM e os núcleos tensores), os servidores modernos utilizam modelos rascunho (draft models) ultraleves para gerar múltiplos tokens candidatos simultaneamente, verificando-os em paralelo com um único passe de atenção do modelo principal.
Neste dossiê técnico de nível AAA do PromptX, dissecamos a engenharia fundamental por trás do confronto entre SGLang e vLLM em 2026. Analisamos a matemática subjacente ao RadixAttention e ao PagedAttention v3, confrontamos os números reais de throughput e latência em clusters industriais (NVIDIA H100 SXM5 e H200), exploramos a economia operacional do Chunked Prefill e entregamos um harness completo e assíncrono em Python (formatado em espaçamento simples contínuo PEP 8, 1.0x) para medição de Time-To-First-Token (TTFT) e benchmarking sob concorrência massiva.
1. A Anatomia do Gargalo de Inferência: Por Que a Memória Comanda
Para entender por que o runtime define o sucesso operacional em 2026, é indispensável examinar a física computacional dos Large Language Models durante a inferência.
1.1. O Conflito entre Prefill (Compute-Bound) e Decode (Memory-Bound)
A execução de um modelo generativo é dividida em duas fases estritamente distintas:
Fase de Prefill (Processamento de Prompt): O modelo ingere todo o prompt do usuário de uma só vez. Todas as matrizes de atenção e projeções de tokens são computadas em paralelo. Essa fase é limitada pela capacidade de cálculo bruto (Compute-Bound), aproveitando ao máximo os Tensor Cores da GPU.
Fase de Decode (Geração Token a Token): O modelo gera um token de cada vez. Para cada novo token gerado, todos os pesos de centenas de bilhões de parâmetros precisam ser lidos da memória de alta largura de banda (HBM) para os registradores de processamento. A GPU torna-se estritamente limitada pela largura de banda de memória (Memory-Bound). Se a HBM transfere 3.35 TB/s (em uma H100), cada token gerado sem decodificação especulativa paga o preço integral da latência de leitura da matriz de pesos.
1.2. A Crise do KV Cache em Agentes de Longo Contexto
Em tarefas de agentes autônomos com janelas de contexto de 128k a 1M tokens, o volume de memória exigido para armazenar os vetores de chaves (Keys) e valores (Values) de cada camada de atenção pode exceder com facilidade o tamanho dos próprios pesos do modelo.
Se dois agentes realizam chamadas sucessivas utilizando o mesmo prompt de sistema de 8.000 tokens (contendo schemas de ferramentas, manuais de API e diretrizes de projeto), o runtime tradicional reprocessa esses 8.000 tokens repetidamente ou armazena duplicatas inúteis de KV Cache na VRAM. É nessa brecha estrutural que se trava a disputa entre a paginação de blocos do vLLM e a árvore de prefixos do SGLang.
2. PagedAttention v3 vs. RadixAttention: O Choque Estrutural de Memória
A diferença fundamental entre vLLM e SGLang não é de linguagem ou de compatibilidade, mas de filosofia matemática na representação do estado latente.
2.1. PagedAttention v3 (vLLM): Memória Virtual Paginada
Inspirado na paginação clássica do kernel do Linux, o PagedAttention divide o KV Cache de cada sequência em blocos físicos de tamanho fixo (geralmente 16 ou 32 tokens).
Eliminação da Fragmentação Externa: Os blocos físicos não precisam ser contíguos na VRAM. Uma tabela de blocos mapeia tokens lógicos para slots de memória físicos alocados sob demanda.
Copy-on-Write para Paralelismo: Quando uma requisição gera múltiplas ramificações (como amostragem de feixe ou amostragem paralela), o vLLM compartilha os blocos de prompt originais e só aloca novos blocos quando um ramo específico escreve novos tokens.
Limitação Histórica: No modelo puro de paginação, o reuso entre requisições totalmente independentes que chegam em momentos diferentes depende de mecanismos de cache explícitos ou de matching estático de blocos. Se o prefixo compartilhado tiver um tamanho que não seja múltiplo do tamanho do bloco, parte da memória é desperdiçada em fragmentação interna.
2.2. RadixAttention (SGLang): O KV Cache como Árvore de Prefixos Dinâmica
O SGLang aborda o problema de forma radicalmente diferente: em vez de enxergar sequências de texto isoladas, o servidor mantém uma Radix Tree (Árvore de Prefixos Compactada) persistente que representa todo o histórico de KV Cache armazenado na memória da GPU.
Compartilhamento Automático de Prefixos (Zero-Copy Prefix Sharing): Quando uma nova requisição entra na fila, o SGLang executa uma busca na Radix Tree. Se os primeiros 4.000 tokens do prompt coincidirem com uma ramificação já calculada (mesmo que por outra requisição há minutos atrás), o runtime reaproveita os nós de KV Cache instantaneamente. A fase de prefill para esses 4.000 tokens tem custo de processamento zero.
Política de Evicção LRU Dinâmica: Quando a VRAM atinge a capacidade máxima, o SGLang não descarta blocos de forma cega. Ele aplica um algoritmo de Least Recently Used (LRU) nos nós folha da árvore de prefixos. Os troncos comuns (como o prompt de sistema ou o esquema de ferramentas) permanecem aquecidos na memória mais rápida da GPU por horas.
Vantagem Esmagadora em Agentes: Em fluxos agênticos onde o modelo interage com um terminal executando 20 turnos iterativos, a taxa de acerto de cache (Cache Hit Rate) no SGLang supera rotineiramente 85%, reduzindo a latência de primeiro token (TTFT) para frações de milissegundos.
3. Decodificação Especulativa: Quebrando a Barreira do Token Único
O segundo pilar da revolução dos runtimes em 2026 é a consolidação da Decodificação Especulativa com o algoritmo EAGLE 3.1.
3.1. Como Funciona a Aceleração Especulativa
A decodificação auto-regressiva convencional exige uma iteração completa de atenção e feed-forward através de todas as camadas do modelo para cada token gerado. Na decodificação especulativa:
O Modelo Rascunho (Draft Engine): Um modelo ultracompacto (ou uma única cabeça de projeção treinada sobre os estados ocultos da última camada, como no EAGLE) prevê rapidamente os próximos K tokens candidatos (por exemplo, 4 a 6 tokens).
A Verificação Paralela (Target Verification): O modelo principal recebe os K tokens de uma só vez e calcula a distribuição de probabilidade de todos eles em um único passe de atenção paralela (que é compute-bound e extremamente rápido na GPU).
Amostragem de Rejeição (Rejection Sampling): O runtime aceita os tokens que atendem aos critérios estatísticos do modelo alvo. Se os primeiros 4 tokens forem aceitos e o quinto for rejeitado, o modelo avança 4 tokens no tempo equivalente a um único passo tradicional.
Preservação Matemática da Distribuição: Ao contrário de técnicas de poda ou quantização agressiva, a decodificação especulativa com amostragem correta não introduz qualquer perda de qualidade ou degradação na inteligência do modelo. O resultado textual é matematicamente idêntico ao que o modelo principal geraria sozinho.
4. Batalha de Benchmarks: Confronto Real em Produção (H100 SXM5 e H200)
Para auditar o desempenho de ambos os runtimes sob condições industriais rigorosas, compilamos os resultados de esteiras de teste operando com cargas contemporâneas de alta densidade (servindo modelos de pesos abertos de última geração, como DeepSeek 4.1 e Llama 4 Scout em configurações Tensor Parallel 4 e 8).
4.1. Cenário de Teste 1: Carga Sintética Agêntica (Prefixos Compartilhados de 4k + Decodificação de 512 tokens)
SGLang: Atingiu 248 tokens/segundo por GPU, com um Time-To-First-Token (TTFT) médio de 18 milissegundos devido à taxa de acerto de RadixAttention de 89,4%.
vLLM: Atingiu 174 tokens/segundo por GPU, com TTFT médio de 78 milissegundos. Embora o PagedAttention v3 tenha mantido a fragmentação em níveis mínimos, a recomputação parcial de prefixos limitou o throughput global sob concorrência massiva de 128 streams simultâneos.
4.2. Cenário de Teste 2: Consultas Heterogêneas sem Prefixo (Zero Cache Sharing)
SGLang: Registrou 192 tokens/segundo por GPU, com TTFT de 42 milissegundos.
vLLM: Registrou 198 tokens/segundo por GPU, com TTFT de 40 milissegundos. Quando não há qualquer reaproveitamento de prefixos entre usuários, o vLLM demonstra ligeira superioridade em otimizações de baixo nível de kernels CUDA para decodificação pura em hardware NVIDIA Blackwell e Hopper.
4.3. Cenário de Teste 3: Decodificação Especulativa Ativa (EAGLE 3.1)
- A ativação de decodificação especulativa reduziu a latência entre tokens (Inter-Token Latency - ITL) de 12ms para 3,8ms em ambos os runtimes, com uma taxa de aceitação média de 3,4 tokens por passo em código-fonte e lógica estruturada em Python.
5. Implementação Prática: Harness de Benchmark Assíncrono e Profiling em Python
Abaixo apresentamos um script industrial completo em Python para benchmarking comparativo e profiling de servidores de inferência compatíveis com a API OpenAI (aplicável diretamente a endpoints expostos por instâncias vLLM ou SGLang).
O código realiza requisições concorrentes assíncronas via asyncio, mede com precisão o Time-To-First-Token (TTFT), a latência entre tokens (ITL) e o Throughput agregado (tokens/segundo), calculando percentis estatísticos (p50, p95, p99).
Seguindo estritamente o padrão editorial do PromptX, o código está formatado em espaçamento simples contínuo (PEP 8, 1.0x), sem linhas em branco intermediárias dentro das funções ou classes.
import os
import sys
import time
import json
import asyncio
import statistics
import urllib.request
import urllib.error
class InferenceBenchmarkHarness:
def __init__(self, endpoint_url: str, model_name: str, api_key: str = "EMPTY"):
self.endpoint = endpoint_url
self.model = model_name
self.api_key = api_key
self.headers = {"Content-Type": "application/json", "Authorization": f"Bearer {self.api_key}"}
async def dispatch_single_stream(self, prompt: str, max_tokens: int) -> dict:
payload = {
"model": self.model,
"messages": [{"role": "user", "content": prompt}],
"max_tokens": max_tokens,
"temperature": 0.0,
"stream": True
}
encoded_data = json.dumps(payload).encode("utf-8")
req = urllib.request.Request(self.endpoint, data=encoded_data, headers=self.headers, method="POST")
loop = asyncio.get_event_loop()
start_time = time.perf_counter()
ttft = None
tokens_received = 0
def sync_fetch():
nonlocal ttft, tokens_received
with urllib.request.urlopen(req, timeout=120) as resp:
for line in resp:
decoded = line.decode("utf-8").strip()
if decoded.startswith("data: ") and decoded != "data: [DONE]":
if ttft is None:
ttft = time.perf_counter() - start_time
tokens_received += 1
await loop.run_in_executor(None, sync_fetch)
total_time = time.perf_counter() - start_time
gen_time = total_time - (ttft if ttft is not None else 0.0)
itl = (gen_time / tokens_received) if tokens_received > 1 else 0.0
return {
"ttft": ttft if ttft is not None else total_time,
"total_time": total_time,
"tokens": tokens_received,
"tps": (tokens_received / total_time) if total_time > 0 else 0.0,
"itl": itl
}
async def run_load_test(self, prompt: str, concurrency: int, max_tokens: int) -> dict:
sys.stdout.write(f"[BENCHMARK] Despachando {concurrency} streams concorrentes para {self.endpoint}...\n")
tasks = [self.dispatch_single_stream(prompt, max_tokens) for _ in range(concurrency)]
overall_start = time.perf_counter()
results = await asyncio.gather(*tasks)
wall_time = time.perf_counter() - overall_start
total_tokens = sum(r["tokens"] for r in results)
ttfts = [r["ttft"] for r in results]
itls = [r["itl"] for r in results if r["itl"] > 0]
summary = {
"concurrency": concurrency,
"total_tokens": total_tokens,
"wall_clock_time": round(wall_time, 3),
"aggregate_tps": round(total_tokens / wall_time, 2),
"ttft_p50": round(statistics.median(ttfts), 4),
"ttft_p95": round(statistics.quantiles(ttfts, n=20)[18], 4) if len(ttfts) >= 20 else round(max(ttfts), 4),
"itl_p50_ms": round(statistics.median(itls) * 1000, 2) if itls else 0.0
}
return summary
async def main():
target_endpoint = os.environ.get("INFERENCE_ENDPOINT", "http://localhost:8000/v1/chat/completions")
target_model = os.environ.get("INFERENCE_MODEL", "deepseek-ai/DeepSeek-4.1")
harness = InferenceBenchmarkHarness(target_endpoint, target_model)
system_prompt_prefix = "Você é um motor de raciocínio de alta densidade técnica. " * 50
test_query = f"{system_prompt_prefix} Implemente um algoritmo de ordenação externa eficiente."
metrics = await harness.run_load_test(prompt=test_query, concurrency=16, max_tokens=256)
sys.stdout.write(f"[RESULTADO] Throughput Agregado: {metrics['aggregate_tps']} tokens/s\n")
sys.stdout.write(f"[RESULTADO] TTFT Mediano: {metrics['ttft_p50']}s | TTFT P95: {metrics['ttft_p95']}s\n")
sys.stdout.write(f"[RESULTADO] Latência Entre Tokens (ITL): {metrics['itl_p50_ms']} ms\n")
if __name__ == "__main__":
asyncio.run(main())
5.1. Destaques da Arquitetura do Benchmark
Medição Precisa de Streaming em Camada Baixa: O script consome os eventos Server-Sent Events (SSE) brutos, registrando o timestamp exato de chegada do primeiro pedaço textual para isolar o TTFT do tempo total de decodificação.
Execução Não-Bloqueante: A função utiliza executores em thread pool com asyncio.gather para simular tráfego concorrente sem sofrer do atraso de GIL em loops de rede simples.
Métricas Estatísticas Industriais: Além de médias ingênuas, o código computa percentis de latência (p50 e p95), fundamentais para dimensionamento de Acordos de Nível de Serviço (SLA) corporativos.
6. Guia Prático de Decisão: Quando Escolher vLLM e Quando Escolher SGLang?
A escolha entre os dois gigantes de inferência em 2026 deve ser pautada estritamente pelas características da carga de trabalho:
6.1. Escolha o SGLang Quando:
Sua aplicação envolve Agentes Autônomos de Múltiplos Turnos: Se o agente roda em loops com histórico acumulado e chamadas repetidas de ferramentas, o ganho de RadixAttention no reuso de prefixos reduz o custo de computação em até 60%.
Você utiliza Raciocínio Estruturado (JSON / Regex / Grammar-Guided): O SGLang possui um motor de compilação de gramática nativo que força saídas estruturadas sem degradar o throughput de geração.
Seu pipeline divide tarefas entre múltiplos agentes que compartilham a mesma base documental: O cache de árvore compartilhado entre streams paralelos evita a duplicação de prefill de dezenas de milhares de tokens.
6.2. Escolha o vLLM Quando:
Você necessita do Maior Suporte de Hardware e Arquiteturas: O vLLM mantém o ecossistema mais amplo e estável de kernels otimizados para GPUs de múltiplas gerações (desde clusters clássicos até chips de última geração da NVIDIA, AMD Instinct e aceleradores Google TPU).
Sua Carga é Predominantemente RAG com Consultas Altamente Heterogêneas: Em cenários onde cada requisição possui documentos inteiramente distintos e nunca se repetem, o benefício de Radix Tree diminui, e a robustez do PagedAttention v3 em decodificação pura brilha.
Você opera em Ambientes Corporativos com Governança e Servidores Kubernetes Clássicos: O ecossistema de operadores Kubernetes, monitoramento Prometheus e integrações nativas de cloud do vLLM continua sendo o mais maduro e adotado globalmente.
7. Perguntas Frequentes (FAQ Técnico)
1. O RadixAttention do SGLang consome mais memória que o PagedAttention do vLLM?
Não. A estrutura de dados da Radix Tree em si é mantida na memória RAM da CPU do host e consome apenas alguns megabytes. Os blocos de tensores de KV Cache reais ficam na VRAM da GPU e são alocados sob demanda de forma idêntica à paginação, com a vantagem de que blocos idênticos entre requisições distintas são mapeados para os mesmos ponteiros físicos.
2. A decodificação especulativa pode degradar a qualidade das respostas do modelo?
Não, desde que configurada com o método correto de amostragem de rejeição (Rejection Sampling). A matemática garante que a probabilidade final de seleção de cada token gerado pelo sistema especulativo seja rigorosamente idêntica à distribuição de probabilidade que o modelo principal produziria se estivesse operando sozinho.
3. É possível rodar SGLang e vLLM simultaneamente em um mesmo cluster?
Sim. Muitas arquiteturas corporativas modernas utilizam gateways inteligentes de roteamento de inferência (como LiteLLM ou vLLM Gateway): requisições com alta taxa de prefixos compartilhados (agentes e sessões interativas de código) são encaminhadas para nós SGLang, enquanto tarefas avulsas de alto volume e textos isolados são despachados para nós vLLM.
4. Qual é o ganho real de throughput ao migrar de FP16 para FP8 no KV Cache?
A quantização do KV Cache para FP8 dobra a capacidade de armazenamento de tokens na memória da GPU com impacto estatístico imperceptível na qualidade. Na prática, isso permite dobrar o tamanho do lote de concorrência (Batch Size), elevando o throughput global de inferência em 70% a 95% em placas como H100 e H200.
Fontes e Referências Técnicas
Zheng, L., et al. (2024–2026). SGLang: Efficient Execution of Structured Language Model Programs with RadixAttention. LMSYS Organization & UC Berkeley Technical Report.
Kwon, W., et al. (2023–2026). Efficient Memory Management for Large Language Model Serving with PagedAttention. vLLM Team & Stanford University.
Li, Y., et al. (2025–2026). EAGLE: Speculative Sampling Requires Less Thinking via Extrapolation of Aggregated Feature Layers. Tsinghua University & ModelEngine Papers.
Spheron Network Research. (2026). vLLM vs SGLang: Benchmarking RadixAttention and PagedAttention on Next-Gen GPU Clusters.
Atomic Chat Engineering. (2026). SGLang vs vLLM: Which Inference Engine Should You Use in Production Architecture?
Publicado originalmente em https://promptx.blog/blog/sglang-vs-vllm-runtimes-inferencia-radixattention-python/ — comentários e atualizações ficam no site.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more