Come progettare prompt LLM compatibili con la cache su OpenAI, Anthropic e Gemini

La memorizzazione nella cache delle richieste è utile solo quando gli stessi token vengono riutilizzati nel posto giusto, per un periodo sufficientemente lungo e secondo la semantica del provider che stai effettivamente chiamando. I team spesso perdono il vantaggio perché trattano la memorizzazione nella cache come una funzionalità del modello anziché un problema di architettura della richiesta. Inseriscono timestamp nella parte superiore di ogni prompt, interlacciano i risultati di recupero specifici della richiesta con schemi di strumenti riutilizzabili o ottimizzano per un provider aumentando silenziosamente i costi su un altro.

La soluzione pratica è rendere la memorizzazione nella cache dei prompt parte del compilatore delle richieste del gateway. Il gateway dovrebbe separare il materiale di richiesta stabile dal materiale di richiesta volatile, compilare istruzioni di cache specifiche del provider e misurare costi e latenza in base al prefisso memorizzabile nella cache. Ciò è particolarmente importante in un ambiente multi-modello, dove OpenAI, Anthropic e Gemini espongono comportamenti di memorizzazione nella cache, campi contabili, TTL e costi di configurazione diversi.

Inizia con l'unità memorizzabile nella cache, non con il provider

L'unità riutilizzabile di solito non è l'intero prompt. È un prefisso o un oggetto di contesto costituito da materiale prompt condiviso da molte richieste. In un LLM aziendale di produzione API, tale materiale spesso include criteri della piattaforma, criteri dell'organizzazione, istruzioni per l'applicazione, definizioni degli strumenti, regole del formato di risposta, istruzioni dell'agente di codifica o indicazioni sul corpus statico.

La parte volatile è il materiale che cambia in base alla richiesta: attività corrente dell'utente, ID richiesta, timestamp, coda della conversazione, passaggi RAG appena recuperati, dati specifici dell'account e strumento una tantum risultati. Se il contenuto volatile viene visualizzato prima del contenuto stabile, può interrompere il riutilizzo del prefisso o forzare il provider a considerare un prompt di grandi dimensioni come nuovo.

Fatto: le implementazioni del provider differiscono. OpenAI documenti richiedono la memorizzazione nella cache come riutilizzo di un prefisso condiviso, con contabilità dei token memorizzati nella cache. Il suo articolo pubblico sulla memorizzazione nella cache dei prompt afferma che la memorizzazione nella cache automatica inizia con un prefisso di 1.024 token e cresce con incrementi di 128 token e che le voci della cache vengono in genere cancellate dopo 5-10 minuti di inattività ed entro un'ora dall'ultimo utilizzo. Anthropic documenta i punti di interruzione della cache espliciti e consiglia di posizionare cache_control sull'ultimo blocco condiviso, come i prompt di sistema o le definizioni degli strumenti. Gemini documenta la memorizzazione nella cache del contesto come funzionalità a pagamento con conteggi di token memorizzati nella cache restituiti nei metadati di utilizzo per le operazioni di cache e le chiamate di generazione che utilizzano una cache.

Raccomandazione: progetta la tua rappresentazione interna del prompt in base a blocchi stabili e volatili prima di mappare qualsiasi cosa alle API del provider.

Compila le richieste dal più stabile al più volatile

A il compilatore di richieste in grado di riconoscere la cache dovrebbe ordinare il materiale in modo che la sezione riutilizzabile più grande venga visualizzata prima della sezione specifica della richiesta. Un ordine predefinito pratico è:

1. Norme sulla sicurezza e sulla conformità della piattaforma.
2. Politiche dell'organizzazione o del tenant.
3. Ruolo dell'applicazione e istruzioni sulle attività.
4. Schemi degli strumenti e regole di utilizzo degli strumenti.
5. Conoscenza statica o materiale di riferimento di lunga durata.
6. Cronologia delle conversazioni che viene riutilizzato tra i turni.
7. Passaggi recuperati o altro contesto specifico della richiesta.
8. L'attività utente corrente.
9. Metadati effimeri necessari solo per questa chiamata.

Questo ordine non è una verità universale. Alcuni fornitori o modelli potrebbero rispondere in modo diverso allo spostamento delle istruzioni. La priorità politica e la qualità comportamentale continuano ad avere importanza.Tratta l'ordinamento in grado di riconoscere la cache come una modifica controllata: esegui test di regressione del prompt prima e dopo la modifica del layout.

