Filtración de Qwen 4: la PR de host-staging de SGLang muestra cómo la tabla PLE de 47,7 GiB cabe en una sola GPU

El número que decidirá si Qwen 4 es un modelo que puedes servir tú mismo no es su cantidad de parámetros. Son 47,7 GiB — el tamaño de la tabla de embeddings de n-gramas que acompaña a la arquitectura Qwen4, separada de los pesos, y tiene que residir en algún lugar mientras el modelo decodifica. Una pull request abierta en el repositorio de SGLang el 18 de septiembre de 2026, titulada [Qwen4-Exp] Añadir staging en host para PLE respaldado por archivo, es un intento de evitar que esa tabla dicte cuánta RAM necesita una máquina antes de poder ejecutarse siquiera. Qwen 4 aún no se ha publicado: no hay tarjeta de modelo, ni pesos, ni entrada de catálogo, ni fecha. El único modelo lanzado que instancia esta arquitectura es Qwen3.8-Flash-Next, la preview de pesos abiertos publicada el 26 de agosto de 2026, cuya configuración declara model_type=qwen4_exp — la misma cadena que da nombre a la pull request. Su hermano de producción Qwen3.8-Flash es la versión a la que un consumidor de API puede acceder realmente hoy. Todo en este artículo sobre Qwen 4 es una inferencia a partir de esa preview y del código del motor; la pull request está abierta y sin fusionar, así que léelo todo como una señal, no como una capacidad ya disponible.

Lo que la señal realmente es

La solicitud de extracción sgl-project/sglang#40235 no es un lanzamiento y no está fusionada. Se encuentra en un solo commit, abierta por el colaborador Dev-Jahn, que fusiona una rama llamada task/ple-host-staged en la línea principal de SGLang. Se ha solicitado la revisión de nueve propietarios de código y todos aparecen como en espera, por lo que al menos una revisión de aprobación se interpone entre esto y la rama main. Tres trabajos de CI —la prueba de PR base, la prueba de PR adicional y la ejecución de AMD ROCm— están fallando en el commit abierto. Esa es la condición normal de un gran cambio de motor en curso, y también es la razón por la que la parte interesante de este PR no es si se fusiona, sino lo que su autor tuvo que medir para defenderlo. La descripción incluye aproximadamente 1.400 líneas añadidas, incluidas las pruebas, y una tabla de benchmarks que constituye los datos públicos más concretos que alguien haya publicado sobre ejecutar esta arquitectura en una sola GPU.

Por qué la tabla lo es todo

Los embeddings por capa son la rareza estructural de esta generación. Donde un modelo normal coloca un único embedding de token al principio, el diseño de Qwen4 lleva una gran tabla de n-gramas —bigramas y trigramas, con hash a un vocabulario mucho más grande que el del tokenizador— y alimenta búsquedas de embeddings por capa desde ella a lo largo de toda la pila. El propio material de vista previa de Alibaba describe el componente de n-gramas como decenas de miles de millones de parámetros sobre el cuerpo MoE de 125B parámetros; los análisis detallados de la comunidad del checkpoint publicado sitúan el archivo de la tabla en 47,7 GiB. Esas cifras provienen de fuentes del proveedor y de la comunidad, más que de una reproducción independiente, y se desconoce la relación exacta entre la tabla de la vista previa y la versión de Qwen 4 que se lance.

Lo que no está en duda es la consecuencia de ingeniería. Una tabla lateral de 47,7 GiB que debe consultarse en cada paso de decodificación no es algo que se pueda empujar silenciosamente a un rincón de la VRAM. En una tarjeta de 96 GB compite directamente con la caché KV; en tarjetas más pequeñas, simplemente no cabe. Por eso SGLang, que ofreció soporte desde el día 0 para la vista previa a finales de agosto, ha pasado las tres semanas siguientes produciendo una solicitud de extracción tras otra sobre esta única estructura de datos en lugar de sobre el modelo que la rodea.

¿Qué estaba roto antes de este PR?

SGLang ya tenía dos formas de mantener la tabla, y ambas tenían un límite inflexible.

• PinnedMantiene toda la tabla en la RAM del host y la lee desde ahí. Funciona, es rápido y hace que el requisito de memoria del host sea absoluto: no existe una versión más pequeña.

• El respaldo por archivo, añadido anteriormente en una solicitud de extracción separada, mantiene la tabla en un archivo disperso y permite que el kernel de recolección lea el mapeo directamente, por lo que la caché de páginas del sistema operativo decide cuánto de ella está residente. El inconveniente es de hardware: esa ruta de lectura directa requiere que la GPU informe cudaDevAttrPageableMemoryAccessUsesHostPageTables — la capacidad que el propio texto del PR describe como "la clase GB10". En una GPU que no la tenga, el backend de archivo se rechaza de plano y la opción fijada es la única que queda.

