El equipo Qwen liberó FlashQLA el martes bajo MIT, una biblioteca de kernels de alto rendimiento que apunta al mecanismo de atención lineal Gated Delta Network (GDN) que alimenta las familias de modelos Qwen3.5 y Qwen3.6. El benchmark principal: speedup de 2-3x en forward pass y 2x en backward pass contra la implementación Triton establecida de Flash Linear Attention (FLA), medido en Nvidia H200 a través de dimensiones de cabeza correspondientes a las configuraciones tensor-parallel de Qwen (TP1 a TP8, hv de 64 hasta 8). Repositorio en github.com/QwenLM/FlashQLA. La sustancia está en sobre qué eligió construirse FlashQLA: no Triton, sino TileLang —un framework compilador relativamente nuevo que expone primitivas de scheduling específicas de Hopper que Triton no puede expresar plenamente.
El contexto arquitectónico importa. La atención lineal reemplaza la complejidad O(n²) de la atención softmax estándar con O(n), lo que se vuelve estructural cuando las longitudes de secuencia cruzan los 100k tokens. GDN es una variante "gated" que aplica una compuerta exponencialmente decreciente sobre el contexto pasado —una formulación que admite implementación eficiente a nivel kernel pero que requiere scheduling cuidadoso de movimiento de memoria, operaciones Tensor Core y compute CUDA Core para realmente entregar la eficiencia teórica. Qwen3.5/3.6 usan un diseño híbrido: capas GDN alternan con atención completa estándar, obteniendo la expresividad de atención completa donde se necesita y la eficiencia de atención lineal en todo lo demás. FlashQLA optimiza específicamente la mitad de atención lineal de ese stack —lo que significa que la ganancia compone con arquitecturas híbridas, no solo modelos de atención lineal pura.
La dimensión Triton-vs-TileLang es la señal más amplia. Triton (el lenguaje de programación GPU basado en Python de OpenAI) democratizó la escritura de kernels —la mayoría de los kernels ML de producción incluyendo la implementación de referencia de FlashAttention dependen de él. Pero la abstracción de Triton apunta a un modelo de programación CUDA genérico, que no expone plenamente las características específicas de Hopper: operaciones Tensor Core a nivel warpgroup, pipelines de datos asíncronos, y especialización de warp que te permite dividir un kernel a través de warpgroups de 128 threads asignados a roles especializados (uno mueve datos, uno corre Tensor Cores, uno corre CUDA cores, todos solapándose). FlashQLA usa primitivas de kernels warp-especializados de TileLang para orquestar manualmente ese solapamiento. El resultado es un kernel que es más frágil (específico de Hopper, requiere SM90+ con CUDA 12.8+ y PyTorch 2.8+) pero materialmente más rápido que lo que Triton puede producir. Volvemos a un régimen donde el rendimiento kernel serio demanda implementaciones hand-tuned específicas de hardware —Triton fue una abstracción hermosa pero costó throughput en el silicio más reciente.
Para constructores, tres lecturas. Primero, si corres inferencia Qwen3.5/3.6 a escala en H100/H200, cambiar FLA por FlashQLA es potencialmente 2x de throughput de decode gratis —pero verifica en tu despliegue específico porque los benchmarks fueron de latencia single-kernel, no de serving end-to-end. Segundo, la división Triton-vs-TileLang señala un impuesto de portabilidad que seguirá ensanchándose: kernels portables corren en todo lugar pero más lento, kernels específicos de hardware requieren mantener caminos de código separados por generación (SM89 Ada, SM90 Hopper, SM100 Blackwell). Frameworks como TileLang y CUTLASS poseerán cada vez más el techo de alto rendimiento mientras Triton mantiene el piso amigable para desarrolladores. Tercero, esto es una señal sobre el equipo de infra de Qwen —enviar una biblioteca de kernels hand-tuned junto con los pesos del modelo es el tipo de optimización verticalmente integrada que los equipos open-source occidentales han sido más lentos en hacer. DeepSeek-V3 vino con implementaciones CUDA custom; Qwen3.x ahora viene con biblioteca de kernels custom. La vara para "pesos abiertos" se está volviendo silenciosamente "pesos abiertos más los kernels que necesitas para realmente servirlos eficientemente". Esa es una mejora significativa de lo que se ve la entrega de IA open-source.