Qwen3.8-Flash-Next localmente: o que significam realmente os 6 mil milhões de parâmetros ativos para a RAM, a VRAM e o NVMe

Não, o Qwen3.8-Flash-Next não cabe na memória como um modelo de 6B apenas porque ativa cerca de 6B de parâmetros por token. A Qwen descreve um modelo principal de 125B de parâmetros com 6B de parâmetros ativados, além de 51B de embeddings de n-gramas e um componente MTP de aproximadamente 4B. O repositório oficial do Qwen3.8-Flash-Next tem atualmente cerca de 360 GB na versão BF16 disponibilizada. As conversões comunitárias para GGUF podem reduzir esse tamanho drasticamente, mas não transformam o Flash-Next num modelo convencional de 6B.

A forma útil de pensar na implementação local é como uma hierarquia de memória. A VRAM determina quanto da execução do modelo a alta velocidade pode permanecer na GPU. A RAM do sistema fornece capacidade para componentes residentes no CPU e componentes transferidos, incluindo a tabela de n-gramas invulgarmente grande que a Qwen concebeu explicitamente para funcionar a partir da memória do sistema. A NVMe fornece armazenamento local rápido e suporte através de mapeamento de memória para ficheiros próximos ou superiores a 100 GB, mas não substitui a RAM nem a VRAM. A verdadeira questão é, portanto, o que o valor de 6B ativos retira à exigência de hardware — e o que não retira.

6B ativos significam que o Qwen3.8-Flash-Next precisa apenas de memória para um modelo de 6B?

Não. Os parâmetros ativados descrevem o cálculo por token, não a quantidade total de estado do modelo existente. Esta distinção é especialmente importante no Qwen3.8-Flash-Next, porque a diferença entre a contagem de parâmetros ativos e a contagem de parâmetros armazenados é invulgarmente grande.

De acordo com o cartão oficial do modelo Qwen3.8-Flash-Next, o modelo de linguagem contém 125B de parâmetros, com aproximadamente 6B ativados para cada token, além de 51B de parâmetros de embeddings de n-gramas e cerca de 4B de parâmetros associados ao MTP. O MoE principal contém 512 especialistas encaminhados e seleciona 10 especialistas encaminhados, além de um especialista partilhado, para cada token.

O que produz três números diferentes que não devem ser misturados:

O ponto essencial é que os especialistas inativos não deixam de existir. Tokens diferentes podem ser encaminhados para especialistas diferentes, pelo que o sistema de execução continua a precisar de acesso ao conjunto mais amplo de pesos, embora apenas uma pequena fração participe na passagem direta de um determinado token. Esta é a razão geral pela qual outros modelos MoE de grandes dimensões podem ter uma computação ativa relativamente modesta, mantendo simultaneamente requisitos de memória muito elevados, uma distinção que também é importante na nossa análise do hardware local do GLM-5.3-Flash.

O Flash-Next acrescenta outra particularidade. A sua tabela de embeddings de n-gramas de 51B não é utilizada como uma matriz normal de pesos de uma rede neuronal densa. Na visão geral oficial da arquitetura Flash-Next da Qwen, a equipa explica que as localizações das consultas de n-gramas podem ser determinadas antecipadamente. Assim, a tabela pode permanecer na memória do sistema anfitrião e ser pré-obtida de forma assíncrona enquanto outros cálculos do modelo estão em execução.

É por isso que o número de 6B ativos é relevante, embora não represente um requisito de memória. O Flash-Next foi concebido para separar a capacidade do modelo da computação por token de forma mais acentuada do que um modelo denso convencional. Para inferência local, isso desloca a questão do hardware de um único número de VRAM para a eficiência com que a VRAM, a RAM do sistema e o armazenamento conseguem trabalhar em conjunto.

Qual é o tamanho do Qwen3.8-Flash-Next após a quantização?

