Latent Sparse Attention: un indice gerarchico per contesti lunghi

Durante il lavoro, un coding agent accumula codice, risultati dei tool e tracce dei tentativi precedenti. Un assistente di ricerca deve collegare informazioni distribuite in centinaia di documenti. Aumentare la context window permette di conservare più materiale, ma rende più costoso consultarlo.

Nell'attention, la query rappresenta ciò che il modello cerca, le key servono a individuare le informazioni pertinenti e i value contengono le rappresentazioni da combinare. Durante il prefill, il modello elabora il prompt; durante il decode, genera nuovi token usando anche la KV cache già costruita.

Con la full attention, il costo computazionale del prefill cresce come $O(T^2)$ rispetto alla lunghezza $T$ del contesto. La sparse attention limita il numero di key consultate da ogni query, ma deve prima sceglierle. Se l'indexer confronta ogni query con tutte le key, o con tutti i blocchi, quella ricerca resta quadratica nel prefill.

Nel test su GLM descritto nel paper LSA, a 10M token l'indexer occupa il 98% del tempo di prefill di un layer di sparse attention. La misura riguarda il tempo necessario a elaborare l'ultimo chunk di query. In quel caso, quasi tutto il tempo serve a trovare le key da leggere.

LSA costruisce un indice basato sul contenuto delle key. Prima combina piccoli gruppi di key consecutive con il pooling. Poi suddivide la sequenza in blocchi e, all'interno di ciascuno, raggruppa le rappresentazioni simili in bucket. Per ogni bucket conserva un centroide, cioè un vettore che rappresenta il gruppo, e gli indici delle key originali.

La query viene confrontata con i centroidi per scegliere i bucket da cui recuperare le key. L'attention viene poi calcolata sulle key e sui value selezionati. I centroidi servono solo alla ricerca; la KV cache conserva le rappresentazioni originali.

Nei principali esperimenti D-LSA, le rappresentazioni usate dall'indice hanno 64 dimensioni. Ogni query seleziona 4.096 key long-range, cioè esterne alla finestra recente, e legge anche le 512 key più recenti e 4 sink key, conservate all'inizio della sequenza. Su GLM, D-LSA Flat seleziona 2.048 key long-range per le query che precedono la posizione 1M. Ogni query legge solo una parte delle key conservate nella cache.

Su Qwen-3.8-27B, a 10M token D-LSA Flat supera la versione con full attention nei due benchmark sul contesto lungo riportati dagli autori: 63,9 contro 59,9 su RULER e 29,1 contro 19,8 su PaperTrail. La differenza è di 4,0 e 9,3 punti rispettivamente, calcolata sui punteggi pubblicati.

Questi sono confronti con la full attention dello stesso Qwen, esteso con YaRN. PaperTrail riporta il punteggio F1 su 90 domande, ripetute tre volte. I valori di RULER e PaperTrail misurano cose diverse e non vanno confrontati fra loro.

Su GLM il confronto è fra Flat e Tree. A 10M token, D-LSA Flat ottiene 66,8 su RULER, mentre Tree scende a 55,8: perde 11,0 punti. Questo confronto misura la differenza tra le due varianti di D-LSA applicate a GLM. La ricerca ad albero può richiedere meno calcoli, ma una scelta sbagliata del ramo può escludere informazioni utili.

Anche Flat ha dei limiti. Su GLM lo scarto rispetto alla sparse attention originale resta entro 3 punti fino a 1M token, ma il calo arriva a 8 punti fra 2M e 5M. Gli autori ricordano che l'attention originale è stata addestrata insieme al modello. D-LSA viene invece aggiunta in seguito, lasciando invariati i pesi del modello.

Con 10M token in input, su otto H200, l'attesa del primo token di Qwen-3.8-27B scende da 4.582,2 a circa 497,5 secondi usando D-LSA Flat: da circa 76 minuti a poco più di 8 minuti. Il vantaggio è grande, ma la risposta non è immediata.

Il confronto riguarda Qwen-3.8-27B con un prompt di 10 milioni di token. Gli autori hanno usato otto GPU H200 con parallelismo TP8 e DCP8, eseguendo una richiesta alla volta in SGLang.

I dati provengono dalla tabella 3 del paper LSA. Abbiamo ricavato il tempo di D-LSA dallo speedup dichiarato dagli autori e arrotondato entrambi i tempi al secondo.

Per distinguere le due fasi della risposta, il TTFT indica il tempo necessario a ricevere il primo token; il TPOT, il tempo per generare ciascun token successivo.

Con contesti più corti, LSA può essere più lenta. Su Qwen con B300, a 512K token, gli speedup di D-LSA Flat sono 0,68x per il TTFT e 0,63x per il TPOT. Entrambi sono inferiori a 1: il primo token arriva più tardi e anche la generazione successiva richiede più tempo rispetto alla baseline. Tree, inoltre, non è sempre più veloce di Flat: su Qwen H200 a 10M, lo speedup del TTFT è 8,83x contro 9,21x.

La variante nativa viene testata su un modello ibrido da circa 0,5B parametri, con 24 layer: uno ogni quattro usa attention, gli altri Gated DeltaNet. Il confronto usa gli stessi dati e lo stesso numero di token di training per tutti i metodi.

N-LSA resta 2,5 punti sotto la full attention su RULER a 128K e raggiunge la stessa validation loss, 1,085. Il training del singolo layer è 1,6 volte più veloce. Considerando l'intero modello, la fase finale a 128K ha uno speedup di 1,24 volte: dai dati pubblicati si ricava un risparmio di tempo di circa il 19,4%.

