Rate-Limit-Aware AI API Gateways: Shape RPM, TPM, Bursts και Tenant Fairness Before 429s Hit

Ένα 429 από έναν πάροχο LLM δεν είναι απλώς ένα σήμα επανάληψης. Στην παραγωγή, συχνά αποδεικνύεται ότι η αίτησή σας έχει ήδη χάσει τον έλεγχο της αποδοχής, της δικαιοσύνης των μισθωτών, του λανθάνοντος χρόνου ή της λογιστικής ποσόστωσης για συγκεκριμένο πάροχο.

Η κοινή διόρθωση - εκθετική υποχώρηση - είναι απαραίτητη αλλά ημιτελής. Το Backoff αντιδρά αφού ο πάροχος απορρίψει την κυκλοφορία. Η AI API gateway θα πρέπει να διαμορφώνει την επισκεψιμότητα προτού φύγουν τα αιτήματα από το σύστημά σας: εκτιμήστε την πίεση διακριτικού, αποθεματοποιήστε το όριο, απομονώστε τους ενοικιαστές, βάλτε σε ουρά τη σωστή εργασία, απορρίψτε τη λάθος εργασία και προσαρμοστείτε όταν αλλάζουν τα όρια παρόχου.

Αυτό το άρθρο περιγράφει έναν πρακτικό διαχειριστή ορίου πύλης για ομάδες που στέλνουν φόρτο εργασίας σε πολλούς παρόχους 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".

Στόχος σχεδίασης: να γίνει ο έλεγχος εισδοχής ευθύνη πύλης

Μια πύλη με επίγνωση ορίου ποσοστού θα πρέπει να απαντά σε πέντε ερωτήσεις πριν από την αποστολή ενός αιτήματος:

1. Ποιος πάροχος, μοντέλο, ανάπτυξη, περιοχή, έργο ή χώρος εργασίας θα λάβει το αίτημα;
2. Πόση χωρητικότητα αιτήματος, διακριτικού εισόδου, διακριτικού εξόδου και συγχρονισμού μπορεί να καταναλώσει;
3. Ποιος μισθωτής, ομάδα, API κλειδί, πελάτης ή κατηγορία φόρτου εργασίας πρέπει να χρεωθεί με την κοινόχρηστη χωρητικότητα;
4. Θα πρέπει το αίτημα να γίνει δεκτό τώρα, να τεθεί σε ουρά για σύντομο χρονικό διάστημα, να υποβαθμιστεί, να δρομολογηθεί αλλού ή να απορριφθεί;
5. Πώς θα πρέπει να συμβιβαστεί η κράτηση αφού ο πάροχος επιστρέψει την πραγματική χρήση;

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

Δημιουργία ενός κανονικοποιημένου μοντέλου ορίου

Ξεκινήστε ορίζοντας εσωτερικές διαστάσεις περιοριστή που μπορούν να αντιπροσωπεύουν τους μεγάλους παρόχους χωρίς να τους επιβάλλουν σε έναν παραπλανητικό κάδο.

Προτεινόμενες διαστάσεις περιοριστή

• RPM: αιτήματα ανά λεπτό.
• Είσοδος TPM: προτροπή, μήνυμα, εργαλείο και διακριτικά περιβάλλοντος ανά λεπτό.
• TPM εξόδου: κουπόνια ολοκλήρωσης ανά λεπτό, δεσμευμένα ξεχωριστά για ροή και μεγάλες γενιές.
• Σύνολο TPM: χρήσιμο για παρόχους ή αναπτύξεις που εκθέτουν συνδυασμένη πίεση συμβολικών.
• Συγχρονισμός: ενεργά αιτήματα, ενεργές ροές ή εργασίες κατά τη διάρκεια της πτήσης.
• Διάρκεια ροής: οι ροές μεγάλης διάρκειας μπορούν να καταλαμβάνουν χώρο σύνδεσης και διακριτικού εξόδου ακόμη και όταν οι στροφές ανά λεπτό είναι χαμηλές.
• Πεδίο εφαρμογής για συγκεκριμένο πάροχο: Συνδρομή/περιοχή/ανάπτυξη Azure, Anthropic χώρος εργασίας/κλάση μοντέλου, Google έργο/βαθμίδα ή OpenAI οργανισμός/έργο/ομάδα μοντέλων.

