Qwen4-Exp QSA chega ao Ascend da Huawei: dentro do PR de prefill CANN opt-in do SGLang

Em 30 de setembro de 2026, um contribuidor abriu o pull request #41855 do SGLang, intitulado "[NPU] Adicionar atenção esparsa CANN opt-in para o prefill QSA do Qwen4-Exp", e a parte interessante não é a aritmética. É o hardware. A arquitetura Qwen4Exp agora tem um caminho de atenção esparsa escrito à mão para o acelerador Ascend 910C da Huawei, por trás de uma flag que vem desativada por padrão, em um pull request em rascunho que ainda não foi mesclado — enquanto o modelo ao qual esse nome de arquitetura pertence, o Qwen4-Exp, nunca foi publicado em nenhuma forma. O único checkpoint que carrega essa arquitetura em pesos abertos ainda é o Qwen3.8-Flash-Next, a prévia de mistura de especialistas com 125 bilhões de parâmetros que o fornecedor lançou no Hugging Face em 24 de agosto de 2026, e cujo cartão na verdade declara sua arquitetura como qwen4_exp. O próprio Qwen 4 — os níveis Max, Flash, Plus e 27B que o fornecedor nomeou em sua conferência Apsara em 22 de setembro de 2026 — ainda não tem pesos, nem identificador, nem preço e nem data. Portanto, este é um texto do tipo "o que sabemos até agora" sobre um artefato de engenharia, não sobre um lançamento: mais uma stack de serving de fornecedor decidindo discretamente que vale a pena dar suporte antecipado a uma arquitetura não lançada.

O que o pull request realmente adiciona

A alteração é deliberadamente pequena e deliberadamente restrita. Cinco arquivos, um commit, +355 linhas em relação a um branch principal no commit b87a, com o SGLang npu como rótulo. O autor, w1ida, declara desde o início a intenção: um caminho de atenção principal CANN opcional para o pré-preenchimento eager do Qwen4-Exp QSA, construído sobre torch_npu.npu_sparse_flash_attention, com o indexador, a seleção Top-K, o orçamento de tokens e o conteúdo da cache KV todos deixados exatamente como estavam.

