Servir Qwen3.8-Flash-Next-Uncensored-FP8: un runbook de vLLM para la compilación block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — la compilación block-FP8 del Flash-Next abliterado — es el artefacto que realmente descargas al servir este modelo en hardware de centro de datos, y es el último de la colección en tener su propio runbook. Se encuentra en orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 en Hugging Face: se eliminó la dirección de rechazo del Qwen3.8-Flash-Next de Qw​en y luego se re-cuantizó fuera de línea al esquema FP8 exacto del Qwen3.8-Flash-Next-FP8 oficial, para que vLLM lo sirva en la misma ruta de kernel. Es la compilación que cualquiera que ejecute este modelo en GPUs de clase Hopper y posteriores buscará, y la ruta de servicio tiene un flag que es fácil de configurar mal y difícil de diagnosticar cuando está mal.

Primero, el límite, porque los lectores siguen difuminándolo y eso cambia todo lo que sigue. Qwen3.8-Flash-Next-Uncensored y Qwen3.8-27B-Uncensored son dos modelos diferentes, no dos versiones de un mismo modelo. Pesos base distintos — Qwen3.8-Flash-Next frente a Qwen3.8-27B — arquitecturas diferentes, lanzamientos de pesos diferentes, colecciones de Hugging Face diferentes. Comparten una técnica de abliteración y un nombre de familia; eso es todo. Ninguno de los números de una página de 27B se transfiere a este modelo, y si llegaste aquí desde una búsqueda de 27B, el runbook local del propio 27B es una página separada con un conjunto separado de decisiones.

Esta página es la página de servicio de Flash-Next FP8 y nada más. El runbook de GGUF/MLX cubre la explicación de la abliteración para este modelo y las dos líneas de compilación para hardware de consumo; la técnica detrás de toda la familia se explica en el manual de abliteración y en el explicador más amplio de LLM sin censura; y Qwen3.8-27B-Uncensored-FP8, el hermano al que quizás te han señalado, tiene su propio runbook de FP8. Aquí nos centramos en una sola pregunta: cómo sirves la compilación block-FP8, qué se rompe cuando lo haces mal, y qué te dicen y qué no te dicen los números de la propia tarjeta.

Antes de empezar: la compuerta y el tiempo de ejecución.

Dos cosas condicionan este repositorio, y ambas producen fallos que parecen otra cosa.

Lo primero es el acceso. El repositorio está restringido: debes iniciar sesión en Hugging Face y haber aceptado los términos del repositorio antes de que cualquier descarga funcione. La página del modelo en sí se puede leer sin cuenta —todo el texto de la tarjeta es público—, pero los pesos no lo están. En pocas palabras, sin una sesión iniciada que haya aceptado los términos, tanto hf download como vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 fallan con un error de autenticación, no con un amable «debes hacer clic en Aceptar». Haz primero el clic único de aceptación y luego descarga los ~186 GB con la CLI de hf, o deja que vLLM resuelva el repositorio en la primera ejecución.

El segundo es el tiempo de ejecución. El checkpoint se registra bajo la arquitectura qwen4_exp (Qwen4ExpForConditionalGeneration), que el vLLM estándar y los Transformers estándar no pueden cargar. Necesita la imagen day-0 de vLLM y transformers 5.16+. Este es el fallo “no carga” más común en los runbooks de la comunidad esta semana — no es una descarga corrupta, sino un tiempo de ejecución anterior a la arquitectura. La imagen no es opcional; es el camino.

Hardware, para que puedas planificar antes de extraer nada: la invocación de la tarjeta apunta a un nodo de 8 GPU, y la guía de la receta oficial de vLLM para el checkpoint FP8 se aplica aquí, ya que las compilaciones coinciden tensor por tensor — del orden de 265 GB de VRAM de GPU para un despliegue de nodo completo, con TP2 tratado como el mínimo en la clase GB300 y TEP4/TEP8 como las configuraciones validadas de bandeja completa.

