Routing w warstwie usług w bramie API AI: szybki, standardowy, udostępniany i wsadowy bez dostawców kodowania na stałe

Routing na poziomie usług to warstwa zasad decydująca, czy żądanie sztucznej inteligencji zasługuje na wysoką wydajność o małych opóźnieniach, normalną pojemność na żądanie, zarezerwowaną przepustowość lub tańsze przetwarzanie asynchroniczne. Bez tej warstwy zespoły aplikacyjne zwykle kodują flagi specyficzne dla dostawcy, nazwy wdrożeń i wsadowe punkty końcowe bezpośrednio w kodzie produktu. To sprawia, że opóźnienia, koszty, limity i zachowania związane z rozliczeniami najemców są trudne do kontrolowania.

Brama powinna ujawniać zamiar obciążenia, a nie mechanikę dostawcy. Zespół ds. produktu powinien móc powiedzieć „to jest interaktywna odpowiedź pomocy technicznej” lub „to jest nocne zadanie polegające na wzbogacaniu”, podczas gdy brama odwzorowuje tę intencję na odpowiednią opcję wydajności wyższego szczebla i rejestruje, co faktycznie się wydarzyło.

Problem czytelnika: klasy wydajności stają się logiką aplikacji

Zespoły korzystające z więcej niż jednego dostawcy modeli często zaczynają od prostego wyznaczania tras modeli: wyślij ten identyfikator modelu do tego dostawcy. Routing staje się trudniejszy, gdy dostawcy udostępniają różne klasy wydajności:

• Doskonała obsługa żądań z niskim opóźnieniem dla ścieżek dostępnych dla użytkownika.
• Standardowa pojemność współdzielona dla zwykłego ruchu synchronicznego.
• Dedykowana lub zapewniona pojemność zapewniająca przewidywalną przepustowość.
• Wsadowe lub asynchroniczne interfejsy API dla obciążeń odpornych na opóźnienia.
• Zachowanie dodatkowe w przypadku wyczerpania zarezerwowanej pojemności.

Jeśli każda aplikacja sama dokonuje tych wyborów, organizacja traci kontrolę nad czterema rzeczami: kto może korzystać z pojemności premium, ile to kosztuje, co się dzieje, gdy pojemność jest niedostępna oraz czy wybrany poziom ulepszył produkt na tyle, aby uzasadnić wydatki.

Praktyczny schemat polega na umieszczeniu warstwy jakości usług neutralnej dla dostawcy wewnątrz bramy AI API.

Fakty, na których można się oprzeć

Szczegóły różnią się w zależności od dostawcy, ale kilka możliwych do zaobserwowania faktów potwierdza konstrukcję na poziomie bramy.

• Fakt: niektórzy dostawcy udostępniają warstwę usług na żądanie w celu przetwarzania premium. OpenAI opisuje tryb szybki jako opcję na żądanie przy użyciu parametru service_tier i twierdzi, że jest naliczany z wyższą opłatą w stosunku do przetwarzania standardowego. OpenAI stwierdza również, że 30 lipca 2026 r. nazwę przetwarzania priorytetowego zmieniono na tryb szybki, podczas gdy zarówno service_tier=priority, jak i service_tier=fast są akceptowane w przypadku żądań API.
• Fakt: Obsługa żądań premium może nie być odrębnym obszarem przydziałów. OpenAI zauważa, że limity szybkości trybu szybkiego są współdzielone z innymi poziomami usług i że szybki wzrost ruchu może wywołać zachowanie o narastającej szybkości, w wyniku którego część ruchu może zamiast tego zostać wysłana do przetwarzania standardowego.
• Fakt: Poziom usług może obejmować wymiar raportowania i rozliczeń. OpenAI twierdzi, że klienci korzystający z interfejsów API mogą grupować dane z panelu użytkowania według warstwy usług i elementu zamówienia. Dokumenty antropiczne standard, priority i batch jako wartości poziomu usług w raportach użycia interfejsu API.
• Fakt: interfejsy API usługi Batch mogą znacząco obniżyć koszty pracy asynchronicznej. Dokumentacja cenowa Anthropic mówi, że interfejs API Batch obsługuje asynchroniczne przetwarzanie dużych ilości danych z 50% rabatem na tokeny wejściowe i wyjściowe. Dokumentacja Google Gemini Batch API opisuje duże asynchroniczne obciążenia przy 50% standardowego kosztu, z kompromisami w zakresie realizacji, takimi jak do 24 godzin w przypadku niektórych zadań o dużej objętości.
• Fakt: zapewniona przepustowość to osobny model wydajności. Firma Microsoft dokumentuje przepustowość aprowizowaną platformą Azure OpenAI jako pojemność dedykowaną, w przeciwieństwie do wdrożeń standardowych, w których pojemność jest współdzielona, ​​a przepustowość może się różnić w zależności od zapotrzebowania. Firma Microsoft dokumentuje również przejście z wdrożeń aprowizowanych do wdrożeń standardowych w tym samym zasobie Azure OpenAI.