Μην αποκρύπτετε ιδιότητες για συγκεκριμένο πάροχο. Κανονικοποιήστε τα σε ένα κοινό σχήμα, αλλά διατηρήστε αρκετές λεπτομέρειες για να εξηγήσετε αργότερα μια απόρριψη.

{
  "provider": "provider_a",
  "model_profile": "fast-chat",
  "provider_scope": {
    "project": "prod",
    "region": "us-east",
    "deployment": "chat-large-01"
  },
  "limits": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "concurrency": 200
  }
}

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

Εκτιμήστε την πίεση συμβολικού πριν την αποστολή

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

Είσοδοι κράτησης πριν από την πτήση

• Σειριοποιημένη προτροπή και μήκος μηνύματος.
• Συγκεκριμένα μοντέλα και γενικά έξοδα για ρόλους, εργαλεία, εικόνες ή οδηγίες δομημένης εξόδου.
• max_completion_tokens ή ισοδύναμο όριο εξόδου.
• Ιστορικός λόγος ολοκλήρωσης για αυτό το τελικό σημείο, μισθωτή, προφίλ μοντέλου και κατηγορία αιτήματος.
• Αναμένονται διακριτικά ανάγνωσης προσωρινής μνήμης, εάν η προσωρινή αποθήκευση προτροπής είναι διαθέσιμη και μετρήσιμη.
• Σημαία ροής και αναμενόμενη διάρκεια ροής.

Ένας απλός κανόνας κράτησης είναι συχνά αρκετός για να ξεκινήσει:

estimated_input_tokens = tokenize(request_messages) + model_overhead
estimated_output_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reserved_total_tokens = estimated_input_tokens + estimated_output_tokens

Για άγνωστες διαδρομές, χρησιμοποιήστε μια συντηρητική προεπιλογή. Για σταθερές διαδρομές παραγωγής, ενημερώνετε συνεχώς τις εκτιμήσεις από την πραγματική χρήση.

Κάντε κράτηση και μετά συμφιλίωση

Οι κρατήσεις ορίου δεν πρέπει να γίνονται μόνιμες χρεώσεις. Αντιμετωπίστε τους σαν δεσμά:

1. Παράθεση: εκτίμηση της πίεσης εισόδου και εξόδου.
2. Κράτηση: αφαίρεση από τους σχετικούς κουβάδες κουπονιών πριν από την αποστολή.
3. Διακανονισμός: αντικαταστήστε την εκτίμηση με χρήση που αναφέρεται από τον πάροχο όταν είναι διαθέσιμη.
4. Επιστροφή χρημάτων ή χρέωση: επιστρέψτε την αχρησιμοποίητη δεσμευμένη χωρητικότητα ή χρεώστε υπερβάσεις στο επόμενο παράθυρο, εάν χρειαστεί.

Αυτό έχει μεγαλύτερη σημασία για κλήσεις μακράς διάρκειας και ροής. Εάν ελέγξετε μόνο την είσοδο TPM πριν από την αποστολή, μια ροή μπορεί να ξεκινήσει με επιτυχία και στη συνέχεια να εκτεθεί σε πίεση διακριτικού εξόδου αργότερα. Η κράτηση χωριστού χώρου εξόδου μειώνει την αστοχία στη μέση ροή και τον κίνδυνο ακινητοποίησης.

Χρησιμοποιήστε ιεραρχικούς κάδους διακριτικών για δικαιοσύνη ενοικιαστών

Ένας μοναδικός καθολικός περιοριστής προστατεύει τον λογαριασμό παρόχου, αλλά δεν προστατεύει τους ενοικιαστές ο ένας από τον άλλο. Μια ομαδική εργασία μεγάλου πλαισίου μπορεί να καταναλώσει κοινόχρηστο TPM και να προκαλέσει την αποτυχία διαδραστικών αιτημάτων από άλλες ομάδες.

Χρησιμοποιήστε ιεραρχικούς κάδους διακριτικών:

organization
  └── tenant
      └── team
          └── api_key
              └── model_profile
                  └── provider_deployment