Por qué existe la compilación FP8 — y por qué la “ruta de kernel idéntica” es el punto clave.

Los pesos BF16 "abliterated" son la fuente de verdad; este repositorio contiene ese modelo re-cuantizado fuera de línea, reproduciendo deliberadamente la receta oficial de Qwen3.8-Flash-Next-FP8. El cuantizador toca solo las 512 proyecciones de expertos enrutados — experts.{e}.down/gate/up_proj — desfusionándolas del diseño 3D de la compilación BF16 y almacenando cada una como pesos float8_e4m3fn más escalas BF16 weight_scale_inv en bloques de 128×128. Las activaciones son FP8 dinámico por token; no hay conjunto de calibración. Todo lo demás permanece en BF16: la atención y linear_attn, el experto compartido, el enrutador MoE (mlp.gate), los mezcladores Hyper-Connection, los embeddings, lm_head, la cabeza de decodificación especulativa MTP y toda la torre de visión.

La línea de “ruta de kernel idéntica” es más que marketing, y merece una frase. La compilación se verificó contra el checkpoint oficial de FP8: las escalas de bloque se reproducen exactamente (scale_relerr = 0) y los códigos FP8 coinciden con un redondeo sub-ULP. Por eso vLLM lo ejecuta con los mismos kernels FP8 de escala por bloques y el mismo decodificado especulativo MTP que la versión oficial — los tensores son efectivamente los mismos tensores, menos la dirección de rechazo.

Concretamente, eso te da ~186 GB en 131 shards (152,089 tensores, 75,264 de ellos FP8), 262,144 tokens de contexto nativo, la torre de visión + video conservada byte a byte (333 tensores visual.*), y el cabezal MTP intacto. Los pesos fueron abliterados primero — una única dirección de rechazo estimada en la capa 24 y ortogonalizada fuera de 149 tensores de escritura residual en float32, siguiendo a Arditi et al. (2024) — y los escritores residuales del cabezal MTP fueron editados de manera consistente, por lo que la decodificación especulativa sigue funcionando. Ese último detalle no es obvio, y es la diferencia entre un cabezal que acelera la decodificación y uno que la degrada silenciosamente.

El único indicador que hace o deshace la carga.

Sirve esta compilación sin --enable-expert-parallel y obtendrás un fallo que parece un bug de forma, no un error de configuración. Es el fallo de servicio más reportado para este checkpoint, y es completamente determinista.

Aquí está la aritmética. La proyección fusionada gate+up de los expertos enrutados tiene un tamaño intermedio de 640. Block-FP8 cuantiza en bloques de 128 de ancho. Con paralelismo de tensores simple, ese 640 se divide entre los rangos — 640 ÷ TP — y para los grados de TP comunes (2, 4, 8) la porción por rango no es divisible por 128: TP8 da 80, TP4 da 160, TP2 da 320. vLLM entonces se niega a cargar los pesos con un error que parece un desajuste de forma: The output_size of gate's and up's weight = 80 is not divisible by weight quantization block_n = 128.

El paralelismo de expertos lo soluciona distribuyendo los pesos de los expertos entre rangos de paralelismo de expertos en lugar de rangos de paralelismo tensorial, lo que preserva los límites de bloque de FP8. Por eso la bandera es obligatoria en esta compilación: con `--enable-expert-parallel`, TP8 se convierte en un TEP8 funcional. (Es inofensiva para la compilación BF16, donde no hay bloques FP8 que preservar). La receta oficial de vLLM es explícita: el TP8 simple es incompatible con los bloques de cuantización de 128 de ancho del checkpoint, y un informe de problema de vLLM abierto dos días después de que los pesos se publicaran documenta el mismo fallo en un nodo de 8×L40s con TP2, TP4 y TP8. Si una carga falla con un error que parece de forma, revisa la bandera antes de revisar la descarga.

El comando exacto

Aquí está la invocación de docker de la tarjeta, reproducida 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

