Qwen3.8-Flash-Next-Uncensored-NVFP4: Um Runbook de Serving para Blackwell

Qwen3.8-Flash-Next-Uncensored-NVFP4 roda em exatamente uma família de GPUs: Blackwell. NVFP4 executa em núcleos tensores FP4 de hardware, e Hopper (H100/H200) e qualquer coisa mais antiga simplesmente não os possuem. Se você estiver em Hopper, pare aqui — a versão Qwen3.8-Flash-Next-Uncensored-FP8 é a que você quer. Tudo abaixo pressupõe Blackwell (B100, B200, GB200, ou uma placa da série RTX 50), uma build recente do vLLM com suporte a qwen4_exp, e transformers ≥ 5.16.

Esta é a quantização NVFP4 da versão abliterada (com remoção de recusas) do Qw​en Qw​en/Qwen3.8-Flash-Next, reduzida de 330 GB em BF16 para 178 GB em disco. A OrcaRouter publicou-a no Hugging Face em 27 de agosto de 2026 como orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. O repositório tem acesso restrito: você precisa estar logado no Hugging Face e ter aceitado os termos do repositório, ou hf download e vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 ambos falham com um erro de autenticação antes que um byte seja transferido. Esta página é um runbook de serving, não uma cobertura de lançamento — a versão tem dois dias, e as perguntas que as pessoas realmente têm são hardware, flags e qual versão escolher.

E antes que os números comecem: Qwen3.8-Flash-Next-Uncensored não é Qwen3.8-27B-Uncensored. São dois modelos diferentes que compartilham um nome de família e uma técnica de abliteração — pesos base diferentes, arquiteturas diferentes, coleções Hugging Face diferentes. Flash-Next é abliterado a partir de Qw​en/Qwen3.8-Flash-Next, uma prévia de mistura de especialistas roteada da arquitetura Qwen4 (qwen4_exp): 512 especialistas, com dez roteados mais um compartilhado ativos, atenção híbrida (camadas lineares Gated DeltaNet junto com camadas de atenção completa), Hyper-Connections, um embedding PLE n-gram, uma torre nativa de visão e vídeo e uma cabeça de decodificação especulativa MTP. O 27B é abliterado a partir de Qw​en/Qwen3.8-27B, uma base densa totalmente diferente. Nada dos números de serving de uma página do 27B se transfere para este modelo; quando uma página do 27B é genuinamente útil — o guia introdutório de abliteração, a matemática geral de escolha de quantização — ela está linkada abaixo, com o que se transfere e o que não se transfere.

O que este build é, precisão por precisão

Qwen3.8-Flash-Next é um MoE roteado: cada token ativa 10 dos 512 especialistas, além de um especialista compartilhado, e apenas alguns bilhões de parâmetros ficam ativos por token, mesmo que o modelo armazenado seja muito maior. A versão NVFP4 é uma quantização compressed-tensors de precisão mista dessa pilha, e a divisão é o cerne de toda a história:

• Pesos dos especialistas MoE — NVFP4 (4 bits, NVIDIA FP4 E2M1, grupo de 16 com escalas de bloco FP8).

• Attention (self_attn.{q,k,v,o}), as projeções linear_attn, o expert compartilhado e lm_head — FP8 (8-bit).

• Embedding n-gram do PLE, embeddings de token e de visão, Hyper-Connections, o indexador QSA, Gated-DeltaNet conv/dt, todas as normas e toda a torre de visão — BF16, mantidos em precisão total.

Três propriedades da conversão importam mais do que a própria divisão de precisão. Primeiro, ela é apenas de pesos: as ativações são quantizadas dinamicamente em tempo de execução, não há calibração estática, e os pesos são derivados diretamente do checkpoint BF16 (a ficha do modelo chama a derivação de data-free). Segundo, a edição de abliteration está embutida nos pesos, então a remoção de recusas sobrevive à quantização — uma conversão de 4 bits é uma mudança de precisão, não uma intervenção de segurança. Terceiro, o cache KV não é quantizado; ele permanece em BF16 em tempo de execução. Esse último ponto é fácil de passar despercebido e importa no contexto nativo de 262.144 tokens do modelo, onde o cache KV é um item real de memória ao lado dos pesos.

