Riepilogo Tecnico: xGR: Servizio di Raccomandazione Generativa Efficiente su Larga Scala

1. Definizione del Problema

I sistemi di Raccomandazione Generativa (GR), che sfruttano i Large Language Models (LLM) per prevedere le interazioni utente-item, affrontano sfide di servizio uniche che differiscono significamente dall'inferenza standard dei modelli linguistici conversazionali. Sebbene la GR condivida l'architettura basata sull'attenzione degli LLM, le sue caratteristiche di carico creano colli di bottiglia specifici in ambienti di produzione ad alta concorrenza e bassa latenza:

• Disallineamento del Carico di Lavoro: A differenza degli LLM conversazionali che generano risposte lunghe a prompt brevi, la GR elabora lunghe sequenze di cronologia utente (prompt) per produrre output brevi e di lunghezza fissa.
• Overhead della Beam Search: La GR richiede ampie larghezze di beam (BW) e valori Top-K elevati per garantire la diversità e l'accuratezza delle raccomandazioni. Ciò porta a pool di candidati massicci (ad es. $128 \times 128$ o $512 \times 512$), rendendo le operazioni di ordinamento e filtraggio computazionalmente costose.
• Inefficienza della Memoria: I sistemi di servizio LLM esistenti (ad es. PagedAttention) trattano ogni beam come una sequenza indipendente. Ciò causa il caricamento ridondante del contesto del prompt condiviso (KV cache) per ogni beam e necessita di costosi copiamenti di blocchi quando le sequenze dei beam si diramano, portando a frammentazione della memoria e saturazione della larghezza di banda.
• Generazione di Token Invalidi: A causa del vasto spazio combinatorio di ID dei token, molte sequenze generate non corrispondono a item del mondo reale. Il filtraggio dinamico di questi item invalidi introduce latenza, mentre lo stoccaggio preventivo delle maschere crea un overhead di memoria ingestibile.
• Latenza di Scheduling: I modelli GR sono spesso più piccoli dei modelli LLM generali, rendendo il sistema altamente sensibile agli overhead non computazionali come lo scheduling lato host e la sincronizzazione, che possono dominare il budget di latenza (gli SLO rigorosi richiedono una latenza P99 entro circa 200ms).

2. Metodologia: Il Sistema xGR

Gli autori propongono xGR, un sistema di servizio dedicato progettato per ricostruire la pipeline GR attraverso tre componenti strettamente accoppiati: xAttention (livello operatore), xBeam (livello algoritmico) e xSchedule (livello di sistema).

2.1 xAttention: Ottimizzazioni a Livello di Operatore

xAffronta i colli di bottiglia di memoria e calcolo nel meccanismo di attenzione:

• KV Cache Separata: xGR scinde la KV cache in componenti Shared (condivisa) e Unshared (non condivisa). La cache Shared memorizza il contesto del prompt (cronologia utente) calcolato una sola volta durante la fase di prefill. La cache Unshared memorizza solo i token generati dinamicamente per ogni step di decode. Ciò elimina il caricamento ridondante del contesto del prompt tra i vari beam.
• Gestione a Granularità di Token: A differenza della gestione basata su blocchi (ad es. PagedAttention), la cache Unshared è gestita a livello di token. Ciò evita l'overhead di allineamento delle lunghezze delle sequenze alle dimensioni dei blocchi ed elimina la necessità di copie fisiche di blocchi quando i beam si diramano.
• Calcolo a Stadi: Il calcolo dell'attenzione è diviso in tre stadi: Shared, Unshared e Merging.
  • Gli stadi Shared e Unshared calcolano i punteggi di attenzione locale e le statistiche (massimi/somme) indipendentemente.
  • Lo stadio di Merging applica l'OnlineSoftmax per combinare i risultati.
  • Questo design consente il parallelismo di pipeline tra le unità hardware (Core Groups), fondendo le operazioni di BatchMatmul e Softmax per massimizzare l'utilizzo dell'hardware.
• Aggiornamenti In-Place: Per gestire la cache Unshared senza copie extra, xAttention utilizza una strategia di ordinamento ibrida con indici diretti per eseguire aggiornamenti di blocchi in-place, prevenendo hazard di tipo "write-before-read".

2.2 xBeam: Ottimizzazioni a Livello Algoritmico

xBeam ottimizza il processo di beam search per ridurre i costi di ordinamento e filtraggio:

• Vincolo di Percorso Valido: Per prevenire la generazione di item invalidi (sequenze di token che non mappano su prodotti reali), xBeam impiega un meccanismo di filtraggio basato su maschere. Utilizza un vocabolario di item validi pre-costruito per generare le maschere.
  • Archiviazione Ibrida Densa/Sparsa: Per gli primi step di decode con molti candidati, le maschere sono memorizzate densamente e pre-generate. Per gli step successivi con meno candidati, le maschere sono memorizzate in modo sparso e aggiornate in-place, minimizzando la latenza di generazione a runtime.
• Terminazione Anticipata dell'Ordinamento: La beam search comporta la selezione di sequenze Top-K da un pool ampio. Poiché le log-probabilità all'interno di un beam sono intrinsecamente ordinate, xBeam utilizza un min-heap globale e una strategia di terminazione anticipata. Se la log-probabilità di un nodo foglia è inferiore al minimo dell'heap, la traversata per quel ramo si interrompe immediatamente, evitando operazioni di ordinamento non necessarie.
• Riutilizzo delle Strutture Dati: Inve invece di allocare nuova memoria per ogni nuova sequenza candidata, xBeam riutilizza le strutture dati delle sequenze scartate, riducendo l'overhead di allocazione/deallocazione.

