SGLang

01 · Conceito

Conceito

Seu tráfego não é o que a lição 8.4 supôs. Em vez de usuários independentes fazendo perguntas independentes, você está rodando um agente: uma tarefa se abre em quarenta chamadas ao modelo, cada uma começando com o mesmo system prompt, os mesmos schemas de tools e os mesmos exemplos few-shot — cerca de três mil tokens de preâmbulo idêntico — e divergindo apenas no último parágrafo. Toda chamada precisa devolver um objeto JSON que o seu código vai parsear. Num engine de propósito geral essa carga é silenciosamente patológica, e entender por quê é a razão inteira de o SGLang existir.

Precifique o desperdício com o número que você já tem. A lição 7.2 estabeleceu 64 KiB de KV por token para o Qwen3.8-27B. Um preâmbulo de três mil tokens ocupa, portanto,

de cache. Quarenta chamadas concorrentes, cada uma guardando a própria cópia, dão cerca de 7,3 GiB de KV duplicado — pressão relevante em qualquer pool realizado, cujo orçamento completo pertence à lição 9.3. O compute é igualmente ruim: o preâmbulo sofre prefill quarenta vezes, cento e vinte mil tokens de trabalho de attention para produzir um prefixo que o engine já computou trinta e nove vezes naquele mesmo segundo.

O RadixAttention é a correção, e seu formato decorre do que o cache de fato é. Blocos de KV são função dos ids de token que os produziram e de suas posições, então duas sequências que começam com a mesma sequência de tokens têm blocos idênticos para esse trecho. O SGLang organiza, portanto, o pool de blocos como uma radix tree indexada por ids de token: uma requisição que chega percorre a árvore desde a raiz, reaproveita cada bloco ao longo do caminho casado mais longo e aloca apenas para o sufixo em que diverge. A eviction é least-recently-used sobre essa árvore, então prefixos quentes — o seu system prompt — permanecem residentes enquanto conversas avulsas envelhecem e saem. No nosso exemplo o preâmbulo é armazenado uma vez, com cerca de 188 MiB, e sofre prefill uma vez, recuperando cerca de sete gibibytes de pool e trinta e nove quarenta avos do custo de prefill do preâmbulo.

A segunda coisa que o SGLang trata como cidadã de primeira classe é que suas quarenta chamadas são um programa, não quarenta requisições sem relação. Elas têm dependências, se ramificam e se juntam, e algumas são ramos especulativos que você vai descartar. Quando o runtime conhece a estrutura do programa, ele pode escalonar com esse conhecimento — mantendo o prefixo de um ramo fixado enquanto seus filhos rodam, agrupando os irmãos em batch, ordenando o trabalho de modo que um pai compartilhado seja computado antes da bifurcação em vez de quarenta vezes depois dela. Um engine que só enxerga requisições HTTP independentes consegue recuperar parte disso a posteriori pelo casamento de prefixo, mas não consegue antecipá-lo.

A saída estruturada é a terceira peça, e é o que transforma a exigência de JSON em garantia em vez de esperança. A lição 7.4 descreveu o sampling como sortear a partir da distribuição sobre o vocabulário. O decoding restrito compila o seu schema JSON ou gramática numa máquina de estados e, a cada passo, mascara os logits de todo token que não pode legalmente seguir o texto até ali, antes que o sampling aconteça. O modelo não consegue emitir um pedido de desculpas em prosa antes da chave, não consegue fechar um array que não abriu e não consegue inventar um nome de campo fora do schema — não porque foi pedido com educação, mas porque esses tokens tiveram sua probabilidade zerada. Duas notas práticas: compilar uma gramática custa tempo real, então schemas devem ser reaproveitados e cacheados em vez de construídos por requisição; e a restrição se aplica apenas ao formato.

A arquitetura híbrida acrescenta ao compartilhamento de prefixo uma ruga que vale enunciar com precisão, porque é a coisa mais profunda desta lição. Apenas as 16 camadas de full attention armazenam blocos de KV por token, que são exatamente o que uma radix tree consegue compartilhar. As 48 camadas Gated DeltaNet guardam um estado recorrente de tamanho fixo que é um resumo de tudo processado até ali — ele não tem estrutura por token e não pode ser indexado nem parcialmente reaproveitado. Para uma requisição retomar de um prefixo compartilhado, o engine precisa portanto ter também feito checkpoint do estado recorrente naquela fronteira de prefixo e ser capaz de restaurá-lo. A implementação de referência armazena cerca de 144 MiB por sequência quando esse estado está em fp32 — a mesma ordem dos 188 MiB de KV compartilhado deste exemplo, não um acréscimo desprezível. Um runtime de serving pode usar outro dtype ou layout de estado, portanto inspecione a alocação realizada. Esse é um mecanismo genuinamente diferente do compartilhamento de blocos, e se um dado release o implementa — em vez de silenciosamente cair em recomputação completa, ou pior, reaproveitar blocos contra um estado desatualizado — é uma questão por versão a verificar, não a supor. O SGLang publica uma página oficial de cookbook para exatamente este modelo, que é o ponto de partida certo justamente porque fixa as versões e configurações que os mantenedores exercitaram.

Uma regra de fronteira sobrevive a tudo isso sem alteração. O reuso é casamento exato por ids de token, então nenhum conteúdo cruza entre requisições que já não o compartilhassem literalmente — mas um acerto de cache é mais rápido que uma falha, e tempo é observável. Trate o compartilhamento de prefixo entre tenants como uma decisão a tomar deliberadamente, mantenha tenants em pools separados quando o próprio prompt é confidencial, e releia o alerta da lição 7.2 sobre keys e values cacheados serem um registro rico do que um usuário disse.

O mapa da lição 7.11 dizia que o SGLang conquista seu lugar quando o seu tráfego são programas e não prompts. Agora você consegue dizer por quê em números: sete gibibytes de pool e trinta e nove prefills redundantes recuperados de uma única carga, e um contrato JSON imposto no sampler em vez de esperado no prompt.