Qwen3.8-Flash-Next en local: qué significan realmente 6B de parámetros activos para la RAM, la VRAM y la NVMe

No, Qwen3.8-Flash-Next no cabe en la memoria como un modelo de 6B solo porque active aproximadamente 6B de parámetros por token. Qwen describe un modelo principal de 125B parámetros con 6B de parámetros activados, además de 51B de embeddings de n-gramas y un componente MTP de aproximadamente 4B. El repositorio oficial de Qwen3.8-Flash-Next ocupa actualmente unos 360 GB en su versión BF16 publicada. Las conversiones comunitarias a GGUF pueden reducir ese tamaño considerablemente, pero no convierten Flash-Next en un modelo convencional de 6B.

La forma útil de pensar en la implementación local es como una jerarquía de memoria. La VRAM determina cuánto procesamiento de alta velocidad del modelo puede permanecer en la GPU. La RAM del sistema proporciona capacidad para los componentes residentes en la CPU y los componentes descargados, incluida la tabla de n-gramas inusualmente grande que Qwen diseñó explícitamente para funcionar desde la memoria del sistema. NVMe proporciona almacenamiento local rápido y respaldo mediante mapeo de memoria para archivos cercanos o superiores a 100 GB, pero no sustituye a la RAM ni a la VRAM. Por tanto, la verdadera pregunta es qué parte de la carga de hardware elimina la cifra de 6B activos y cuál no.

¿Significa «6B activos» que Qwen3.8-Flash-Next solo necesita la memoria de un modelo de 6B?

No. Los parámetros activados describen el cálculo por token, no la cantidad total de estado del modelo existente. Esta distinción es especialmente importante para Qwen3.8-Flash-Next porque la diferencia entre su cantidad de parámetros activos y su cantidad de parámetros almacenados es inusualmente grande.

Según la tarjeta oficial del modelo Qwen3.8-Flash-Next, el modelo de lenguaje contiene 125B de parámetros, con aproximadamente 6B activados para cada token, además de 51B de parámetros de embeddings de n-gramas y unos 4B de parámetros asociados a MTP. El MoE principal contiene 512 expertos enrutados y selecciona 10 expertos enrutados más un experto compartido para cada token.

Lo que produce tres cifras diferentes que no deben mezclarse:

La idea clave es que los expertos inactivos no dejan de existir. Distintos tokens pueden dirigirse a distintos expertos, por lo que el entorno de ejecución sigue necesitando acceso al conjunto más amplio de pesos, aunque solo una pequeña fracción participe en la pasada hacia delante de un token concreto. Esta es la razón general por la que otros modelos MoE grandes pueden tener una carga computacional activa relativamente modesta y, al mismo tiempo, ocupar mucha memoria, una distinción que también es importante en nuestro análisis del hardware local para GLM-5.3-Flash.

Flash-Next añade otra particularidad. Su tabla de embeddings de n-gramas de 51B no se utiliza como una matriz de pesos normal de una red neuronal densa. En la descripción oficial de la arquitectura de Flash-Next de Qwen, el equipo explica que las ubicaciones de consulta de n-gramas pueden determinarse con antelación. Por lo tanto, la tabla puede residir en la memoria del sistema y precargarse de forma asíncrona mientras se ejecutan otros cálculos del modelo.

Por eso la cifra de 6B activos es significativa, aunque no represente un requisito de memoria. Flash-Next está diseñado para separar la capacidad del modelo de la computación por token de forma más marcada que un modelo denso convencional. Para la inferencia local, esto desplaza la cuestión del hardware de una única cifra de VRAM a la eficiencia con la que la VRAM, la RAM del sistema y el almacenamiento pueden trabajar conjuntamente.

¿Cuánto ocupa Qwen3.8-Flash-Next después de la cuantización?

La versión oficial BF16 ocupa aproximadamente 360 GB, lo que sitúa de inmediato una implementación sin cuantizar completamente residente fuera del alcance del hardware de escritorio habitual. La cuantización cambia considerablemente la situación.

