Amostragem Qwen4Embed-shift: dentro do vLLM {{1}}1018{{/1}}, e o que ele diz sobre o Qwen 4

O número mais informativo no pull request #61018 do vLLM é uma perda: 1,5%. Esse é o limite superior que o autor atribui à própria alteração — cerca de 0,6 a 0,8 milissegundos economizados de um passo médio de 42 milissegundos, medidos em uma máquina que não é dele, em um patch que ele não consegue executar de jeito nenhum. O pull request, intitulado "[Model] Qwen4Exp: support batch-sharded sampling (compute_logits_local)" e aberto em 2026-10-10 pelo colaborador kimseunghyun-kr, acrescenta três linhas de código de modelo a dois arquivos para que a arquitetura Qwen4Exp possa usar um caminho de amostragem que o vLLM passou a oferecer em agosto. É um rascunho. São 14 linhas de código de modelo mais 57 linhas de teste. E ainda assim vale a pena lê-lo com atenção, por causa daquilo que essas três linhas estão contornando: Qwen4Exp é a arquitetura dentro do Qwen3.8-Flash-Next, o modelo de pesos abertos de 125 bilhões de parâmetros que o fornecedor publicou em 2026-08-24 como "uma prévia experimental da arquitetura que servirá de base para o Qwen4" — e um bug de dois caminhos na metade somente texto dessa arquitetura é exatamente o tipo de detalhe que você só descobre observando a camada de serving em vez do post de lançamento.

Para não deixar margem para ambiguidade quanto ao enquadramento, porque isso importa aqui: o próprio Qwen 4 ainda não foi lançado. O fornecedor nomeou quatro níveis do Qwen 4 — Qwen 4 Max, Flash, Plus e 27B — na sua conferência Apsara, em 2026-09-22, e não publicou pesos, identificador, preço, comprimento de contexto nem benchmark para nenhum deles. Nada do que vem abaixo é um lançamento. Esta é uma leitura do que sabemos até agora sobre um único pull request em rascunho, e tudo nele que traz um número é ou um carimbo de data/hora que você pode verificar, ou um número que o contribuidor digitou no corpo do seu próprio PR, ou um valor lido de um arquivo de configuração de modelo público.

O que é amostragem fragmentada por lote, em um parágrafo

O paralelismo de tensores divide os pesos de um modelo entre GPUs; a projeção do vocabulário é o tensor único mais largo da pilha, então cada rank normalmente calcula apenas sua própria fatia do vocabulário — e então cada rank faz all-gather, de modo que cada um acaba mantendo os logits completos para cada requisição no lote. A amostragem fragmentada inverte essa troca. Em vez de replicar o vocabulário entre os ranks, ela fragmenta o lote: cada rank amostra uma fatia das requisições, e os ranks trocam fatias de vocabulário entre si por meio de um all-to-all. A própria documentação da CLI do vLLM descreve a flag claramente — "Cada rank amostra uma fatia do lote em vez de cada rank amostrar todo ele" — e afirma as restrições: --enable-batch-sharded-sampling tem como padrão False, exige tensor_parallel_size maior que 1, pelo menos tensor_parallel_size sequências máximas e um valor não negativo de max_logprobs. A última linha dessa documentação é o gancho no qual este pull request se apoia: "Os modelos optam por participar implementando compute_logits_local."

O recurso em si não é novo. O vLLM o mesclou como PR #50465 — "[Model Runner V2] batch-sharded sample", de Giancarlo Delfin — em 2026-08-24, no mesmo dia em que os pesos do Qwen3.8-Flash-Next foram publicados. A motivação ali era memória e latência: materializar os logits completos do alvo custa na ordem de tamanho do lote × (tokens especulativos + 1) × tamanho do vocabulário, e o sharding reduz essa alocação por um fator do grau de paralelismo de tensores, ao mesmo tempo que permite que o trabalho de top-k e top-p do amostrador seja executado em paralelo. É o passo que viabiliza, não o destino: o próprio texto do PR aponta os draft-logits fragmentados como trabalho futuro.

Por que três linhas era o trabalho inteiro

Aqui está o defeito real, e é um bom exemplo porque é invisível de fora do código. A implementação Qwen4Exp do vLLM é distribuída como duas classes. Qwen4ExpForConditionalGeneration é o wrapper de visão-linguagem — uma torre de visão Qwen3-VL acoplada ao modelo de linguagem — e Qwen4ExpForCausalLM é o caminho somente texto. O wrapper herda compute_logits_local de Qwen3_5ForConditionalGeneration, que encaminha a chamada para language_model.compute_logits_local. Mas a classe do modelo de linguagem para a qual o wrapper apontava nunca definiu esse método.

