Guida al Prompt Caching di GPT-6 Astra: Come Ridurre i Costi di Contesto Ripetuto
Scopri come funziona la cache dei prompt di GPT-6 Astra, come strutturare prefissi riutilizzabili, posizionare punti di interruzione della cache, misurare i successi ed evitare costosi fallimenti della cache.

I prompt di agenti di grandi dimensioni spesso ripetono le stesse policy di sistema, definizioni di strumenti, documentazione di prodotto, esempi e cronologia delle conversazioni. Re-inviare quel materiale è talvolta inevitabile; pagare il costo completo di input e la latenza per un prefisso identico non lo è. GPT-6 Astra supporta la memorizzazione nella cache dei prompt nell'API Responses, in modo che i prefissi ripetuti possano essere riutilizzati.
La memorizzazione nella cache è un'ottimizzazione, non una memoria. Non fa sì che un modello ricordi un cliente tra una richiesta e l'altra, e non cambia ciò che il modello vede. La richiesta necessita comunque dell'input pertinente. La differenza è che un prefisso identico e idoneo può essere servito dalla cache a una tariffa di input memorizzato inferiore.
Cosa memorizza nella cache GPT-6 Astra
La cache è basata su prefisso. OpenAI può riutilizzare i token dall'inizio di un prompt quando la richiesta successiva inizia con contenuti corrispondenti. Un modello mentale utile è un documento i cui capitoli stabili vengono prima e il cui appendice specifico della richiesta viene per ultimo.
Metti questi vicino al davanti:
- istruzioni di sviluppo stabili;
- schemi di strumenti in un ordine stabile;
- documenti di riferimento lunghi utilizzati in più richieste;
- esempi canonici e regole di output.
Metti questi verso la fine:
- il messaggio corrente dell'utente;
- timestamp, ID richiesta e stato temporaneo;
- passaggi recuperati che cambiano a ogni chiamata;
- preferenze per utente che non sono condivise.
Un timestamp inserito vicino all'inizio può invalidare tutto ciò che lo segue. Allo stesso modo, generare array di strumenti da una mappa non ordinata può produrre prefissi semanticamente identici ma diversi a livello di byte. Costruisci i prompt in modo deterministico.
Caching implicito ed esplicito
GPT-5.6 e i modelli successivi espongono prompt_cache_options. In modalità implicita, il servizio identifica automaticamente un punto di interruzione riutilizzabile. Questo è il punto di partenza più semplice ed è adatto quando il tuo prompt ha un prefisso grande e stabile.
OUTPUT SOLO TRADUZIONE:
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-6-astra",
prompt_cache_key: "support-agent:v4",
prompt_cache_options: { mode: "implicit", ttl: "30m" },
input: [
{ role: "developer", content: "Politica stabile e istruzioni operative..." },
{ role: "user", content: "Perché la mia fattura è stata duplicata?" }
]
});
Il valore TTL attualmente documentato è 30m e 30 minuti è il valore predefinito. Non progettare in base a durate non documentate. OpenAI segna anche il campo più vecchio prompt_cache_retention come deprecato.
La modalità esplicita dà all'applicazione un maggiore controllo. Aggiungi elementi di contenuto prompt_cache_breakpoint ai confini che vale la pena preservare. Questo è utile quando un prompt viene assemblato da diversi blocchi stabili seguiti da materiale volatile. Una richiesta può scrivere al massimo quattro breakpoint, e il servizio considera fino agli ultimi 80 breakpoint. Più breakpoint non sono automaticamente migliori: ogni scrittura ha un costo, e i prefissi frammentati possono essere più difficili da ragionare.
Un'architettura pratica di prefisso
Per un agente di produzione, utilizza quattro livelli:
1. Identità e sicurezza
Metti per primo il ruolo durevole, i vincoli di sicurezza e il contratto di risposta. Versiona questo blocco deliberatamente. Una modifica alle policy dovrebbe creare una nuova chiave cache invece di mescolare silenziosamente misurazioni di due versioni.
2. Definizioni degli strumenti
Gli schemi degli strumenti sono spesso grandi e ripetuti. Mantieni stabili nomi, descrizioni, proprietà e ordinamento. Rimuovi gli strumenti inutilizzati quando possibile; questo riduce sia il contesto non memorizzato nella cache che quello memorizzato, e diminuisce l'ambiguità nella selezione degli strumenti.
3. Conoscenza condivisa
Aggiungi manuali durevoli, tassonomie, guide di stile o documentazione di prodotto. Se la conoscenza cambia frequentemente, la ricerca nei file potrebbe essere migliore rispetto a incorporarla tutta in ogni prompt. Metti in cache la conoscenza operativa stabile; recupera i fatti che cambiano.
4. Stato della richiesta dinamico
Aggiungi input utente, record correnti, risultati di ricerca in tempo reale e stato temporaneo. Questa collocazione protegge il prefisso riutilizzabile da modifiche di routine.
Per un flusso di lavoro creativo, lo strato stabile potrebbe contenere regole di produzione di animazione e uno stile della casa, mentre la coda dinamica contiene la scena corrente. Una piattaforma come Elser AI potrebbe applicare lo stesso principio a un contesto ripetuto di story-bible o di coerenza dei personaggi senza implicare che la cache stessa crei coerenza.
Misura i risparmi invece di darli per scontati
Ispeziona usage.input_tokens_details.cached_tokens e cache_write_tokens. Un numero elevato di token in cache indica che parte del prefisso è stata riutilizzata. I token di scrittura della cache rivelano il costo della creazione o dell'aggiornamento delle voci.
Per GPT-6 Astra, i prezzi del modello pubblicati alla data di verifica elencano l'input in cache al di sotto dell'input normale e le scritture in cache al di sopra dell'input normale. Questo crea una questione di pareggio: un prefisso riutilizzato ripetutamente può far risparmiare denaro; un prefisso scritto una volta e mai riutilizzato può costare di più. I prezzi cambiano, quindi calcola con la pagina del modello corrente piuttosto che codificare numeri fissi nei fogli di pianificazione.
Traccia almeno:
- tasso di hit della cache per versione del prompt;
- token di input memorizzati nella cache, scritti e totali;
- tempo p50 e p95 per il primo token;
- costo per attività completata, non semplicemente per richiesta;
- cache miss causati dai rilasci.
Una dashboard raggruppata solo per modello nasconde la causa dei miss. Includi una chiave di cache o una dimensione di versione del prompt nella tua telemetria, ma non inserire mai dati personali o segreti nelle chiavi di cache.
Sette cause comuni di cache-miss
Il contenuto dinamico appare troppo presto
Sposta le date, gli ID utente e il materiale recuperato dopo il contenuto riutilizzabile.
L'ordine degli schemi degli strumenti cambia
Ordina gli strumenti e le proprietà dello schema in modo deterministico durante la fase di build dell'applicazione.
I prompt sono "equivalenti" ma non identici
Spazi bianchi, esempi o serializzazione possono differire. Genera blocchi condivisi da artefatti con versione piuttosto che da stringhe ad hoc.
Il prefisso è troppo breve
La lunghezza minima memorizzabile varia a seconda del modello. I prompt molto brevi potrebbero non trarre beneficio. Conferma tramite i dati di utilizzo.
La compattazione ha cambiato il prefisso
La compattazione aiuta a contenere conversazioni lunghe, ma produce una diversa rappresentazione del contesto. Aspettati che i pattern di riutilizzo cambino dopo la compattazione e misura intorno ai confini delle milestone.
Troppi punti di interruzione di basso valore
I punti di interruzione dovrebbero corrispondere a livelli significativi e riutilizzabili. Quattro scritture consentite sono un tetto massimo, non un obiettivo.
Una chiave cache è troppo ampia o troppo ristretta
Una chiave per ogni flusso di lavoro non correlato produce un raggruppamento debole; una chiave univoca per richiesta impedisce il riutilizzo. Preferisci una chiave semantica come legal-review:v3:us.
Un piano di rollout sicuro
Inizia con la modalità implicita su un flusso di lavoro ad alto volume. Stabilizza la costruzione del prompt, registra i dettagli dei token e confronta due settimane di costi e latenza. Poi considera punti di interruzione espliciti se il prompt ha più livelli riutilizzabili o code dinamiche frequenti. Valuta la qualità insieme ai risparmi: la rimozione aggressiva del contesto non è caching e potrebbe ridurre la qualità delle risposte.
Memorizza nella cache solo contenuti che ti è già consentito inviare all'API. La memorizzazione nella cache non sostituisce la classificazione dei dati, l'isolamento dei tenant, i controlli di accesso o le decisioni di conservazione. Tieni i segreti fuori dai prompt quando uno strumento può recuperarli just-in-time.
FAQ
La memorizzazione nella cache dei prompt riduce il costo dei token di output?
No. Si applica agli input ripetuti idonei. L'output viene generato normalmente e fatturato alla tariffa di output.
previous_response_id rende gratuiti i turni precedenti?
No. OpenAI afferma che i token di input precedenti in una catena di risposta vengono comunque fatturati come input. La memorizzazione nella cache delle richieste può ridurre il costo dei prefissi ripetuti ammissibili, ma il concatenamento delle conversazioni e la memorizzazione nella cache sono meccanismi separati.
Dovrei memorizzare nella cache i risultati di ricerca recuperati?
Solo quando sono stabili e realmente riutilizzati. I risultati live appartengono normalmente alla coda dinamica. Per corpora controllati, la ricerca nei file può evitare di incorporare un'intera collezione in ogni prompt.
Posso fare affidamento su un cache hit?
Tratta la cache come un'ottimizzazione opportunistica. La tua applicazione deve rimanere corretta in caso di miss.
Conclusione
La strategia di caching GPT-6 Astra di maggior valore è architetturale: istruzioni e strumenti stabili per primi, stato volatile per ultimo, serializzazione deterministica, versionamento deliberato e misurazione tramite dettagli dei token. Inizia con caching implicito, aggiungi punti di interruzione espliciti solo quando i dati li supportano e ottimizza il costo per attività riuscita anziché inseguire un e





























































































