Memorizzare nella cache i prefissi lunghi

Ogni prompt lungo paga un costo di prefill per codificare i propri token prima della generazione. Quando lo stesso prefisso lungo si ripete in molte chiamate, ad esempio un prompt di sistema, una specifica degli strumenti o un ampio documento di riferimento, il caching del prompt consente al provider di riutilizzare lo stato dell'attenzione già calcolato invece di ricalcolarlo.

• I cache hit riducono drasticamente la latenza e i costi di input.
• Il risparmio aumenta con la dimensione del prefisso e la frequenza di riutilizzo.

Le cache si basano su una corrispondenza esatta del prefisso di token dall'inizio del prompt. L'intervallo memorizzato nella cache va dall'inizio fino al primo punto di divergenza. Se modifica qualcosa all'inizio, tutto ciò che segue non può utilizzare la cache.

Conseguenza: il layout che massimizza i cache hit mette prima i contenuti più stabili e per ultimi quelli più variabili.

Disponga i contenuti dal più stabile al meno stabile: regole di sistema immutabili e definizioni degli strumenti, quindi ampio materiale di riferimento stabile, poi contesto stabile per la sessione e infine l'input e la domanda variabili della singola richiesta.

• Stabile -> in testa (memorizzabile nella cache).
• Variabile -> in coda (l'unica parte da ricalcolare).

Questo singolo principio di ordinamento determina la maggior parte dei vantaggi del caching.

Alcuni provider consentono di contrassegnare punti di interruzione espliciti per la cache. Li posizioni alla fine di ogni segmento stabile, così il sistema può memorizzare nella cache tutto fino a quel punto. Contrassegni come memorizzabile nella cache il blocco stabile più grande, cioè il corpus di riferimento o il lungo prompt di sistema.

In assenza di marcatori espliciti, organizzi comunque la struttura secondo l'ordine di stabilità, così la corrispondenza implicita del prefisso potrà essere d'aiuto.

Variazioni sottili e involontarie interrompono silenziosamente il caching: un timestamp nel prompt di sistema, un ID per richiesta inserito all'inizio, definizioni degli strumenti riordinate o un ordine non deterministico delle chiavi JSON. Ognuna sposta il prefisso e forza un ricalcolo completo.

Verifichi il prefisso alla ricerca di qualsiasi elemento che varia tra una chiamata e l'altra e lo sposti dopo la regione memorizzata nella cache.

Le cache scadono dopo un time-to-live definito dal provider, spesso rinnovato a ogni hit. I cold miss si ripresentano se le chiamate sono troppo diradate. Per carichi di lavoro a raffiche e ad alta frequenza, il caching è vantaggioso; per chiamate rare e sporadiche, la cache può scadere tra un utilizzo e l’altro.

Adatti il pattern del traffico al TTL e valuti dei ping keep-alive per i prefissi importanti.

Il caching comporta in genere un piccolo sovrapprezzo per scrivere una voce nella cache e uno sconto consistente per leggerla. Dal punto di vista economico, il riutilizzo è vantaggioso: una scrittura ammortizzata su molte letture produce un grande risparmio netto; un utilizzo singolo che comporta solo una scrittura può costare leggermente di più.

• Riutilizzo elevato -> applichi il caching in modo aggressivo.
• Prefissi usati una sola volta -> il caching potrebbe non essere conveniente.

Renda deterministici e con versione fissata il prompt di sistema e le specifiche degli strumenti. Ordini le definizioni degli strumenti in modo canonico, eviti di incorporare dati dinamici e li modifichi solo in occasione di release deliberate. Un blocco di sistema stabile diventa una voce della cache longeva e con alta probabilità di hit, condivisa da tutte le richieste.

Tratti il prefisso memorizzato nella cache come un artefatto con una versione, non come una stringa da modificare con leggerezza.

Nei cicli degli agenti, la conversazione in crescita è una cache naturale: ogni turno estende un prefisso che il turno successivo riutilizza. Aggiunga i nuovi turni in coda e non riscriva mai quelli precedenti, così la cache precedente rimane valida.

Quando deve compattare, lo faccia in modo da creare un nuovo prefisso stabile per i turni successivi, invece di modificare ripetutamente quelli vecchi.

Strumenti il sistema. La maggior parte dei provider indica i token di input memorizzati nella cache e quelli non memorizzati per ogni chiamata. Tenga traccia dell'hit rate e, se è basso, esamini il prefisso per individuare eventuali variazioni. Una regressione dell'hit rate di solito indica un valore dinamico introdotto recentemente nelle prime posizioni del prompt.

• Registri cached_tokens / total_input_tokens.
• Generi un avviso quando l'hit rate diminuisce dopo un deploy.

Per controllare i costi sui prefissi lunghi: ordini i contenuti in base alla stabilità, contrassegni il blocco stabile più grande come cache breakpoint, elimini le variazioni nascoste, fissi e assegni una versione ai blocchi di sistema e degli strumenti, usi un approccio append-only nei cicli degli agenti e monitori l'hit rate. L'obiettivo è un unico prefisso grande e riutilizzabile, più una piccola coda volatile ricalcolata a ogni chiamata.

Il prompt caching riutilizza il prefill di un prefisso esatto e stabile, riducendo drasticamente latenza e costi di input quando il riutilizzo è frequente. Ordini i contenuti partendo da quelli più stabili, contrassegni il grande blocco stabile come cache breakpoint e sposti tutta la variabilità in coda. Elimini le variazioni nascoste, fissi le versioni dei blocchi di sistema e degli strumenti, usi un approccio append-only nei cicli degli agenti e monitori l'hit rate, così una regressione segnala un valore variabile introdotto recentemente nelle prime posizioni.