Servicio de Qwen3.8-Flash-Next en RTX 3090 con carga externa de tensores mediante llama.cpp
Por qué un modelo disperso de 88 GB y 180 mil millones de parámetros cabe en las GPUs para consumidores, y cómo flags como -ot, -ncmoe y mmap de llama.cpp lo distribuyen entre VRAM, RAM y NVMe.
Qwen3.8-Flash-Next es un modelo abierto con aproximadamente 180 mil millones de parámetros, cuyos archivos cuantizados suman 88 GB; sin embargo, hay personas que afirman poder ejecutarlo en una sola RTX 3090 con 24 GB de VRAM. En teoría, eso representa una diferencia de un orden de magnitud. Funciona gracias a la arquitectura del modelo, no a una cuantización inteligente ni a una GPU excepcionalmente potente: grandes partes del modelo nunca necesitan almacenarse en la tarjeta gráfica. Este artículo explica las cuatro decisiones de diseño que lo hacen posible y luego detalla las configuraciones completas de llama.cpp para sistemas con tres GPUs y uno solo, incluyendo qué función cumple cada flag importante y qué rendimiento se puede esperar de forma realista.
Por qué vale la pena ejecutar Flash-Next localmente
Alibaba lanzó Flash-Next en agosto. En el momento de redactar este texto, sus resultados publicados lo sitúan por delante de Qwen3.8-27B, DeepSeek V4 Flash (0731) y, en varios benchmarks de agencia, Opus 4.6, al activar solo 6 mil millones de parámetros por token. La clasificación en los benchmarks cambia rápidamente, por lo que es necesario verificar las evaluaciones actuales antes de considerar esas comparaciones como definitivas. Lo más relevante es la estructura del modelo, ya que es ella quien determina qué hardware puede utilizarlo.
Cuatro opciones arquitectónicas que trasladan el trabajo fuera de la GPU
Flash-Next combina cuatro ideas. Cada una de ellas traslada parte del trabajo costoso desde hardware caro a hardware económico, o bien lo elimina por completo.
Mezcla ultra-esparcida de expertos
El modelo tiene 48 capas, y cada capa alberga 512 subredes de expertos. Cualquier token pasa solo por 11 de ellas: 10 elegidas por un enrutador que examina el token y selecciona a los especialistas más adecuados, además de 1 experto compartido que todos los tokens utilizan sin necesidad de enrutamiento. En otras palabras, aproximadamente el 2% de los expertos realizan el trabajo para un dato token.
Una imagen útil es la de un hospital con 512 especialistas de guardia y un médico general que siempre está en la sala. Cada paciente recibe diez consultas adaptadas a sus síntomas, y los otros 501 especialistas no intervienen. La idea clave para la inferencia local es que “de guardia” solo significa “al alcance”. Un especialista no necesita estar en la GPU para estar disponible.
El experto compartido existe porque los diseños basados únicamente en ruteo tienden a perder el conocimiento general que cada token necesita. Al colocar ese conocimiento en un especialista general siempre activo, los expertos basados en ruteo pueden especializarse de manera más intensiva. La mayoría de los diseños actuales de MoE incluyen uno, y sus parámetros forman parte de la cifra total de 6 mil millones de parámetros activos.
Gated DeltaNet más Qwen Sparse Attention
Un transformador estándar mantiene una entrada de clave/valor para cada token que ha procesado. Ese caché KV crece linealmente con el contexto y se vuelve enorme en longitudes extensas. Flash-Next evita en gran medida este problema. Tres de cada cuatro capas utilizan Gated DeltaNet, el cual comprime la historia en un estado de tamaño fijo. La capa restante de cada grupo emplea Qwen Sparse Attention, la cual accede a un presupuesto fijo de 512 bloques, 2,048 tokens, independientemente de si el contexto contiene 32 mil o un millón de tokens.
El efecto práctico es drástico: con un contexto de 178K, la caché KV en las configuraciones siguientes ocupa unos 6GB, mientras que un modelo denso comparable necesitaría aproximadamente diez veces más. Esa es la razón por la cual una tarjeta de 24GB puede mantener una conversación larga.
Un flujo residual con múltiples vías y compuertas
Los transformadores clásicos envían todo a través de un único flujo residual desde la primera capa hasta la última, y en redes profundas las características iniciales tienden a diluirse a lo largo del camino. Flash-Next amplía ese camino a cuatro vías paralelas, con compuertas aprendidas que controlan qué entra y sale de cada vía. Durante el entrenamiento, una de las vías terminó especializándose como un canal de largo alcance que transmite información inicial profundamente dentro de la red. Se trata de un pequeño cambio arquitectónico que añade capacidad sin costo significativo.
Una tabla de incrustación de n-gramas
La cuarta parte es una tabla con 51 mil millones de parámetros, más que el resto del modelo combinado, la cual no realiza ninguna multiplicación de matrices. Se trata de una estructura de búsqueda, y es la razón principal por la cual una sola GPU para juegos resulta viable.
La tabla de n-gramas: conocimiento que no necesita GPU
En un modelo de lenguaje normal, cada token se asigna a un ID y el modelo busca ese ID en una tabla de embeddings: una fila por token. Una fila con un solo token contiene muy poca información sobre el contexto. En una frase como “Dostoevsky escribió Los hermanos”, el embedding de “el” no dice nada sobre los Karamázov; el modelo debe inferir la continuación con sus costosas capas, y tiene que hacerlo cada vez que aparece ese patrón.
Flash-Next agrega una segunda tabla cuyas filas están identificadas por frases cortas en lugar de tokens individuales. Conceptualmente, las entradas se ven como el boceto a continuación: una frase hashada en el lado izquierdo y el tipo de pista que codifica su vector aprendido en el lado derecho.
Drawer "born on october" → hint: 1985, Honolulu, singer
Drawer "dostoevsky brothers" → hint: Karamazov, novel, 1880
Drawer "def main(" → hint: python entry point
Durante la lectura, el modelo hasha los pocos tokens más recientes, obtiene la fila correspondiente y consigue una pista precalculada prácticamente de forma gratuita. Nadie escribió estas filas a mano. A lo largo del entrenamiento, cada vez que una frase iba seguida de una continuación específica, su fila se ajustaba ligeramente en esa dirección, de modo que después de billones de tokens cada fila aproxima lo que suele venir a continuación. La tabla contiene aproximadamente 20 millones de entradas de bigramas y trigramas, y su salida se introduce una sola vez, temprano, en la capa 2. En efecto, se trata de memorización de frases comunes, y una gran parte del texto real está compuesto por frases comunes.
La diferencia entre los dos tipos de conocimiento en el modelo es lo que hace posible la división del hardware. La comparación a continuación la resume.
| | Neural network | N-gram table |
|------------------|-------------------------|-------------------------|
| Work per token | Matrix math (expensive) | Drawer lookup (no math) |
| Needs the GPU? | Yes, every millisecond | No — CPU can fetch it |
| Lives in | VRAM | RAM. Even SSD. |
La propiedad decisiva es que la fila a obtener depende únicamente del texto de entrada, y no de ningún estado oculto dentro de la red. Tan pronto como un prompt se tokeniza, la CPU sabe exactamente qué filas serán necesarias, por lo que puede cargarlas por adelantado mientras la GPU sigue ocupada con las capas anteriores.
Eso permite distribuir el modelo a lo largo de la jerarquía de memoria según las capacidades de cada nivel:
- VRAM (rápida, costosa): los aproximadamente 6 mil millones de parámetros que se calculan realmente para cada token.
- RAM del sistema (moderada, económica): los pesos de los expertos en estado inactivo y la tabla de n-gramas de 29 GB.
- Almacenamiento NVMe (lento, más económico): los datos que sobrepasan el espacio disponible, cargados dinámicamente cuando se accede a ellos.
La GPU deja de ser el lugar donde se almacena todo el modelo y pasa a ser el sitio donde tiene lugar el cálculo activo.
Una configuración con tres GPUs para uso diario
Considere un servidor compuesto por tres RTX 3090 (con un total de 72 GB de VRAM), 48 GB de memoria del sistema DDR4 y una unidad NVMe PCIe Gen3 que almacena los pesos del modelo. Nada en él es de clase estación de trabajo; se trata del tipo de máquina que muchos desarrolladores arman con tarjetas gráficas antiguas para juegos.
El archivo del modelo utilizado aquí es la versión UD-IQ4_XS del repositorio GGUF de unsloth para este modelo en Hugging Face, con aproximadamente 88 GB distribuidos en tres fragmentos: unos 59 GB de pesos del esqueleto del modelo más los 29 GB de la tabla de n-gramas. El soporte para esta arquitectura es reciente, por lo que debe descargar la versión más actualizada de llama.cpp y reconstruir el modelo antes de probarlo.
La orden a continuación inicia llama-server en tres de las GPUs de la máquina. La mayoría de los parámetros son habituales (host, puerto, parámetros de muestreo, tamaños de lote, longitud de contexto), por lo que hay que prestar atención a los parámetros de descarga, los parámetros de división y el modo de carga, que se explican justo después.
CUDA_VISIBLE_DEVICES=0,2,3 CUDA_SCALE_LAUNCH_QUEUES=4x llama-server \
-m /mnt/data_2t/ai_models_all/llm_hf_models/unsloth/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
--alias Qwen3.8-Flash-Next \
--jinja \
--metrics \
--host 0.0.0.0 \
-ngl 99 \
--batch-size 4096 \
--ubatch-size 512 \
--flash-attn on \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
--split-mode layer \
--tensor-split 0.9,0.95,1.0 \
--fit off \
--main-gpu 0 \
--ctx-size 178000 \
--parallel 1 \
--image-min-tokens 1024 \
--reasoning-format none \
--timeout 1200 \
--ctx-checkpoints 8 \
--port 8082 \
--load-mode mmap \
--cache-type-k q8_0 --cache-type-v q8_0 \
-ot '^per_layer_token_embd\.weight$=CPU' \
--reasoning-effort low \
-t 14
Fijación de la tabla de n-gramas en la RAM del sistema
La sobrescritura -ot '^per_layer_token_embd\.weight$=CPU' indica a llama.cpp que cualquier tensor cuyo nombre coincida con la expresión regular debe colocarse en la memoria CPU en lugar de en VRAM. La tabla de n-gramas se almacena bajo el nombre del tensor per_layer_token_embd.weight, por lo que esta única línea mantiene los 29 GB de dicha tabla fuera de las GPUs. Cuando un token necesita una fila, la CPU la obtiene y transmite el resultado, lo cual es exactamente el mecanismo de precarga descrito anteriormente. Los marcadores ^ y $ son importantes: aseguran que el patrón solo coincida con ese tensor y no mueva accidentalmente otros pesos.
Permitir que el SO gestione la residencia mediante mmap
--load-mode mmap mapea en memoria el archivo del modelo en lugar de leerlo primero en RAM. El sistema operativo luego mantiene las páginas que se acceden con frecuencia en el caché de páginas disponible y deja las páginas poco utilizadas en el SSD. Con 48 GB de RAM y una tabla de 29 GB, ese es el equilibrio adecuado: el kernel decide qué merece permanecer en memoria. En una máquina con mucha memoria, como 128 GB, tiene más sentido cambiar a none, ya que todo el archivo se lee una sola vez y no hay errores de página posteriormente.
Distribuir capas entre tarjetas
--split-mode layer combinado con --tensor-split 0.9,0.95,1.0 divide los 59 GB del modelo principal en grupos contiguos de capas, un grupo por GPU, con proporciones ligeramente desiguales para que la primera tarjeta tenga espacio adicional para sus funciones adicionales como --main-gpu. -ngl 99 distribuye las 48 capas entre las GPUs, aproximadamente 20 GB por tarjeta. La caché KV, cuantizada a q8_0 mediante --cache-type-k y --cache-type-v, se almacena junto a los pesos y abarca 178K tokens en unos 6 GB.
Rendimiento medido en tres tarjetas
En esta configuración, los números reportados se muestran a continuación.
Decode: 30-50 tokens/second
Prefill: 400-700 tokens/second
Context: 178,000 tokens
Eso es más rápido que la velocidad de lectura de un modelo de clase similar a los de vanguardia, en tarjetas de consumo usadas dentro de una carcasa de tipo medio.
Configuración con una sola GPU y sus limitaciones
Una tarjeta 3090 es suficiente si se cumple una condición: al menos 64 GB de RAM del sistema. La tabla de n-gramas y los expertos descargados necesitan un lugar donde almacenarse, y la memoria del sistema suele ser la actualización más económica para una máquina de IA local.
La orden utiliza el mismo archivo GGUF. Las diferencias notables son la nueva bandera -ncmoe, una sola GPU visible, --load-mode none en lugar de mmap, y menos hilos de CPU.
CUDA_VISIBLE_DEVICES=0 llama-server \
-m /mnt/data_2t_3/ai_models_all/unsloth/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00003.gguf \
--alias Qwen3.8-Flash-Next \
--jinja \
--metrics \
--host 0.0.0.0 \
-ngl 99 \
-ncmoe 38 \
--batch-size 4096 \
--ubatch-size 1024 \
--flash-attn on \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
--ctx-size 178000 \
--parallel 1 \
--image-min-tokens 1024 \
--reasoning-format none \
--timeout 1200 \
--ctx-checkpoints 8 \
--port 8083 \
--load-mode none \
-ot '^per_layer_token_embd\.weight$=CPU' \
--reasoning-effort low \
-t 8
Qué hace -ncmoe 38
-ncmoe 38 mantiene los pesos de los expertos de las primeras 38 capas en la RAM del CPU, mientras que las últimas 10 capas almacenan sus expertos en la VRAM. Esto coloca aproximadamente 43 GB de pesos de expertos en la memoria del sistema. Las componentes de atención y compartidas de cada capa siguen ejecutándose en la GPU gracias a -ngl 99.
Almacenar tanta información en la RAM sigue siendo viable gracias a la escasez de datos. Cada token activa 10 de los 512 expertos por capa, por lo que solo afecta aproximadamente a 1.3 GB de pesos de los expertos en total. Los expertos que se encuentran en la RAM se procesan en la CPU donde están, sin necesidad de copiarlos a la GPU, mientras que los expertos en VRAM se ejecutan directamente en la tarjeta. La CPU es mucho más lenta que una 3090, por lo que existe un verdadero costo adicional, pero este varía según el aproximado 2 % de pesos que afecta cada token y no según toda la información almacenada.
Dado que aquí la RAM alberga tanta cantidad de datos, --load-mode none lee el archivo por completo al iniciar en lugar de depender de errores de página, lo cual es otra razón por la que es importante contar con al menos 64 GB de RAM.
Ajustes para otras tarjetas
La misma orden funciona en una RTX 4090 o 5090; solo -ncmoe necesita ajustarse según la cantidad de VRAM disponible. A continuación se detallan los puntos de partida recomendados.
| GPU | VRAM | Suggested -ncmoe | Experts in RAM |
|------------|------|------------------|----------------|
| RTX 3090 | 24GB | 38 | ~43GB |
| RTX 4090 | 24GB | 38 | ~43GB |
| RTX 5090 | 32GB | 28-30 | ~32GB |
Cada vez que reduces el valor de -ncmoe, se devuelve a la GPU un estrato completo de expertos, aproximadamente 1.1 GB. Después de cargar el modelo, verifica nvidia-smi y procura dejar alrededor de 500 MB de VRAM libres; si la tarjeta funciona completamente llena, se producirán errores por falta de memoria cuando el contexto crezca.
Establecer expectativas realistas
En una sola tarjeta 3090, la decodificación se realiza a 15 a 20 tokens por segundo. Eso es utilizable, pero apenas: lo suficientemente rápido como para seguir leyendo, pero lo suficientemente lento como para que las generaciones largas resulten lentas, ya que parte del cálculo realmente ocurre en la CPU dentro de la RAM del sistema. Como prueba de concepto, o para aprovechar al máximo una máquina que ya posees, ejecutar un modelo de 180 mil millones de parámetros a velocidad de lectura en una sola tarjeta de juego es algo notable.
Para tener un asistente disponible todo el día para programación y tareas cotidianas, tres o cuatro tarjetas 3090 son necesarias para que la experiencia sea cómoda. La diferencia entre aproximadamente 18 y 40 tokens por segundo marca la distinción entre una demostración y una herramienta de uso diario. Si, en cambio, estás explorando modelos Qwen más pequeños para programación autónoma, la guía sobre crear un juego local con Qwen3.8-27B muestra una configuración más ligera.
Predicción de múltiples tokens: la próxima mejora de velocidad a seguir
Flash-Next incluye una cabeza de predicción multi-token (MTP) entrenada, un módulo adicional pequeño que propone varios tokens futuros al mismo tiempo para que el modelo principal pueda verificarlos en paralelo. Se trata de una decodificación especulativa con un componente preliminar entrenado de extremo a extremo específicamente para este modelo. En vLLM, se ha reportado que ofrece aproximadamente 2.5 veces más velocidad de decodificación con prompts reales.
En el momento de escribir esto, llama.cpp ya soporta la arquitectura Flash-Next en sí, pero su versión preliminar de MTP aún no está preparada para este modelo. Existe soporte para modelos similares, por lo que el cambio debería ser modesto; sin embargo, revise las notas de la versión actual de llama.cpp antes de asumir que está disponible. Una vez implementado, la velocidad de 30 a 50 tokens por segundo en configuraciones con tres GPUs podría aumentar razonablemente a entre 60 y 100 en el mismo hardware, únicamente mediante una actualización de software. Considérelo una estimación hasta que pueda medirlo.
Puntos clave
- Flash-Next se adapta al hardware de consumo gracias a su diseño, no a la fuerza bruta: el MoE ultra-esparso, el estado de atención de tamaño fijo y una tabla de n-gramas de solo consulta reducen todo lo que necesita almacenarse en la VRAM.
-ot con una expresión regular estricta es la forma de colocarlo allí.-ncmoe es la opción principal para configuraciones con una sola GPU: bájelo hasta que la VRAM esté casi llena, dejando un pequeño margen de seguridad.mmap cuando la RAM es escasa y desea que el sistema operativo gestione su residencia; elija none cuando la RAM es abundante y desea una latencia predecible después de la carga.Lecturas relacionadas
- Construyendo un clon local de Angry Birds con Qwen3.8-27B y Pi — Aprenda cómo configurar un flujo de trabajo de programación con IA completamente local utilizando LM Studio y el agente Pi para crear un nivel jugable de Angry Birds con Qwen3.8-27B.
- Arquitectura de un SaaS de chat con IA con Next.js, FastAPI, créditos y SSE — Explore una arquitectura de chat con IA de capa completa que incluye un guardián FastAPI, un registro de créditos, límites de velocidad en Redis y transmisión en tiempo real SSE, además de las deficiencias que deben resolverse primero.