Un desarrollador lleva seis semanas usando Qwen3.8-Flash-Next, un modelo MoE de 125.000 millones de parámetros, como único LLM de producción en un NVIDIA DGX Spark de sobremesa con 128 GB de memoria unificada, y ha publicado en GitHub la imagen, la configuración de vLLM y los scripts para reproducirlo. El montaje comparte máquina con un modelo de embeddings y con Whisper, alcanza unos 55 tokens por segundo en una sola petición y, según su autor, la clave no está en el modelo, sino en reducir los bits que hay que leer en cada paso de generación.
Las claves de Qwen3.8-Flash-Next en un DGX Spark en 20 segundos
- Qwen3.8-Flash-Next corre en producción en un DGX Spark con 128 GB de memoria unificada.
- El autor mide unos 55 tokens/s por petición y unos 145 agregados con 10 usuarios.
- NVFP4, FP8 y decodificación especulativa permiten encajar un modelo que pesa 135 GB.
- Todo está en GitHub y sirve para cualquier equipo con GB10.
El proyecto, publicado por el usuario aseth0 en el repositorio aseth0/qwen3.8-flash-next-gb10 con licencia Apache 2.0, interesa a cualquier administrador que esté valorando servir modelos grandes en local. Muestra con números qué optimizaciones funcionan en el chip GB10 de NVIDIA, cuáles no y cuánta memoria queda para el resto de servicios.
El modelo y la máquina
Qwen3.8-Flash-Next es el modelo MoE (mezcla de expertos) que Alibaba presentó en agosto de 2026. Según la receta oficial de vLLM y las especificaciones publicadas, suma 125.000 millones de parámetros, de los que solo unos 6.000 millones se activan en cada token, y añade una tabla de embeddings n-gram de 51.000 millones de parámetros. Combina capas Gated DeltaNet, un tipo de atención lineal con estado, con capas de atención dispersa, e incluye un módulo de predicción multitoken (MTP) que sirve para la decodificación especulativa. La receta de vLLM recomienda para la versión FP8 uno o varios GB300 o servidores con ocho H100 o H200.
El DGX Spark, en cambio, es un equipo de sobremesa con el superchip GB10 y 128 GB de memoria unificada compartida entre CPU y GPU. Sobre esa máquina, el autor sirve el modelo con vLLM v0.30 en un endpoint compatible con la API de OpenAI y deja sitio para bge-m3, que genera embeddings, y para Whisper, que transcribe audio. Según su publicación, el conjunto ocupa unos 105 GiB.
Cómo cabe un modelo de 135 GB en 128 GB
En NVFP4, el formato de 4 bits de NVIDIA, el modelo pesa unos 135 GB, más que la memoria disponible. El autor explica que lo resolvió con cuatro cambios, todos medidos:
- Tabla n-gram en NVFP4 servida por mmap: la tabla PLE, de unos 27 GB una vez cuantizada, se mapea en memoria en lugar de cargarse entera.
- Cabeza de draft en NVFP4: el especulador MTP-3 leía 1,27 GB de la capa de salida en BF16 tres veces por paso. Cuantizarla aportó entre un 13 % y un 25 % más de velocidad.
- Capas lineales densas en FP8: las 145 capas pasaron a FP8, con un 16 % más de velocidad en código y sin pérdida en HumanEval+.
- vLLM v0.30 con un parche para el estado del bloque recurrente: según el autor, aporta un 5 % más con carga concurrente.
Igual de útil es la lista de lo que probó y descartó. Bajar de 10 expertos activos rompía la calidad sin ganar velocidad. Guardar la caché KV en FP8 aumentaba la capacidad, pero reducía un 11 % la velocidad de generación sin permitir más usuarios simultáneos. MTP-4 empataba con MTP-3 y consumía más memoria. El README añade un aviso práctico: con temperatura 0, el modelo entra en bucles.
Rendimiento medido y diferencias con el repositorio
En su publicación en LinkedIn, el autor da estas cifras propias: 96,3 % en HumanEval+, frente al 92,7 % de Qwen3.8-27B en FP8; 0,865 en τ²-bench sobre 74 tareas agénticas largas con herramientas, frente al 0,770 del modelo de 27B; unos 55 tokens por segundo en código y 52 en prosa con una petición, con un techo de unos 145 tokens por segundo agregados con 10 usuarios; y unos 310.000 tokens de caché KV, con caché de prefijos que empieza a acertar desde unos 1.600 tokens.
Conviene tener en cuenta que el README del repositorio, con mediciones fechadas entre el 26 de septiembre y el 5 de octubre de 2026, recoge algunos datos distintos: 95,7 % en HumanEval+ base y 91,5 % en la variante plus, 0,784 en τ²-bench (58 de 74 tareas) y 239.238 tokens de caché KV, con unos 121 GiB de memoria unificada necesarios. Las cifras de velocidad sí coinciden, entre 50,6 y 55,9 tokens por segundo con una petición y unos 145 agregados. La publicación puede reflejar ajustes posteriores, pero quien quiera replicarlo debería contrastarlo con su propia ejecución.
Para un administrador, los requisitos prácticos son claros: un equipo con GB10, como el DGX Spark o el ASUS Ascent GX10, unos 235 GB de disco para pesos e imagen, y la configuración fijada por digest para evitar sorpresas con nuevas versiones de vLLM. Con GPU dedicada, el autor estima unos 86 GiB de VRAM y 100 GiB de RAM, aunque la configuración solo está validada en GB10. Su conclusión resume la lección técnica: en la inferencia local de 2026, cada gigabyte en BF16 que se lee durante la generación se paga en tokens por segundo.
Preguntas frecuentes
¿Se puede ejecutar Qwen3.8-Flash-Next en un DGX Spark?
Sí. Un desarrollador lo sirve en producción con vLLM v0.30 en un DGX Spark de 128 GB, combinando NVFP4, FP8 y decodificación especulativa, y ha publicado la configuración en GitHub.
¿Qué velocidad alcanza?
Según sus mediciones, unos 55 tokens por segundo en una sola petición y un máximo de unos 145 tokens por segundo agregados con 10 usuarios simultáneos.
¿Qué optimizaciones descartó?
Reducir el número de expertos activos, la caché KV en FP8 y MTP-4, porque empeoraban la calidad o la velocidad sin aportar ventajas.
¿Qué hardware hace falta para replicarlo?
Un equipo con chip GB10, como el NVIDIA DGX Spark o el ASUS Ascent GX10, y unos 235 GB de disco.
Fuentes:
- GitHub: aseth0/qwen3.8-flash-next-gb10
- vLLM Recipes: Qwen3.8-Flash-Next
- Mer.vin: Qwen3.8-Flash-Next, Alibaba’s 125B MoE model
- Publicación del autor en LinkedIn (octubre de 2026)
