HySparse2 di Xiaomi riduce il costo dei contesti lunghi senza rinunciare al recupero delle informazioni

Per un agente AI che lavora a più riprese, ogni risposta di uno strumento può aggiungere molto testo a una conversazione già lunga. Il problema non è soltanto conservare quel contesto: bisogna elaborarlo prima di generare la risposta successiva, senza perdere la capacità di ritrovare informazioni inserite molto prima. HySparse2 è la proposta architetturale di Xiaomi per ridurre questo costo. Il lavoro è collegato ai piani per MiMo-V3, ma non documenta il rilascio dei pesi di un nuovo MiMo-V3. 34

Perché il prefill può fermarsi prima

HySparse2 divide il modello, secondo un’impostazione ispirata a YOCO, in un self-decoder e un cross-decoder. Il self-decoder elabora il lungo input iniziale. Con il meccanismo chiamato KV Bridging, i livelli di attenzione completa del cross-decoder costruiscono le proprie chiavi e i propri valori — i dati della cache KV usati dall’attenzione — a partire dagli stati prodotti dal self-decoder. Per il contesto già presente, la fase iniziale di elaborazione, o prefill, può quindi terminare dopo il self-decoder, senza far attraversare lo stesso lungo input anche al cross-decoder. Quest’ultimo continua invece a partecipare quando il modello genera nuovi token. 4615

C’è poi un secondo livello di condivisione. Con KV Reuse, i livelli di attenzione sparsa di ciascun blocco ibrido del cross-decoder riutilizzano sia la cache KV sia gli indici dei token selezionati dal precedente livello di attenzione completa. La selezione avviene token per token, anziché per blocchi di testo. Inoltre, i token più recenti vengono inclusi obbligatoriamente: così il modello mantiene accessibile il contesto vicino senza una diramazione separata di attenzione a finestra scorrevole (sliding-window attention, SWA). Token recenti e token lontani selezionati possono usare la stessa cache. 4615

Che cosa mostrano i confronti

In una configurazione MoE — mixture of experts, in cui si attiva solo una parte dei parametri per ogni token — con 80 miliardi di parametri totali e circa 3 miliardi attivi per token, il confronto riportato con Hybrid SWA indica che, a un milione di token, HySparse2 usa 5,02 volte meno FLOP di prefill. La cache KV indicata è di 2,69 GB contro 12,09 GB, circa 4,5 volte più piccola. Xiaomi segnala anche punteggi migliori nei test di recupero MRCRv2 e RULER-v2 e valori inferiori per AgentPPL e LongPPL; secondo un resoconto della valutazione, HySparse2 precede sia HySparse sia Hybrid SWA nei test di recupero su contesti lunghi esaminati. 615

Un test di ablazione permette di attribuire un risultato più preciso alla selezione token per token: mantenendo invariati la struttura di base e il budget di attenzione, e cambiando soltanto la selezione per blocchi con quella per token, nei test fino a 32.000 token il resoconto indica incrementi di 6,57 punti percentuali su RULER-v2, 8,14 punti su MRCR-v2 con due informazioni da recuperare e 5,55 punti su GraphWalks. Questo sostiene l’utilità della selezione più fine in quel contesto, ma non misura separatamente il contributo di KV Bridging, KV Reuse o dell’inclusione obbligatoria dei token recenti. 6

I limiti dei numeri

Le fonti disponibili non permettono di quantificare il confronto HySparse contro HySparse2 a un milione di token, né di stabilire quanto ciascun meccanismo contribuisca ai guadagni complessivi o se gli stessi miglioramenti persistano su modelli più grandi. Gli estratti citati non specificano inoltre la precisione di memorizzazione alla base del dato di 2,69 GB: non va quindi presentato come una misura verificata specificamente in FP8. Infine, FLOP di prefill e dimensione della cache non sono misure della latenza in un servizio reale. 615