Revisa las banderas que no son obvias:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — la imagen day-0 de qwen4_exp. No es un vLLM genérico; es la imagen específica de la arquitectura, y las imágenes estándar anteriores a qwen4_exp no cargarán el checkpoint en absoluto.

• --trust-remote-code — carga el código de modelado qwen4_exp incluido en el repositorio. Sin él, el cargador se niega por principio.

• --max-model-len 262144 — coincide con la ventana de contexto nativa. Quieres que esté explícito aquí en lugar de dejarlo en un valor predeterminado.

• --enable-expert-parallel — necesario para la compilación FP8, por las razones en la sección anterior. La tarjeta indica que es inofensivo para BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — activa la llamada a herramientas y funciones utilizando el formato XML de Qwen3-Coder. Si los dejas desactivados, el modelo sigue chateando, pero el uso de herramientas de agente está desactivado.

• --tensor-parallel-size 8 — la invocación de la tarjeta asume un nodo de 8 GPU (8× clase Hopper). Con --enable-expert-parallel, eso es un despliegue TEP8.

Una vez que el contenedor esté en funcionamiento, el endpoint es compatible con OpenAI en :8000/v1. Establezca --served-model-name a lo que sus clientes esperan; la tarjeta usa Qwen3.8-Flash-Next-Uncensored.

Alternativas, todas en la tarjeta o corroboradas por profesionales esta semana: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 directamente una vez que tu sesión de HF esté autenticada; SGLang mediante la imagen lmsysorg/sglang:qwen38flashnext con --tp 8 --ep 8 — el mismo requisito de paralelismo de expertos, la misma razón; y Transformers con pipeline("image-text-to-text", ...) en transformers 5.16+ si quieres escribir scripts contra el modelo en lugar de servirlo.

Lo que realmente funciona cuando lo sirves

Los patrones de esta sección son hallazgos de la comunidad, extraídos de runbooks de profesionales y hilos de foros de esta semana, no orientación de proveedores. Cuando más de una configuración reporta el mismo comportamiento, vale la pena tratarlo como real:

• La decodificación especulativa MTP funciona. Añade --speculative-config '{"method":"mtp","num_speculative_tokens":3}' y vLLM utiliza la cabeza MTP conservada. Varios runbooks señalan que MTP es la razón por la que la decodificación de este modelo sigue siendo utilizable a pesar de su tamaño.

• ¿OOM al cargar? Descarga la tabla de n-gramas. El embedding de n-gramas PLE de 51B parámetros es la sorpresa de memoria en esta arquitectura. VLLM_PLE_CPU_OFFLOAD=1 lo mueve a la RAM del host — asígnale al menos ~51 GB allí. La receta oficial y los runbooks comunitarios multinodo recurren a esta flag.

• La visión es real, no vestigial. La torre de visión + video se conserva byte a byte, por lo que sigue siendo un modelo completo de visión y lenguaje. Pasa una parte de contenido image_url en una finalización de chat y el mismo endpoint sirve para la comprensión de imágenes; las pruebas de OCR de la comunidad en esta compilación informan pases limpios.

• El razonamiento está activado por defecto — y esto cambia el panorama de seguridad. La plantilla de chat habilita el pensamiento a menos que indiques lo contrario. Actívalo o desactívalo por solicitud con chat_template_kwargs={"enable_thinking": true|false}, y añade un analizador de razonamiento si quieres que el texto de pensamiento aparezca separado de la respuesta. Debido a esta configuración predeterminada, casi siempre estás sirviendo el modelo con pensamiento activado a menos que lo desactives explícitamente.

• 262K nativo, 1M con una anulación de rope.El contexto nativo es de 262 144 tokens. Para llegar a 1M se necesita una anulación explícita del escalado de rope YaRN, además de una variable de entorno que eleve el límite de max-model-len de vLLM; y deberías hacer pruebas de regresión de la calidad en contextos más cortos primero, porque la extensión ciega a 4× es donde la calidad en contextos largos suele degradarse.

