Il collo di bottiglia dei modelli a contesto lungo non si presenta solo quando il modello genera, ma prima: durante il prefill, l'attenzione densa deve attraversare l'intero prompt. La proposta RBS-Attention interviene esattamente su questo costo. Non richiede addestramento, non tocca i pesi e si integra con l'esecuzione block-sparse di FlashAttention su GPU H100.

Il problema che RBS-Attention affronta è sottile. Quando si selezionano blocchi sparsi, il centroide di un blocco può nascondere un token molto rilevante in mezzo a molti irrilevanti. Gli autori chiamano questo fallimento 'mean dilution'. Per aggirarlo, il metodo usa due rami di selezione complementari: un ramo basato sul centroide cattura la rilevanza media, mentre un ramo rescue usa il raggio massimo del blocco chiave e la sua distribuzione per prompt, layer e testa per identificare i blocchi a rischio di sottostima. Le soglie dei due rami sono indipendenti e le maschere vengono combinate, mantenendo l'esecuzione regolare con FlashAttention sparsa a blocchi.

Sui benchmark dichiarati, i numeri sono rilevanti. Su GPU H100 con Qwen3-30B-A3B-Instruct-2507-FP8 a 128K token, RBS-Attention raggiunge 20,65x di accelerazione sul solo prefill-attention stand-alone, 11,92x sul prefill-attention in vLLM e 5,97x end-to-end sul tempo al primo token. Sul modello denso Qwen3-32B, l'accuratezza RULER complessiva è 88,65 contro 89,52 dell'attenzione densa, con valutazioni aggiuntive su LongBench-v2, InfiniteBench e Video-MME.

Il punto strutturale non è la singola accelerazione. È che la selezione sparsa sta diventando adattiva e dipendente dal contenuto, non più una scorciatoia statica che accetta di perdere token rari. Per chi gestisce modelli self-hosted in un parco GPU fisso, questo tocca il TCO in modo diretto: se il prefill consuma meno calcolo, contesti lunghi diventano realistici anche senza aggiungere GPU o passare a servizi cloud. Ma il vincolo si sposta, non sparisce. La memoria per la cache KV e la larghezza di banda restano fattori determinanti, soprattutto quando si aumenta la lunghezza del contesto. Chi usa quantization FP8 o FP16 su singole GPU deve comunque fare i conti con la VRAM: un prefill più veloce non libera automaticamente spazio per sequenze più lunghe. Per chi valuta deployment on-premise, i trade-off tra accelerazione del prefill, memoria e costi fissi dell'hardware trovano spazio anche negli strumenti analitici che AI-RADAR propone su /llm-onpremise.

Un secondo effetto riguarda la qualità. La compressione del prefill spesso si paga in accuratezza sui benchmark di lungo contesto. Qui il divario RULER è inferiore a un punto percentuale, ma la fonte segnala valutazioni aggiuntive su LongBench-v2, InfiniteBench e Video-MME: il metodo non può essere valutato solo sui token al secondo, ma sulla capacità di non far sparire gli elementi rari. Il ramo rescue è pensato proprio per questo, ma la sua efficacia dipende da soglie che variano per prompt, layer e testa. In pratica, la complessità si sposta dall'architettura del modello alla configurazione del runtime. Dal punto di vista degli equilibri di settore, tecniche training-free come questa riducono la barriera all'adozione di contesti lunghi per chi ha hardware già installato. I fornitori di servizi cloud mantengono il vantaggio dell'elasticità, ma un deployment on-premise con una o poche GPU H100 può affrontare carichi che prima richiedevano risorse più ampie. Il prezzo da pagare è la complessità operativa: servono pipeline di serving come vLLM che supportino l'esecuzione block-sparse e la combinazione delle maschere.

La domanda aperta è se il guadagno resti stabile quando la lunghezza del contesto cresce oltre i 128K token.