Bramy API AI obsługujące limity szybkości: kształtuj obroty na minutę, TPM, impulsy i uczciwość najemców przed uderzeniem 429s

Kod 429 od dostawcy LLM to nie tylko sygnał ponownej próby. W środowisku produkcyjnym często świadczy to o tym, że aplikacja utraciła już kontrolę nad dostępem, uczciwością najemców, opóźnieniami lub rozliczaniem limitów specyficznych dla dostawcy.

Powszechne rozwiązanie — wykładnicze wycofywanie — jest konieczne, ale niekompletne. Backoff reaguje po odrzuceniu ruchu przez dostawcę. Brama API AI obsługująca limity szybkości powinna kształtować ruch, zanim żądania opuszczą Twój system: szacować obciążenie tokenów, rezerwować przydział, izolować najemców, ustawiać w kolejce właściwe prace, odrzucać niewłaściwe i dostosowywać się w przypadku zmiany limitów dostawcy.

W tym artykule opisano praktyczny regulator przydziału bramy dla zespołów wysyłających obciążenia produkcyjne do wielu dostawców LLM za pośrednictwem ujednoliconego interfejsu API.

Problem czytelnika: 429 są wielowymiarowe

Wiele zespołów traktuje limity szybkości jako pojedynczą liczbę żądań na minutę. To założenie szybko się łamie w przypadku interfejsów API LLM.

Fakty z aktualnej dokumentacji dostawcy:

• OpenAI dokumentuje, że limity mogą być egzekwowane w oknach krótszych niż reklamowany limit na minutę, więc krótkie serie mogą zakończyć się niepowodzeniem, nawet jeśli średnia minuta wygląda na bezpieczną.
• Przydział Azure OpenAI jest przypisywany według subskrypcji, regionu, modelu i typu wdrożenia w tokenach na minutę. Przypisanie modułu TPM do wdrożenia określa również wymuszone limity RPM wnioskowania, a współczynniki RPM do TPM różnią się w zależności od modelu.
• Azure OpenAI zauważa również, że obliczenia tokenów limitu szybkości są szacowane w momencie otrzymania żądania i nie są tym samym, co ostateczna liczba tokenów rozliczeniowych.
• Dokumenty Anthropic oddzielają limity żądań na minutę, tokenów wejściowych na minutę i tokenów wyjściowych na minutę. Przekroczenie limitów zwraca 429 z nagłówkiem ponawiania próby.
• Anthropic ostrzega, że gwałtowny wzrost ruchu może osiągnąć wartości graniczne przyspieszenia, i zaleca stopniowe zwiększanie prędkości.
• W przypadku większości modeli Claude dokumenty Anthropic, które tokeny wejściowe odczytują z pamięci podręcznej, nie wliczają się do limitów tokenów wejściowych na minutę, co oznacza, że szybkie buforowanie może zmienić efektywny zapas mocy.
• Limity stawek interfejsu API Google Gemini są powiązane z poziomami wykorzystania projektu, przy czym wyższe poziomy zależą od konfiguracji rozliczeń, skumulowanych wydatków i czasu, jaki upłynął od kamieni milowych płatności.

Lekcja operacyjna jest jasna: kształt żądania zgodny z OpenAI nie oznacza zachowania przydziałów zgodnego z OpenAI. Brama wielu dostawców wymaga wewnętrznego modelu przydziałów, który jest bogatszy niż „ponów próbę, jeśli 429”.

Cel projektu: uczynienie kontroli dostępu obowiązkiem bramy

Brama obsługująca limity szybkości powinna odpowiedzieć na pięć pytań przed wysłaniem żądania:

1. Który dostawca, model, wdrożenie, region, projekt lub obszar roboczy otrzyma żądanie?
2. Ile żądań, tokenów wejściowych, tokenów wyjściowych i pojemności współbieżności może to zużyć?
3. Który dzierżawca, zespół, klucz API, klient lub klasa obciążenia powinna być rozliczana w oparciu o współdzieloną pojemność?
4. Czy wniosek powinien zostać teraz przyjęty, umieszczony na krótko w kolejce, obniżony, przekierowany gdzie indziej, czy może odrzucony?
5. W jaki sposób należy uzgodnić rezerwację po zwróceniu przez dostawcę faktycznego wykorzystania?