Zaleca się, aby nie odzwierciedlać każdego terminu dostawcy w kodzie aplikacji. Zaleca się normalizację tych mechanizmów w ramach poziomów bram zorientowanych na biznes.

Określ poziomy bram neutralnych dla dostawców

Zacznij od nazwania warstw ze względu na zachowanie obciążenia, a nie terminologię dostawcy. Przydatna pierwsza taksonomia to:

Ta lista poziomów jest celowo mała. Jeśli utworzysz dwadzieścia poziomów, programiści ominą system. Brama może nadal wewnętrznie mapować jedną neutralną warstwę na kilka mechanizmów specyficznych dla dostawcy.

Oddziel żądany poziom od wybranego poziomu

Wywołujący powinien wysłać żądany poziom, ale brama powinna zarejestrować zarówno żądany poziom, jak i faktycznie wybrany poziom. Nie zawsze są takie same.

Przykładowe metadane żądania:

{
  "model": "domyślny czat wsparcia",
  „wiadomości”: [...],
  „metadane”: {
    "workflow": "customer_support_reply",
    "ident_dzierżawcy": "dzierżawa_123",
    "requested_gateway_tier": "interactive_fast",
    „end_user_id”: „u_789”
  }

Przykładowy zapis wysyłki:

{
  "request_id": "req_abc",
  "ident_dzierżawcy": "dzierżawa_123",
  "api_key_id": "key_live_456",
  "workflow": "customer_support_reply",
  "model_alias": "domyślny czat wsparcia",
  "requested_gateway_tier": "interactive_fast",
  "wybrany_dostawca": "dostawca_a",
  "selected_provider_tier": "szybki",
  "tier_outcome": "wybrane_na żądanie",
  „powód_degradacji”: null,
  „tokens_wejściowy”: 1840,
  „tokeny_wyjściowe”: 420,
  „opóźnienie_ms”: 1420,
  "estimated_cost_usd": "0,0312",
  "settled_cost_usd": "0,0308"

Jeśli żądanie premium zostanie wysłane do standardowego przetwarzania z powodu limitów rampy lub reguł budżetu dzierżawcy, musi to być widoczne:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standardowy",
  "tier_outcome": "obniżona wersja",
  "downgrade_reason": "tenant_premium_budget_exhausted"

To rozróżnienie zapobiega wprowadzaniu w błąd analiz. Jeśli pulpity nawigacyjne pokazują tylko to, o co prosił dzwoniący, finanse zobaczą zamiar premium, ale nie wykonanie premium. Jeśli pulpity nawigacyjne pokazują tylko wyniki nadrzędne, zespoły produktowe nie będą wiedzieć, kiedy w ich wrażliwym na opóźnienia przepływie pracy odmówiono przepustowości premium.

Przed routingiem utwórz macierz możliwości

Router warstwy usług potrzebuje matrycy możliwości. Macierz powinna odpowiedzieć: jakie mechanizmy wydajnościowe są dostępne dla danego modelu, regionu, najemcy i przepływu pracy?

Minimalna liczba pól:

• dostawca
• model_lub_deployment
• regiony
• supports_sync
• supports_batch
• obsługuje_premium_tier
• supports_provisioned_capacity
• supports_spillover
• wartości_poziomu_dostawcy
• billing_line_items
• znane_zachowanie_degradacji
• lista dozwolonych najemców

Uproszczony przykład:

mapa_poziomu bramy:
  interaktywny_szybki:
    preferowane:
      - dostawca: openai
        parametry_żądania:
          poziom_usługi: szybko
      - dostawca: antropiczny
        parametry_żądania:
          poziom_usługi: priorytet
    rezerwa:
      - poziom_bramy: standard_interaktywny
        dozwolony_when: policy.allows_standard_downgrade
  rabat_tła:
    preferowane:
      - dostawca: antropiczny
        tryb: wsadowy
      - dostawca: gemini
        tryb: wsadowy
    rezerwa:
      - kolejka: opóźniona_retry
        dozwolone_kiedy: prawda
  zarezerwowana_pojemność:
    preferowane:
      - dostawca: azure_openai
        klasa_wdrożeniowa: udostępniona
    rezerwa:
      - dostawca: azure_openai
        klasa_wdrożenia: standard
        dozwolone_when: policy.allows_spillover

Ta macierz powinna dotyczyć konfiguracji, a nie rozproszonego kodu. Zmiany nazewnictwa dostawców, dostępność regionalna i sposób rozliczania będą się zmieniać z biegiem czasu. Aktualizacja zasad bramy jest bezpieczniejsza niż ponowne wdrażanie każdej aplikacji wywołującej interfejs API.

Klasyfikuj obciążenia przed wybraniem pojemności

Najtrudniejszą częścią nie jest mapowanie dostawców. Decyduje, które żądania zasługują na który poziom.

Dobrzy kandydaci do interactive_fast

• Asystenci głosowi, w których opóźnienie przerywa rozmowę.
• Czat skierowany do klienta na temat ścieżek konwersji lub utrzymania o wysokiej wartości.
• Operacje wykonywane przez człowieka w pętli, podczas których agent aktywnie czeka.
• Incydenty produkcyjne, w przypadku których opóźnienie bezpośrednio wpływa na ograniczenie.

Dobrzy kandydaci na interactive_standard

• Wewnętrzni drugi piloci.
• Wspieraj kreślenie tam, gdzie człowiek może tolerować normalny czas reakcji.
• Cechy produktu, w przypadku których czas reakcji ma znaczenie, ale nie jest krytyczny.

Dobrzy kandydaci do background_discount

• Nocne podsumowanie.
• Duże wzbogacanie dokumentów.
• Oceny offline.
• Osadzanie zbiorcze odświeża.
• Oznaczanie etykiet Analytics i generowanie raportów.

Dobrzy kandydaci na reserved_capacity

• Stałe, duże obciążenia produkcyjne.
• Zakontraktowane obciążenia klientów z przewidywalnymi zobowiązaniami dotyczącymi przepustowości.
• Ruch, który nie toleruje zmian w hałaśliwych sąsiadach i ma wystarczające wykorzystanie, aby uzasadnić dedykowaną pojemność.

Prosta zasada brzmi: nie pozwalaj dzwoniącym na wybieranie pojemności premium tylko dlatego, że preferują szybkość. Wymagaj zadeklarowanego przepływu pracy, uprawnień najemcy i koperty budżetowej.

Egzekwuj uprawnienia dzierżawy i klucza API

Każdy dzierżawca i klucz interfejsu API powinien mieć ustawiony dozwolony poziom. Nowe klucze powinny domyślnie dotyczyć poziomów standardowych i tła, a nie warstw premium.

Przykładowe zasady najemcy:

{
  "ident_dzierżawcy": "dzierżawa_123",
  „allowed_gateway_tiers”: [
    "interaktywny_standard",
    „rabat_w tle”
  ],
  „poziom_premium”: {
    „włączone”: fałsz,
    "monthly_budget_usd": "0,00",
    „wymagane zatwierdzenie”: prawda
  },
  „zarezerwowana_pojemność”: {
    „włączone”: prawda,
    "deployment_pool": "support-prod-ptu",
    „allow_spillover_to_standard”: prawda,
    "spillover_monthly_budget_usd": "500,00"
  }

Przykładowe zastąpienie na poziomie klucza:

{
  "api_key_id": "key_voice_prod",
  „allowed_gateway_tiers”: [„interactive_fast”],
  „workflow_allowlist”: [„voice_control_loop”],
  "premium_daily_budget_usd": "75,00",
  „max_premium_traffic_percent”: 15

Zasady na poziomie klucza zapobiegają przypadkowej ekspansji. Programista nie może wziąć klucza przeznaczonego do ruchu głosowego i użyć go w skrypcie podsumowania zbiorczego, chyba że przepływ pracy jest również dozwolony.

Wyraźnie zaprojektuj zachowanie niższej wersji i przeniesienia

Zachowanie dotyczące przejścia na niższą wersję to decyzja dotycząca produktu, a nie tylko decyzja dotycząca infrastruktury. Gdy pojemność premium lub aprowizowana jest niedostępna, brama powinna wybrać jedną z czterech ścieżek:

• Kontynuuj standardowo: przydatne, gdy dostępność jest ważniejsza niż spójność opóźnień.
• Kolejka: przydatna w przypadku zadań w tle i obciążeń wsadowych.
• Szybka awaria: przydatna, gdy powolna reakcja byłaby gorsza niż brak reakcji, na przykład w przypadku ciasnych pętli w czasie rzeczywistym.
• Poproś dzwoniącego o ponowną próbę: przydatne, gdy klient może bezpiecznie ponowić próbę z wycofywaniem i zachowanym kluczem idempotentności.

Przykładowa zasada:

downgrade_policy:
  pętla_kontroli_głosu:
    żądany_poziom: interaktywny_szybki
    if_fast_unavailable: Fail_fast
    kod_błędu: poziom_pojemności_niedostępny
  odpowiedź_obsługi klienta:
    żądany_poziom: interaktywny_szybki
    if_fast_unavailable: kontynuuj_na_standardzie
    record_outcome: obniżona wersja
  nightly_document_enrichment:
    żądany_poziom: rabat_tła
    if_batch_unavailable: kolejka
    max_queue_delay_hours: 24
  zakontraktowany_api_klient:
    żądany_poziom: zarezerwowana_pojemność
    if_reserved_exhausted: przelew_do_standardu
    require_spillover_budget: true

Nie ukrywaj skutków ubocznych. Efekty uboczne mogą poprawić dostępność, ale zmieniają interpretację kosztów i SLO. Faktury i analizy powinny wykazywać żądanie zarezerwowanej mocy obliczeniowej, zdarzenie dodatkowe, faktycznie wykorzystaną standardową moc obliczeniową i przyczynę.

Połącz routing warstwy usług z rozliczeniami

Brama nie może kontrolować wydatków premium, jeśli wybór poziomu nie jest częścią księgi. Zapisz te pola dla każdego żądania lub zadania:

• Żądany poziom bramy.
• Wybrany poziom dostawcy lub klasa wydajności.
• Wynik poziomu: wybrany, obniżony, ulepszony, umieszczony w kolejce, przeniesiony, odrzucony.
• Przyczyna wyniku.
• Identyfikatory dzierżawy, klucza API, użytkownika i przepływu pracy.
• Alias modelu i model lub wdrożenie nadrzędne.
• Szacowany koszt przed wysyłką.
• Koszt rozliczany po poznaniu wykorzystania dostawcy.
• Liczba opóźnień i ponownych prób w przypadku żądań synchronicznych.
• Czas przesyłania partii, czas zakończenia i stan przetwarzania wyników dla zadań asynchronicznych.

Dzięki tym polom brama może odpowiedzieć na pytania zadawane przez finanse i inżynierię:

• Którzy najemcy wykorzystali w tym tygodniu pojemność premium?
• Które przepływy pracy spowodowały najwięcej wydatków premium?
• Jak często żądania premium przechodziły na wersję standardową?
• Czy interactive_fast poprawiło opóźnienie p95 na tyle, aby uzasadnić premię?
• Ile zaoszczędzono dzięki przetwarzaniu wsadowemu w tle w porównaniu z synchronicznym przetwarzaniem standardowym?
• Ile standardowych efektów ubocznych wygenerowała udostępniona pojemność?

Ważne zalecenie: wystawiaj fakturę na faktycznie wykorzystany poziom, jednocześnie wyświetlając żądany poziom w kontekście operacyjnym. W przeciwnym razie najemcy albo będą zaskoczeni kosztami, albo wprowadzeni w błąd co do jakości usług.

Dodaj poręcze, aby premium nie stało się ustawieniem domyślnym

Gdy zespoły odkryją szybszy poziom, mogą go nadużywać. Ustaw ograniczenia w bramie przed szerokim wdrożeniem.

• Budżet premium na najemcę: sztywne pułapy miesięczne i dzienne.
• Zatwierdzanie przepływu pracy: Premium dozwolone tylko w przypadku nazwanych przepływów pracy.
• Ograniczenie udziału ruchu: na przykład nie więcej niż 10% synchronicznych żądań dzierżawcy może korzystać z interactive_fast bez zgody.
• Alert ze standardu do wersji premium: alert w przypadku uaktualnienia przepływu pracy normalnie korzystającego ze standardu.
• Alert dotyczący wskaźnika zużycia premium: ostrzegaj, gdy przewidywane wydatki przekroczą zatwierdzoną kopertę.
• Automatyczne wygaśnięcie: tymczasowe awaryjne zastąpienia powinny wygasnąć bez ręcznego czyszczenia.
• Kontrola kwalifikowalności partii: blokuje zadania masowe z synchronicznych warstw premium, gdy spełniają kryteria partii.

Poręcze powinny być odwracalne. W przypadku zdarzenia upoważniony operator może potrzebować tymczasowego zastąpienia składki. To zastąpienie powinno mieć powód, osobę zatwierdzającą, budżet, czas wygaśnięcia i zapis audytu.

Kolejność wdrożenia

Bezpieczne wdrożenie nie rozpoczyna się od włączenia wszędzie routingu premium. Zacznij od pomiaru.

1. Dodaj klasyfikację warstwy cienia

Klasuj każde żądanie do proponowanego poziomu bramy, ale nie zmieniaj jeszcze routingu. Zapisz proponowaną warstwę obok istniejących metadanych dotyczących opóźnień, kosztów i przepływu pracy. To pokazuje, ile ruchu zostałoby przeniesione do pojemności premium, wsadowej lub zarezerwowanej, gdyby zasady zostały wymuszone.

2. Utwórz macierz możliwości

Wyświetl listę mechanizmów dostawców, obsługiwanych modeli, regionów, limitów, pól raportowania i znanych zachowań związanych z przejściem na starszą wersję. Traktuj nieznane zachowanie polegające na przejściu na niższą wersję jako ryzyko do czasu przetestowania.

3. Egzekwuj uprawnienia dzierżawy w trybie próbnym

Zapisuj, czy każde żądanie zostanie zaakceptowane, obniżone, umieszczone w kolejce lub odrzucone. Przed egzekwowaniem przepisów udostępnij wyniki właścicielom produktów.

4. Włącz jeden poziom dla jednej kohorty

Wybierz wąski przepływ pracy, taki jak ścieżka odpowiedzi do pomocy technicznej na żywo lub nocne podsumowanie. Włącz odpowiednią warstwę bramy dla małej kohorty dzierżawców. Zmierz opóźnienie p50, opóźnienie p95, koszt, współczynnik obniżenia wersji, poziom błędów i wskaźniki biznesowe dostępne dla użytkowników, jeśli są dostępne.

5. Rozwijaj tylko wtedy, gdy dane to potwierdzają

Jeśli poziom premium poprawia opóźnienia, ale nie poprawia wyników produktu, należy go ograniczać. Jeśli przetwarzanie wsadowe zmniejsza koszty bez szkody dla zachowania produktu, rozwiń je. Jeśli udostępniona pojemność pozostaje bezczynna, rozważ ponownie zobowiązanie lub skieruj do niej bardziej przewidywalny ruch.

Kompromisy, które należy wyraźnie określić

• Poziomy premium o małych opóźnieniach mogą poprawić czas reakcji, ale mogą mieć wspólne limity szybkości lub wyzwalać ograniczenia rampy. Nie zastępują one kształtowania limitów stawek.
• Udostępniona pojemność zwiększa przewidywalność, ale może powodować marnowanie pieniędzy, gdy wykorzystanie jest niskie. Pojemność standardowa lub wsadowa może być lepsza w przypadku ruchu gwałtownego lub odpornego na opóźnienia.
• Przetwarzanie wsadowe może obniżyć koszt tokena, ale zmienia zachowanie produktu, ponieważ odpowiedzi są asynchroniczne i mogą dotrzeć znacznie później.
• Nazwy poziomów neutralne dla dostawcy upraszczają kod aplikacji, ale brama musi utrzymywać aktualną matrycę możliwości, ponieważ dostawcy używają różnych nazw, limitów, linii rozliczeniowych i zachowań związanych z przejściem na starszą wersję.
• Automatyczne przejście na niższą wersję poprawia dostępność, ale może zaburzyć poziom docelowego poziomu usług i oczekiwania dotyczące rozliczeń, chyba że brama rejestruje faktycznie używany poziom.
• Ścisła kontrola najemców zapobiega niespodziewanym wydatkom, ale zbyt sztywne zasady mogą blokować pilne przepływy pracy produkcyjne, chyba że istnieje kontrolowana ścieżka obejścia.

Przewidywanie: warstwa usług stanie się pierwszorzędnym wymiarem routingu

Przewidywanie: w miarę dojrzewania interfejsów API modeli poziom usług stanie się tak samo ważny dla routingu AI jak wybór modelu, region i okno kontekstowe. Zespoły nie będą pytać tylko „który model powinien na to odpowiedzieć?” Zapytają „jaki model, w jakiej klasie pojemności, na jaki budżet najemcy, z jaką polityką downgrade?”

Zalecenie: Zaprojektuj teraz księgę bramy i model zasad, aby można było dodawać nowe klasy wydajności dostawców bez zmiany kodu aplikacji. Nawet jeśli zaczynasz od standardowego i wsadowego, od początku używaj pól takich jak requested_gateway_tier, selected_provider_tier i tier_outcome.

Praktyczna lista kontrolna

• Zdefiniuj nie więcej niż pięć poziomów bram neutralnych dla dostawcy.
• Wymagaj, aby każdy klucz API deklarował, z jakich warstw i przepływów pracy może korzystać.
• Utwórz macierz możliwości dostawcy dla zachowań premium, standardowych, aprowizowanych, wsadowych i rozproszonych.
• Rejestruj żądany poziom, wybrany poziom, wynik przejścia na niższą wersję lub efekt uboczny, opóźnienia, wykorzystanie i rozliczony koszt.
• Domyślne nowe klucze do poziomów standardowych lub w tle.
• Dodaj budżety premium, limity udziału w ruchu i alerty.
• Wyraź zachowanie w przypadku przejścia na niższą wersję w zależności od przepływu pracy.
• Zacznij od wskaźników ukrytych przed egzekwowaniem.
• Najpierw udostępnij pojemność premium lub alokowaną w małej kohorcie.
• Rozwijaj tylko wtedy, gdy opóźnienia, niezawodność lub wskaźniki biznesowe uzasadniają koszt.

Wniosek

Routing na poziomie usług należy do bramy AI API, ponieważ jest to przekrojowa decyzja polityczna. Ma to wpływ na opóźnienia, koszty, przydziały, uprawnienia dzierżawy, faktury i oczekiwania operacyjne. Zespoły ds. aplikacji nie powinny na stałe kodować nazw warstw ani klas wdrożeń specyficznych dla dostawcy tylko po to, aby wyrazić pilność obciążenia.

Praktyczna brama udostępnia neutralne poziomy, takie jak interactive_fast, interactive_standard, reserved_capacity i background_discount. Odwzorowuje te poziomy na mechanizmy specyficzne dla dostawcy, wymusza uprawnienia najemcy, rejestruje rzeczywisty wynik i sprawia, że pojemność premium jest zamierzonym wyjątkiem, a nie ścieżką domyślną.

Powiązane lektury

• Kształtowanie limitu stawki przed dostawcą 429s
• trwały wzorzec bramy dla asynchronicznych zadań wsadowych
• księga rozliczeniowa do wyceny, rezerwowania, rozliczania i uzgadniania