A Nous Research publicou a Lighthouse Attention esta semana — um mecanismo de atenção hierárquica training-only que pooleia queries, keys e values simetricamente através de uma pirâmide multi-nível, roda seleção top-K fora do kernel, e deixa FlashAttention operar sobre uma pequena subsequência densa. Speedup wall-clock pretrain reportado: 1.40-1.69× end-to-end vs SDPA cuDNN-backed sobre um decoder 530M Llama-3-style, testado a 512K contexto em uma única GPU e 1M tokens em 32 GPUs com context parallelism. Speedup kernel-level a 512K é mais nítido: 21× forward, 17.3× forward+backward. Autores: Peng, Ghosh, Quesnelle. arXiv 2605.06554, código em github.com/ighoshsubho/lighthouse-attention como patch sobre torchtitan mais dois arquivos novos.
A escolha arquitetural que separa Lighthouse dos trabalhos anteriores NSA e HISA é o pooling simétrico Q/K/V, não só K/V. Métodos de atenção selection-based anteriores deixavam as queries em resolução completa e pooleavam só o lado K/V; Lighthouse pooleia as três na pirâmide e roda uma seleção ℓ₂-norm chunked-bitonic top-K através delas. O custo se move de O(N·S·d) para O(S²·d). O pipeline de quatro etapas — average-pool em L níveis, score e top-K, gather de entradas selecionadas, roda FlashAttention stock sobre o gather, scatter de outputs de volta via um kernel determinístico — mantém o kernel de atenção interno exatamente como está sobre sequências densas. Essa é a razão prática pela qual o speedup do FlashAttention se compõe com a seleção do Lighthouse em vez de brigar com ela.
O posicionamento training-only importa. Lighthouse é removida na inferência: uma receita de training de dois stages — stage 1 treina com seleção habilitada, stage 2 retoma sob SDPA densa. Loss final de training 0.6980-0.7102 vs baseline densa-do-zero 0.7237 — marginalmente melhor — a 22.5-27.0 horas wall-clock vs 37.9 horas para a baseline densa no mesmo modelo e orçamento de tokens (~50.3B tokens, 16.000 steps). Então o win é no eixo training-compute, não inference-compute: um modelo treinado com Lighthouse se comporta como um modelo denso normal no desplegamento. Isto é um problem statement diferente do trabalho de sparse-attention-at-inference (StreamingLLM, compressão de KV cache) e de atenção esparsa architecture-level enviada para produção. Lighthouse é o ponto "pretrain mais barato, desplega denso" no espaço de design.
Segunda-feira: se você pretrains um modelo em long context sobre infra training commodity, Lighthouse está a um patch torchtitan e dois arquivos de estar no seu training run para ablação. O resultado a 530M é sugestivo, não load-bearing — se o 1.4-1.7× se sustenta a 7B, 70B, ou 405B é a pergunta em aberto. O overhead de seleção (gather/scatter, top-K) não escala linearmente com tamanho do modelo, então o speedup pode comprimir ou expandir. Fique de olho na Nous mesma replicando em escala, fique de olho em se os próximos pretrains de Llama, Qwen, ou DeepSeek adotam o truque de pooling pirâmide simétrico, e fique de olho no repo do GitHub para um kernel fused grau-cuDNN que ainda não foi publicado — é aí que a adoção grau-produção se gate.