Qwen 4 QSA ganha paralelismo de contexto de decodificação: dentro do PR em rascunho do vLLM para o Qwen3.8-Flash-Next

Em 2026-09-29, surgiu um pull request em rascunho no repositório do vLLM intitulado “[Model][DCP] Support Qwen4Exp QSA”, e, para o modelo que descreve, ele traz os números de serving mais concretos que alguém publicou durante todo o mês: execuções emparelhadas do Qwen3.8-Flash-Next em quatro GPUs mostrando a capacidade de tokens KV passando de 9,759,529 para 17,603,636, a concorrência máxima de 37.23× para 67.15×, e o tempo até o primeiro token caindo de 1,869 ms para 767 ms. O Qwen3.8-Flash-Next é a prévia de mistura de especialistas, com pesos abertos e 125 bilhões de parâmetros, cujo card no Hugging Face o descreve como “Uma Prévia da Arquitetura Qwen4”; o pull request adiciona paralelismo de contexto de decodificação ao caminho de atenção esparsa em torno do qual essa arquitetura é construída. O próprio Qwen4 — os níveis Qwen4 Max, Flash, Plus e 27B que o fornecedor nomeou em sua conferência Apsara em 2026-09-22 — ainda não foi lançado, sem pesos, sem identificador, sem preço e sem data. Portanto, leia isto pelo que é: não um lançamento, não um benchmark, mas um artefato de engenharia que mostra como o envelope de serving do Qwen4 está sendo ampliado antes de a família existir.

Este é um texto do tipo o-que-sabemos-até-agora, e a fundamentação das fontes importa mais do que o habitual. O pull request é um rascunho, aberto e não mesclado — vllm-project/vllm#59279, aberto em 2026-09-29 por Sungsoo Ha, um engenheiro de software da NVIDIA, e ainda permanece como rascunho. Todos os números abaixo são medições pareadas do próprio autor, relatadas no corpo do PR, obtidas em uma revisão anterior do mesmo trabalho. Nada aqui foi auditado de forma independente, nada aqui chegou a uma versão lançada, e a ressalva que o autor anexa é relevante o suficiente para ganhar sua própria seção abaixo.

O que o pull request realmente altera

O paralelismo de contexto de decodificação — DCP — é uma técnica de serving, não uma alteração do modelo. Em vez de um grupo de GPUs manter um KV cache inteiro, o DCP divide esse cache entre os ranks, de modo que cada rank lê apenas a sua fatia do contexto, enquanto os resultados de atenção são combinados entre os ranks no final. O ponto é a capacidade: com o cache particionado, uma implantação pode manter muito mais tráfego concorrente de contexto longo no mesmo hardware, que é exatamente a restrição que pesa quando cada requisição carrega um quarto de milhão de tokens.

A complicação é que o Qwen Sparse Attention — QSA — não é uma camada de atenção comum. Como especifica o model card do Qwen3.8-Flash-Next, um indexador leve comprime as chaves em micro-blocos a uma taxa de compressão de 4, atribui-lhes pontuações e mantém os 512 melhores blocos, aproximadamente 2.048 posições de token, enquanto o softmax final e a agregação de valores ainda são executados sobre os K e V não comprimidos. Isso significa que o QSA carrega mais estado do que um cache KV: há o cache principal, e há os caches seletor e lateral que o indexador mantém. A implementação genérica de DCP no vLLM não sabe nada disso.

O que o #59279 faz, de acordo com sua descrição, é ensinar ao DCP sobre as partes específicas do QSA:

• Cada rank lê sua própria parte do principal cache KV, enquanto o seletor e os caches laterais do QSA permanecem replicados entre os ranks em vez de fragmentados.

• Os resultados de atenção são combinados entre ranks após a leitura dividida

• O seletor e o cache KV principal são mantidos em um mesmo grupo de cache, de modo que não podem se distanciar.

• Lotes Synthetic V2 são impedidos de gravar caches laterais do QSA.

