Hvis man har siddet en tirsdag nat og set GPU‑udnyttelsen danse op og ned, ved man det i kroppen: long‑context pretraining er tungt. Nous Research melder, at deres nye Lighthouse Attention giver 1,40–1,69× end‑to‑end speedup på træning af lange sekvenser mod en cuDNN‑backet SDPA‑baseline, uden at det endelige træningstab bliver værre. Ikke magi. Men potentielt praktisk.
Kernen er en trænings‑kun, selektionsbaseret hierarkisk attention, der udvælger et tæt deludsnit af tokens og derefter kører standard FlashAttention på det. Inference‑backbonen forbliver tæt. Altså hurtigere træning uden at ændre den tætte attention, I bruger i produktion.
Hvorfor attention er dyrt
Transformerens scaled dot‑product attention skalerer kvadratisk i både compute og hukommelse med sekvenslængde N. Θ(N²) er ikke bare notation, det er budget. FlashAttention hjælper ved at være IO‑bevidst og undgå at materialisere hele N×N‑matricen i HBM, så hukommelsesfodaftrykket falder, men den ændrer ikke den underliggende Θ(N²) compute‑skalering.
Ved 64k, 128k eller længere sekvenser bliver kvadratikken dominerende for både wall‑clock og pris per eksperiment. Vi har set det på H100‑klynger: alt så rigtigt ud på papiret, men dataloading og memory‑tryk tvang os ned i batch‑størrelser, der gjorde iterationshastigheden lav. Jeg kan stadig høre blæserne fra et rack i Ballerup. Og den ene CSV‑parser, der væltede timingen midt om natten.
Hvad Lighthouse gør anderledes
Lighthouse pakker sig uden om SDPA i fire trin. Først bygges en L‑niveau pyramide med gennemsnits‑pooling på både Q, K og V — symmetrisk — så man får koherente tripler på hvert niveau. Pyramiden koster Θ(N) i tid og hukommelse ifølge beskrivelsen.
Andet trin scorer hvert element parameterfrit med per‑head ℓ₂‑normer, både som query‑ og key‑score. Coarse niveauer arver maks‑score fra finere niveauer, så stærke tokens bobler op. Et chunked‑bitonic top‑K‑valg udpeger derefter de k mest lovende elementer på tværs af niveauer. Den groveste niveau beholdes altid helt for at sikre dækning. Tredje trin samler de valgte indgange til en tæt delsekvens i hukommelsen. Fjerde trin: kør stock FlashAttention på den tætte delsekvens.
Fra udvælgelse til standard kerner
Det, der skiller Lighthouse fra tidligere sparsity‑metoder som NSA, HISA, DSA og MoBA, er to valg: 1) symmetrisk pooling af Q, K, V i stedet for kun K og V, 2) udvælgelsen ligger uden for attention‑kernen. Resultatet er, at man kan genbruge eksisterede, gennemtestede FlashAttention‑kerner efter selection. For teams, der har kæmpet med custom CUDA‑kerner, er det en lettelse.
En praktisk detalje: top‑K‑steppet er diskret og bærer ingen gradient. Gradienten går gennem de samlede Q, K, V ind i projektionerne. Det tvinger projektionerne til at lære nyttige repræsentationer, ikke blot gode scorere.
Performanceclaim og klare forbehold
Nous rapporterer 1,40–1,69× end‑to‑end pretraining‑speedup mod en cuDNN‑backet SDPA‑baseline, og at sluttræningstabet matcher eller er lavere. Vigtigt: baseline er cuDNN SDPA, ikke FlashAttention. Derfor bør en POC altid måle mod begge baselines.
Der mangler centrale eksperimentdetaljer i offentlig rapportering: GPU‑model, sekvenslængder, batch‑størrelser, optimizer‑valg og mixed‑precision‑indstillinger, antal steps, seeds. Indtil uafhængige målinger foreligger, er overførbarheden uklar. Preprint: arXiv:2605.06554.
Hvorfor trænings‑only er vigtigt
Trænings‑only kan lyde begrænsende. I praksis er det ofte en fordel. Kravet er, at vægtene efter træning giver en kompetent tæt‑attention model ved inference — og det løfter Nous som korrekthedskriterium. Man kan træne hurtigere uden at ændre produktionsstakken eller rulle ny ops til sparsity‑inference.
En stor del af omkostningen ligger i pretraining og store finetunes. Hvis man sparer 40–70 procent wall‑clock i lange sekvensfaser uden at røre inference‑delen, rykker det budgetter og iterationstempo. Forudsat at gevinsten holder i jeres workload.
Hvad betyder 1.4–1.7× i drift
Et menneskeligt regnestykke: Sig I kører long‑context pretraining på H100 med 128k tokens, batch 8. I dag tager et træningsvindue 10 dage á 512 H100‑timer per dag. Med 1,5× speedup kan samme målsætning lande på cirka 6,7 dage, alt andet lige. Det frigiver GPU‑timer, forkorter ablations og sænker energi‑ og lejeudgift.
Kontraeksempel: Samme setup, men input‑pipen hænger på CPU‑tokenisering og storage‑IO med små filer; GPU‑utilization dykker til 40 procent. Så forsvinder gevinsten i memcpy‑thrash og ujævne batches. Mål altid end‑to‑end før I jubler over en kernel‑speedup.
Hvornår gevinsten er realistisk
Lighthouse giver mest mening ved meget lange sekvenser og hvor baseline ikke allerede er tunet til kanten. H100 profiterer ofte af IO‑effektive mønstre, men forskellen kan være lille, hvis FlashAttention kører tæt på peak og batchen i forvejen er lille. Ved finetuning af 7B‑modeller med 4k–8k tokens ses sjældent store gevinster — overhead fra top‑K og gather kan dominere.
Omvendt: ved 64k–128k tokens, moderate til store batches og eksisterende FlashAttention er udsigten god. Symmetrisk pooling af Q, K, V giver en udvælgelse, der matcher den efterfølgende tætte beregning bedre end asymmetrisk komprimering.
Begrænsninger og risici
Tre steder kan det gå galt: 1) Korte sekvenser og små modeller, hvor gevinsten forsvinder i overhead. 2) Implementeringen — selection‑kernel, chunking og gather skal undgå uheldige memcpy‑mønstre. 3) Workloads, hvor ℓ₂‑norm‑scoring misser de rigtige signaler ved jævn vigtighed. Der er ikke rapporteret ablations på sådanne corner cases i den offentlige opsummering.
Reproducerbarhed er nødden: Vi vil gerne se memory‑profiler fra træning, især peak‑footprint, og skaleringsanalyse over hoveder, lag og modelstørrelse, før man ruller bredt ud.
Sammenligning med andre tilgange
NSA, HISA, DSA og MoBA vælger typisk asymmetrisk: de puljer K og V og lader Q være tæt, og de lægger udvælgelsen ind i en specialiseret attention‑kernel. Det kan give flotte microbenchmarks, men koster vedligehold. Lighthouse gør det modsat: udvælg udenfor, hold Q, K, V i symmetri, og kør derefter standard FlashAttention. Tradeoff’et er mere forudsigelig integration og genbrug af gennemtestede kerner, mod en selection‑ og gather‑pipeline, der skal tunes grundigt.
FlashAttention er ikke en konkurrent her, men en byggesten. Lighthouse bruger FlashAttention efter udvælgelsen, hvilket mindsker risikoen for at brække noget, der allerede er optimeret tæt på hardwaregrænserne.
Implementering i praksis
Sådan ville vi evaluere Lighthouse hos jer: start småt. Ét lag ad gangen, én sekvenslængde ad gangen. Mål mod to kendte baselines: cuDNN SDPA og FlashAttention. Log wall‑clock per 1k tokens, GPU‑utilization, SM‑occupancy, HBM‑båndbredde og peak‑memory. Følg loss‑kurver tæt. En ren 1,5× på kronometeret er god, men hvis træningsdynamikken skrider, kommer regningen senere.
Stram også checkpoint‑strategien. Fordi metoden er trænings‑only, bør hvert større milestone‑checkpoint verificeres i tæt‑inference med standardkerner, før I går videre. Billig forsikring.
Tre‑trins POC, klar til at køre
- Trin 1 — Baseline og vindue: Kør 1.000–2.000 steps på jeres long‑context workload med cuDNN SDPA og med FlashAttention. Gem nsys‑traces. Notér GPU‑type, sekvenslængder og batch‑størrelser.
- Trin 2 — Indsæt Lighthouse ét lag: Implementér pyramide, scorer, top‑K og gather i et enkelt lag. Kør samme vindue. Log dram_read/write, memcpy‑bytes, SM‑stall‑årsager og peak‑memory.
- Trin 3 — Verificér og afgør: Tæt‑inference på milepæls‑checkpoints. Pass/fail: ≥1,3× wall‑clock speedup over 1k–2k steps, ingen eval‑regression og stabil loss‑trajectory.
Artefakter at kræve for reproducibilitet
- Træningsscripts og præcis kommandolinje for alle runs
- Profilertraces (nsys) pr. 500 steps, inkl. SM‑occupancy, dram_read/write, memcpy‑tællere
- Peak‑memory‑rapporter og memory‑profilgrafer
- Seeds, data‑shard‑log og dataset‑version
- Rå timing‑CSV’er med wall‑clock per step og per 1k tokens
Lille rapportskabelon vi bruger: Setup (GPU, batch, seqlen, precision), Kernels (SDPA/FlashAttn/Lighthouse‑lag), Metrikker (wall‑clock, HBM‑util, SM‑stall), Kvalitet (loss‑trajectory, eval), Beslutning (go/no‑go, næste iteration).
Kilder og validering
De centrale tekniske påstande om Θ(N²)‑skalering for SDPA og FlashAttentions IO‑tilgang er bredt anerkendte og gengives i vores primære kilde. Oplysningerne om Lighthouse’ designvalg og speedup‑intervaller stammer fra rapporteringen, herunder at sluttræningstab matcher eller er lavere. Der er endnu ikke offentlig uafhængig reproduktion eller fuld kodeudgivelse — vi opdaterer, når sådanne resultater foreligger. Preprint: arXiv:2605.06554.
Hvad vi synes det betyder nu
Hvis I kæmper med lange kontekster i træning, er Lighthouse værd at teste. Gevinsten bliver størst, hvor attention‑arbejdet dominerer, og hvor selection‑ og gather‑overheads holdes nede. Den praktiske forskel til mange sparsity‑forsøg er, at I bliver i den kendte FlashAttention‑verden efter udvælgelsen — det sænker den tekniske risiko.
Vores anbefaling er jordnær: kør en smal POC i tre trin — lagtest, end‑to‑end profilering, tæt checkpoint‑verifikation. Og først derefter rul bredere. Man opdager først forskellen, når man sidder med det i hænderne.
FlashAttention kort fortalt
FlashAttention reducerer memory‑fodaftrykket ved at tilte og streame beregningen, så man ikke materialiserer hele N×N‑attentionmatricen i HBM. Det sænker IO‑omkostninger og forbedrer throughput, men den teoretiske beregning forbliver kvadratisk i N.
Hvad Snilld kan hjælpe med
Vi har implementeret FlashAttention‑optimeringer på H100‑klynger og set, hvordan teoretiske speedups kan forsvinde, hvis batching og data‑pipeline ikke er tunet. Vi tilbyder en POC‑pakke: baseline‑måling, Lighthouse i ét lag, end‑to‑end profilering og tæt‑inference‑verifikation. Lige til at sætte i gang – uden at rive jeres produktionsstack fra hinanden.
