Vazamento do Qwen 4: PR de Host-Staging do SGLang mostra como a tabela PLE de 47,7 GiB cabe em uma única GPU

O número que vai decidir se Qwen 4 é um modelo que você consegue servir por conta própria não é a sua contagem de parâmetros. É 47,7 GiB — o tamanho da tabela de embeddings de n-gramas que acompanha a arquitetura do Qwen4, separada dos pesos, e que precisa ficar em algum lugar enquanto o modelo decodifica. Um pull request aberto no repositório do SGLang em 18 de setembro de 2026, intitulado [Qwen4-Exp] Adicionar staging no host para PLE com suporte a arquivos, é uma tentativa de impedir que essa tabela dite quanta RAM uma máquina precisa antes de conseguir rodar. O Qwen 4 ainda não foi lançado: nenhum model card, nenhum peso, nenhuma entrada em catálogo, nenhuma data. O único modelo já lançado que instancia essa arquitetura é Qwen3.8-Flash-Next, a prévia de pesos abertos publicada em 26 de agosto de 2026, cuja configuração declara model_type=qwen4_exp — a mesma string que dá nome ao pull request. Seu irmão de produção Qwen3.8-Flash é a versão que quem chama a API consegue de fato acessar hoje. Tudo neste texto sobre o Qwen 4 é inferência a partir dessa prévia e do código do motor; o pull request está aberto e não foi mesclado, então leia tudo isso como um sinal, e não como um recurso já disponível.

O que o sinal realmente é

O pull request sgl-project/sglang#40235 não é um lançamento e não foi mesclado. Ele está em um commit, aberto pelo contribuidor Dev-Jahn, mesclando um branch chamado task/ple-host-staged na linha principal do SGLang. Nove proprietários de código foram solicitados para revisão e todos aparecem como aguardando, então pelo menos uma revisão de aprovação separa isto da main. Três jobs de CI — o teste de PR base, o teste de PR extra e a execução do AMD ROCm — estão falhando no commit aberto. Essa é a condição normal de uma grande mudança de engine em andamento, e é também por isso que a parte interessante deste PR não é se ele entra, mas o que seu autor teve de medir para argumentar a favor dele. A descrição traz aproximadamente 1.400 linhas adicionadas, incluindo testes, e uma tabela de benchmark que representa os dados públicos mais concretos que alguém já publicou sobre executar esta arquitetura em uma única GPU.

Por que a tabela conta toda a história

Os embeddings por camada são a peculiaridade estrutural desta geração. Enquanto um modelo normal coloca um único embedding de token no início, o design do Qwen4 carrega uma grande tabela de n-gramas — bigramas e trigramas, com hash em um vocabulário muito maior que o do tokenizador — e alimenta consultas de embeddings por camada a partir dela ao longo de toda a pilha. O próprio material de prévia da Alibaba descreve o componente de n-gramas como dezenas de bilhões de parâmetros além do corpo MoE de 125 B parâmetros; análises detalhadas da comunidade sobre o checkpoint lançado estimam o arquivo da tabela em 47,7 GiB. Esses números vêm de fontes do fabricante e da comunidade, e não de reprodução independente, e a relação exata entre a tabela da prévia e o que quer que o Qwen 4 venha a lançar é desconhecida.

O que não está em dúvida é a consequência de engenharia. Uma tabela lateral de 47,7 GiB que precisa ser consultada a cada passo de decodificação não é algo que você possa empurrar discretamente para um canto da VRAM. Em uma placa de 96 GB, ela compete diretamente com o cache KV; em placas menores, simplesmente não cabe. É por isso que o SGLang, que implementou suporte no dia zero para a prévia no final de agosto, passou as três semanas seguintes produzindo um pull request atrás do outro sobre essa única estrutura de dados, e não sobre o modelo ao seu redor.

O que estava quebrado antes deste PR?

O SGLang já tinha duas maneiras de manter a tabela, e ambas tinham um lado áspero.

• Pinned mantém a tabela inteira na RAM do host e a lê a partir dela. Funciona, é rápido e torna o requisito de memória do host absoluto — não há uma versão menor dele.

• Com suporte a arquivo, adicionado antes em um pull request separado, mantém a tabela em um arquivo esparso e permite que o kernel de coleta leia o mapeamento diretamente, de modo que o cache de páginas do sistema operacional decide quanto dela fica residente. O problema é de hardware: esse caminho de leitura direta exige que a GPU reporte cudaDevAttrPageableMemoryAccessUsesHostPageTables — a capacidade que o próprio texto do PR descreve como "a classe GB10". Em uma GPU sem isso, o backend de arquivo é recusado de imediato e o pinned é a única opção restante.

