Vazamento do Qwen 4: SGLang fragmenta o prefill do Qwen4Exp para um TTFT 18% mais rápido e devolve um GiB por GPU

Um pull request aberto no repositório SGLang às 03:47 UTC desta manhã, 2026-10-08, promete algo que nenhum anúncio do Qwen 4 produziu até agora: um número. Seu título é feat(qwen4-exp): habilitar paralelismo de sequência LayerNorm para GR e PLE, e em quatro GPUs H20 executando o checkpoint de pesos abertos Qwen3.8-Flash-Next em FP8, seu autor relata ganhos de tempo até o primeiro token de 17,7–18,4% com entrada de 32K e 14,6–14,7% com entrada de 235K, cerca de um gigabyte de memória de pico devolvido por GPU, e até 22% mais throughput de entrada. Qwen 4 em si — a família que o fornecedor nomeou mas não lançou na conferência Apsara em Hangzhou em 2026-09-22 — ainda não foi lançada, sem pesos, sem identificador e sem preço. O único modelo que instancia a arquitetura Qwen4Exp hoje é o Qwen3.8-Flash-Next, publicado em 2026-08-26, e seu modelo irmão gerenciado Qwen3.8-Flash é a versão que um chamador de API consegue de fato acessar. Portanto, leia o que segue exatamente como é: medições pareadas de um engenheiro, anexadas a um pull request aberto, em rascunho e não mesclado, sobre o envelope de serving de uma família de modelos que ainda não existe.

Primeiro, a apuração de fontes, porque este é um texto sobre vazamento e a distinção faz diferença real. O sinal é sgl-project/sglang#43048, aberto em 2026-10-08 às 03:47 UTC pela conta do GitHub shiyang814-cpu, com última modificação em 03:55 UTC, e ainda marcado como rascunho, sem nenhuma revisão de aprovação registrada e sem merge. Ele altera seis arquivos — dois arquivos de teste, o arquivo de modelo Qwen4Exp, o módulo LayerNorm-SP, uma fábrica de limite de camada e um hook de grupo de argumentos — em +345 e −50 linhas. Todos os números de desempenho abaixo vêm da descrição do PR, são a própria medição pareada OFF/ON do autor e não foram reproduzidos por ninguém. Três execuções de CI na revisão na ponta do branch estão marcadas como falhas. Nada aqui é uma funcionalidade lançada.

O que o pull request realmente altera

O paralelismo de sequência não é uma mudança de modelo e não é uma nova capacidade. É uma reorganização de onde algumas camadas fazem sua aritmética. Sua linhagem remonta ao paralelismo de sequência no estilo Megatron — o truque do arXiv:2205.05198 — e o SGLang já o oferece: a própria docstring do módulo explica o mecanismo que ele reutiliza, que sob paralelismo puro de tensor um all_reduce paralelo por linhas é algebricamente um reduce_scatter seguido por um all_gather. Como esses dois coletivos movem exatamente os mesmos bytes que o único all_reduce que eles substituem, dividir a operação dessa forma não custa nenhum volume extra de comunicação. O que isso proporciona é a liberdade de deixar as regiões de normalização e residual rodarem em ativações sequence-sharded — cada rank de paralelismo de tensor mantendo um-1/tpésimo das linhas de tokens — o que reduz a memória de ativação transitória que o prefill de contexto longo precisa manter viva.

O que este pull request específico faz é estender esse caminho existente da arquitetura na qual ele foi validado para a arquitetura Qwen4Exp. Durante o prefill, as ativações Gated Residual e Per-Layer Embedding permanecem sharded ao longo da dimensão de tokens em todo o grupo TP. Antes da atenção, antes do GDN, antes do QSA e antes de o bloco Mixture-of-Experts ser executado, as linhas completas de tokens são all-gathered de volta, a computação tensor-parallel de linha completa existente é executada sem alterações por trás de um fallback compartilhado, e um reduce-scatter então soma as contribuições parciais e restaura o shard de cada rank. O decode nunca toca o novo caminho de forma alguma. O recurso é acessado por meio da opção que já existe — --enable-layernorm-sp — sem nenhuma flag específica do Qwen4Exp, e, com a flag ausente, o código se comporta exatamente como antes.

Por que o Qwen4Exp é a arquitetura que precisa disso

O motivo pelo qual isso importa especificamente para o Qwen4Exp, e não igualmente para todos os modelos, está no próprio design da arquitetura. O Qwen3.8-Flash-Next aplica projeções Gated Residual a todas as linhas de token em cada camada do decoder — a configuração declara quatro fluxos residuais e um posto de gargalo de 320 ao longo de 48 camadas — e o Per-Layer Embedding adiciona uma segunda projeção replicada, linha de token por linha de token, sobre isso. Sob paralelismo de tensores, ambas as operações são duplicadas de forma idêntica em cada rank, porque não carregam nenhuma matriz de pesos fragmentada por TP própria que force uma divisão. O sharding da dimensão de tokens delas remove diretamente o trabalho replicado e, como diz a seção de motivação do PR, isso acontece preservando o layout de paralelismo de tensores existente e a semântica de redução de atenção, GDN/QSA e MoE — que é a parte que torna a mudança segura em vez de engenhosa.

