Filtración de Qwen 4: SGLang fragmenta el prefill de Qwen4Exp para un TTFT 18% más rápido y recuperar un GiB por GPU

Una solicitud de incorporación de cambios abierta en el repositorio de SGLang a las 03:47 UTC de esta mañana, 2026-10-08, promete algo que ningún anuncio de Qwen 4 ha producido aún: un número. Se titula feat(qwen4-exp): habilitar el paralelismo de secuencia de LayerNorm para GR y PLE, y en cuatro GPU H20 que ejecutan el checkpoint de pesos abiertos Qwen3.8-Flash-Next en FP8, su autor informa mejoras en el tiempo hasta el primer token de 17,7–18,4 % con entrada de 32K y de 14,6–14,7 % con entrada de 235K, aproximadamente un gigabyte de memoria pico devuelta por GPU, y hasta un 22 % más de rendimiento de entrada. Qwen 4 en sí —la familia que el proveedor nombró pero no lanzó en la conferencia Apsara en Hangzhou el 2026-09-22— sigue sin publicarse, sin pesos, sin identificador y sin precio. El único modelo que instancia la arquitectura Qwen4Exp hoy es Qwen3.8-Flash-Next, publicado el 2026-08-26, y su hermano gestionado Qwen3.8-Flash es la versión a la que un cliente de API puede acceder realmente. Así que lea lo que sigue por lo que es exactamente: mediciones emparejadas de un ingeniero, adjuntas a una solicitud de incorporación de cambios abierta, en borrador y sin fusionar, sobre la envolvente de servicio de una familia de modelos que aún no existe.

Empecemos por el origen, porque esto es una filtración y la distinción tiene consecuencias reales. La señal es sgl-project/sglang#43048, abierta el 2026-10-08 a las 03:47 UTC por la cuenta de GitHub shiyang814-cpu, tocada por última vez a las 03:55 UTC y todavía marcada como borrador, sin ninguna revisión de aprobación registrada y sin fusión. Modifica seis archivos —dos archivos de prueba, el archivo del modelo Qwen4Exp, el módulo LayerNorm-SP, una factoría de límites de capa y un hook de grupo de argumentos—, con +345 y −50 líneas. Todas las cifras de rendimiento que aparecen a continuación provienen de la descripción del PR, son la propia medición emparejada OFF/ON del autor y nadie las ha reproducido. Tres ejecuciones de CI sobre la revisión en la punta de la rama están marcadas como fallidas. Nada de lo que hay aquí es una capacidad ya en producción.

Lo que realmente cambia el pull request

El paralelismo de secuencia no es un cambio del modelo y no es una capacidad nueva. Es un recableado de dónde realizan su aritmética unas pocas capas. Su linaje se remonta al paralelismo de secuencia al estilo Megatron —el truco de arXiv:2205.05198— y SGLang ya lo incorpora: el propio docstring del módulo explica el mecanismo que reutiliza, que, bajo paralelismo de tensores puro, un all_reduce en paralelo por filas es algebraicamente un reduce_scatter seguido de un all_gather. Como esos dos colectivos mueven exactamente los mismos bytes que el único all_reduce que reemplazan, dividir la operación de esa manera no cuesta ningún volumen de comunicación adicional. Lo que aporta es la libertad de dejar que las regiones de normalización y residuales se ejecuten sobre activaciones fragmentadas por secuencia —cada rango de paralelismo de tensores tiene una fracción 1/tp de las filas de tokens—, lo que reduce la memoria de activaciones transitorias que el prefill de contexto largo necesita mantener viva.

Lo que hace esta solicitud de extracción en particular es extender esa ruta existente desde la arquitectura en la que se validó hasta la arquitectura Qwen4Exp. Durante el prefill, las activaciones de Gated Residual y Per-Layer Embedding permanecen fragmentadas a lo largo de la dimensión de tokens entre el grupo TP. Antes de la atención, antes de GDN, antes de QSA y antes de que se ejecute el bloque de Mixture-of-Experts, se vuelven a reunir todas las filas completas de tokens mediante all-gather, la computación tensor-parallel de fila completa existente se ejecuta sin cambios detrás de un fallback compartido, y luego un reduce-scatter suma las contribuciones parciales y restaura el fragmento de cada rank. Decode nunca toca la nueva ruta en absoluto. Se accede a la funcionalidad a través de la opción que ya existe — --enable-layernorm-sp — sin ninguna bandera específica de Qwen4Exp, y con la bandera ausente el código se comporta exactamente como lo hacía antes.

Por qué Qwen4Exp es la arquitectura que necesita esto

