Nous Research a publié Lighthouse Attention cette semaine — un mécanisme d'attention hiérarchique training-only qui pool queries, keys et values symétriquement à travers une pyramide multi-niveaux, roule la sélection top-K en dehors du kernel, et laisse FlashAttention opérer sur une petite sous-séquence dense. Speedup wall-clock pretrain rapporté : 1.40-1.69× end-to-end vs SDPA cuDNN-backed sur un decoder 530M Llama-3-style, testé à 512K context sur un seul GPU et 1M tokens à travers 32 GPUs avec context parallelism. Speedup kernel-level à 512K est plus net : 21× forward, 17.3× forward+backward. Auteurs : Peng, Ghosh, Quesnelle. arXiv 2605.06554, code à github.com/ighoshsubho/lighthouse-attention comme patch sur torchtitan plus deux nouveaux fichiers.
Le choix architectural qui sépare Lighthouse des travaux NSA et HISA précédents, c'est le pooling symétrique Q/K/V, pas juste K/V. Les méthodes d'attention selection-based antérieures laissaient les queries en pleine résolution et poolaient juste le côté K/V ; Lighthouse pool les trois dans la pyramide et roule une sélection ℓ₂-norm chunked-bitonic top-K à travers eux. Le coût bouge de O(N·S·d) à O(S²·d). La pipeline en quatre étapes — average-pool en L niveaux, score et top-K, gather des entrées sélectionnées, roule FlashAttention stock sur le gather, scatter les outputs en retour via un kernel déterministe — garde le kernel d'attention interne exactement comme il est sur des séquences denses. C'est la raison pratique pour laquelle le speedup de FlashAttention se compose avec la sélection de Lighthouse au lieu de se battre avec.
Le positionnement training-only compte. Lighthouse est enlevée à l'inférence : une recette training en deux stages — stage 1 train avec sélection activée, stage 2 resume sous SDPA dense. Loss final de training 0.6980-0.7102 vs baseline dense-from-scratch 0.7237 — marginalement meilleur — à 22.5-27.0 heures wall-clock vs 37.9 heures pour la baseline dense sur le même modèle et budget de tokens (~50.3B tokens, 16 000 steps). Donc le win est sur l'axe training-compute, pas inference-compute : un modèle entraîné avec Lighthouse se comporte comme un modèle dense normal au déploiement. C'est un problem statement différent du travail sur sparse-attention-at-inference (StreamingLLM, compression de KV cache) et de l'attention sparse architecture-level shippée en prod. Lighthouse est le point « pretrain cheaper, deploy dense » dans le design space.
Lundi matin : si tu pretrains un modèle à long context sur de l'infra training commodity, Lighthouse est à un patch torchtitan et deux fichiers de se retrouver sur ton training run pour ablation. Le résultat à 530M est suggestif, pas load-bearing — si le 1.4-1.7× tient à 7B, 70B, ou 405B reste la question ouverte. L'overhead de sélection (gather/scatter, top-K) scale pas linéairement avec la taille de modèle, donc le speedup pourrait compresser ou s'expandre. Watch pour Nous elle-même qui réplique à scale, watch pour si les prochains pretrains de Llama, Qwen, ou DeepSeek adoptent le trick de pooling pyramide symétrique, et watch le repo GitHub pour un kernel fused grade-cuDNN qui a pas été publié encore — c'est là que l'adoption grade-production se gate.