A fecha del 1 de septiembre de 2026, las versiones GGUF actuales de Flash-Next de Unsloth van desde versiones de muy pocos bits extremadamente agresivas hasta variantes mucho más grandes y de alta calidad. Dos puntos de referencia útiles son la versión UD-IQ4_XS de aproximadamente 93,7 GB y la versión UD-Q4_K_XL de aproximadamente 111 GB.

Estos tamaños de GGUF son conversiones de la comunidad, no recomendaciones oficiales de Qwen sobre la RAM o la VRAM mínimas. Aun así, son útiles para planificar la capacidad, porque muestran la magnitud del problema antes de añadir los búferes del tiempo de ejecución, el estado del contexto, el procesamiento de visión, el sistema operativo y otras aplicaciones.

Por ejemplo, un archivo de modelo de 94 GB no implica que una máquina con exactamente 96 GB de memoria combinada permita una implementación cómoda. El tiempo de ejecución sigue necesitando espacio de trabajo, y la cantidad de memoria adicional necesaria cambia según la longitud del contexto, el backend, el formato de caché, la estrategia de descarga a la GPU y la concurrencia.

¿Cuánta VRAM necesita Qwen3.8-Flash-Next?

No existe una única cifra útil de «VRAM mínima» para Flash-Next, porque la inferencia local puede variar desde una ejecución casi completamente residente en la CPU hasta un modelo distribuido entre una o más GPU. La VRAM determina principalmente qué parte de la carga de inferencia de gran ancho de banda puede permanecer en la GPU y, por tanto, a qué velocidad puede funcionar el sistema.

Una GPU de consumo de 24 o 32 GB no puede alojar por sí sola un GGUF actual de cuatro bits de 94–111 GB. Eso no significa necesariamente que la GPU sea inútil. Un tiempo de ejecución capaz de descargar parcialmente el modelo a la GPU puede mantener tensores o capas seleccionados en la VRAM mientras la RAM del sistema almacena el resto.

Las opciones actuales de carga de modelos de llama.cpp incluyen la asignación de capas a la GPU, la selección explícita de dispositivos, las anulaciones de tensores y los controles de MoE en la CPU. Eso significa que «¿puede ejecutarlo mi GPU?» y «¿puede mi GPU alojar el modelo completo?» son preguntas diferentes.

La diferencia de rendimiento entre estas configuraciones puede ser enorme, incluso cuando todas cargan técnicamente el modelo. El ancho de banda de la memoria de la GPU es drásticamente superior al de la memoria del sistema convencional, y trasladar una gran parte del cálculo activo de vuelta a la CPU puede convertir un modelo local que, de otro modo, sería impresionante en algo más adecuado para la experimentación que para el trabajo interactivo con agentes.

Por lo tanto, para Flash-Next, la VRAM debe considerarse una asignación de rendimiento, no una cifra binaria de compatibilidad.

¿Cuánta RAM necesita Qwen3.8-Flash-Next para la descarga entre la CPU y la GPU?

Podría decirse que la RAM del sistema es más importante para Flash-Next de lo que sugiere el titular de «6B activos». Una máquina con una GPU de consumo pero muy poca RAM no tiene un lugar útil donde colocar la gran cantidad de estado del modelo que no cabe en la VRAM.

La incrustación de n-gramas hace que esto sea especialmente interesante. Qwen afirma que la tabla de 51B puede colocarse en la memoria del host porque sus accesos son deterministas y pueden precargarse. Cuando la implementación de Flash-Next se integró en llama.cpp el 27 de agosto, sus notas de implementación describieron la tabla de incrustaciones de n-gramas por capa como de aproximadamente 97.7 GiB en BF16 y gestionaron la búsqueda de filas desde el lado del host.

Eso no significa que cada implementación local necesite permanentemente otros 97.7 GiB sin cuantizar además de un GGUF cuantizado. La cuantización y la representación en tiempo de ejecución son importantes. Sí demuestra por qué la arquitectura se diseñó en torno a una memoria heterogénea, en lugar de suponer que cada parámetro debe permanecer en la memoria de la GPU.