Esse último par de detalhes é a parte interessante se você se importa com correção em vez de vazão. Um cache de atenção fragmentado que silenciosamente discorda de um seletor replicado é o tipo de bug que se manifesta como um declínio lento da precisão em contexto longo, em vez de um crash, e a mudança é explícita quanto a manter os dois em sincronia. O autor também afirma que assistência de IA foi usada e Codex é creditado como coautor — vale dizer isso claramente, porque em um PR em rascunho desse formato é justo perguntar quem escreveu o quê.

Os números emparelhados, e como foram obtidos

O plano de teste é específico o suficiente para ser verificável, e é por isso que os resultados merecem ser citados. Ambos os braços executam o Qwen/Qwen3.8-Flash-Next-FP8 em quatro GPUs com tensor parallelism 4 e expert parallelism habilitados, com --gpu-memory-utilization 0.90 com prefix caching ativado. A única diferença entre os dois braços é --decode-context-parallel-size: omitido para DCP=1, definido como 2 para DCP=2, com uma reinicialização entre os braços para que o benchmark comece a partir de um cache frio. A carga é um trace AgentX 256k com 128 usuários durante 900 segundos; a acurácia é o EvalScope para GSM8K mais o avaliador MRCR versionado no repositório, executado seis vezes por braço, descartando a primeira execução após a reinicialização.

Os deltas de taxa de transferência reportados, DCP=2 em comparação com DCP=1:

• KV tokens — 9.759.529 vs 17.603.636, um aumento de 1,80× na capacidade de cache.

• Concorrência máxima — 37,23× vs 67,15×, também 1,80×.

• Requisições por segundo — 1,69 vs 2,30, 1,36×.

• Tokens de entrada por segundo — 128.730 vs 179.702, 1,40×

• Tempo até o primeiro token — 1.869 ms vs 767 ms, 2,44× menor.

• Latência entre tokens — 43,48 ms vs 26,27 ms, 1,66× menor.

• Taxa de acertos do cache de prefixo em regime estacionário — 67,85% vs 88,98%, um ganho de 21,1 pontos percentuais.

A acurácia, relatada como média ± desvio padrão amostral entre execuções pós-aquecimento, ficou essencialmente estável: agregado MRCR 0,8630 ± 0,0005 com DCP=1 contra 0,8697 ± 0,0153 com DCP=2, e GSM8K 0,9788 ± 0,0020 contra 0,9790 ± 0,0016. As amostras MRCR de 2 agulhas e 4 agulhas ficaram fixas em 0,9960 e 0,9906 em ambos os braços, então toda a variação entre execuções veio das amostras de 8 agulhas — e uma execução agregada com DCP=2 marcou 0,8970, enquanto as outras quatro ficaram entre 0,8620 e 0,8632. Isso é uma dispersão real, não ruído que se possa simplesmente ignorar, e está declarado no PR em vez de ser suavizado.

O que estes números não estabelecem

A ressalva está no texto do PR e não é pequena. Os resultados emparelhados do AgentX e de acurácia foram medidos em uma anterior revisão do QSA DCP, usando um vLLM nightly baseado no commit 3df4ae153eb. O commit limpo final no pull request inclui uma correção subsequente do kernel de localização do QSA e passou por validação focada no B200 — mas as avaliações completas do AgentX e de acurácia não foram repetidas nesse código-fonte exato. Em outras palavras: a história da vazão e o diff entregue não são o mesmo artefato, e o autor diz isso.

Além disso, aplica-se a disciplina de sempre, e aqui ela se aplica com força. Estes são números de uma única configuração, de um único colaborador, em uma única montagem de quatro GPUs. Eles são adjacentes ao fornecedor, e não neutros: um colaborador de um framework medir uma mudança no framework é algo normal e útil, mas não é uma auditoria independente, e nenhum terceiro reproduziu a execução. Não há nenhuma versão lançada do vLLM que você possa instalar hoje que contenha essa mudança, porque a mudança ainda não foi mesclada. E DCP=2 é uma divisão em duas vias de um formato específico — os deltas não são uma promessa sobre o que DCP=4 ou DCP=8 fariam, e nada no PR afirma que sejam.