O tamanho em disco é dominado por {{1}}um único tensor{{/1}}. A placa descreve {{2}}a incorporação PLE n-gram como um único tensor de ~66B de parâmetros mantido em BF16 por design{{/2}}; ele é {{3}}o maior shard{{/3}} e o motivo pelo qual o build tem {{4}}178 GB{{/4}} em vez de um número mais enxuto. Uma discrepância a sinalizar em vez de ignorar: {{5}}a placa irmã FP8 chama a mesma tabela de PLE n-gram de 51B de parâmetros{{/5}}, e a nota W4A4 desta placa se refere a ela como {{6}}~100 GB{{/6}}. {{7}}As duas placas apresentam números diferentes para a mesma tabela{{/7}}, então trate cada um como o número da sua respectiva placa — e ao dimensionar uma implantação, suponha que {{8}}a tabela é grande em BF16{{/8}} e planeje em torno disso.

A pré-condição de hardware, explicitada

Esta é a seção mais curta e mais importante da página. NVFP4 é um formato Blackwell: o caminho rápido é um GEMM FP4 nativo nos tensor cores de quinta geração, e sem esse hardware o formato não tem onde rodar. A linha de requisitos da própria placa é explícita — uma GPU Blackwell (B100 / B200 / GB200 / RTX 50-series), porque NVFP4 usa os tensor cores FP4 de hardware, e não rodará em Hopper (H100/H200) ou mais antigas, que não possuem computação FP4.

Os redirecionamentos, em um só lugar:

• No Hopper (H100/H200) — sirva Qwen3.8-Flash-Next-Uncensored-FP8 em vez disso. São os mesmos pesos em 8 bits, roda em Hopper e Blackwell, e é a versão que o manual de FP8 deste blog cobre.

• Em uma GPU NVIDIA de consumo ou uma máquina com CPU — o build GGUF, com seus 13 quants llama.cpp, é o caminho local.

• No Apple Silicon — a compilação MLX, em níveis de 4/6/8 bits, é o caminho nativo do Metal.

O requisito de runtime é tão vinculante quanto o silício. qwen4_exp é uma arquitetura totalmente nova, portanto, builds de vLLM padrão que a precedem se recusarão a carregar o checkpoint. Você precisa de um vLLM recente com suporte a qwen4_exp, além do leitor de tensores comprimidos NVFP4 (o formato é detectado a partir do config.json, não selecionado manualmente), e transformers ≥ 5.16. A entrada multimodal requer adicionalmente a pilha de visão Qw​en do runtime; a execução somente com texto funciona sem ela.

O comando serve do cartão, flag por flag.

A invocação do próprio model card é um bom ponto de partida, e vale a pena entender para que serve cada flag em vez de copiar e colar cegamente:

vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 --tensor-parallel-size 4 --trust-remote-code --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

• --tensor-parallel-size 4 — os pesos têm ~178 GB em disco, então a placa os divide entre quatro GPUs. Este é o formato para o qual o build foi dimensionado; não interprete isso como uma sugestão.

• --trust-remote-code — necessário para uma arquitetura personalizada. O código de modelagem do qwen4_exp ainda não está no registro padrão do transformers, então o vLLM carrega o código da arquitetura do repositório. Você está confiando nesse código, o que é uma decisão normal, porém real, para uma arquitetura totalmente nova.

• --enable-expert-parallel — distribui os especialistas entre os ranks tensor-paralelos em vez de replicá-los, o que torna um MoE de 512 especialistas viável em TP4. O card irmão FP8 indica o motivo mais preciso nessa build: sem ele, a largura intermediária do MoE dividida por TP não é divisível pelo tamanho de bloco FP8. Trate-o como obrigatório, não opcional.

• --enable-auto-tool-choice e --tool-call-parser qwen3_coder — juntos, eles ativam a chamada de função. A flag auto permite que o modelo decida se deve chamar uma ferramenta, e o parser qwen3_coder decodifica o formato de chamada de ferramenta, a mesma família de parsers usada por Qwen3.8-27B e Qwen3.8-Flash-Next.

Depois que estiver no ar, o endpoint compatível com OpenAI em /v1/chat/completions carrega todo o conjunto de recursos através da stack Qwen4 do runtime: chamada de ferramentas como acima, raciocínio via chat_template_kwargs.enable_thinking e visão por meio de partes de conteúdo image_url. Você não precisa de um servidor separado para multimodal; é o mesmo endpoint.