A versão oficial BF16 tem aproximadamente 360 GB, o que coloca imediatamente uma implementação não quantizada totalmente residente fora do alcance do hardware de desktop comum. A quantização altera substancialmente esta situação.

Em 1 de setembro de 2026, as atuais versões Flash-Next GGUF da Unsloth variam entre versões de poucos bits extremamente agressivas e variantes de maior qualidade bastante maiores. Dois pontos de referência úteis são a versão UD-IQ4_XS, com aproximadamente 93,7 GB, e a versão UD-Q4_K_XL, com aproximadamente 111 GB.

Estes tamanhos de GGUF são conversões da comunidade, não recomendações oficiais mínimas de RAM ou VRAM da Qwen. Ainda assim, são úteis para o planeamento da capacidade, porque mostram a dimensão do problema antes de adicionar buffers de execução, estado do contexto, processamento de visão, o sistema operativo e outras aplicações.

Por exemplo, um ficheiro de modelo de 94 GB não implica que uma máquina com exatamente 96 GB de memória combinada proporcione uma implementação confortável. O motor de execução ainda precisa de espaço de trabalho, e a quantidade de memória adicional necessária varia consoante o comprimento do contexto, o backend, o formato da cache, a estratégia de descarregamento para a GPU e a concorrência.

De quanta VRAM precisa o Qwen3.8-Flash-Next?

Não existe um único valor útil de «VRAM mínima» para o Flash-Next, porque a inferência local pode variar entre uma execução quase totalmente residente na CPU e um modelo distribuído por uma ou mais GPUs. A VRAM determina sobretudo quanta carga de inferência de elevada largura de banda pode permanecer na GPU e, por conseguinte, a velocidade de execução do sistema.

Uma GPU para consumidores com 24 GB ou 32 GB não consegue conter, por si só, um GGUF atual de quatro bits com 94–111 GB. Isso não significa necessariamente que a GPU seja inútil. Um motor de execução capaz de fazer descarregamento parcial para a GPU pode manter tensores ou camadas selecionados na VRAM, enquanto a RAM do sistema contém o restante.

As opções atuais de carregamento de modelos do llama.cpp incluem a colocação de camadas na GPU, a seleção explícita de dispositivos, substituições de tensores e controlos de MoE na CPU. Isso significa que «a minha GPU consegue executá-lo?» e «a minha GPU consegue conter o modelo inteiro?» são perguntas diferentes.

A diferença de desempenho entre estas configurações pode ser enorme, mesmo quando todas conseguem tecnicamente carregar o modelo. A largura de banda da memória da GPU é significativamente superior à da memória normal do sistema, e transferir uma grande parte da computação ativa de volta para a CPU pode transformar um modelo local que, de outro modo, seria impressionante, em algo mais adequado para experimentação do que para o trabalho interativo com agentes.

Para o Flash-Next, a VRAM deve, por isso, ser tratada como uma alocação de desempenho, e não como um número binário de compatibilidade.

De Quanta RAM Precisa o Qwen3.8-Flash-Next para o Descarregamento entre CPU e GPU?

A RAM do sistema é, discutivelmente, mais importante para o Flash-Next do que sugere o destaque dos «6B ativos». Uma máquina com uma GPU de consumidor, mas muito pouca RAM, não tem onde colocar de forma útil a grande quantidade de estado do modelo que não cabe na VRAM.

A incorporação de n-gramas torna isto particularmente interessante. A Qwen afirma que a tabela de 51B pode ser colocada na memória do anfitrião, pois os seus acessos são determinísticos e podem ser pré-obtidos. Quando a implementação do Flash-Next foi integrada no llama.cpp a 27 de agosto, as notas da implementação descreviam a tabela de incorporação de n-gramas por camada como tendo aproximadamente 97,7 GiB em BF16 e tratavam da pesquisa das linhas a partir do lado do anfitrião.