Para una inferencia práctica con GGUF, la memoria del sistema debe planificarse a partir del tamaño real del modelo cuantizado, más el margen necesario para el sistema operativo y el tiempo de ejecución. Con una cuantización de aproximadamente 94 GB, 128 GB de RAM es un objetivo de capacidad experimental plausible, pero no ofrece mucho margen una vez incluidos el sistema operativo, el contexto, los búferes y el comportamiento de asignación entre la GPU y el host. Un sistema de 192 GB o 256 GB proporciona un margen mucho más seguro para una inferencia híbrida seria.

Este es uno de los ejemplos más claros de por qué la memoria de la IA local se está convirtiendo en una jerarquía en lugar de una única especificación de VRAM. La memoria de la GPU gestiona el trabajo más sensible al ancho de banda, la memoria del sistema amplía la capacidad del modelo y el almacenamiento proporciona los datos persistentes del modelo por debajo de ambas.

¿Puede la descarga a un SSD NVMe hacer práctico Qwen3.8-Flash-Next?

NVMe puede facilitar el almacenamiento y la carga de un modelo sobredimensionado, pero no convierte la capacidad de un SSD en memoria de inferencia rápida. Esta distinción importa más a medida que los modelos locales superan el límite de 100 GB.

Una unidad NVMe rápida es útil para almacenar varias variantes GGUF, cargar un modelo grande sin esperar al almacenamiento de red o de disco duro más lento y admitir el acceso a modelos mediante mapeo de memoria. llama.cpp utiliza el mapeo de memoria como modo de carga del modelo, lo que permite mapear las páginas del modelo desde un archivo en lugar de exigir que todo el archivo se copie en una asignación de RAM independiente al inicio.

Sin embargo, la documentación de llama.cpp sobre la carga de memoria también explica por qué esto no debe interpretarse como una descarga gratuita al disco. Si el modelo de trabajo supera la RAM disponible, las paginaciones y el acceso repetido al almacenamiento pueden perjudicar el rendimiento. El bloqueo de memoria existe precisamente porque puede ser importante mantener residentes en la RAM las páginas del modelo que se utilizan con frecuencia.

Una regla útil es: NVMe puede hacer que un modelo sobredimensionado sea cargable; no hace que automáticamente sea interactivo.

Esto también explica por qué la arquitectura de almacenamiento es cada vez más importante para la IA local, incluso cuando el propio dispositivo de almacenamiento no realiza inferencias. Los modelos, los recursos visuales, los índices RAG, los conjuntos de datos, los espacios de trabajo de los agentes y varios checkpoints cuantizados pueden consumir fácilmente cientos de gigabytes. El almacenamiento local rápido se está convirtiendo en parte del sistema de IA, pero sigue ocupando un nivel distinto al de la memoria que alimenta el cálculo activo.

¿Cómo cambia el contexto de 262.000 tokens los requisitos de memoria?

Qwen3.8-Flash-Next admite de forma nativa una longitud de contexto de 262.144 tokens y puede ampliarse hasta cerca de un millón de tokens con YaRN. Eso no significa que todas las implementaciones locales deban configurar de forma predeterminada el contexto máximo.

El modelo utiliza una arquitectura híbrida en lugar de atención completa convencional en cada capa. Gated DeltaNet comprime el historial, mientras que Qwen Sparse Attention utiliza un indexador para seleccionar los bloques de contexto relevantes. Esto está diseñado específicamente para reducir la presión computacional y de memoria asociada a las secuencias largas.

El contexto largo tampoco es gratuito. La memoria del entorno de ejecución puede incluir el estado recurrente, las cachés de atención dispersa, el estado del indexador, los búferes temporales de cálculo, las entradas de visión, la sobrecarga del procesamiento por lotes y las asignaciones específicas del backend. Por lo tanto, la curva exacta de memoria depende del motor de inferencia y no queda determinada únicamente por el tamaño del archivo GGUF.