A lacuna que isso cria não é teórica. Um relatório separado apresentado contra o mesmo caminho de código documenta um usuário com duas RTX 3090 cuja parcela da tabela por rank chegou a 23,84 GiB contra 23,56 GiB de memória utilizável — 0,28 GiB a menos, com 188 GiB de RAM do host livres. Nessa configuração, o backend de arquivo foi rejeitado pela verificação de hardware e a flag comum de CPU-offload gera erro quando combinada com a flag de PLE offload. Ficar trezentos megabytes abaixo com cento e oitenta gigabytes sobrando é exatamente o tipo de problema que este pull request existe para eliminar.

Que alterações no staging do host

O mecanismo que o PR adiciona é uma camada de preparação (staging) entre o arquivo e o dispositivo. Em vez de pedir à GPU para desreferenciar páginas do host, um componente do lado da CPU lê as linhas de que precisa por meio do mapeamento já existente do carregador e orienta o kernel a trazer essas páginas antecipadamente; uma variável de ambiente, SGLANG_QWEN4_PLE_FILE_PREFETCH, desativa essa orientação se você quiser medir sem ela. Cada camada PLE recebe então dois buffers fixados (pinned) de 8.192 linhas — cerca de 1,25 MiB cada em FP8 — e um worker. As linhas são reunidas em um buffer enquanto o outro está sendo copiado para o dispositivo, de modo que a coleta e a transferência se sobrepõem em vez de serem serializadas. Os identificadores de N-gramas passam por hash no host, e não no dispositivo. A reprodução de grafo (graph replay) recebe uma chamada de preparação antes de cada reprodução, e a thread de lançamento aguarda a etapa anterior.

Esse último detalhe é o custo, e o PR o afirma sem rodeios: aproximadamente 0,5 a 1 milissegundo adicionado por passo de decodificação em relação ao caminho fixado. Todo o resto é o ganho. Medido em uma única RTX PRO 6000 Blackwell com 96 GB, um host AMD EPYC com 377 GiB de RAM, CUDA 13.2, usando os checkpoints públicos FP8 e NVFP4 do Qwen3.8-Flash-Next:

• Cache de páginas do host, FP8 TP4/EP4 — 71 GB fixados e sem limite, contra 49 GB com um limite de 64 GB, 15 GB com 32 GB e 6 GB com um limite de 24 GB

• Latência de decodificação, mesmas execuções — 8,62 ms por token com concorrência 1 fixada, contra 9,16 / 9,20 / 9,12 ms nas três execuções de arquivo limitadas

• Simultaneidade 16 — 16,54 ms com afinidade fixa versus 17,62 / 17,85 / 17,37 ms com limite, o que representa de 893 tokens por segundo para 827–840

• Vazão de prefill — 620 tokens por segundo a 8k fixado versus 624 / 630 / 631 limitado; a 32k, 1.347 versus 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB fixados versus 24 GB com o backend de arquivo num limite de 32 GB, a 8,87 ms versus 9,18 ms

• NVFP4 em GPU única — 69 GB fixados versus 51 GB com limite de 64 GB, a 6,44 ms versus 6,73 ms

• A alternativa que ele supera — ler o mesmo arquivo por meio do gerenciamento de memória do host nessa GPU resultou em 10,8 ms com concorrência 1 e 46,5 ms com concorrência 16, o que o PR descreve como 2,8× a latência com memória fixada (pinned) nessa concorrência

O lado da acurácia é relatado como limpo. A saída greedy determinística em oito prompts de 256 tokens foi idêntica token a token entre os caminhos pinned e file em FP8 TP4, e o GSM8K ficou em 97,6% no pinned contra 98,0% no file no limite de 64 GB — uma diferença de seis questões que o autor atribui à variação entre execuções, e não ao caminho de offload. Todos esses números são do próprio autor do pull request, medidos uma vez, em uma única máquina, e ninguém os reproduziu.

Os custos que a PR admite

