Το Amazon Bedrock εκθέτει πλέον τα όρια tokens ανά λεπτό του Mantle endpoint του στην τυπική κονσόλα AWS Service Quotas. Μπορείτε να διαβάσετε απευθείας τα ανά μοντέλο όρια input-tokens-per-minute και output-tokens-per-minute, και να ζητήσετε αυξήσεις μέσα από την ίδια ροή εργασίας που χρησιμοποιείτε ήδη για όλα τα υπόλοιπα στο AWS. Αυτό ακούγεται σαν μια μικρή αλλαγή στην κονσόλα. Για όποιον τρέχει multi-agent συστήματα στην παραγωγή, είναι η διαφορά ανάμεσα στο να σχεδιάζετε τη χωρητικότητά σας και στο να την ανακαλύπτετε ως ένα τείχος από 429.

Η χρήσιμη επαναδιατύπωση είναι η εξής: για τα agentic workloads, τα tokens ανά λεπτό, όχι τα requests ανά λεπτό, είναι το πραγματικό όριο κλιμάκωσής σας. Οι περισσότερες ομάδες δεν το εσωτερικεύουν αυτό μέχρι που ένας στόλος από agents που δούλευε μια χαρά σε ένα demo αρχίζει να δέχεται throttling υπό πραγματική κίνηση. Τώρα που ο αριθμός είναι ορατός, η δουλειά είναι να τον αντιμετωπίσετε σαν ένα σχέδιο χωρητικότητας αντί για μια έκπληξη.

Τι είναι το Mantle, σύντομα

Το Bedrock Mantle endpoint (bedrock-mantle) είναι αυτό που σας δίνει το OpenAI Responses API, το OpenAI Chat Completions API και το Anthropic Messages API πάνω στο Bedrock, με ελάχιστες αλλαγές σε κώδικα γραμμένο για αυτά τα native APIs. Είναι αυτό που σας επιτρέπει να στρέψετε έναν υπάρχοντα agent σχήματος OpenAI ή Anthropic προς το Bedrock χωρίς να ξαναγράψετε τα σημεία κλήσης σας. Η αλλαγή στα quotas σημαίνει ότι κάθε μοντέλο πίσω από αυτό το endpoint αναφέρει πλέον τα όριά του input και output TPM ως εγγραφές πρώτης κατηγορίας στο Service Quotas.

Γιατί το TPM είναι το ταβάνι για τους agents, όχι το RPM

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

Τα agentic συστήματα σπάνε αυτή την αναλογικότητα. Μια μεμονωμένη εργασία χρήστη διακλαδώνεται: ένας planner agent την αποσυνθέτει, δημιουργεί sub-agents, κάθε sub-agent κάνει αρκετές κλήσεις σε εργαλεία, κάθε κλήση κουβαλάει το system prompt, το συσσωρευμένο context, τα tool schemas και τη συλλογιστική του μοντέλου ξανά προς τα έξω. Το κόστος σε tokens μιας εργασίας ορατής στον χρήστη δεν είναι ένα prompt και μία ολοκλήρωση. Είναι δεκάδες από αυτά, και το context τείνει να μεγαλώνει σε κάθε βήμα.

Έτσι η κατανάλωση tokens σας κλιμακώνεται με agents επί βήματα επί μέγεθος context, όχι με χρήστες. Μπορεί να είστε πολύ μακριά από οποιοδήποτε όριο ρυθμού request και να περάσετε ίσια μέσα από το ταβάνι των tokens ανά λεπτό, επειδή κάθε request είναι μεγάλο και υπάρχουν πολλά από αυτά ανά εργασία. Ακριβώς γι' αυτό ο ανά μοντέλο αριθμός TPM είναι αυτός που πρέπει να παρακολουθείτε, και γι' αυτό έχει σημασία που βρίσκεται στο Service Quotas.

Ο τρόπος αποτυχίας, με τη σειρά

Όταν περνάτε τη γραμμή του TPM, το Bedrock επιστρέφει ένα ThrottlingException (ένα HTTP 429). Από μόνο του αυτό είναι εντάξει. Το πρόβλημα είναι τι κάνει στη συνέχεια ένα multi-agent σύστημα:

  • Η κλήση που έφαγε throttling κάνει retry με backoff. Το ίδιο και οι άλλοι agents που χτύπησαν το ίδιο ανά μοντέλο quota μέσα στο ίδιο λεπτό.
  • Τα retries είναι τα ίδια κατανάλωση tokens έναντι του ίδιου ταβανιού, οπότε ένας στόλος υπό φορτίο μπορεί να κρατάει τον εαυτό του σε throttling.
  • Η καθυστέρηση ανεβαίνει καθώς οι κλήσεις στοιβάζονται πίσω από τους χρονομετρητές backoff. Μια εργασία που έπαιρνε οκτώ δευτερόλεπτα τώρα παίρνει σαράντα, ή έχει timeout.
  • Οι μερικές αποτυχίες αφήνουν τους agents σε ασυνεπείς καταστάσεις: ο planner νομίζει ότι μια υπο-εργασία έτρεξε, ο sub-agent δεν πήρε ποτέ ούτε ένα token output.

Τίποτα από αυτά δεν εμφανίζεται σε ένα περιβάλλον ανάπτυξης ενός χρήστη, επειδή ένας μόνο developer δεν παράγει ποτέ αρκετά tokens ανά λεπτό για να σκαλώσει στο όριο. Εμφανίζεται την πρώτη φορά που φτάνει πραγματική ταυτοχρονία, που είναι η χειρότερη δυνατή στιγμή για να μάθετε το ταβάνι σας.

