Il contesto riutilizzabile delle sessioni AI può gravare sulla memoria GPU

In parole semplici

La ricerca

Cosa mostrano le prove

• La memoria delle sessioni

  Questo studio operativo sui sistemi esamina come i sistemi di serving dovrebbero gestire lo stato salvato nella cache key-value (KV) tra le chiamate di una sessione. Le chiamate successive possono riutilizzare calcoli fatti sul contesto precedente, ma conservare quello stato nella memoria della GPU occupa capacità quando una sessione è inattiva.

  Gli autori analizzano quattro carichi di lavoro Microsoft M365 in produzione e riproducono i flussi di chiamate per esaminare la pressione sulla memoria e lo stato locale alla distribuzione.

• Stimare la scala

  Poiché le configurazioni dei modelli in produzione sono riservate, le stime in byte usano la configurazione pubblica della cache KV di Llama-2-70B. Con questa ipotesi, una sessione Deep Research al 99° percentile ha una quantità stimata di stato KV pari a 81.6 GiB, superiore agli 80 GB di memoria di una GPU H100.

  In una stima separata, mantenere lo stato di picco di ogni sessione Research idonea per tutta la sua durata osservata produce un limite massimo di 501.8 TB per la flotta. Queste cifre riguardano solo la cache KV stimata, non l’effettiva allocazione di memoria delle GPU.

• Provare un limite di inattività

  Gli autori riproducono quindi l’intera traccia Research idonea applicando un limite di inattività: dopo un’ora senza attività, lo stato KV dimensionato sul picco della sessione viene eliminato. La permanenza massima stimata per la flotta scende da 501.8 TB a 140.8 TB, mentre la quota di chiamate che richiede una ricostruzione sale dal 4.07% al 4.53%.

  Le percentuali si riferiscono alle chiamate di quella traccia. Il confronto indica che i lunghi intervalli di inattività gonfiano la stima che mantiene tutto attivo, mentre con questa impostazione l’aumento delle chiamate da ricostruire nel replay è contenuto.

• Le copie recuperabili riducono le ricostruzioni

  Un replay separato testa diverse policy di memoria su 176,007 chiamate da 9,486 sessioni nell’ora di Research con più attività, assegnando a tutte le sessioni un budget condiviso di 4.7 TB. La quota di chiamate che richiede una ricostruzione è del 62.9% con l’eliminazione least recently used e del 31.1% con furthest-next-use.

  Conservare lo stato espulso in una copia int4 più piccola riduce il tasso al 13.6%. Poiché MRR riduce lo stato seguendo l’ordine di eliminazione di LRU, il suo miglioramento rispetto a LRU isola l’effetto di conservare una copia più piccola e recuperabile anziché eliminare lo stato.

  Il vantaggio rispetto a FNU con questo budget deriva dal fatto che entra in memoria più stato, non dalla conoscenza del futuro; al budget più ristretto testato, FNU ha un tasso di ricostruzione inferiore. Il risultato vale per questo replay e questo budget; non considera la qualità delle risposte né i costi di ripristino delle copie.

• Il posizionamento aggiunge un limite minimo distinto

  Infine, un replay con memoria illimitata cambia il modo in cui vengono identificati gli oggetti della cache. Quando lo stato è locale a una distribuzione, identificare gli oggetti con sessione e distribuzione porta la quota minima di ricostruzioni al primo accesso dal 5.4% al 20.2% delle chiamate nella stessa ora di Research.

  Gli autori interpretano questo risultato come un problema di posizionamento distinto dalla pressione sulla memoria: più memoria non elimina le mancate corrispondenze dovute allo stato indisponibile presso un’altra distribuzione.