Esempio di blocchi di prompt interni

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

Il compilatore può eseguire l'hashing del prefisso stabile dopo averlo renderizzato. L'hash diventa la chiave di unione per l'analisi della cache: modello, tenant, applicazione, hash del prefisso memorizzabile nella cache, versione del prompt, scelta TTL, token di input non memorizzati nella cache, token di input memorizzati nella cache, token di scrittura nella cache ove disponibili, token di output, latenza e costo finale.

Utilizza adattatori del provider anziché un presupposto della cache

Un singolo flag "abilita cache" è troppo vago per le operazioni multi-provider. Il gateway deve esporre una policy della cache interna e compilarla in un comportamento specifico del provider.

OpenAI Adattatore

Per OpenAI, ottimizza per prefissi condivisi ripetuti e contabilità dell'utilizzo. Il compilatore della richiesta dovrebbe mantenere il materiale stabile in primo piano ed evitare piccole differenze all'interno del primo intervallo memorizzabile nella cache. Tieni traccia dei token di input memorizzati nella cache dai campi di utilizzo del provider. Se disponibile, tieni traccia anche dei token di scrittura nella cache in modo che il registro dei costi possa confrontare la creazione e il riutilizzo della cache.

Poiché la memorizzazione nella cache è orientata al prefisso, l'importante attività operativa è prevenire la deriva del prefisso. Due prompt che sembrano uguali agli esseri umani possono differire perché un timestamp, un ID build, un ordine casuale degli strumenti o una personalizzazione del tenant è stato visualizzato nella parte superiore.

Anthropic Adattatore

Per Anthropic, compila punti di interruzione della cache espliciti. Posiziona cache_control sull'ultimo blocco che deve essere condiviso con le richieste di follow-up. Buoni candidati sono istruzioni di sistema di grandi dimensioni, definizioni di strumenti o contesto di riferimento stabile. I candidati scadenti sono i messaggi utente una tantum, i payload delle attività correnti o gli snippet RAG specifici della richiesta.

Fatto: Anthropic documenta una durata della cache predefinita di 5 minuti e una durata della cache di 1 ora disponibile a un costo aggiuntivo. Ciò rende la scelta del TTL una decisione economica. Una cache lunga può avere senso per gli agenti di codifica interattivi, la revisione di documenti in più fasi o per supportare i copiloti con pause tra i turni. Può essere uno spreco per un'attività one-shot poco ripetitiva.

Gemini Adattatore

Per Gemini, considera la memorizzazione nella cache del contesto come una decisione relativa alle risorse. Crea contenuto memorizzato nella cache quando il riutilizzo previsto giustifica i costi di installazione e archiviazione, quindi fai riferimento a tale cache dalle chiamate di generazione. Questo è diverso dal fare affidamento solo su una cache automatica del prefisso. L'adattatore deve possedere ciclo di vita della cache, TTL, metadati e policy di pulizia.

GeminiLe cache di contesto in stile sono spesso ideali per contesti ampi e stabili che verranno riutilizzati da molte richieste: un lungo manuale di policy, un estratto statico del catalogo di prodotti, un ambiente di strumenti di agente di codifica fisso o un flusso di lavoro di revisione che pone ripetutamente domande sullo stesso set di documenti.

Misura gli aspetti economici della cache, non solo i risultati Rate

La percentuale di riscontri nella cache è utile, ma non è sufficiente. Un tasso di successo elevato su un prefisso piccolo può far risparmiare poco. Un tasso di successo più basso su un prefisso di policy e strumenti molto ampio potrebbe avere più importanza.Alcuni provider espongono costi di scrittura o configurazione della cache e tali costi possono annullare i risparmi se il riutilizzo è basso.

Cattura questi campi per ogni richiesta in cui il provider li espone o il gateway può stimarli:

• Provider e modello.
• Tenant, applicazione, ambiente e API identità della chiave.
• Versione del modello di prompt e prefisso memorizzabile nella cache hash.
• Criterio TTL o durata della cache.
• Token di input non memorizzati nella cache.
• Token di input memorizzati nella cache.
• Token di scrittura o creazione della cache, ove disponibili.
• Token di output.
• Tempo per il primo token e totale latenza.
• Versione del prezzo di listino del provider utilizzata per il calcolo dei costi.
• Se la richiesta faceva parte di una sessione interattiva, un processo batch, un loop dell'agente o una chiamata one-shot.

