Guadagni:
- Spiegare la logica di corrispondenza del prefisso della memorizzazione nella cache del prompt
- Aumenta l'utilizzo della cache inserendo prima il contesto fisso e poi quello variabile
- Può calcolare gli aspetti economici di scrittura/lettura della cache e il punto di pareggio
Un prodotto LLM sembra economico nel prototipo; Quando si sale sulla bilancia, il conto sorprende. Nella maggior parte dei carichi di lavoro, la maggior parte della fattura proviene dallo stesso contesto fisso che viene inviato più e più volte con ogni richiesta: un lungo prompt di sistema, un regolamento, documentazione di riferimento. La memorizzazione nella cache immediata elimina esattamente questo spreco. In questa unità imparerai come funziona la cache, come organizzare il prompt per colpire e come calcolare il punto di pareggio dell'economia della cache. Se installato correttamente, da solo può dimezzare o addirittura ridurre la bolletta.
Come funziona la cache? L'unica regola immutabile
La memorizzazione nella cache della richiesta è una corrispondenza del prefisso. Il provider memorizza temporaneamente i token che ha elaborato dall'inizio della richiesta. Se alla richiesta successiva il prompt inizia con lo stesso prefisso, questa parte comune non viene ricalcolata; È molto più economico leggere che memorizzare nella cache.
Da ciò segue una regola immutabile: se un singolo byte cambia in un punto qualsiasi del prefisso, l'intera cache diventa non valida da quel punto in poi. Cioè, il contenuto fisso dovrebbe essere all'inizio e il contenuto variabile alla fine. Se metti una riga all'inizio del prompt di sistema che cambia ad ogni richiesta, come "Data di oggi: 18.07.2026", tutto ciò che sta dietro non potrà entrare nella cache.
L'ordine di elaborazione è solitamente: strumenti → prompt di sistema → messaggi. Metti il punto cache (punto di interruzione) alla fine della sezione fissa.
Economia della cache
La cache ha tre fasce di prezzo:
- Scrittura cache: memorizzazione per la prima volta. ~1,25 volte il prezzo di input normale (per 5 minuti di archiviazione).
- Lettura cache: lettura su richieste successive. ~0,1 volte il normale prezzo di input, ovvero un decimo.
- Input normale: la parte che non entra nella cache e viene elaborata ogni volta a costo pieno.
Punto di pareggio: la prima richiesta paga il premio di scrittura (1,25×). Dalla seconda richiesta entra in gioco la lettura (0,1×). Approssimativamente, sarai testa a testa su due richieste; Dopodiché si tratta di un risparmio netto. Quanto più ampio è il contesto fisso e quante più richieste viene riutilizzato, tanto maggiore diventa il guadagno.
Scenario
La cache funziona?
Ampio prompt di sistema fisso, migliaia di richieste
Sì, i guadagni più alti
Molte domande sugli stessi documenti di riferimento
Sì
Breve testo completamente diverso per ogni richiesta
No, il bonus di scrittura è sprecato
Richiesta una tantum
No, nessuna lettura
Data/ID modificabile ad ogni richiesta al prompt del sistema
No: il prefisso è interrotto, il risultato è zero
Passo dopo passo: come impostare una richiesta di successo?
- Separare costante e variabile. Quali contenuti non cambiano mai (prompt di sistema, regolamento, documentazione)? Cosa cambia con ogni richiesta (domanda utente, data, ID)?
- Metti la costante all'inizio. Durante la lavorazione la parte che viene prima (utensili, sistema) deve essere stabile.
- Metti la variabile alla fine. La domanda attuale dell'utente, ultima.
- Posiziona il cartello alla fine del confine. Metti il punto cache nell'ultimo blocco della parte fissa.
- Verifica il successo. Controlla se cache_read_input_tokens è maggiore di zero nel campo di utilizzo nella risposta. Se zero, c'è un disgregatore nascosto nel prefisso.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "effimero" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}
Suggerimento: non indovinare i riscontri nella cache, misurali. Se using.cache_read_input_tokens è ancora zero su richieste consecutive, è in esecuzione un interruttore silenzioso (datetime.now() al prompt del sistema, JSON non ordinato, elenco di strumenti che cambiano con ogni richiesta). Confronta il prompt grezzo delle due richieste byte per byte e trova la differenza.
Disturbatori silenziosi
Pattern tipici che corrompono inconsapevolmente la cache:
# BREAKER: incorpora informazioni nel prompt di sistema che cambiano ad ogni richiesta "Data di oggi: {{now}}. Sei un assistente..." ← il prefisso cambia ad ogni richiesta, il risultato è zero# TRUE: sposta la variabile nel sistema di messaggi: "Sei un assistente..." ← la costante inserisce i messaggi della cache: [{role: user, content: "Oggi è {{now}}. Domanda: ..."}] ← variabile alla fine
Altri interruttori: JSON ordinato in modo diverso su ogni richiesta (mantieni le chiavi in ordine fisso), elenco di strumenti che variano in base all'utente (gli strumenti vengono elaborati per primi; nulla va nella cache se cambiano), modifica del modello durante la conversazione (le cache sono specifiche del modello).
Prompt debole/Prompt forte (struttura adatta alla cache)
# Sistema DEBOLE (build di busting della cache): "Data: 18.07.2026 14:32. Utente: Ahmet (id 8842). Sei un bot di supporto. Regole: ...(2000 token)..."
# Sistema FORTE (struttura cache-friendly): "Sei un bot di supporto. Regole: ...(2000 token, non cambia mai)..." [cache sign]messages: [ { role: user, content: "Data: 18.07.2026 14:32. ID utente: 8842. Domanda: come posso avviare il mio rimborso?" }]
Nella versione debole, il blocco di regole di 2000 token viene elaborato a costo pieno su ogni richiesta. Nella versione strong, lo stesso blocco viene scritto una volta e letto su tutte le richieste successive per un decimo del prezzo.
Tre mini custodie
Caso 1: memorizzazione nella cache del regolamento. Un'automazione contabile aggiungeva il regolamento di 12.000 token a ciascuna fattura; 5.000 richieste al giorno. L'input senza cache costa circa $ 180 al giorno. Hanno mantenuto costante il regolamento e lo hanno memorizzato nella cache: le prime richieste pagavano un premio di scrittura, le letture successive 0,1×. Il costo di acquisto è sceso del 90% circa, arrivando a circa 18 dollari al giorno.
Caso 2: costo della linea della data nascosta. Una squadra ha creato una cache ma non ha ottenuto risultati; cache_read_input_tokens era sempre zero. Motivo: c'era datetime.now() nella prima riga del prompt del sistema, il prefisso cambiava ad ogni richiesta. Quando abbiamo spostato la data nel messaggio dell'utente, la percentuale di successo è aumentata improvvisamente dallo 0% al 94%.
Caso 3: cache smarrita. Un'applicazione di ricerca inviava brevi query completamente diverse con ciascuna richiesta; Hanno aggiunto con entusiasmo un segno di cache. Senza un prefisso comune, ogni richiesta pagava solo un premio di scrittura, nessuna lettura, aumentando il costo. Hanno tolto il cartello. Lezione: la cache paga solo se c'è un prefisso ampio e costante che viene riutilizzato.
Errori comuni
- Miscelazione di costante e variabile: quando il contenuto della variabile è nel prefisso, l'hit viene ripristinato.
- Incorporamento di data/ID nel prompt di sistema: il disturbatore silenzioso più comune.
- Non misurare l'hit: se cache_read_input_tokens non è selezionato, gli sprechi non verranno notati.
- Aggiunta di cache quando non è presente un prefisso pubblico: paghi solo il premio di scrittura, il costo aumenta.
- Modifica dell'elenco dei veicoli o del modello: il prefisso è rotto dall'inizio; tutto viene riscritto.
- Dimenticare la dimensione minima della cache: le cache molto brevi (meno di ~ 1–4k token a seconda del modello) non entreranno nella cache in modo silenzioso.
Approfondimento: progettazione della cache in base al tipo di carico di lavoro
Il rendimento effettivo della memorizzazione nella cache varia a seconda della natura del carico di lavoro; quindi conosci prima il tuo traffico. Tre modelli tipici e installazione corretta:
Prompt di sistema comune, domande diverse. Modello aziendale più comune: un ampio prompt di sistema (ruolo, regole, magari un documento di riferimento) con centinaia di diverse domande degli utenti. Qui la parte fissa (sistema) viene inizialmente memorizzata nella cache; ogni nuova domanda paga il prezzo intero solo per la sua piccola parte. Il guadagno è altissimo perché la gran parte viene recitata ripetutamente ad un decimo del prezzo.
Monologo a più giri. Man mano che la conversazione si trascina, ogni nuovo round si basa su tutta la storia precedente. Se metti il flag della cache alla fine dell'ultimo round, ogni richiesta riutilizza il prefisso della conversazione precedente; i risultati si accumulano man mano che la conversazione cresce. Ciò riduce drasticamente il costo delle lunghe sessioni di assistente.
Il prefisso condiviso è l'ultimo bit da cambiare. Richieste multiple condividono un ampio insieme di priorità fisse (set di campioni, istruzioni) ma sono separate da un'unica domanda alla fine. Metti il puntatore della cache alla fine della parte condivisa; Altrimenti, ogni richiesta scriverebbe la propria cache separata e nessuna di essa verrebbe letta.
Un avvertimento: la cache dipende dal modello e da una certa dimensione minima. Prefissi molto piccoli (meno di qualche migliaio di token, a seconda del modello) non entreranno silenziosamente nella cache anche se li contrassegni: cache_creation_input_tokens rimane zero. Inoltre, la modifica del modello nel corso della conversazione invalida l'intera cache; Se un'attività diversa richiede un modello economico, mantieni il flusso principale in un modello e inserisci il lavoro secondario in una chiamata separata.
In sintesi
La memorizzazione nella cache dei prompt è una corrispondenza del prefisso: il contenuto fisso dovrebbe essere all'inizio, il contenuto variabile dovrebbe essere alla fine. Per un contesto ampio e riutilizzato, il costo di lettura è un decimo del prezzo intero, più o meno in pareggio in due richieste. L'errore più comune è corrompere il prefisso incorporando dati variabili nel prompt del sistema; Si verifica l'hit misurandolo nel campo di utilizzo.
Compito dell'applicazione
Scegli un carico di lavoro. (1) Dividere il contenuto in due colonne: "non cambia mai" e "cambia ad ogni richiesta". (2) Ridisegnare la struttura del prompt, mettendo la parte costante all'inizio e la parte variabile alla fine. (3) Stimare la dimensione del token della parte fissa e confrontare il costo mensile con/senza cache. (4) Annota da quale campo (cache_read_input_tokens) verificherai l'hit.
lista di controllo
- [ ] Posso spiegare che la cache è la corrispondenza del prefisso e l'unica regola immutabile.
- [ ] Posso aumentare la precisione inserendo il contenuto fisso all'inizio e la variabile alla fine.
- [] Conosco scrivere/leggere economia e il punto di pareggio a due richieste.
- [ ] Riconosco i perturbatori silenziosi (data, JSON non ordinato, elenco dei veicoli che cambia).
- [] Posso verificare l'hit con using.cache_read_input_tokens.