Amazon presenta un tiered KV cache per LLM su SageMaker HyperPod

Amazon descrive un “tiered KV cache” per l’inferenza di modelli linguistici su SageMaker HyperPod, realizzato con Curvine, per ridurre il compromesso tra istanze GPU sovradimensionate e tempo-to-first-token lento¹.

Il post parte da un punto preciso. In generazione, vLLM memorizza le chiavi e i valori di attenzione di ogni token già processato in una KV cache. Così evita di ricalcolarli a ogni step¹. La prefix caching estende l’idea: riusa quella cache tra richieste che condividono gli stessi token iniziali, per esempio un prompt di sistema comune¹. Se la cache non c’è o non basta, le richieste con prompt identici vengono ricalcolate ogni volta e il tempo-to-first-token peggiora¹.

Il compromesso operativo è netto. O si pagano istanze GPU più grandi per ospitare una KV cache che cresce con la generazione, oppure si accetta una latenza iniziale più alta dovuta al ricalcolo di prefissi ripetuti¹. Per chi distribuisce un catalogo ampio di modelli di base pubblici su più endpoint, o integra RAG, o gestisce dialoghi multi-turn, questo compromesso impatta costi e qualità d’uso¹.

Il post elenca casi d’uso. Cataloghi di modelli pubblici come Qwen, Llama, DeepSeek, esposti su endpoint per singola linea di business. Pipeline di Retrieval Augmented Generation. Applicazioni di dialogo multi-turn. Qui i prefissi ricorrono spesso e la prefix caching può evitare ricalcoli inutili quando lo spazio di cache lo consente¹.

C’è anche un riferimento all’infrastruttura. Su istanze considerate più efficienti in termini di costo, come ml.g6e.4xlarge con 48 GB per GPU, dopo i pesi del modello e le allocazioni di runtime, la discussione si concentra su quanta memoria resti per la prefix caching¹. Se lo spazio è insufficiente e la cache dei prefissi non persiste, vLLM ricalcola e il tempo-to-first-token sale¹.

Qui si inserisce il “tiered KV cache”. L’obiettivo dichiarato è ridurre il compromesso tra costo dell’infrastruttura e prestazioni percepite, riusando i prefissi comuni senza dover ricorrere sempre a GPU più capienti o accettare ricalcoli frequenti¹. Il meccanismo mira a estendere i benefici della prefix caching anche quando la memoria GPU disponibile per la cache è limitata, collocando parte dello stato su livelli diversi¹.

Il messaggio si rivolge a team che gestiscono molti endpoint e modelli, con prefissi ripetuti tra richieste. In questi contesti, la possibilità di riusare i prefissi riduce ricalcoli e incide sul tempo-to-first-token, soprattutto quando le stesse sequenze iniziali si presentano spesso tra richieste vicine¹.

La chiusura del post mette l’accento su un fatto pratico: nei flussi con prefissi condivisi, come un prompt di sistema comune, la combinazione tra vLLM, prefix caching e una KV cache a livelli può attenuare il costo del ricalcolo senza cambiare i prompt ricorrenti né la struttura dei flussi. Questo vale in particolare dove coesistono più modelli pubblici esposti per linea di business, pipeline RAG e dialoghi multi-turn, che ripropongono gli stessi inizi di sequenza e traggono beneficio dal riuso della cache¹.