L'équipe Qwen a sorti FlashQLA mardi sous MIT, une bibliothèque de kernels haute performance qui cible le mécanisme d'attention linéaire Gated Delta Network (GDN) qui alimente les familles de modèles Qwen3.5 pis Qwen3.6. Le benchmark principal : 2-3x de speedup forward pass pis 2x backward pass contre l'implémentation Triton établie de Flash Linear Attention (FLA), mesuré sur Nvidia H200 à travers des dimensions de tête correspondant aux configurations tensor-parallel de Qwen (TP1 à TP8, hv de 64 jusqu'à 8). Repo à github.com/QwenLM/FlashQLA. La substance, c'est dans le choix de ce sur quoi FlashQLA a été bâti : pas Triton, mais TileLang — un framework compilateur relativement nouveau qui expose des primitives de scheduling spécifiques à Hopper que Triton peut pas pleinement exprimer.
Le contexte architectural compte. L'attention linéaire remplace la complexité O(n²) de l'attention softmax standard par O(n), ce qui devient porteur quand les longueurs de séquence dépassent 100k tokens. GDN, c'est une variante « gated » qui applique une porte décroissante exponentiellement sur le contexte passé — une formulation qui admet une implémentation efficace au niveau kernel mais qui demande un scheduling soigné du mouvement mémoire, des opérations Tensor Core pis du compute CUDA Core pour vraiment livrer l'efficacité théorique. Qwen3.5/3.6 utilisent un design hybride : les couches GDN alternent avec de l'attention pleine standard, en obtenant l'expressivité de l'attention pleine où c'est nécessaire pis l'efficacité de l'attention linéaire ailleurs. FlashQLA optimise spécifiquement la moitié attention-linéaire de cette stack — ce qui veut dire que le gain compose avec les architectures hybrides, pas juste les modèles attention linéaire pure.
La dimension Triton-vs-TileLang, c'est le signal plus large. Triton (le langage de programmation GPU basé Python d'OpenAI) a démocratisé l'écriture de kernels — la plupart des kernels ML en production, incluant l'implémentation de référence de FlashAttention, dépendent de Triton. Mais l'abstraction de Triton vise un modèle de programmation CUDA générique, qui expose pas pleinement les fonctionnalités spécifiques à Hopper : opérations Tensor Core au niveau warpgroup, pipelines de données asynchrones, pis spécialisation de warp qui te permet de diviser un kernel à travers des warpgroups de 128 threads assignés à des rôles spécialisés (un déplace les données, un fait rouler les Tensor Cores, un fait rouler les CUDA cores, tous en chevauchement). FlashQLA utilise les primitives de kernels warp-spécialisés de TileLang pour orchestrer manuellement ce chevauchement. Le résultat, c'est un kernel qui est plus fragile (spécifique Hopper, demande SM90+ avec CUDA 12.8+ pis PyTorch 2.8+) mais matériellement plus rapide que ce que Triton peut produire. On retourne à un régime où la performance kernel sérieuse demande des implémentations hand-tunées spécifiques au matériel — Triton était une belle abstraction mais ça coûtait du débit sur le silicium le plus récent.
Pour les builders, trois takeaways. Premièrement, si tu roules de l'inférence Qwen3.5/3.6 à l'échelle sur H100/H200, échanger FLA pour FlashQLA est potentiellement 2x de débit decode gratuit — mais vérifie sur ton déploiement spécifique parce que les benchmarks étaient en latence single-kernel, pas en serving end-to-end. Deuxièmement, le split Triton-vs-TileLang signale une taxe de portabilité qui va continuer à s'élargir : les kernels portables roulent partout mais plus lentement, les kernels spécifiques au matériel demandent de maintenir des chemins de code séparés par génération (SM89 Ada, SM90 Hopper, SM100 Blackwell). Des frameworks comme TileLang pis CUTLASS vont de plus en plus posséder le plafond haute-performance pendant que Triton garde le plancher friendly-pour-développeurs. Troisièmement, c'est un signal sur l'équipe infra de Qwen — livrer une bibliothèque de kernels hand-tunée à côté des poids du modèle, c'est le genre d'optimisation verticalement intégrée que les équipes open-source occidentales ont été plus lentes à faire. DeepSeek-V3 est venu avec des implémentations CUDA custom ; Qwen3.x vient maintenant avec une bibliothèque de kernels custom. La barre pour les « poids ouverts » devient tranquillement « poids ouverts plus les kernels dont t'as besoin pour vraiment les servir efficacement ». C'est un upgrade significatif à quoi ressemble la livraison d'IA open-source.