Ένα application inference profile είναι ένα ετικετοποιημένο wrapper γύρω από ένα model ARN, και είναι το μόνο πράγμα που στέκεται ανάμεσα σε σένα και έναν λογαριασμό Bedrock που λέει έναν αριθμό για ολόκληρη την εταιρεία. Δημιουργείς ένα profile που δείχνει σε ένα μοντέλο, προσαρτάς ετικέτες κατανομής κόστους, και καλείς το profile ARN αντί για το model ID. Οι ετικέτες ταξιδεύουν μαζί μέχρι το Cost Explorer και την Cost and Usage Report. Αυτός είναι όλος ο μηχανισμός, και παίρνει ένα απόγευμα.

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

Το πρόβλημα που λύνει

Χωρίς profiles, η χρήση Bedrock εμφανίζεται ως χρήση Bedrock. Παίρνεις δαπάνη ανά μοντέλο και ανά περιοχή, που σου λέει ότι το Claude Sonnet σου κόστισε πολύ τον περασμένο μήνα και τίποτα για το ποια από τις εννέα εφαρμογές σου το προκάλεσε. Η προεπιλεγμένη αναφορά δεν μπορεί να απαντήσει στο μόνο ερώτημα που ρωτά ποτέ τα οικονομικά, που είναι από ποιο budget βγαίνει αυτό. Έγραψα για το ευρύτερο σχήμα αυτού στο Your LLM Bill Is an Observability Problem. Τα profiles είναι ο συγκεκριμένος έλεγχος για το μισό της απόδοσης.

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

Δημιούργησε ένα profile που δείχνει σε ένα foundation model ή ένα system-defined cross-region profile, με ετικέτες:

aws bedrock create-inference-profile \
  --inference-profile-name "support-assistant-prod" \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --tags key=team,value=support key=app,value=assistant key=env,value=prod

Έπειτα κάλεσε το profile ARN όπου περνούσες ένα model ID:

response = client.converse(
    modelId="arn:aws:bedrock:eu-central-1:123456789012:application-inference-profile/abc123",
    messages=messages,
)

Τρεις λειτουργικές λεπτομέρειες που είναι εύκολο να χαθούν:

  • Τα profiles είναι ειδικά ανά μοντέλο. Ένα profile τυλίγει ένα μοντέλο. Έξι εφαρμογές επί τέσσερα μοντέλα ισούται με είκοσι τέσσερα profiles. Αυτός ο πολλαπλασιασμός είναι γιατί ο σχεδιασμός ετικετών σου μετράει περισσότερο απ' όσο φαίνεται: δεν ονομάζεις έναν πόρο, ορίζεις ένα πλέγμα.
  • Οι ετικέτες δεν είναι αναδρομικές. Η ενεργοποίηση μιας ετικέτας κατανομής κόστους στην κονσόλα Billing ετικετοποιεί δαπάνη από εκείνο το σημείο και μετά. Τίποτα από όσα έκανες τον περασμένο μήνα δεν παίρνει ετικέτα. Ενεργοποίησε τα κλειδιά ετικετών πριν χρειαστείς τα δεδομένα, όχι όταν κάποιος τα ζητήσει.
  • Η κοκκομετρία είναι ημερήσια, ανά τύπο χρήσης. Τα profiles σου δίνουν χρεωμένα δολάρια στο Cost Explorer και στο CUR σε ημερήσια κοκκομετρία. Δεν σου δίνουν κόστος ανά αίτημα. Αν θέλεις οικονομικά ανά αίτημα, αυτό είναι token logging στο επίπεδο εφαρμογής, ένα διαφορετικό σύστημα με διαφορετικό owner.

Σχεδιάζοντας το σχήμα ετικετών

Η παγίδα είναι το να ετικετοποιείς αυτό που είναι εύκολο να δεις αντί για αυτό που κάποιος μπορεί να αναλάβει δράση πάνω του. Κάθε κλειδί ετικέτας πρέπει να απαντά σε μια ερώτηση που ένας πραγματικός άνθρωπος κάνει σε μια πραγματική συνάντηση.

Τέσσερα κλειδιά καλύπτουν τους περισσότερους οργανισμούς:

  • team: ποιος πληρώνει. Ταίριαξέ το με την υπάρχουσα ταξινομία κέντρων κόστους σου ακριβώς. Αν τα οικονομικά το λένε cc-4471, μην εφεύρεις platform-eng· θα ξοδέψεις τον επόμενο χρόνο συντηρώντας έναν πίνακα μετάφρασης που κανείς δεν εμπιστεύεται.
  • app: ποιο workload. Η μονάδα που θα έκλεινες στην πραγματικότητα.
  • env: prod, staging, dev. Αυτό είναι εκείνο που πληρώνει τον εαυτό του πιο γρήγορα, επειδή ο πρώτος γνήσια εκπληκτικός αριθμός στους περισσότερους λογαριασμούς Bedrock είναι πόσο κοστίζει το dev.
  • feature: προαιρετικό, για εφαρμογές όπου ένα feature μπορεί να κυριαρχεί στη δαπάνη. Χρησιμοποίησέ το με φειδώ. Κάθε επιπλέον κλειδί πολλαπλασιάζει τον αριθμό των profiles σου.