Então, os dois caminhos estavam em estados diferentes. Uma implantação de visão-linguagem do Qwen3.8-Flash-Next podia seguir o caminho fragmentado; uma apenas de texto não podia, porque o método ao qual o wrapper delegava não existia. A correção é um método, idêntico nas cópias NVIDIA e AMD do arquivo do modelo:

• O método retorna self.logits_processor(self.lm_head, hidden_states, skip_gather=True) — o fragmento de vocabulário do próprio rank, sem gather e sem materialização do vocabulário completo em nenhum rank.

• Segue o que o PR chama de “o mesmo padrão de 3 linhas de Qwen3.5 e MiniMax M3”, o que merece uma pausa para reflexão: duas outras famílias de modelos no mesmo repositório já tinham aderido. Qwen4Exp era simplesmente aquela que não o tinha feito.

O arquivo de teste é onde a honestidade do patch é mais fácil de verificar, e onde seus limites são mais fáceis de ver. Ele tem 57 linhas, é parametrizado sobre ambos os módulos NVIDIA e AMD, e não baixa um modelo. O helper constrói a classe com object.__new__, substitui nn.Identity pela cabeça do modelo de linguagem, e instala um processador de logits falso que retorna sua entrada mais um enquanto registra como foi chamado. O primeiro teste afirma que um 4.0 entrando sai como 5.0 e que a chamada registrada carregava skip_gather=True. O segundo envolve o modelo de linguagem na classe de geração condicional e afirma que a delegação chega. Isso é um teste real da fiação e um teste de nada mais — nenhum kernel é exercitado, nenhuma fronteira de rank é cruzada, e o número de GPUs envolvidas é zero.

Ambos esses fatos estão declarados no PR, em vez de ficarem enterrados. O próprio docstring do arquivo de teste chama o Qwen4Exp de "um minúsculo test double só de CPU". A seção de validação do autor observa que ele não conseguiu importar o modelo de jeito nenhum na sua configuração de macOS, porque a build do transformers que ele tinha não trazia um Qwen4ExpConfig. A execução em CUDA ainda estava pendente. O benchmark de ponta a ponta — dataset agêntico do MLPerf, 20 sessões concorrentes, três braços de 60 minutos — ainda estava pendente. O próprio caminho de logits do drafter de MTP está sinalizado como não verificado. O LoRA já é rejeitado pela flag no upstream, então está fora de escopo, e não é uma regressão. Há também uma linha divulgando que o rascunho foi escrito com assistência de IA, e o trailer do commit nomeia Claude Opus 5.5 como coautor, que é o tipo de divulgação que deveria ser normal numa stack desse tamanho e em geral não é.

A estimativa de 1,5%, e as medições ao lado das quais ela se encontra

A estimativa do contribuidor é um nsys trace em 16 sessões simultâneas no Qwen3.8-Flash-Next-FP8 com paralelismo de tensor 8 e paralelismo de especialistas em oito placas A100-SXM4-40GB: cerca de 1,6 milissegundos de um passo de 42 milissegundos, reduzido para aproximadamente um terço disso, para um ganho ponta a ponta de 1,5 a 2%. Sua manchete é a aritmética — 0,6 a 0,8 ms sobre 42 ms. Observe o que está anexado a isso: 42 ms é uma figura de latência entre tokens, então um corte de 1,7% é um corte de 1,7% no tempo de geração de tokens, não uma reivindicação de throughput no abstrato.

A comparação honesta é com os próprios números mesclados do recurso pai, porque eles foram medidos de ponta a ponta por alguém com o hardware. Nas execuções do Speed-Bench 2K/2K publicadas no PR #50465, a amostragem fragmentada por lote levou o DeepSeek V4 com DSpark, com 7 tokens especulativos e concorrência 64, de 2,62 para 2,66 solicitações por segundo — um ganho de throughput de 1,53% — com a latência mediana entre tokens caindo 3,09% e o tempo até o primeiro token subindo 1,45%. No MiniMax M3 com DSpark, com 8 tokens especulativos, o throughput de solicitações subiu 5,38% e a TPOT mediana caiu 8,33%, de 15,61 para 14,31 milissegundos. E o mesmo plano documenta onde isso não ajuda: com concorrência de 4 a 16, as execuções ficaram estáveis a levemente negativas, com o braço de concorrência 16 caindo 0,54% no throughput e 1,89% no comprimento de aceitação.

