
Qwen 4: O PR 'qwen4 fuse op' do vLLM nomeou a arquitetura — Apsara 2026 nomeou a família
- OrcaNOVOOrcaCyber: GLM 5.3 Flash Abliterated2026-10-27106 tok/s
- OrcaNOVOOrcaCyber: Qwen3.8 Flash Next Abliterated2026-10-26$0.80 / $1.60 por 1M de tokens · 256 tok/s
- OrcaNOVOOrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 por 1M de tokens · 89 tok/s
- MoonshotNOVOMoonshotAI: Kimi K3.1 Pro2026-10-2446Inteligência
- OrcaNOVOOrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 por 1M de tokens · 104 tok/s
- minimaxNOVOMiniMax: M3.1 Flash2026-10-1929Inteligência
- OrcaNOVOOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 por 1M de tokens · 62 tok/s
- deepseekNOVODeepSeek: DeepSeek V4.1 Flash 10172026-10-1733Inteligência
- DeepSeekNOVODeepSeek: DeepSeek V4.1 Flash2026-10-1740Inteligência
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 por 1M de tokens · 103 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955Inteligência
- anthropicAnthropic: Claude Sonnet 5.52026-09-2854Inteligência
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 por 1M de tokens · 166 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2228Inteligência
- OpenAIOpenAI: GPT-6 Sol2026-09-2248Inteligência
- AnthropicAnthropic: Claude Opus 5.52026-09-2258Inteligência
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-2127Inteligência
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-2130Inteligência
- xAIGrok 4.72026-09-2134Inteligência
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 por 1M de tokens · 79 tok/s
Um pull request intitulado "Add qwen4 fuse op" está aberto no repositório vLLM desde 26 de agosto e, durante a maior parte desse mês, foi a coisa mais próxima de uma descrição da próxima geração de modelos da Alibaba que existia fora da empresa. Isso mudou em 22 de setembro de 2026, quando o líder do Qwen na Alibaba, Liu Da Yiheng, aproveitou a abertura da conferência Apsara em Hangzhou para nomear a família: Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus e Qwen 4 27B — a camada de pesos abertos, e aquela pela qual o mundo da inferência local vem esperando. Dois dias depois, com a conferência encerrada, a empresa colocou essa família em um roadmap pela primeira vez: Qwen 4 em treinamento, e uma linha sucessora — Qwen 4.5 e Qwen 5 — projetada em 5 a 10 trilhões de parâmetros, um número que o CEO do Alibaba Group, Eddie Wu, deu no palco e que a empresa depois repetiu em seu próprio comunicado em inglês. O que o roadmap não é, duas semanas depois, é um cronograma. A janela de tempo que agora circula é outubro, ou o início de novembro — e nada disso remonta a algo que a Alibaba tenha publicado. O material escrito da própria empresa não traz mês, trimestre nem data; o modelo não tem identificador, nem janela de contexto, nem preço; e não existe nenhum repositório do Qwen 4 na organização Qwen no Hugging Face. Trate a janela como um desejo, não como um plano. O pull request — vllm-project/vllm#53909, ainda aberto, ainda não mesclado e ainda aguardando revisão — também não traz data de lançamento nem contagem de parâmetros. Ele adiciona kernels Triton independentes para três famílias de operadores: HyperConnection, Qwen Sparse Attention (QSA) e operações de estado PLE. Seu título diz "qwen4", e sua lista de operadores é quase exatamente compatível com a arquitetura que a Alibaba lançou nos pesos abertos do Qwen3.8-Flash-Next — um modelo multimodal de mistura de especialistas, lançado em 26 de agosto de 2026, cujo card no Hugging Face diz "A Preview of the Qwen4 Architecture". O próprio Qwen 4 ainda não foi lançado. A família tem um nome, um lugar em um roadmap e uma janela rumorada; os kernels ainda são a única coisa que a descreve.
Este é um texto do tipo “o que sabemos até agora”, não uma notícia de lançamento. A Alibaba já nomeou a família num palco público e colocou-a no roteiro da empresa, mas dar um nome não é lançar: não existe ficha de modelo, nem pesos, nem API para nenhum nível do Qwen 4, e todas as afirmações de arquitetura abaixo continuam a vir da pré-visualização do Qwen3.8-Flash-Next e dos artefatos de engenharia que a rodeiam, e não de qualquer documento do Qwen 4. A prova concreta é o pull request do vLLM ainda em revisão, o modelo de pré-visualização lançado, um PR do sglang submetido em 27 de agosto que acrescenta suporte nativo para a mesma configuração de arquitetura Qwen4-Exp, e a entrada qwen4_exp que desde então foi integrada no próprio registro de modelos do vLLM na main — Qwen4ExpForCausalLM, Qwen4ExpForConditionalGeneration e Qwen4ExpMTP — a par do trabalho multimodal com frontend em Rust, que foi integrado em 1º de setembro. A conclusão que deles retiramos — que os operadores nos PRs são a arquitetura que a Alibaba pré-visualizou — é uma leitura dessa evidência, e cada detalhe específico abaixo está rotulado em conformidade. Uma afirmação aqui não é de todo da Alibaba: a janela de outubro ao início de novembro vem de uma publicação de lista de observação no X e das páginas de rastreamento que a repetiram nas últimas duas semanas, não foi reproduzida e é apresentada como de origem comunitária onde quer que apareça.
O que a Alibaba realmente disse em 22 de setembro
Alibaba apresentou uma prévia da família Qwen 4 na abertura de sua conferência Apsara (Yunqi), que ocorreu em Hangzhou de 22 a 24 de setembro de 2026, com o líder do Qwen, Liu Da Yiheng, no palco. Quatro níveis foram nomeados na abertura, com base na estrutura que a geração 3.8 já havia estabelecido:
• Qwen 4 Max — a categoria carro-chefe, e aquele posicionado contra o principal modelo de todos os outros laboratórios de ponta.
• Qwen 4 Flash — a camada de alto rendimento, voltada para cargas de trabalho sensíveis à latência e de grande volume, em vez de raciocínio de pico.
• Qwe*n 4 Plus — o nível intermediário equilibrado.
• Qwen 4 27B — o nível de pesos abertos: a classe de tamanho em que a Qwen já lançou pesos abertos antes, e aquela sobre a qual se escreve como a opção de execução local.
A entrada de 27B é a parte concreta do anúncio, e é aquilo a que o sinal de fonte por trás deste artigo estava reagindo. Na geração 3.8, o nível de 27B foi o lançamento de pesos abertos convertido para MLX, quantizado para NVFP4 e ajustado finamente poucos dias após o seu lançamento, então um Qwen 4 27B nomeado dá novamente um alvo a esse ecossistema a jusante. É um alvo e não um lançamento, e a distinção vale a pena manter: a Alibaba não publicou nenhum detalhamento de parâmetros, nenhuma licença, nenhuma janela de contexto e nenhuma data para ele, e o nome do nível nem sequer diz se é denso ou uma mistura de especialistas. Tudo o que tornava o nível de 27B anterior executável — a classe de tamanho, o foco em máquina única — é herdado do histórico da linha de produto, não especificado para este modelo.
O que a conferência não produziu é aquilo em que um leitor pode se basear para planejar. A posição declarada da Alibaba — enquadramento de fornecedor, apresentado no palco e noticiado por vários veículos independentes, em vez de verificado de forma independente — é que o Qwen 4 se baseia em uma arquitetura de nova geração, que está em treinamento e que chega "em breve". Nenhum nível tem janela de contexto, preço, lista de modalidades ou pontuação publicada. O único item com data na conferência era um modelo de vídeo de nova geração previsto para novembro. Um número do mesmo palco precisa ser mantido no seu devido lugar: a ambição de 5 a 10 trilhões de parâmetros pertence ao horizonte temporal do Qwen 4.5 e do Qwen 5, não ao Qwen 4 — nenhuma contagem de parâmetros foi associada a qualquer nível do Qwen 4. Esse número já não é um vazamento nem uma alegação em circulação: está no próprio comunicado em inglês da Alibaba, atribuído ao keynote do CEO Eddie Wu, e é apresentado como uma projeção sem data e sem arquitetura por trás — declarado pela empresa, e ainda não reproduzido.
Portanto, a nomenclatura mudou o status da família, não o estado das evidências. Tudo abaixo ainda é o relato da camada de serviço sobre o que esta arquitetura é — e, como o anúncio não acrescenta especificações próprias, esse relato continua mais detalhado do que qualquer coisa que a Alibaba tenha publicado.
O que o PR "qwen4 fuse op" realmente é
Pull request #53909 no vllm-project/vllm está aberto, vindo de um fork de contribuidor, e ainda aguardando revisão do code-owner — a revisão automatizada foi desativada justamente porque veio de um fork. É um trabalho pequeno, em formato de kernel:
• Três kernels HyperConnection — uma Gema RMSNorm agrupada, uma redução de gate e uma combinação de injeção.
• Três kernels QSA mais três wrappers de baseline do fornecedor para comparação.
• Kernels de coleta de estado PLE e dispersão mascarada.
• Treze testes aprovados cobrindo guardas de dtype e forma, metadados de paginação, slots de cache, layout MRoPE, estado com stride, índices nulos e duplicados, e execução determinística.
Dois detalhes importam além da lista de operações. Primeiro, a implementação é fail-closed: guards de host geram erros em vez de recorrer a um caminho de computação Torch genérico, porque um valor silenciosamente errado em um kernel de atenção é pior do que uma falha grave. Segundo, a divergência de nomenclatura — o título diz "qwen4" enquanto a descrição menciona Qwen3.8-Flash-Next — é por si só um sinal. O lado do vLLM está tratando o modelo de pré-visualização como a primeira instância da linha qwen4, e construindo kernels sob o nome da família que cobrirão o que vier depois dele.

