A LMSYS adicionou um alocador de memória unificada experimental ao SGLang para arquiteturas de modelos híbridos, incluindo GPT-OSS, Qwen3.5 e Kimi K3. Esses modelos combinam camadas de atenção completa, atenção de janela deslizante e camadas recorrentes ou de atenção linear, cada uma com um perfil de uso diferente da memória de alta largura de banda (HBM) da GPU. Antes, o SGLang exigia que os operadores dividissem a HBM entre esses tipos de estado antes da inicialização; o novo alocador permite que compartilhem uma única arena e ajusta o layout conforme o tráfego muda, reduzindo a capacidade ociosa e as remoções evitáveis.
Por que os pools fixos desperdiçam HBM
A decodificação autorregressiva armazena tensores de chave e valor (KV) de tokens anteriores para calcular o próximo. As camadas de atenção completa retêm o KV de todo o contexto, de modo que seu consumo cresce com o comprimento da sequência. As camadas de janela deslizante mantêm apenas um sufixo limitado, enquanto as camadas recorrentes e de atenção linear mantêm um estado de tamanho fixo para cada requisição ativa, o que faz seu consumo depender principalmente da concorrência.
O alocador anterior do SGLang dividia a HBM em pools separados configurados por --swa-full-tokens-ratio e --mamba-full-memory-ratio. O tráfego de contexto longo podia esgotar o pool de atenção completa enquanto a capacidade de KV de janela e de estado recorrente ficava ociosa, e o tráfego curto e altamente concorrente podia preencher os pools de estado limitado enquanto a capacidade de atenção completa ficava sem uso. A memória livre não podia atravessar as fronteiras entre pools.
Uma única arena, layouts mistos
Ao ativar --enable-unified-memory, o KV de atenção completa é posicionado na extremidade superior de uma única arena e cresce para baixo. O KV de janela deslizante e o estado recorrente começam na extremidade inferior e crescem para cima, enquanto a compactação tardia preserva uma região livre entre eles. As flags de proporção continuam disponíveis, mas apenas como sugestões de posicionamento inicial; elas não impõem mais partições de capacidade fixas após a inicialização.
O alocador representa um token, ou um slot de estado recorrente, como uma entrada contendo linhas para cada camada participante. Uma página é uma sequência contígua de entradas, de forma que alocação, remoção e movimentação de páginas atualizam todas as camadas em conjunto. As linhas dentro de uma entrada podem manter formatos e tipos de dados diferentes. Esse layout permite que o KV do modelo de rascunho especulativo compartilhe armazenamento e regras de ciclo de vida com o KV do modelo alvo, mesmo quando os tipos de dados diferem. Ele também mantém as chaves de índice da Dynamic Sparse Attention do Kimi K3.1 ao lado do KV de Multi-head Latent Attention ao qual se referem.
A admissão vira um problema de empacotamento
Uma requisição de entrada pode precisar de páginas de atenção completa, páginas de janela deslizante e um slot de estado recorrente ao mesmo tempo. O SGLang avalia o layout disponível em três etapas de custo crescente:
- Reuso no local: preencher os espaços existentes e estender qualquer uma das faixas das extremidades sem mover dados.
- Compactar as extremidades: empacotar as alocações dentro das faixas alta e baixa para eliminar lacunas internas.
- Relayout: mover alocações elegíveis para o espaço entre as faixas extremas compactadas.
IDs de página virtuais mantêm as referências lógicas estáveis enquanto o SGLang copia uma página e remapeia sua localização física. Um registro de uso de páginas acompanha os passes de forward do modelo, as cópias do HiCache e as transferências de rede que ainda referenciam cada página. Quando uma requisição libera uma página, o SGLang a marca como logicamente livre e retém seu endereço físico fora de novas alocações até que o registro não mostre usuários pendentes.
Onde a H200 ganhou folga
A LMSYS comparou a memória unificada com a configuração padrão de pools separados do SGLang em uma única NVIDIA H200. As cargas de trabalho testadas mostraram quase paridade sob pressão moderada e maior capacidade de requisições quando um pool fixo se tornava o gargalo.
Resultados de benchmark em uma única H200 reportados pela LMSYS:
| Modelo e carga de trabalho | Pools separados | Memória unificada |
|---|---|---|
| Qwen3.5-4B, 1.024 tokens de entrada, 256 tokens de saída, concorrência 64 | 5.880 tokens de saída/s | 5.830 tokens de saída/s com acurácia GSM8K idêntica |
| GPT-OSS-20B sob concorrência máxima | 618 requisições simultâneas; 43 s de tempo até o primeiro token | Cerca de 1.000 requisições simultâneas; 6 s de tempo até o primeiro token; 14% mais de throughput |
| Qwen3.5-4B, 16K tokens de entrada, 4.096 tokens de saída, concorrência 64 | 22 requisições ativas | 32 requisições ativas e 26% mais de throughput |
| Qwen3.5-4B, 512 tokens de entrada, 16.384 tokens de saída, concorrência 51 | Cerca de 294 retrações por 1.000 requisições concluídas | Cerca de 233 retrações por 1.000 requisições concluídas |
Um teste de sensibilidade separado com GPT-OSS-20B mostrou o custo de uma divisão estática ruim: definir --swa-full-tokens-ratio como 0,1 reduziu o throughput em 12% em relação à proporção padrão.
Uma retração ocorre quando a pressão de memória força o escalonador a remover uma requisição em andamento do lote ativo. Menos retrações reduzem a instabilidade de escalonamento e o trabalho repetido durante gerações longas.
Esses números cobrem uma única H200 e as cargas de trabalho listadas; implantações multi-GPU e tráfego de produção ainda exigem validação específica por carga de trabalho.
Suporte em toda a pilha de servir
Integrações do SGLang disponíveis com memória unificada:
| Área | Caminhos suportados |
|---|---|
| Escalonamento e cache | Overlap scheduling, Radix cache e HiCache |
| Execução distribuída | Desagregação prefill/decode, paralelismo de pipeline, paralelismo de contexto de decodificação e data-parallel attention |
| Decodificação especulativa | EAGLE, EAGLE3, DFLASH e DSPARK; rascunhos fundidos compatíveis podem compartilhar o armazenamento de entradas com o KV do modelo alvo |
O guia de uso do SGLang documenta a configuração, e o guia de design fornece a matriz de compatibilidade de backends e os detalhes do alocador.
Limites atuais orientam a implantação
A memória unificada continua experimental e é voltada a modelos híbridos.
- Sem suporte: modelos com apenas camadas de atenção completa, MLA combinada com camadas de janela deslizante e DeepSeek-V4.
- A desagregação prefill/decode requer Mooncake e não pode rodar junto com paralelismo de pipeline, decodificação especulativa ou paralelismo de contexto de decodificação.
- O HiCache não pode rodar junto com EAGLE ou EAGLE3.
- A preempção por prioridade fica desativada enquanto a memória unificada estiver ativa.
Reproduza a mistura de tráfego antes do rollout
A avaliação em produção deve começar em staging com --enable-unified-memory e traces que cubram tráfego de contexto longo, de requisições curtas e de alta concorrência. As equipes podem comparar o throughput de saída, o tempo até o primeiro token, o máximo de requisições ativas e as retrações com sua configuração atual de pools divididos, e então verificar cada backend habilitado contra a matriz de compatibilidade do SGLang.