Isto não significa que todas as implementações locais precisem permanentemente de mais 97,7 GiB não quantizados além de um GGUF quantizado. A quantização e a representação em tempo de execução são importantes. Isto demonstra, contudo, por que razão a arquitetura foi concebida em torno de memória heterogénea, em vez de presumir que todos os parâmetros têm de permanecer na memória da GPU.

Para uma inferência prática com GGUF, a memória do sistema deve ser planeada com base no tamanho real do modelo quantizado, acrescido da margem necessária para o sistema operativo e a execução. Com uma quantização de cerca de 94 GB, 128 GB de RAM constituem um alvo de capacidade experimental plausível, mas não são generosos quando se incluem o sistema operativo, o contexto, os buffers e o comportamento da alocação entre a GPU e o anfitrião. Um sistema com 192 GB ou 256 GB proporciona uma margem muito mais segura para uma inferência híbrida séria.

Este é um dos exemplos mais claros de por que razão a memória da IA local está a tornar-se uma hierarquia, em vez de uma única especificação de VRAM. A memória da GPU trata do trabalho mais sensível à largura de banda, a memória do anfitrião expande a capacidade dos modelos e o armazenamento fornece os dados persistentes dos modelos por baixo de ambas.

A transferência para um SSD NVMe pode tornar o Qwen3.8-Flash-Next prático?

O NVMe pode tornar mais fácil armazenar e carregar um modelo demasiado grande, mas não transforma a capacidade do SSD em memória de inferência rápida. Essa distinção é cada vez mais importante à medida que os modelos locais ultrapassam os 100 GB.

Uma unidade NVMe rápida é útil para armazenar várias variantes GGUF, carregar um modelo grande sem esperar pelo armazenamento de rede ou pelo disco rígido mais lento e suportar o acesso a modelos mapeados na memória. O llama.cpp utiliza o mapeamento de memória como modo de carregamento de modelos, permitindo mapear as páginas do modelo a partir de um ficheiro, em vez de exigir que o ficheiro inteiro seja copiado para uma alocação de RAM separada no arranque.

No entanto, a documentação do llama.cpp sobre o carregamento de memória também explica por que razão isto não deve ser interpretado como transferência gratuita para o disco. Se o modelo em utilização exceder a RAM disponível, as paginações para o disco e os acessos repetidos ao armazenamento podem prejudicar o desempenho. O bloqueio de memória existe precisamente porque manter na RAM as páginas do modelo utilizadas com frequência pode ser importante.

Uma regra útil é: o NVMe pode tornar carregável um modelo demasiado grande; não o torna automaticamente interativo.

Isto também explica por que razão a arquitetura de armazenamento é cada vez mais importante para a IA local, mesmo quando o próprio dispositivo de armazenamento não está a executar inferência. Modelos, recursos de visão, índices RAG, conjuntos de dados, espaços de trabalho de agentes e vários checkpoints quantizados podem facilmente consumir centenas de gigabytes. O armazenamento local rápido está a tornar-se parte do sistema de IA, mas continua a ocupar um nível diferente da memória que alimenta a computação ativa.

Como é que um contexto de 262K altera os requisitos de memória?

O Qwen3.8-Flash-Next suporta nativamente um comprimento de contexto de 262 144 tokens e pode ser expandido para cerca de um milhão de tokens com YaRN. Isso não significa que todas as implementações locais devam configurar o contexto máximo por predefinição.

O modelo utiliza uma arquitetura híbrida, em vez de atenção total convencional em todas as camadas. A Gated DeltaNet comprime o histórico, enquanto a Qwen Sparse Attention utiliza um indexador para selecionar blocos de contexto relevantes. Isto foi concebido especificamente para reduzir a pressão computacional e de memória associada a sequências longas.

Um contexto longo também não é gratuito. A memória do ambiente de execução pode incluir o estado recorrente, caches de atenção esparsa, o estado do indexador, buffers temporários de computação, entradas de visão, sobrecarga de processamento em lotes e alocações específicas do backend. A curva exata de memória depende, portanto, do motor de inferência, em vez de ser determinada apenas pelo tamanho do ficheiro GGUF.

