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 wyższą wydajność o małych opóźnieniach, normalną wydajność 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 trudne jest kontrolowanie opóźnień, kosztów, przydziałów i sposobu rozliczania dzierżawców.

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 pojemności stają się logiką aplikacji

Zespoły korzystające z więcej niż jednego dostawcy modelu często zaczynają od prostego routingu modelu: 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ć wydatek.

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

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 informuje, że jest on naliczany z wyższą opłatą w porównaniu z przetwarzaniem standardowym. OpenAI stwierdza również, że 30 lipca 2026 r. zmieniono nazwę przetwarzania priorytetowego 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ć skierowana do przetwarzania standardowego.
• Fakt: Poziom usług może być wymiarem raportowania i rozliczeń. OpenAI mówi, że API klienci mogą grupować dane panelu użytkowania według poziomu usług i elementu zamówienia. Anthropic dokumentów standard, priority i batch jako wartości poziomu usług w API raportach użycia.
• Fakt: Interfejsy API wsadowe mogą znacząco obniżyć koszty pracy asynchronicznej. Dokumentacja cenowa Anthropic mówi, że partia API obsługuje asynchroniczne przetwarzanie dużych ilości danych z 50% rabatem na tokeny wejściowe i wyjściowe. Dokumentacja Google Gemini partii 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ść udostępnioną przez 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 także efekt przeniesienia z wdrożeń udostępnionych do wdrożeń standardowych w tym samym zasobie OpenAI platformy Azure.

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ą warstwę neutralną na kilka mechanizmów specyficznych dla dostawcy.

Oddziel żądany poziom od wybranego poziomu

Obiekt 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": "support-chat-default",
  "messages": [...],
  "metadata": {
    "workflow": "customer_support_reply",
    "tenant_id": "tenant_123",
    "requested_gateway_tier": "interactive_fast",
    "end_user_id": "u_789"
  }
}

Przykładowy zapis wysyłki:

{
  "request_id": "req_abc",
  "tenant_id": "tenant_123",
  "api_key_id": "key_live_456",
  "workflow": "customer_support_reply",
  "model_alias": "support-chat-default",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "fast",
  "tier_outcome": "selected_as_requested",
  "downgrade_reason": null,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_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": "standard",
  "tier_outcome": "downgraded",
  "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 ds. produktu nie będą wiedziały, kiedy w ich wrażliwym na opóźnienia przepływie pracy odmówiono przepustowości premium.

Zbuduj macierz możliwości przed trasowaniem

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

Minimalna liczba pól:

• provider
• model_or_deployment
• regions
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Uproszczony przykład:

gateway_tier_map:
  interactive_fast:
    preferred:
      - provider: openai
        request_params:
          service_tier: fast
      - provider: anthropic
        request_params:
          service_tier: priority
    fallback:
      - gateway_tier: interactive_standard
        allowed_when: policy.allows_standard_downgrade

  background_discount:
    preferred:
      - provider: anthropic
        mode: batch
      - provider: gemini
        mode: batch
    fallback:
      - queue: delayed_retry
        allowed_when: true

  reserved_capacity:
    preferred:
      - provider: azure_openai
        deployment_class: provisioned
    fallback:
      - provider: azure_openai
        deployment_class: standard
        allowed_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 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 na interactive_fast

• Asystenci głosowi, w których opóźnienie przerywa rozmowę.
• Czat z klientem 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 ryzyka.

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 na background_discount

• Nocne podsumowanie.
• Wzbogacanie dużych 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ążenie 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ą przepustowość.

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

Wymuś uprawnienia dzierżawy i APIklucza

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

Przykładowa polityka najemcy:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0.00",
    "approval_required": true
  },
  "reserved_capacity": {
    "enabled": true,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": true,
    "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 ten przepływ pracy jest również dozwolony.

Wyraźnie zaprojektuj zachowanie niższej wersji i przeniesienia

Zachowanie do przejścia na niższą wersję to decyzja dotycząca produktu, a nie tylko decyzja dotycząca infrastruktury. Gdy pojemność premium lub udostępniona 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: Przydatne, gdy powolna reakcja byłaby gorsza niż brak odpowiedzi, na przykład w przypadku ciasnych pętli w czasie rzeczywistym.
• Poproś rozmówcę o ponowną próbę: Przydatne, gdy klient może bezpiecznie ponowić próbę, korzystając z wycofywania i zachowanego klucza idempotentności.

Przykładowa zasada:

downgrade_policy:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable

  customer_support_reply:
    requested_tier: interactive_fast
    if_fast_unavailable: proceed_on_standard
    record_outcome: downgraded

  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: queue
    max_queue_delay_hours: 24

  contracted_api_customer:
    requested_tier: reserved_capacity
    if_reserved_exhausted: spillover_to_standard
    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, uaktualniony, umieszczony w kolejce, przeniesiony, odrzucony.
• Powód wyniku.
• Identyfikatory dzierżawcy, API klucza, 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 dla żą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 korzystali w tym tygodniu z pojemności 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ć zakup premium?
• Jak dużo zaoszczędzono w przypadku przetwarzania wsadowego w tle w porównaniu z synchronicznym przetwarzaniem standardowym?
• Jak dużo standardowego efektu ubocznego 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 będą albo zaskoczeni kosztami, albo wprowadzeni w błąd co do jakości usług.

Dodaj poręcze, aby wersja premium nie stała się opcją domyślną

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

• Budżet premium na najemcę: Sztywne pułapy miesięczne i dzienne.
• Zatwierdzanie przepływu pracy: Wersja Premium dozwolona tylko w przypadku nazwanych przepływów pracy.
• Limit udziału ruchu: Na przykład nie więcej niż 10% synchronicznych żądań dzierżawcy może używać interactive_fast bez zatwierdzenia.
• Alert ze standardu do wersji premium: Alarm w przypadku uaktualnienia przepływu pracy normalnie korzystającego ze standardu.
• Alert dotyczący współczynnika zużycia premium: Alarm, gdy przewidywane wydatki przekroczą zatwierdzoną kopertę.
• Automatyczne wygaśnięcie: Tymczasowe awaryjne zastąpienia powinny wygasnąć bez ręcznego czyszczenia.
• Kontrola kwalifikowalności partii: Blokuj zadania zbiorcze z synchronicznych warstw premium, gdy spełniają one 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.

Sekwencja implementacji

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

Lista 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, np. ścieżkę 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 obsługują

Jeśli warstwa premium poprawia opóźnienia, ale nie poprawia wydajności produktu, należy ją ograniczyć. 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 podkreś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 o charakterze gwałtownym lub tolerującym opóźnienia.
• Przetwarzanie wsadowe może zmniejszyć 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 SLO i oczekiwania dotyczące rozliczeń, chyba że brama rejestruje faktycznie używaną warstwę.
• Ś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

Prognoza: w miarę dojrzewania interfejsów API modeli warstwa usług stanie się równie ważna 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 ramach jakiej klasy pojemności, na jaki budżet najemcy, z jaką polityką dotyczącą obniżenia wersji?”

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 tylko od wersji standardowej i wsadowej, od początku używaj pól takich jak requested_gateway_tier, selected_provider_tier i tier_outcome.

Lista kontrolna z możliwością wykonania

• Zdefiniuj nie więcej niż pięć poziomów bram neutralnych dla dostawców.
• Wymagaj, aby każdy klucz API deklarował, jakich warstw i przepływów pracy może używać.
• Utwórz macierz możliwości dostawcy dla zachowania premium, standardowego, udostępnianego, wsadowego i rozproszonego.
• Zarejestruj żą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źnie określ zachowanie przejścia na starszą 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 się 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. Mapuje te warstwy na mechanizmy specyficzne dla dostawcy, wymusza uprawnienia dzierżawcy, rejestruje rzeczywisty wynik i sprawia, że pojemność premium jest zamierzonym wyjątkiem, a nie ścieżką domyślną.

Powiązane lektury

• kształtowanie limitu szybkości przed 429s dostawcy
• trwały wzorzec bramy dla partii asynchronicznej zadania
• księga rozliczeniowa do wyceny, rezerwowania, rozliczania i uzgadniania