Lo que dicen los números de la tarjeta — y lo que no dicen

Estas son las mediciones del propio proveedor sobre su propia edición, publicadas en la tarjeta del modelo y medidas sobre estos pesos exactos servidos con vLLM frente a la base oficial bajo scripts y ajustes idénticos. Repórtalas como lo que son: indicativas, y no una auditoría independiente.

El titular es el colapso del rechazo con el razonamiento desactivado. En la suite de indicaciones dañinas de la tarjeta (n de 50 a 150 por punto de referencia), el rechazo base oscila entre 64–100% y esta versión entre 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%, y una sonda personalizada en chino/inglés 63.6%→0.0%.

Ahora la mitad honesta. La tasa de rechazo del modelo base se derrumba cuando el razonamiento está activado: AdvBench cae del 100 % en el base al 7,0 % con el razonamiento activado, por lo que la comparación con el razonamiento activado es mucho menos drástica: esta versión se sitúa en el 0,0 % en el mismo conjunto de pruebas, pero le está restando una pequeña cantidad a una cifra que el base ya había reducido. Si se citan solo las cifras con el razonamiento desactivado, se está presentando la mitad halagüeña de la historia, y esa es precisamente la mitad en la que una evaluación de seguridad no debe apoyarse.

El sobre-rechazo en prompts benignos (XSTest-safe, n=250) cae del 9,6% en la base al 1,2% en esta compilación con el pensamiento desactivado — una mejora real, ya que un modelo que rechaza prompts benignos es el modo de fallo más silencioso. La retención de capacidades en MMLU / MMLU-Pro / GSM8K / CMMLU muestra deltas de −2,0, −1,2, −1,3 y −0,6 puntos respectivamente, lo que es consistente con la afirmación de que ortogonalizar una dirección cuesta casi cero capacidad general. La llamada a herramientas, la visión/OCR y el razonamiento se reportan como funcionales en esta compilación.

Dos salvedades se ciernen sobre todo lo anterior. La métrica de rechazo proviene de un clasificador de frases iniciales basado en reglas, que la propia tarjeta califica de indicativa, más que de un juez LLM o una cifra de calidad de publicación: un panel humano o un modelo juez no reproducirá estas cifras exactas. Y la columna de salvedades importa: en el conjunto sin pensamiento, aproximadamente entre la mitad y tres cuartos de las salidas de esta compilación aún comienzan con un breve descargo antes de cumplir. El modelo rara vez se niega; matiza. “Uncensored” aquí significa que responde, no que responde sin preámbulo.

La sección de seguridad no es una formalidad.

Lee esto antes de tirar de las pesas, no después.

Este modelo ha visto su alineamiento de seguridad sustancialmente eliminado, y el mecanismo es específico: se estimó una única dirección de rechazo en el flujo residual y se ortogonalizó fuera de cada matriz de escritura residual — 149 de ellas — calculado en float32. La consecuencia es anunciada, no incidental. La tarjeta es contundente al afirmar que el modelo cumplirá con solicitudes dañinas, poco éticas, ofensivas o ilegales que el Qwen3.8-Flash-Next base rechazaría, y que no tiene salvaguardas integradas significativas. Se publica estrictamente para investigación legítima — interpretabilidad, estudio de mecanismos de rechazo y seguridad de IA, red-teaming, evaluación de robustez y experimentos controlados — y el usuario asume toda la responsabilidad y obligación legal por lo que genere. Apache 2.0 rige lo que puedes hacer con los pesos.

Dos cosas que hay que hacer exactamente bien, porque esta compilación hace que sea fácil equivocarse.

Primero, una prueba de jailbreak que «tiene éxito» contra este modelo no es una evaluación de seguridad superada. Es el comportamiento anunciado. Si tu evaluación afirma que «se vulneró la seguridad de este modelo», has medido el diseño, no una vulnerabilidad. Lo que realmente sería un hallazgo es una negativa que sobreviva a la abliteration, o una regresión de capacidades — y los números de la tarjeta sugieren que ambos son raros.