2.3 xSchedule: Ottimizzazioni a Livello di Sistema

xSchedule gestisce la pipeline multi-livello per massimizzare il parallelismo e la sovrapposizione:

• Gerarchia a Tre Livelli: Il sistema impiega una gerarchia di scheduler, engine e worker per consentire la sovrapposizione tra batch, all'interno dei batch e all'interno delle singole richieste.
• Sovrapposizione Host-Device: I flussi di controllo (ad es. kernel dispatch) e i trasferimenti di dati (ad es. generazione di maschere e trasferimento H2D) sono sovrapposti alle computazioni lato device (ad es. forward pass del modello).
• Esecuzione Basata su Grafi: Le operazioni lato device sono catturate in un grafo statico e inviate in blocco, riducendo l'overhead di lancio dei kernel e l'intervento della CPU.
• Batching Dinamico e Multi-Stream: xSchedule regola le dimensioni dei batch in base alla capacità di token e ai vincoli SLO. Impiega inoltre una strategia multi-stream per elaborare i batch concorrentemente, garantendo che l'impronta computazionale ridotta dei modelli GR non porti a un sottoutilizzo degli acceleratori.

3. Contributi Chiave

1. Analisi del Carico di Lavoro: Un'analisi completa delle caratteristiche del carico di lavoro GR, identificando che la fase di decode nella GR è computazionalmente pesante a causa della beam search, contrariamente all'assunto che il prefill sia il costo dominante nei classici LLM.
2. Ottimizzazione dell'Operatore (xAttention): Introduzione di un meccanismo di attenzione a stadi con gestione della KV cache separata, eliminando la ridondanza di accesso alla memoria e le copie di blocchi.
3. Ottimizzazione dell'Algoritmo (xBeam): Sviluppo di un algoritmo di beam search caratterizzato da vincoli di percorso valido, terminazione anticipata dell'ordinamento e riutilizzo delle strutture dati per minimizzare l'overhead di sorting e filtraggio.
4. Ottimizzazione del Sistema (xSchedule): Un sistema di servizio riprogettato che utilizza la sovrapposizione host-device, l'esecuzione basata su grafi e il parallelismo multi-stream per massimizzare il throughput sotto rigorosi vincoli di latenza.
5. Distribuzione in Produzione: Il sistema è stato distribuito in produzione per oltre sei mesi, servendo centinaia di milioni di utenti con una latenza P99 inferiore a 200ms anche a decine di migliaia di richieste al secondo (RPS).

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su dataset reali (Amazon Review e JD Trace) utilizzando NPU Ascend e GPU NVIDIA H800, confrontando xGR con baseline allo stato dell'arte (vLLM e xLLM).

• Throughput: Sotto rigorosi vincoli di latenza P99 (≤200ms), xGR raggiunge un throughput almeno 2,89× superiore rispetto alla migliore baseline (xLLM) sui modelli Qwen e 8,05× sui modelli OneRec.
• Scalabilità: All'aumentare della larghezza del beam (ad es. da 128 a 512), le baseline sperimentano una crescita non lineare della latenza e non riescono a rispettare gli SLO. xGR mantiene un aumento della latenza relativamente fluido, dimostrando una scalabilità robusta.
• Efficienza della Memoria: xGR riduce significativamente l'impronta di memoria. Con una larghezza di beam di 512, xGR consuma circa 10,6 GB rispetto ai 46,3 GB di xLLM. Decoppia l'uso della memoria dalla lunghezza della sequenza, mantenendo un basso utilizzo di memoria anche con contesti di input lunghi (3k token).
• Efficienza del Kernel: xAttention riduce la latenza del kernel di circa 6,6× e aumenta il throughput computazionale di 7× rispetto a PagedAttention. Trasforma il carico di lavoro da memory-bound (93,4% di tempo di attività nel pipeline di memoria per le baseline) a compute-bound (~52% di tempo di attività per xGR).
• Portabilità: I guadagni di prestazione sono coerenti sia su NPU Ascend che su GPU NVIDIA, validando la portabilità architettonica del sistema.

5. Significato e Claim

Il paper sostiene di essere il primo lavoro a ricostruire in modo completo il paradigma di servizio GR, coprendo ottimizzazioni che vanno dagli operatori agli algoritmi e all'architettura di sistema.

• Cambio di Paradigma: Sfida l'idea che i sistemi di servizio LLM standard siano sufficienti per la GR, evidenziando le uniche caratteristiche di "long prompt, short output" e "high beam width" che richiedono una gestione specializzata.
• Violabilità in Produzione: Il sistema non è meramente teorico; è distribuito in un ambiente di produzione ad alta concorrenza (JD Company), provando la sua capacità di gestire pattern di traffico reali e rigorosi SLO.
• Ottimizzazione Olistica: Il paper sottolinea che i miglioramenti hardware da soli (ad es. GPU più veloci) non sono sufficienti a risolvere le sfide del servizio GR. Al contrario, è necessaria una riprogettazione completa del sistema che affronti la gestione della memoria, gli algoritmi di ricerca e lo scheduling per sbloccare il pieno potenziale della Raccomandazione Generativa.