Rate-Limit-Aware AI API Gateways: Shape RPM, TPM, Bursts και Tenant Fairness Before 429s Hit
Μια πρακτική αρχιτεκτονική πύλης για την αποφυγή κλιμακωτών LLM API 429: ομαλοποίηση των ορίων παρόχου, εκτίμηση της πίεσης συμβολαίου πριν από την αποστολή, δέσμευση ποσόστωσης από τον ενοικιαστή, ομαλή ράμπες κυκλοφορίας και έλεγχος του στραγγαλισμού.
Ένα 429 από έναν πάροχο LLM δεν είναι απλώς ένα σήμα επανάληψης. Κατά την παραγωγή, είναι συχνά απόδειξη ότι η αίτησή σας έχει ήδη χάσει τον έλεγχο της αποδοχής, της δικαιοσύνης των μισθωτών, του λανθάνοντος χρόνου ή της λογιστικής ποσόστωσης για συγκεκριμένο πάροχο.
Η κοινή διόρθωση - εκθετική υποχώρηση - είναι απαραίτητη αλλά ημιτελής. Το Backoff αντιδρά αφού ο πάροχος απορρίψει την κυκλοφορία. Μια πύλη API AI με επίγνωση ποσοστού θα πρέπει να διαμορφώνει την επισκεψιμότητα προτού φύγουν τα αιτήματα από το σύστημά σας: εκτιμήστε την πίεση διακριτικών, αποθεματικό όριο, απομόνωση ενοικιαστών, βάλτε στην ουρά τη σωστή εργασία, απορρίψτε τη λάθος εργασία και προσαρμοστείτε όταν αλλάζουν τα όρια παρόχου.
Αυτό το άρθρο περιγράφει έναν πρακτικό διαχειριστή ορίου πύλης για ομάδες που στέλνουν φόρτο εργασίας παραγωγής σε πολλούς παρόχους LLM μέσω ενός ενοποιημένου API.
Το πρόβλημα του αναγνώστη: Τα 429 είναι πολυδιάστατα
Πολλές ομάδες αντιμετωπίζουν τα όρια τιμών σαν να ήταν ένας αριθμός αιτημάτων ανά λεπτό. Αυτή η υπόθεση σπάει γρήγορα με τα API LLM.
Στοιχεία από την τεκμηρίωση του τρέχοντος παρόχου:
- Το OpenAI τεκμηριώνει ότι τα όρια ενδέχεται να επιβάλλονται σε μικρότερα παράθυρα από το διαφημιζόμενο όριο ανά λεπτό, επομένως οι σύντομες ριπές μπορεί να αποτύχουν ακόμα και όταν το μέσο λεπτό φαίνεται ασφαλές.
- Το όριο του Azure OpenAI εκχωρείται ανά συνδρομή, περιοχή, μοντέλο και τύπο ανάπτυξης σε διακριτικά ανά λεπτό. Η αντιστοίχιση TPM σε μια ανάπτυξη καθορίζει επίσης τα όρια επιβολής συμπερασμάτων RPM και οι λόγοι RPM προς TPM ποικίλλουν ανάλογα με το μοντέλο.
- Το Azure OpenAI σημειώνει επίσης ότι οι υπολογισμοί του διακριτικού ορίου επιτοκίου εκτιμώνται όταν λαμβάνεται το αίτημα και δεν είναι ίδιοι με τους τελικούς αριθμούς διακριτικών χρέωσης.
- Τα Anthropic έγγραφα χωρίζουν τα όρια αιτημάτων-ανά λεπτό, εισόδου-κουπόνια-ανά-λεπτό και δείκτες εξόδου-ανά λεπτό. Η υπέρβαση ορίων επιστρέφει ένα 429 με μια κεφαλίδα επανάληψης δοκιμής.
- Η Anthropic προειδοποιεί ότι η απότομη αύξηση της κυκλοφορίας μπορεί να φτάσει τα όρια επιτάχυνσης και συνιστά σταδιακή αύξηση.
- Για τα περισσότερα μοντέλα Claude, τα έγγραφα Anthropic που τα διακριτικά εισόδου ανάγνωσης προσωρινής μνήμης δεν υπολογίζονται στα όρια εισόδου ανά λεπτό, πράγμα που σημαίνει ότι η άμεση αποθήκευση στην κρυφή μνήμη μπορεί να αλλάξει τον πραγματικό χώρο.
- Τα όρια χρέωσης του Google Gemini API συνδέονται με τα επίπεδα χρήσης του έργου, με υψηλότερα επίπεδα ανάλογα με τη ρύθμιση χρέωσης, τη σωρευτική δαπάνη και τον χρόνο που έχει παρέλθει μετά τα ορόσημα πληρωμής.
Το λειτουργικό μάθημα είναι σαφές: ένα σχήμα αιτήματος συμβατό με OpenAI δεν συνεπάγεται συμπεριφορά ορίου που είναι συμβατή με OpenAI. Μια πύλη πολλών παρόχων χρειάζεται ένα εσωτερικό μοντέλο ορίου που είναι πιο πλούσιο από το "επανάληψη αν 429".
Στόχος σχεδιασμού: να γίνει ο έλεγχος εισδοχής ευθύνη πύλης
Μια πύλη με επίγνωση ποσοστού ορίου πρέπει να απαντά σε πέντε ερωτήσεις πριν από την αποστολή ενός αιτήματος:
- Ποιος πάροχος, μοντέλο, ανάπτυξη, περιοχή, έργο ή χώρος εργασίας θα λάβει το αίτημα;
- Πόση χωρητικότητα αιτήματος, διακριτικού εισόδου, διακριτικού εξόδου και συγχρονισμού μπορεί να καταναλώσει;
- Ποιος μισθωτής, ομάδα, κλειδί API, πελάτης ή κατηγορία φόρτου εργασίας πρέπει να χρεωθεί με την κοινόχρηστη χωρητικότητα;
- Θα πρέπει το αίτημα να γίνει δεκτό τώρα, να τεθεί σε ουρά για λίγο, να υποβαθμιστεί, να δρομολογηθεί αλλού ή να απορριφθεί;
- Πώς θα πρέπει να συμβιβαστεί η κράτηση αφού ο πάροχος επιστρέψει την πραγματική χρήση;
Η πύλη γίνεται κυβερνήτης ποσόστωσης. Δεν αντικαθιστά τα όρια παρόχου. Κάνει τα όρια παρόχου ορατά, προβλέψιμα και δίκαια μέσα στο δικό σας σύστημα.
Δημιουργήστε ένα κανονικοποιημένο μοντέλο ορίου
Ξεκινήστε ορίζοντας εσωτερικές διαστάσεις περιοριστή που μπορούν να αντιπροσωπεύουν τους κύριους παρόχους χωρίς να τους επιβάλλουν σε έναν παραπλανητικό κάδο.
Προτεινόμενες διαστάσεις περιοριστή
- RPM: αιτήματα ανά λεπτό.
- Εισαγωγή TPM: προτροπή, μήνυμα, εργαλείο και διακριτικά περιβάλλοντος ανά λεπτό.
- TPM εξόδου: διακριτικά ολοκλήρωσης ανά λεπτό, δεσμευμένα ξεχωριστά για ροή και μεγάλες γενιές.
- Συνολικό TPM: χρήσιμο για παρόχους ή αναπτύξεις που εκθέτουν συνδυαστική πίεση συμβολικών.
- Συγχρονισμός: ενεργά αιτήματα, ενεργές ροές ή εργασίες κατά τη διάρκεια της πτήσης.
- Διάρκεια ροής: οι ροές μεγάλης διάρκειας μπορούν να καταλαμβάνουν χώρο σύνδεσης και διακριτικού εξόδου ακόμη και όταν οι στροφές ανά λεπτό είναι χαμηλές.
- Πεδίο εφαρμογής για συγκεκριμένο πάροχο: Συνδρομή/περιοχή/ανάπτυξη Azure, κλάση χώρου εργασίας/μοντέλου Anthropic, έργο/επίπεδο Google ή οργανισμός/έργο/ομάδα μοντέλων OpenAI.
Μην κρύβετε ιδιότητες για συγκεκριμένο πάροχο. Κανονικοποιήστε τα σε ένα κοινό σχήμα, αλλά διατηρήστε αρκετές λεπτομέρειες για να εξηγήσετε αργότερα μια απόρριψη.
{
"provider": "provider_a",
"model_profile": "fast-chat",
"provider_scope": {
"έργο": "παραγωγή",
"περιοχή": "εμάς-ανατολή",
"deployment": "chat-large-01"
},
"όρια": {
"rpm": 1200,
"input_tpm": 800000,
"output_tpm": 250000,
"Συγχρονισμός": 200
}
}Αυτό το εσωτερικό αντικείμενο πρέπει να διαμορφωθεί ρητά, όχι να συνάγεται μόνο από τα ονόματα των μοντέλων. Οι πίνακες εργαλείων παρόχου, τα επίπεδα λογαριασμού, οι τοπικές αναπτύξεις και οι ρυθμίσεις χώρου εργασίας μπορούν όλα να αλλάξουν την αποτελεσματική χωρητικότητα της ίδιας οικογένειας μοντέλων.
Υπολογίστε την πίεση συμβολικού πριν από την αποστολή
Ο περιορισμός της χρέωσης από την πλευρά του παρόχου συμβαίνει συχνά πριν γίνει γνωστή η τελική χρήση χρέωσης. Η πύλη σας θα πρέπει να κάνει το ίδιο είδος συντηρητικής εκτίμησης πριν από την αποστολή επισκεψιμότητας.
Είσοδοι κράτησης πριν από την πτήση
- Σειριοποιημένη προτροπή και μήκος μηνύματος.
- Διαμόρφωση διακριτικών και επιβάρυνση για συγκεκριμένο μοντέλο για ρόλους, εργαλεία, εικόνες ή οδηγίες δομημένης εξόδου.
max_completion_tokensή ισοδύναμο όριο εξόδου.- Ιστορικός λόγος ολοκλήρωσης για αυτό το τελικό σημείο, τον μισθωτή, το προφίλ μοντέλου και την κατηγορία αιτήματος.
- Αναμενόμενα διακριτικά ανάγνωσης προσωρινής μνήμης, εάν η προσωρινή αποθήκευση προτροπής είναι διαθέσιμη και μετρήσιμη.
- Σημασία ροής και αναμενόμενη διάρκεια ροής.
Ένας απλός κανόνας κράτησης είναι συχνά αρκετός για να ξεκινήσει:
estimated_input_tokens = tokenize(request_messages) + model_overhead
εκτιμώμενες_εξόδους_tokens = min(
max_completion_tokens,
p95_historical_output_tokens_for_route
)
reserved_total_tokens = εκτιμώμενα_input_tokens + εκτιμώμενα_έξοδο_tokens
Για άγνωστες διαδρομές, χρησιμοποιήστε μια συντηρητική προεπιλογή. Για σταθερές διαδρομές παραγωγής, ενημερώνετε συνεχώς τις εκτιμήσεις από την πραγματική χρήση.
Κάντε κράτηση και μετά συμφιλίωση
Οι κρατήσεις ορίου δεν θα πρέπει να γίνονται μόνιμες χρεώσεις. Αντιμετωπίστε τα σαν δεσμά:
- Παράθεση: υπολογίστε την πίεση εισόδου και εξόδου.
- Κράτηση: αφαιρέστε από τους σχετικούς κάδους διακριτικών πριν από την αποστολή.
- Διακανονισμός: αντικαταστήστε την εκτίμηση με χρήση που αναφέρεται από τον πάροχο όταν είναι διαθέσιμη.
- Επιστροφή χρημάτων ή χρέωση: επιστρέψτε την αχρησιμοποίητη δεσμευμένη χωρητικότητα ή χρεώστε τις υπερβάσεις στο επόμενο παράθυρο, εάν χρειαστεί.
Αυτό έχει μεγαλύτερη σημασία για κλήσεις μακράς διάρκειας και ροής. Εάν ελέγξετε μόνο την είσοδο TPM πριν από την αποστολή, μια ροή μπορεί να ξεκινήσει με επιτυχία και στη συνέχεια να εκτεθεί σε πίεση διακριτικού εξόδου αργότερα. Η κράτηση χωριστού χώρου εξόδου μειώνει την αστοχία στη μέση ροή και τον κίνδυνο ακινητοποίησης.
Χρησιμοποιήστε ιεραρχικούς κάδους διακριτικών για δικαιοσύνη ενοικιαστών
Ένας μοναδικός καθολικός περιοριστής προστατεύει τον λογαριασμό παρόχου, αλλά δεν προστατεύει τους ενοικιαστές ο ένας από τον άλλο. Μια μαζική εργασία μεγάλου πλαισίου μπορεί να καταναλώσει κοινόχρηστο TPM και να προκαλέσει την αποτυχία διαδραστικών αιτημάτων από άλλες ομάδες.
Χρησιμοποιήστε ιεραρχικούς κάδους διακριτικών:
οργανισμός
└── μισθωτής
└── ομάδα
└── api_key
└── model_profile
└── provider_deployment
Ένα αίτημα πρέπει να περάσει από κάθε σχετικό κάδο. Αυτό σας επιτρέπει να επιβάλλετε πολλές πολιτικές ταυτόχρονα:
- Ο οργανισμός δεν μπορεί να υπερβαίνει τη χωρητικότητα του παρόχου.
- Ένας ενοικιαστής δεν μπορεί να καταναλώσει περισσότερο από το συμβατικό του μερίδιο.
- Ένα κλειδί API δεν μπορεί να υπερβαίνει το προβλεπόμενο περιβάλλον ή το όριο εφαρμογής του.
- Ένα προφίλ μοντέλου παρτίδας δεν μπορεί να εξαφανίσει ένα διαδραστικό προφίλ μοντέλου.
- Μια ανάπτυξη παρόχου δεν μπορεί να υπερφορτωθεί ακόμα κι αν μια άλλη ανάπτυξη έχει εφεδρικό όριο.
Δίκαιη κοινή χρήση έναντι χρήσης
Σύσταση: χρησιμοποιήστε τη σταθμισμένη δίκαιη κατανομή με ελεγχόμενο δανεισμό.
Τα αυστηρά ανώτατα όρια ανά ενοικιαστή είναι εύκολο να εξηγηθούν, αλλά μπορούν να περιορίσουν την αχρησιμοποίητη χωρητικότητα. Ο έκτακτος δανεισμός βελτιώνει τη χρήση επιτρέποντας στον ενοικιαστή να χρησιμοποιεί προσωρινά το όριο αδράνειας από μια κοινόχρηστη πισίνα. Η αντιστάθμιση είναι πολυπλοκότητα: οι πίνακες ελέγχου πρέπει να δείχνουν τι ήταν εγγυημένο, τι δανείστηκε και πότε ανακλήθηκε ο δανεισμός.
Ένας πρακτικός κανόνας:
- Δώστε σε κάθε ενοικιαστή μια εγγυημένη γραμμή βάσης.
- Να επιτρέπεται ο ριπής δανεισμός από αχρησιμοποίητη κοινόχρηστη χωρητικότητα.
- Ανακτήστε τη δανεισμένη χωρητικότητα όταν εμφανιστεί επισκεψιμότητα υψηλότερης προτεραιότητας ή εγγυημένης κίνησης.
- Μην αφήνετε ποτέ τη δανεική επισκεψιμότητα να δημιουργεί 429 σε επίπεδο παρόχου για εγγυημένη επισκεψιμότητα.
Διαχωρίστε τις κατηγορίες κυκλοφορίας πριν αντιπαρατεθούν
Δεν αξίζουν όλα τα αιτήματα την ίδια συμπεριφορά στην ουρά. Βάλτε την επισκεψιμότητα σε προφίλ μοντέλων με ξεχωριστές ουρές και ομάδες ορίων.
<πίνακας> <κεφάλι>Η ουρά βελτιώνει το ποσοστό επιτυχίας, αλλά αυξάνει τον λανθάνοντα χρόνο. Μια πύλη θα πρέπει να κάνει σαφή αυτή την ανταλλαγή. Για παράδειγμα, ένα διαδραστικό αίτημα μπορεί να περιμένει έως και 300 χιλιοστά του δευτερολέπτου για το όριο, στη συνέχεια να υποχωρήσει ή να αποτύχει. Μια νυχτερινή ομαδική εργασία μπορεί να περιμένει 20 λεπτά και εξακολουθεί να θεωρείται επιτυχημένη.
Κανονικοποιήστε τα 429 σε ένα μεμονωμένο σχήμα σφάλματος
Ακόμα και με καλό έλεγχο αποδοχής, τα 429 του παρόχου θα εξακολουθήσουν να υπάρχουν. Τα όρια μπορεί να αλλάξουν, οι εκτιμήσεις παρόχων μπορεί να διαφέρουν από τις δικές σας και η επισκεψιμότητα μπορεί να φτάσει με πιο έντονες εκρήξεις από το αναμενόμενο.
Κανονικοποιήστε κάθε πάροχο 429 σε ένα αντικείμενο σφάλματος πύλης:
{
"σφάλμα": {
"type": "rate_limited",
"limiter": "output_tpm",
"provider": "provider_a",
"model_profile": "fast-chat",
"provider_model": "model-x",
"retry_after_ms": 2400,
"tenant_id": "tenant_123",
"api_key_id": "key_456",
"request_class": "interactive",
"estimated_input_tokens": 4200,
"estimated_output_tokens": 800,
"gateway_decision": "admitted_then_provider_rejected",
"fallback_allowed": ψευδής,
"trace_id": "trace_abc"
}
}
Το πεδίο κλειδιού είναι gateway_decision. Ένα 429 μετά την αποδοχή του αιτήματος από την πύλη είναι διαφορετικό από ένα αίτημα που η πύλη απέρριψε τοπικά πριν από την αποστολή. Το πρώτο υποδεικνύει πρόβλημα βαθμονόμησης περιοριστή. Το δεύτερο υποδεικνύει σκόπιμη προστασία.
Προσαρμογή από κεφαλίδες παρόχου, αλλά μην εξαρτάστε από αυτές
Ορισμένοι πάροχοι επιστρέφουν χρήσιμες κεφαλίδες, όπως δείκτες ικανότητας επανάληψης δοκιμής ή υπολειπόμενης χωρητικότητας. Χρησιμοποιήστε τα όταν είναι διαθέσιμα.
Σύσταση: οι κεφαλίδες του παρόχου πρέπει να συντονίζουν τον τοπικό σας κυβερνήτη και όχι να τον αντικαθιστούν.
Λόγοι:
- Η διαθεσιμότητα της κεφαλίδας διαφέρει ανά πάροχο και τελικό σημείο.
- Οι κεφαλίδες ενδέχεται να μην εκθέτουν κάθε ιδιότητα περιοριστή.
- Το Retry-after σάς ενημερώνει πότε να δοκιμάσετε ξανά, όχι ποιος ενοικιαστής θα λάβει χωρητικότητα στη συνέχεια.
- Οι εκτιμήσεις διακριτικών από την πλευρά του παρόχου ενδέχεται να διαφέρουν από τη χρέωση ή την εσωτερική λογιστική σας.
Μια ισχυρή εφαρμογή ενημερώνει τους τοπικούς ρυθμούς επαναπλήρωσης του κάδου και τις καθυστερήσεις με βάση τις κεφαλίδες, ενώ εξακολουθεί να επιβάλλει τα όρια ανάπτυξης μισθωτή, κλειδιού API, κατηγορίας κυκλοφορίας και παρόχου εντός της πύλης.
Προσθέστε κυβερνήτες ράμπας για μετεγκαταστάσεις και προγραμματισμένες εργασίες
Πολλά περιστατικά ορίου ποσοστού συμβαίνουν κατά τη διάρκεια προγραμματισμένων αλλαγών: μετάβαση από το ένα μοντέλο σε άλλο, αλλαγή παρόχων, ενεργοποίηση νέας ροής εργασιών αντιπροσώπου ή έναρξη προγραμματισμένης εκτέλεσης αξιολόγησης.
Σύσταση: αντιμετωπίζετε την αύξηση της επισκεψιμότητας ως ελεγχόμενη διάθεση.
- Μετεγγραφές μοντέλων σημαίας λειτουργιών ανά μισθωτή, διαδρομή ή ποσοστό επισκεψιμότητας.
- Ορίστε ανώτατα όρια ανάπτυξης ανά λεπτό για αναπτύξεις νέων παρόχων.
- Προθερμάνετε την κυκλοφορία σταδιακά μέσα σε ώρες αντί να αλλάζετε όλη την κυκλοφορία αμέσως.
- Παύση της διάθεσης όταν ο ρυθμός 429, ο ρυθμός υποβάθμισης, το βάθος ουράς ή η καθυστέρηση p95 υπερβούν ένα όριο.
- Διατηρήστε μια διαδρομή επαναφοράς έκτακτης ανάγκης με μια πολιτική συμβατότητας, όχι απλώς ένα εφεδρικό μοντέλο.
Πρόβλεψη: καθώς οι λειτουργίες δρομολόγησης παρόχου, οι βαθμίδες προτεραιότητας και τα στοιχεία ελέγχου σε επίπεδο χώρου εργασίας γίνονται πιο συνηθισμένα, η διακυβέρνηση ράμπας θα γίνει τυπική δυνατότητα πύλης παρά σενάριο απόκρισης περιστατικού.
Η εναλλακτική είναι μια απόφαση πολιτικής, όχι απλώς μια απόφαση χωρητικότητας
Όταν ένας πάροχος επιστρέφει ένα 429, η δρομολόγηση σε άλλο πάροχο μπορεί να είναι η σωστή απάντηση. Μπορεί επίσης να μην είναι ασφαλές.
Το εναλλακτικό μπορεί να αλλάξει:
- Ποιότητα εξόδου και οδηγίες ακολουθούν.
- Μήκος περιβάλλοντος.
- Συμπεριφορά κλήσης εργαλείου.
- Αξιοπιστία δομημένης παραγωγής.
- Διατήρηση δεδομένων και στάση διαμονής.
- Κόστος και καθυστέρηση.
Ο κυβερνήτης ορίου πρέπει να ρωτήσει ένα επίπεδο συμβατότητας εάν επιτρέπεται εναλλακτική λύση για αυτήν την κατηγορία αιτήματος. Εάν όχι, θα πρέπει να βρίσκεται σε ουρά ή να αποτύχει με μια σαφή απόκριση ορίου τοπικής ταχύτητας αντί να αλλάζει σιωπηλά τη σημασιολογία.
Εκθέστε πίνακες ελέγχου ορίου που εξηγούν αποφάσεις
Ένα σύστημα ποσοστώσεων που κανείς δεν μπορεί να καταλάβει θα παρακαμφθεί. Δημιουργήστε πίνακες εργαλείων γύρω από λειτουργικές ερωτήσεις:
- Ποιοι ενοικιαστές καταναλώνουν τις περισσότερες RPM, TPM εισόδου και TPM εξόδου;
- Ποια προφίλ μοντέλων βρίσκονται στην ουρά, απορρίπτονται ή υποχωρούν;
- Ποιο εύρος παρόχου είναι το σημείο συμφόρησης: έργο, περιοχή, ανάπτυξη, χώρος εργασίας, κατηγορία μοντέλου ή επίπεδο λογαριασμού;
- Πόσο συχνά διαφέρουν οι εκτιμήσεις πύλης από τη χρήση του παρόχου;
- Τι είναι η διανομή επανάληψης μετά από πάροχο και τύπο περιοριστή;
- Πόσο αποτελεσματικός χώρος κεφαλής δημιουργείται από τις άμεσες αναγνώσεις της κρυφής μνήμης;
- Ποιες κατηγορίες επισκεψιμότητας δανείζονται χωρητικότητα ριπής;
Για προϊόντα που απευθύνονται σε πελάτες ή συνεργάτες, εκθέστε τα ασφαλή στοιχεία ελέγχου:
- Όρια χρέωσης ανά κλειδί.
- Όρια έκρηξης ανά ομάδα.
- Ημερήσια ανώτατα όρια ανά πελάτη.
- Παύση έκτακτης ανάγκης για ενοικιαστή ή κλειδί.
- Ειδοποιήσεις για 429 αιχμές, αύξηση ουρών και μη φυσιολογική πίεση συμβολικού.
- Τελικά σημεία API Partner για διαχείριση ορίων μεταπωλητή.
Αυτό μετατρέπει τον περιορισμό ποσοστών από ένα μυστηριώδες σφάλμα παρόχου σε ελεγχόμενο μέρος της διακυβέρνησης του API ομάδας.
Λίστα ελέγχου εφαρμογής
Φάση 1: παρατηρήστε και ταξινομήστε
- Καταγραφή παρόχου, μοντέλου, ανάπτυξης, περιοχής, χώρου εργασίας, έργου, μισθωτής, κλειδιού API και κατηγορίας αιτημάτων για κάθε κλήση.
- Καταλάβετε τον πάροχο 429 με μεταδεδομένα επανάληψης μετά από προσπάθεια και ακατέργαστων σφαλμάτων.
- Καταγράψτε τα εκτιμώμενα και τα πραγματικά διακριτικά εισόδου/εξόδου ξεχωριστά.
- Διαχωρίστε τη διαδραστική, ομαδική, ισολογική και επισκεψιμότητα στο παρασκήνιο στην τηλεμετρία.
Φάση 2: τοπικός έλεγχος αποδοχής
- Δημιουργήστε αντικείμενα εσωτερικού περιοριστή για RPM, TPM εισόδου, TPM εξόδου, συνολικό TPM και ταυτόχρονη.
- Προσθήκη εκτίμησης διακριτικού πριν από την πτήση.
- Κρατήστε το όριο πριν από την αποστολή και συμβιβάστε το μετά την άφιξη της χρήσης του παρόχου.
- Απορρίψτε τοπικά όταν ένα αίτημα δεν χωράει τον κάδο του μισθωτή ή του παρόχου του.
Φάση 3: δικαιοσύνη και ουρές
- Προσθέστε ιεραρχικούς κάδους από την ανάπτυξη του οργανισμού στον πάροχο.
- Εκχώρηση εγγυημένων μετοχών ενοικιαστών και ελεγχόμενου εκρηκτικού δανεισμού.
- Δημιουργήστε ξεχωριστές ουρές ανά κατηγορία κυκλοφορίας.
- Ορίστε μέγιστους χρόνους αναμονής και εναλλακτικούς κανόνες για συγκεκριμένη τάξη.
Φάση 4: προσαρμογή και λειτουργίες
- Χρησιμοποιήστε τις κεφαλίδες παρόχου για να προσαρμόσετε τις παραδοχές ψύξης και αναπλήρωσης.
- Προσθέστε κυβερνήτες ράμπας για μεταναστεύσεις και προγραμματισμένες εργασίες.
- Εκθέστε πίνακες εργαλείων και ειδοποιήσεις ορίου.
- Ελέγξτε το σφάλμα εκτίμησης και το λανθάνον όριο εβδομαδιαία.
Εκκίνητο συμπέρασμα
Εάν η πύλη σας επαναλάβει μόνο 429s, λειτουργεί μετά την αποτυχία. Μια πύλη API AI ποιότητας παραγωγής θα πρέπει να αποτρέπει τις περισσότερες αποτυχίες ορίου ποσοστού αποφασίζοντας ποιος επιτρέπεται να στέλνει τι, πότε και σε ποιο όριο παρόχου.
Ξεκινήστε με ένα κανονικοποιημένο μοντέλο περιοριστή, κράτηση διακριτικού πριν από την πτήση και ουρές κατηγορίας κυκλοφορίας. Στη συνέχεια, προσθέστε ιεραρχική δικαιοσύνη ενοικιαστών, προσαρμογή παρόχου-κεφαλίδας και ρυθμιστές ράμπας. Το αποτέλεσμα δεν είναι απλώς λιγότερα 429s. Είναι σαφέστερη κατανομή χωρητικότητας, πιο προβλέψιμος λανθάνοντας χρόνος, ασφαλέστερες μετακινήσεις και συμπεριφορά ορίου ποσοστού που μπορούν πραγματικά να εξηγήσουν οι ομάδες μηχανικής, χρηματοδότησης και υποστήριξης πελατών.