Servindo Qwen3.8-Flash-Next-Uncensored-FP8: um runbook vLLM para a build block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — a build block-FP8 do Flash-Next abliterado — é o artefato que você realmente baixa ao servir este modelo em hardware de datacenter, e é o último da coleção a ganhar um runbook próprio. Ele está hospedado em orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 no Hugging Face: a direção de recusa removida do Qwen3.8-Flash-Next da Qw​en, depois re-quantizado offline para o esquema FP8 exato do Qwen3.8-Flash-Next-FP8 oficial, para que o vLLM o sirva no mesmo caminho de kernel. É a build que qualquer pessoa rodando este modelo em GPUs da classe Hopper e mais novas vai procurar, e o caminho de serviço tem um flag fácil de errar e difícil de diagnosticar quando está errado.

Primeiro, a fronteira, porque os leitores continuam a confundi-la e isso muda tudo abaixo. Qwen3.8-Flash-Next-Uncensored e Qwen3.8-27B-Uncensored são dois modelos diferentes, não duas versões de um mesmo modelo. Pesos base diferentes — Qwen3.8-Flash-Next contra Qwen3.8-27B — arquiteturas diferentes, lançamentos de pesos diferentes, coleções diferentes no Hugging Face. Eles compartilham uma técnica de abliteração e um nome de família; só isso. Nenhum dos números de uma página do 27B se aplica a este modelo, e se você chegou aqui a partir de uma pesquisa pelo 27B, o runbook local do 27B é uma página separada com um conjunto separado de decisões.

Esta página é a página de serving do Flash-Next FP8 e nada mais. O runbook GGUF/MLX cobre a explicação de abliteração para este modelo e as duas linhas de build para hardware de consumo; a técnica por trás de toda a família é explicada no primer de abliteração e no explainer mais amplo de LLM não-censurado; e o Qwen3.8-27B-Uncensored-FP8, o irmão que podem ter indicado para você, tem seu próprio runbook FP8. Aqui, nos concentramos em uma única questão: como você serve o build block-FP8, o que quebra quando você faz isso errado e o que os números do próprio card informam ou não.

Antes de começar: o gate e o runtime

Duas coisas condicionam este repositório, e ambas geram falhas que parecem outra coisa.

{{1}}O primeiro é o acesso.{{/1}} O repositório é restrito: você precisa estar logado no Hugging Face e ter aceitado os termos do repositório antes que qualquer download funcione. A própria página do modelo pode ser lida sem uma conta — todo o texto do card é público — mas os pesos não são. {{2}}Em termos diretos, sem uma sessão logada que tenha aceitado os termos, hf download e vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 falham com um erro de autenticação, não com um amigável “você precisa clicar em Agree.”{{/2}} Faça primeiro o aceite por clique único e, em seguida, baixe os ~186 GB com a CLI do hf ou deixe o vLLM resolver o repositório na primeira execução.

A segunda é o runtime. O checkpoint é registrado sob a arquitetura qwen4_exp (Qwen4ExpForConditionalGeneration), que o vLLM padrão e o Transformers padrão não conseguem carregar. Você precisa da imagem vLLM do dia 0 e do transformers 5.16+. Este é o erro de "não carrega" mais comum em todos os runbooks da comunidade nesta semana — não é um download corrompido, mas um runtime anterior à arquitetura. A imagem não é opcional; ela é o caminho.

Hardware, para que você possa planejar antes de retirar qualquer coisa: a invocação da placa tem como alvo um nó de 8 GPUs, e as diretrizes da receita oficial do vLLM para o checkpoint FP8 se aplicam aqui, já que os builds correspondem tensor por tensor — na ordem de 265 GB de VRAM de GPU para uma implantação de nó completo, com TP2 tratado como o mínimo na classe GB300 e TEP4/TEP8 como as configurações de bandeja completa validadas.

Por que a build FP8 existe — e por que o "caminho de kernel idêntico" é exatamente o ponto

Os pesos BF16 abliterados são a fonte da verdade; este repositório é esse modelo re-quantizado offline, reproduzindo deliberadamente a receita oficial do Qwen3.8-Flash-Next-FP8. O quantizador toca apenas nas 512 projeções de especialistas roteados — experts.{e}.down/gate/up_proj — desfundindo-as do layout 3D da build BF16 e armazenando cada uma como pesos float8_e4m3fn mais escalas BF16 weight_scale_inv, em blocos de 128×128. As ativações são FP8 dinâmico por token; não há conjunto de calibração. Todo o resto permanece em BF16: atenção e linear_attn, o especialista compartilhado, o roteador MoE (mlp.gate), os mixers Hyper-Connection, embeddings, lm_head, a cabeça de decodificação especulativa MTP e toda a torre de visão.