También hay una diferencia entre el límite de contexto arquitectónico de un modelo y el grado de madurez de la implementación actual del entorno de ejecución. Al 1 de septiembre de 2026, la compatibilidad de llama.cpp con la nueva arquitectura solo tiene unos días. Un problema actual de CUDA con un contexto de 262K informa de un fallo al iniciar el kernel exactamente con 262.144 tokens, mientras que 261.888 tokens funcionan correctamente en el sistema de prueba. El informe identifica esto como una limitación del kernel, no como un agotamiento de la VRAM.

Es posible que ese problema concreto se solucione rápidamente, pero ilustra un punto más general: 262K es una capacidad del modelo, no una garantía de que todas las GPU actuales y todos los backends de inferencia puedan utilizar hoy toda la ventana de forma eficiente.

Para la implementación local, empieza por la longitud de contexto que realmente necesita la carga de trabajo. Una sesión de programación, una tarea de análisis de documentos o un flujo de trabajo privado de RAG que quepa en 16K, 32K o 64K no mejora simplemente porque el entorno de ejecución reserve cientos de miles de tokens.

¿Qué hardware puede ejecutar realmente Qwen3.8-Flash-Next de forma local?

La respuesta de hardware más útil depende de lo que signifique «ejecutar». Cargar un modelo muy cuantizado y generar tokens es un objetivo. Mantener un rendimiento interactivo, un contexto amplio, entradas de visión y cargas de trabajo de agentes es un objetivo mucho más exigente.

Por lo tanto, la tabla siguiente sirve como guía de planificación basada en los tamaños actuales de los modelos y archivos GGUF, no como una recomendación oficial de hardware para Qwen.

La línea divisoria más importante no es un modelo específico de GPU. Es si la máquina tiene suficiente capacidad de memoria rápida combinada para evitar que la paginación de almacenamiento forme parte de la ruta crítica de generación.

Una GPU de 24 GB combinada con 192 GB de memoria del sistema rápida puede ofrecer un experimento con Flash-Next más creíble que una GPU de 24 GB combinada con solo 32 o 64 GB de RAM. Por el contrario, añadir una gran cantidad de RAM no hace que la inferencia con una carga elevada en la CPU sea equivalente a ejecutar esos mismos tensores en la memoria de GPU de gran ancho de banda.

Para la mayoría de los usuarios de escritorio interesados en la familia Qwen3.8 y no específicamente en esta arquitectura, Qwen3.8-27B es el objetivo local más convencional. Flash-Next tiene más sentido para quienes quieran experimentar deliberadamente con un modelo disperso mucho más grande, memoria heterogénea, una arquitectura de contexto largo o la tecnología que, según Qwen, anticipa la dirección de Qwen4.

¿Vale la pena ejecutar Qwen3.8-Flash-Next localmente?

Sí, para la estación de trabajo adecuada y por el motivo adecuado, pero no porque «6B activos» haga que un lanzamiento de aproximadamente 180B de parámetros se comporte de repente como un modelo pequeño de escritorio.

Flash-Next resulta especialmente interesante si tienes entre 128 y 256 GB de memoria del sistema o unificada, una aceleración significativa de GPU, almacenamiento NVMe rápido y motivos para experimentar con grandes cargas de trabajo locales de programación, multimodales, ofimáticas o basadas en agentes. Su arquitectura es especialmente relevante para la IA local porque separa deliberadamente los parámetros que se calculan con frecuencia de las grandes estructuras orientadas a la capacidad, que pueden residir fuera de la memoria de la GPU.

Es una opción mucho menos adecuada para un PC normal con 32–64 GB de RAM cuyo plan dependa de que el sistema operativo recupere constantemente de la SSD las páginas del modelo que falten. Una máquina así puede demostrar que el modelo técnicamente puede iniciarse, pero «cargar correctamente» y «funcionar de forma útil» son estándares diferentes.

