Το Amazon Bedrock τρέχει batch inference στο 50% της τιμολόγησης tokens on-demand, και το μόνο που παραιτείσαι είναι η αμεσότητα. Υποβάλλεις ένα αρχείο με requests, η εργασία τρέχει ασύγχρονα όταν υπάρχει χωρητικότητα, και συλλέγεις τα αποτελέσματα αργότερα. Για κάθε φόρτο εργασίας όπου κανένας άνθρωπος δεν κάθεται να περιμένει την απάντηση, το να πληρώνεις πλήρη τιμή για inference σε πραγματικό χρόνο αφήνει τα μισά χρήματα στο τραπέζι για μια ταχύτητα που κανείς δεν χρειαζόταν.

Το λάθος είναι να κάνεις κάθε κλήση μοντέλου προεπιλεγμένη στο σύγχρονο, πραγματικού χρόνου μονοπάτι επειδή έτσι γράφτηκε το πρώτο prototype. Το διαδραστικό chat πρέπει να είναι πραγματικού χρόνου. Μια νυχτερινή εργασία που ταξινομεί τα χθεσινά tickets υποστήριξης όχι. Αυτές είναι διαφορετικές απαιτήσεις καθυστέρησης, και το Bedrock τις τιμολογεί διαφορετικά. Το μηχανικό ερώτημα είναι απλά ποιοι από τους φόρτους εργασίας σου χρειάζονται πραγματικά μια απάντηση τώρα έναντι ποιοι χρειάζονται μια απάντηση κάποια στιγμή.

Πώς λειτουργεί το batch στο Bedrock

Το batch inference είναι μια εργασία, όχι μια κλήση. Η ροή είναι σκόπιμα βαρετή:

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

Κάθε εγγραφή input φέρει ένα record ID και το ίδιο input μοντέλου που θα έστελνες σε πραγματικό χρόνο. Το output γράφεται πίσω στο S3, ένα αποτέλεσμα ανά input, με κλειδί αυτό το record ID ώστε να μπορείς να συνδέσεις αποτελέσματα με inputs. Δεν υπάρχει endpoint να κρατάς ζεστό, καμία ταυτόχρονη εκτέλεση να ρυθμίσεις, κανένα throttling να πιάσεις. Ανταλλάσσεις τον βρόχο request-response για έναν βρόχο submit-and-collect, και παίρνεις τον μειωμένο ρυθμό επειδή αποδέχεσαι ότι η εργασία τελειώνει με το πρόγραμμα της υπηρεσίας, όχι το δικό σου.

Πού πραγματικά δεν έχει σημασία η καθυστέρηση

Οι φόρτοι εργασίας που ταιριάζουν είναι εκείνοι όπου το αποτέλεσμα τροφοδοτεί μια διαδικασία, όχι έναν άνθρωπο που περιμένει σε μια οθόνη:

  • Μαζική ταξινόμηση και ετικετοποίηση. Κατηγοριοποίησε ένα backlog εγγράφων, tickets, ή προϊόντων. Η απάντηση καταλήγει σε μια βάση δεδομένων, όχι μπροστά σε έναν χρήστη.
  • Pipelines εμπλουτισμού. Περιλήψεις, εξαγωγές, ή embeddings που δημιουργούνται εκ των προτέρων και αποθηκεύονται, ώστε το μονοπάτι πραγματικού χρόνου απλά να διαβάζει μια προϋπολογισμένη τιμή.
  • Offline αξιολόγηση. Βαθμολόγηση μιας αλλαγής μοντέλου ή prompt σε χιλιάδες test cases. Είναι μια αναφορά, και οι αναφορές μπορούν να περιμένουν μια ώρα.
  • Περιοδική αναφορά. Οτιδήποτε τρέχει με πρόγραμμα και παράγει output που ένας άνθρωπος διαβάζει αργότερα, όχι στιγμιαία.

Το κοινό νήμα: η προθεσμία μετριέται σε ώρες, και ο όγκος είναι αρκετά μεγάλος ώστε το να μειωθεί στο μισό η τιμή token να είναι πραγματικά χρήματα και όχι στρογγυλοποίηση.

Τα μαθηματικά του κόστους

Η ανταλλαγή είναι εντυπωσιακή όταν τη βάζεις στο χαρτί. Πάρε μια εργασία ενός εκατομμυρίου εγγραφών, καθεμία με σταθερό μέσο κόστος tokens:

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

Η στήλη batch είναι το μισό του λογαριασμού tokens και λιγότερη λειτουργική επιφάνεια, γιατί δεν υπάρχει ζωντανό endpoint να προστατεύσεις από ένα ξέσπασμα. Το break-even δεν αφορά τον όγκο, αφορά την προθεσμία. Αν η απάντηση μπορεί να περιμένει, το batch κερδίζει και σε κόστος και σε απλότητα. Αν δεν μπορεί, καμία έκπτωση δεν κάνει μια ασύγχρονη εργασία αποδεκτή.

Πότε το batch είναι το λάθος εργαλείο

Μην το εξαναγκάζεις εκεί που το σχήμα δεν ταιριάζει. Το batch είναι λάθος όταν ένας χρήστης περιμένει το output, όταν ένα request εξαρτάται από το αποτέλεσμα του προηγούμενου, ή όταν η εργασία είναι αρκετά μικρή ώστε η έκπτωση να είναι ασήμαντη και η ασύγχρονη υδραυλική να μην αξίζει τον κόπο. Είναι επίσης λάθος ως λύση εναντίον throttling: αν η κίνηση πραγματικού χρόνου σου κάνει throttle, η λύση είναι σχεδιασμός χωρητικότητας και prompt caching, όχι να σπρώχνεις διαδραστικά requests μέσα από μια εργασία που επιστρέφει ώρες αργότερα. Το batch είναι για δουλειά που ούτως ή άλλως θα αναβαλλόταν, όχι για να κρύψεις ένα πρόβλημα καθυστέρησης.

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

Το μισό ενός μεγάλου λογαριασμού tokens αξίζει μια αρχιτεκτονική που οι περισσότερες ομάδες ήδη έχουν πρόχειρη: γράψε στο S3, υπόβαλε μια εργασία, διάβασε τα αποτελέσματα αργότερα. Η έκπτωση δεν είναι έξυπνη, είναι απλά να πληρώνεις για αναβλημένη χωρητικότητα αντί για χωρητικότητα on-demand. Έλεγξε τις κλήσεις μοντέλου σου και ταξινόμησέ τες με βάση ποιος περιμένει. Οτιδήποτε έχει έναν άνθρωπο στην άλλη άκρη παραμένει πραγματικού χρόνου. Όλα τα υπόλοιπα, η ταξινόμηση, ο εμπλουτισμός, η αξιολόγηση, και η αναφορά που τροφοδοτεί ένα pipeline αντί για ένα άτομο, ανήκουν σε μια batch εργασία με 50% έκπτωση. Η εξοικονόμηση κάθεται στους φόρτους εργασίας που ποτέ δεν αμφισβήτησες.

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

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