Qwen3.8-27B-Uncensored-NVFP4: Um Runbook de Serviço para GPUs Blackwell

Qwen3.8-27B-Uncensored-NVFP4 está no Hugging Face desde 19 de agosto de 2026 e, nos dez dias desde então, foi baixado aproximadamente 32.700 vezes. Isto não é uma cobertura de lançamento — os pesos têm dez dias, não há anúncio a relatar, e os builds irmãos Qwen3.8-27B-Uncensored-FP8 e Qwen3.8-27B-Uncensored-GGUF já estão documentados neste blog. É um runbook para um build que as pessoas estão baixando ativamente agora: o que é NVFP4 na verdade, por que este build específico o mistura com FP8, quais GPUs se beneficiam e quais não, como servi-lo, e quem deve escolhê-lo em vez dos builds FP8 ou GGUF — e quem não deve.

Uma coisa de antemão: isso atrapalha todo usuário que baixa pela primeira vez, pois o repositório é restrito. O simples hf download orcarouter/Qwen3.8-27B-Uncensored-NVFP4 comando de uma linha falha com erro de autenticação até você estar logado no Hugging Face e ter aceitado os termos de acesso do repositório na página do modelo. Tudo abaixo pressupõe que você fez ambas as coisas.

Também desde já: o model card deste repositório está atrás do mesmo controle de acesso, então nada aqui o parafraseia. O que se segue está ancorado na listagem pública de arquivos e nos metadados do repositório, na documentação pública da NVIDIA sobre NVFP4 e em relatos de campo de pessoas que servem builds NVFP4 do Qwen3.8-27B em Blackwell. Quando um número vem de um profissional de campo em vez do fornecedor, o texto diz isso.

O que é este build

Qwen3.8-27B-Uncensored-NVFP4 é a quantização NVFP4 do Qwen3.8-27B-Uncensored, a versão abliterada da Ali​baba do Qw​en/Qwen3.8-27B que a organização orcarouter publicou em 2026-08-18. A abliteração remove do fluxo residual a direção de recusa do modelo; essa técnica é explicada no nosso guia explicativo sobre modelos sem censura e não será explicada novamente aqui. A base é o modelo denso de 27B com atenção híbrida — 48 camadas de atenção linear mais 16 camadas de atenção total — compreensão nativa de imagens e vídeos, um contexto de 262.144 tokens e uma cabeça integrada de decodificação especulativa MTP. Apache 2.0 de ponta a ponta.

O que torna este build interessante não é a abliteração, mas o layout de quantização, porque é deliberadamente um build quantizado — se você procurou por NVFP4, o formato é o ponto. Conforme os metadados públicos do repositório e a configuração de quantização, é um build compressed-tensors de precisão mista: as projeções de atenção são FP8 (E4M3), os MLPs são NVFP4 (4 bits, empacotados), e o codificador de visão, o head MTP, o lm_head e as normas e biases da atenção linear são mantidos em BF16. Os metadados safetensors da listagem pública de arquivos se alinham com esse esquema: cerca de 3,5 bilhões de parâmetros em BF16, 9,4 bilhões em FP8-E4M3 e 15 bilhões em tensores de 4 bits empacotados, aproximadamente 24,7 GB em disco, distribuídos por cinco shards, além de um shard model-extra separado. Nada disso é uma afirmação sobre o comportamento no serving — VRAM em tempo de execução e throughput para este repositório específico não estão publicados em nenhum lugar que eu possa citar hoje. O tamanho em disco vem da listagem de arquivos, o formato vem da configuração, e o comportamento no serving abaixo é verificado pela comunidade em builds NVFP4 intimamente relacionados.

O que é o NVFP4 e como ele difere do FP8 e do INT8/AWQ

NVFP4 é o formato de ponto flutuante de 4 bits da NVIDIA, introduzido para os núcleos tensoriais de quinta geração na Blackwell, e o blog técnico oficial da NVIDIA é a fonte primária correta para ele. Ele armazena pesos como E2M1 — um bit de sinal, dois bits de expoente, um bit de mantissa — e os dimensiona em blocos: a cada 16 valores compartilham uma escala E4M3 FP8, e o tensor inteiro recebe um escalar FP32 por tensor. Esse esquema em dois níveis é exatamente o objetivo do formato: ele recupera a faixa dinâmica que um float ingênuo de 4 bits perderia, ao custo de alguns bits de overhead por bloco. As diferenças práticas, em uma frase:

• NVFP4 vs FP8 — ambos são de ponto flutuante, mas FP8 (E4M3, 8 bits) roda em Hopper e Blackwell, enquanto NVFP4 é de 4 bits e só é acelerado nativamente em Blackwell. A NVIDIA cita pesos aproximadamente 3,5× menores que FP16 e cerca de 1,8× menores que FP8, e em Blackwell o matmul roda diretamente nos tensor cores FP4.

• NVFP4 vs INT8/AWQ — INT8 (W8A8) e AWQ (W4A16) são formatos inteiros que rodam a partir de Ampere; AWQ é de 4 bits, mas inteiro, e na maioria do hardware os pesos são dequantizados para um tipo mais amplo para o matmul. NVFP4 é float de 4 bits com escalonamento por bloco, então preserva mais precisão nos bits baixos, e tem um caminho nativo de GEMM FP4 que os formatos inteiros não têm.

• NVFP4 vs MXFP4 — os dois são constantemente confundidos. MXFP4 usa blocos de 32 elementos e escalas E8M0 (potência de dois); NVFP4 usa blocos de 16 elementos e escalas E4M3. Os blocos mais finos dão ao NVFP4 melhor isolamento de outliers, razão pela qual o formato é o padrão de facto de 4 bits nas pilhas de serviço Blackwell.

Qual hardware se beneficia — e qual não

O fato mais importante sobre esta configuração: NVFP4 é um formato Blackwell. Ele só se justifica em GPUs cujos núcleos tensor implementam GEMM FP4 nativamente, e em qualquer outra coisa é a ferramenta errada, por mais rápida que a máquina seja no papel.

• Blackwell — RTX 50-series, B200/B300, RTX PRO 6000, DGX Spark (GB10) — é aqui que o NVFP4 é a escolha certa: núcleos tensores FP4 nativos, a menor pegada de nível servidor na linha sem censura e o formato para o qual a configuração foi feita.

• Hopper — H100/H200 — sem FP4 GEMM nativo. O NVFP4 degrada para um caminho de dequantização somente de pesos, que é mais lento e não traz nenhum benefício. Use Qwen3.8-27B-Uncensored-FP8 aqui; essa versão é verificada exatamente neste hardware.

• Ampere/Ada — RTX 3090/4090 — NVFP4 também não acelera nesses. A versão GGUF, com seu nível Q4_K_M de 16,8 GB, é a ferramenta certa para uma placa de 24 GB.

• Apple Silicon — NVFP4 é irrelevante em um Mac. A versão MLX (ou GGUF) é a que roda.

Uma nuance honesta: forks da comunidade rodam NVFP4 somente-pesos em hardware anterior à Blackwell. Um build NVFP4 da comunidade do mesmo modelo abliterado é explicitamente configurado para placas da classe V100 por meio de um fork do vLLM com patch, e as receitas recentes do DGX Spark em torno do Qwen3.8-27B são um caso à parte. Esses são caminhos especializados com suas próprias ressalvas, não o alvo deste build. Se você está na Blackwell, nada disso importa; se você não está na Blackwell, o build FP8 ou GGUF é o download mais indicado.

Como servir

O repositório está marcado para vLLM, e o formato compressed-tensors é lido automaticamente do config.json — você não seleciona manualmente um esquema de quantização. A stack em que os profissionais convergem para builds NVFP4 do Qwen3.8-27B é um vLLM recente em uma placa Blackwell, um cache KV FP8 e a própria cabeça MTP do modelo usada para decodificação especulativa. O guia NVFP4 da Unsloth, que é a referência comunitária mais citada, recomenda vLLM 0.25.0 ou mais recente com FlashInfer e a dependência de kernel CUTLASS-DSL para o caminho FP4 rápido.

Um ponto de partida funcional, montado a partir das flags verificadas da nossa build FP8 e das receitas da comunidade NVFP4, tudo em uma linha:

vllm serve orcarouter/Qwen3.8-27B-Uncensored-NVFP4 --kv-cache-dtype fp8 --max-model-len 262144 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}'

• Cache KV FP8 — a maneira mais amplamente compatível de reduzir a memória de cache pela metade; profissionais da área relatam que ele aproximadamente dobra o contexto que você pode manter. O suporte ao cache KV NVFP4 existe, mas é limitado a alguns backends de atenção, portanto, o cache KV FP8 é o padrão mais seguro.

