Το Amazon Bedrock prompt caching διαβάζει ένα cached πρόθεμα με περίπου 90% έκπτωση, αλλά η εγγραφή σε cache κοστίζει περισσότερο από ένα κανονικό input token, άρα μια cache που δεν πετυχαίνει ποτέ hit κάνει τον λογαριασμό σου χειρότερο, όχι καλύτερο. Το χαρακτηριστικό είναι γενικά διαθέσιμο από τον Απρίλιο του 2025, και η διάρκεια cache μίας ώρας που κυκλοφόρησε τον Ιανουάριο του 2026 το κάνει χρήσιμο για ολόκληρες συνεδρίες και batch jobs. Οι περισσότερες ομάδες το αφήνουν ακόμα απενεργοποιημένο, ή το ενεργοποιούν στο λάθος σημείο και πληρώνουν σιωπηλά ένα premium. Η έκπτωση είναι πραγματική. Το αν θα την κερδίσεις εξαρτάται εξ ολοκλήρου από το πού βάζεις το cache breakpoint.

Το νοητικό μοντέλο που παγιδεύει τον κόσμο είναι να αντιμετωπίζει την cache σαν μια δωρεάν επιτάχυνση που την πασπαλίζεις. Δεν είναι δωρεάν. Κάθε cache checkpoint είναι ένα στοίχημα ότι τα tokens πριν από αυτό θα ξανασταλούν, αναλλοίωτα, πριν λήξει η cache. Κέρδισε το στοίχημα και πληρώνεις το ένα δέκατο της τιμής ανάγνωσης. Χάσε το και πλήρωσες ένα premium εγγραφής για το τίποτα.

Πώς λειτουργεί στην πραγματικότητα η τιμολόγηση

Τρεις κατηγορίες tokens έχουν σημασία, και τιμολογούνται διαφορετικά:

  • Εγγραφή στην cache: την πρώτη φορά που το Bedrock αποθηκεύει ένα πρόθεμα, αυτά τα tokens χρεώνονται πάνω από τον κανονικό ρυθμό input. Στα μοντέλα Anthropic η εγγραφή είναι περίπου 1.25x του βασικού input για τη σύντομη διάρκεια cache και περίπου 2x για τη διάρκεια της μίας ώρας.
  • Ανάγνωση από την cache: κάθε επόμενο request που ταιριάζει με το αποθηκευμένο πρόθεμα διαβάζει αυτά τα tokens με περίπου 0.1x, η κεντρική εξοικονόμηση 90%.
  • Μη cached input: ό,τι έρχεται μετά το τελευταίο cache checkpoint, χρεώνεται στον κανονικό ρυθμό κάθε φορά.

Το premium εγγραφής είναι όλο το παιχνίδι. Προπληρώνεις για να κάνεις φθηνές τις μελλοντικές αναγνώσεις. Το break-even είναι απλό: χρειάζεσαι αρκετά hits σε ένα cached πρόθεμα για να ξαναβγάλεις το επιπλέον που πλήρωσες για να το γράψεις. Μία εγγραφή συν μία ανάγνωση μπορεί να κοστίσει περισσότερο από δύο απλές κλήσεις. Η εξοικονόμηση αυξάνεται μόνο όταν το ίδιο πρόθεμα διαβάζεται πολλές φορές.

Πού πάει το breakpoint

Ένα cache checkpoint λέει «όλα πριν από αυτό το σημείο είναι σταθερά, αποθήκευσέ τα». Άρα βάλε το μετά τα μέρη του prompt που δεν αλλάζουν μεταξύ κλήσεων, και πριν από αυτά που αλλάζουν. Σε έναν τυπικό assistant αυτή η σειρά είναι:

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

Το system prompt και οι ορισμοί εργαλείων είναι πανομοιότυπα σε κάθε κλήση, άρα ανήκουν μέσα στο cached πρόθεμα. Το νέο turn του χρήστη δεν επαναλαμβάνεται ποτέ, άρα ανήκει έξω. Το ανακτημένο context βρίσκεται στη μέση: κάνε cache αν τα ίδια έγγραφα επαναχρησιμοποιούνται σε μια συνεδρία, άφησέ το χωρίς cache αν κάθε κλήση ανακτά κάτι νέο. Αν κάνεις λάθος αυτή τη σειρά, βάζοντας το checkpoint πριν τους ορισμούς εργαλείων, θα κάνεις cache σχεδόν τίποτα ενώ θα πληρώνεις για να το γράψεις.