A linha do “caminho de kernel idêntico” é mais do que marketing, e merece uma frase. A build foi verificada em relação ao checkpoint oficial FP8: as escalas de bloco são reproduzidas exatamente (scale_relerr = 0) e os códigos FP8 correspondem ao arredondamento sub-ULP. É por isso que o vLLM a executa com os mesmos kernels FP8 de escala de bloco e a mesma decodificação especulativa MTP da versão oficial — os tensores são efetivamente os mesmos tensores, menos a direção de recusa.

Concretamente, isso lhe dá ~186 GB distribuídos em 131 shards (152.089 tensores, 75.264 deles em FP8), 262.144 tokens de contexto nativo, a torre de visão + vídeo preservada byte a byte (333 tensores visual.*) e a cabeça MTP intacta. Os pesos foram abliterados primeiro — uma única direção de recusa estimada na camada 24 e ortogonalizada de 149 tensores de escrita residual em float32, seguindo Arditi et al. (2024) — e os escritores residuais da cabeça MTP foram editados de forma consistente, para que a decodificação especulativa continue funcionando. Esse último detalhe não é óbvio, e é a diferença entre uma cabeça que acelera a decodificação e uma que silenciosamente a degrada.

A única flag que determina o sucesso ou o fracasso do carregamento.

Sirva este build sem {{1}}--enable-expert-parallel{{/1}} e você obtém uma falha que parece um bug de shape, não um erro de configuração. É a falha de serving mais relatada para este checkpoint, e é totalmente determinística.

Aqui está a aritmética. A projeção fundida gate+up dos especialistas roteados tem um tamanho intermediário de 640. O Block-FP8 quantiza em blocos de largura 128. Com paralelismo de tensor simples, esse 640 é dividido entre os ranks — 640 ÷ TP — e para os graus de TP comuns (2, 4, 8) a fatia por rank não é divisível por 128: TP8 dá 80, TP4 dá 160, TP2 dá 320. Então o vLLM se recusa a carregar os pesos com um erro que parece uma incompatibilidade de forma: O output_size do peso de gate e up = 80 não é divisível por block_n de quantização de peso = 128.

O paralelismo de especialistas corrige isso distribuindo os pesos dos especialistas entre os ranks de paralelismo de especialistas em vez dos ranks de paralelismo de tensor, o que preserva os limites de bloco FP8. É por isso que a flag é obrigatória para este build: com --enable-expert-parallel, TP8 se torna um TEP8 funcional. (É inofensivo para o build BF16, onde não há blocos FP8 a preservar.) A receita oficial do vLLM é explícita de que TP8 puro é incompatível com os blocos de quantização de largura 128 do checkpoint, e um issue do vLLM aberto dois dias após os pesos serem publicados documenta a mesma falha em um nó com 8×L40s em TP2, TP4 e TP8. Se um carregamento morrer com um erro parecido com shape, verifique a flag antes de verificar o download.

O comando exato

Eis a invocação docker do cartão, reproduzida fielmente:

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

Percorra os sinalizadores que não são óbvios:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — a imagem qwen4_exp do dia 0. Esta não é uma vLLM genérica; é a imagem específica da arquitetura, e as imagens padrão anteriores à qwen4_exp não carregarão o checkpoint de forma alguma.

• --trust-remote-code — carrega o código de modelagem qwen4_exp que acompanha o repositório. Sem ele, o carregador se recusa por princípio.

• --max-model-len 262144 — corresponde à janela de contexto nativa. Você quer isso explícito aqui, em vez de deixá-lo com um padrão.

• --enable-expert-parallel — necessário para a build FP8, pelas razões na seção acima. A placa observa que é inofensivo para BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — ativa a chamada de ferramentas e funções usando o formato XML do Qwen3-Coder. Se deixá-los desativados, o modelo ainda conversa, mas o uso de ferramentas agênticas fica desativado.

• --tensor-parallel-size 8 — a invocação da placa assume um nó de 8 GPUs (8× classe Hopper). Com --enable-expert-parallel, trata-se de uma implantação TEP8.

Quando o contêiner estiver ativo, o endpoint é compatível com OpenAI em :8000/v1. Defina --served-model-name para o que seus clientes esperam; a placa usa Qwen3.8-Flash-Next-Uncensored.

Alternativas, todas no card ou corroboradas por profissionais esta semana: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 diretamente assim que sua sessão HF estiver autenticada; SGLang via a imagem lmsysorg/sglang:qwen38flashnext com --tp 8 --ep 8 — o mesmo requisito de paralelismo por especialista, a mesma razão; e Transformers com pipeline("image-text-to-text", ...) no transformers 5.16+ se você quiser usar scripts contra o modelo em vez de servi-lo.