Uma nota estrutural do card: não existe uma variante W4A4 totalmente estática deste build, e não haverá uma a baixo custo. Uma conversão W4A4 estática exige um forward pass de calibração de ativações, e essa etapa precisa manter o embedding de n-gramas de ~100 GB em uma única GPU. Essa é a mesma razão pela qual a tabela PLE domina a listagem de arquivos, e é por isso que este build permanece somente com pesos e ativações dinâmicas.

Relatos de campo da comunidade — como é, na prática, servir isso

Não há números de throughput ou latência publicados para este repositório exato, e esta página não os inventará. O que existe é um conjunto crescente de relatos de campo de profissionais que servem os builds base Qwen3.8-Flash-Next NVFP4 — a mesma arquitetura, a mesma divisão de precisão NVFP4/FP8/BF16, menos a edição de abliteração — e o comportamento de serving se transfere diretamente. Estas são descobertas da comunidade, não orientações do fornecedor, e as pessoas que fizeram esses relatos estavam em hardware Blackwell com o mesmo esquema de quantização.

• A decodificação especulativa com MTP é a maior alavanca de desempenho. O modelo vem com uma cabeça de draft de previsão de múltiplos tokens e, em uma RTX PRO 6000 (96 GB, SM120), o módulo MTP é carregado quantizado em NVFP4, ocupando cerca de 0,51 GB de VRAM — o relatório mediu um comprimento de aceitação de 2,3–3,9 de um máximo de 4 e uma taxa de aceitação de 0,86–0,96. O mesmo relatório mediu uma decodificação mediana de fluxo único de 180–226 tok/s (216,9 em codificação, 225,8 em uma carga de trabalho de chamada de ferramenta de agente, 136,6 em raciocínio) contra uma linha de base de aproximadamente 105 tok/s, e respondeu a um prompt de 216.685 tokens em 8,4 segundos. Trate os números como a configuração de uma pessoa, não como uma especificação.

• Descarregue o embedding de n-gramas do PLE para a RAM do host. Como a tabela é enorme e raramente é o gargalo de throughput, as receitas da comunidade em placas Blackwell individuais fixam-na no host (~50 GiB de RAM livre do host no relatório do RTX PRO 6000) e a mapeiam via mmap a partir do NVMe, trocando um pouco de latência para conseguir fazer o modelo caber. Espere fazer algo assim, a menos que você tenha um orçamento de VRAM muito grande.

• Fixe a janela de contexto explicitamente.Com o cache KV em BF16 e MTP ativo, um pool KV de tamanho automático cresceu além do que a placa suportava e causou OOM em prefill longo; fixar max-model-len / max-total-tokens em 262144 restaurou a margem. Em contexto de 262K, o cache KV é um item que você precisa orçar, não um padrão.

• Um bug de autotune do FlashInfer corrompe silenciosamente a saída. O modo de falha mais importante no campo: o autotune seleciona táticas de kernel MoE fundido apenas pela latência e nunca verifica a precisão numérica, então sob certas formas, a decodificação colapsa em um token repetido. O relatório do RTX PRO 6000 reproduziu isso como 36 de 36 gerações corrompidas com o autotune ativado, e 0 de 36 com ele desativado — a solução é desabilitar o autotune do FlashInfer (no vLLM, --no-enable-flashinfer-autotune; no SGLang, --disable-flashinfer-autotune). Se a sua saída servida de repente degenerar, verifique isso antes de tocar em qualquer outra coisa.

• O DGX Spark (GB10, SM121) precisa de seus próprios patches. Os pesos NVFP4 (~126 GiB na build da comunidade) não cabem em um único Spark de 128 GB, então as receitas do SGLang executam tensor-parallel 2 em dois nós via RoCE, e o resolvedor de decodificação esparsa QSA condiciona o kernel FlashInfer rápido a uma verificação is_sm100_supported() que falha no SM121, caindo em um caminho que morre no warmup — a correção é um pequeno patch mais offload de PLE. Espere cerca de 47–50 tok/s de decodificação, chegando perto de 70 com MTP4 e CUDA graphs, e verifique se seu kernel realmente roda no SM121 antes de prometer um benchmark.

Raciocínio, chamada de ferramentas e visão através da stack Qwen4