Ένα αίτημα πρέπει να περάσει από κάθε σχετικό κάδο. Αυτό σας επιτρέπει να επιβάλλετε πολλές πολιτικές ταυτόχρονα:

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

Δίκαιη κοινή χρήση έναντι χρήσης

Σύσταση: χρησιμοποιήστε σταθμισμένη δίκαιη κοινή χρήση με ελεγχόμενο δανεισμό ριπής.

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

Ένας πρακτικός κανόνας:

• Δώστε σε κάθε ενοικιαστή μια εγγυημένη γραμμή βάσης.
• Να επιτρέπεται ο ριπής δανεισμός από αχρησιμοποίητη κοινόχρηστη χωρητικότητα.
• Ανακτήστε τη δανεισμένη χωρητικότητα όταν εμφανιστεί επισκεψιμότητα υψηλότερης προτεραιότητας ή εγγυημένης κυκλοφορίας.
• Μην αφήνετε ποτέ τη δανεισμένη επισκεψιμότητα να δημιουργεί 429 σε επίπεδο παρόχου για εγγυημένη επισκεψιμότητα.

Διαχωρίστε τις κατηγορίες κυκλοφορίας πριν αντιπαρατεθούν

Δεν αξίζουν όλα τα αιτήματα την ίδια συμπεριφορά στην ουρά. Βάλτε την επισκεψιμότητα σε προφίλ μοντέλων με ξεχωριστές ουρές και ομάδες ορίων.

Η ουρά βελτιώνει το ποσοστό επιτυχίας, αλλά αυξάνει τον λανθάνοντα χρόνο. Μια πύλη θα πρέπει να κάνει σαφή αυτή την ανταλλαγή. Για παράδειγμα, ένα διαδραστικό αίτημα μπορεί να περιμένει έως και 300 χιλιοστά του δευτερολέπτου για το όριο, στη συνέχεια να υποχωρήσει ή να αποτύχει. Μια νυχτερινή μαζική εργασία μπορεί να περιμένει 20 λεπτά και να εξακολουθεί να θεωρείται επιτυχημένη.

Κανονοποίηση 429 σε ένα μεμονωμένο σχήμα σφάλματος

Ακόμα και με καλό έλεγχο αποδοχής, τα πάροχος 429 θα εξακολουθήσουν να υπάρχουν. Τα όρια μπορούν να αλλάξουν, οι εκτιμήσεις των παρόχων μπορεί να διαφέρουν από τις δικές σας και η επισκεψιμότητα μπορεί να φτάσει με πιο έντονες εκρήξεις από το αναμενόμενο.

Κανονικοποίηση κάθε παρόχου 429 σε ένα αντικείμενο σφάλματος πύλης:

{
  "error": {
    "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": false,
    "trace_id": "trace_abc"
  }
}

Το πεδίο κλειδιού είναι gateway_decision. Ένα 429 μετά την αποδοχή του αιτήματος από την πύλη είναι διαφορετικό από ένα αίτημα που η πύλη απέρριψε τοπικά πριν από την αποστολή. Το πρώτο υποδεικνύει πρόβλημα βαθμονόμησης περιοριστή. Το δεύτερο υποδηλώνει σκόπιμη προστασία.

Προσαρμογή από κεφαλίδες παρόχου, αλλά μην εξαρτάστε από αυτές

Ορισμένοι πάροχοι επιστρέφουν χρήσιμες κεφαλίδες, όπως δείκτες ικανότητας επανάληψης δοκιμής ή υπολειπόμενης χωρητικότητας. Χρησιμοποιήστε τα όταν είναι διαθέσιμα.

Σύσταση: οι κεφαλίδες παρόχου θα πρέπει να συντονίζουν τον τοπικό κυβερνήτη και όχι να τον αντικαθιστούν.

Λόγοι:

• Η διαθεσιμότητα της κεφαλίδας διαφέρει ανά πάροχο και τελικό σημείο.
• Οι κεφαλίδες ενδέχεται να μην εκθέτουν κάθε ιδιότητα περιοριστή.
• Retry-after σας ενημερώνει πότε να δοκιμάσετε ξανά, όχι ποιος ενοικιαστής θα λάβει χωρητικότητα στη συνέχεια.
• Οι εκτιμήσεις διακριτικών από την πλευρά του παρόχου ενδέχεται να διαφέρουν από τη χρέωση ή την εσωτερική λογιστική σας.

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

