NVIDIA publica Qwen3.6-35B-A3B-NVFP4: una versión cuantizada en FP4 para despliegues con vLLM

Resumen de Qwen3.6-35B-A3B-NVFP4, publicado por NVIDIA en Hugging Face: origen del modelo, cuantización NVFP4, comandos de despliegue con vLLM, requisitos de hardware, resultados de evaluación y límites de uso.

NVIDIA ha publicado nvidia/Qwen3.6-35B-A3B-NVFP4 en Hugging Face. Es una versión cuantizada basada en Qwen3.6-35B-A3B de Alibaba, procesada con NVIDIA Model Optimizer, cuyo objetivo es facilitar que los desarrolladores desplieguen el modelo en vLLM, Agent, RAG, chatbots y otros escenarios de inferencia.

La tarjeta del modelo indica que usa la licencia Apache-2.0 y puede utilizarse en escenarios comerciales y no comerciales. Un punto importante es que NVIDIA aclara explícitamente que este modelo no es un modelo base desarrollado por NVIDIA, sino una versión cuantizada del modelo de terceros Qwen3.6-35B-A3B.

Información básica del modelo

Según la tarjeta del modelo, los parámetros clave de Qwen3.6-35B-A3B-NVFP4 son los siguientes:

  • Modelo base: Qwen/Qwen3.6-35B-A3B
  • Publicador: NVIDIA
  • Herramienta de cuantización: NVIDIA Model Optimizer
  • Licencia: Apache-2.0
  • Arquitectura: Transformer
  • Estructura de red: MoE with Hybrid Attention
  • Escala de parámetros: 35B parámetros totales, 3B parámetros activados
  • Entrada: texto, imágenes, video
  • Salida: texto
  • Longitud de contexto: hasta 262K
  • Motor de inferencia: vLLM
  • Hardware recomendado: NVIDIA Hopper, NVIDIA Blackwell
  • Sistema recomendado: Linux

La barra lateral de la página de Hugging Face también muestra información sobre el tamaño de los archivos del modelo y los tipos de tensores. Al leerla, no conviene equiparar directamente esas estadísticas de archivos con los parámetros arquitectónicos del modelo base.

Qué hace la cuantización NVFP4

El punto central de esta versión es la cuantización NVFP4. La descripción de la tarjeta del modelo menciona que NVIDIA aplicó cuantización NVFP4 a los pesos de Qwen3.6-35B-A3B para que pueda usarse con inferencia en vLLM.

Esta cuantización no consiste en comprimir todo de forma brusca a 4-bit. En cambio, procesa los pesos y las activaciones de los operadores lineales dentro del MoE Transformer block. El resultado oficial es que el ancho de bits por parámetro baja de 16 bit a 4 bit, mientras que el uso de disco y los requisitos de memoria GPU se reducen aproximadamente 3.06 veces.

Para el despliegue, el valor de una versión precuantizada de este tipo es directo: no hace falta volver a ejecutar el flujo de cuantización por cuenta propia, y se puede probar directamente el throughput, el uso de memoria y el comportamiento de inferencia con contexto largo.

Comando de despliegue con vLLM

El comando básico de inicio que proporciona la tarjeta del modelo es:

1
vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 --port 8000 --quantization modelopt --max-model-len 262144 --reasoning-parser qwen3

Este comando conserva la longitud de contexto de 262K y es adecuado para validar primero las capacidades del modelo en un entorno con mucha memoria GPU. Si la memoria es limitada, se puede reducir primero --max-model-len y aumentarlo después de forma gradual.

Para NVIDIA DGX Spark, la tarjeta del modelo ofrece otro conjunto de variables de entorno y parámetros de vLLM:

1
2
3
4
5
export VLLM_USE_FLASHINFER_MOE_FP4=0
export VLLM_FP8_MOE_BACKEND=flashinfer_cutlass
export FLASHINFER_DISABLE_VERSION_CHECK=1
export CUTE_DSL_ARCH=sm_121a
vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 --port 8000 --tensor-parallel-size 1 --trust-remote-code --dtype auto --quantization modelopt --kv-cache-dtype fp8 --attention-backend flashinfer --moe-backend marlin --gpu-memory-utilization 0.85 --max-model-len 65536 --max-num-seqs 4 --max-num-batched-tokens 8192 --enable-chunked-prefill --async-scheduling --enable-prefix-caching --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}'

