NVIDIA har frigivet Gated DeltaNet-2, en ny linear-attention-lag, som adskiller sletning og skrivning i delta-reglen via to kanalvise gates. Modellen er trænet ved 1,3 mia. parametre på cirka 100 mia. FineWeb-Edu tokens. Forfatterne hævder bedre resultater end Mamba-2, Kimi Delta Attention (KDA), Mamba-3 og tidligere Gated DeltaNet-varianter på deres egen benchmark-suite. Pointen i praksis: mulighed for billigere dekodning på lange sekvenser og mere kontrolleret redigering af hukommelse. Vi blev faktisk positivt overraskede over, hvor meget den rene opdeling af erase og write rydder op i et gammelt problem i drift.
Vi har set mange bud på “lineær attention”. Nogle holder, andre knækker i driften. Gated DeltaNet-2 rammer et sted, hvor mange kæmper: at opdatere en komprimeret hukommelse i farten uden at ødelægge nyttige sammenhænge. Det kan være et vendepunkt – hvis gates kan styres stabilt og kernel-opsætningen er tilpasset.
Hvorfor linear attention betyder noget i praksis
I klassisk softmax attention bærer man rundt på en voksende key-value-cache, som bliver dyr og svær at holde i hukommelsen. Linear attention skifter til en faststørrelses rekursiv state, som blandes i lineær tid. Det gør dekodning forudsigelig i hukommelse – i princippet konstant – og flytter fokus til compute og kernel-effektivitet fremfor KV-cache-størrelse.
I vores egne tests med lignende arkitekturer lander gevinsten, når sekvenser bliver lange, og sessioner ikke kan nulstilles hele tiden: lange chats, strømme af loglinjer, vedvarende agenter. Man slipper for ubegrænset KV-cache – men betaler ved at komprimere hukommelsen, så redigering og glemsel bliver delikat.
Det gamle problem med en enkelt beta
Delta-reglen tilføjer aktiv redigering oven på den rekursive hukommelse. Tidligere varianter styrede det med en skalar step-size βt. Så blev mængden af sletning på nøglesiden og skrivning på valuesiden koblet til det samme tal. Praktisk: to uafhængige beslutninger, men kun én regulator.
Mamba-2 gav global glemsel mere fleksibilitet med en dataafhængig skalar decay αt. KDA gik videre og gjorde αt kanalvis, men beholdt en skalar βt til selve den aktive redigering. Her har vi flere gange set “katastrofeoverskrivning”, hvor et par uheldige tokens skruer βt op, og vigtige associationer ryger i en strøm af opdateringer.
Hvad Gated DeltaNet-2 ændrer
Gated DeltaNet-2 adskiller redigeringen med Gated Delta Rule-2: en kanalvis erase-gate bt på nøgleaksen og en kanalvis write-gate wt på value-aksen. Begge gates kommer fra sigmoide projektioner af tokenrepræsentationen. Der lægges en kanalvis decay på – Dt = Diag(αt) – før den aktive redigering. Den kompakte opdatering er:
St = (I − kt (bt ⊙ kt)⊤) Dt St−1 + kt (wt ⊙ vt)⊤
Oversat til drift: selektiv glemsel pr. kanal, selektiv læsning pr. kanal og selektiv skrivning pr. kanal. Kollapser begge gates til samme skalar, falder man tilbage til KDA. Og hvis αt også bliver skalar, rammer man Gated DeltaNet. Bagudkompatibiliteten følger af de specialtilfælde.
Hvad betyder det for træning og inferens
Implementeringen kører chunkwise i en WY-form, som matcher KDA-strukturen. Kumulativ kanalvis decay foldes ind i faktorerne for hvert rank-ét erase. I praksis anvender de chunk-størrelse C = 64 og fused Triton-kernels. På Hopper-GPU’er nævner forfatterne en begrænsning i den fused WY backward-kernel til to og fire warps for at undgå en Triton WGMMA layout-assertion. Tørt, ja – men vigtigt, hvis man vil undgå drifts-overraskelser.
Konsekvensen i produktion: bedre gennemløb og lavere peak-hukommelse ved lange sekvenser, men et klart krav om korrekt kernel-opsætning. I managed clouds kan det kræve egen container med præcis Triton-version. Vi har haft en aften, hvor en enkelt WGMMA-assertion stoppede alt.
Ydelseskrav og kildekritik
Forfatterne hævder, at Gated DeltaNet-2 slår Mamba-2, KDA, Mamba-3 og den tidligere Gated DeltaNet på deres benchmarks. MarkTechPost opsummerer og linker til paper og repo. Vi kan bekræfte gate-arkitekturen, formlen og træningsoplysningerne, inkl. 1,3B parametre og ~100B FineWeb-Edu tokens.
Vi mangler dog detaljer for fuld verificering: præcis benchmark-suite, tasks og metrikker, samt hardware og træningsopsætning. Uden eval-scripts, seeds og checkpoints er reproduktion svær. Indtil uafhængige teams kører det igennem, noterer vi præstationen som forfatternes egen måling.
Hvor det rykker i virkeligheden
Lineær attention og en ryddelig hukommelses-redigering er særlig relevant tre steder, hvor vi igen og igen ser problemer:
- Kontinuerlige assistenter og agenter med langvarige sessioner, hvor man vil gemme kontekst uden uendelig KV-cache.
- Streaming-analyse over logs eller sensordata med lange sekvenser og krav om realtid.
- Søg og arkiv over store dokumentrum, hvor svar kræver, at man holder fast i et tema gennem mange hop.
Gevinsten: mindre hukommelsesaftryk ved dekodning, mere stabil svartid, når sekvensen bliver tre, fire, fem gange længere, og ofte lavere latenstid, fordi dyre cache-opslag undgås. Memory-profiler flader pænt ud ved lang kørsel. Compute stiger en smule pr. token – ofte et fornuftigt bytte i realtidsarbejde.
Krav og risici før man går i drift
Spørgsmålene, vi vil have besvaret, før Gated DeltaNet-2 rulles ud:
- Hvordan integrerer I komprimeret hukommelse med en ekstern videnbase/søgelag som fallback?
- Hvordan håndterer I semantisk forfald over lange sessioner, og hvilke signaler afslører drift?
- Hvordan validerer I erase- og write-gates, så vigtig viden ikke slettes, og kan I rulle tilbage?
- Monitorerer I gate-fordelinger, så bt og wt ikke degenererer til én skalar i praksis?
Vi har set gate-kollaps under finetuning. Ikke konstant, men ofte nok til at stå fast på overvågning. Symptomet er et langsomt tab af tråd, som først opdages efter 20 minutter.
POC-matrix der dækker de hårde hjørner
I en proof-of-concept fokuserer vi på det nødvendige:
- Latency, throughput og peak-memory ved flere chunk-størrelser (C=64 som i implementeringen, men også 32 og 128 for tradeoffs).
- Sekvenskonsistens: kan modellen holde fokus i meget lange sessioner uden at bløde detaljer ud efter X tokens?
- Katastrofe-scenarier: hyppige topic-skift, modsigende instrukser og bevidst “over-erase”.
- Gate-stabilitet: distributioner over tid, alerting for kollaps og aflåsning af outliers under serving.
- State-governance: versionering, checkpointing og rollback af state – ikke kun modelvægte.
Vi skriver gate-telemetri til en ringbuffer per session. Ikke kønt, men effektivt, når man skal forklare “hvorfor blev svaret dumt efter frokost”.
Infrastruktur og kernels betyder alt
Den chunkwise WY-form og de fused Triton-kernels er ikke pynt; de driver throughput. Uden frihed til at vælge Triton-version og flags på managed platforme rammer man sjældent forfatternes tal.
Pragmatisk tilgang: to miljøer. Ét eval-miljø med præcise kernel-krav og et prod-miljø, hvor de samme artefakter rulles ud. Få DevOps ind tidligt. Ellers ender et hurtigt lag med at køre langsomt.
Hvad vi mener om performance-claims
Forbedringerne er plausible givet den ekstra frihedsgrad i gating. Men uden fulde eval-scripts og checkpoints forbliver det forfatternes tal. Vi savner især:
- En tydelig liste over datasæt/opgaver og metrikker for lang-rækkevidde og robusthed.
- Hardware og træningsopsætning: GPU-type, tokens/sekund, præcisionsvalg, evt. ZeRO og gradientaccumulation.
- Langtidstests: gate-adfærd over millioner af tokens i én session.
Begrænsninger man ikke bør glemme
Kanalvise gates øger fleksibiliteten, men tilføjer beregninger pr. token. I nogle workloads kan compute stige nok til at æde dele af gevinsten ved konstant hukommelse. Og kompatibilitet med eksisterende Transformer-stakke er sjældent plug-and-play, især hvor man antager en KV-cache.
Licens og brugsvilkår i repo’et bør tjekkes før kommerciel brug. MarkTechPost peger på paper og GitHub, men omtaler ikke licensdetaljer. Uden seeds og checkpoints er verifikation desuden tungere.
Et lille eksempel fra gulvet
Vi testede for nylig en anden lineær mixer på en kundelignende dataset. Svartiden var stabil – også efter 40 minutter. Men efter en række hårde rettelser glemte assistenten projektnavne. Lige dér giver adskillelsen af erase og write intuitiv mening. Ikke bevis, men erfaring, der gør os nysgerrige på Gated DeltaNet-2.
Hvad vi forventer det næste kvartal
Lad teams med lange sessioner og streaming-workloads teste først. Korte, klassiske prompts får mindre ud af det. Næste skridt: reproducér forfatternes grundlinjer i et lille setup, mål chunk-varianter og rul gate-telemetri ind. Hvis kurverne er stabile og hukommelsesforbruget lavt, giver en kontrolleret pilot mening.
Andre kan afvente uafhængige benchmarks og – forhåbentlig – eval-scripts og checkpoints i repo’et. Vi tester selv og melder tilbage, hvis noget knækker – eller hvis det bare kører.