Il picco di memoria sale però da 5,8 a 6,8 GiB per layer a 128K, anche perché occorre conservare gli indici delle key selezionate per il backward pass. Lo speedup di 1,24 volte è stato misurato nella fase finale del training, con contesto lungo.

Zyphra Hierarchical Attention, di Zyphra Research, costruisce un albero a partire da chunk consecutivi di key. Per riassumere il contenuto di ciascun nodo usa alcune reference query, i cui parametri vengono appresi durante il training. La query del modello viene poi confrontata con questi riassunti, partendo dalla cima dell'albero, per scegliere i rami in cui cercare.

Rispetto a LSA cambiano soprattutto il modo di raggruppare le key e il numero di key recuperate. LSA raggruppa per somiglianza e, una volta scelta la configurazione, recupera un numero prestabilito di key long-range. ZHA mantiene i chunk consecutivi e ne seleziona quanti ne servono per raggiungere una certa quota del peso di attention complessivo stimato per i candidati. Questa quota è la soglia top-p.

Questa flessibilità permette di adattare la ricerca alla domanda. Per trovare una singola informazione possono bastare poche key; per combinare informazioni distribuite nel contesto ne possono servire molte di più. A ogni livello, però, la soglia si applica solo ai candidati rimasti dopo le selezioni precedenti. Impostare p a 0,95 non garantisce quindi di conservare il 95% del peso complessivo della full attention originale.

Il paper LSA riporta tempi misurati eseguendo i modelli in SGLang con contesti fino a 10M token. Il paper ZHA approfondisce invece come variano la selezione delle key e i risultati al cambiare della struttura dell'albero, anche nei test su agenti. Per stabilire quale metodo sia più veloce a parità di qualità, bisognerebbe provarli sullo stesso modello, con gli stessi prompt e lo stesso hardware.

I numeri dei due studi non si possono confrontare direttamente:

• I modelli sono diversi. LSA usa Qwen-3.8-27B, ZHA Qwen3.6-35B-A3B. Manca un modello comune con cui verificare quanto incidano le differenze fra i due studi.
• RULER viene eseguito a lunghezze diverse. Un risultato a 10M non è confrontabile con uno a 256K. LSA usa 20 esempi per task oltre 1M; ZHA ne usa 100 a 256K.
• Le domande di LongBench v2 cambiano. LSA ne usa 60; ZHA ne seleziona 205 con contesto originale di almeno 128K. Cambiano anche i limiti di generazione.
• Cambiano i test di reasoning. LSA valuta AIME 2025, ZHA AIME 2026, con sampling e numero di ripetizioni diversi.
• Le latenze descrivono cose diverse. Il tempo di una richiesta completa, quello di un singolo layer e una stima roofline non misurano la stessa cosa.

Possiamo confrontare ciascun metodo con la sua baseline nello stesso studio. Calcolare una media fra risultati ottenuti in condizioni così diverse sarebbe fuorviante.

Se vuoi usare LSA per un assistente che consulta paper scientifici, parti da domande di cui puoi verificare la risposta. Alcune dovrebbero richiedere di collegare più documenti; altre dovrebbero chiedere informazioni assenti dalla raccolta, per verificare se il modello riconosce di non avere una risposta. Controlla la correttezza delle risposte e delle fonti citate, poi misura TTFT, TPOT e memoria.

Prefrontal AI mette a disposizione il codice, le matrici ottenute dalla distillazione dell'indexer e le configurazioni degli esperimenti. Questi comandi si limitano a preparare l'ambiente e mostrare l'help della CLI. Non li abbiamo eseguiti; seguono il README della versione indicata. Servono Python 3.12 e uv. Per eseguire i modelli con il runtime descritto dagli autori servono GPU NVIDIA e il relativo software.

Entrambi i metodi conservano la KV cache. Ridurre le key consultate da una query non significa poter eliminare tutte le altre: una domanda successiva potrebbe averne bisogno. La memoria della cache continua quindi a crescere linearmente con il contesto.

Nel test LSA su GLM a 10M token, la KV cache di un solo layer occupa 10 GiB. Con context parallelism su otto GPU, ogni processo GPU, o rank, ne conserva 1,25 GiB, insieme a una copia completa dell'indice dei bucket da 246 MiB. Per calcolare la memoria necessaria all'intero modello bisogna considerare anche gli altri layer, i pesi e le ulteriori allocazioni del runtime.

Il codice LSA è rilasciato sotto Apache-2.0; le componenti di terze parti mantengono le proprie licenze e il kit PaperTrail è indicato come CC BY 4.0. Per i modelli di partenza e i dataset restano valide le rispettive licenze. Per ZHA, la disponibilità del paper su arXiv non implica una licenza software o il rilascio di un runtime ottimizzato.

LSA riduce il tempo necessario a consultare contesti molto lunghi, soprattutto quando la ricerca delle key è l'operazione più costosa. Restano da capire quanto regga sui compiti più difficili, quando convenga usarla sotto il milione di token e come si comporti N-LSA su modelli più grandi. ZHA affronta lo stesso problema con una scelta diversa: adattare il numero di key lette alla domanda e alle informazioni presenti nel contesto.

Dati aggiornati al 3 novembre 2026. L'articolo si basa su LSA v1, pubblicato il 30 ottobre, e ZHA v2, aggiornato il 2 novembre. I risultati dei benchmark sono quelli degli autori: non abbiamo ripetuto gli esperimenti. Abbiamo calcolato le differenze fra i punteggi, i tempi ricavati dagli speedup e il risparmio percentuale sul tempo di training, usando i valori arrotondati dei paper. L'assistente di ricerca è un esempio d'uso; non abbiamo eseguito i comandi.