Perché la cache KV cresce con la lunghezza del contesto dell’IA domestica?

La cache KV cresce con la lunghezza del contesto perché il runtime memorizza chiavi e valori dell'attenzione per ogni token conservato nei diversi livelli del modello.

Un breve prompt per l'IA domestica può lasciare memoria sufficiente per diversi utenti, mentre un documento lungo, una cronologia di chat estesa o la traccia di un agente possono consumare molta più memoria di lavoro senza modificare il file del modello. La cache viene inizializzata durante l'elaborazione del prompt e continua a crescere man mano che il modello genera nuovi token. Le sue dimensioni dipendono anche dal numero di livelli, dall'architettura dell'attenzione, dalla precisione numerica e dalle richieste simultanee. Le sezioni seguenti seguono questa crescita da un singolo token fino al limite di memoria dell'intero server.

Ogni token conservato aggiunge uno stato di attenzione

Durante l'inferenza del trasformatore, ogni livello produce tensori di chiavi e valori dai token già elaborati. Il runtime conserva questi tensori in modo che il token successivo possa prestare attenzione al contesto precedente senza ricalcolare l'intera sequenza.

Il lavoro di vLLM identifica lo stato KV per token come un requisito importante per la memoria di distribuzione. I nuovi token aggiungono nuove voci alla cache, mentre quelle conservate in precedenza restano disponibili per i successivi passaggi di attenzione.

La cache è quindi uno stato mutabile della richiesta, non una parte dei pesi statici del modello. Caricare lo stesso modello con una conversazione attiva più lunga crea un ingombro di memoria maggiore.

La crescita della cache è approssimativamente lineare rispetto alla lunghezza della sequenza conservata

Con un'architettura del modello e una precisione della cache fisse, raddoppiare il numero di token conservati raddoppia approssimativamente le voci KV mantenute per quella richiesta. Sia il prompt sia la risposta generata contribuiscono alla sequenza attiva.

H2O descrive come la cache KV varia con la lunghezza della sequenza e la dimensione del batch. La relazione resta approssimativamente lineare perché ogni token aggiuntivo contribuisce con chiavi e valori a ogni livello che genera la cache.

Per questo motivo, aumentare un'impostazione del runtime da un contesto ridotto a un limite massimo molto più ampio può modificare il limite pratico di memoria, anche quando il modello utilizza pesi identici.

Il valore massimo impostato e l'utilizzo effettivo sono due cose diverse. Alcuni runtime allocano i blocchi della cache su richiesta, mentre altri riservano anticipatamente una regione più ampia per garantire la crescita futura.

L'architettura del modello modifica il numero di byte per token

Due modelli con lo stesso numero di parametri possono richiedere quantità diverse di memoria KV perché possono usare numeri differenti di livelli, dimensioni delle teste, teste di attenzione, grouped-query attention o multi-query attention.

KIVI studia la precisione della cache KV e mostra che memorizzare chiavi e valori con un numero inferiore di bit può ridurre sostanzialmente la memoria di picco. Il vantaggio riguarda lo stato della richiesta, non la riduzione dei pesi del modello sottostante.

Le architetture grouped-query e multi-query condividono le teste chiave-valore tra più teste query, riducendo potenzialmente i byte della cache per token rispetto alla normale attenzione multi-head. Il numero di livelli e l'ampiezza delle teste continuano comunque a moltiplicare lo stato conservato.

Una stima utile deve quindi basarsi sull'architettura esatta del modello e sul formato della cache del runtime, non soltanto su una regola generica di byte per token copiata da un altro modello.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

I token generati continuano ad ampliare la cache dopo il prefill

L'elaborazione del prompt crea la cache iniziale per il contesto di input. La decodifica autoregressiva aggiunge quindi lo stato di ogni token di output accettato, affinché i token successivi possano prestare attenzione all'intera conversazione.

vAttention considera la crescita dinamica della cache un problema di allocazione, perché la lunghezza finale dell'output è sconosciuta quando inizia una richiesta. Riservare troppo spazio spreca memoria, mentre riservarne troppo poco può richiedere la preemption o operazioni di espansione.

Un prompt che rientra comodamente nei limiti può comunque superare il limite di memoria durante una risposta lunga. I limiti dell'output proteggono quindi la memoria oltre alla lunghezza della risposta e al tempo di generazione.

Gli utenti simultanei moltiplicano lo stato dei singoli contesti

I pesi del modello possono essere condivisi tra le richieste, ma ogni conversazione attiva normalmente mantiene la propria cronologia dei token e la propria cache KV. Cinque utenti con contesti lunghi non condividono una cache universale soltanto perché usano lo stesso modello.

Le ricerche recenti sulla gestione della KV descrivono le riserve per richiesta come un compromesso centrale tra efficienza della memoria e rischio di preemption. La lunghezza dell'output, quando è sconosciuta, rende il picco combinato più difficile da prevedere rispetto a un semplice conteggio degli utenti.

I prefissi di prompt condivisi possono talvolta riutilizzare lo stato della cache quando il runtime supporta una corrispondenza esatta dei prefissi, ma la cronologia privata delle chat e gli output divergenti creano comunque rami separati.

La guida hardware di ZimaSpace considera il contesto e la concorrenza requisiti di memoria aggiuntivi rispetto al file del modello. Un test con un solo utente può quindi sottostimare la RAM o la VRAM necessaria a un assistente domestico.

Paging, quantizzazione ed espulsione modificano il limite, non la causa

L'allocazione paginata riduce la frammentazione dividendo lo stato della cache in blocchi più piccoli, così il runtime non deve riservare un'unica area contigua sovradimensionata per ogni possibile sequenza.

PagedAttention offre un'allocazione basata su blocchi, mentre la quantizzazione della cache riduce i byte per valore memorizzato e le politiche di espulsione eliminano alcune voci meno recenti. Ogni metodo modifica la quantità di contesto che può essere contenuta, ma lo stato di attenzione conservato continua a crescere man mano che si accumulano token.

L'espulsione o le finestre scorrevoli possono limitare la memoria rimuovendo i token precedenti, ma il modello non può più prestare attenzione allo stato eliminato attraverso il normale percorso a contesto completo. Anche la compressione e la conservazione selettiva possono introdurre compromessi legati alla qualità o al carico di lavoro.

Misura l'utilizzo della cache con il modello reale, il contesto, la precisione della cache, la dimensione del batch e il numero di utenti effettivi. Il limite pratico viene raggiunto quando un altro token o un'altra richiesta non può essere ammesso senza espulsione, trasferimento su memoria secondaria, ricalcolo o errore.

Domande frequenti

Il file del modello diventa più grande quando aumenta la lunghezza del contesto?

No. I pesi del modello rimangono invariati. La memoria aggiuntiva è costituita dallo stato del runtime creato per il prompt attivo e per i token generati.

Impostare un contesto massimo elevato alloca sempre immediatamente tutta la memoria KV?

No. Il comportamento di allocazione dipende dal runtime. Alcuni riservano la capacità in anticipo, mentre i sistemi paginati allocano i blocchi man mano che i token vengono ammessi.

La RAM di sistema può contenere la cache KV quando la VRAM è piena?

Alcuni runtime possono trasferire o spostare lo stato della cache, ma i trasferimenti aggiungono latenza e dipendono dal supporto software, dalla larghezza di banda e dal percorso di attenzione attivo.