Nous Research publicó Lighthouse Attention esta semana — un mecanismo de atención jerárquica training-only que poolea queries, keys y values simétricamente a través de una pirámide multi-nivel, corre selección top-K fuera del kernel, y deja a FlashAttention operar sobre una pequeña sub-secuencia densa. Speedup wall-clock pretrain reportado: 1.40-1.69× end-to-end vs SDPA cuDNN-backed sobre un decoder 530M Llama-3-style, probado a 512K contexto en un solo GPU y 1M tokens a través de 32 GPUs con context parallelism. Speedup kernel-level a 512K es más nítido: 21× forward, 17.3× forward+backward. Autores: Peng, Ghosh, Quesnelle. arXiv 2605.06554, código en github.com/ighoshsubho/lighthouse-attention como patch sobre torchtitan más dos archivos nuevos.
La elección arquitectónica que separa a Lighthouse de los trabajos NSA y HISA previos es el pooling simétrico Q/K/V, no solo K/V. Los métodos de atención selection-based anteriores dejaban las queries en resolución completa y pooleaban solo el lado K/V; Lighthouse poolea las tres en la pirámide y corre una selección ℓ₂-norm chunked-bitonic top-K a través de ellas. El costo se mueve de O(N·S·d) a O(S²·d). El pipeline de cuatro etapas — average-pool en L niveles, score y top-K, gather de entradas seleccionadas, corre FlashAttention stock sobre el gather, scatter de outputs de vuelta vía un kernel determinístico — mantiene el kernel de atención interno exactamente como está sobre secuencias densas. Esa es la razón práctica por la que el speedup de FlashAttention se compone con la selección de Lighthouse en vez de pelearse con ella.
El posicionamiento training-only importa. Lighthouse se remueve en inferencia: una receta de training de dos stages — stage 1 entrena con selección habilitada, stage 2 resume bajo SDPA densa. Loss final de training 0.6980-0.7102 vs baseline densa-desde-cero 0.7237 — marginalmente mejor — a 22.5-27.0 horas wall-clock vs 37.9 horas para la baseline densa en el mismo modelo y presupuesto de tokens (~50.3B tokens, 16,000 steps). Así que el win es en el eje training-compute, no inference-compute: un modelo entrenado con Lighthouse se comporta como un modelo denso normal en despliegue. Esto es un problem statement diferente del trabajo de sparse-attention-at-inference (StreamingLLM, compresión de KV cache) y de atención sparse architecture-level enviada a producción. Lighthouse es el punto "pretrain más barato, despliega denso" en el espacio de diseño.
Lunes: si pretrains un modelo a long context sobre infraestructura training commodity, Lighthouse está a un patch torchtitan y dos archivos de estar en tu corrida de training para ablación. El resultado a 530M es sugestivo, no load-bearing — si el 1.4-1.7× se sostiene a 7B, 70B, o 405B es la pregunta abierta. El overhead de selección (gather/scatter, top-K) no escala linealmente con tamaño de modelo, así que el speedup podría comprimirse o expandirse. Vigila a Nous misma replicando a escala, vigila si los próximos pretrains de Llama, Qwen, o DeepSeek adoptan el truco de pooling pirámide simétrico, y vigila el repo de GitHub para un kernel fused grado-cuDNN que aún no se ha publicado — ahí es donde la adopción grado-producción se compuerta.