Por que um PR de serving sobre uma arquitetura não lançada ainda vale o seu tempo

A objeção óbvia: o modelo no título não existe, então por que se importar? Porque o que está sendo ajustado não é o Qwen 4. É o Qwen3.8-Flash-Next, e esse modelo existe — a Alibaba o publicou em 24/08/2026 como um MoE de 125B parâmetros com 6B ativados, uma tabela de embeddings n-gram de 51 bilhões de parâmetros, um cabeçote MTP de 4B para decodificação especulativa, 48 camadas organizadas como doze repetições de três blocos Gated DeltaNet seguidas por um bloco QSA, 512 especialistas com 10 roteados e 1 compartilhado ativo, e um contexto nativo de 262.144 tokens que o card diz ser extensível a 1.000.000. É a implementação de referência da arquitetura Qwen4 em pesos abertos, e o QSA — a atenção esparsa de microbloco que este pull request está ensinando o DCP a fragmentar — é a parte mais distintiva dele.

O que os números descrevem é o que acontece quando você deixa de tratar aquele contexto de 262K como algo que um único grupo de GPUs precisa manter por inteiro. O salto de 1,80× na capacidade de tokens de KV e na concorrência é a aritmética de dividir um cache em dois, que é o resultado menos surpreendente da lista. Os números mais interessantes são os de latência: tempo até o primeiro token 2,44× menor e latência entre tokens 1,66× menor sob a mesma carga oferecida, além de uma melhoria de 21 pontos na taxa de acerto do prefix cache em estado estacionário. Isso indica que o caminho DCP não está apenas comprando capacidade ao custo de latência — nesta execução emparelhada, ele comprou as duas coisas. Esse é o tipo de mudança que importa para quem atende tráfego de agentes com system prompts muito longos, porque o comportamento do prefix cache em contexto longo costuma ser justamente onde a vazão de contexto longo morre silenciosamente.

E este não é um patch isolado. A mesma semana produziu um conjunto de trabalhos do engine Qwen4Exp: #59214 adiciona planos GEMM para decodificação de baixa latência em SM100 para formatos B200, #59010 adiciona um kernel de prefill esparso nativo para SM90 para o caminho QSA no Hopper, #58977 cobre embeddings BF16 INC PLE, e #58961 — aquele que de fato foi mesclado, em 2026-09-28 — corrigiu um cache KV de profiling que as views de chave do QSA mantinham vivo. Lidos em conjunto, eles são o envelope de serving da arquitetura Qwen4 sendo construída em público, nos runtimes, meses antes de a família ser lançada. Se você está planejando para o Qwen 4, o sinal útil não é uma data de lançamento — não existe uma — é o que os kernels e os layouts de cache já pressupõem sobre como você terá de servi-lo.

O que você pode chamar hoje

Se você quiser testar o comportamento de contexto longo na arquitetura de que este PR trata, o modelo a procurar é o tier Flash que a Alibaba realmente serve. O Qwen3.8-Flash — a implantação de produção construída sobre o Qwen3.8-Flash-Next, com contexto de 1.000.000 de tokens e saída máxima de 131.072 tokens, aceitando entrada de texto, imagem e vídeo — está no ar, e é um endpoint para o modelo que de fato executa a arquitetura Qwen4Exp hoje, listado como qwen/qwen3.8-flash a $0.15 por milhão de tokens de entrada e $0.47 por milhão de tokens de saída, com leituras de cache a $0.0184. Como esses são preços de tabela do provedor repassados sem nenhum markup da nossa parte, uma mudança de preço ou de limite do fornecedor chega até você no mesmo dia em que for anunciada.

