Qwen 4 QSA obtiene paralelismo de contexto de decodificación: dentro del PR en borrador de vLLM para Qwen3.8-Flash-Next

El 29 de septiembre de 2026 apareció una pull request en borrador en el repositorio de vLLM titulada “[Model][DCP] Support Qwen4Exp QSA”, y, para el modelo que describe, contiene las cifras de servicio más concretas que se hayan publicado en todo el mes: ejecuciones emparejadas de Qwen3.8-Flash-Next en cuatro GPU que muestran la capacidad de tokens KV pasando de 9.759.529 a 17.603.636, la concurrencia máxima de 37,23× a 67,15×, y el tiempo hasta el primer token reduciéndose de 1.869 ms a 767 ms. Qwen3.8-Flash-Next es la vista previa de mezcla de expertos, de pesos abiertos y 125.000 millones de parámetros, cuya ficha de Hugging Face la describe como «Una vista previa de la arquitectura Qwen4»; la pull request añade paralelismo de contexto de decodificación a la ruta de atención dispersa sobre la que está construida esa arquitectura. Qwen4 en sí —los niveles Qwen4 Max, Flash, Plus y 27B que el proveedor nombró en su conferencia Apsara el 22 de septiembre de 2026— sigue sin lanzarse, sin pesos, sin identificador, sin precio y sin fecha. Así que lee esto por lo que es: no un lanzamiento, no un benchmark, sino un artefacto de ingeniería que te dice cómo se está ampliando la envolvente de servicio de Qwen4 antes de que la familia exista.

Este es un artículo de lo que sabemos hasta ahora, y las fuentes importan más de lo habitual. La pull request es un borrador, abierta y sin fusionar — vllm-project/vllm#59279, abierta el 2026-09-29 por Sungsoo Ha, ingeniero de software de NVIDIA, y todavía en borrador. Cada número a continuación es la medición pareada del propio autor, reportada en el cuerpo del PR, tomada en una revisión anterior del mismo trabajo. Nada de esto ha sido auditado de forma independiente, nada de esto ha llegado a una versión, y la advertencia que el autor adjunta es lo suficientemente relevante como para tener su propia sección a continuación.

Lo que realmente cambia el pull request

El paralelismo de contexto de decodificación —DCP— es una técnica de servicio, no un cambio en el modelo. En lugar de que un solo grupo de GPU contenga una caché KV completa, DCP divide esa caché entre los rangos, de modo que cada rango lee solo su porción del contexto mientras los resultados de atención se combinan entre los rangos al final. El objetivo es la capacidad: con la caché particionada, un despliegue puede sostener mucho más tráfico concurrente de contexto largo en el mismo hardware, que es exactamente la restricción que aprieta cuando cada solicitud lleva un cuarto de millón de tokens.

La complicación es que Qwen Sparse Attention —QSA— no es una capa de atención común. Tal como especifica la tarjeta de modelo de Qwen3.8-Flash-Next, un indexador ligero comprime las claves en microbloques con una relación de compresión de 4, las puntúa y conserva los mejores 512 bloques, aproximadamente 2.048 posiciones de token, mientras que el softmax final y la agregación de valores siguen ejecutándose sobre las K y V sin comprimir. Eso significa que QSA conlleva más estado que una caché KV: está la caché principal y están las cachés de selector y laterales que mantiene el indexador. La implementación genérica de DCP en vLLM no sabe nada de todo eso.

Lo que hace el #59279, según su descripción, es enseñarle a DCP las partes específicas de QSA:

• Cada rango lee su propia parte de la principal caché KV, mientras que el selector de QSA y las cachés secundarias permanecen replicados entre los rangos en lugar de fragmentados.

• Los resultados de atención se combinan entre rangos después de la lectura dividida.

• El selector y la caché KV principal se mantienen en un mismo grupo de caché, por lo que no pueden desincronizarse.

• Se evita que los lotes sintéticos V2 escriban en las cachés laterales de QSA.