La lección más importante va más allá de este modelo. El hardware de IA local depende cada vez menos de pedir una única cifra mínima de VRAM y más de diseñar una jerarquía: VRAM para el procesamiento de alta velocidad, RAM para la capacidad accesible del modelo y NVMe para el almacenamiento local persistente de modelos y datos. Qwen3.8-Flash-Next hace que esa transición sea especialmente visible.

Preguntas frecuentes: requisitos de hardware local de Qwen3.8-Flash-Next

¿Qwen3.8-Flash-Next puede ejecutarse en una RTX 4090 o RTX 5090?

Sí, esas GPU pueden participar en una implementación local híbrida, pero ni una RTX 4090 de 24 GB ni una RTX 5090 de 32 GB pueden albergar completamente en la VRAM un GGUF actual de Flash-Next de cuatro bits de aproximadamente 94–111 GB. Necesitarías una cantidad considerable de RAM del sistema y descarga a la CPU y la GPU. La GPU aún puede acelerar la parte del modelo que se coloque allí, por lo que esto es muy distinto de decir que no se pueden utilizar esas tarjetas.

¿Qwen3.8-Flash-Next puede ejecutarse con 64 GB de RAM?

64 GB de RAM del sistema están por debajo del tamaño de las compilaciones GGUF prácticas actuales más pequeñas de cuatro bits. La asignación en memoria puede permitir acceder desde el almacenamiento a partes de un archivo demasiado grande, pero el paginado repetido probablemente hará que la inferencia sea lenta e inestable como carga de trabajo interactiva. Para una implementación local seria, 64 GB no deberían considerarse un objetivo práctico.

¿Son suficientes 128 GB de RAM para Qwen3.8-Flash-Next?

128 GB es un punto de partida razonable para una de las compilaciones GGUF más pequeñas, de aproximadamente cuatro bits, combinada con descarga a la GPU y una ventana de contexto moderada. No es una recomendación universal cómoda. Un modelo de aproximadamente 94 GB deja bastante menos de 34 GB para el sistema operativo, los búferes del runtime, el estado del contexto, el procesamiento de visión y otros servicios, por lo que 192 GB o más ofrecen un margen considerablemente mejor.

¿Qwen3.8-Flash-Next puede ejecutarse completamente desde un SSD NVMe?

Un runtime puede asignar en memoria los archivos del modelo almacenados en NVMe, y el sistema operativo puede cargar las páginas a medida que se necesitan. Eso no equivale a ejecutar el modelo «desde un SSD» a las velocidades de la RAM o la GPU. NVMe es excelente para almacenar y cargar modelos, pero depender continuamente de él porque la memoria física se ha agotado puede reducir drásticamente el rendimiento de generación.

¿Que tenga 6B de parámetros activos significa que Qwen3.8-Flash-Next es tan rápido como un modelo de 6B?

No. La cifra de 6B describe el número aproximado de parámetros activados del modelo principal para cada token. Flash-Next sigue teniendo una arquitectura mucho mayor, lógica de enrutamiento, tráfico de memoria, búsqueda de n-gramas, estado de atención dispersa y otras tareas de ejecución. Un menor número de parámetros activados puede reducir considerablemente el cómputo, pero no hace que el sistema completo sea equivalente a un modelo denso de 6B.

¿Pueden Ollama o llama.cpp ejecutar Qwen3.8-Flash-Next localmente?

Compatibilidad de llama.cpp con Qwen3.8-Flash-Next qwen4exp architecture se fusionó con master el 27 de agosto de 2026, un día después del lanzamiento del modelo. Los repositorios comunitarios actuales de GGUF también ofrecen compilaciones destinadas a flujos de inferencia local basados en llama.cpp. Como la implementación aún es muy reciente, consulta las versiones actuales del runtime y las instrucciones del modelo antes de asumir que todos los backends de GPU, longitudes de contexto, rutas de visión o configuraciones de descarga están igual de maduras.