Come gestisce Paged Attention la cache KV durante richieste AI locali simultanee?

Paged Attention gestisce la cache KV concorrente mappando lo stato dei token in crescita di ogni richiesta su blocchi di dimensione fissa, che possono essere allocati e riciclati indipendentemente.

Questo è importante su un server AI domestico perché le chat attive, le attività sui documenti e gli agenti raramente hanno la stessa lunghezza del contesto o terminano nello stesso momento. Una strategia di prenotazione contigua spreca la preziosa memoria dell’acceleratore attorno a queste sequenze variabili. Il paging modifica la disposizione della memoria, consentendo allo scheduler di utilizzare più densamente la capacità disponibile.

Le richieste concorrenti creano cache KV che crescono a velocità diverse

Ogni richiesta autoregressiva attiva necessita dello stato key e value per i token elaborati. Una chat può terminare dopo 100 token, mentre un’altra continua per migliaia di token; per questo il loro fabbisogno di memoria non può essere conosciuto con precisione quando il batch viene avviato.

Il paper PagedAttention identifica la memoria della cache KV a crescita dinamica come un collo di bottiglia del serving che limita il batching quando l’allocazione è inefficiente.

Su un server domestico con diversi utenti o agenti in background, questa variabilità trasforma una grande quantità di memoria libera in numerose allocazioni attive di dimensioni differenti.

Le prenotazioni contigue fisse sprecano memoria attorno alle sequenze variabili

Un runtime ingenuo può riservare una grande area contigua per ogni richiesta, basandosi sulla lunghezza massima. Le richieste brevi lasciano spazio inutilizzato all’interno della loro prenotazione, mentre quelle più lunghe possono richiedere una riallocazione o un sovradimensionamento.

vAttention riassume la motivazione originale del paging: le prenotazioni anticipate della cache KV creano frammentazione interna. La memoria sprecata riduce il numero di richieste che possono rimanere attive contemporaneamente.

Il sintomo pratico è un limite di memoria insufficiente o un batch massimo ridotto, anche se la somma degli stati dei token effettivamente utilizzati sembra inferiore alla VRAM disponibile.

PagedAttention divide lo stato KV in blocchi di dimensione fissa

PagedAttention sostituisce un singolo buffer fisicamente contiguo per la richiesta con una sequenza logica di blocchi. Quando arrivano altri token, il runtime alloca ulteriori blocchi fisici da un pool condiviso.

vLLM spiega che i blocchi KV possono risiedere in una memoria fisica non contigua. Una tabella dei blocchi associa l’ordine logico dei token della richiesta alle rispettive posizioni fisiche.

Il modello continua a prestare attenzione alla sequenza corretta. L’indirezione modifica la posizione in memoria, non l’ordine semantico della conversazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

I blocchi liberati tornano in un pool condiviso quando le richieste terminano

Quando una richiesta termina, i blocchi non condivisi possono essere rilasciati immediatamente e riutilizzati da un’altra richiesta attiva o appena ammessa. Il server non deve aspettare che un’intera grande area diventi vuota.

Lo stack di inferenza di NVIDIA espone la capacità della cache KV come risorsa del serving, da bilanciare con i pesi e l’area di lavoro del runtime.

Questo riciclo a livello di blocco è prezioso in ambito domestico perché le lunghezze delle richieste sono irregolari: una persona pone una breve domanda sulla casa intelligente, mentre un’altra esegue un lungo assistente per documenti e un agente in background riassume i file.

Il paging aumenta la concorrenza riducendo la frammentazione, non riducendo ogni token

PagedAttention non rende fondamentalmente più piccoli i tensori key e value di un singolo token. Il principale vantaggio in termini di memoria deriva dall’allocazione più vicina alla crescita effettiva della sequenza e dalla possibilità di condividere lo stato quando è valido farlo.

La guida al calcolo distribuito di PyTorch distingue il parallelismo del modello dalla gestione della memoria del serving. Il paging non è parallelismo tensoriale e non suddivide autonomamente i pesi del modello tra più GPU.

Se i pesi del modello consumano già quasi tutta la memoria del dispositivo, il paging non può creare capacità sufficiente per una concorrenza elevata. Migliora l’utilizzo della regione KV rimanente.

La gestione dei blocchi comporta costi aggiuntivi e limiti di scheduling

Il runtime deve ora gestire tabelle dei blocchi, conteggi dei riferimenti, decisioni di allocazione e kernel di attenzione compatibili con layout paginati. Batch estremamente piccoli o hardware non supportato possono ridurre il vantaggio.

L’articolo di ZimaSpace sulla concorrenza familiare e sulla pressione sulla cache KV mostra il limite dal punto di vista dell’utente: l’efficienza della memoria è importante perché determina quanti contesti attivi possono coesistere prima che la coda inizi ad allungarsi.

Prova diverse lunghezze delle richieste e diversi schemi di arrivo, anziché un solo batch sintetico. La guida di ZimaSpace alle finestre di contesto scorrevoli e alla memoria KV è un confronto utile, perché il windowing modifica la quantità di stato conservata da ogni sequenza, mentre il paging modifica il modo in cui tale stato viene allocato. Registra le sequenze attive, i blocchi KV utilizzati, il tempo in coda e le preemption.

Lo scheduler TGI di Hugging Face distingue inoltre lo scheduling di prefill e decode durante il serving concorrente. La memoria paginata aiuta lo scheduler ad ammettere il lavoro, ma equità e latenza dipendono comunque dal modo in cui tale lavoro viene messo in coda.