Existe também uma diferença entre o limite de contexto arquitetural de um modelo e o nível atual de maturidade da implementação num ambiente de execução. Em 1 de setembro de 2026, o suporte do llama.cpp à nova arquitetura tem apenas alguns dias. Um problema atual do CUDA com contexto de 262K relata uma falha no lançamento do kernel exatamente com 262 144 tokens, enquanto 261 888 tokens funcionam no sistema de teste. O relatório identifica isto como uma limitação do kernel, e não como esgotamento da VRAM.

Esse problema específico pode ser corrigido rapidamente, mas ilustra um ponto mais abrangente: 262K é uma capacidade do modelo, não uma garantia de que todas as GPU atuais e todos os backends de inferência conseguem utilizar eficientemente toda a janela hoje.

Para uma implementação local, comece pelo comprimento de contexto de que a carga de trabalho realmente necessita. Uma sessão de programação, uma tarefa de análise de documentos ou um fluxo de trabalho RAG privado que caiba em 16K, 32K ou 64K não se torna melhor simplesmente porque o ambiente de execução reserva centenas de milhares de tokens.

Que hardware consegue realmente executar o Qwen3.8-Flash-Next localmente?

A resposta sobre o hardware mais adequado depende do que significa «executar». Carregar um modelo fortemente quantizado e gerar tokens é um objetivo. Manter um desempenho interativo, um contexto grande, entradas de visão e cargas de trabalho de agentes é um objetivo muito mais exigente.

A tabela abaixo é, portanto, um guia de planeamento baseado nos tamanhos atuais dos modelos e dos GGUF — não uma recomendação oficial de hardware da Qwen.

A linha divisória mais importante não é um modelo específico de GPU. É saber se a máquina tem capacidade suficiente de memória rápida combinada para manter a paginação do armazenamento fora do percurso crítico da geração.

Uma GPU de 24 GB emparelhada com 192 GB de memória rápida do sistema pode proporcionar uma experiência com o Flash-Next mais credível do que uma GPU de 24 GB emparelhada com apenas 32 ou 64 GB de RAM. Inversamente, adicionar uma grande quantidade de RAM não torna a inferência dependente da CPU equivalente à execução dos mesmos tensores em memória da GPU de elevada largura de banda.

Para a maioria dos utilizadores comuns de computadores de secretária interessados na família Qwen3.8, e não especificamente nesta arquitetura, o Qwen3.8-27B é o alvo local mais convencional. O Flash-Next faz mais sentido para utilizadores que querem deliberadamente experimentar um modelo esparso muito maior, memória heterogénea, uma arquitetura de contexto longo ou a tecnologia que a Qwen afirma antecipar a direção do Qwen4.

Vale a pena executar o Qwen3.8-Flash-Next localmente?

Sim, para a estação de trabalho certa e pelo motivo certo — mas não porque «6B ativos» faça subitamente com que uma versão com cerca de 180 mil milhões de parâmetros se comporte como um modelo pequeno de computador de secretária.

O Flash-Next é especialmente interessante se tiver 128–256 GB de memória do sistema ou unificada, aceleração significativa por GPU, armazenamento NVMe rápido e uma razão para experimentar cargas de trabalho locais de programação, multimodais, de escritório ou de agentes de grande dimensão. A sua arquitetura é particularmente relevante para a IA local porque separa deliberadamente os parâmetros calculados com frequência das estruturas orientadas para grande capacidade, que podem residir fora da memória da GPU.

É uma opção muito menos adequada para um PC normal com 32–64 GB de RAM, cujo plano dependa de o sistema operativo ir constantemente buscar ao SSD as páginas do modelo em falta. Uma máquina destas pode demonstrar que o modelo consegue arrancar tecnicamente, mas «carrega com sucesso» e «funciona de forma útil» são critérios diferentes.

