Qwen4-Exp QSA llega al Ascend de Huawei: dentro del PR de prefill CANN opcional de SGLang

El 30 de septiembre de 2026, un colaborador abrió el pull request #41855 de SGLang, titulado “[NPU] Añadir atención dispersa CANN opcional para el prefill QSA de Qwen4-Exp”, y la parte interesante no es la aritmética. Es el hardware. La arquitectura Qwen4Exp ahora tiene una ruta de atención dispersa escrita a mano para el acelerador Ascend 910C de Huawei, detrás de un flag que, de forma predeterminada, está desactivado, en un pull request en borrador que no se ha fusionado — mientras que el modelo al que pertenece ese nombre de arquitectura, Qwen4-Exp, nunca se ha publicado en ninguna forma. El único checkpoint que lleva esta arquitectura en pesos abiertos sigue siendo Qwen3.8-Flash-Next, la vista previa de mezcla de expertos de 125.000 millones de parámetros que el proveedor publicó en Hugging Face el 24 de agosto de 2026, y cuya ficha de hecho declara su arquitectura como qwen4_exp. Qwen 4 en sí —los niveles Max, Flash, Plus y 27B que el proveedor nombró en su conferencia Apsara el 22 de septiembre de 2026— todavía no tiene pesos, ni identificador, ni precio, ni fecha. Así que esto es un artículo de lo que sabemos hasta ahora sobre un artefacto de ingeniería, no un lanzamiento: una pila de servicio de un proveedor más que decide en silencio que vale la pena dar soporte temprano a una arquitectura no publicada.

Lo que realmente añade la pull request

El cambio es deliberadamente pequeño y deliberadamente acotado. Cinco archivos, un commit, +355 líneas frente a una rama main en el commit b87a241, con la etiqueta SGLang npu. El autor, w1ida, declara por adelantado la intención: una ruta de atención principal CANN opcional para el prefill eager de Qwen4-Exp QSA, construida sobre torch_npu.npu_sparse_flash_attention, con el indexador, la selección Top-K, el presupuesto de tokens y el contenido de la caché KV dejados exactamente como estaban.