Brama staje się zarządcą kwot. Nie zastępuje limitów dostawcy. Dzięki temu limity dostawców są widoczne, przewidywalne i sprawiedliwe w Twoim systemie.

Zbuduj znormalizowany model kwot

Zacznij od zdefiniowania wewnętrznych wymiarów ograniczających, które mogą reprezentować głównych dostawców, bez wrzucania ich do jednego wprowadzającego w błąd segmentu.

Zalecane wymiary ogranicznika

• RPM: żądań na minutę.
• Wprowadź TPM: tokeny podpowiedzi, wiadomości, narzędzi i kontekstu na minutę.
• Wyjściowy moduł TPM: tokeny ukończenia na minutę, zarezerwowane oddzielnie dla przesyłania strumieniowego i długich generacji.
• Całkowity moduł TPM: przydatny w przypadku dostawców lub wdrożeń, które eksponują łączną presję na tokeny.
• Współbieżność: aktywne żądania, aktywne strumienie lub zadania w locie.
• Czas trwania przesyłania strumieniowego: długotrwałe strumienie mogą zajmować połączenie i zapas tokena wyjściowego, nawet gdy prędkość obrotowa jest niska.
• Zakres specyficzny dla dostawcy: subskrypcja/region/wdrożenie platformy Azure, obszar roboczy/klasa modelu Anthropic, projekt/poziom Google lub organizacja/projekt/grupa modelu OpenAI.

Nie ukrywaj wymiarów specyficznych dla dostawcy. Normalizuj je w ramach wspólnego schematu, ale zachowaj wystarczająco dużo szczegółów, aby później wyjaśnić odrzucenie.