O truque que ele usa para chegar lá merece um parágrafo, porque explica por que isto é um adaptador de layout e não um novo kernel de atenção. Para Q e K já rotacionados, o caminho empacota o cache como C = [K, V] e a consulta como Q' = [Q, 0]. O produto Q' @ C.T então é igual a Q @ K.T, e como a consulta preenchida não contribui em nada, softmax(scale * Q' @ C.T) @ C retorna [P @ K, P @ V] empilhados — então a metade V pode ser recortada. Nas próprias palavras do autor, isto é “um embedding de layout de atenção, não uma mudança na atenção do modelo nem uma compressão KV de baixo posto.” Cada cabeça KV se torna um lote independente no layout nativo do MLA, a escala D256 original é preservada, e o RoPE auxiliar é zerado.

Os detalhes operacionais importam tanto quanto a matemática:

• Habilitação — SGLANG_NPU_QSA_NATIVE_PREFILL=1, padrão desativado. Somente o ForwardMode.EXTEND comum adere; decode, modos especulativos, forward misto e captura de grafo permanecem todos nos caminhos existentes, e a captura de grafo contorna totalmente o adaptador.

• Hardware e dtype — BF16 com dimensão de cabeça 256, Ascend 910C (Ascend910_93*), testado em CANN 9.0 e torch-npu 2.10. Qualquer dtype ou shape não suportado recorre silenciosamente ao caminho de referência.

• Formatos de cabeça — pares locais suportados (cabeças Q, cabeças KV) são (16,2), (24,2), (12,1), (6,1) e (3,1). O CANN rejeita categoricamente uma proporção query/KV de 12 — seu tiler só aceita potências de dois — então as cabeças são preenchidas de 12→16, 6→8 ou 3→4 e as saídas adicionais são descartadas. Este é o sinal mais claro em todo o PR de que o hardware não foi projetado pensando em proporções de cabeças de atenção esparsa, e o adaptador está absorvendo essa incompatibilidade em vez de o modelo mudar de formato por causa disso.

• Limites de dimensionamento — apenas a extensão física de cache referenciada é compactada, com limite de 262.144 tokens, que o autor calcula como no máximo 512 MiB para o tensor K/V BF16 compactado com dois cabeçotes KV. No interior, -1: o preenchimento é detectado e encaminhado para o fallback, porque o CANN exige slots válidos contíguos; linhas totalmente mascaradas mantêm a convenção existente de saída zero.

• Por que apenas prefill — a verificação de extensão e layout copia dois escalares para o host, e as cópias temporárias, além do workspace, consomem memória. Essa sincronização é a razão pela qual o caminho é restrito ao prefill eager e mantido desativado durante a captura.

Nove testes que passaram, e um número de velocidade que não veio deste branch

A evidência de correção é específica e reproduzível, o que é mais do que a maioria dos PRs de kernel oferece. O autor relata 9 testes aprovados em 40,772 segundos em um Ascend 910C (Ascend910_9362) com CANN 9.0 e torch-npu 2.10.0, sem necessidade de checkpoint: Q/K/V BF16 aleatórios não nulos contra uma referência de CPU FP32 calculada a partir das mesmas entradas BF16, slots físicos não ordenados com larguras 1/63/64/65/2051, escalas padrão e explícitas, linhas totalmente mascaradas, linhas zero, largura de seleção zero, tensores não contíguos, remanescentes da cauda causal com razão de compressão 4, de 0 a 3, mapeamento físico de duas requisições com um prefixo compartilhado, reutilização de conteúdo de cache e os formatos de cabeça local do Flash-Next com 1 e 257 linhas de consulta.

O caso principal é um prefill longo: 7.810 tokens de consulta contra um cache de 65.536 tokens com 2.051 slots selecionados por consulta, todas as saídas finitas, com oito linhas amostradas comparadas com a referência FP32. O erro L2 relativo observado atingiu 0,209% nos casos de formato de cabeça pequeno e 0,231% nas linhas amostradas de prefill longo, em relação a limiares de teste de atol=0.025, rtol=0.025 e L2 relativo abaixo de 0,008, com a exigência de que linhas vazias sejam exatamente zero. O pico de memória NPU alocada para essa execução é citado em 1.042,7 MiB — e o autor a rotula como a métrica do alocador do PyTorch, não HBM da placa nem memória do modelo completo, o que é exatamente a ressalva certa a se acrescentar.

Depois há o número que será citado e não deveria ser. O corpo do PR traz uma tabela de velocidade mostrando o caminho de atenção local existente a 2.270,79 novos tokens por segundo e a atenção principal nativa empacotada a 3.890,06 — um ganho de 1,713× / +71,3%, com o tempo médio até o primeiro token caindo de 3,109 s para 1,812 s. O autor deixa explícito que estas são medições históricas de protótipo feitas em 2026-09-29 em um checkpoint Whittle-Next-26B-A3B adaptado, executado em TP1 com pesos W8A8 e atenção BF16 em 910C sob CANN 9.0, usando o harness oficial sglang.bench_serving sob concorrência 1, com seis requisições, um token de saída cada, e 36.096 tokens de prefixo em cache excluídos da vazão de novos tokens. Elas não são um benchmark do ramo upstream no PR, os artefatos JSON originais de serving não estão presentes no checkout, e resultados locais posteriores em torno de 5.000 tokens por segundo usaram trabalho adicional nativo de indexador e block4 que explicitamente não é atribuído a esta mudança. O autor também observa que os pesos do indexador do checkpoint adaptado são inertes e seu orçamento difere do original, de modo que nada disso é evidência sobre a correção do indexador ou a qualidade de geração com orçamento total.

Um esclarecimento sobre nomenclatura, já que isso confundirá qualquer pessoa que procure pelo checkpoint: o modelo de benchmark é o artefato adaptado do próprio contribuidor. Separadamente, “Whittle-Next” também é o nome de uma série pública de fine-tunes MoE derivados do Qwen3.8, publicada por uma conta de terceiros no Hugging Face, incluindo uma variante 26B-A3B enviada em setembro. Esses não são o modelo Qwen4Exp que este PR visa, e não devem ser interpretados como a configuração de benchmark por trás daquele valor de 1,713×.

Mais duas ressalvas vêm do autor, e não de mim. A integração completa de serving, o paralelismo de tensores distribuído e o modelo completo Qwen3.8-Flash-Next não foram validados neste branch; o contribuidor diz que manter como rascunho enquanto a questão de integração e dependência é discutida é deliberado, e até pergunta no corpo do PR se o adaptador pertence ao SGLang ou ao sgl-kernel-npu repositório separado. A CI também não está limpa — o bloco de estado no corpo do PR mostra falhas no PR Test (Base), PR Test (Extra) e na execução do AMD ROCm 10. A correção descrita acima é em nível de operador; nada no PR afirma um resultado de precisão ou throughput de ponta a ponta na pilha integrada.

Por que o QSA é a parte incômoda, em números

O Qwen Sparse Attention não é uma camada de atenção convencional, e a configuração publicada mostra por que um fornecedor de aceleradores precisa escrever um caminho sob medida para ele. A partir da configuração do Qwen3.8-Flash-Next: 48 camadas organizadas como doze repetições de três blocos Gated DeltaNet seguidas de um bloco de atenção completa, full_attention_interval 4, tamanho oculto 2.560, dimensão da cabeça de atenção 256, 24 cabeças de consulta contra 2 cabeças KV, dimensão RoPE 64. O indexador que torna a atenção esparsa é uma estrutura de múltiplas consultas com 4 cabeças de consulta compartilhando 1 cabeça de chave, dimensão de cabeça 128, uma taxa de compressão de 4 e um orçamento de 2.048 micro-blocos selecionados por consulta.

Esse orçamento é o que o PR mantém fixo. O tamanho do bloco esparso permanece 1, o modo esparso permanece 0, o modo de atenção permanece 2, e a interface de tokens selecionados não é alterada; otimizações nativas de indexer e block4 estão explicitamente fora do escopo. Portanto, isto é um adaptador parafusado sob um mecanismo de seleção existente, não uma reimplementação do QSA — que também é a razão pela qual o autor pode afirmar de forma credível que o conteúdo do KV-cache não mudou.

O cartão de modelo enuncia a intenção de design sem rodeios: em vez de selecionar tokens individuais, o QSA opera no nível de microbloco para reduzir a latência de contexto longo, e essa granularidade de microbloco, somada ao estado replicado do seletor que a acompanha, é exatamente o que não se mapeia de forma limpa em um kernel genérico de atenção paginada no silício de nenhum dos dois fabricantes.

Onde isto se encaixa na expansão do serving do Qwen4Exp

Visto isoladamente, um PR em rascunho em um acelerador é uma curiosidade. Comparado ao restante de setembro, é a quarta ou quinta tábua de uma plataforma que está sendo montada em público antes que a família a que serve exista:

• A arquitetura em pesos abertos — Qwen3.8-Flash-Next, 2026-08-24, um MoE de 125B parâmetros com 6B ativados, uma tabela de embeddings de n-gramas de 51 bilhões de parâmetros e uma cabeça MTP de 4B, trazendo model_type: qwen4_exp e arquiteturas Qwen4ExpForConditionalGeneration.

• O lado do vLLM — #53909, o PR “qwen4 fuse op”, que adiciona kernels HyperConnection, QSA e PLE, ainda aberto e sem merge desde 2026-08-26; #59279, que adiciona paralelismo de contexto de decodificação ao mesmo caminho QSA, um rascunho aberto em 2026-09-29; e o trabalho de offload de PLE que foi integrado ao longo de setembro.

• O lado do SGLang — #38642 para captura de estados ocultos do DFlash, #39548 para offload de PLE para a CPU no Qwen4-Exp em Ascend, #40235 adicionando preparação no host para a tabela PLE respaldada por arquivo, e agora #41855 para o caminho de atenção do Ascend.

A linha de habilitação de NPU — sglang #37570, que adiciona Qwen3.8-Flash-Next ao SGLang em NPU com replay de grafo, MTP e kernels Triton (aberto em 2026-09-02, ainda aberto, +2.590 linhas em 20 arquivos), e sgl-kernel-npu #807 para os kernels Triton complementares (aberto em 2026-09-17, +4.643 linhas). Ambos vêm do mesmo contribuidor. #41855 é a camada de atenção que está dentro desse esforço de habilitação mais amplo.

Duas observações sobre as quais um leitor pode agir. Primeiro, toda a história do Ascend Qwen4Exp repousa sobre um número muito pequeno de contribuidores — os PRs de habilitação e o repositório de kernels compartilham um autor, e o adaptador de atenção tem outro autor. Essa concentração é uma estimativa justa de quão longe o serving do Ascend Qwen4Exp está de ser um caminho de produto suportado em vez de um experimento. Segundo, o gargalo de kernel não é específico de fornecedor: duas issues do SGLang abertas em 2026-08-28 documentam o decode do Qwen4Exp em uma NVIDIA DGX Spark, em que o tempo de kernel de QSA, PLE e Gated DeltaNet domina e em que um KV cache NVFP4 foi medido com regressão de aproximadamente 29% no decode em comparação com fp8_e4m3. As camadas de atenção e embedding dessa arquitetura são a parte difícil em todos os lugares.

O que isso não significa

Isso não significa que o Qwen 4 foi lançado, nem que está próximo. A família Qwen 4 que a Alibaba nomeou em 22 de setembro de 2026 — Max, Flash, Plus e uma categoria de 27B — continua sendo um roteiro sem cartão de modelo, sem pesos, sem identificador de API, sem janela de contexto, sem licença e sem preço. Um adaptador de framework que tem como alvo o nome da arquitetura interna é um passo para servir bem essa família um dia; não é um passo rumo à existência da família.

Isso não significa que você consiga rodar isto hoje. O PR é um rascunho com CI falhando e sem data de merge. Mesmo depois de mesclado, o caminho precisa de um Ascend 910C, BF16, CANN 9.0 com torch-npu 2.10 e de um entre cinco formatos específicos de cabeça local, e é opt-in — ou seja, uma implantação precisa escolhê-lo. O autor também se recusou a afirmar validação em nível de servidor, que é a parte que realmente diria se ele se sustenta sob batching real.

E isso não significa que o Qwen3.8-Flash-Next seja um produto suportado no Ascend, nem em qualquer outro build de engine distribuído. Os caminhos do Qwen4Exp nos dois principais runtimes abertos são pull requests ainda não mesclados. Não há nenhuma versão lançada do SGLang ou do vLLM que você possa instalar e que ofereça suporte nativo a essa arquitetura — a conveniência, no estilo FastAPI, de um endpoint hospedado é uma coisa diferente de um kernel que você mesmo pode executar, e a lacuna entre eles é exatamente para o que servem PRs como este.

O que você pode realmente usar enquanto espera

Se o motivo pelo qual você se interessa pelo Qwen4Exp é que quer testar o comportamento de contexto longo da arquitetura, e não os detalhes internos do kernel, o modelo que você deve buscar é o nível que a Alibaba realmente disponibiliza. Qwen3.8-Flash — a linha de produção construída sobre o Qwen3.8-Flash-Next, com ferramentas oficiais integradas e um contexto de 1.000.000 de tokens — está ativa no OrcaRouter como qwen/qwen3.8-flash: entrada de texto, imagem e vídeo, saída máxima de 131.072 tokens, $0,15 por milhão de tokens de entrada e $0,47 por milhão de saída, com leituras de cache a $0,0184. Esses são preços de tabela do provedor repassados com 0% de markup da nossa parte, então uma alteração de preço ou de limite do fornecedor nele chega até você no mesmo dia em que é anunciada. Na janela móvel dos últimos sete dias, o card em tempo real mostra uma latência p50 para o primeiro token de 4.416 ms, cerca de 106 tokens de saída por segundo e uma taxa de erro de 2,68% — o perfil de uma camada de texto de alto volume, e não de uma prévia de laboratório.

Duas ressalvas honestas, e são as mesmas duas que as análises irmãs sobre esta arquitetura trazem. O próprio Qwen3.8-Flash-Next — o checkpoint de prévia em FP8, aquilo de que você precisaria para reproduzir qualquer uma dessas medições de kernel localmente — não está no nosso catálogo; o nível Flash servido é a implantação de produção construída a partir dele, não o artefato de prévia bruto. E nenhum dos trabalhos com Ascend ou DCP descritos acima existe em algo que você possa chamar, porque nada disso foi mesclado. O que o nível servido oferece é uma forma barata de descobrir se sua carga de trabalho tem o formato do problema que esses kernels resolvem — prompts longos, com muito prefixo e agênticos, contra um contexto muito longo. Se tiver, o throughput e o comportamento de cache que você observa ali correspondem ao mesmo comportamento que a stack de serving do Qwen 4 será ajustada para proteger.

Há também um argumento de infraestrutura para não esperar por uma família que não tem data. Independentemente de qual nível acabe vencendo na linha Qwen 4, o custo de troca é uma questão de roteamento, e não um projeto de integração, e uma API para mais de 200 modelos é como você mantém essa opção aberta sem um segundo contrato ou alteração de código quando os pesos chegarem. O failover importa pelo mesmo motivo aqui de uma forma específica: se você quer construir com base em um nível não comprovado, quer que a requisição passe para algo estável em vez de falhar quando o caminho em que você apostou estiver tendo um mau momento.

Três perguntas que vale a pena responder diretamente

O SGLang #41855 significa que o Qwen 4 foi lançado ou que está disponível para pré-visualização?

Não, em ambos os pontos. O pull request tem como alvo a arquitetura Qwen4Exp conforme implementada no Qwen3.8-Flash-Next, que a Alibaba lançou em 2026-08-24. Ele não altera os pesos do Qwen 4, e nenhum nível do Qwen 4 tem pesos para alterar. O sinal a ser lido aqui é sobre capacidade de serving para uma arquitetura de preview, não sobre a disponibilidade da família.

Se a ficha de um modelo diz qwen4_exp, isso é o Qwen 4?

Não — e esta é a armadilha de nomenclatura de toda a história. qwen4_exp é o identificador interno de arquitetura, e é o que você encontrará em config.json para o Qwen3.8-Flash-Next e seu equivalente FP8. “Arquitetura experimental” é a palavra-chave: os pesos são publicados, a arquitetura é real, e o modelo é uma prévia daquilo sobre o que se espera que a família Qwen 4 seja construída. Pesquisar o identificador e encontrar um PR do SGLang ou do vLLM com Qwen4Exp no título fala sobre trabalho no motor, não sobre um lançamento.

Isto é uma história de Ascend contra NVIDIA?

Na verdade, não. O mesmo caminho de atenção também precisou de um adaptador sob medida no lado da NVIDIA — paralelismo de contexto de decodificação para QSA no vLLM, e um kernel nativo de prefill esparso para Hopper — e os problemas do DGX Spark mostram que o tempo de kernel de QSA, PLE e Gated DeltaNet também domina a decodificação ali. O indexador de microblocos do QSA e seu estado de seletor replicado simplesmente não são o que kernels genéricos de atenção paginada pressupõem. A contribuição da Ascend para o padrão é a restrição mais acentuada: um tiler de proporção de cabeças que só aceita potências de dois, o que força o padding que o adaptador precisa ocultar.

A coisa a observar

Não se isso será mesclado. O adaptador é honesto quanto a ser um adaptador, os testes de correção são reproduzíveis sem um checkpoint, e o autor sinalizou a questão da integração em vez de fingir que ela está resolvida. O que é preciso observar é o que acontece depois que a linha de habilitação da NPU e este caminho de atenção forem combinados — se o ramo integrado terá a execução ponta a ponta que nenhum dos dois teve, em batching real com o modelo completo, em vez de tensores locais com formato de cabeça. O valor de 1,713× é o que vai circular, e é o que foi calculado em um build diferente, em um checkpoint adaptado, com um indexador inerte. Um número medido na stack final valeria consideravelmente mais do que um histórico.

Até lá, o resumo honesto é aquele a que o próprio PR se atém: a aritmética confere, a flag está desativada por predefinição, a CI está vermelha, e o modelo no título ainda não existe.