Μοντελοποιήστε τον προϋπολογισμό tokens σας πριν κάνετε ship

Τα μαθηματικά δεν είναι δύσκολα, και αξίζει να γίνουν στο χαρτί πριν γίνουν από ένα incident. Για ένα δεδομένο μοντέλο, εκτιμήστε:

tokens_per_minute =
    concurrent_tasks
  × agents_per_task
  × model_calls_per_agent
  × avg_tokens_per_call        # input + output
  × (1 / task_duration_minutes)

Στη συνέχεια συγκρίνετε το input και το output ξεχωριστά έναντι των quotas input-TPM και output-TPM που μπορείτε πλέον να διαβάσετε, επειδή διέπονται ανεξάρτητα και το agentic output (συλλογιστική, μακριά ορίσματα εργαλείων) υποτιμάται εύκολα. Αν ο προβλεπόμενος αριθμός σας κάθεται οπουδήποτε πάνω από περίπου το 70 τοις εκατό του quota στην αναμενόμενη αιχμή, δεν έχετε περιθώριο, έχετε ένα μελλοντικό incident με ημερομηνία πάνω του.

Παρακολουθήστε το, μην το υποθέτετε

Μπορείτε να βγάλετε λίστα με τα quotas απευθείας από το CLI αντί να κάνετε κλικ μέσα από την κονσόλα:

aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'tokens per minute')].[QuotaName,Value]" \
  --output table

Συνδυάστε το με τις μετρικές χρήσης του Bedrock στο CloudWatch και βάλτε ένα alarm στο 70 έως 80 τοις εκατό του TPM κάθε μοντέλου. Ο στόχος είναι να μάθετε ότι πλησιάζετε το ταβάνι από ένα dashboard, μια Τρίτη, και όχι από τους χρήστες σας μια Παρασκευή βράδυ.

Μέτρα μετριασμού που δεν είναι "ζήτα περισσότερο quota"

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

  • Περιορίστε το context. Η μεγαλύτερη πηγή κατανάλωσης tokens στους agents είναι το να σέρνετε όλο το ιστορικό και κάθε tool schema σε κάθε βήμα. Περάστε μόνο ό,τι χρειάζεται το βήμα.
  • Κάντε cache τα prompts. Τα σταθερά system prompts και οι ορισμοί εργαλείων είναι τα ίδια tokens σε κάθε κλήση. Το prompt caching τα βγάζει από το κοντέρ.
  • Βάλτε όριο στην ταυτοχρονία και κάντε queue. Ένα φραγμένο worker pool μπροστά από το μοντέλο μετατρέπει μια αιχμή tokens σε ένα ελαφρώς πιο αργό αλλά επιβιώνον σύστημα, αντί για μια καταιγίδα throttling.
  • Δρομολογήστε ανά δυσκολία. Δεν χρειάζεται κάθε βήμα το frontier μοντέλο. Στείλτε τα φθηνά, μηχανικά βήματα σε ένα μικρότερο, φθηνότερο μοντέλο και κρατήστε το ακριβό για συλλογιστική που το αξίζει.
  • Ξεχωρίστε την πειθαρχία input και output. Τα μακριά outputs χρεώνονται και υφίστανται throttling στο δικό τους quota. Περιορίστε τα μέγιστα output tokens ανά βήμα ώστε μια ανεξέλεγκτη παραγωγή να μην μπορεί να φάει μόνη της το output TPM σας.

Όταν όντως ζητήσετε αύξηση

Ανοίξτε το request στο Service Quotas έναντι της συγκεκριμένης εγγραφής input ή output TPM του μοντέλου, και φέρτε μαζί τα μαθηματικά προϋπολογισμού παραπάνω. Το AWS εγκρίνει αυξήσεις γρηγορότερα όταν μπορείτε να δείξετε προβλεπόμενο φορτίο αιχμής και την ανά εργασία ανάλυση tokens, παρά έναν στρογγυλό αριθμό βγαλμένο από αισιοδοξία. Αντιμετωπίστε το ως αίτημα χωρητικότητας, επειδή αυτό ακριβώς είναι.

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

Η έκθεση των token quotas του Mantle στο Service Quotas είναι απαραίτητη, όχι επαρκής. Το ότι ο αριθμός είναι ορατός δεν σας προστατεύει. Σημαίνει απλώς ότι δεν έχετε πια δικαιολογία για να σας πιάσει εξ απήνης. Για τα agentic συστήματα, τα tokens ανά λεπτό είναι το φέρον όριο, και οι ομάδες που κάνουν ship αξιόπιστους agents είναι αυτές που μοντελοποιούν αυτόν τον προϋπολογισμό, τον παρακολουθούν, και σχεδιάζουν την κατανάλωση tokens τους προς τα κάτω πριν καν ζητήσουν από το AWS να ανεβάσει το ταβάνι.

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

Για την πλευρά της υποδομής και της πλατφόρμας στο να τρέχετε αυτό με ασφάλεια σε κλίμακα, οι cloud σημειώσεις πεδίου βρίσκονται στο ercan.cloud, συμπεριλαμβανομένης της έγκρισης πολλαπλών μερών για τις υψηλού ρίσκου λειτουργίες που οι agents δεν θα έπρεπε ποτέ να τρέχουν μόνοι. Για consulting σε AWS, AI και εργασία πλατφόρμας, ή απλώς για ένα γεια, ξεκινήστε από το ercanermis.com.