O que realmente funciona quando você o serve

Os padrões desta seção são descobertas da comunidade, obtidas de runbooks de profissionais e discussões em fóruns desta semana, não orientações do fornecedor. Quando mais de uma configuração apresenta o mesmo comportamento, é razoável tratá-lo como real:

• A decodificação especulativa com MTP funciona. Adicione --speculative-config '{"method":"mtp","num_speculative_tokens":3}' e o vLLM usa a cabeça MTP preservada. Vários runbooks relatam que o MTP é o motivo pelo qual a decodificação deste modelo continua utilizável apesar do seu tamanho.

• OOM ao carregar? Transfira a tabela de n-gramas. O embedding de n-gramas PLE de 51B parâmetros é a surpresa de memória nesta arquitetura. VLLM_PLE_CPU_OFFLOAD=1 a move para a RAM do host — reserve pelo menos ~51 GB lá. A receita oficial e os runbooks da comunidade para múltiplos nós recorrem a esta flag.

• A visão é real, não vestigial. A torre de visão + vídeo é preservada byte por byte, portanto este continua sendo um modelo completo de visão-linguagem. Passe uma parte de conteúdo image_url em um chat completion e o mesmo endpoint serve para compreensão de imagens; as sondas de OCR da comunidade reportam passes limpos nesta compilação.

• O raciocínio está ativado por padrão — e isso muda o cenário de segurança. O template de chat permite o pensamento, a menos que você diga o contrário. Alterne por solicitação com chat_template_kwargs={"enable_thinking": true|false}, e adicione um parser de raciocínio se quiser que o texto do pensamento seja separado da resposta. Devido a esse padrão, você quase sempre estará servindo o modelo com pensamento ativado, a menos que o desative explicitamente.

• 262K nativo, 1M com override de rope.O contexto nativo é de 262.144 tokens. Para chegar a 1M, é necessário um override explícito do escalonamento de rope YaRN, além de uma variável de ambiente que eleve o limite de max-model-len do vLLM — e você deve primeiro fazer testes de regressão na qualidade em contextos mais curtos, porque a extensão cega de 4× é onde a qualidade em contextos longos geralmente degrada.

O que os números do cartão dizem — e o que eles não dizem

Estas são as próprias medições do fornecedor em sua própria edição, publicadas no model card e medidas nesses pesos exatos servidos com vLLM contra a base oficial sob scripts e configurações idênticos. Relate-as como o que são: indicativas, e não uma auditoria independente.

A manchete é o colapso de recusa com o pensamento desligado. Na suíte de prompts prejudiciais do card (n de 50 a 150 por benchmark), a recusa base varia de 64–100% e esta build de 0–2.7%: AdvBench 100%→2.0%, JailbreakBench 94%→0.0%, StrongREJECT 99.3%→1.3%, HarmBench 100%→1.3%, MaliciousInstruct 98%→0.0%, SimpleSafetyTests 64%→2.0%, ForbiddenQuestions 75.3%→2.7%, e um probe personalizado chinês/inglês 63.6%→0.0%.

Agora a metade honesta. A taxa de recusa do modelo base em si colapsa quando o raciocínio é ativado — o {{1}}AdvBench{{/1}} cai de 100% no base para 7,0% com o raciocínio ligado —, então a comparação com o raciocínio ativado é muito menos dramática: esta build fica em 0,0% na mesma suíte, mas está raspando um número pequeno de um número que o base já havia reduzido. Citar apenas os números sem raciocínio é apresentar a metade lisonjeira da história, e é precisamente essa metade em que uma avaliação de segurança não pode se apoiar.

Excesso de recusa em prompts benignos (XSTest-safe, n=250) cai de 9,6% na base para 1,2% nesta versão com o raciocínio desativado — uma melhoria real, já que um modelo que recusa prompts benignos é o modo de falha mais silencioso. A retenção de capacidade em MMLU / MMLU-Pro / GSM8K / CMMLU mostra deltas de −2,0, −1,2, −1,3 e −0,6 pontos, respectivamente, consistente com a afirmação de que ortogonalizar uma direção custa capacidade geral quase zero. Chamada de ferramentas, visão/OCR e raciocínio são todos relatados como funcionando nesta versão.