Duas ressalvas honestas. Primeiro, o próprio Qwen3.8-Flash-N — os pesos FP8 no plano de testes do pull request, aqueles que você precisaria para reproduzir qualquer uma dessas medições localmente — não está no nosso catálogo; a camada Flash servida é a linha de produção da QwenCloud, não o checkpoint de pré-visualização bruto. Se você quiser executar a configuração exata do PR, você está fazendo auto-hospedagem em quatro GPUs. Segundo, a mudança do DCP não foi mesclada, então nada que você possa chamar em qualquer lugar hoje está executando-a. O que a camada servida lhe oferece é uma forma de descobrir se sua carga de trabalho é sequer adequada ao problema que o DCP resolve: se seus prompts são longos, agênticos e com muitos prefixos, então a capacidade de 1.80× e o delta do cache de prefixo são os números a observar nos seus próprios traces.

E se a parte interessante para você não for um único modelo, mas a questão da troca — em qual camada construir enquanto a linha Qwen 4 ainda não tem nome —, isso é um problema de roteamento e não de serving, e uma API para mais de 200 modelos é como você mantém a opção em aberto sem um segundo contrato nem alteração de código quando a família finalmente chegar.

Perguntas que vale a pena responder diretamente

O #59279 significa que o Qwen 4 já saiu, ou está prestes a sair?

Não. O pull request é sobre a arquitetura Qwen4Exp conforme implementada no Qwen3.8-Flash-Next, que a Alibaba lançou em 24 de agosto de 2026. A família Qwen 4 — Max, Flash, Plus e 27B — foi nomeada em um palco na Apsara em 22 de setembro de 2026 e colocada em um roteiro da empresa com uma linha sucessora projetada em 5 a 10 trilhões de parâmetros, e ainda não tem model card, nem pesos, nem identificador de API, nem janela de contexto, nem preço e nem data. Um PR de framework que adiciona um modo de paralelismo à arquitetura de pré-visualização é um passo para servir bem o Qwen 4. Não é um passo para o Qwen 4 existir.

Como o paralelismo de contexto de decodificação é diferente do paralelismo de tensores?

Eles dividem coisas diferentes e falham de maneiras diferentes. O paralelismo de tensor particiona os pesos e a computação de cada camada entre GPUs, então cada rank participa de cada token, mas vê a sequência inteira. O paralelismo de contexto de decodificação particiona o cache KV em si, então cada rank mantém e lê apenas uma fatia do contexto, e os resultados parciais de atenção são mesclados depois. TP é sobre caber o modelo; DCP é sobre caber o contexto e o tráfego concorrente que trafega sobre ele. Essa distinção é exatamente o motivo pelo qual este PR não é trivial: o seletor e os caches laterais do QSA não podem simplesmente ser fragmentados como o cache KV principal pode, então a mudança tem que fragmentar um e replicar os outros, e então provar que os dois permanecem consistentes.

Se eu chamar o Qwen3.8-Flash-Next hoje por meio de uma API hospedada, já obtenho esses números?

Não, e a lacuna tem três partes. A mudança não foi mesclada, então nenhuma versão lançada do vLLM a contém. Mesmo depois de mesclada, o provedor precisa adotar esse build e optar por executá-lo com um tamanho de DCP maior que um — é uma configuração de serving, não um padrão. E os deltas medidos são de uma revisão anterior do patch, e não do commit final, que, segundo o autor, até agora só teve validação focada no B200. Trate os deltas relatados como um limite superior bem documentado do que a abordagem oferece em uma configuração, e não como uma especificação de qualquer endpoint que você possa alugar nesta semana.

A questão em aberto

O ponto a observar não é se este rascunho específico será mesclado — provavelmente será, de alguma forma, já que o tratamento de cache específico do QSA que ele adiciona é uma lacuna genuína, e não uma preferência. O ponto a observar é se o commit final receberá a mesma avaliação emparelhada que a revisão intermediária recebeu. Uma mudança no serving cujas alegações de throughput vêm de uma build e cujas alegações de correção vêm de outra é, por ora, uma proposta bem argumentada, e não um resultado medido, e a dispersão de acurácia nas amostras MRCR com 8 agulhas é ampla o suficiente para que repetir a execução no código-fonte enviado seria a coisa mais útil que alguém poderia publicar sobre isso. Até lá: a direção é legível, o balanço não está fechado, e o único modelo de arquitetura Qwen4 em pesos abertos continua sendo o de agosto.