DEV Community

Cover image for Qwen3.8-27B-FP8: Alibaba lanza FP8 nativo y reasoning effort
lu1tr0n
lu1tr0n

Posted on • Originally published at elsolitario.org

Qwen3.8-27B-FP8: Alibaba lanza FP8 nativo y reasoning effort

Alibaba subió a Hugging Face un nuevo checkpoint de su familia Qwen: Qwen3.8-27B-FP8, un modelo de 27.000 millones de parámetros que llega ya cuantizado en FP8 de fábrica y que deja elegir, petición por petición, cuánto tiempo quiere "pensar" antes de responder.

La ficha del modelo expone el chat template completo en formato Jinja, y ahí aparecen los detalles más interesantes: control explícito de esfuerzo de razonamiento, tool calling nativo con sintaxis tipo XML y soporte de visión para imágenes y video dentro del mismo checkpoint.

TL;DR

  • Alibaba publicó Qwen3.8-27B-FP8 en Hugging Face, un checkpoint nativo en FP8 de 27.000 millones de parámetros.- El chat template del modelo permite elegir el nivel de reasoning_effort: xhigh (por defecto), medium o low.- Con xhigh, el sistema inyecta la instrucción de validar supuestos y considerar alternativas antes de responder.- Con low, la instrucción pide mantener el razonamiento breve y llegar directo a la conclusión.- El modelo soporta tool calling nativo con sintaxis XML: tool_call, function y parameter anidados.- También procesa imágenes y video mediante tokens de visión dentro del mismo checkpoint FP8.- FP8 nativo reduce el tamaño en disco y en VRAM frente a un checkpoint BF16 equivalente, pero pide GPU con soporte FP8 (Hopper, Ada, Blackwell).

Introducción

Qwen3.8-27B-FP8 pertenece a la familia de modelos abiertos que Alibaba publica bajo el usuario Qwen en Hugging Face. Lo distintivo de este lanzamiento no es solo el tamaño (27B parámetros, un punto intermedio entre un modelo liviano para laptop y uno de frontera que necesita un clúster), sino que el checkpoint viene nativamente cuantizado en FP8: no es un modelo BF16 que vos cuantizás después con bitsandbytes o AWQ, sino pesos entrenados y publicados directamente en ese formato.

El segundo punto relevante está en el chat template, el archivo Jinja que define cómo se arma el prompt final que recibe el modelo. Ahí Alibaba documentó, en el propio template, un mecanismo de control de esfuerzo de razonamiento (reasoning_effort) que cualquier desarrollador puede activar desde transformers sin tocar los pesos ni cambiar de modelo.

Qué pasó

El repositorio Qwen/Qwen3.8-27B-FP8 quedó publicado en Hugging Face con su tokenizer_config.json incluyendo un chat template extenso que resuelve varias cosas al mismo tiempo: construcción de mensajes multimodales (texto, imagen y video), inyección de instrucciones de sistema según el esfuerzo de razonamiento elegido, y serialización de llamadas a herramientas en un formato basado en etiquetas.

A diferencia de otros modelos donde el "nivel de pensamiento" se controla con un parámetro de generación separado o con un prompt manual, acá el propio template resuelve el routing: si no pasás nada, asume xhigh por defecto, y solo cambia de comportamiento si vos explícitamente pedís medium, low o desactivás el razonamiento con enable_thinking=false.

Contexto e historia

La familia Qwen viene evolucionando desde 2023 como una de las líneas de modelos abiertos más activas, junto con Llama, Mistral y DeepSeek. Cada generación fue sumando capacidades que antes vivían en modelos separados: primero contexto largo, después visión, luego tool calling estructurado y, más recientemente, modos explícitos de razonamiento con bloques de thinking visibles (el patrón que popularizaron modelos como QwQ y DeepSeek R1).

Qwen3.8-27B-FP8 consolida esas tres capacidades (visión, tool calling y razonamiento configurable) en un único checkpoint, y además resuelve el problema de tamaño publicando directamente en FP8 en lugar de dejar la cuantización como tarea del usuario final.
FP8 nativo: menos memoria por parámetro, pero exige tensor cores compatibles.

Detalles técnicos y rendimiento

Lo más útil para un desarrollador que evalúa Qwen3.8-27B-FP8 es entender los tres mecanismos que expone el chat template, porque determinan cómo se integra en un pipeline real.

Reasoning effort