Para contextualizar o que é um "fuse op": um motor de inferência normalmente executa o grafo de um modelo com um lançamento de kernel por operação, e cada lançamento carrega sobrecarga — viagens de ida e volta de memória entre kernels, custo de despacho. Fundir várias operações elemento a elemento e de estado em um único kernel reduz essa sobrecarga, e é exatamente aí que o custo e a latência de uma nova arquitetura são ganhos ou perdidos. Um modelo construído sobre operadores que não têm nenhuma implementação fundida em lugar algum será lento e faminto por memória, não importa quão inteligente seja o treinamento; o primeiro motor que os fundir bem define o preço real do modelo no mundo real.
Lendo os nomes do kernel como um blueprint.
Nenhum desses operadores existe no opset padrão do transformer, e é justamente por isso que eles precisam de novos kernels — e cada um corresponde a uma parte específica da arquitetura que a Alibaba mostrou em prévia no Qwen3.8-Flash-Next:
HyperConnection → conexões residuais com portas. O único fluxo residual é ampliado para quatro ramos paralelos com portas dinâmicas elemento a elemento, permitindo que o modelo decida quanto ler de e escrever em cada ramo; o estado residual pode ser armazenado em FP8 para reduzir o tráfego de memória.
• QSA → Qwen Sparse Attention. Um indexador leve comprime as chaves em micro-blocos com uma taxa de compressão de 4, atribui pontuações a eles e mantém os 512 melhores blocos — aproximadamente 2.051 posições lógicas de tokens — enquanto a softmax final e a agregação de valores ainda são executadas no K/V original, não comprimido. Doze das 48 camadas são QSA; as outras 36 são camadas de atenção linear GDN, com estado recorrente de tamanho fixo e sem cache KV crescente.
• Operações de estado PLE → memória de n-gramas. A tabela de consulta de 51 bilhões de parâmetros — "Per-Layer Embeddings" no artigo do SGLang — é endereçada por hash a partir do token atual mais os dois ou três anteriores, buscando 16 linhas por token. Suas posições são pré-computáveis, portanto pode residir na memória do host e ser pré-buscada assincronamente, em vez de ocupar VRAM da GPU.
• O corpo MoE onde os kernels residem: 125B de parâmetros totais com aproximadamente 6B ativos por token — menos de 5% de ativação — roteado por 512 especialistas com roteamento top-10.