Esse padrão é a lição a se levar. A amostragem fragmentada compensa quando a amostragem é pesada e o lote é amplo — alta concorrência, muitos tokens especulativos, top-k e top-p fazendo trabalho de verdade — e custa um pouco quando o lote é pequeno o suficiente para que o all-to-all seja puro overhead. Uma estimativa de 1,5% para um modelo que opta por participar é consistente com isso, e não está em conflito com isso: os números de 5,38% e 8,33% pertencem a modelos diferentes com orçamentos especulativos diferentes, e o modelo neste PR tem sua própria configuração, seu próprio vocabulário de 248.320 tokens e seu próprio caminho de decodificação especulativa.

Nada disso é auditado. Os números do PR pai são execuções pareadas de um único contribuidor em um único nó; os números do smoke test aqui são um traço em hardware que o autor não possui, de uma revisão do patch que ele diz ter sido medida em apenas 16 sessões. Uma medição de um único contribuidor e de uma única configuração é um sinal útil sobre a direção e uma base ruim para um plano de capacidade. O motivo pelo qual vale a pena escrever sobre o assunto é a direção, não a casa decimal.

O que o cluster de patches ao redor diz sobre Qwen4Exp

Um PR em rascunho não seria uma história. A história é que o Qwen4Exp se tornou um alvo de serving sustentado na semana em que isto foi integrado, e o menor patch desse conjunto é o que torna o padrão legível. Nos sete dias até 2026-10-10, o vLLM trouxe, do mesmo contribuidor e de outros: um caminho de cache KV principal em FP8 para atenção esparsa em Ampere, com capacidade de KV 1,83× maior em oito A100s e 1,87× maior em quatro RTX 3090s e aproximadamente 2,7× mais requisições em concorrência 16, ao custo de cerca de 6% a mais de TPOT de decodificação em fluxo único; uma correção para o padding de MoE W4A4 em tensor-parallel 1 e paralelismo de especialistas; um caminho AMD que faz fallback de operações FP8 MoE do AITER não suportadas e atende em fp16; uma correção que propaga o estado de convolução curta do PLE pelo modo align; e um kernel de decodificação que desempacota bytes e4m3 quatro por vez por registrador em sm_80. Um deles, um reajuste do plano QSA LL-GEMM mesclado M=4 para H200, foi mesclado na main em 2026-10-09.

Leia essa lista como um todo e ela diz algo concreto. A arquitetura Qwen4Exp — aquela que o fornecedor não lançou — está sendo ajustada para Ampere, Hopper, ROCm e fallback fp16 simultaneamente, num projeto que entrega suporte desde o dia zero a modelos que as pessoas podem realmente baixar. O motivo não é misterioso: o Qwen3.8-Flash-Next é um modelo real, baixável e amplamente usado, e é construído sobre a arquitetura que o Qwen 4 vai usar. Se os pesos do Qwen 4 algum dia chegarão com esta cara é desconhecido e o fornecedor não disse nada, mas o envelope de serving está sendo ampliado em público, e isso é informação verificável de um jeito que uma janela especulada de outubro a novembro não é.

Parte da forma arquitetural também é pública, para quem lê a configuração em vez do anúncio. A configuração do Qwen3.8-Flash-Next lista um vocabulário de 248.320 tokens ao longo de 48 camadas, 512 especialistas com 10 roteados mais um partilhado ativo por token, com uma largura intermédia de especialista de 640, um tamanho oculto de 2.560 e um contexto nativo de 262.144 tokens descrito como extensível a um milhão. É um híbrido: a lista de tipos de camada alterna três blocos de atenção linear com um bloco de atenção completa, e os blocos de atenção completa usam o caminho de atenção esparsa com um indexador de uma cabeça que comprime as chaves por um fator de quatro e mantém um orçamento de 2.048 posições. Há uma tabela de embeddings por camada na camada 2, um embedding de n-gramas com um vocabulário de 20 milhões de entradas — essa é a tabela de 47,7 GiB que outros patches neste cluster estão ocupados a fazer host-staging — e uma cabeça MTP de uma camada para descodificação especulativa. O próprio resumo do cartão do modelo é "125B com 6B ativados, mais embedding de n-gramas de 51B e 4B de MTP." Um vocabulário de 248.320 entradas é o motivo pelo qual vale a pena fragmentar a projeção de logits desde o início.

O que isso não muda para você