{
  "dostawca": "dostawca_a",
  "model_profile": "szybki czat",
  "zakres_dostawcy": {
    "projekt": "prod",
    "region": "us-wschód",
    „wdrożenie”: „czat-duży-01”
  },
  „limity”: {
    „obr/min”: 1200,
    "input_tpm": 800000,
    „wyjście_tpm”: 250000,
    „współbieżność”: 200
  }

Ten obiekt wewnętrzny powinien być skonfigurowany jawnie, a nie wynikać z samych nazw modeli. Pulpity dostawców, poziomy kont, wdrożenia regionalne i ustawienia obszaru roboczego mogą zmieniać efektywną pojemność tej samej rodziny modeli.

Oszacuj ciśnienie tokenów przed wysyłką

Ograniczenia stawek po stronie dostawcy często mają miejsce, zanim znane jest ostateczne wykorzystanie rozliczeń. Twoja brama powinna dokonać tego samego ostrożnego oszacowania przed wysłaniem ruchu.

Wprowadzone dane dotyczące rezerwacji przed lotem

• Serializowana długość monitu i wiadomości.
• Tokenizacja specyficzna dla modelu i narzut związany z rolami, narzędziami, obrazami lub ustrukturyzowanymi instrukcjami wyjściowymi.
• max_completion_tokens lub równoważny limit wyjściowy.
• Historyczny współczynnik ukończenia dla tego punktu końcowego, dzierżawy, profilu modelu i klasy żądania.
• Oczekiwane tokeny odczytu pamięci podręcznej, jeśli buforowanie podpowiedzi jest dostępne i mierzalne.
• Flaga transmisji i oczekiwany czas trwania transmisji.

Na początek często wystarczy prosta zasada rezerwacji:

estimated_input_tokens = tokenize(request_messages) + model_overhead
szacowana_wyjściowa_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
zarezerwowane_total_tokens = szacowane_tokensy_wejściowe + szacowane_tokensy_wyjściowe

W przypadku nieznanych tras użyj konserwatywnych ustawień domyślnych. Aby zapewnić stabilne trasy produkcyjne, stale aktualizuj szacunki na podstawie rzeczywistego wykorzystania.

Zarezerwuj, a potem uzgodnij

Rezerwacje kwot nie powinny stać się opłatami stałymi. Traktuj je jak blokady:

1. Cytat: oszacuj ciśnienie wejściowe i wyjściowe.
2. Rezerwa: odlicz od odpowiednich koszyków tokenów przed wysyłką.
3. Rozlicz się: zastąp oszacowanie wykorzystaniem zgłoszonym przez dostawcę, jeśli jest dostępne.
4. Zwrot pieniędzy lub obciążenie: zwróć niewykorzystaną zarezerwowaną pojemność lub w razie potrzeby naładuj nadwyżki w następnym oknie.

Ma to największe znaczenie w przypadku rozmów długokontekstowych i transmisji strumieniowych. Jeśli przed wysłaniem sprawdzisz tylko wejściowy moduł TPM, strumień może rozpocząć się pomyślnie, a później uruchomić token wyjściowy. Oddzielna rezerwacja zapasu wyjściowego zmniejsza ryzyko awarii strumienia środkowego i ryzyka przeciągnięcia.

Używaj hierarchicznych zasobników tokenów, aby zapewnić uczciwość najemców

Pojedynczy globalny limiter chroni konto dostawcy, ale nie chroni dzierżawców przed sobą. Jedno zadanie wsadowe o długim kontekście może zużywać współdzielony moduł TPM i powodować niepowodzenie interaktywnych żądań od innych zespołów.

Użyj hierarchicznych zasobników tokenów:

organizacja
  └── najemca
      └── zespół
          └── klucz_api
              └── profil_modelu
                  └── wdrożenie_dostawcy

Żądanie musi przejść każdy odpowiedni segment. Dzięki temu możesz egzekwować kilka zasad jednocześnie:

• Organizacja nie może przekroczyć możliwości dostawcy.
• Najemca nie może zużyć więcej, niż wynosi jego umowna część.
• Klucz API nie może przekraczać limitu zamierzonego środowiska lub aplikacji.
• Profil modelu wsadowego nie może zablokować profilu modelu interaktywnego.
• Wdrożenie dostawcy nie może zostać przeciążone, nawet jeśli inne wdrożenie ma wolny limit.

Sprawiedliwe udostępnianie a wykorzystanie

Zalecenie: stosuj ważony sprawiedliwy podział z kontrolowanym pożyczaniem impulsowym.

Ścisłe limity na jednego najemcę można łatwo wyjaśnić, ale mogą powodować utratę niewykorzystanej pojemności. Pożyczanie seryjne poprawia wykorzystanie, umożliwiając dzierżawcy tymczasowe wykorzystanie bezczynnego przydziału ze wspólnej puli. Kompromis jest złożony: pulpity nawigacyjne muszą pokazywać, co zostało objęte gwarancją, co zostało pożyczone i kiedy pożyczka została cofnięta.

Praktyczna zasada:

• Zapewnij każdemu najemcy gwarantowaną linię bazową.
• Zezwalaj na pożyczanie seryjne z niewykorzystanej współdzielonej pojemności.
• Odzyskaj pożyczoną pojemność, gdy pojawi się ruch o wyższym priorytecie lub gwarantowany.
• Nigdy nie pozwól, aby ruch pożyczony tworzył kody 429 na poziomie dostawcy w celu zapewnienia ruchu gwarantowanego.

Oddziel klasy ruchu, zanim będą ze sobą rywalizować

Nie wszystkie żądania zasługują na takie samo zachowanie w kolejce. Umieść ruch w profilach modeli z oddzielnymi kolejkami i pulami przydziałów.

Kolejkowanie poprawia wskaźnik powodzenia, ale zwiększa opóźnienie ogona. Brama powinna wyraźnie podkreślać ten kompromis. Na przykład żądanie interaktywne może czekać do 300 milisekund na przydział, a następnie zostać wycofane lub zakończyć się niepowodzeniem. Conocne zadanie wsadowe może poczekać 20 minut i nadal zostać uznane za zakończone sukcesem.

Normalizacja błędów 429 w pojedynczy schemat błędów

Nawet przy dobrej kontroli dostępu, błędy 429 dostawcy nadal będą się pojawiać. Limity mogą się zmieniać, szacunki dostawców mogą różnić się od Twoich, a ruch może pojawiać się w większych ilościach, niż oczekiwano.

Normalizuj każdego dostawcę 429 w obiekt błędu bramy:

{
  „błąd”: {
    "type": "rate_limited",
    "limiter": "wyjście_tpm",
    "dostawca": "dostawca_a",
    "model_profile": "szybki czat",
    "provider_model": "model-x",
    „retry_after_ms”: 2400,
    "ident_dzierżawcy": "dzierżawa_123",
    "api_key_id": "klucz_456",
    "request_class": "interaktywny",
    „estimated_input_tokens”: 4200,
    „estimated_output_tokens”: 800,
    "gateway_decision": "admitted_then_provider_rejected",
    „fallback_allowed”: fałsz,
    "trace_id": "trace_abc"
  }

Pole kluczowe to gateway_decision. Komunikat 429 po przyjęciu żądania przez bramę różni się od żądania, które brama odrzuciła lokalnie przed wysłaniem. Pierwsza wskazuje na problem z kalibracją ogranicznika. Drugie wskazuje na celową ochronę.

Dostosuj nagłówki dostawców, ale nie polegaj na nich

Niektórzy dostawcy zwracają przydatne nagłówki, takie jak wskaźniki ponownej próby lub pozostałej pojemności. Używaj ich, jeśli są dostępne.

Zalecenie: nagłówki dostawców powinny dostrajać lokalnego gubernatora, a nie go zastępować.

Powody:

• Dostępność nagłówka różni się w zależności od dostawcy i punktu końcowego.
• Nagłówki mogą nie ujawniać wszystkich wymiarów ograniczających.
• Ponowna próba informuje Cię, kiedy spróbować ponownie, a nie, który dzierżawca powinien uzyskać pojemność jako następny.
• Oszacowania dotyczące tokenów po stronie dostawcy mogą różnić się od danych rozliczeniowych lub wewnętrznej księgowości.

Niezawodna implementacja aktualizuje lokalne współczynniki uzupełniania zasobników i czasy odnowienia na podstawie nagłówków, jednocześnie egzekwując limity dzierżawy, klucza API, klasy ruchu i wdrożenia dostawcy wewnątrz bramy.

Dodaj zarządców ramp dla migracji i zaplanowanych zadań

Wiele incydentów związanych z limitami szybkości ma miejsce podczas planowanych zmian: przechodzenia z jednego modelu do drugiego, zmiany dostawców, włączania nowego przepływu pracy agenta lub uruchamiania zaplanowanego przebiegu próbnego.

Zalecenie: traktuj wzrost ruchu jako kontrolowane wdrożenie.

• Migracje modeli flag funkcji według dzierżawcy, trasy lub procentu ruchu.
• Ustaw pułapy wzrostu na minutę dla wdrożeń nowych dostawców.
• Stopniowo zwiększaj ruch w ciągu kilku godzin, zamiast natychmiastowo przełączać cały ruch.
• Wstrzymaj wdrażanie, gdy szybkość 429, częstotliwość obniżania wersji, głębokość kolejki lub opóźnienie p95 przekroczą próg.
• Zachowaj możliwość awaryjnego wycofania produktu zgodnie z zasadami zgodności, a nie tylko modelem zapasowym.

Przewidywanie: w miarę jak tryby routingu dostawców, poziomy priorytetów i kontrole na poziomie obszaru roboczego staną się coraz bardziej powszechne, zarządzanie rampą stanie się standardową funkcją bramy, a nie skryptem odpowiedzi na incydenty.

Praca awaryjna to decyzja polityczna, a nie tylko decyzja dotycząca wydajności

Gdy jeden dostawca zwróci kod 429, właściwym rozwiązaniem może być przekierowanie do innego dostawcy. Może to być również niebezpieczne.

Przywrócenie może ulec zmianie:

• Jakość wydruku i przestrzeganie instrukcji.
• Długość kontekstu.
• Zachowanie wywołań narzędzi.
• Niezawodność wyników strukturalnych.
• Przechowywanie danych i sposób przechowywania.
• Koszt i opóźnienia.

Zarządca przydziału powinien zapytać warstwę zgodności, czy dla tej klasy żądań dozwolona jest rezerwa. Jeśli nie, powinien ustawić się w kolejce lub zakończyć się niepowodzeniem z wyraźną odpowiedzią na lokalne ograniczenie szybkości, a nie po cichu zmieniać semantykę.

Udostępnij panele przydziałów wyjaśniające decyzje

System kwot, którego nikt nie może zrozumieć, zostanie ominięty. Twórz dashboardy wokół pytań operacyjnych:

• Którzy dzierżawcy zużywają najwięcej RPM, wejściowego i wyjściowego modułu TPM?
• Które profile modeli oczekują w kolejce, odrzucają lub wycofują się?
• Który zakres dostawcy stanowi wąskie gardło: projekt, region, wdrożenie, obszar roboczy, klasa modelu czy poziom konta?
• Jak często szacunki bramy różnią się od wykorzystania dostawcy?
• Jaka jest dystrybucja ponownych prób według dostawcy i typu ogranicznika?
• Jak dużo efektywnego zapasu powstaje w wyniku natychmiastowych odczytów pamięci podręcznej?
• Jakie klasy ruchu korzystają z przepustowości impulsowej?

W przypadku produktów przeznaczonych dla klientów lub partnerów udostępnij bezpieczne kontrole:

• Limity stawek za klucz.
• Limity serii na zespół.
• Dzienne limity na klienta.
• Przerwa awaryjna dla najemcy lub klucza.
• Alerty dotyczące skoków liczby 429, wzrostu kolejki i nieprawidłowego obciążenia tokenów.
• Punkty końcowe interfejsu API partnerów do zarządzania limitami sprzedawców.

Dzięki temu ograniczanie szybkości przestaje być tajemniczym błędem dostawcy i staje się podlegającą kontroli częścią zarządzania interfejsem API zespołu.

Lista kontrolna wdrożenia

Faza 1: obserwacja i klasyfikacja

• Rejestruj dostawcę, model, wdrożenie, region, obszar roboczy, projekt, dzierżawę, klucz API i klasę żądania dla każdego wywołania.
• Przechwytuj błędy 429 dostawcy z ponowną próbą i nieprzetworzonymi metadanymi o błędach.
• Oddzielnie rejestruj szacunkowe i rzeczywiste tokeny wejścia/wyjścia.
• Oddziel ruch interaktywny, wsadowy, ewaluacyjny i w tle w telemetrii.

Faza 2: lokalna kontrola wstępu

• Utwórz obiekty wewnętrznego ogranicznika dla RPM, wejściowego TPM, wyjściowego TPM, całkowitego TPM i współbieżności.
• Dodaj oszacowanie tokenu wstępnej inspekcji.
• Zarezerwuj limit przed wysyłką i uzgodnij po otrzymaniu wykorzystania przez dostawcę.
• Odrzuć lokalnie, jeśli żądanie nie pasuje do segmentu dzierżawcy lub dostawcy.

Faza 3: sprawiedliwość i kolejki

• Dodaj hierarchiczne segmenty z organizacji do wdrożenia dostawcy.
• Przydzielaj gwarantowane udziały najemców i kontrolowane zaciąganie pożyczek.
• Utwórz osobne kolejki według klasy ruchu.
• Ustaw maksymalne czasy oczekiwania i reguły awaryjne dla danej klasy.

Faza 4: adaptacja i operacje

• Użyj nagłówków dostawców, aby dostosować czasy odnowienia i założenia dotyczące uzupełniania.
• Dodaj zarządców ramp dla migracji i zaplanowanych zadań.
• Udostępnij panele i alerty dotyczące przydziałów.
• Cotygodniowo przeglądaj błąd szacunków i osierocony limit.

Wniosek, który można zastosować

Jeśli brama ponawia tylko błędy 429, oznacza to, że po awarii działa. Brama API AI klasy produkcyjnej powinna zapobiegać większości błędów związanych z limitami szybkości, decydując, kto może wysyłać co, kiedy i w ramach jakiego limitu dostawcy.

Zacznij od znormalizowanego modelu limitera, rezerwacji tokenów przed inspekcją i kolejek według klas ruchu. Następnie dodaj hierarchiczną uczciwość najemców, adaptację nagłówka dostawcy i zarządcy rampy. Rezultatem jest nie tylko mniejsza liczba 429. To jaśniejsza alokacja przepustowości, bardziej przewidywalne opóźnienia, bezpieczniejsze migracje i zachowanie przy ograniczaniu szybkości, które mogą w rzeczywistości wyjaśnić zespoły inżynieryjne, finansowe i obsługi klienta.

Powiązane lektury

• rezerwacja i użytkowanie przed przebiegiem uzgadnianie
• szybkie rozliczanie pamięci podręcznej i analiza trafień w pamięci podręcznej
• zgodne zasady routingu rezerwowego