Uma leitura justa deste pull request inclui o que ele se recusa a fazer. Vários modos de execução são rejeitados no momento da construção em vez de serem silenciosamente degradados, e cada rejeição indica o backend fixado como fallback: grafos CUDA de prefill, atenção data-parallel, o caminho de multiplexação prefill-decode, sobreposição de dois lotes, os grafos de decodificação DLLM e grafos compactos de verificação ragged estão todos fora. Igualmente importante, ele não adiciona nenhuma nova flag nem nenhum novo switch voltado ao usuário — o caminho de staging é o que o backend de arquivo faz em hardware que antes não conseguia usá-lo de forma alguma. E a execução de acurácia traz uma ressalva que o autor oferece voluntariamente: as execuções com teto nunca continham a tabela inteira, porque a tabela tem 47,7 GiB e os tetos chegam a apenas 24 GB, de modo que uma carga de trabalho com um padrão de acesso genuinamente plano e imprevisível sobre toda a tabela não é o que foi medido.

Por que isso importa especificamente para o Qwen 4

Deixe de lado os detalhes do motor e o padrão fica legível. A Alibaba lançou uma prévia da arquitetura em 26 de agosto com instruções para a comunidade de código aberto preparar runtimes, quantização e motores de inferência antes da família completa. O SGLang fez isso e depois passou três semanas abrindo pull requests sobre o único componente que torna a arquitetura difícil de implantar. Lido como uma previsão, isso é uma afirmação sobre o que o Qwen 4 vai exigir do seu hardware, não sobre o que ele consegue fazer em um benchmark.

Isso também aguça a questão do cronograma. O Qwen 4 ainda não foi lançado, e a especulação de setembro em torno dele aponta para a Apsara Conference da Alibaba, de 22 a 24 de setembro, em Hangzhou — o local onde as gerações anteriores do Qwen foram anunciadas. Nada disso está confirmado, e o padrão do último ciclo de prévia é que uma prévia da arquitetura precede a família completa em meses, não em semanas. Um pull request aberto três dias antes dessa conferência é sugestivo, e nada mais.

O resumo honesto de onde isso deixa o leitor: o Qwen 4 não existe, o Qwen3.8-Flash-Next existe, e o segundo informa quanto custará executar o primeiro. Se a tabela de 47,7 GiB continuar encolhendo em pegada efetiva — e três semanas de pull requests dizem que se está trabalhando duro nisso —, então o limite de implantação para a família Qwen 4 é mais baixo do que a semana de lançamento da prévia sugeria.

O que você pode realmente fazer com isso hoje

Nada neste pull request está disponível na main, e o modelo que ele tem como alvo não é algo que você possa chamar por uma API. O checkpoint de pesos abertos Qwen3.8-Flash-Next é uma história de auto-hospedagem: você baixa os pesos, você mesmo os serve, e o caminho PLE baseado em arquivos é o que você está lendo. Ele não é roteado aqui. O que é roteado é a variante de produção — Qwen3.8-Flash, acessível como qwen/qwen3.8-flash a US$ 0,15 por milhão de tokens de entrada e US$ 0,47 por milhão de saída, com contexto de 1M de tokens e entrada de texto, imagem e vídeo — e o maior Qwen3.8-Max a US$ 2,00 e US$ 6,00.

Essa distinção é a mais útil para um leitor que está decidindo o que fazer nesta semana. A prévia é uma pesquisa que você mesmo conduz; a variante servida é o caminho de produção dessa mesma arquitetura, e está a apenas um endpoint de distância. O OrcaRouter repassa o preço de lista do provedor com 0% de margem, então uma mudança de preço do fornecedor nesse endpoint aparece no mesmo dia, em vez de no próximo ciclo de faturamento, e todos os modelos da chave ficam acessíveis por uma única URL base compatível com OpenAI, em vez de um contrato, SDK e credencial separados por fornecedor. Para uma arquitetura tão jovem — em que o trabalho no motor ainda chega semanalmente e o roteiro não foi publicado — o failover automático entre provedores é a forma prática de depender da variante servida sem apostar um caminho de produção na disponibilidade de um único provedor. Tudo isso diz respeito aos modelos que você pode chamar hoje. Não diz nada sobre o Qwen 4, que não é um deles.

O que ainda não sabemos

Se o Qwen 4 vai entregar a mesma tabela no mesmo tamanho. Se o pull request chega a ser mesclado — ele tem três execuções de CI com falha e ainda nenhuma revisão. Se a penalidade de 0,5 a 1 milissegundo por passo se sustenta fora das configurações de baixa concorrência do autor. E se a Alibaba dirá alguma coisa na Apsara em 22 de setembro. Com as evidências atuais, a conclusão mais segura sobre o Qwen 4 não é a pontuação que ele alcança, mas quanta maquinaria a indústria está construindo só para fazê-lo caber — o que, por si só, é algo útil de se saber antes que o modelo tenha um nome em qualquer catálogo.