Vale a pena dizer com clareza o que isso significa para o leitor. O interessante neste PR não é que o SGLang esteja ficando mais rápido. É que a arquitetura Qwen4 carrega custos por camada que escalam com a contagem de tokens em vez da contagem de parâmetros, e são esses custos que pesam em prefills longos. Isso é uma impressão digital de design, e é o tipo de coisa que uma ficha técnica nunca menciona.

Os deltas medidos

O benchmark do autor fixa uma configuração e alterna a flag: quatro GPUs NVIDIA H20, Qwen3.8-Flash-Next-FP8, paralelismo tensorial 4 e paralelismo de especialistas 4, tamanho de prefill em chunks 8192, backends de prefill e decode de atenção linear do FlashInfer, a mesma configuração de servidor para OFF e ON, reinicializações do serviço alternando OFF → ON → OFF → ON, e entradas de token fixas com requisições de warmup. Todas as figuras abaixo são dessa configuração e não foram auditadas:

• 32K de entrada, tamanho do lote 1 — TTFT melhorou 17,72–18,36%, latência ponta a ponta cerca de 16%, taxa de transferência de entrada cerca de 20%

• 235K de entrada, tamanho do lote 1 — TTFT melhorou 14,63–14,71%, latência ponta a ponta cerca de 14%, throughput de entrada cerca de 17%

• Entrada de 32K, tamanho do lote 4 — TTFT melhorou 18,74%, latência ponta a ponta 18,14%, vazão de entrada 22,14%

• Pico de memória — reduzido em aproximadamente 1,0 GiB por GPU

• Decodificação, tamanho de lote 1 — tempo por token de saída efetivamente inalterado

A última linha é a que deve ser lida duas vezes, e o autor é sincero sobre o porquê: essa otimização é habilitada apenas para prefill, então a decodificação de fluxo único não ganha nada com isso. A melhoria de tempo por token com lote de 4, onde ela aparece, reflete atrasos de agendamento reduzidos de prefills longos concorrentes, em vez de qualquer kernel de decodificação mais rápido. Se você esperava que esta fosse uma história de throughput, não é — é uma história de latência até o primeiro token e de memória, e essas são as duas restrições que decidem se uma requisição de 235K tokens é sequer atendível.

O bug de layout que eles tiveram que corrigir primeiro

A parte mais informativa do pull request não é a tabela de speedup. É a seção sobre a disposição física das linhas do PLE, porque ela mostra o que a stack de serving do Qwen4Exp ainda faz de errado.

O Per-Layer Embedding opera em um bucket físico fixo de grafo CUDA, enquanto apenas um prefixo das linhas nesse bucket pode conter tokens reais. O padding, portanto, tem de ser aplicado antes de a sequência sofrer sharding, e não depois. No bloco final de uma requisição de 235K tokens, os números do autor são 5.624 tokens processados dentro de um bucket físico de 8.192 linhas em TP 4, e o único layout correto é: rank 0 com 2.048 linhas válidas, rank 1 com 2.048 linhas válidas, rank 2 com 1.528 linhas válidas mais 520 linhas de padding, e rank 3 com 2.048 linhas de padding. Fazer o sharding das 5.624 linhas processadas primeiro — a implementação óbvia — insere padding entre intervalos válidos globalmente contíguos e corrompe o resultado. O autor registra que um teste real OFF/ON de 235K só produziu uma saída greedy idêntica de 16 tokens depois que esse layout foi corrigido.

Esse é um pequeno detalhe com uma grande implicação. O caminho PLE no SGLang foi adicionado recentemente o bastante para que um bug de ordenação de tokens desse tipo ainda fosse possível, e a pessoa que o encontrou estava escrevendo a extensão de paralelismo de sequência. O suporte de serving desde o primeiro dia para esta arquitetura não está pronto; ele está sendo ativamente construído, em público, por contribuidores, um layout de cada vez.

O que isso te custa: as restrições

Uma flag que ajuda apenas algumas implantações só é útil se você souber quais. O PR declara seus requisitos explicitamente, e configurações fora deles falham durante a validação de argumentos em vez de degradar silenciosamente:

• O tamanho do paralelismo de tensores deve ser maior que 1 — uma implantação com uma única GPU não ganha nada, porque não há rank para distribuir os fragmentos

• O tamanho do paralelismo de experts deve ser igual ao tamanho do paralelismo de tensores

• O tamanho do pipeline paralelo deve ser igual a 1

• A atenção com paralelismo de dados deve ser desativada