Πότε ένα miss κοστίζει περισσότερο από καθόλου cache

Τα cache hits απαιτούν ακριβή αντιστοίχιση στο πρόθεμα, byte προς byte, και η εγγραφή πρέπει να είναι ακόμα ζωντανή. Χάνεις το στοίχημα με τρεις συνηθισμένους τρόπους:

  • Μεταλλάσσεις το πρόθεμα. Η εισαγωγή ενός timestamp, ενός request ID, ή ενός ανά χρήστη χαιρετισμού κοντά στην κορυφή του system prompt αλλάζει τα bytes, άρα κάθε κλήση είναι μια νέα εγγραφή και ποτέ ανάγνωση. Αυτό είναι το πιο συνηθισμένο αυτογκόλ.
  • Η κίνηση είναι πολύ αραιή για το TTL. Αν τα requests φτάνουν με μεγαλύτερα διαστήματα από τη διάρκεια ζωής της cache, το καθένα γράφει και λήγει πριν έρθει το επόμενο. Η διάρκεια της μίας ώρας διεύρυνε πολύ αυτό το παράθυρο, αλλά ένα endpoint χαμηλής κίνησης μπορεί ακόμα να αστοχεί κάθε φορά.
  • Το πρόθεμα είναι κάτω από το ελάχιστο. Το Bedrock κάνει cache μόνο προθέματα πάνω από ένα κατώφλι tokens ανά μοντέλο. Ένα σύντομο system prompt μπορεί να μην είναι καθόλου cacheable, οπότε το checkpoint αγνοείται και δεν κερδίζεις τίποτα.

Σε κάθε περίπτωση είτε πληρώνεις το premium εγγραφής χωρίς αναγνώσεις να το αποσβέσουν, είτε δεν πληρώνεις τίποτα επιπλέον αλλά και δεν εξοικονομείς τίποτα ενώ νομίζεις ότι βελτιστοποίησες. Και τα δύο είναι χειρότερα από μια ξεκάθαρη απόφαση να αφήσεις το caching απενεργοποιημένο για εκείνο το μονοπάτι.

Ένας γρήγορος τρόπος να ξέρεις αν λειτουργεί

Μην υποθέτεις ότι η cache είναι ζεστή. Οι απαντήσεις των Converse και InvokeModel αναφέρουν αριθμούς tokens για ανάγνωση και εγγραφή cache στα πεδία χρήσης τους. Κατέγραψέ τα και παρακολούθησε την αναλογία. Ένα υγιές cached μονοπάτι δείχνει μια μικρή, σταθερή ροή εγγραφών και έναν μεγάλο όγκο αναγνώσεων. Αν οι εγγραφές και οι αναγνώσεις κινούνται μαζί ένα προς ένα, το πρόθεμά σου δεν είναι σταθερό και πληρώνεις το premium για μια cache που κανείς δεν πετυχαίνει. Διόρθωσε το πρόθεμα ή απενεργοποίησε το checkpoint.

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

Το συμπέρασμα

Το prompt caching στο Bedrock δεν είναι ένας διακόπτης που γυρνάς για μια δωρεάν έκπτωση 90%. Είναι μια προπληρωμένη έκπτωση: πληρώνεις ένα premium εγγραφής εκ των προτέρων και το ξαναβγάζεις μέσω επαναλαμβανόμενων αναγνώσεων ενός αναλλοίωτου προθέματος. Βάλε το checkpoint μετά το σταθερό system prompt και τους ορισμούς εργαλείων, κράτα οτιδήποτε ασταθές έξω από την cached περιοχή, και κατέγραψε την αναλογία ανάγνωσης προς εγγραφή ώστε να μπορείς να αποδείξεις ότι το στοίχημα αποδίδει. Σωστά γινόμενο είναι η φθηνότερη μεγάλη εξοικονόμηση διαθέσιμη στο Bedrock. Απρόσεκτα γινόμενο είναι ένα κονδύλι που κάνει τον λογαριασμό σου χειρότερο ενώ φαίνεται σαν βελτιστοποίηση.

Διάβασε επίσης

Για το ευρύτερο playbook βελτιστοποίησης κόστους σε όλο το AWS, οι σημειώσεις πεδίου για το cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.