Duas ressalvas pairam sobre tudo o que foi dito. A métrica de recusa vem de um classificador de frase de abertura baseado em regras, que o próprio cartão considera indicativo, e não um número de juiz-LLM ou de nível de publicação — um painel humano ou um modelo avaliador não reproduzirá esses valores exatos. E a coluna de ressalvas importa: na suíte com raciocínio desativado, cerca de metade a três quartos das saídas desta versão ainda abrem com uma breve isenção de responsabilidade antes de atender. O modelo raramente recusa; ele faz rodeios. “Sem censura” aqui significa que ele responde, não que responde sem preâmbulo.

A seção de segurança não é uma formalidade.

Leia isto antes de puxar os pesos, não depois.

Este modelo teve seu alinhamento de segurança substancialmente removido, e o mecanismo é específico: uma única direção de recusa foi estimada no fluxo residual e ortogonalizada para fora de cada matriz de escrita residual — 149 delas — calculada em float32. A consequência é anunciada, não incidental. A ficha técnica é direta: o modelo atenderá a solicitações prejudiciais, antiéticas, ofensivas ou ilegais que o Qwen3.8-Flash-Next base recusaria, e que ele não possui proteções integradas significativas. Ele é lançado estritamente para pesquisa legítima — interpretabilidade, estudo de segurança de IA e mecanismos de recusa, red-teaming, avaliação de robustez e experimentos controlados — e o usuário assume total responsabilidade e responde integralmente pelo que ele gera. A Apache 2.0 rege o que você pode fazer com os pesos.

Duas coisas para acertar exatamente, porque esta compilação torna fácil errá-las.

Primeiro, uma sonda de jailbreak que “funciona” contra este modelo não é passar numa avaliação de segurança. É o comportamento anunciado. Se a alegação da sua avaliação é “a segurança deste modelo foi contornada”, você mediu o design, não uma vulnerabilidade. O que seria de fato uma descoberta é uma recusa que sobrevive à abliteração, ou uma regressão de capacidade — e os números do card sugerem que ambos são raros.

Segundo, a superfície de ataque preservada é mais ampla do que texto. A torre de visão está intacta byte por byte e a chamada de ferramentas funciona, portanto a entrada de imagens e o uso agêntico estão ambos ativos. Um plano de red team que apenas testa prompts de texto perde as modalidades que este modelo realmente expõe. E os números de recusa acima são um classificador baseado em regras sobre a própria edição do fornecedor — não são uma auditoria independente de nada, incluindo segurança.

Não implante isso para usuários finais ou em produção sem adicionar suas próprias camadas de segurança, moderação e prevenção de abuso. Os termos do repositório dizem isso claramente, e não é texto padrão: as saídas não refletem as opiniões dos uploaders ou da Qw​en / Ali​baba.

Como obter uma linha de base censurada para comparação

Se o seu trabalho é pesquisa de mecanismos de recusa ou red-teaming, você quase certamente quer a contraparte censurada deste modelo lado a lado — a mesma arquitetura sem a edição — para medir o delta. Esta compilação não censurada é somente local por design: o repositório tem acesso restrito e não possui implantação de inferência hospedada, o que é intencional para que payloads sensíveis nunca transitem por uma API de terceiros.

Para a linha de base hospedada, o OrcaRouter roteia a linha Qw​en pelo preço de tabela do provedor, sem margem de lucro — Qwen3.8-Flash a US$ 0,15 por milhão de tokens de entrada e US$ 0,47 por milhão de tokens de saída, repassados como estão, com failover automático e uma única chave para mais de 200 modelos. Uma alteração de preço do fornecedor aparece no mesmo dia. Se você está avaliando se deve executar esse build, ou quanto da sua stack ela pode suportar, essa é a forma barata de comparar a versão censurada com ele, sem um segundo contrato ou um segundo código-fonte.

Comece aqui

Resumo da decisão. Você precisa de: uma conta Hugging Face com os termos do repositório aceitos; um nó da classe Hopper ou superior — o comando da placa é direcionado a 8 GPUs, e algo em torno de 265 GB de VRAM de GPU, conforme a orientação da receita oficial para o checkpoint FP8 correspondente; a imagem vLLM do dia 0 e transformers 5.16+; e aproximadamente 186 GB de disco para os pesos.

Ordem de execução: aceite os termos do repositório → baixe os pesos → puxe a imagem do dia 0 → sirva com --enable-expert-parallel → verifique com uma requisição para :8000/v1/chat/completions → então inicie suas avaliações. Se um carregamento falhar com um erro que parece ser de formato, verifique a flag antes de verificar o download.

E mantenha o enquadramento. Este é um instrumento de pesquisa, liberado nessa condição. Seus números são as medições indicativas do próprio fornecedor em sua própria edição. Seu comportamento de segurança é o objetivo do exercício, não um bug a ser contornado. Sirva-o, meça-o e coloque sua própria moderação entre ele e qualquer coisa humana.

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.