Ese último par de detalles es la parte interesante si te importa la corrección más que el rendimiento. Una caché de atención fragmentada que discrepa silenciosamente de un selector replicado es el tipo de error que se manifiesta como una lenta degradación de la precisión en contextos largos en lugar de un fallo, y el cambio deja explícito que mantiene ambos sincronizados. El autor también afirma que se utilizó asistencia de IA y Codex figura como coautor; vale la pena decirlo sin rodeos, porque en un PR en borrador de estas características es legítimo preguntar quién escribió qué.

Los números emparejados, y cómo se tomaron

El plan de pruebas es lo suficientemente específico como para ser verificable, por lo que los resultados merecen citarse. Ambos brazos sirven Qwen/Qwen3.8-Flash-Next-FP8 en cuatro GPU con paralelismo tensorial 4 y paralelismo de expertos habilitado, con --gpu-memory-utilization 0.90 y la caché de prefijos activada. La única diferencia entre los dos brazos es --decode-context-parallel-size: se omite para DCP=1, se establece en 2 para DCP=2, con un reinicio entre brazos para que el benchmark comience desde una caché fría. La carga es una traza AgentX de 256k con 128 usuarios durante 900 segundos; la precisión se evalúa con EvalScope para GSM8K más el evaluador MRCR incluido en el repositorio, ejecutado seis veces por brazo, descartando la primera ejecución después del reinicio.

Los deltas de rendimiento reportados, DCP=2 frente a DCP=1:

• Tokens KV: 9,759,529 frente a 17,603,636, un aumento de 1.80× en la capacidad de caché.

• Concurrencia máxima — 37,23× frente a 67,15×, también 1,80×.

• Solicitudes por segundo — 1,69 vs 2,30, 1,36×.

• Tokens de entrada por segundo — 128,730 frente a 179,702, 1.40×.

• Tiempo hasta el primer token: 1.869 ms frente a 767 ms, 2,44× menor.

• Latencia entre tokens — 43,48 ms frente a 26,27 ms, 1,66× menor.

• Tasa de aciertos de la caché de prefijos en estado estacionario — 67,85 % frente a 88,98 %, una ganancia de 21,1 puntos porcentuales.

La exactitud, reportada como media ± desviación estándar muestral en las ejecuciones posteriores al calentamiento, se mantuvo esencialmente constante: el agregado de MRCR fue de 0,8630 ± 0,0005 con DCP=1 frente a 0,8697 ± 0,0153 con DCP=2, y GSM8K fue de 0,9788 ± 0,0020 frente a 0,9790 ± 0,0016. Las muestras de MRCR de 2 agujas y de 4 agujas se fijaron en 0,9960 y 0,9906 en ambos brazos, así que toda la variación entre ejecuciones provino de las muestras de 8 agujas, y una ejecución agregada con DCP=2 obtuvo 0,8970, mientras que las otras cuatro se situaron entre 0,8620 y 0,8632. Eso es una dispersión real, no ruido que se pueda desestimar, y se declara en el PR en lugar de disimularla.

Lo que estos números no establecen

La advertencia está en el texto del PR y no es menor. Los resultados pareados de AgentX y de exactitud se midieron en una anterior revisión de QSA DCP, usando una nightly de vLLM basada en el commit 3df4ae153eb. El commit limpio final en el pull request incluye una corrección posterior del kernel de localización de QSA y ha superado una validación enfocada en B200 — pero las evaluaciones completas de AgentX y de exactitud no se han repetido en ese código fuente exacto. En otras palabras: la historia del rendimiento y el diff enviado no son el mismo artefacto, y el autor lo dice.

Más allá de eso, se aplica la disciplina habitual, y aquí se aplica con dureza. Estos son números de una única configuración, de un único colaborador y en una única instalación de cuatro GPU. Son afines al proveedor más que neutrales: que un colaborador de un framework mida un cambio en el framework es algo normal y útil, pero no es una auditoría independiente, y ningún tercero ha reproducido la ejecución. No hay ninguna versión de vLLM publicada que puedas instalar hoy que contenga este cambio, porque el cambio no se ha fusionado. Y DCP=2 es una división en dos de una forma específica; los deltas no son una promesa sobre lo que harían DCP=4 o DCP=8, y nada en el PR afirma que lo sean.

Por qué un PR de serving sobre una arquitectura no publicada todavía vale la pena tu tiempo