En segundo lugar, la superficie de ataque preservada es más amplia que el texto. La torre de visión está intacta byte por byte y la llamada a herramientas funciona, por lo que tanto la entrada de imágenes como el uso agéntico están activos. Un plan de equipo rojo que solo pruebe indicaciones de texto pasa por alto las modalidades que este modelo realmente expone. Y los números de rechazo anteriores son un clasificador basado en reglas sobre la edición del propio proveedor: no son una auditoría independiente de nada, incluida la seguridad.

No implementes esto para usuarios finales ni lo despliegues en producción sin añadir tus propias capas de seguridad, moderación y prevención de abusos. Los términos del repositorio lo dicen claramente, y no es una fórmula vacía: los resultados no reflejan las opiniones de los cargadores ni de Qw​en / Ali​baba.

Cómo obtener una línea base censurada para comparación

Si tu trabajo es {{1}}investigación de mecanismos de rechazo o red-teaming{{/1}}, casi con seguridad querrás {{2}}la contraparte censurada de este modelo en paralelo — la misma arquitectura sin la edición —{{/2}} {{3}}para medir el delta{{/3}}. {{4}}Esta versión sin censurar es exclusivamente local por diseño{{/4}}: {{5}}el repositorio tiene acceso restringido y no cuenta con un despliegue de inferencia alojado,{{/5}} {{6}}lo cual es intencional{{/6}} {{7}}para que los payloads sensibles nunca transiten por una API de terceros{{/7}}.

Para la línea base alojada, OrcaRouter enruta la línea Qwen al precio de lista del proveedor sin margen adicional — Qwen3.8-Flash a $0.15 por millón de tokens de entrada y $0.47 por millón de tokens de salida, traspasado tal cual, con conmutación por error automática y una única clave para más de 200 modelos. Un cambio de precio del proveedor se refleja el mismo día. Si te estás preguntando si ejecutar esta compilación en absoluto, o cuánto de tu stack puede soportar, esa es la forma económica de comparar la versión censurada con ella sin un segundo contrato ni un segundo código base.

Empieza aquí

Resumen de la decisión. Se necesita: una cuenta de Hugging Face con los términos del repositorio aceptados; un nodo de clase Hopper o superior — el comando de la tarjeta apunta a 8 GPUs y del orden de 265 GB de VRAM de GPU según la guía de la receta oficial para el checkpoint FP8 correspondiente; la imagen vLLM del día 0 y transformers 5.16+; y aproximadamente 186 GB de disco para los pesos.

Orden de ejecución: acepta los términos del repositorio → descarga los pesos → obtén la imagen day-0 → sirve con --enable-expert-parallel → verifica con una solicitud a :8000/v1/chat/completions → luego inicia tus evaluaciones. Si una carga falla con un error de forma aparente, revisa la bandera antes de revisar la descarga.

Y mantenga el marco. Este es un instrumento de investigación, publicado bajo esa condición. Sus números son las mediciones indicativas propias del proveedor sobre su propia edición. Su comportamiento de seguridad es el punto del ejercicio, no un error que haya que sortear. Sírvalo, mídalo y ponga su propia moderación entre él y cualquier cosa humana.

Las cinco compilaciones de Flash-Next — BF16, GGUF, MLX, FP8 y NVFP4 — están reunidas en la colección Qwen3.8-Flash-Next-Uncensored en Hugging Face.

Un modelo diferente, no otra compilación de este: Qwen3.8-27B-Uncensored está ablacionado de una base diferente y tiene su propia colección y sus propios runbooks.

Estos pesos son solo locales por diseño. Para contar con una línea base alojada contra la cual medir la compilación abliterada, Qwen3.8-Flash se sirve en OrcaRouter al precio de lista del proveedor con un margen del 0 % — el modelo estándar, con la alineación de seguridad intacta.