El template define tres niveles de esfuerzo de razonamiento. Con xhigh (el valor por defecto cuando enable_thinking está activo), el sistema recibe literalmente esta instrucción: "Reasoning effort is set to xhigh. Please think carefully through the task, validate key assumptions, consider plausible alternatives, and prioritize correctness, consistency, and clarity in the final answer." Con low, la instrucción cambia a: "Reasoning effort is set to low. Keep your thinking brief and focused, moving directly to the conclusion without unnecessary elaboration." El nivel medium no agrega instrucción adicional: es el punto neutro.
NivelCuándo usarloComportamientoContrapartidaxhigh (por defecto)Matemáticas, código, análisis multi-pasoValida supuestos y considera alternativas antes de responderMás tokens de pensamiento, más latencia y costomediumUso general, tareas de dificultad mediaSin instrucción adicional en el prompt de sistemaPunto intermedio entre velocidad y profundidadlowAgentes con latencia crítica, clasificación, extracciónVa directo a la conclusión, sin elaboración extraMenos verificación interna del propio modelo

Tool calling nativo

El template arma un bloque de sistema con la lista de funciones disponibles bajo un tag tools en formato JSON, y le indica al modelo que responda exclusivamente con un bloque tool_call que envuelve un function con nombre y parámetros. Es una sintaxis basada en etiquetas, no en JSON puro como OpenAI, y el propio template advierte que los parámetros requeridos deben estar presentes y que no hay que agregar texto después del bloque de llamada.

Visión y video

El template también resuelve mensajes multimodales: cuando un item del mensaje trae una imagen, inserta los tokens <|vision_start|><|image_pad|><|vision_end|>; si es video, usa el equivalente con video_pad. Con add_vision_id activo, el modelo incluso numera las imágenes ("Video 1:", "Video 2:") cuando hay varias en la misma conversación.

flowchart TD
A["Peticion del usuario"] --> B{"reasoning_effort?"}
B -->|"xhigh"| C["Valida supuestos y alternativas"]
B -->|"medium"| D["Sin instruccion extra"]
B -->|"low"| E["Va directo a la conclusion"]
C --> F["Respuesta final"]
D --> F
E --> F
Enter fullscreen mode Exit fullscreen mode

⚠️ Ojo: FP8 nativo no corre a velocidad completa en cualquier GPU. Necesitás tensor cores con soporte FP8 (Hopper H100, Ada L4/L40, Blackwell); en una Ampere A100 el runtime suele hacer upcast a BF16 y perdés buena parte de la ventaja de memoria.

Cómo empezar a probarlo

Para levantar Qwen3.8-27B-FP8 localmente con transformers, el flujo es el mismo en Windows, macOS y Linux; solo cambia cómo activás el entorno virtual.

Windows (PowerShell):

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install --upgrade transformers accelerate torch
Enter fullscreen mode Exit fullscreen mode

macOS / Linux:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade transformers accelerate torch
Enter fullscreen mode Exit fullscreen mode

Con el entorno listo, cargar el modelo y generar una respuesta con esfuerzo de razonamiento bajo (útil para probar rápido) se ve así:

from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "Qwen/Qwen3.8-27B-FP8"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype="auto", device_map="auto")

mensajes = [{"role": "user", "content": "Explicame que es FP8 en dos oraciones"}]
prompt = tokenizer.apply_chat_template(
    mensajes,
    tokenize=False,
    add_generation_prompt=True,
    reasoning_effort="low"
)
entradas = tokenizer(prompt, return_tensors="pt").to(model.device)
salida = model.generate(**entradas, max_new_tokens=200)
print(tokenizer.decode(salida[0][entradas.input_ids.shape[1]:], skip_special_tokens=True))
Enter fullscreen mode Exit fullscreen mode

Este primer ejemplo pide una respuesta corta y directa. Para un caso más realista, con tool calling y esfuerzo de razonamiento alto porque la tarea requiere elegir bien qué función invocar:

tools = [
    {
        "name": "consultar_tipo_cambio",
        "description": "Devuelve el tipo de cambio actual del dolar en un pais de LATAM",
        "parameters": {
            "type": "object",
            "properties": {
                "pais": {"type": "string", "description": "Nombre del pais, ej: Argentina, Mexico, Chile"}
            },
            "required": ["pais"]
        }
    }
]

mensajes = [{"role": "user", "content": "Cual es el tipo de cambio del dolar en Argentina hoy?"}]
prompt = tokenizer.apply_chat_template(
    mensajes,
    tools=tools,
    tokenize=False,
    add_generation_prompt=True,
    reasoning_effort="xhigh"
)
# El modelo responde con:
# 
# 
# 

# Argentina
# 
# 
# 
Enter fullscreen mode Exit fullscreen mode

Para confirmar que el nivel de esfuerzo realmente se aplicó, no hace falta generar texto: alcanza con imprimir el prompt devuelto por apply_chat_template antes de tokenizarlo. Si pasaste reasoning_effort="xhigh", vas a ver la instrucción de "validate key assumptions, consider plausible alternatives" inyectada en el mensaje de sistema; con "low", en cambio, aparece la instrucción de ir directo a la conclusión. Es la forma más rápida de verificar que el parámetro no se ignoró.