• A decodificação especulativa deve ser desativada

A última restrição é aquela com uma decisão real por trás. Para um modelo esparso que ativa cerca de 6 bilhões de parâmetros por token, a decodificação especulativa é uma das poucas alavancas que aceleram a decodificação, e este recurso desativa explicitamente essa alavanca em troca de um ganho no prefill. Se sua carga de trabalho é de prompt longo e saída curta — análise de documentos e bases de código, sumarização de vídeo, um contexto grande lido uma vez —, a troca é claramente boa. Se sua carga de trabalho é um prompt curto e uma geração longa, você está abrindo mão daquilo que estava ajudando você e comprando um número que não se aplica a você. O requisito de que expert-parallel seja igual a tensor-parallel é o outro a observar: isso significa que a geometria de sharding do MoE tem de se alinhar exatamente com a geometria de TP, o que inviabiliza vários layouts de múltiplos nós que seriam razoáveis de outra forma.

O que isso diz sobre o cronograma do Qwen 4

Leia o diff de outra forma e você obtém um calendário. O módulo LayerNorm-SP do SGLang no branch main hoje carrega uma lista de permissões explícita de arquiteturas para as quais o recurso foi validado e, até o momento desta escrita, essa lista de permissões contém exatamente uma entrada, Qwen3ForCausalLM — todas as outras arquiteturas são rejeitadas na construção se você passar a flag. Adicionar Qwen4Exp a esse caminho, portanto, não é um ajuste a uma abstração madura; é a primeira vez que a arquitetura Qwen4 é trazida para uma otimização que a antecede em gerações.

Compare isso com o registro público e o quadro é coerente. O fornecedor anunciou em 2026-09-22 que o Qwen 4 está em treinamento e deu uma prévia de quatro nomes de níveis — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus e Qwen 4 27B — sem nenhuma especificação associada a qualquer um deles. A prévia de pesos abertos que compartilha a arquitetura, Qwen3.8-Flash-Next, está disponível para download desde 2026-08-26. O que vem acontecendo nas três semanas desde então é exatamente o que se esperaria entre "em treinamento" e "lançamento": autores de engines ajustando o runtime para que o suporte no dia zero seja real, e não nominal. Um pull request que faz uma otimização de serving funcionar na arquitetura, aberto na manhã de 2026-10-08 e ainda em rascunho, é um sinal melhor de quão perto o Qwen 4 está de poder ser servido do que qualquer data que alguém tenha aventado. Também não é, enfaticamente, uma data de lançamento — a flag está desativada por padrão, a alteração não foi mesclada, e o modelo que ele usa como benchmark é a prévia, não o Qwen 4.

O que você pode chamar hoje

Nada disso muda o que está, de facto, disponível esta tarde. O Qwen3.8-Flash-Next é real, os seus pesos estão no Hugging Face e podes alojá-lo tu mesmo — mas não está no nosso catálogo, e não vamos fingir o contrário. O nível que servimos é qwen/qwen3.8-flash, o irmão gerido que corre a mesma arquitetura Qwen4-preview com uma janela de contexto de 1M de tokens e entrada de texto, imagem e vídeo, com um preço de $0,15 por milhão de tokens de entrada, $0,47 por milhão de saída e $0,0184 por milhão de leituras de cache. Esse é um preço de tabela repassado com 0% de margem, por isso, quando o fornecedor o altera, o número na tua fatura muda no mesmo dia, em vez de esperar que um intermediário volte a publicar uma tabela.

Há uma segunda razão, menos óbvia, para se importar com uma camada de roteamento aqui. Tudo neste artigo gira em torno de uma prévia não comprovada mais um patch em rascunho — o tipo de coisa que você quer testar sem apostar um caminho de produção nela. É para isso que serve o failover: coloque a prévia atrás da mesma chave do modelo em que você já confia, observe como ela se comporta no seu tráfego e deixe a requisição recair para a rota conhecida como boa quando um provedor oscilar ou o endpoint não estiver lá.Uma API para mais de 200 modelos, um único conjunto de credenciais, nenhum segundo contrato assinado para descobrir se uma nova arquitetura vale a sua atenção.

Duas coisas a observar daqui em diante, nenhuma das quais podemos prever. A primeira é se este patch será mesclado: é um rascunho com três execuções de CI falhando em uma alteração de seis arquivos de uma conta de colaborador sem histórico anterior no repositório, e a fluidez do trabalho de layout de linhas do PLE sugere que o autor ainda está iterando. A segunda é se a lista de permissões cresce — se o Qwen4Exp se juntar ao Qwen3ForCausalLM como uma arquitetura validada, então isso deixa de ser um vazamento e se torna a maneira padrão como um modelo da família Qwen4 é servido em contexto longo. Até que uma dessas coisas aconteça, trate os 18% como uma promessa sobre para onde o runtime está indo, não como um número que você pode alugar.