La objeción obvia: el modelo del título no existe, así que ¿por qué debería importarnos? Porque lo que se está ajustando no es Qwen 4. Es Qwen3.8-Flash-Next, y ese modelo sí existe: Alibaba lo publicó el 24 de agosto de 2026 como un MoE de 125B parámetros con 6B activados, una tabla de embeddings de n-gramas de 51 mil millones de parámetros, una cabeza MTP de 4B para decodificación especulativa, 48 capas dispuestas como doce repeticiones de tres bloques Gated DeltaNet seguidas de un bloque QSA, 512 expertos con 10 enrutados y 1 compartido activo, y un contexto nativo de 262,144 tokens que, según la ficha, es ampliable a 1,000,000. Es la implementación de referencia de la arquitectura Qwen4 en pesos abiertos, y QSA —la atención dispersa de microbloques que esta pull request está enseñando a DCP a fragmentar— es la parte más distintiva de todo ello.

Lo que describen las cifras es lo que ocurre cuando dejas de tratar ese contexto de 262K como algo que un solo grupo de GPU tiene que mantener entero. El salto de 1,80× en capacidad de tokens KV y concurrencia es la aritmética de dividir una caché en dos, que es el resultado menos sorprendente de la lista. Las cifras más interesantes son las de latencia: 2,44× menos tiempo hasta el primer token y 1,66× menos latencia entre tokens con la misma carga ofrecida, además de una mejora de 21 puntos en la tasa de aciertos de la caché de prefijos en estado estacionario. Estas indican que la ruta DCP no solo está comprando capacidad a costa de latencia; en esta ejecución emparejada compró ambas. Esa es la forma de cambio que le importa a cualquiera que sirva tráfico de agentes con prompts de sistema muy largos, porque el comportamiento de la caché de prefijos en contexto largo suele ser donde el rendimiento de contexto largo muere en silencio.

Y esto no es un parche aislado. Esa misma semana produjo un conjunto de trabajo sobre el motor Qwen4Exp: #59214 añade planes GEMM de decodificación de baja latencia para SM100 orientados a formas de B200, #59010 añade un kernel de prefill disperso nativo para SM90 destinado a la ruta QSA en Hopper, #58977 cubre los embeddings BF16 INC PLE, y #58961 —el que realmente se ha fusionado, el 2026-09-28— corrigió una caché KV de perfilado que las vistas de claves QSA mantenían viva. Leídos en conjunto, constituyen la envolvente de servicio de la arquitectura Qwen4 que se está construyendo en público, en los runtimes, meses antes de que la familia se lance. Si estás planificando para Qwen 4, la señal útil no es una fecha de lanzamiento —no existe—, sino lo que los kernels y las disposiciones de caché ya dan por sentado sobre cómo tendrás que servirlo.

Lo que puedes llamar hoy

Si quieres probar el comportamiento de contexto largo en la arquitectura de la que trata este PR, el modelo al que debes recurrir es el nivel Flash que Alibaba realmente sirve. Qwen3.8-Flash —el despliegue de producción basado en Qwen3.8-Flash-Next, con un contexto de 1.000.000 de tokens y una salida máxima de 131.072 tokens, que admite entrada de texto, imagen y vídeo— está disponible, y es un endpoint para el modelo que realmente ejecuta la arquitectura Qwen4Exp hoy, listado como qwen/qwen3.8-flash a $0.15 por millón de tokens de entrada y $0.47 por millón de tokens de salida, con lecturas de caché a $0.0184. Como esos son precios de lista del proveedor que se trasladan sin margen de nuestra parte, un cambio de precio o de límite por parte del proveedor en él te llega el mismo día en que se anuncia.

Dos salvedades honestas. Primero, Qwen3.8-Flash-Next en sí —los pesos FP8 del plan de pruebas del pull request, los que necesitarías para reproducir cualquiera de estas mediciones localmente— no está en nuestro catálogo; el nivel Flash servido es la línea de producción de QwenCloud, no el checkpoint de vista previa sin procesar. Si quieres ejecutar la configuración exacta del PR, estarás autoalojándote en cuatro GPU. Segundo, el cambio de DCP no está fusionado, así que nada a lo que puedas llamar hoy en ningún sitio lo está ejecutando. Lo que te ofrece el nivel servido es una forma de averiguar si tu carga de trabajo tiene siquiera la forma adecuada para el problema que resuelve DCP: si tus prompts son largos, agénticos y con mucho prefijo, entonces la capacidad de 1,80× y el delta de la caché de prefijos son los números que debes vigilar en tus propias trazas.

