In che modo la memorizzazione nella cache dei prefissi riduce il lavoro ripetuto sui prompt su un server AI domestico?

Il caching dei prefissi riduce il lavoro ripetuto sui prompt riutilizzando lo stato chiave-valore già calcolato per una sequenza iniziale identica di token.

Su un server AI domestico, quel prefisso condiviso può essere una policy di sistema, uno schema degli strumenti, un documento lungo, un insieme di istruzioni per la casa o una cronologia chat ripetuta. La prima richiesta sostiene comunque l’intero costo di prefill, ma le richieste successive compatibili possono saltarne una parte significativa. Il vantaggio principale è un percorso di prefill più breve e un primo token più rapido, non una generazione gratuita.

Senza cache, i prompt ripetuti ricalcolano lo stesso prefill

Prima di generare una risposta, un modello autoregressivo elabora i token di input e costruisce lo stato chiave-valore utilizzato durante la decodifica successiva. Un lungo prompt di sistema, uno schema degli strumenti, l’intestazione di un documento o un blocco di istruzioni condiviso possono quindi consumare lo stesso lavoro di prefill a ogni richiesta.

Prompt Cache formalizza questa opportunità riutilizzando gli stati di attenzione dei segmenti di prompt sovrapposti. Su un server AI domestico, la parte ripetuta può contenere migliaia di token, anche se l’utente aggiunge soltanto una nuova frase.

Senza riutilizzo, la GPU o la CPU esegue nuovamente quelle operazioni matriciali e legge gli stessi pesi del modello per lo stesso prefisso. L’output può essere identico, ma il server sostiene comunque il costo computazionale di preparazione.

Una cache dei prefissi memorizza lo stato KV di un prefisso già elaborato

Dopo la prima richiesta compatibile, il runtime può conservare lo stato KV associato al prefisso condiviso. Una richiesta successiva inizia verificando se la sequenza iniziale di token corrisponde ai blocchi memorizzati nella cache.

La cache automatica dei prefissi di vLLM identifica i blocchi in base a token presenti nel blocco e prefisso precedente. Le richieste compatibili possono fare riferimento agli stessi blocchi fisici della cache invece di allocare e calcolare stati duplicati.

L’oggetto riutilizzabile non è la risposta finale né un riepilogo semantico generico. È uno stato di attenzione specifico del modello per un prefisso esatto e compatibile.

Un riscontro positivo nella cache salta il prefill condiviso, ma calcola comunque il nuovo suffisso

Quando il prefisso corrisponde, il runtime può partire dallo stato di attenzione memorizzato ed elaborare soltanto i nuovi token successivi al limite della cache. Un assistente domestico con un prompt di sistema stabile può quindi evitare il lavoro ripetuto prima di ogni comando breve.

LMCache descrive il riutilizzo della cache KV tra le richieste degli LLM come un’ottimizzazione del livello di servizio, non come una modifica ai pesi del modello.

Il nuovo messaggio dell’utente richiede comunque il prefill e ogni token generato richiede ancora il calcolo di decodifica. Il caching dei prefissi riduce principalmente il lavoro ridondante prima dell’inizio della generazione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

I prefissi lunghi e stabili offrono il maggiore guadagno nel tempo al primo token

Una cache fa risparmiare una quantità di lavoro proporzionale alla parte che altrimenti verrebbe ricalcolata. Riutilizzare un prefisso di 2.000 token composto da istruzioni e documenti è più significativo che riutilizzare un saluto di dieci token.

Il design di servizio di SGLang utilizza il riutilizzo strutturato della cache KV per accelerare i carichi di lavoro con prefissi condivisi. L’equivalente su un server domestico è una policy ripetuta dell’agente, un catalogo di strumenti, un pacchetto di conoscenze domestiche o un modello di documento.

Per questo il caching dei prefissi dovrebbe essere valutato in base al tempo al primo token e al throughput di prefill, non soltanto in base ai token al secondo durante la generazione. La fase di decodifica può rimanere pressoché invariata, mentre la risposta inizia prima.

Piccole modifiche al prompt possono interrompere il riutilizzo al confine del blocco

Una cache è generalmente precisa rispetto ai token e allo stato del modello. Riordinare le definizioni degli strumenti, inserire un timestamp variabile vicino all’inizio, cambiare gli adattatori o modificare il prompt di sistema può rendere i blocchi successivi non idonei al riutilizzo.

Le indicazioni di servizio di Hugging Face distinguono la pianificazione di prefill e decodifica. Mantenere i contenuti stabili all’inizio del prompt rende riutilizzabile una porzione maggiore di quel prefill.

Le applicazioni dovrebbero quindi evitare di inserire dati variabili all’inizio di un prefisso altrimenti stabile quando le stesse informazioni possono essere collocate più avanti.

La capacità della cache e l’espulsione definiscono i limiti del server domestico

I blocchi KV consumano memoria, quindi il server non può conservare ogni prefisso per sempre. Conversazioni simultanee, contesti lunghi e più modelli competono per lo stesso pool di memoria e possono espellere gli stati riutilizzabili meno recenti.

La spiegazione di ZimaSpace sul caching dei modelli e sulla latenza delle risposte a caldo illustra la gerarchia complessiva delle cache. Il caching dei prefissi è solo un livello e non deve essere confuso con la permanenza dei pesi del modello in memoria.

Misura la percentuale di riscontri positivi nella cache, il numero di token riutilizzati, il tempo al primo token, il throughput di prefill, l’uso della memoria KV e il tasso di espulsione al reale livello di concorrenza domestica.

La documentazione NVIDIA di TensorRT-LLM descrive il riutilizzo della cache KV come un’ottimizzazione del servizio con lo stesso limite fondamentale: lo stato riutilizzabile è utile solo finché i blocchi corrispondenti rimangono disponibili.