O consenso da comunidade sobre a geração Qwen3.8 se aplica a este modelo, com a ressalva usual de que se trata de prática de campo, não de orientação do fornecedor.

• reasoning_effort é o controle que mais importa. O template de chat usa xhigh por padrão, o que faz o modelo pensar longamente em cada solicitação. Operadores de agent-loop definem medium por padrão e reduzem para low em chamadas sensíveis à latência; enable_thinking false desativa o raciocínio por completo quando você não precisa dele. Em uma única placa Blackwell, deixar xhigh ativado em chamadas rotineiras faz com que um modelo rápido produza respostas lentas.

• Emparelhe amostradores com o modo de pensamento. Praticantes convergem para temperatura 1,0 / top-p 0,95 quando o modo de pensamento está ativado, e temperatura 0,7 / top-p 0,80 com penalidade de presença em torno de 1,5 quando está desativado. Misturar os dois conjuntos degrada a qualidade da saída.

• A chamada de ferramentas sobrevive tanto à abliteração quanto à conversão de 4 bits. O caminho de chamada de função está intacto, que é o que os sinalizadores do parser qwen3_coder e de auto-tool-choice configuram. Para um red team, isso é uma faca de dois gumes, pois significa que o uso indevido agêntico está totalmente operacional em um modelo não alinhado — abordado abaixo.

• A visão é preservada, e isso amplia a superfície de ataque. A torre de visão nunca foi tocada pela abliteração e permanece em BF16, então a entrada de imagens funciona através das partes de conteúdo do image_url. Profissionais que avaliam a linha não censurada tratam o caminho multimodal como um alvo de avaliação de primeira classe: a injeção de prompt carregada em uma imagem atinge um modelo sem comportamento de recusa para enfrentar.

Qual build você deve servir?

A coleção Flash-Next tem cinco builds — BF16, GGUF, MLX, FP8 e este NVFP4 — e a lógica honesta de escolha é sobre hardware e trade-offs, não um ranking.

• NVFP4 (esta versão, ~178 GB em disco) — a escolha para Blackwell. Núcleos tensoriais FP4, especialistas de 4 bits, a versão mais recente da coleção e a menor das suas versões de servidor vLLM, e é sobre ela que esta página trata.

• FP8 (~186 GB em disco) — a escolha para Hopper, e igualmente à vontade em Blackwell. Os mesmos pesos em 8 bits, que é o caminho vLLM mais amplamente verificado e o que tem o requisito de paralelismo de especialistas mais claro.

• GGUF (13 quants, de IQ2_XXS ~52 GB a Q5_K_M ~125 GB) — a escolha do llama.cpp para máquinas de consumo com NVIDIA, AMD ou CPU. Não é preciso Blackwell, nem vLLM.

• MLX (níveis de 4/6/8 bits, aproximadamente 163–221 GB) — a escolha para Apple Silicon, Metal nativo, cabeça MTP incluída.

Duas observações honestas antes de você escolher. Primeiro, as versões NVFP4 e FP8 têm apenas cerca de oito GB de diferença em disco, porque ambas mantêm a grande tabela de n-gramas em BF16 — a economia de 4 bits está concentrada nos pesos dos especialistas, não no espaço total ocupado. A verdadeira vantagem do NVFP4 em Blackwell é a velocidade do FP4-tensor-core nesses especialistas, não um arquivo dramaticamente menor. Segundo, a ficha descreve o NVFP4 como uma derivação determinística de pesos que herda a avaliação de abliteration com um pequeno trade-off adicional de qualidade dos especialistas de 4 bits, e ela não quantifica esse trade-off. Esse trade-off não é quantificado — trate-o como um custo real, porém não especificado, dos especialistas menores, não como desprezível.

A avaliação, lida corretamente

O card relata abliteration medida na compilação BF16 servida com vLLM contra o Qw​en/Qwen3.8-Flash-Next oficial: a recusa de prompts prejudiciais caindo de 64–100% para cerca de 0–3,3%, a recusa excessiva de prompts benignos permanecendo perto de zero e a capacidade dentro de ±2 pontos da base. Há três coisas a acertar sobre esses números. São medições na compilação BF16, herdadas por esta compilação de 4 bits por argumento, em vez de medidas nela. São números do próprio fornecedor, produzidos com um classificador de frase de abertura baseado em regras que os cards da coleção descrevem como indicativos, e não como de qualidade de publicação — uma medição interna da própria edição, não uma auditoria independente. E eles não dizem nada sobre o trade-off de qualidade do NVFP4 acima, que o card não quantifica.