Προσθήκη κυβερνήτων ράμπας για μετεγκαταστάσεις και προγραμματισμένες εργασίες

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

Σύσταση: αντιμετωπίζετε την αύξηση της επισκεψιμότητας ως ελεγχόμενη διάθεση.

• Μετεγγραφές μοντέλων επισήμανσης λειτουργιών ανά μισθωτή, διαδρομή ή ποσοστό επισκεψιμότητας.
• Ορίστε ανώτατα όρια ανάπτυξης ανά λεπτό για αναπτύξεις νέων παρόχων.
• Προθερμάνετε την κυκλοφορία σταδιακά με τις ώρες αντί να αλλάζετε όλη την κυκλοφορία αμέσως.
• Παύση κυκλοφορίας όταν ο ρυθμός 429, ο ρυθμός υποβάθμισης, το βάθος ουράς ή ο λανθάνοντας χρόνος p95 υπερβεί ένα όριο.
• Διατηρήστε μια διαδρομή επαναφοράς έκτακτης ανάγκης με μια πολιτική συμβατότητας, όχι απλώς ένα εφεδρικό μοντέλο.

Πρόβλεψη: καθώς οι λειτουργίες δρομολόγησης παρόχου, οι βαθμίδες προτεραιότητας και τα στοιχεία ελέγχου σε επίπεδο χώρου εργασίας γίνονται πιο κοινά, η διακυβέρνηση ράμπας θα γίνει μια τυπική δυνατότητα πύλης και όχι σενάριο απόκρισης περιστατικού.

Το εναλλακτικό είναι μια απόφαση πολιτικής, όχι απλώς μια απόφαση χωρητικότητας

Όταν ένας πάροχος επιστρέφει ένα 429, η δρομολόγηση σε άλλον πάροχο μπορεί να είναι η σωστή απάντηση. Μπορεί επίσης να μην είναι ασφαλές.

Το εναλλακτικό μπορεί να αλλάξει:

• Ποιότητα εξόδου και ακολουθούν οδηγίες.
• Μήκος περιβάλλοντος.
• Συμπεριφορά κλήσης εργαλείου.
• Αξιοπιστία δομημένης εξόδου.
• Διατήρηση δεδομένων και στάση διαμονής.
• Κόστος και καθυστέρηση.

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

Εκθέστε πίνακες ελέγχου ορίου που εξηγούν αποφάσεις

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

• Ποιοι ενοικιαστές καταναλώνουν τις περισσότερες RPM, TPM εισόδου και TPM εξόδου;
• Ποια προφίλ μοντέλων βρίσκονται στην ουρά, απορρίπτουν ή υποχωρούν;
• Ποιος παροχέας είναι το σημείο συμφόρησης: έργο, περιοχή, ανάπτυξη, χώρος εργασίας, κατηγορία μοντέλου ή επίπεδο λογαριασμού;
• Πόσο συχνά διαφέρουν οι εκτιμήσεις πύλης από τη χρήση του παρόχου;
• Τι είναι η διανομή μετά από επανάληψη ανά πάροχο και τύπο περιοριστή;
• Πόσο αποτελεσματικός χώρος κεφαλής δημιουργείται από τις άμεσες αναγνώσεις της κρυφής μνήμης;
• Ποιες κατηγορίες επισκεψιμότητας δανείζονται χωρητικότητα ριπής;

Για προϊόντα που απευθύνονται σε πελάτες ή συνεργάτες, εκθέστε τα ασφαλή στοιχεία ελέγχου:

• Όρια χρέωσης ανά κλειδί.
• Όρια ριπών ανά ομάδα.
• Ημερήσια ανώτατα όρια ανά πελάτη.
• Παύση έκτακτης ανάγκης για ενοικιαστή ή κλειδί.
• Ειδοποιήσεις για 429 αιχμές, αύξηση ουρών και μη φυσιολογική πίεση συμβολικών.
• Τελικά σημεία συνεργάτη API για διαχείριση ποσοστώσεων μεταπωλητών.