Duas ressalvas mantêm isto honesto. Primeiro, a arquitetura acima é extraída do cartão de modelo do Qwen3.8-Flash-Next e de análises da comunidade, não de qualquer documento do Qwen 4 — é evidência sobre a família, não uma especificação da família. Segundo, nada disso muda o fato central: o Qwen 4 não existe em nenhum catálogo.
Uma linha de evidência separada é o caminho de visão, que vale a pena manter separado da leitura do kernel acima. Independentemente de qualquer mapeamento de operador, o próprio registo de modelos do vLLM no main lista uma entrada qwen4_exp — Qwen4ExpForConditionalGeneration — registada como um modelo multimodal com uma torre de visão Qwen3-VL e um Qwen3VLMultiModalProcessor. O PR de frontend em Rust (#54813) que liga essa configuração à crate multimodal do motor, o caminho de código que transforma entradas de imagem em tokens, foi integrado em 1 de setembro de 2026 — uma afirmação mais forte do que o mesmo PR estar aberto, porque o caminho multimodal para a linha qwen4 está agora no motor, e não no fork de alguém. Ainda não é um lançamento: o modelo que essa entrada de registo descreve não tem pesos nem API. Mas é a primeira confirmação ao nível da engenharia de que a próxima geração Qwen aceita entrada de imagem, e o rótulo "multimodal" na arquitetura já não é apenas uma linha na ficha do modelo da pré-visualização.
Por que a arquitetura altera o quadro de custos
Se o Qwen 4 for lançado nesta arquitetura, a economia será diferente da de um transformer denso padrão — ou mesmo de um MoE comum —, e essa diferença é o motivo pelo qual vale a pena acompanhar o trabalho com kernels.
• Divisão de memória e computação. O custo de memória rastreia os parâmetros totais — todos os 125B devem estar residentes para servir o modelo. O custo de computação rastreia os parâmetros ativos — apenas ~6B são executados por passagem direta. É essa separação que permite que um modelo "125B" sirva ao custo de um muito menor.
• O cache KV para de crescer na maioria das camadas. Com 36 das 48 camadas usando atenção de estado recorrente de tamanho fixo, o cache de chave/valor em crescimento fica confinado a 12 camadas. Em um contexto nativo de 262 mil tokens — 1M via YaRN — isso é em grande parte por que o serviço de contexto longo se torna acessível.
• A tabela grande é descarregável. A tabela de n-gramas é o maior consumidor de memória, com 51B parâmetros, e não precisa ficar na GPU. O trabalho day-0 do SGLang mediu o descarregamento da tabela BF16 para memória host fixada, liberando cerca de 23 GiB por GPU no H200 e aumentando a capacidade de KV alocada em aproximadamente 78% — com saídas idênticas bit a bit. Do lado do vLLM, o mesmo descarregamento ocorreu em etapas, em vez de em um único PR: o PR de suporte original (#53899) foi fechado sem merge em 21 de setembro, enquanto o recurso em si chegou através de merges separados — #54371, descarregamento PLE baseado em UVA com paralelismo tensorial Engram, em 9 de setembro, e um caminho ROCm (#57497) em 25 de setembro.
{{1}}Nenhum desses números ainda foi auditado de forma independente{{/1}} — {{2}}as alegações de aceleração de 7.6×/4.9× em contexto longo, o número de decodificação de 540 tok/s do post do SGLang, a alegação de custo de treinamento de "1/9 do Qwen3.7-Plus"{{/2}} — {{3}}e devem ser lidos como divulgados pelo fornecedor ou pela comunidade até que um índice neutro os reproduza.{{/3}}
A corrida para servi-lo.
Ambos os principais mecanismos têm trabalho em andamento para o qwen4 — a SGLang publicou suporte no dia 0 poucos dias após a prévia de 26 de agosto, e o trabalho de cada lado não parou de se acumular desde então, desde o registro de configuração até a engenharia de kernel e memória.
• O SGLang publicou um post de day-0 em 26 de agosto, em uma colaboração entre SGLang, Alibaba, NVIDIA e AMD, disponibilizando um checkpoint NVFP4 e alegando decodificação de 540 tokens/s em TP4 no B200 com decodificação especulativa.
• Em 27 de agosto, um PR do sglang (#36585) adicionou suporte nativo ao Qwen4-Exp ao próprio motor — registrando a configuração Qwen4ExpForConditionalGeneration e um modelo de texto construído a partir das mesmas peças GatedResidual, Gated DeltaNet, atenção esparsa do Qwen, PLE e MoE. Ele não foi integrado: o PR vem de um colaborador que não é mantenedor, o trabalho foi atribuído a um agente autônomo chamado Argus, e ainda está aberto e aguardando revisão. Sua âncora, no entanto, é verificável de forma independente — a própria configuração do Qwen3.8-Flash-Next declara model_type=qwen4_exp, e a implementação de referência agora está em huggingface/transformers, em models/qwen4_exp.
• Em 8 de setembro, um PR draft do sglang (#38492) foi aberto contra qwen4-main-squashed, um branch do sglang dedicado à linha Qwen4/Flash-Next, e este não é um registro. Ele porta o RecoverSSM — um caminho de recuperação de estado aceito, construído inicialmente para o Qwen3.8-Flash-Next no SM120 — para a verificação de predição multi-token (MTP) da arquitetura. Os drafts de MTP percorrem o estado recorrente de tamanho fixo das camadas Gated DeltaNet e, em vez de manter cada estado especulativo intermediário em memória enquanto um draft é verificado, a engine reconstrói o estado aceito a partir do estado confirmado e do prefixo de tokens aceito. O modo é opt-in (uma flag --gdn-mtp-cache-mode none; o comportamento atual de cache completo permanece como padrão), e é precoce mesmo para os padrões desta história: um draft tocado pela última vez em 14 de setembro, cujo head atual ainda falha em nove de suas verificações, com a própria checklist do autor em aberto antes que possa ser marcado como pronto para revisão. A direção é o ponto — o sglang está desenvolvendo o caminho de serving do Qwen4, não apenas registrando sua configuração.
• A linha qwen4 do vLLM passou de três PRs abertos para um balanço misto nas semanas desde que este artigo foi publicado pela primeira vez. O PR multimodal com frontend em Rust (#54813) foi mesclado em 1 de setembro. O trabalho de PLE-offload foi mesclado em duas partes — #54371 em 9 de setembro e #57497 em 25 de setembro —, enquanto o PR original de PLE-offload (#53899) foi fechado sem ser mesclado em 21 de setembro. A configuração desde então foi para o upstream: #57387, que muda a configuração e o processador qwen4_exp para as implementações upstream do Transformers, foi mesclado em 2 de outubro. O que ainda está aberto é o PR de fuse-op que é o assunto deste artigo (#53909) — junto com uma correção de bug do ring buffer QSA protocolada em 1 de outubro (#59528) e uma passagem SM86 (Ampere) pela tabela de n-gramas de 51 bilhões de parâmetros, aberta desde 26 de setembro (#58856), que é o tipo de trabalho que alguém faz quando um modelo é algo que as pessoas estão tentando servir em hardware mais antigo, em vez de algo que ninguém executou. A própria configuração qwen4_exp está registrada no vLLM como multimodal: uma torre de visão Qwen3-VL emparelhada com o modelo de texto Qwen4-Exp.
Esta é uma corrida com um prêmio real. O motor que melhor funde os novos operadores define o preço de serviço da geração Qwen4, porque a eficiência do kernel — não a contagem bruta de parâmetros — é o que compõe o custo por token de um modelo de atenção híbrida.
O que está realmente disponível hoje: Qwen3.8-Flash-Next vs Qwen 4
Vale a pena ser preciso sobre as duas coisas desta história, porque a nomeação está fazendo muito trabalho.
• Qwen3.8-Flash-Next foi lançado. Os pesos abertos estão no Hugging Face e no ModelScope sob a licença qwen-community-1.0, nas variantes padrão e FP8; o card do modelo define a ficha técnica — MoE de 125B, ~6B ativos, tabela n-gram de 51B, contexto de 262K, multimodal. É a prévia da arquitetura, não o carro-chefe.
• Qwen3.8-Flash é a variante de produção disponibilizada que a Alibaba anunciou junto com ele, listada no Qwen Cloud a ¥1 por milhão de tokens de entrada e ¥3 por milhão de tokens de saída (aproximadamente $0,16 / $0,47), com um contexto padrão de 1M tokens e ferramentas integradas. Preços informados pelo fornecedor, ainda não presentes em nenhum índice independente.
• Qwen 4 ainda não foi lançado. A Alibaba nomeou todos os quatro níveis em 22 de setembro de 2026 e disse que a família está em treinamento e chegará em breve — a primeira informação oficial sobre o prazo, e ainda assim não é um cronograma. Sem data, sem card e sem pesos para nenhum nível. A janela que circula agora é de outubro ao início de novembro, e vem de threads de watchlist e páginas de tracker, não da Alibaba: o status de treinamento é declarado pela empresa, já o prazo vem da comunidade. A janela de setembro que circulou em um vazamento de roadmap de julho já se esgotou, o que é uma resposta por si só.
• O nível Qwen 4 27B é o que merece atenção por um motivo alheio a benchmarks: é o único nível da família com um histórico de lançar pesos abertos, e um 27B anunciado é aquilo em torno do qual as stacks de inferência local se planeiam — e é por isso que a ausência de detalhamento dos tamanhos, da licença e da data importa mais aqui do que importa para o modelo principal.
A tabela de benchmark da prévia — DeepSWE 1.1 com 58,7, SWE-bench Pro com 62,5, LiveCodeBench v6 com 91,9 — é reportada pelo fornecedor na ficha técnica e não foi reproduzida de forma independente. Planeje com base na arquitetura; trate as pontuações como uma promessa, não como uma medição.
O que um desenvolvedor deve fazer agora
Nada na sua stack atual muda hoje: o Qwen 4 não é chamável em lugar nenhum — a Apsara nomeou os tiers e colocou a família em um roadmap, e não entregou nada disso — e, no momento em que escrevo, os pesos abertos do Qwen3.8-Flash-Next também ainda não estão na nossa própria lista de modelos — as coisas mais próximas que disponibilizamos hoje são a variante Qwen3.8 Flash servida a $0,15/$0,47 por milhão de tokens e a rota de pesos abertos do Qwen3.8 27B a $0,33/$2,40, que é a coisa mais próxima de um Qwen executável localmente no catálogo enquanto a geração sucessora ainda é um rumor. A linha do roadmap é a única coisa que vale a pena ler duas vezes, porque é a primeira vez que a Alibaba compromete uma geração sucessora no papel: se o Qwen 4.5 e o Qwen 5 realmente ficarem na faixa de 5 a 10 trilhões de parâmetros, o tier que você pode se dar ao luxo de auto-hospedar nessa geração importa mais, não menos. Se você quer sentir a arquitetura antes de a família ser lançada, os caminhos honestos são baixar os pesos você mesmo ou esperar que a prévia chegue por trás de uma API. Para quem está planejando em torno do tier de 27B, vale o mesmo, com um acréscimo: vale a pena acompanhá-lo justamente porque é o tier com maior probabilidade de ser executável sem uma API, e atualmente é o menos especificado dos quatro.
Quando um Qwen3.8-Flash-Next ou um modelo Qwen 4 aparecer em um catálogo de provedor, o custo de troca no OrcaRouter é praticamente zero: uma API para mais de 200 modelos, o preço de tabela do provedor repassado com 0% de margem, e um corte de preço do fornecedor publicado do nosso lado no mesmo dia. O mesmo endpoint e a mesma chave que você já usa para o Qwen3.8 Max — disponível hoje como qwen/qwen3.8-max a US$ 2,00/US$ 6,00 por milhão de tokens, com o preço de tabela repassado — é o mesmo endpoint que uma chamada do Qwen 4 vai usar.
Para uma arquitetura não comprovada, o failover automático é o primeiro passo certo: roteie uma fatia do tráfego para o novo modelo com failover para Qwen3.8 Max (ou qualquer modelo que a carga de trabalho realmente precise) e deixe seu próprio tráfego decidir se a prévia está à altura do card — uma edição de routing-DSL, não uma reescrita.

O que estamos assistindo
• Se os kernels de fuse-op serão mesclados (#53909), agora o último dos três PRs originais do qwen4 no vLLM que ainda está aberto — o front-end multimodal e o trabalho de offload de PLE já foram integrados, e a configuração já foi para o upstream. Do lado do sglang, o PR de suporte nativo e o rascunho do RecoverSSM ainda estão ambos abertos. Um conjunto de kernels mesclado é o sinal mais forte até agora de que a linha qwen4 está nos roadmaps de curto prazo de ambos os runtimes.
• Se qwen4-main-squashed se consolidar como a mainline do Qwen4 do sglang — um branch de integração que segue recebendo trabalho de kernel e memória é um compromisso mais forte do que um PR de um único colaborador, e vale a pena observar o que acontece com ele quando o carro-chefe tiver uma data.
• Se o caminho de visão sobrevive até o lançamento — a entrada de registro multimodal do qwen4_exp e a integração do front-end Rust são o primeiro sinal forte de que o carro-chefe vem com entrada de imagem, e ambos agora estão no código principal do vLLM, e não em um fork. A questão em aberto é se o modelo lançado mantém essa torre de visão.
• Os primeiros números independentes sobre o Qwen3.8-Flash-Next, que serão o primeiro teste para saber se as afirmações de custo da arquitetura se sustentam fora do fornecedor.
• Uma data ou card para o próprio Qwen 4. A família agora tem nomes, uma lista de níveis, um status de treinamento e um lugar em um roadmap publicado, e nada disso é um cronograma. A janela que a comunidade está circulando é de outubro ao início de novembro; o roadmap que a Alibaba publicou na Apsara não contém nenhuma data, e nenhum repositório do Qwen 4 apareceu no Hugging Face. O próximo sinal real é o primeiro com uma data anexada a ele — um card de modelo, um identificador de API ou pesos.
• O nível Qwen 4 27B em particular — se ele é disponibilizado com pesos abertos no padrão Qwen3.8-27B, sob qual licença, e com que rapidez o ecossistema de conversão e ajuste fino acompanha.
• A licença para a família — se o Qwen 4 repete o padrão do Qwen3.8 Max de pesos abertos sob uma licença com restrições de uso, ou se abre ainda mais.
• A corrida de preços servidos na prévia, que nos dirá quanto os tokens da arquitetura híbrida realmente custam em produção.
FAQ
Quando o Qwen 4 será lançado? Ainda não há uma data, e agora há duas declarações oficiais sobre o momento, em vez de uma. O CEO do Alibaba Group, Eddie Wu, confirmou na Apsara em 22 de setembro de 2026 que o Qwen 4 está em treinamento e que uma linha sucessora — Qwen 4.5 e Qwen 5 — está projetada para 5 a 10 trilhões de parâmetros; o comunicado em inglês da Alibaba repete ambas. Nenhuma das declarações inclui um cronograma. Três alegações de datas circularam e nenhuma delas é da Alibaba: o vazamento do roadmap de julho que ventilava uma janela em setembro de 2026, que passou sem lançamento; e a janela de outubro ao início de novembro que agora circula em posts de listas de acompanhamento e páginas de rastreadores, que é uma leitura da cadência de lançamentos do laboratório, e não uma declaração do laboratório. O lançamento do Qwen3.8-Flash-Next em 26 de agosto é explicitamente uma prévia da arquitetura, não o carro-chefe.
O Qwen 4 é o mesmo modelo que o Qwen3.8-Flash-Next? Não. O Qwen3.8-Flash-Next é um modelo de pesos abertos já lançado, cujo cartão o descreve como "A Preview of the Qwen4 Architecture". O Qwen 4 é a família ainda não lançada que a Alibaba anunciou em 22 de setembro — quatro níveis, nenhuma especificação publicada — e a arquitetura é compartilhada, mas o produto não é.
Posso usar o Qwen 4 hoje? Não — nada encaminha para um modelo que não tem pesos nem API, e o anúncio de 22 de setembro não mudou isso. As coisas mais próximas que você pode realmente acessar são os pesos abertos do Qwen3.8-Flash-Next, lançados em 26 de agosto, ou a API do Qwen3.8 Max, disponível no OrcaRouter a US$ 2,00/US$ 6,00 por milhão de tokens.
O kernel é a mensagem — e o anúncio de 22 de setembro, apesar de todo o tempo de palco, não a sobrescreveu. O vLLM não gasta ciclos de revisão construindo kernels Triton para famílias de operadores que espera abandonar, e a Alibaba também não publica uma prévia de arquitetura que espera abandonar. Entre o PR "qwen4 fuse op" ainda aberto, a prévia do Qwen3.8-Flash-Next lançada em 26 de agosto, a entrada qwen4_exp agora no registro mainline do vLLM com sua config integrada upstream e sua integração multimodal mesclada, o trabalho de PLE-offload que chegou tanto ao CUDA quanto ao ROCm em setembro, e um PR draft do sglang aberto em 8 de setembro que ainda ajusta a memória do SM120 para o caminho de previsão multi-token da linha, o formato da próxima geração Qwen não é mais rumor — está escrito nos kernels e caminhos de memória que dois runtimes estão construindo para ela. O que a Apsara acrescentou é um nome para cada nível, um status de treinamento e uma faixa de parâmetros para a geração seguinte. O que a comunidade acrescentou desde então é uma janela, e não um fato: de outubro ao início de novembro, das mesmas threads da watchlist. A Alibaba não publicou nenhuma das duas. Planeje para a arquitetura; não aposte nas datas.