La brecha que eso crea no es teórica. Un informe aparte presentado contra la misma ruta de código documenta un usuario con dos RTX 3090s cuya cuota por rango de la tabla llegaba a 23,84 GiB frente a 23,56 GiB de memoria utilizable — 0,28 GiB menos, con 188 GiB de RAM del host libres. En esa configuración, el backend de archivos fue rechazado por la comprobación de hardware y el flag ordinario de CPU-offload provoca un error cuando se combina con el flag de offload de PLE. Quedarse trescientos megabytes corto con ciento ochenta gigabytes de sobra es precisamente la forma de problema que este pull request existe para eliminar.

¿Qué cambios de staging del host?

El mecanismo que añade el PR es una capa de staging entre el archivo y el dispositivo. En lugar de pedirle a la GPU que desreferencie páginas del host, un componente del lado de la CPU lee las filas que necesita a través del mapeo existente del loader y le indica al kernel que traiga esas páginas por adelantado; una variable de entorno, SGLANG_QWEN4_PLE_FILE_PREFETCH, desactiva esa indicación si quieres medir sin ella. Cada capa PLE recibe entonces dos búferes fijados de 8.192 filas —unos 1,25 MiB cada uno en FP8— y un worker. Las filas se recopilan en un búfer mientras el otro se está copiando al dispositivo, de modo que la recopilación y la transferencia se solapan en lugar de serializarse. Los identificadores de n-gramas se hashean en el host en lugar de en el dispositivo. La reproducción de grafos recibe una llamada de preparación antes de cada reproducción, y el hilo que lanza espera al paso anterior.

Ese último detalle es el coste, y el PR lo declara sin rodeos: aproximadamente de 0,5 a 1 milisegundo añadido por paso de decodificación respecto a la ruta fijada. Todo lo demás es la recompensa. Medido en una única RTX PRO 6000 Blackwell con 96 GB, un host AMD EPYC con 377 GiB de RAM, CUDA 13.2, usando los checkpoints públicos FP8 y NVFP4 de Qwen3.8-Flash-Next:

• Caché de páginas del host, FP8 TP4/EP4 — 71 GB fijados y sin límite, frente a 49 GB con un límite de 64 GB, 15 GB con 32 GB y 6 GB con un límite de 24 GB

• Latencia de decodificación, mismas ejecuciones — 8,62 ms por token con concurrencia 1 fijada, frente a 9,16 / 9,20 / 9,12 ms en las tres ejecuciones de archivo limitadas

• Concurrencia 16 — 16,54 ms fijado frente a 17,62 / 17,85 / 17,37 ms limitado, lo que supone bajar de 893 tokens por segundo a 827–840

• Rendimiento de prellenado — 620 tokens por segundo a 8k fijado frente a 624 / 630 / 631 limitado; a 32k, 1.347 frente a 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB fijados frente a 24 GB con el backend de archivos con un límite de 32 GB, a 8,87 ms frente a 9,18 ms

• NVFP4 en una sola GPU — 69 GB fijados frente a 51 GB con un límite de 64 GB, a 6,44 ms frente a 6,73 ms

• La alternativa a la que supera — leer el mismo archivo a través de la gestión de memoria del host en esa GPU dio 10,8 ms con concurrencia 1 y 46,5 ms con concurrencia 16, lo que el PR describe como 2,8× la latencia pinned a esa concurrencia

El lado de la precisión se reporta como limpio. La salida greedy determinista sobre ocho prompts de 256 tokens fue idéntica a nivel de token entre las rutas pinned y de archivo en FP8 TP4, y GSM8K dio 97.6% con pinned frente a 98.0% con archivo en el límite de 64 GB — una diferencia de seis preguntas que el autor atribuye a la variación entre ejecuciones y no a la ruta de offload. Todas estas cifras son del propio autor del pull request, medidas una sola vez, en una sola máquina, y nadie las ha reproducido.

Los costes que admite el PR