La razón por la que esto es importante específicamente para Qwen4Exp, y no por igual para todos los modelos, está en el propio diseño de la arquitectura. Qwen3.8-Flash-Next aplica proyecciones Gated Residual a todas las filas de tokens en cada capa del decodificador — la configuración declara cuatro flujos residuales y un rango de cuello de botella de 320 en 48 capas — y Per-Layer Embedding añade una segunda proyección replicada, fila de tokens por fila de tokens, además de eso. Bajo paralelismo tensorial, ambas operaciones se duplican de forma idéntica en cada rango, porque no llevan consigo ninguna matriz de pesos con particionado TP propia que fuerce una división. Particionar su dimensión de tokens elimina directamente el trabajo replicado y, como lo expresa la sección de motivación del PR, eso ocurre mientras se preserva el diseño tensorial paralelo existente y la semántica de reducción de atención, GDN/QSA y MoE — que es la parte que hace que el cambio sea seguro en lugar de ingenioso.

Vale la pena decir con claridad lo que eso significa para el lector. Lo interesante de este PR no es que SGLang se esté volviendo más rápido. Es que la arquitectura Qwen4 conlleva costos por capa que escalan con el número de tokens en lugar de con el número de parámetros, y esos costos son los que pasan factura en los prefills largos. Eso es una huella de diseño, y es el tipo de cosa que una ficha técnica nunca menciona.

Los deltas medidos

El benchmark del autor fija una configuración y alterna el flag: cuatro GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, paralelismo tensorial 4 y paralelismo de expertos 4, tamaño de prefill por fragmentos 8192, backends de prefill y decodificación de atención lineal de FlashInfer, la misma configuración de servidor para OFF y ON, reinicios del servicio alternando OFF → ON → OFF → ON, y entradas de tokens fijas con solicitudes de calentamiento. Cada cifra a continuación proviene de esa configuración y no está auditada:

• Entrada de 32K, tamaño de lote 1 — TTFT mejoró un 17,72–18,36 %, la latencia de extremo a extremo cerca del 16 %, el rendimiento de entrada cerca del 20 %

• Entrada de 235K, tamaño de lote 1 — TTFT mejoró entre 14,63 y 14,71 %, latencia de extremo a extremo alrededor del 14 %, rendimiento de entrada alrededor del 17 %

• Entrada de 32K, tamaño de lote 4 — TTFT mejoró un 18,74 %, la latencia de extremo a extremo un 18,14 % y el rendimiento de entrada un 22,14 %

• Memoria máxima — reducida en aproximadamente 1,0 GiB por GPU

• Decodificación, tamaño de lote 1 — el tiempo por token de salida prácticamente sin cambios

La última línea es la que hay que leer dos veces, y el autor es sincero sobre por qué: esta optimización solo está habilitada para prefill, así que la decodificación de flujo único no obtiene nada de ella. La mejora de tiempo por token con lote de 4, donde aparece, refleja retrasos de planificación reducidos debidos a prefills largos concurrentes, no un kernel de decodificación más rápido. Si esperabas que esto fuera una historia de rendimiento, no lo es: es una historia de latencia hasta el primer token y de memoria, y esas son las dos restricciones que deciden si una solicitud de 235K tokens se puede servir siquiera.

El error de diseño que tuvieron que corregir primero.

La parte más informativa del pull request no es la tabla de aceleración. Es la sección sobre el diseño de filas físicas de PLE, porque muestra lo que el stack de servicio de Qwen4Exp todavía hace mal.

Per-Layer Embedding opera sobre un bucket físico fijo de CUDA-graph, mientras que solo un prefijo de las filas de ese bucket puede contener tokens reales. Por lo tanto, el padding tiene que aplicarse antes de que la secuencia se fragmente, no después. En el fragmento final de una solicitud de 235K tokens, los números del autor son 5.624 tokens procesados dentro de un bucket físico de 8.192 filas con TP 4, y el único layout correcto es que el rank 0 contenga 2.048 filas válidas, el rank 1 contenga 2.048 filas válidas, el rank 2 contenga 1.528 filas válidas más 520 filas de padding, y el rank 3 contenga 2.048 filas de padding. Fragmentar primero las 5.624 filas procesadas —la implementación obvia— inserta padding entre rangos válidos globalmente contiguos y corrompe el resultado. El autor registra que una prueba real OFF/ON de 235K solo produjo una salida greedy idéntica de 16 tokens después de que se corrigiera este layout.

Eso es un detalle pequeño con una gran implicación. La ruta PLE en SGLang se añadió lo suficientemente recientemente como para que un bug de ordenación de tokens de esta forma todavía fuera posible, y la persona que lo encontró estaba escribiendo la extensión sequence-parallel. El soporte de serving desde el día cero para esta arquitectura no está terminado; está siendo construido activamente, en público, por colaboradores, un layout a la vez.

Lo que te cuesta: las restricciones

Una bandera que solo ayuda a algunas implementaciones solo es útil si sabes a cuáles. El PR declara sus requisitos de forma explícita, y las configuraciones que quedan fuera de ellos fallan durante la validación de argumentos en lugar de degradarse silenciosamente:

• El tamaño del paralelismo de tensores debe ser mayor que 1 — un despliegue con una sola GPU no aporta nada, porque no hay ningún rango entre el que fragmentar

• Expert parallel size debe ser tensor parallel size

• El tamaño del paralelismo de pipeline debe ser igual a 1

• La atención con paralelismo de datos debe estar desactivada

