Amazon spiega il routing "prefix-aware" per ridurre la latenza delle LLM

Amazon mostra come ridurre la latenza delle LLM su SageMaker Inference riusando il calcolo sui prefissi ripetuti dei prompt¹.

Un prompt tipico ha due parti. Una parte fissa con contesto: istruzioni, documenti di riferimento, cronologia della conversazione. Una parte variabile con l’input dell’utente. Il blog porta l’esempio di un bot per l’assistenza clienti. Ogni richiesta apre con lo stesso testo: “You are a support agent for AnyCompany. Here are our policies…” e poi arriva la domanda del cliente. Le istruzioni iniziali possono arrivare a 3.000 token. La domanda può essere di 50 token. Questo schema si ripete su centinaia o migliaia di richieste: il modello rilegge lo stesso inizio di 3.000 token ogni volta¹.

Ricalcolare quel blocco fisso a ogni chiamata aggiunge attesa inutile. La soluzione proposta è sfruttare i prefissi già visti. Quando il sistema riconosce lo stesso inizio, può evitare lavoro ripetuto. L’effetto è una riduzione del time-to-first-token, la fase che l’utente percepisce di più perché segna l’avvio della risposta¹.

I framework di serving per LLM hanno già strumenti per questo. vLLM e TensorRT-LLM implementano il caching del prefisso. Conservano le coppie chiave-valore (KV) calcolate per i prompt con quella stessa apertura. Se arriva una nuova richiesta con lo stesso inizio, il modello non riparte da zero: riusa la cache e processa solo i token nuovi in coda. Questa tecnica si chiama prefix caching e può ridurre il time-to-first-token¹.

L’esempio operativo chiarisce il perché. Nel bot di supporto, ogni chiamata include lo stesso blocco di istruzioni e policy: “You are a support agent for AnyCompany. Here are our policies…”. Cambia la domanda del cliente in fondo, che può essere breve. Senza cache, il modello ricalcola migliaia di token identici su ogni richiesta. Con la cache del prefisso, salta quel lavoro e si concentra sui pochi token variabili¹.

Il meccanismo dipende dalla ripetizione del contesto. Più richieste condividono lo stesso inizio, più opportunità di riuso esistono. Nei casi in cui il prefisso domina la lunghezza del prompt, come nell’esempio da 3.000 contro 50 token, l’impatto sulla latenza è concreto perché il modello evita gran parte del calcolo iniziale a ogni nuova richiesta¹.

Il principio non cambia la parte variabile. I token nuovi vanno comunque elaborati. Il guadagno arriva dall’aver già svolto il lavoro comune, e dal poterlo richiamare quando ricompare lo stesso inizio. La riduzione tocca soprattutto il tempo che intercorre tra l’invio della richiesta e la comparsa del primo token di risposta¹.

Il post inquadra questa ottimizzazione come “prefix-aware” nell’ambito di SageMaker Inference. Il punto centrale è riconoscere quando i prompt condividono l’apertura, e sfruttare la cache del prefisso per evitare ricalcoli ripetuti. I framework citati dimostrano che la strada è praticabile con strumenti già noti nel serving di LLM¹.