A lição mais abrangente estende-se para além deste modelo. O hardware de IA local tem cada vez menos que ver com pedir um único valor mínimo de VRAM e mais com conceber uma hierarquia: VRAM para computação de alta velocidade, RAM para capacidade acessível do modelo e NVMe para armazenamento local persistente do modelo e dos dados. O Qwen3.8-Flash-Next torna essa transição particularmente evidente.

Perguntas frequentes: requisitos de hardware local do Qwen3.8-Flash-Next

O Qwen3.8-Flash-Next consegue ser executado numa RTX 4090 ou numa RTX 5090?

Sim, essas GPUs podem participar numa implementação local híbrida, mas nem uma RTX 4090 de 24 GB nem uma RTX 5090 de 32 GB consegue conter inteiramente na VRAM uma GGUF atual do Flash-Next de quatro bits, com cerca de 94–111 GB. Seria necessária uma quantidade substancial de RAM do sistema e offload para a CPU/GPU. A GPU pode ainda acelerar a parte do modelo nela colocada, pelo que isto é muito diferente de dizer que as placas não podem ser utilizadas.

O Qwen3.8-Flash-Next consegue ser executado com 64 GB de RAM?

64 GB de RAM do sistema ficam abaixo do tamanho das atuais compilações GGUF práticas mais pequenas de quatro bits. O mapeamento na memória pode permitir o acesso a partes de um ficheiro demasiado grande a partir do armazenamento, mas a paginação repetida provavelmente tornará a inferência lenta e instável como carga de trabalho interativa. Para uma implementação local séria, 64 GB não deve ser considerado um objetivo prático.

128 GB de RAM são suficientes para o Qwen3.8-Flash-Next?

128 GB é um ponto de partida plausível para uma das compilações GGUF de cerca de quatro bits mais pequenas, quando combinado com offload para a GPU e uma janela de contexto moderada. Não é uma recomendação universal confortável. Um modelo de cerca de 94 GB deixa muito menos de 34 GB para o sistema operativo, buffers do runtime, estado do contexto, processamento de visão e outros serviços, pelo que 192 GB ou mais proporciona uma margem consideravelmente melhor.

O Qwen3.8-Flash-Next consegue ser executado inteiramente a partir de um SSD NVMe?

Um runtime pode mapear na memória os ficheiros do modelo armazenados num NVMe, e o sistema operativo pode carregar as páginas à medida que são necessárias. Isso não equivale a executar o modelo “a partir do SSD” às velocidades da RAM ou da GPU. O NVMe é excelente para armazenar e carregar modelos, mas depender continuamente dele porque a memória física se esgotou pode reduzir drasticamente o desempenho da geração.

O facto de ter 6B de parâmetros ativos significa que o Qwen3.8-Flash-Next é tão rápido como um modelo de 6B?

Não. O valor de 6B descreve o número aproximado de parâmetros ativados do modelo principal para cada token. O Flash-Next continua a ter uma arquitetura muito maior, lógica de encaminhamento, tráfego de memória, pesquisa de n-gramas, estado de atenção esparsa e outras tarefas de execução. Um número menor de parâmetros ativados pode reduzir significativamente a computação, mas não torna o sistema completo equivalente a um modelo denso de 6B.

O Ollama ou o llama.cpp conseguem executar o Qwen3.8-Flash-Next localmente?

suporte do llama.cpp para o Qwen3.8-Flash-Next qwen4exp a arquitetura foi integrada no master em 27 de agosto de 2026, um dia após o lançamento do modelo. Os repositórios comunitários atuais de GGUF também disponibilizam compilações destinadas a fluxos de inferência local baseados no llama.cpp. Como a implementação ainda é muito recente, consulte as versões atuais dos runtimes e as instruções do modelo antes de assumir que todos os backends de GPU, comprimentos de contexto, vias de visão ou configurações de offload têm o mesmo nível de maturidade.