Una lectura imparcial de este pull request incluye lo que se niega a hacer. Varios modos de ejecución se rechazan en el momento de la construcción en lugar de degradarse en silencio, y cada rechazo nombra el backend fijado como alternativa: los grafos CUDA de prefill, la atención con paralelismo de datos, la ruta de multiplexación de prefill-decode, el solapamiento de dos lotes, los grafos de decodificación de DLLM y los grafos compactos de verificación ragged quedan todos fuera. Y, igual de importante, no añade ninguna flag nueva ni ningún conmutador de cara al usuario: la ruta de staging es lo que hace el backend de archivos en hardware que antes no podía utilizarla en absoluto. Y la ejecución de precisión conlleva una salvedad que el autor ofrece por iniciativa propia: las ejecuciones con tope nunca contuvieron la tabla completa, porque la tabla es de 47.7 GiB y los topes llegan a ser tan bajos como 24 GB, así que una carga de trabajo con un patrón de acceso verdaderamente plano e impredecible sobre toda la tabla no es lo que se midió.

Por qué esto es importante específicamente para Qwen 4

Si se eliminan los detalles del motor, el patrón resulta legible. Alibaba publicó una vista previa de la arquitectura el 26 de agosto con instrucciones para que la comunidad de código abierto preparara entornos de ejecución, cuantización y motores de inferencia antes del lanzamiento de la familia completa. SGLang lo hizo y luego pasó tres semanas presentando pull requests sobre el único componente que hace que la arquitectura sea difícil de desplegar. Leído como un pronóstico, eso es una declaración sobre lo que Qwen 4 necesitará de tu hardware, no sobre lo que puede hacer en un benchmark.

También afina la cuestión de los plazos. Qwen 4 no se ha lanzado, y las especulaciones de septiembre en torno a él apuntan a la Apsara Conference de Alibaba, del 22 al 24 de septiembre en Hangzhou —el lugar donde se anunciaron generaciones anteriores de Qwen—. Nada de eso está confirmado, y el patrón del último ciclo de vista previa es que una vista previa de la arquitectura precede a la familia completa por meses, no por semanas. Que se abra un pull request tres días antes de esa conferencia es sugerente y nada más.

El resumen honesto de en qué punto deja esto a un lector: Qwen 4 no existe, Qwen3.8-Flash-Next sí, y el segundo te dice cuánto te costará ejecutar el primero. Si la tabla de 47.7 GiB sigue reduciendo su huella efectiva —y tres semanas de pull requests indican que se está trabajando mucho en ello—, entonces el umbral de despliegue para la familia Qwen 4 es más bajo de lo que sugería la semana de lanzamiento de la vista previa.

Lo que realmente puedes hacer con esto hoy

Nada en esta solicitud de extracción está disponible en main, y el modelo al que apunta no es algo que puedas llamar a través de una API. El checkpoint de pesos abiertos Qwen3.8-Flash-Next es una historia de autoalojamiento: tú descargas los pesos, los sirves tú mismo, y la ruta PLE respaldada por archivos es de lo que estás leyendo. No está enrutado aquí. Lo que está enrutado es la variante de producción — Qwen3.8-Flash, accesible como qwen/qwen3.8-flash a $0.15 por millón de tokens de entrada y $0.47 por millón de salida, con un contexto de 1M de tokens y entrada de texto, imagen y video — y el más grande Qwen3.8-Max a $2.00 y $6.00.

Esa distinción es la útil para un lector que decide qué hacer esta semana. La vista previa es investigación que uno mismo realiza; la variante servida es la ruta de producción de la misma arquitectura, y está a un solo endpoint de distancia. OrcaRouter repercute el precio de lista del proveedor con 0 % de margen, de modo que un cambio de precio de un proveedor en ese endpoint se refleja el mismo día en lugar de en el siguiente ciclo de facturación, y todos los modelos de la clave son accesibles a través de una única URL base compatible con OpenAI en vez de un contrato, un SDK y una credencial aparte por proveedor. Para una arquitectura tan joven —en la que el trabajo del motor sigue aterrizando cada semana y la hoja de ruta aún no se ha publicado—, la conmutación por error automática entre proveedores es la forma práctica de depender de la variante servida sin apostar una ruta de producción a la disponibilidad de un solo proveedor. Todo eso tiene que ver con los modelos que se pueden invocar hoy. No dice nada sobre Qwen 4, que no es uno de ellos.

Lo que todavía no sabemos

Si Qwen 4 entregará la misma tabla con el mismo tamaño. Si la pull request llega a fusionarse — tiene tres ejecuciones de CI fallidas y aún no tiene revisiones. Si la penalización de 0,5 a 1 milisegundo por paso se mantiene fuera de las configuraciones de baja concurrencia del autor. Y si Alibaba dice algo en Apsara el 22 de septiembre. Con la evidencia actual, lo más seguro que se puede concluir sobre Qwen 4 no es cuánto puntúa, sino cuánta maquinaria está construyendo la industria solo para hacerlo encajar — lo que es en sí mismo algo útil de saber antes de que el modelo tenga un nombre en cualquier catálogo.