El truco que usa para llegar ahí merece un párrafo, porque explica por qué esto es un adaptador de layout en lugar de un nuevo kernel de atención. Para Q y K ya rotados, la ruta empaqueta la caché como C = [K, V] y la consulta como Q' = [Q, 0]. El producto Q' @ C.T entonces equivale a Q @ K.T, y como la consulta con padding no aporta nada, softmax(scale * Q' @ C.T) @ C devuelve [P @ K, P @ V] apilados —así que la mitad V se puede extraer. En palabras del propio autor, esto es “un embedding de layout de atención, no un cambio a la atención del modelo ni una compresión KV de bajo rango”. Cada cabeza KV se convierte en un lote independiente en el layout nativo de MLA, se conserva la escala original D256 y el RoPE auxiliar se pone a cero.

Los detalles operativos importan tanto como las matemáticas:

• Habilitación — SGLANG_NPU_QSA_NATIVE_PREFILL=1, por defecto desactivado. Solo ForwardMode.EXTEND ordinario se activa; decodificación, modos especulativos, forward mixto y captura de grafo permanecen todos en las rutas existentes, y la captura de grafo omite el adaptador por completo.

• Hardware y tipo de dato — BF16 con dimensión de cabeza 256, Ascend 910C (Ascend910_93*), probado con CANN 9.0 y torch-npu 2.10. Cualquier tipo de dato o forma no compatible recurre silenciosamente a la ruta de referencia.

• Formas de cabeza: los pares locales compatibles (cabezas Q, cabezas KV) son (16,2), (24,2), (12,1), (6,1) y (3,1). CANN rechaza de plano una relación query/KV de 12 — su tiler solo acepta potencias de dos —, así que las cabezas se rellenan 12→16, 6→8 o 3→4 y las salidas añadidas se descartan. Esta es la señal más clara en todo el PR de que el hardware no se diseñó pensando en proporciones de cabezas de atención dispersa, y el adaptador está absorbiendo ese desajuste en lugar de que el modelo cambie de forma para ello.

• Límites de tamaño — solo se empaqueta la extensión física de caché referenciada, limitada a 262,144 tokens, que el autor calcula como máximo en 512 MiB para el tensor K/V BF16 empaquetado con dos cabezas KV. El padding interior -1 se detecta y se redirige al fallback, porque CANN requiere ranuras válidas contiguas; las filas totalmente enmascaradas conservan la convención existente de salida cero.

• Por qué solo prefill — la comprobación de extensión y diseño copia dos escalares al host, y las copias temporales más el espacio de trabajo nativo consumen memoria. Esa sincronización es la razón por la que la ruta está restringida a prefill eager y se mantiene desactivada durante la captura.

Nueve pruebas que pasaron, y un número de velocidad que no provino de esta rama

La evidencia de corrección es específica y reproducible, lo que es más de lo que ofrecen la mayoría de los PR de kernel. El autor informa que 9 pruebas pasan en 40,772 segundos en un Ascend 910C (Ascend910_9362) con CANN 9.0 y torch-npu 2.10.0, sin necesidad de checkpoint: Q/K/V BF16 aleatorios no nulos contra una referencia de CPU FP32 calculada a partir de las mismas entradas BF16, ranuras físicas desordenadas en anchos 1/63/64/65/2051, escalas predeterminadas y explícitas, filas totalmente enmascaradas, filas cero, ancho de selección cero, tensores no contiguos, restos de cola causal con relación de compresión 4, de 0 a 3, mapeo físico de dos solicitudes con un prefijo compartido, reutilización del contenido de la caché y las formas de cabeza locales de Flash-Next en 1 y 257 filas de consulta.

El caso principal es un prefill largo: 7.810 tokens de consulta contra una caché de 65.536 tokens con 2.051 slots seleccionados por consulta, todas las salidas finitas, con ocho filas muestreadas comparadas contra la referencia FP32. El error L2 relativo observado alcanzó el 0,209 % en los casos pequeños de forma de cabeza y el 0,231 % en las filas muestreadas del prefill largo, frente a los umbrales de prueba de atol=0.025, rtol=0.025 y L2 relativo por debajo de 0,008, con las filas vacías obligadas a ser exactamente cero. La memoria NPU máxima asignada para esa ejecución se cita en 1.042,7 MiB — y el autor la etiqueta como la métrica del asignador de PyTorch, no como HBM de placa y no como memoria del modelo completo, que es exactamente la advertencia correcta que hay que adjuntar.

Luego está el número que se citará y que no debería serlo. El cuerpo del PR incluye una tabla de velocidad que muestra la ruta de atención local existente a 2.270,79 tokens nuevos por segundo y la atención principal nativa empaquetada a 3.890,06 — una mejora de 1,713× / +71,3 %, con el tiempo medio hasta el primer token cayendo de 3,109 s a 1,812 s. El autor es explícito en que estas son mediciones históricas de prototipo tomadas el 29 de septiembre de 2026 sobre un Whittle-Next-26B-A3B checkpoint adaptado, ejecutado en TP1 con pesos W8A8 y atención BF16 en 910C bajo CANN 9.0, utilizando el arnés oficial de sglang.bench_serving con concurrencia 1, con seis solicitudes, un token de salida cada una, y 36.096 tokens de prefijo en caché excluidos del rendimiento de tokens nuevos. Ellos no son un benchmark de la rama upstream en el PR, los artefactos JSON de servicio originales no están presentes en el checkout, y resultados locales posteriores de alrededor de 5.000 tokens por segundo utilizaron trabajo adicional del indexador nativo y de block4 que explícitamente no se atribuye a este cambio. El autor también señala que los pesos del indexador del checkpoint adaptado son inertes y que su presupuesto difiere del original, por lo que nada de esto es evidencia sobre la corrección del indexador o la calidad de generación con presupuesto completo.

Una aclaración sobre el nombre, ya que confundirá a cualquiera que busque el checkpoint: el modelo de benchmark es el propio artefacto adaptado del colaborador. Por separado, “Whittle-Next” también es el nombre de una serie pública de modelos MoE ajustados derivados de Qwen3.8, publicada por una cuenta de terceros de Hugging Face, que incluye una variante 26B-A3B subida en septiembre. Esos no son el modelo Qwen4Exp al que apunta este PR, y no deben interpretarse como la configuración de benchmark detrás de esa cifra de 1.713×.

Otras dos advertencias provienen del autor, no de mí. La integración completa del servicio, el paralelismo tensorial distribuido y el modelo completo Qwen3.8-Flash-Next no se han validado en esta rama; el colaborador dice que mantenerlo como borrador mientras se discute la cuestión de la integración y las dependencias es deliberado, e incluso pregunta en el cuerpo del PR si el adaptador debe ir en SGLang o en el repositorio separado sgl-kernel-npu. La CI tampoco está limpia: el bloque de estado del cuerpo del PR muestra fallos en PR Test (Base), PR Test (Extra) y la ejecución de AMD ROCm 10. La corrección descrita anteriormente es a nivel de operador; nada en el PR afirma un resultado de precisión o rendimiento de extremo a extremo en la pila integrada.

Por qué QSA es la parte incómoda, en cifras

Qwen Sparse Attention no es una capa de atención convencional, y la configuración publicada muestra por qué un proveedor de aceleradores tiene que escribir una ruta específica para ella. Según la configuración de Qwen3.8-Flash-Next: 48 capas dispuestas como doce repeticiones de tres bloques Gated DeltaNet seguidas de un bloque de atención completa, full_attention_interval 4, tamaño oculto 2,560, dimensión de cabeza de atención 256, 24 cabezas de consulta frente a 2 cabezas KV, dimensión de RoPE 64. El indexador que hace que la atención sea dispersa es una estructura multi-consulta con 4 cabezas de consulta que comparten 1 cabeza de clave, dimensión de cabeza 128, una relación de compresión de 4 y un presupuesto de 2,048 microbloques seleccionados por consulta.

Ese presupuesto es lo que el PR mantiene fijo. El tamaño de bloque disperso se mantiene en 1, el modo disperso se mantiene en 0, el modo de atención se mantiene en 2, y la interfaz de tokens seleccionados permanece intacta; las optimizaciones del indexador nativo y block4 quedan explícitamente fuera de alcance. Así que esto es un adaptador atornillado bajo un mecanismo de selección existente, no una reimplementación de QSA —lo cual también explica por qué el autor puede afirmar de manera creíble que el contenido de la caché KV no ha cambiado.

La ficha del modelo expone claramente la intención de diseño: en lugar de seleccionar tokens individuales, QSA trabaja a nivel de microbloque para reducir la latencia en contextos largos, y esa granularidad de microbloque, junto con el estado replicado del selector que la acompaña, es precisamente lo que no se mapea limpiamente sobre un kernel genérico de atención paginada en el silicio de ninguno de los dos proveedores.

Dónde encaja esto en el despliegue del servicio de Qwen4Exp

Visto de forma aislada, un PR en borrador sobre un acelerador es una curiosidad. Visto en contraste con el resto de septiembre, es la cuarta o quinta tabla de una plataforma que se está ensamblando en público antes de que exista la familia a la que sirve:

• La arquitectura en pesos abiertos — Qwen3.8-Flash-Next, 2026-08-24, un MoE de 125B de parámetros con 6B activados, una tabla de embeddings de n-gramas de 51 mil millones de parámetros y una cabeza MTP de 4B, que incluye model_type: qwen4_exp y arquitecturas Qwen4ExpForConditionalGeneration.

• Por el lado de vLLM — #53909, el PR “qwen4 fuse op” que añade kernels de HyperConnection, QSA y PLE, sigue abierto y sin fusionar desde el 2026-08-26; #59279, que añade paralelismo de contexto de decodificación a la misma ruta de QSA, un borrador abierto el 2026-09-29; y el trabajo de PLE-offload que se integró a lo largo de septiembre.

• El lado de SGLang — #38642 para la captura de estados ocultos de DFlash, #39548 para la descarga a CPU de PLE de Qwen4-Exp en Ascend, #40235 que añade staging en el host para la tabla PLE respaldada por archivo, y ahora #41855 para la ruta de atención de Ascend.

• La línea de habilitación de NPU: sglang #37570, que añade Qwen3.8-Flash-Next a SGLang en NPU con reproducción de grafos, MTP y kernels de Triton (abierto el 2026-09-02, sigue abierto, +2.590 líneas en 20 archivos), y sgl-kernel-npu #807 para los kernels de Triton complementarios (abierto el 2026-09-17, +4.643 líneas). Ambos provienen del mismo colaborador. #41855 es la capa de atención que se encuentra dentro de ese esfuerzo de habilitación más amplio.

Dos observaciones sobre las que un lector puede actuar. En primer lugar, toda la historia de Ascend Qwen4Exp se apoya en un número muy pequeño de colaboradores: las PR de habilitación y el repositorio de kernels comparten autor, y el adaptador de atención es otro distinto. Esa concentración es una estimación razonable de lo lejos que está el servicio de Ascend Qwen4Exp de ser una ruta de producto soportada en lugar de un experimento. En segundo lugar, el cuello de botella de los kernels no es específico de un proveedor: dos problemas de SGLang reportados el 28 de agosto de 2026 documentan la decodificación de Qwen4Exp en una NVIDIA DGX Spark, donde domina el tiempo de kernel de QSA, PLE y Gated DeltaNet, y donde se midió que una caché KV NVFP4 degradaba la decodificación en aproximadamente un 29 % frente a fp8_e4m3. Las capas de atención y de embeddings de esta arquitectura son la parte difícil en todas partes.

Lo que esto no significa

No significa que Qwen 4 haya salido ni que esté cerca. La familia Qwen 4 que Alibaba nombró el 2026-09-22 —Max, Flash, Plus y un nivel de 27B— sigue siendo una hoja de ruta sin ficha de modelo, sin pesos, sin identificador de API, sin ventana de contexto, sin licencia y sin precio. Un adaptador de framework que apunta al nombre de la arquitectura interna es un paso hacia servir bien a esa familia algún día; no es un paso hacia que la familia exista.

No significa que puedas ejecutar esto hoy. El PR es un borrador con CI fallando y sin fecha de fusión. Incluso fusionado, la ruta necesita un Ascend 910C, BF16, CANN 9.0 con torch-npu 2.10, y una de cinco formas específicas de cabeza local, y es opt-in — lo que significa que un despliegue tiene que elegirlo. El autor también se negó a afirmar una validación a nivel de servidor, que es la parte que realmente te diría si se sostiene bajo batching real.

Y no significa que Qwen3.8-Flash-Next sea un producto compatible en Ascend, ni en ningún otro lugar de una compilación de motor ya publicada. Las rutas de Qwen4Exp en ambos runtimes abiertos principales son pull requests sin fusionar. No existe ninguna versión publicada de SGLang o vLLM que puedas instalar y que sirva esta arquitectura de forma nativa: la comodidad al estilo FastAPI de un endpoint alojado es algo distinto de un kernel que puedas ejecutar por tu cuenta, y la brecha entre ambos es exactamente para lo que sirven PRs como este.

Lo que realmente puedes llamar mientras esperas

Si la razón por la que te interesa Qwen4Exp es que quieres probar el comportamiento de contexto largo de la arquitectura en lugar de su funcionamiento interno del kernel, el modelo al que debes recurrir es el tier que Alibaba sirve realmente. Qwen3.8-Flash —la línea de producción construida sobre Qwen3.8-Flash-Next, con herramientas oficiales integradas y un contexto de 1.000.000 de tokens— está disponible en OrcaRouter como qwen/qwen3.8-flash: entrada de texto, imagen y vídeo, salida máxima de 131.072 tokens, 0,15 $ por millón de tokens de entrada y 0,47 $ por millón de salida, con lecturas de caché a 0,0184 $. Son precios de lista del proveedor que se trasladan con un 0 % de margen por nuestra parte, así que cualquier cambio de precio o de límite del proveedor te llega el mismo día en que se anuncia. En la ventana móvil de los últimos siete días, la tarjeta en vivo muestra una latencia p50 del primer token de 4.416 ms, unos 106 tokens de salida por segundo y una tasa de error del 2,68 % —el perfil de un tier de texto de alto volumen más que el de una vista previa de laboratorio.

Dos salvedades honestas, y son las mismas dos que traen los análisis hermanos sobre esta arquitectura. Qwen3.8-Flash-Next en sí —el checkpoint de vista previa FP8, eso que necesitarías para reproducir localmente cualquiera de estas mediciones de kernels— no está en nuestro catálogo; el nivel Flash servido es el despliegue de producción construido a partir de él, no el artefacto de vista previa en bruto. Y nada del trabajo de Ascend o DCP descrito arriba existe en nada que puedas invocar, porque ninguna de esas piezas se ha fusionado. Lo que sí te da el nivel servido es una forma barata de averiguar si tu carga de trabajo tiene la forma del problema que resuelven estos kernels: prompts largos, con mucho prefijo y de naturaleza agéntica frente a un contexto muy largo. Si es así, el rendimiento y el comportamiento de caché que observes allí son el mismo tipo de comportamiento que la pila de servicio de Qwen 4 se ajustará para proteger.

También hay un argumento de infraestructura para no esperar a una familia que no tiene fecha. Sea cual sea el nivel que acabe ganando en la línea Qwen 4, el costo de cambio es una cuestión de enrutamiento y no un proyecto de integración, y una sola API para más de 200 modelos es la forma de mantener esa opción abierta sin un segundo contrato ni un cambio de código cuando lleguen los pesos. La conmutación por error importa por la misma razón aquí de una forma concreta: si quieres desarrollar contra un nivel no probado, quieres que la solicitud recaiga en algo estable en lugar de fallar cuando el camino por el que apostaste está teniendo un mal momento.

Tres preguntas que vale la pena responder directamente

¿Significa SGLang #41855 que Qwen 4 ya salió, o que se puede previsualizar?

No, en ninguno de los dos puntos. La solicitud de extracción (pull request) se dirige a la arquitectura Qwen4Exp tal como está implementada en Qwen3.8-Flash-Next, que Alibaba lanzó el 24 de agosto de 2026. No toca los pesos de Qwen 4, y ningún nivel de Qwen 4 tiene pesos que tocar. La señal que hay que leer aquí se refiere a la capacidad de servicio para una arquitectura de vista previa, no a la disponibilidad de la familia.

Si una tarjeta de modelo dice qwen4_exp, ¿eso es Qwen 4?

No — y esta es la trampa de nomenclatura de toda la historia. qwen4_exp es el identificador interno de la arquitectura, y es lo que encontrarás en config.json para Qwen3.8-Flash-Next y su hermano FP8. «Experimental architecture» es la expresión clave: los pesos están publicados, la arquitectura es real y el modelo es una vista previa de aquello sobre lo que se espera que se construya la familia Qwen 4. Buscar el identificador y encontrar un PR de SGLang o vLLM con Qwen4Exp en el título te habla de trabajo en el motor, no de un lanzamiento.

¿Es esta una historia de Ascend contra NVIDIA?

En realidad, no. La misma ruta de atención necesitaba también un adaptador a medida en el lado de NVIDIA —paralelismo de contexto de decodificación para QSA en vLLM, y un kernel nativo de prefill disperso para Hopper—, y los problemas de DGX Spark muestran que el tiempo de kernel de QSA, PLE y Gated DeltaNet también domina la decodificación allí. El indexador de microbloques de QSA y su estado de selector replicado simplemente no son lo que asumen los kernels genéricos de atención paginada. La contribución de Ascend al patrón es la restricción más marcada: un tiler de relación de cabezas que solo acepta potencias de dos, lo que fuerza el padding que el adaptador tiene que ocultar.

Lo que hay que observar

No se trata de si esto se fusiona. El adaptador es honesto acerca de ser un adaptador, las pruebas de corrección son reproducibles sin un checkpoint, y el autor ha señalado la cuestión de la integración en lugar de fingir que está resuelta. Lo que hay que observar es qué ocurre después de que la línea de habilitación de la NPU y esta ruta de atención se combinen: si la rama integrada recibe la ejecución de extremo a extremo que ninguna de las dos ha tenido, con batching real y el modelo completo en lugar de tensores locales con forma de cabeza. La cifra de 1,713× es la que circulará, y es la que se calculó sobre una compilación distinta, sobre un checkpoint adaptado y con un indexador inerte. Un número medido sobre la pila terminada valdría considerablemente más que uno histórico.

Hasta entonces, lo honesto es aquello a lo que se ciñe el PR: la aritmética cuadra, el flag está desactivado por defecto, la CI está, y el modelo del título no existe.