Vale a pena ser exato, porque um conjunto de patches tão denso pode parecer um lançamento. Nada do que foi mencionado acima está mesclado, e uma parte disso — o trabalho de cache KV FP8 para Ampere — está explicitamente sem validação na CI, porque a CI do vLLM não tem nenhuma A100. Não há nenhuma versão lançada do vLLM que se possa instalar hoje que inclua o opt-in de amostragem fragmentada do Qwen4Exp. Não há nenhum benchmark independente do comportamento de serving do Qwen3.8-Flash-Next sob qualquer uma dessas mudanças; todos os números citados acima vêm das descrições dos PRs, o que os torna relatados por contribuidores e não auditados no sentido específico de que nenhum terceiro reproduziu a execução. E o número de destaque no PR que deu origem a este texto é 1,5%, o que é um ganho real em uma pilha de serving e não um motivo para mudar a escolha de um modelo.

O que mudaria uma decisão seria uma execução de serviço completa e auditada, e isso ainda não existe. As medições de ritmo que existem para o Qwen3.8-Flash-Next estão totalmente fora destes patches: o modelo alcança um Índice de Inteligência de 40 na Artificial Analysis, bem acima da mediana de 18 para modelos de pesos abertos de tamanho semelhante, e esse número é independente de tudo o que foi discutido aqui.

O que você pode chamar hoje, e o ângulo de roteamento

É aqui que a situação se torna prática para quem leu até aqui e quer usar um modelo hospedado em vez de instrumentar um. O Qwen3.8-Flash-Next não está no catálogo da OrcaRouter — não é um dos 205 modelos que roteamos, e não há endpoint hospedado para ele aqui. Mas o irmão de produção do qual ele é a prévia é: qwen/qwen3.8-flash, o lançamento oficial do Qwen3.8-Flash que o próprio model card do fornecedor descreve como trazendo mais recursos do que a prévia, incluindo um contexto de um milhão de tokens por padrão e ferramentas integradas, está disponível a $0,15 por milhão de tokens de entrada e $0,47 por milhão de tokens de saída, repassado pelo preço de tabela do provedor sem nenhuma margem adicionada. Para escala dentro da mesma família, qwen/qwen3.8-27b custa $0,33 e $2,40, e qwen/qwen3.8-max $2,00 e $6,00 — todos acessíveis com uma única chave.

Há duas razões que importam mais do que o habitual para um artigo sobre uma arquitetura não lançada. A primeira é o custo de troca. Se você quer calibrar como um modelo de atenção esparsa se comporta no seu tráfego antes de o Qwen 4 existir, a comparação que você quer fazer é com qwen/qwen3.8-flash a preço de tabela — e fazer isso por meio de um roteador significa que o modelo que você está medindo e o modelo para o qual você pode recorrer estão atrás do mesmo endpoint, do mesmo SDK e da mesma chave, sem um segundo contrato para assinar. A segunda é que toda mudança de serving neste conjunto de patches tem como alvo o vLLM auto-hospedado. Se você não está executando oito A100s, a capacidade de KV de 1,83× e o ganho de amostragem de 1,5% são coisas sobre as quais você lê, não coisas que você obtém. Um endpoint roteado é a versão disto que chega sem uma etapa de build: failover automático se um provedor apresentar degradação, e uma DSL de roteamento que permite colocar uma chamada hospedada ao lado de uma auto-hospedada em um único endpoint quando você tem hardware próprio para medir.

A única coisa a não fazer é ler este artigo como uma forma de esperar pelo Qwen 4. Não há data. Não há preço. Não há contagem de pesos do produto real — os números são da prévia, não do produto. O que existe é uma stack de serving pública para uma arquitetura que, por enquanto, só pode ser baixada em formato de prévia.

A versão curta

Três linhas que fecham uma lacuna entre os caminhos somente texto e visão-linguagem de um arquivo de modelo não são, por si só, notícia. É o tipo de patch que ficaria enterrado num commit de merge se alguém tivesse tempo de revê-lo, e bem pode acabar incorporado numa alteração maior ou fechado de vez — as próprias diretrizes de agente do bot do vLLM, citadas no PR, instruem contribuidores assistidos por IA a encerrar seu trabalho se ele não trouxer benefício significativo, e 1,5% é um número que convida a essa pergunta. O que o torna digno da sua atenção é aquilo que documenta: uma tabela de n-gramas com 20 milhões de entradas, um MoE de 512 especialistas com dez especialistas ativos por token, um híbrido de atenção linear e atenção esparsa comprimida, uma cabeça especulativa — tudo isso sendo ajustado em NVIDIA e AMD, de Ampere a Hopper, antes que exista o produto que o carrega. Se você se importa com o envelope de serving do Qwen4, os corpos dos PRs são onde atualmente vivem as suas especificações reais. Se você quer chamar um modelo hoje, o Qwen3.8-Flash é o que de fato está lá.

Uma API para mais de 200 modelos, failover automático, DSL de roteamento. Explore o catálogo de modelos do OrcaRouter