Quindi calcola il valore della cache in base al carico di lavoro, non a livello globale. Un copilota di supporto, un agente di codifica, un revisore di documenti e un riepilogo una tantum hanno modelli di riutilizzo diversi. I rollup dovrebbero mostrare i soldi risparmiati, i soldi spesi per la scrittura nella cache, la modifica della latenza e il tasso di successo in base all'hash del prefisso.

Per iniziare è sufficiente un semplice modello ROI:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Questo modello è volutamente semplice. Dovrebbe essere utilizzato come cancello prima di abilitare cache di lunga durata o esplicite, non come sostituto della misurazione della produzione.

Aggiungi regole Lint per i Cache Breakers

La maggior parte degli errori della cache derivano da abitudini di costruzione tempestiva, non da bug del provider. Aggiungi regole lint del gateway che vengono eseguite prima che le richieste raggiungano il provider.

Segnala i timestamp nella parte superiore dei prompt. Se il modello necessita dell'ora corrente, inseriscila dopo il prefisso riutilizzabile o passala come blocco di richieste tardive.

Contrassegna gli ID casuali nei messaggi di sistema. Gli ID di correlazione appartengono ai metadati o ai log, non al prefisso del prompt stabile.

Contrassegna gli schemi degli strumenti ordinati dinamicamente. Ordinare gli strumenti e le proprietà dello schema in modo deterministico prima del rendering. Un elenco di strumenti che cambia ordine a ogni richiesta può compromettere il riutilizzo anche quando il set di strumenti è logicamente identico.

Contrassegna il RAG specifico della richiesta prima degli strumenti stabili. I passaggi recuperati sono spesso volatili. Inserisci prima le istruzioni stabili e gli schemi degli strumenti, quindi i passaggi recuperati, a meno che i test rapidi non dimostrino che è necessario un altro ordine.

Contrassegna la personalizzazione specifica dell'utente nella policy condivisa. I criteri del tenant possono essere memorizzabili nella cache di un tenant, ma le preferenze dell'utente e lo stato corrente dell'account in genere non lo sono.

Variazione della versione del modello di flag. Se a ogni distribuzione vengono modificati spazi bianchi, commenti o testo di istruzioni non utilizzato, l'hash del prefisso memorizzabile nella cache cambia. Modelli di prompt di versione deliberatamente ed evita modifiche inutili a blocchi stabili di grandi dimensioni.

Gestisci i carichi di lavoro RAG con attenzione

RAG è il luogo in cui i team spesso sovraccaricano la cache. Le istruzioni di recupero stabile, le regole di citazione, gli schemi di strumenti e le descrizioni del corpus possono essere riutilizzabili. I passaggi recuperati stessi sono solitamente specifici della richiesta. Se inserisci i passaggi recuperati prima delle istruzioni stable, riduci il riutilizzo. Se memorizzi nella cache l'intero contesto quando è improbabile che i passaggi si ripetano, potresti pagare costi di scrittura o configurazione senza un numero sufficiente di risultati futuri.

Ci sono delle eccezioni. Un flusso di revisione legale, un flusso di lavoro di supporto o un assistente documento-prodotto possono interrogare ripetutamente lo stesso pacchetto di documenti in una sessione. In tal caso, può essere utile una cache di più lunga durata per il contesto del documento.La decisione dovrebbe dipendere dal numero di riutilizzi previsto, dalla durata della cache, dalle dimensioni del contesto del documento e dalla tendenza degli utenti a porre più domande sullo stesso materiale.

Raccomandazione: classifica il contesto RAG come uno di tre tipi: guida al corpus statico, contesto di sessione riutilizzabile o snippet recuperati una tantum. Per impostazione predefinita, memorizza nella cache solo i primi due.

Convalida il comportamento prima di ottimizzare i costi

Lo spostamento dei contenuti in un secondo momento in un prompt può migliorare il riutilizzo della cache, ma può anche modificare il comportamento del modello. Ad esempio, spostare le regole dello strumento dopo la cronologia delle conversazioni potrebbe ridurne l'influenza. Lo spostamento della policy al di sotto del contenuto recuperato può indebolire la priorità delle istruzioni. La normalizzazione degli schemi può influenzare la selezione degli strumenti se le descrizioni cambiano.

Utilizza i test di regressione prima di implementare layout che riconoscono la cache. Come minimo, testare:

• Priorità delle istruzioni per i criteri di sicurezza e conformità.
• Selezione degli strumenti su attività note.
• Validità dell'output strutturato in cui sono coinvolti gli schemi.
• Qualità della risposta su esempi RAG rappresentativi.
• Latenza e costi su ripetuti turni.
• Contabilità dell'utilizzo specifica del provider.

Per i flussi di lavoro ad alto rischio, esegui un confronto ombra: layout del prompt originale rispetto al layout con riconoscimento della cache, stesso modello, stessi input, con controlli umani o automatizzati per modifiche di output inaccettabili. I risparmi sui costi non sono utili se il compilatore delle richieste modifica il comportamento aziendale in modi non approvati dai team.

Scegli i carichi di lavoro in modo selettivo

La memorizzazione nella cache dei prompt è più efficace quando i prompt sono lunghi e ripetuti. Buoni punti di partenza includono agenti di codifica con schemi di strumenti di grandi dimensioni, copiloti di supporto con istruzioni ricche di policy, flussi di revisione dei documenti con domande ripetute sullo stesso materiale, agenti con molti strumenti e assistenti aziendali con ampi blocchi di governance.

I candidati deboli includono brevi istruzioni singole, istruzioni altamente personalizzate in cui la parte superiore della richiesta cambia ogni volta, attività di amministrazione poco frequenti e flussi di lavoro in cui i token di output dominano il costo totale. In questi casi, altre ottimizzazioni potrebbero avere più importanza: prompt più brevi, recupero migliore, routing del modello, elaborazione batch o limiti di output più rigidi.

Previsione: la semantica della memorizzazione nella cache del provider continuerà a divergere. La memorizzazione automatica dei prefissi nella cache, i punti di interruzione espliciti, le risorse contestuali a pagamento, la contabilità di scrittura nella cache e i prezzi TTL probabilmente rimarranno disomogenei tra le piattaforme.I team che centralizzano la compilazione delle richieste e la telemetria sul gateway saranno in grado di adattarsi più velocemente rispetto ai team che incorporano la logica di memorizzazione nella cache specifica del provider nel codice dell'applicazione.

Elenco di controllo per l'implementazione

• Crea un modello di blocco di prompt interno con etichette di stabilità: globale, tenant, applicazione, flusso di lavoro, sessione e richiesta.
• Esegui il rendering dei blocchi in modo deterministico, incluso l'ordine degli strumenti e la proprietà dello schema ordine.
• Sposta i campi volatili fuori dal prefisso stabile.
• Calcola un hash del prefisso memorizzabile nella cache dopo il rendering.
• Aggiungi adattatori del provider per il riutilizzo del prefisso OpenAI, Anthropic breakpoint della cache e Gemini risorse della cache del contesto.
• Registra token di input non memorizzati nella cache, token di input memorizzati nella cache, token di scrittura nella cache ove disponibile, token di output, latenza, modello, tenant, applicazione, hash del prefisso e TTL.
• Crea dashboard per il risparmio netto, costi di scrittura/configurazione, percentuale di successo e latenza in base al carico di lavoro.
• Aggiungi regole lint per timestamp, ID casuali, posizionamento RAG volatile, ordine dinamico degli strumenti e personalizzazione nei blocchi condivisi.
• Esegui prima test di regressione del comportamento dei prompt modifica del layout di produzione.
• Abilita prima la memorizzazione nella cache per carichi di lavoro a ripetizione elevata, quindi espandila in base al ROI misurato.

Conclusione

La progettazione dei prompt in grado di riconoscere la cache non è solo la formattazione dei prompt. Si tratta di una funzionalità gateway: rendering deterministico, progettazione di prefissi stabili, compilazione specifica del provider, linting e telemetria dei costi. I team che ne trarranno maggiori benefici saranno quelli in grado di rispondere a tre domande per ogni carico di lavoro: quale parte della richiesta è veramente riutilizzabile, in che modo questo fornitore addebita il riutilizzo e la cache ha migliorato i costi end-to-end o la latenza senza modificare il comportamento?

Inizia con un flusso di lavoro ad alta ripetizione. Separa i blocchi stabili dai blocchi volatili, aggiungi la gestione della cache specifica del provider, misura gli aspetti economici e solo dopo generalizza. Questo percorso evita la modalità di errore comune: attivare una funzionalità di cache senza sapere se sta risparmiando denaro, aggiungendo latenza o semplicemente spostando i costi in un campo contabile diverso.

Leggi correlati

• Osservabilità LLM indipendente dal provider