• Decodificação especulativa MTP — o modelo inclui uma cabeça de rascunho MTP, e a quantização a mantém em BF16. Profissionais relatam que dois a três tokens de rascunho funcionam bem com pesos NVFP4 em Blackwell, com os maiores ganhos em saída estruturada, como JSON e chamadas de ferramentas.

• Visão — o encoder de visão é preservado em BF16 nesta versão. Adicione --language-model-only para servir apenas texto; remova-o se precisar de entrada de imagem ou vídeo.

• Em um DGX Spark — algumas armadilhas relatadas em campo: mantenha --gpu-memory-utilization em ou abaixo de 0.90 (valores mais altos travaram a máquina durante o carregamento de pesos), e adicione --safetensors-load-strategy lazy se a memória estiver apertada. Você também precisa de uma compilação GB10 do vLLM para os kernels sm_121a.

Desempenho honesto: não há números de throughput publicados e independentes para este repositório exato. As medições que existem são para builds NVFP4 intimamente relacionadas. A Unsloth relata 1,41–1,49× os tokens por segundo de BF16 em um B200 para sua própria build Qwen3.8-27B-NVFP4 (89,8 a 133,7 tok/s no batch 1; 3.048 a 4.407 no batch 64), e um usuário de DGX Spark nos fóruns da NVIDIA relata cerca de 20–32 tok/s com pesos NVFP4, um cache KV FP8 e profundidade MTP 3. Ambos merecem ser citados; nenhum é um benchmark deste repositório.

Padrões de uso que realmente funcionam

Praticantes que executam modelos da família Qwen3.8-27B em Blackwell convergem em um punhado de configurações. Trate estas como relatos de campo, não como orientação do fornecedor — a Qw​en não documenta a maior parte disso, e o próprio card deste repositório é restrito.

• reasoning_effort é o controle que mais importa. O padrão xhigh faz o modelo pensar por um longo tempo em cada requisição. Pessoas que executam loops de agentes definem medium como padrão e reduzem para low — ou desativam o pensamento completamente com enable_thinking: false — para chamadas individuais sensíveis à latência. Em uma única GPU Blackwell, o raciocínio xhigh em uma tarefa rotineira é como você acaba com um modelo rápido e respostas lentas.

• Os samplers estão emparelhados com o modo de pensamento, não são independentes. Consenso da comunidade: pensamento ligado roda com temperature 1.0 / top_p 0.95; pensamento desligado roda com temperature 0.7 / top_p 0.80 com presence_penalty 1.5. Trocar os dois conjuntos degrada a qualidade da saída.

• Use um template de chat atual. O template qwen3_5 envolve cada turno do assistente em um bloco de raciocínio, e vários profissionais relatam respostas em loop ou truncadas com templates desatualizados; as variantes corrigidas pela comunidade Qw​en-Fixed-Chat-Templates e Qw​en-Sharp definem preserve_thinking e interrompem os loops. Se a sua saída servida divagar além do token de parada, essa é a primeira coisa a verificar.

• Reserve orçamento para longos rastros de raciocínio em trabalho de agente. Profissionais relatam que o modelo da geração 3.8 emite aproximadamente o dobro de tokens por tarefa em relação ao seu predecessor 3.6 — o salto de qualidade vem em parte de um raciocínio mais longo. Para respostas xhigh longas, transmita a saída do raciocínio ou você encontrará timeouts de gateway.

• A chamada de ferramentas permanece intacta durante a quantização.O caminho de chamada de função sobrevive tanto à abliteração quanto à conversão de 4 bits; ative-o com o parser de chamada de ferramentas qwen3_coder e o modelo escolhe ferramentas da mesma forma que o modelo base.

Quem deve escolher esta build — e quem não deve

A decisão honesta, sem repetir a matemática de seleção de quantização que nossos artigos sobre FP8 e GGUF já cobrem em detalhes:

• Escolha NVFP4 se você estiver servindo em Blackwell e quiser a menor pegada de nível servidor na linha sem censura com velocidade de FP4-tensor-core — e estiver fazendo pesquisa, trabalho de red-team ou interpretabilidade que legitimamente precise de um modelo abliterated.