Αυτό μετατρέπει τον περιορισμό ποσοστών από ένα μυστηριώδες σφάλμα παρόχου σε ένα ελεγχόμενο μέρος της διακυβέρνησης της ομάδας API.

Λίστα ελέγχου εφαρμογής

Φάση 1: παρατηρήστε και ταξινομήστε

• Καταγραφή πάροχου, μοντέλου, ανάπτυξης, περιοχής, χώρου εργασίας, έργου, μισθωτής, κλειδιού API και κατηγορίας αιτήματος για κάθε κλήση.
• Καταλάβετε τον πάροχο 429 με μεταδεδομένα επανάληψης μετά από προσπάθεια και ακατέργαστων σφαλμάτων.
• Καταγράψτε τα εκτιμώμενα και τα πραγματικά διακριτικά εισόδου/εξόδου ξεχωριστά.
• Διαχωρίστε διαδραστική, ομαδική, ισοτιμία και επισκεψιμότητα στο παρασκήνιο στην τηλεμετρία.

Φάση 2: τοπικός έλεγχος αποδοχής

• Δημιουργία εσωτερικών αντικειμένων περιοριστή για RPM, TPM εισόδου, TPM εξόδου, συνολικό TPM και συγχρονισμό.
• Προσθήκη εκτίμησης διακριτικού πριν από την πτήση.
• Κρατήστε το όριο πριν από την αποστολή και συμβιβάστε μετά την άφιξη της χρήσης του παρόχου.
• Απορρίψτε τοπικά όταν ένα αίτημα δεν χωράει τον κάδο του μισθωτή ή του παρόχου.

Φάση 3: δικαιοσύνη και ουρές

• Προσθέστε ιεραρχικούς κάδους από την ανάπτυξη του οργανισμού στον πάροχο.
• Εκχώρηση εγγυημένων μετοχών ενοικιαστών και ελεγχόμενου δανεισμού.
• Δημιουργήστε ξεχωριστές ουρές ανά κατηγορία κυκλοφορίας.
• Ορίστε μέγιστους χρόνους αναμονής και εναλλακτικούς κανόνες για συγκεκριμένη κατηγορία.

Φάση 4: προσαρμογή και λειτουργίες

• Χρησιμοποιήστε κεφαλίδες παρόχου για να προσαρμόσετε τις παραδοχές ψύξης και αναπλήρωσης.
• Προσθέστε κυβερνήτες ράμπας για μετεγκαταστάσεις και προγραμματισμένες εργασίες.
• Εκθέστε πίνακες ελέγχου ορίου και ειδοποιήσεις.
• Ελέγξτε το σφάλμα εκτίμησης και το λανθάνον όριο εβδομαδιαίως.

Εκκίνητο συμπέρασμα

Εάν η πύλη σας επαναλαμβάνει μόνο 429s, λειτουργεί μετά την αποτυχία. Μια πύλη ποιότητας AI API θα πρέπει να αποτρέπει τις περισσότερες αποτυχίες ορίου ποσοστού αποφασίζοντας ποιος επιτρέπεται να στέλνει τι, πότε και σε ποιο όριο παρόχου.

Ξεκινήστε με ένα κανονικοποιημένο μοντέλο περιοριστή, κράτηση διακριτικού πριν από την πτήση και ουρές κατηγορίας κυκλοφορίας. Στη συνέχεια, προσθέστε ιεραρχική δικαιοσύνη ενοικιαστών, προσαρμογή παρόχου-κεφαλίδας και ρυθμιστές ράμπας. Το αποτέλεσμα δεν είναι απλώς λιγότερα 429s. Είναι σαφέστερη κατανομή χωρητικότητας, πιο προβλέψιμος λανθάνοντας χρόνος, ασφαλέστερες μετακινήσεις και συμπεριφορά ορίου ρυθμού που μπορούν πραγματικά να εξηγήσουν οι ομάδες μηχανικής, χρηματοδότησης και υποστήριξης πελατών.

Σχετική ανάγνωση

• κράτηση και χρήση πριν από την πτήση reconciliation
• prompt accounting cache and cache-hit analytics
• συμβατές εναλλακτικές πολιτικές δρομολόγησης