A fronteira de segurança — apenas para pesquisa

O aviso da ficha do modelo é direto, e é a parte desta página que não deve soar como texto genérico. Este modelo teve seu alinhamento de segurança substancialmente removido: a direção de recusa foi ortogonalizada do fluxo residual, e o modelo atenderá a solicitações prejudiciais, antiéticas ou ilegais que o Qwen3.8-Flash-Next original recusaria. Ele é lançado estritamente para pesquisa legítima — interpretabilidade, estudo de segurança de IA e mecanismos de recusa, red-teaming e avaliação de robustez — e os autores não assumem responsabilidade por uso indevido. Você assume total responsabilidade pelo que ele gera e adiciona suas próprias camadas de segurança e moderação antes que qualquer coisa alcance um usuário. Apache 2.0 é o mínimo; a restrição de finalidade de pesquisa está acima disso.

Duas coisas que o discurso sobre modelos sem censura erra, e este card torna impossível não notá-las. Primeiro, uma sonda de jailbreak que tem sucesso contra este modelo não é uma avaliação de segurança aprovada — é o comportamento anunciado. Um modelo abliterado falha nessas sondas de propósito; medi-lo com um único teste "você consegue fazer jailbreak" é medir que a edição funcionou, não que uma salvaguarda é forte. Segundo, a torre de visão preservada e o caminho de chamada de ferramentas intacto ampliam a superfície de ataque real para além do texto: injeção de prompt por imagem e uso indevido de ferramentas agênticas estão ambos totalmente operacionais, e é exatamente por isso que o enquadramento de red team trata isso como uma sonda de capacidade, não como um candidato a chatbot. Se o seu caso de uso é lançar um assistente voltado ao usuário, este não é o seu modelo, e isso é por design.

Onde o OrcaRouter se encaixa

Uma build de dois dias, fechada e apenas self-host é o caso clássico para roteamento em vez de ligação direta. Quando você mesmo executa esta build NVFP4, pode montar uma rota que aponta para ela e faz failover para um modelo hospedado se a build se comportar mal sob carga — uma única interface, sem religação entre provedores quando você troca. Especificamente para trabalho de avaliação, a baseline servida censurada é a comparação que você quer, e está a um clique de distância: o catálogo traz o Qwen3.8-Flash da Ali​baba a US$ 0,15 por milhão de entrada e US$ 0,47 por milhão de saída, repassado ao preço de tabela do provedor com margem de 0%, então um harness de red-team pode circular entre a base censurada hospedada e a sua build local não censurada sem um segundo contrato, e qualquer mudança de preço do fornecedor chega ao seu endpoint no mesmo dia.

Quem deve baixar isto — e quem não deve

Baixe orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 se você estiver em Blackwell, quiser a menor pegada de servidor na coleção Flash-Next com velocidade FP4-tensor-core e estiver fazendo o trabalho de pesquisa para o qual esta linha existe. Baixe Qwen3.8-Flash-Next-Uncensored-FP8 se você estiver em Hopper ou quiser o caminho mais amplamente verificado. Baixe a versão GGUF se você estiver em uma GPU de consumidor ou em uma máquina com CPU, a versão MLX se estiver em Apple Silicon, e não baixe nada se o objetivo for uma implantação voltada para o usuário. Leia o gate e o aviso legal antes de aceitar qualquer um deles — eles são os termos do modelo, não uma formalidade.

Todos os cinco builds Flash-Next — BF16, GGUF, MLX, FP8 e NVFP4 — estão reunidos na coleção Qwen3.8-Flash-Next-Uncensored no Hugging Face.

Um modelo diferente, não outra versão deste: Qwen3.8-27B-Uncensored é abliterado de uma base diferente e tem sua própria coleção e seus próprios runbooks.

Estes pesos são exclusivamente locais por design. Para servir como referência hospedada contra a qual medir a versão abliterada, o Qwen3.8-Flash é servido no OrcaRouter a preço de tabela do provedor com margem de 0% — o modelo padrão, com o alinhamento de segurança intacto.