• Escolha Qwen3.8-27B-Uncensored-FP8 se você estiver na Hopper ou quiser o caminho vLLM mais amplamente verificado — são os mesmos pesos em 8-bit, verificados em um H200, com um mínimo de aproximadamente 40 GB de VRAM.

• Escolha Qwen3.8-27B-Uncensored-GGUF se você estiver em uma GPU de consumo ou em um Mac, ou preferir llama.cpp em vez de vLLM — o nível Q4_K_M é o ponto ideal local.

• Não escolha nenhum se você quer fidelidade máxima, está construindo qualquer coisa voltada ao usuário (veja o limite de segurança abaixo) ou não quer fazer self-host de jeito nenhum — a mesma linha sem censura é servida através do OrcaRouter com acesso restrito a pesquisadores, então não é necessário GPU.

A fronteira de segurança — apenas para pesquisa

Este é um modelo abliterado, e a quantização não coloca de volta as proteções. A direção de recusa foi removida do fluxo residual do Qw​en/Qwen3.8-27B, e NVFP4 é uma mudança de precisão, não uma intervenção de segurança — o modelo atenderá a solicitações que o modelo base recusa, e esta versão não possui moderação embutida. Ele é lançado para pesquisa de interpretabilidade, segurança de IA e red-team sob Apache 2.0, e a responsabilidade é sua.

Duas notas de avaliação que surgem raramente demais no {{1}}espaço de modelos não censurados{{/1}}. Primeiro, uma única sonda de jailbreak que passa trivialmente não é uma avaliação de segurança aprovada — {{2}}modelos abliterados falham nelas de propósito{{/2}}. {{3}}Meça o que realmente importa para você com as baterias de testes adequadas{{/3}} ({{4}}AdvBench, HarmBench e StrongREJECT para nocividade; XSTest-safe para recusa excessiva{{/4}}) e {{5}}compare as taxas de recusa antes e depois da intervenção{{/5}}. Segundo, avalie {{6}}o quant, não apenas a base{{/6}}: {{7}}uma build de 4 bits pode mudar o comportamento em casos extremos mesmo quando as pontuações agregadas parecem boas{{/7}}. Não implante isso para usuários finais sem {{8}}suas próprias camadas de moderação e prevenção de abuso{{/8}}.

Onde o OrcaRouter se encaixa

Um build quantizado de dez dias é o caso clássico de roteamento em vez de ligação direta. Você pode configurar uma rota que aponte para o build NVFP4 que você mesmo executa e fazer failover para um modelo hospedado se o build apresentar problemas sob carga — uma interface, sem reconfiguração entre provedores ao alternar. O OrcaRouter repassa o preço de lista do provedor com margem de 0%, então, se o preço do modelo subjacente mudar, seu endpoint reflete isso no mesmo dia, em vez de no seu ciclo de faturamento.

E se todo o objetivo é evitar executar uma GPU por completo: a mesma linha sem censura está disponível através do OrcaRouter, restrita a pesquisadores de segurança e red teams, com failover automático entre provedores. Quer você hospede esta build NVFP4 por conta própria ou use a linha hospedada, é uma única chave de API de qualquer forma.

O resultado final

Qwen3.8-27B-Uncensored-NVFP4 é o download certo se você estiver servindo o modelo abliterado em Blackwell e quiser a menor pegada com velocidade de FP4-tensor-core. É o download errado em Hopper (use a versão FP8), em uma GPU de consumo ou Apple (use a versão GGUF ou MLX), ou se precisar de fidelidade máxima. Não é novo — está disponível para download desde 19 de agosto de 2026 — mas está sendo baixado em volume, e agora você sabe no que está se metendo antes de aceitar o gate.

Não é outra compilação deste modelo — Qwen3.8-Flash-Next-Uncensored é um lançamento separado: abliterado do Qwen3.8-Flash-Next, uma prévia de mistura de especialistas com 176B armazenados / 6B ativos da arquitetura Qwen4. Mesma técnica de abliteração, pesos diferentes, coleção própria.

Todas as seis versões 27B — BF16, GGUF, MLX, FP8, INT8 e NVFP4 — estão reunidas na coleção Qwen3.8-27B-Uncensored no Hugging Face.

Estes pesos são apenas locais por design. Para medir a versão abliterada em relação a uma linha de base hospedada, Qwen3.8-27B é servido no OrcaRouter ao preço de tabela do provedor com margem de 0% — o modelo original, com alinhamento de segurança intacto.