Σκόπιμα εκτός λίστας: ετικέτες ανά χρήστη. Μην δημιουργείς ένα profile ανά χρήστη. Θα χτυπήσεις όρια πόρων, και η συντήρηση είναι απεριόριστη. Για απόδοση σε επίπεδο ταυτότητας, το Bedrock υποστηρίζει κατανομή κόστους βασισμένη σε IAM principal, που αποδίδει δαπάνη στην καλούσα ταυτότητα χωρίς profile ανά άτομο. Χρησιμοποίησε profiles για την κοκκομετρία team και app, και απόδοση IAM principal όταν χρειάζεσαι να ξέρεις ποιος άνθρωπος ή ρόλος υπηρεσίας προκάλεσε την αιχμή. Συνδυάζονται.

Κάν' το δομικό

Ένα σχήμα ετικετοποίησης που εξαρτάται από πειθαρχία φθείρεται. Δύο έλεγχοι το κρατούν σταθερό.

Πρώτον, δημιούργησε profiles στο IaC σου, δίπλα στην εφαρμογή που τα χρησιμοποιεί, και τράβηξε τιμές ετικετών από τις ίδιες μεταβλητές που ετικετοποιούν τους υπόλοιπους πόρους εκείνης της εφαρμογής. Ένα profile δημιουργημένο με το χέρι στην κονσόλα είναι ένα profile που θα ετικετοποιείται test για πάντα.

Δεύτερον, έκλεισε τον άμεσο δρόμο. Μόλις υπάρχουν profiles, μια εφαρμογή που καλεί ένα ακατέργαστο model ID παράγει μη ετικετοποιημένη δαπάνη, και η μη ετικετοποιημένη δαπάνη είναι ακριβώς η γραμμή που κανείς δεν διεκδικεί. Μια πολιτική IAM που αρνείται τα bedrock:InvokeModel και bedrock:Converse σε foundation-model ARNs ενώ τα επιτρέπει σε application-inference-profile ARNs κάνει τον ετικετοποιημένο δρόμο τον μόνο δρόμο. Αυτό είναι το ίδιο ένστικτο με το να ορίζεις εύρος σε έναν ρόλο για ένα task, και δεν θα επαναλάβω το επιχείρημα από το IAM for LLM Apps: Least Privilege When the Caller Is a Model, μόνο θα σημειώσω ότι ισχύει και για τον λογαριασμό σου όσο και για την ακτίνα έκρηξής σου.

Κάν' το την πρώτη μέρα. Το να προσθέσεις εκ των υστέρων μια πολιτική άρνησης σε έξι εφαρμογές που ήδη καλούν model IDs είναι μια μετανάστευση με change-freeze προσαρτημένο.

Τι παίρνεις, και τι ακόμα δεν θα έχεις

Μετά από έναν μήνα ετικετοποιημένων δεδομένων μπορείς να ομαδοποιήσεις το Cost Explorer κατά team και να δεις τον διαχωρισμό, να φιλτράρεις σε env=dev και να βρεις το batch job που κάποιος ξέχασε να τρέχει, και να κάνεις query στο CUR για κόστος ανά εφαρμογή ανά ημέρα και να το βάλεις σε ένα dashboard δίπλα στον όγκο αιτημάτων. Η ανίχνευση ανωμαλιών γίνεται επίσης χρήσιμη, επειδή ένα budget alert σε μία εφαρμογή είναι σήμα εκεί που ένα alert στη συνολική δαπάνη Bedrock είναι θόρυβος.

Τι ακόμα δεν θα έχεις: κόστος ανά αίτημα, κόστος ανά πελάτη σε μια multi-tenant εφαρμογή, και καμία ιδέα αν η δαπάνη άξιζε τον κόπο. Το πρώτο είναι token logging. Το δεύτερο χρειάζεται context tenant που το σύστημα χρέωσης δεν βλέπει ποτέ, γι' αυτό η απόδοση multi-tenant παραμένει πρόβλημα εφαρμογής. Το τρίτο δεν είναι καν ερώτημα χρέωσης. Τα profiles σου λένε πού πήγαν τα χρήματα. Δεν έχουν άποψη για το αν έπρεπε.

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

Τα application inference profiles μετατρέπουν έναν μη αποδόσιμο λογαριασμό Bedrock σε γραμμές ανά ομάδα, ανά εφαρμογή, με το κόστος του να τυλίξεις ένα model ARN. Ενεργοποίησε τα κλειδιά ετικετών πριν χρειαστείς ιστορικό, κράτα το σχήμα σε λίγα κλειδιά που ταιριάζουν με το πώς προϋπολογίζει πραγματικά ο οργανισμός σου, δημιούργησε profiles στο IaC, και άρνησε τον μη ετικετοποιημένο δρόμο με IAM ώστε η απόδοση να μην εξαρτάται από το να θυμάται κανείς. Το API είναι ένα απόγευμα. Ο σχεδιασμός ετικετών επιζεί των ανθρώπων που τον επέλεξαν.

Διάβασε αυτό στη συνέχεια

Η γενική πειθαρχία κατανομής κόστους από την οποία δανείζεται αυτό, στρατηγική ετικετοποίησης σε ολόκληρο ένα estate AWS, βρίσκεται στις σημειώσεις πεδίου στο ercan.cloud. Ο κόμβος είναι στο ercanermis.com.