Y si la parte interesante para ti no es un solo modelo, sino la cuestión del cambio —sobre qué nivel construir mientras la línea Qwen 4 sigue sin nombre—, eso es un problema de enrutamiento más que de servicio, y una API para más de 200 modelos es la forma de mantener la opción abierta sin un segundo contrato ni un cambio de código cuando la familia por fin llegue.

Preguntas que vale la pena responder directamente

¿Significa #59279 que Qwen 4 ya salió, o que está a punto de salir?

No. La pull request trata sobre la arquitectura Qwen4Exp tal como está implementada en Qwen3.8-Flash-Next, que Alibaba lanzó el 24-08-2026. La familia Qwen 4 —Max, Flash, Plus y 27B— fue anunciada sobre un escenario en Apsara el 22-09-2026 y situada en una hoja de ruta de la empresa con una línea sucesora proyectada en 5 a 10 billones de parámetros, y todavía no tiene ficha de modelo, ni pesos, ni identificador de API, ni ventana de contexto, ni precio ni fecha. Una PR de framework que añade un modo de paralelismo a la arquitectura preliminar es un paso hacia servir bien a Qwen 4. No es un paso hacia que Qwen 4 exista.

¿En qué se diferencia el paralelismo de contexto de decodificación del paralelismo de tensores?

Dividen cosas distintas y fallan de maneras distintas. El paralelismo de tensores reparte los pesos y el cómputo de cada capa entre las GPU, así que cada rank participa en cada token pero ve toda la secuencia. El paralelismo de contexto de decodificación divide la caché KV en sí misma, así que cada rank solo mantiene y lee una porción del contexto, y los resultados parciales de atención se fusionan después. TP se trata de hacer que el modelo quepa; DCP se trata de hacer que quepan el contexto y el tráfico concurrente que viaja sobre él. Esa distinción es exactamente la razón por la que este PR no es trivial: el selector y las cachés auxiliares de QSA no pueden fragmentarse simplemente de la forma en que puede la caché KV principal, así que el cambio tiene que fragmentar una y replicar las otras, y luego demostrar que ambas se mantienen consistentes.

Si llamo a Qwen3.8-Flash-Next hoy a través de una API alojada, ¿ya obtengo estos números?

No, y la brecha tiene tres partes. El cambio no está fusionado, así que ninguna compilación publicada de vLLM lo contiene. Incluso una vez fusionado, el proveedor tiene que adoptar esa compilación y elegir ejecutarla con un tamaño de DCP superior a uno; es una configuración de servicio, no un valor predeterminado. Y los deltas medidos son de una revisión anterior del parche, en lugar del commit final, el cual, según afirma el autor, hasta ahora solo ha tenido una validación centrada en B200. Considera los deltas reportados como una cota superior bien documentada de lo que aporta el enfoque en una configuración, no como una especificación de cualquier endpoint que puedas alquilar esta semana.

La pregunta abierta

Lo que hay que observar no es si este borrador específico se fusiona —probablemente lo hará de alguna forma, ya que el manejo de caché específico de QSA que añade es una laguna genuina y no una preferencia. Lo que hay que observar es si el commit final recibe la misma evaluación emparejada que recibió la revisión intermedia. Un cambio en el serving cuyas afirmaciones de rendimiento provienen de una compilación y cuyas afirmaciones de corrección provienen de otra es, por ahora, una propuesta bien argumentada en lugar de un resultado medido, y la dispersión de precisión en las muestras de MRCR de 8 agujas es lo suficientemente amplia como para que repetir la ejecución en el código fuente publicado sea lo más útil que cualquiera podría publicar al respecto. Hasta entonces: la dirección es legible, el registro no está cerrado, y el único modelo con arquitectura Qwen4 en pesos abiertos sigue siendo el de agosto.