Prompt caching in Amazon Bedrock può ridurre i costi degli input fino al 90%

Senza cache, un contratto da 10.000 token allegato a 50 domande genera 500.000 token di input fatturati. Il post di Amazon mostra questo caso per spiegare uno spreco comune: ripagare molte volte lo stesso contesto già elaborato dal modello¹.

Il punto è l’uso ripetuto della stessa base informativa insieme a richieste diverse. Succede con prompt di sistema, documenti e definizioni di tool. Ogni invio rimanda al modello parti identiche. Amazon propone il prompt caching a livello di infrastruttura: quando si memorizzano sezioni stabili della conversazione, il servizio legge i token in cache nelle richieste successive invece di riprocessarli¹.

Il blog quantifica il beneficio economico. Prompt caching in Amazon Bedrock può ridurre i costi dei token di input fino al 90% quando si invia ripetutamente lo stesso contesto ai foundation model, in base ai prezzi del prompt caching di Amazon Bedrock¹. L’esempio dei 500.000 token aiuta a visualizzare l’impatto quando si allega un documento lungo a molte domande. Con la cache, i token del documento non si ripagano ogni volta. Si evita il ricalcolo del contenuto invariato e si limita l’addebito a ciò che cambia tra una richiesta e l’altra¹.

Prima, chi costruisce applicazioni valutava tre strade, tutte con compromessi. Accorciare i prompt per ridurre i token, con il rischio di degradare la qualità del contesto. Restringere la context window per abbassare i costi, a scapito della capacità del modello di ragionare su informazioni complete. Oppure fare response caching, molto efficace solo quando la query è identica di volta in volta e inutile quando lo stesso contesto accompagna domande diverse¹.

Portare il caching dei prompt nell’infrastruttura affronta questo limite. Il servizio può memorizzare parti della conversazione come prompt di sistema, documenti e definizioni di tool, e riutilizzare i token memorizzati nelle chiamate successive. In pratica, Amazon Bedrock evita di rianalizzare token immutati e legge direttamente dalla cache. Questo riduce il lavoro ripetitivo nella fase di input e, secondo il titolo e l’impostazione del post, punta a ottimizzare sia i costi sia la latenza¹.

La meccanica è semplice dal punto di vista dell’uso. Se una parte del contesto rimane costante tra le chiamate, vale la pena metterla in cache. Il servizio riconosce le sezioni memorizzate e le rilegge dai dati salvati, così che il modello non le debba processare di nuovo. Il guadagno cresce quando lo stesso documento o lo stesso prompt di sistema accompagna una serie di richieste, come nella sequenza di 50 domande dell’esempio. La cache agisce dove il response caching non aiuta: quando cambia la domanda ma resta uguale il contesto¹.

Per flussi che associano contesti stabili a domande variabili, il criterio operativo emerge netto dalle informazioni del post. Usare la cache dei prompt indirizza il costo verso ciò che cambia tra le richieste. Secondo Amazon, questa scelta può ridurre sensibilmente la spesa in token di input e, per impostazione, migliorare anche la latenza, mantenendo intatti i vantaggi di includere un contesto ampio quando serve¹.