Para servir el modelo en producción con mejor rendimiento que transformers puro, la ruta habitual es vLLM, que soporta checkpoints FP8 de forma nativa:

pip install vllm
vllm serve Qwen/Qwen3.8-27B-FP8 --port 8000
Enter fullscreen mode Exit fullscreen mode

Impacto y análisis

El aporte central de Qwen3.8-27B-FP8 no es un número de benchmark, sino un cambio de diseño: mover la decisión de "cuánto razonar" del lado del prompt de sistema hacia un parámetro documentado del chat template. Eso simplifica el trabajo de quien construye agentes: en vez de mantener dos modelos (uno rápido para tareas triviales, otro lento para tareas complejas) o escribir prompts manuales para simular ese comportamiento, alcanza con un argumento en apply_chat_template.

El costo de esa flexibilidad aparece en la infraestructura. Publicar el checkpoint directamente en FP8 reduce el espacio en disco y en VRAM frente a un equivalente en BF16, pero ata la eficiencia real del modelo al hardware disponible. Un equipo que todavía corre GPUs Ampere (A100, RTX 30xx) no va a ver la ventaja completa de memoria, porque esas tarjetas no tienen tensor cores FP8 nativos y el runtime termina haciendo upcast.

💡 Tip: en pipelines de agentes con muchas llamadas triviales (clasificar, extraer un campo, decidir si llamar o no una herramienta), probá primero con reasoning_effort="low": bajás tokens de pensamiento y latencia, y reservás xhigh solo para los pasos que de verdad lo necesitan.

Otro punto a tener en cuenta: el formato de tool calling con etiquetas (tool_call/function/parameter) no es JSON puro como el de la API de OpenAI o Anthropic. Si tu framework de agentes espera JSON estricto en la respuesta de la herramienta, vas a necesitar un parser propio o una capa de adaptación antes de conectar Qwen3.8-27B-FP8 a herramientas ya escritas para otro formato.

Qué sigue

Lo esperable es que el patrón de reasoning_effort configurable, que ya usan modelos de OpenAI y Anthropic bajo otros nombres, se termine de estandarizar entre los modelos abiertos: hoy cada familia lo expone con su propio nombre de parámetro y su propio texto de instrucción, lo que obliga a reescribir la lógica de integración cada vez que se cambia de modelo.

Para equipos en LATAM que evalúan modelos abiertos con soporte multimodal y tool calling en un solo checkpoint, Qwen3.8-27B-FP8 vale la pena probarlo primero en un entorno con GPU alquilada (RunPod, Lambda, o una instancia con H100/L4) antes de decidir compra de hardware propio, justamente por la dependencia de tensor cores FP8.
El tool calling de Qwen3.8-27B-FP8 usa etiquetas, no JSON puro.
📖 Resumen en Telegram: Ver resumen

Probalo vos: corré pip install transformers accelerate torch y cargá Qwen/Qwen3.8-27B-FP8 desde la ficha oficial en Hugging Face para ver el reasoning_effort en acción hoy mismo.

Preguntas frecuentes

¿Qué significa que el checkpoint sea "FP8 nativo"?

Que los pesos se entrenaron y publicaron directamente en formato de 8 bits de punto flotante, sin pasar por un proceso de cuantización posterior a cargo del usuario, como sí ocurre con checkpoints BF16 que después se cuantizan con AWQ o GPTQ.

¿Qué diferencia hay entre reasoning_effort xhigh, medium y low?

Cada nivel inyecta una instrucción distinta en el mensaje de sistema del chat template. xhigh pide validar supuestos y considerar alternativas, low pide ir directo a la conclusión, y medium no agrega instrucción adicional.

¿Qwen3.8-27B-FP8 soporta imágenes y video?

Sí, el chat template inserta tokens específicos de visión (vision_start, image_pad o video_pad, vision_end) para cada item multimodal del mensaje.

¿Cómo llamo a herramientas (tool calling) con este modelo?

Pasando la lista de funciones en el parámetro tools de apply_chat_template. El modelo responde con un bloque de etiquetas tool_call que envuelve el nombre de la función y sus parámetros.

¿Qué hardware necesito para correrlo con ventaja real?

Una GPU con tensor cores FP8 nativos: Hopper (H100), Ada Lovelace (L4, L40) o Blackwell. En GPUs Ampere el runtime puede hacer upcast a BF16 y se pierde parte de la ventaja de memoria.

¿Es compatible con vLLM?

Sí, vLLM soporta checkpoints FP8 de forma nativa y permite levantar el modelo como servidor compatible con la API de OpenAI con vllm serve.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Top comments (0)