• La decodificación especulativa debe estar deshabilitada

La última restricción es la que tiene una decisión real detrás. Para un modelo disperso que activa alrededor de 6B parámetros por token, la decodificación especulativa es una de las pocas palancas que acelera la decodificación, y esta característica desactiva explícitamente esa palanca a cambio de una ventaja en prefill. Si tu carga de trabajo es de prompt largo y salida corta —análisis de documentos y bases de código, resumen de vídeo, un contexto grande leído una sola vez—, el intercambio es directamente bueno. Si tu carga de trabajo es un prompt corto y una generación larga, estás renunciando a lo que te estaba ayudando y comprando un número que no se aplica a ti. El requisito de que expert-parallel sea igual a tensor-parallel es el otro a tener en cuenta: significa que la geometría de sharding de MoE tiene que coincidir exactamente con la geometría de TP, lo que descarta varias configuraciones multinodo que de otro modo serían razonables.

Qué dice esto sobre la cronología de Qwen 4

Si lees el diff de otra manera, obtienes un calendario. El módulo LayerNorm-SP de SGLang en la rama main lleva hoy una lista de permitidos explícita de las arquitecturas para las que se ha validado la función y, en el momento de escribir esto, esa lista de permitidos contiene exactamente una entrada, Qwen3ForCausalLM — todas las demás arquitecturas se rechazan en el momento de la construcción si pasas el flag. Por lo tanto, añadir Qwen4Exp a esa ruta no es un simple retoque a una abstracción madura; es la primera vez que la arquitectura Qwen4 se incorpora a una optimización que la precede por generaciones.

Si se contrasta eso con el registro público, el panorama es coherente. El proveedor anunció el 2026-09-22 que Qwen 4 está en entrenamiento y adelantó cuatro nombres de niveles —Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus y Qwen 4 27B— sin especificaciones asociadas a ninguno de ellos. La vista previa de pesos abiertos que comparte la arquitectura, Qwen3.8-Flash-Next, está disponible para descargar desde el 2026-08-26. Lo que ha ocurrido en las tres semanas transcurridas desde entonces es exactamente lo que cabría esperar entre «en entrenamiento» y «lanzamiento»: autores de motores poniendo a punto el runtime para que el soporte desde el día cero sea real y no nominal. Una pull request que hace que una optimización de servicio funcione en la arquitectura, abierta en la mañana del 2026-10-08 y todavía en borrador, es una señal mejor sobre lo cerca que está Qwen 4 de ser servible que cualquier fecha que alguien haya barajado. Además, y de forma enfática, no es una fecha de lanzamiento: el flag está desactivado de forma predeterminada, el cambio no está fusionado, y el modelo que evalúa es la vista previa, no Qwen 4.

Lo que puedes llamar hoy

Nada de eso cambia lo que está realmente disponible esta tarde. Qwen3.8-Flash-Next es real, sus pesos están en Hugging Face y puedes alojarlo tú mismo, pero no está en nuestro catálogo y no vamos a fingir lo contrario. El nivel que sí servimos es qwen/qwen3.8-flash, el hermano gestionado que ejecuta la misma arquitectura Qwen4-preview con una ventana de contexto de 1M de tokens y entrada de texto, imagen y vídeo, con un precio de 0,15 $ por millón de tokens de entrada, 0,47 $ por millón de salida y 0,0184 $ por millón de lecturas de caché. Es un precio de tarifa repercutido con un 0 % de margen, así que cuando el proveedor lo mueve, la cifra de tu factura se mueve el mismo día, y no cuando a un intermediario le apetezca volver a publicar una tabla.

Hay una segunda razón, menos obvia, para preocuparse por una capa de enrutamiento aquí. Todo en este artículo trata sobre una vista previa no probada más un parche en borrador: el tipo de cosa que quieres probar sin apostar una ruta de producción a ella. Para eso está la conmutación por error: pon la vista previa detrás de la misma clave que el modelo en el que ya confías, observa cómo se comporta con tu tráfico y deja que la solicitud recaiga en la ruta que sabes que funciona cuando un proveedor falla o el endpoint no está ahí. Una API para más de 200 modelos, un solo conjunto de credenciales, sin firmar un segundo contrato para averiguar si una nueva arquitectura merece tu atención.

Dos cosas que observar a partir de aquí, y ninguna de las cuales podemos predecir. La primera es si este parche llega a fusionarse: es un borrador con tres ejecuciones de CI fallidas en un cambio de seis archivos de una cuenta de colaborador sin historial previo en el repositorio, y la fluidez del trabajo de diseño de filas de PLE sugiere que el autor todavía está iterando. La segunda es si la lista de permitidos crece — si Qwen4Exp se une a Qwen3ForCausalLM como arquitectura validada, entonces esto deja de ser una fuga y se convierte en la forma predeterminada en que se sirve un modelo de la familia Qwen4 en contexto largo. Hasta que ocurra una de esas cosas, trata el 18% como una promesa sobre hacia dónde va el entorno de ejecución, no como un número que puedas alquilar.