Este conjunto de parámetros está más orientado al ajuste de despliegues reales: reduce el contexto a 65536, activa FP8 KV cache, chunked prefill y prefix caching, y configura speculative decoding. No es algo que pueda copiarse y ejecutarse directamente en cualquier máquina. En particular, parámetros como CUTE_DSL_ARCH=sm_121a, FlashInfer y el MoE backend dependen de la GPU, el controlador, CUDA y la versión de vLLM concretos.

Cómo leer los resultados de evaluación

La tarjeta del modelo compara la línea base BF16 con la versión cuantizada NVFP4:

Precision MMLU Pro GPQA Diamond τ²-Bench Telecom SciCode AIME 2025 AA-LCR IFBench MMMU Pro
BF16 85.6 84.9 95.5 40.8 89.2 62.0 62.3 74.1
NVFP4 85.0 84.8 94.7 40.6 88.8 62.0 62.8 74.5

Según la tabla, NVFP4 presenta pequeñas variaciones frente a BF16: algunas métricas bajan ligeramente, mientras que IFBench y MMMU Pro incluso suben un poco. Una lectura más prudente es que esta versión cuantizada intenta mantenerse cerca de BF16 en estos benchmarks públicos, pero antes de desplegarla sigue siendo necesario probarla con datos propios del negocio.

Esto es especialmente importante en escenarios como Agent, RAG, generación de código y recuperación con contexto largo. Los benchmark públicos solo ofrecen una referencia. Antes de llevarlo a producción, conviene comprobar:

  • Si sigue instrucciones de forma estable con contextos largos;
  • Si ignora materiales citados en escenarios RAG;
  • Si las llamadas a herramientas tienden a generar parámetros incorrectos;
  • Si las entradas en chino, inglés y multimodales cumplen los requisitos del negocio;
  • Si el throughput y la latencia son aceptables con configuraciones de poca memoria.

Para qué escenarios encaja

Este modelo encaja mejor con equipos que ya planean usar GPU NVIDIA y vLLM para servicios de inferencia. Algunos escenarios típicos son:

  • Chatbots locales o privados;
  • Preguntas y respuestas sobre bases de conocimiento RAG;
  • Planificación y llamadas a herramientas en sistemas Agent;
  • Lectura y resumen de documentos largos;
  • Pruebas de inferencia con modelos grandes que requieren menos memoria GPU;
  • Equipos de despliegue que quieren comparar los resultados de cuantización BF16 y FP4.

Si solo se quiere probar de forma casual en una GPU de consumo común, primero hay que confirmar la memoria disponible, la versión de vLLM y el soporte de cuantización. Un modelo precuantizado puede reducir la barrera de despliegue, pero eso no significa que todo el hardware pueda ejecutar sin problemas un contexto de 262K.

Límites de uso

La tarjeta del modelo también recuerda limitaciones habituales: los datos de entrenamiento del modelo base proceden de internet y pueden contener contenido dañino y sesgos sociales. Por eso, ante ciertos prompts, el modelo puede amplificar sesgos, generar contenido inexacto, omitir información clave o producir texto inapropiado.

Si se usa en producción, conviene añadir al menos varias capas de protección:

  • Realizar evaluaciones de seguridad para los escenarios del negocio;
  • Añadir validación de resultados para RAG y llamadas a herramientas;
  • Incorporar revisión humana para salidas de alto riesgo;
  • Registrar la versión de inferencia, la configuración de cuantización y los parámetros de vLLM;
  • Mantener un plan para volver a otros modelos o a la versión BF16 en tareas importantes.

Resumen

El valor de nvidia/Qwen3.6-35B-A3B-NVFP4 está en convertir Qwen3.6-35B-A3B en una versión cuantizada de NVIDIA que puede desplegarse directamente con vLLM. NVFP4 reduce la presión sobre la memoria GPU y el disco, y las evaluaciones oficiales también muestran que se acerca a BF16 en varias métricas.

Aun así, sigue siendo un modelo de inferencia que requiere validación de ingeniería. Antes de un despliegue real, no basta con mirar las puntuaciones de benchmark: hay que probarlo junto con el hardware propio, la longitud de contexto, los datos RAG, la cadena de herramientas Agent y los requisitos de seguridad.

Enlaces de referencia:

记录并分享
Creado con Hugo
Tema Stack diseñado por Jimmy