Qwen 3.6 35B en DGX Spark: Benchmarks de Tokens por Segundo
Benchmarks reales de Qwen 3.6 35B-A3B en DGX Spark: de 30 a 120 tokens/s, por qué la concurrencia es el techo y cuándo pasar a GPUs de datacenter.
Qwen 3.6 35B en DGX Spark: Benchmarks de Tokens por Segundo
En un NVIDIA DGX Spark, Qwen 3.6 35B-A3B decodifica a aproximadamente 28 o 30 tokens por segundo con una configuración estándar de vLLM en FP8, y entre 97 y 120 tokens por segundo con cuantización NVFP4 y un motor optimizado. Esa velocidad en flujo único es perfectamente utilizable para un desarrollador, pero no es un número de producción para servir peticiones.
El motivo por el que funciona bien es la arquitectura. Qwen 3.6 35B-A3B es un modelo de mezcla de expertos que activa solo unos 3.000 millones de sus 35.000 millones de parámetros por token, de modo que un modelo denso de 70B en el mismo equipo apenas alcanza 2,7 tokens por segundo en comparación. El límite real en el Spark es la concurrencia: el ancho de banda de memoria limita el rendimiento agregado mucho antes de alcanzar la carga de producción multiusuario. A continuación se presentan los números reales y dónde está el techo.
Tokens por segundo según la configuración
La cifra principal depende casi por completo de la cuantización y del motor de inferencia. Esto es lo que reportan los benchmarks independientes para Qwen 3.6 35B-A3B en un único DGX Spark, en flujo único:
| Configuración (cuantización / motor) | Decodificación en flujo único | Notas |
|---|---|---|
| vLLM estándar, FP8 | ~28-30 tok/s | Aproximadamente el 32 % del techo teórico de ~91 tok/s de ancho de banda |
| FP8 + decodificación especulativa (MTP-3) | ~64 tok/s | Predicción multitóken |
| Build DFlash | ~50 tok/s | Build comunitario optimizado |
| Cuantización NVFP4 | ~97 tok/s | Aproximadamente el doble que FP8 simple |
| Motor Atlas, NVFP4 | ~120 tok/s | Mantenido en un contexto de 1 millón de tokens |
La dispersión es amplia porque la decodificación en el Spark está limitada por el ancho de banda de memoria, no por el cómputo. Todo lo que reduce los bytes leídos por token (cuantización de menor precisión, decodificación especulativa, kernels más ligeros) mejora el número. NVFP4 aproximadamente duplica el resultado de FP8 simple, y el motor Atlas, una pila de inferencia en Rust puro con kernels personalizados, mantiene unos 120 tokens por segundo incluso en un contexto de un millón de tokens (Flowtivity).
Por qué un modelo de 35B funciona en un equipo con 273 GB/s
El DGX Spark combina un chip GB10 Grace Blackwell con 128 GB de memoria unificada LPDDR5X, y esa memoria alcanza un máximo de unos 273 GB/s de ancho de banda compartido entre CPU y GPU (LMSYS). Para la generación de texto, ese ancho de banda lo es todo.
La inferencia se ejecuta en dos fases con perfiles muy distintos. El prefill, que lee el prompt, está limitado por el cómputo y es rápido: el Spark procesa entre 800 y más de 2.000 tokens por segundo en esa fase. La decodificación, que escribe la respuesta token a token, está limitada por la memoria, porque cada token requiere leer los pesos activos del modelo desde la memoria. Ahí es donde el techo de 273 GB/s se hace notar.
Por eso el diseño de mezcla de expertos importa tanto. Un modelo denso de 70B tiene que leer los 70.000 millones de pesos en cada token, lo que lo reduce a unos 2,7 tokens por segundo en el Spark (LMSYS). Qwen 3.6 35B-A3B lee solo sus aproximadamente 3.000 millones de parámetros activos por token, mueve muchos menos datos y se sitúa un orden de magnitud por encima. La arquitectura MoE es lo que hace que un modelo de clase 35B sea agradable de usar en un equipo de escritorio.
¿Qué configuración conviene usar?
Para el uso local diario, NVFP4 es la configuración que merece la pena perseguir. Aproximadamente duplica el rendimiento de un build FP8 simple y sitúa a Qwen 3.6 35B-A3B en el rango de 97 a 120 tokens por segundo, suficientemente rápido para que el modelo se sienta ágil en un bucle de chat. La contrapartida es el esfuerzo de configuración: NVFP4 y motores como Atlas son más recientes y menos inmediatos que una instalación estándar de vLLM, así que conviene prever tiempo para la cuantización y la compatibilidad de kernels.
Si solo se quiere tener el modelo funcionando con la menor fricción posible, vLLM estándar en FP8 llega a unos 30 tokens por segundo y funciona de inmediato. Es más lento que las cifras principales, pero para desarrollo de un solo usuario, completado de código o prueba de prompts es perfectamente válido. La decodificación especulativa, o predicción multitóken, es un camino intermedio que eleva FP8 a unos 64 tokens por segundo sin cambiar la cuantización.
Cualquiera que sea la elección, la cifra en flujo único es lo que se está optimizando. Ninguna de estas configuraciones cambia la situación de concurrencia que se describe a continuación, porque ese techo lo fija el hardware, no el software.
Qué ocurre bajo concurrencia
La velocidad en flujo único es el número que se cita. También es el más favorable. En el momento en que se sirven más de una petición a la vez, cada flujo compite por el mismo canal de 273 GB/s y la aritmética cambia.
Con un despliegue estándar de vLLM en FP8, el rendimiento agregado sube a unos 156 tokens por segundo con 32 flujos concurrentes, pero escala de forma sublineal y la latencia por usuario se degrada con fuerza. Con 32 flujos, el tiempo por token de salida alcanza unos 195 milisegundos, aproximadamente 5 tokens por segundo por usuario (benchmark de rikkarth). Eso es aceptable para un trabajo por lotes nocturno y demasiado lento para un chat interactivo. NVFP4 lo hace mejor, alcanzando unos 322 tokens por segundo agregados con 8 flujos concurrentes, pero eso sigue siendo solo unos 42 tokens por segundo por usuario (benchmark de concurrencia NVFP4), y la curva sigue aplanándose al añadir carga.
Así que el resumen honesto no es «se rompe por encima de cuatro usuarios». Es que el techo agregado del Spark se sitúa en los cientos bajos de tokens por segundo, y se sacrifica la capacidad de respuesta por usuario para llegar ahí. Para un desarrollador, un equipo de investigación pequeño o una carga de trabajo de un único inquilino sensible a la privacidad, es más que suficiente. Para tráfico de producción con decenas o cientos de usuarios concurrentes y un objetivo de latencia, no es ni de lejos suficiente.
El DGX Spark es un equipo de desarrollo, no un servidor de producción
Nada de esto es una crítica al Spark. Es una de las mejores máquinas de desarrollo de IA local que se pueden poner sobre un escritorio. Los 128 GB de memoria unificada permiten cargar modelos que no caben en una GPU de consumo, consume poca energía y mantiene los datos completamente en local (NVIDIA). Para prototipar con Qwen 3.6, experimentos de ajuste fino, investigación sin conexión o un único usuario avanzado, es casi ideal.
El error es tratar ese benchmark en flujo único como un número de servicio. La inferencia en producción es un problema de concurrencia, y la concurrencia en el Spark está limitada por un bus de memoria que una GPU de centro de datos supera en más de diez veces. Un acelerador de clase H100 con HBM mueve más de 3 TB/s, por lo que mantiene alta velocidad en flujo único y alta concurrencia al mismo tiempo, que es exactamente lo que necesita el servicio multiinquilino. El Spark es donde se construye y se prueba. No es donde se pone el modelo cuando llega el tráfico real.
Servir Qwen 3.6 en producción
Cuando se supera la capacidad del escritorio, no hace falta comprar un rack. Tessera sirve Qwen 3.6 35B-A3B en GPUs de centro de datos con memoria de alto ancho de banda, por lo que los límites de latencia por usuario y concurrencia que se alcanzan en un Spark no aplican. Se obtiene rendimiento sostenido bajo carga concurrente, una API compatible con OpenAI para que el código cliente existente funcione con solo cambiar la URL base, y precios mensuales fijos en lugar de facturación por token que convierte un pico de tráfico en una factura inesperada.
Tessera ejecuta únicamente modelos de código abierto, en clústeres de GPU dedicados en la UE y LATAM, con residencia de datos en la UE para los equipos que la necesiten. Si se está evaluando Qwen 3.6 en local para decidir si es suficientemente bueno, casi con toda seguridad lo es: consulta los benchmarks completos de Qwen 3.6 35B y los resultados específicos de programación para el lado de la calidad. El Spark responde a «¿es este modelo suficientemente rápido para mí?». Tessera responde a «¿es suficientemente rápido para todos, a la vez?».
Preguntas frecuentes
¿Cuántos tokens por segundo genera Qwen 3.6 35B en un DGX Spark?
Unos 28 o 30 tokens por segundo en flujo único con una configuración estándar de vLLM en FP8, y entre 97 y 120 tokens por segundo con cuantización NVFP4 y un motor optimizado como Atlas. La decodificación está limitada por el ancho de banda de memoria de 273 GB/s del Spark.
¿Por qué Qwen 3.6 35B es mucho más rápido que un modelo de 70B en el mismo hardware?
Qwen 3.6 35B-A3B es un modelo de mezcla de expertos que activa solo unos 3.000 millones de sus 35.000 millones de parámetros por token, por lo que lee muchos menos datos de la memoria por token. Un modelo denso de 70B lee todos sus pesos en cada token y cae a unos 2,7 tokens por segundo.
¿Puede un DGX Spark servir Qwen 3.6 a varios usuarios a la vez?
Solo a pequeña escala. El rendimiento agregado alcanza un máximo en los cientos bajos de tokens por segundo (unos 156 tok/s con 32 flujos en FP8, unos 322 tok/s con 8 flujos en NVFP4), y la latencia por usuario se degrada al añadir flujos. Funciona para un desarrollador o un equipo pequeño, pero el servicio multiusuario en producción necesita GPUs de centro de datos con memoria de alto ancho de banda.
¿Es el DGX Spark adecuado para ejecutar Qwen 3.6 en local?
Sí, para un único usuario o un equipo pequeño es excelente. Los 128 GB de memoria unificada alojan Qwen 3.6 35B-A3B con comodidad, la velocidad en flujo único es ágil con NVFP4 y los datos nunca salen del equipo. Deja de ser la herramienta adecuada cuando se necesita servir a muchos usuarios concurrentes con un objetivo de latencia, que es un trabajo para GPUs de centro de datos.