Όταν ο λογαριασμός σου στο Amazon Bedrock εκτοξεύεται και κανείς δεν μπορεί να πει ποιο feature το προκάλεσε, δεν έχεις πρόβλημα τιμολόγησης. Έχεις πρόβλημα παρατηρησιμότητας. Το τιμολόγιο σου λέει ότι ο λογαριασμός ξόδεψε περισσότερα σε tokens. Δεν σου λέει ποιος agent, ποιος πελάτης, ή ποιο μονοπάτι κώδικα έκανε την ξοδεία, και χωρίς αυτή την απόδοση κάθε συζήτηση κόστους είναι μαντεψιά. Δεν μπορείς να βελτιστοποιήσεις αυτό που δεν μπορείς να μετρήσεις, και οι περισσότερες ομάδες μετράνε το σύνολο και τίποτα από κάτω του.

Η δαπάνη tokens έχει μια ιδιότητα που το κάνει χειρότερο από συνηθισμένο κόστος cloud: παράγεται από ένα μη ντετερμινιστικό σύστημα. Μια αλλαγή prompt, ένα retry loop, ένας φλύαρος agent, ή ένας χρήστης που βρήκε τρόπο να κάνει το μοντέλο να σκέφτεται πιο σκληρά μπορούν όλα να κινήσουν τον λογαριασμό, και κανένα από αυτά δεν εμφανίζεται ως νέος πόρος στο τιμολόγιο. Η δαπάνη κρύβεται μέσα σε ένα ενιαίο κονδύλι Bedrock. Η δουλειά είναι να σπάσεις αυτό το κονδύλι πριν σε εκπλήξει, όχι μετά.

Η απόδοση είναι όλο το παιχνίδι

Το ερώτημα που έχει σημασία δεν είναι ποτέ «πόσα ξοδέψαμε στο Bedrock». Είναι «πόσα ξόδεψε αυτό, και αξίζει τον κόπο». Για να απαντήσεις αυτό χρειάζεσαι μια διάσταση σε κάθε μονάδα δαπάνης tokens. Στο ελάχιστο, ετικέτησε κάθε κλήση με:

  • Feature ή τομέα προϊόντος, ώστε να μπορείς να ρωτήσεις αν ο συνοψιστής ή ο βοηθός chat είναι ο οδηγός κόστους.
  • Πελάτη ή customer, ώστε να δεις αν ένας λογαριασμός επιδοτείται από τους υπόλοιπους και αν η τιμολόγησή σου καλύπτει το κόστος εξυπηρέτησής σου.
  • Agent ή workflow, ώστε το κόστος ενός πολυβηματικού pipeline να είναι ορατό ανά βήμα αντί ως ένα αδιαφανές σύνολο.
  • Μοντέλο, ώστε να μπορείς να διακρίνεις πότε ακριβή κίνηση πηγαίνει σε ένα frontier μοντέλο που ένα φθηνότερο θα χειριζόταν.

Χωρίς αυτές τις διαστάσεις, η βελτιστοποίηση κόστους υποβαθμίζεται σε γενικά μέτρα: βάλε όριο σε όλους, ή κλείσε features και δες ποια καταγγελία φτάνει. Με αυτές, μπορείς να δείξεις στο ακριβές μονοπάτι που μεγάλωσε και να αποφασίσεις αν κέρδισε την ανάπτυξη.

Δύο επίπεδα οργανολόγησης

Ετικέτες κατανομής κόστους για το τιμολόγιο

Οι ετικέτες κατανομής κόστους του AWS είναι το χοντρό επίπεδο. Ετικέτησε τους πόρους και τα requests που οδηγούν τη χρήση Bedrock ώστε τα ίδια τα δεδομένα τιμολόγησης να κουβαλάνε τις διαστάσεις σου, και οι αναφορές κόστους να μπορούν να ομαδοποιούν κατά feature ή περιβάλλον αντί να δείχνουν ένα αδιαφοροποίητο νούμερο Bedrock. Αυτή είναι η προβολή στην οποία ζουν οικονομικά τμήματα και ιδιοκτήτες πλατφόρμας. Είναι σε μηνιαία κοκκοποίηση και καλή για τη συζήτηση «πού πάνε τα χρήματα», όχι για να πιάσεις μια αιχμή τη στιγμή που συμβαίνει.

Μετρικές CloudWatch για την εικόνα σε πραγματικό χρόνο

Το τιμολόγιο είναι ένας υστερούμενος δείκτης. Ο προπορευόμενος δείκτης είναι η ρυθμαπόδοση tokens, και αυτή ανήκει στο CloudWatch. Το Bedrock εκπέμπει μετρικές χρήσης, και μπορείς να δημοσιεύσεις δικές σου προσαρμοσμένες μετρικές με διαστάσεις ανά agent, ανά πελάτη, ή ανά feature απευθείας από την εφαρμογή:

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

Τώρα η δαπάνη είναι ένα γράφημα στο οποίο μπορείς να βάλεις alarm. Μια μετρική tokens ανά agent που τριπλασιάζεται μέσα σε μια νύχτα πυροδοτεί μια ειδοποίηση την Τρίτη, αντί για μια ερώτηση οικονομικών στο τέλος του μήνα. Διάβασε input και output ξεχωριστά, γιατί το output τιμολογείται υψηλότερα και μια ανεξέλεγκτη γένεση εμφανίζεται εκεί πρώτη.

Τι σου επιτρέπει η ορατότητα

Μόλις κάθε token αποδοθεί, οι βελτιστοποιήσεις σταματούν να είναι αμβλείς. Μπορείς να δρομολογήσεις τις φθηνές, μηχανικές κλήσεις που αποκαλύπτει μια μετρική ανά agent σε ένα μικρότερο μοντέλο, και να κρατήσεις το frontier μοντέλο για τη σκέψη που το αξίζει. Μπορείς να βρεις τον πελάτη του οποίου το κόστος εξυπηρέτησης ξεπερνά το πλάνο του και να διορθώσεις την τιμολόγηση ή τη χρήση. Μπορείς να πιάσεις το retry loop που εισήγαγε μια αλλαγή prompt, γιατί ο αριθμός tokens εκτοξεύτηκε ενώ ο αριθμός requests όχι. Κάθε μία από αυτές τις κινήσεις απαιτεί να ξέρεις ποιο κομμάτι του λογαριασμού να κόψεις, που είναι ακριβώς αυτό που σου δίνει η οργανολόγηση και το ακατέργαστο τιμολόγιο ποτέ δεν θα δώσει.

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

Ένας λογαριασμός Bedrock που δεν μπορείς να αποσυνθέσεις είναι ένας λογαριασμός που δεν μπορείς να διαχειριστείς. Αντιμετώπισε τη δαπάνη tokens ως τηλεμετρία, όχι απλώς ως γραμμή τιμολογίου: ετικέτησέ την με ετικέτες κατανομής κόστους για την προβολή τιμολόγησης, εκπέμψε μετρικές tokens ανά agent και ανά πελάτη στο CloudWatch για την προβολή πραγματικού χρόνου, και βάλε alarm στον προπορευόμενο δείκτη ώστε μια αιχμή να είναι μια ειδοποίηση, όχι μια νεκροψία. Οι ομάδες των οποίων το κόστος LLM παραμένει υπό έλεγχο δεν είναι αυτές με τις καλύτερες τιμές. Είναι αυτές που μπορούν να δουν, οποιαδήποτε στιγμή, ακριβώς ποιο feature, πελάτης, και agent ξοδεύει τα χρήματα.

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

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