Rate limits σε AI APIs: 429 errors, retries και queues χωρίς να σταματά ο agent
Ένας AI agent λειτουργεί κανονικά στις δοκιμές και αποτυγχάνει μόλις πολλοί χρήστες τον χρησιμοποιήσουν μαζί. Οι κλήσεις επιστρέφουν 429, τα retries πολλαπλασιάζουν την κίνηση και οι εργασίες μένουν στη μέση. Το πρόβλημα δεν λύνεται απλώς με μεγαλύτερο API limit. Χρειάζεται σχεδιασμός για περιορισμένη χωρητικότητα.
Τα AI APIs μπορούν να περιορίζουν requests, input ή output tokens, concurrent εργασίες και ημερήσια χρήση. Επιπλέον, διαφορετικά models ή projects μπορεί να έχουν διαφορετικά όρια. Μια production εφαρμογή πρέπει να θεωρεί το rate limiting φυσιολογική κατάσταση λειτουργίας, όχι απρόβλεπτη εξαίρεση.
Δεν σημαίνουν όλα τα 429 το ίδιο
Ο κωδικός HTTP 429 συχνά συνδέεται με προσωρινή υπέρβαση ρυθμού, αλλά μπορεί να δείχνει εξαντλημένο credit balance ή spend limit. Η επίσημη βοήθεια της OpenAI ξεχωρίζει rate limit, ανεπαρκές υπόλοιπο και όρια οργανισμού ή project. Η τυφλή επανάληψη ενός billing error δεν θα το διορθώσει.
Η εφαρμογή πρέπει να διαβάζει error code, μήνυμα και response headers. Ένα προσωρινό limit μπορεί να δοκιμαστεί ξανά. Ένα quota ή billing πρόβλημα απαιτεί alert και διαχειριστική ενέργεια. Ένα invalid request δεν πρέπει να μπαίνει σε retry loop.
Χρήσιμη ταξινόμηση είναι:
- retryable throttling με προτεινόμενο χρόνο αναμονής
- προσωρινό provider failure ή timeout
- μη retryable validation ή authentication error
- exhausted credits ή enforced spend limit
- application-level budget που επέβαλε η ίδια η επιχείρηση
Requests ανά λεπτό και tokens ανά λεπτό
Δύο requests δεν έχουν πάντα το ίδιο βάρος. Ένα μικρό classification prompt και μια μεγάλη ανάλυση εγγράφου καταναλώνουν διαφορετικά tokens. Γι' αυτό ο agent μπορεί να βρίσκεται κάτω από το request limit αλλά πάνω από το token limit.
Τα headers του OpenAI API περιλαμβάνουν, μεταξύ άλλων, limits και remaining values για requests και tokens, καθώς και χρόνους reset. Η εφαρμογή μπορεί να χρησιμοποιεί αυτά τα στοιχεία για observability και adaptive pacing, χωρίς να υποθέτει σταθερούς αριθμούς μέσα στον κώδικα.
Σημασία έχει και το max_output_tokens. Αν ο provider δεσμεύει χωρητικότητα με βάση το πιθανό output, μια υπερβολικά μεγάλη τιμή μπορεί να αυξάνει την πίεση ακόμη κι αν οι απαντήσεις είναι συνήθως μικρές. Τα όρια πρέπει να ταιριάζουν στην πραγματική εργασία.
Γιατί τα bursts προκαλούν προβλήματα
Ένα όριο ανά λεπτό δεν σημαίνει ότι όλες οι κλήσεις μπορούν να σταλούν στο πρώτο δευτερόλεπτο. Η OpenAI επισημαίνει ότι τα limits μπορεί να εφαρμόζονται σε μικρότερα χρονικά διαστήματα. Ένα burst από background jobs μπορεί επομένως να προκαλέσει 429 παρότι ο μέσος όρος του λεπτού φαίνεται αποδεκτός.
Χρειάζεται client-side limiter που απλώνει τις κλήσεις στον χρόνο. Συνήθεις προσεγγίσεις είναι token bucket ή leaky bucket, μαζί με semaphore για το μέγιστο concurrency. Ο limiter πρέπει να γνωρίζει τουλάχιστον model, provider και project, επειδή δεν μοιράζονται όλα την ίδια δεξαμενή.
Σε distributed εφαρμογή, ένας limiter μόνο μέσα σε κάθε server δεν αρκεί. Δέκα instances μπορεί να πιστεύουν ότι καθένα έχει ολόκληρο το όριο. Χρειάζεται κοινός coordinator ή queue με συνολική εικόνα.
Retry-After, exponential backoff και jitter
Όταν υπάρχει έγκυρο Retry-After, η εφαρμογή περιμένει τουλάχιστον όσο υποδεικνύει ο provider. Αν δεν υπάρχει, χρησιμοποιεί exponential backoff: κάθε αποτυχία αυξάνει την καθυστέρηση. Το jitter προσθέτει μικρή τυχαιότητα, ώστε εκατοντάδες workers να μη ξυπνήσουν ταυτόχρονα και δημιουργήσουν νέο κύμα.
Η επίσημη οδηγία της OpenAI προτείνει backoff με jitter, περιορισμό του αριθμού retries και περιορισμό του συνολικού χρόνου. Επισημαίνει επίσης ότι τα αποτυχημένα requests μπορεί να μετρούν στο limit, άρα το συνεχές retry επιδεινώνει το πρόβλημα.
Τα retries χρειάζονται budget. Μια interactive ερώτηση μπορεί να περιμένει λίγα δευτερόλεπτα, ενώ ένα nightly batch μπορεί να περιμένει λεπτά. Μετά το deadline, η εργασία αποτυγχάνει ελεγχόμενα ή μεταφέρεται σε dead-letter queue.
Πρέπει επίσης να γνωρίζουμε αν το SDK κάνει ήδη retries. Διπλό retry layer μπορεί να μετατρέψει τρεις προσπάθειες του SDK επί τρεις της εφαρμογής σε εννέα πραγματικές κλήσεις.
Queues και backpressure
Όταν η εισερχόμενη εργασία ξεπερνά προσωρινά τη χωρητικότητα του provider, η queue απορροφά το burst. Δεν πρέπει όμως να γίνεται απεριόριστη αποθήκη. Χρειάζονται μέγιστο μήκος, TTL εργασίας και backpressure προς το UI ή το upstream σύστημα.
Οι εργασίες μπορούν να έχουν priorities:
- άμεσες ενέργειες χρήστη
- κρίσιμα operational tasks
- κανονικά background jobs
- χαμηλής προτεραιότητας enrichment ή reprocessing
Έτσι ένα μεγάλο import δεν μπλοκάρει το live support chatbot. Η προτεραιοποίηση χρειάζεται fairness, ώστε οι χαμηλότερες ουρές να μη μένουν μόνιμα πίσω.
Ο worker δεσμεύει εργασία μόνο όταν υπάρχει concurrency slot και εκτιμώμενο token budget. Αν το provider response δείξει χαμηλό remaining capacity, μειώνει προσωρινά τον ρυθμό. Αυτό είναι πιο σταθερό από το να στέλνει μέχρι να λάβει μαζικά 429.
Idempotency και tool side effects
Η επανάληψη μιας model call συνήθως δημιουργεί νέα απάντηση. Αν όμως ο agent έχει ήδη καλέσει tool που έστειλε email, δημιούργησε ticket ή ενημέρωσε CRM, η επανεκτέλεση μπορεί να διπλασιάσει την ενέργεια.
Κάθε επιχειρησιακή εργασία χρειάζεται stable operation ID. Τα side-effecting tools ελέγχουν αν το operation ολοκληρώθηκε πριν το εκτελέσουν ξανά. Το checkpoint του agent καταγράφει ποιο βήμα πέτυχε, ώστε μετά από 429 να συνεχίσει από ασφαλές σημείο αντί να ξεκινήσει ολόκληρη τη ροή.
Το model output από μόνο του δεν αποτελεί απόδειξη ότι η ενέργεια εκτελέστηκε. Η κατάσταση προκύπτει από το σύστημα που κατέχει το side effect και αποθηκεύεται ξεχωριστά.
Fallback model και graceful degradation
Ένα fallback σε μικρότερο model μπορεί να βοηθήσει μόνο αν έχει διαφορετικό διαθέσιμο limit και αν έχει δοκιμαστεί για τη συγκεκριμένη εργασία. Δεν πρέπει να χρησιμοποιείται για να παρακάμπτει αυθαίρετα spend controls ή για tasks όπου η ποιότητα πέφτει κάτω από αποδεκτό όριο.
Άλλες μορφές degradation είναι η συντόμευση context, η μείωση output allowance, η προσωρινή απενεργοποίηση μη κρίσιμου enrichment και η async ολοκλήρωση. Το UI μπορεί να ενημερώσει ότι η εργασία βρίσκεται σε ουρά, αντί να κρατά ανοιχτό request μέχρι timeout.
Η απόφαση fallback καταγράφεται μαζί με model, λόγο και αποτέλεσμα, ώστε να αξιολογηθεί αργότερα.
Observability και capacity planning
Χωρίς metrics, τα rate limits μοιάζουν τυχαία. Χρειάζεται παρακολούθηση ανά provider, model και workload:
- requests και tokens ανά χρονικό παράθυρο
- 429 ανά error code και αιτία
- queue depth και ηλικία παλαιότερης εργασίας
- retry count και συνολικό retry delay
- success rate μετά από retry
- latency, token usage και κόστος ανά task
- concurrency και dropped ή expired jobs
Τα request IDs του provider πρέπει να καταγράφονται για troubleshooting, χωρίς να αποθηκεύονται prompts ή προσωπικά δεδομένα χωρίς λόγο. Alerts χρειάζονται πριν γεμίσει η queue, όχι μόνο όταν σταματήσει ολόκληρη η υπηρεσία.
Το capacity test πρέπει να περιλαμβάνει πραγματικά μεγέθη prompts και bursts. Ένα benchmark με δέκα μικρές κλήσεις δεν προβλέπει τη συμπεριφορά εκατό ταυτόχρονων αναλύσεων PDF.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε τους AI agents με σαφή όρια concurrency, token budgets και προτεραιότητες εργασιών. Διαχωρίζουμε τα interactive requests από τα batches, τοποθετούμε queues όπου χρειάζονται και εφαρμόζουμε bounded retries που σέβονται Retry-After και deadlines.
Στις production υλοποιήσεις μας, συνδέουμε κάθε εργασία με operation ID και checkpoints, ώστε ένα retry να μην επαναλαμβάνει email, CRM updates ή άλλες side effects. Παρακολουθούμε rate-limit headers, queue age, token consumption και success rate ανά model. Προβλέπουμε επίσης graceful degradation και alerts για quota ή billing προβλήματα, ώστε η ομάδα να γνωρίζει τι συμβαίνει πριν επηρεαστούν όλοι οι χρήστες.
Checklist για production AI εφαρμογή
- Ξεχωρίζονται προσωρινά 429 από quota και billing errors;
- Υπάρχει limiter για requests, tokens και concurrency;
- Συντονίζονται όλα τα application instances στο ίδιο όριο;
- Τα retries σέβονται
Retry-After, backoff, jitter και deadline; - Έχει ληφθεί υπόψη το retry behavior του SDK;
- Υπάρχουν queue priorities, TTL και backpressure;
- Είναι idempotent τα tools με side effects;
- Μετρώνται queue age, 429, retries, tokens και κόστος;
Τα rate limits δεν είναι απλώς περιορισμός του provider. Είναι σήμα χωρητικότητας που η εφαρμογή πρέπει να μετατρέψει σε ομαλή ροή. Με pacing, queues και ασφαλή retries, ο agent μπορεί να παραμένει αξιόπιστος ακόμη και όταν η ζήτηση αυξάνεται απότομα.