Prompt caching: struttura dei prompt e misura del risparmio

Diversi provider (OpenAI, Anthropic, Google, …) offrono o hanno offerto sconti o conteggi separati per prefissi di prompt riutilizzati—spesso chiamati “prompt caching”, “context caching”, o prezzi ridotti per block ripetuti. Le regole cambiano spesso: questa guida tratta il metodo di misura, non cifre aggiornate. Apri sempre la pagina pricing e la doc “caching” del vendor attivo.

Cosa vuol dire “cache hit” lato provider

In genere: un prefisso deterministico (system instructions lunghe, manuale tool, corpus RAG statico) che il provider ha già visto di recente viene fatturato con tariffe diverse dal testo “nuovo” inviato nel turno corrente. Non è una cache HTTP tua: è infra del vendor.

Fallimenti tipici false negative (l’hit non avviene):

• Cambi anche un byte nello system prompt stabile (timestamp, UUID per richiesta).
• Ordini diversamente chunk identici.
• Usi modelli o endpoint dove la feature non è abilitata (verifica doc).

Struttura stabile del prompt

1. Metti il massimo testo riutilizzabile nel system (o prefisso fisso) partendo da template immutabili.
2. Sposta variabili utente (domanda, file upload digest) dopo il blocco stabile—molti sistemi confrontano prefissi.
3. Evita stringhe dinamiche nel system (new Date() salvo necessità).

Protocollo di misura (A/B)

1. Baseline: N richieste (es. 200) con payload reale senza tentativo di caching (o con system minimale).
2. Cached: stesse N richieste dopo aver pre-scaldato inviando almeno una richiesta identica per stabilire prefisso (se richiesto dal vendor).
3. Registra da usage (o dashboard billing export): input tokens totali, eventuale breakdown cached_prompt_tokens se esposto, costo stimato con listino corrente.

Confronta media e p95 del costo per richiesta, non solo la media—code con retry possono sporcare.

OpenAI: numeri e telemetria (fonte cookbook + guide API)

Il cookbook ufficiale Prompt Caching 201 riassume meccanismi verificabili:

• Hit affidabile solo se il prefisso byte-per-byte coincide con una richiesta recente; include system, tool definitions, schede structured output—non solo testo libero.
• Soglia pratica spesso citata: prompt ≥ 1024 token, cache in blocchi da 128 token sul prefisso (dettaglio da ricontrollare quando OpenAI aggiorna la doc).
• La risposta riporta usage.prompt_tokens_details.cached_tokens (Chat/Responses) per sapere quanti input token sono stati serviti dalla cache—misura lì, non stimando caratteri.
• Parametro opzionale prompt_cache_key (se abilitato nel tuo endpoint) migliora affinità di routing per traffico che condivide grandi prefissi—vedi guida Prompt caching e il cookbook Prompt Caching 201.
• Il discount sul listino dipende dal modello (es. esempi tabellari nel cookbook: fino ~50% su gpt-4o cached input, fino ~90% sulle famiglie gpt-5.x mostrate lì)—rivalida sempre su Pricing.

Engineering tip dal cookbook: spostare timestamp/debug in metadata invece che nel system prompt stabile per non invalidare involontariamente la cache.

Anthropic: cache_control e policy

Per Claude, la doc Prompt caching descrive breakpoint espliciti (cache_control: { type: "ephemeral" }) o modalità automatica sulle conversazioni lunghe—TTL e prezzi sono listati lato Anthropic e differiscono da OpenAI. Valuta Zero Data Retention vs caching con il tuo account manager se applicabile.

Ordini di grandezza

Il risparmio dichiarato dai vendor per workload ad alta ripetizione può essere moltiplicativo sul solo input statico; se il tuo prompt è per lo più domanda utente unica, non aspettarti miracoli. Misura sempre.

Privacy e invalidazione

Contenuti sensibili nel prefisso cache condiviso multi-tenant possono essere problema compliance: verifica isolamento del tenant e retention dichiarata dal vendor.

Sintesi

Congela il prefisso, metti variabilità in coda, misura prima/dopo con token effettivi dalla risposta API. Le percentuali marketing non sostituiscono usage.prompt_tokens_details (o equivalente) nei log.