Smerovanie na úrovni služieb v bráne AI API: rýchle, štandardné, poskytované a dávkové bez poskytovateľov pevného kódovania

Tento zoznam úrovní je zámerne malý. Ak vytvoríte dvadsať vrstiev, vývojári obídu systém. Brána môže stále mapovať jednu neutrálnu vrstvu na niekoľko mechanizmov špecifických pre poskytovateľa interne.

Oddeľte požadovanú úroveň od vybratej úrovne

Volajúci by mal poslať požadovanú úroveň, ale brána by mala zaznamenať požadovanú úroveň aj skutočne vybratú úroveň. Nie sú vždy rovnaké.

Príklad metadát žiadosti:

{
  "model": "support-chat-default",
  "správy": [...],
  "metadata": {
    "workflow": "customer_support_reply",
    "tenant_id": "tenant_123",
    "requested_gateway_tier": "interactive_fast",
    "end_user_id": "u_789"
  }
}

Príklad záznamu o odoslaní:

{
  "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": "poskytovateľ_a",
  "selected_provider_tier": "rýchlo",
  "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"
}

Ak sa žiadosť o prémiu odošle na štandardné spracovanie z dôvodu limitov rampy alebo pravidiel rozpočtu nájomcu, musí to byť viditeľné:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "štandard",
  "tier_outcome": "downgraded",
  "downgrade_reason": "premium_premium_budget_vyčerpaný nájomníkom"
}

Toto rozlíšenie zabraňuje zavádzajúcej analýze. Ak informačné panely zobrazujú iba to, čo volajúci požadoval, financie uvidia prémiový zámer, ale nie plnenie prémie. Ak sa na informačných paneloch zobrazuje iba upstream výsledok, produktové tímy nebudú vedieť, kedy ich pracovnému postupu citlivému na latenciu bola odmietnutá prémiová kapacita.

Pred smerovaním vytvorte maticu schopností

Smerovač na úrovni služieb potrebuje maticu schopností. Matica by mala zodpovedať: aké kapacitné mechanizmy sú dostupné pre daný model, región, nájomcu a pracovný tok?

Minimálne množstvo polí:

• poskytovateľ
• model_or_deployment
• regióny
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• hodnoty_vrstvy_poskytovateľa
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Zjednodušený príklad:

gateway_tier_map:
  interaktívne_rýchle:
    preferované:
      - poskytovateľ: openai
        request_params:
          service_tier: rýchly
      - poskytovateľ: antropický
        request_params:
          service_tier: priorita
    záložný:
      - gateway_tier: interaktívny_štandard
        allow_when: policy.allows_standard_downgrade
  background_discount:
    preferované:
      - poskytovateľ: antropický
        režim: dávkový
      - poskytovateľ: gemini
        režim: dávkový
    záložný:
      - front: delayed_retry
        allow_when: true
  rezervovaná_kapacita:
    preferované:
      - poskytovateľ: azure_openai
        Trieda_nasadenia: poskytovaná
    záložný:
      - poskytovateľ: azure_openai
        Trieda_nasadenia: štandard
        allow_when: policy.allows_spillover

Táto matica by mala byť konfiguráciou, nie rozptýleným kódom. Zmeny názvov poskytovateľov, regionálna dostupnosť a spôsob fakturácie sa časom zmenia. Aktualizácia politiky brány je bezpečnejšia ako opätovné nasadenie každej aplikácie, ktorá volá rozhranie API.

Pred výberom kapacity klasifikujte pracovné zaťaženie

Najťažšou časťou nie je mapovanie poskytovateľa. Rozhoduje, ktoré požiadavky si zaslúžia akú úroveň.

Dobrí kandidáti na interactive_fast

• Hlasoví asistenti, pri ktorých oneskorenie preruší konverzáciu.
• Rozhovor so zákazníkom na cestách konverzie alebo uchovania vysokej hodnoty.
• Operácie typu Human-in-the-loop, pri ktorých agent aktívne čaká.
• Produkčné incidenty, pri ktorých latencia priamo ovplyvňuje zmiernenie.

Dobrí kandidáti pre interactive_standard

• Interní kopiloti.
• Podporujte kreslenie tam, kde človek môže tolerovať normálny čas odozvy.
• Funkcie produktu, kde čas odozvy je dôležitý, ale nie je kritický.

Dobrí kandidáti na background_discount

• Nočný súhrn.
• Veľké obohatenie dokumentov.
• Offline hodnotenia.
• Hromadné vkladanie sa obnoví.
• Označovanie v službe Analytics a generovanie prehľadov.

Dobrí kandidáti na reserved_capacity

• Stále veľké množstvo produkčného pracovného zaťaženia.
• Zmluvné pracovné zaťaženie zákazníkov s predvídateľnými záväzkami priepustnosti.
• Premávka, ktorá nedokáže tolerovať hlučné odchýlky od susedov a má dostatočné využitie na to, aby odôvodnila vyhradenú kapacitu.

Jednoduché pravidlo znie: nedovoľte volajúcim vybrať si prémiovú kapacitu len preto, že uprednostňujú rýchlosť. Vyžadovať deklarovaný pracovný postup, povolenie nájomcu a obálku rozpočtu.

Vynútiť povolenia nájomníka a kľúča API

Každý nájomník a kľúč rozhrania API by mali mať nastavenú povolenú úroveň. Nové kľúče by mali predvolene používať štandardné úrovne a úrovne na pozadí, nie prémiové úrovne.

Príklad pravidiel nájomníka:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "povolené": nepravda,
    "monthly_budget_usd": "0,00",
    "approval_required": pravda
  },
  "reserved_capacity": {
    "povolené": pravda,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": true,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Príklad prepísania na úrovni kľúča:

{
  "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
}

Pravidlá na úrovni kľúča bránia náhodnému rozšíreniu. Vývojár nemôže vziať kľúč určený pre hlasovú prevádzku a použiť ho na hromadný súhrnný skript, pokiaľ nie je povolený aj pracovný postup.

Explicitne navrhnite downgrade a prelievanie

Správanie sa na staršiu verziu je rozhodnutím o produkte, nielen rozhodnutím o infraštruktúre. Keď nie je k dispozícii prémiová alebo poskytovaná kapacita, brána by si mala vybrať jednu zo štyroch ciest:

• Pokračovať štandardne: Užitočné, keď na dostupnosti záleží viac ako na konzistencii latencie.
• Poradie: Užitočné pre úlohy na pozadí a dávkové úlohy.
• Rýchle zlyhanie: Užitočné, keď by pomalá odozva bola horšia ako žiadna odozva, ako sú napríklad úzke slučky v reálnom čase.
• Požiadajte volajúceho, aby to zopakoval: Užitočné, keď sa klient môže bezpečne pokúsiť zopakovať s odstúpením a zachovaným kľúčom idempotencie.

Príklad pravidiel:

zásady prechodu na nižšiu verziu:
  loop_control_loop:
    požadovaná_úroveň: interaktívna_rýchla
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable
  customer_support_reply:
    požadovaná_úroveň: interaktívna_rýchla
    if_fast_unavailable: continue_on_standard
    record_outcome: downgraded
  nočné_obohatenie_dokumentov:
    požadovaná_úroveň: zľava na pozadí
    if_batch_unavailable: front
    max_queue_delay_hours: 24
  contracted_api_customer:
    požadovaná_úroveň: vyhradená_kapacita
    if_reserved_exhausted: spillover_to_standard
    require_spillover_budget: true

Neskrývajte presah. Prelievanie môže zlepšiť dostupnosť, ale mení cenu a interpretáciu SLO. Faktúry a analýzy by mali zobrazovať požiadavku na rezervovanú kapacitu, udalosť prelievania, skutočne využitú štandardnú kapacitu a dôvod.

Pripojte smerovanie na úrovni služieb k fakturácii

Brána nemôže kontrolovať prémiové výdavky, ak výber úrovne nie je súčasťou účtovnej knihy. Uložte tieto polia pre každú požiadavku alebo úlohu:

• Požadovaná úroveň brány.
• Vybraná úroveň poskytovateľa alebo trieda kapacity.
• Výsledok úrovne: vybratý, znížený, inovovaný, zaradený do poradia, presah, odmietnutý.
• Dôvod výsledku.
• Nájomca, kľúč API, používateľ a identifikátory pracovného toku.
• Alias modelu a upstream model alebo nasadenie.
• Odhadované náklady pred odoslaním.
• Vyrovnané náklady po tom, ako je známe využitie poskytovateľa.
• Latencia a počet opakovaní pre synchrónne požiadavky.
• Čas hromadného odoslania, čas dokončenia a stav príjmu výsledkov pre asynchrónne úlohy.

Vďaka týmto poliam môže brána odpovedať na otázky, ktoré budú klásť financie a inžinierstvo:

• Ktorí nájomníci tento týždeň využili prémiovú kapacitu?
• Ktoré pracovné postupy spôsobili najvyššie prémiové výdavky?
• Ako často prešli prémiové požiadavky na úroveň štandardnej?
• Zlepšil interactive_fast latenciu p95 dostatočne na to, aby odôvodnil prémiu?
• Koľko ušetrilo dávkové spracovanie na pozadí v porovnaní so synchrónnym štandardným spracovaním?
• Koľko štandardného prelievania vytvorila poskytnutá kapacita?

Dôležité odporúčanie: fakturujte skutočne použitú úroveň a zároveň zobrazte požadovanú úroveň pre prevádzkový kontext. V opačnom prípade budú nájomníci buď prekvapení nákladmi, alebo budú zavádzaní, pokiaľ ide o kvalitu služieb.

Pridajte zábradlia, aby sa prémia nestala predvolenou

Keď tímy objavia rýchlejšiu úroveň, môžu ju nadmerne využívať. Pred širokým zavedením zadajte do brány limity.

• Prémiový rozpočet na nájomníka: Pevné mesačné a denné stropy.
• Schválenie pracovného toku: Prémiové povolené len pre pomenované pracovné toky.
• Obmedzenie podielu návštevnosti: Napríklad najviac 10 % synchrónnych žiadostí nájomníka môže bez schválenia použiť interactive_fast.
• Upozornenie zo štandardnej na prémiovú verziu: Upozornenie pri inovácii pracovného postupu, ktorý bežne používa štandard.
• Upozornenie na prémiovú rýchlosť spaľovania: Upozornenie, keď plánované výdavky prekročia schválenú obálku.
• Automatické uplynutie platnosti: Platnosť dočasných núdzových prepísaní by mala uplynúť bez manuálneho čistenia.
• Kontroly vhodnosti pre dávky: Blokujte hromadné úlohy zo synchrónnych prémiových vrstiev, keď spĺňajú kritériá dávky.

Zábradlia by mali byť obojstranné. Počas incidentu môže byť potrebné, aby oprávnený prevádzkovateľ udelil dočasné prepísanie poistného. Toto prepísanie by malo mať dôvod, schvaľovateľa, rozpočet, čas vypršania platnosti a záznam auditu.

Sekvencia implementácie

Bezpečné zavádzanie nezačína zapnutím prémiového smerovania všade. Začnite meraním.

1. Pridajte klasifikáciu tieňovej vrstvy

Zaraďte každú požiadavku do navrhovanej úrovne brány, ale zatiaľ nemeňte smerovanie. Zaznamenajte navrhovanú úroveň vedľa existujúcich metadát latencie, nákladov a pracovného toku. Toto odhaľuje, koľko prenosu by sa presunulo na prémiovú, dávkovú alebo rezervovanú kapacitu, ak by sa presadila politika.

2. Vytvorte maticu schopností

Uveďte zoznam mechanizmov poskytovateľov, podporovaných modelov, regiónov, limitov, polí prehľadov a známeho správania pri prechode na nižšiu verziu. Považujte neznáme správanie pri prechode na nižšiu verziu za riziko, kým nebude testované.

3. Vynútiť povolenia nájomníka v režime suchého chodu

Zapíšte si, či bude každá žiadosť povolená, preradená na nižšiu verziu, zaradená do poradia alebo odmietnutá. Pred presadzovaním zdieľajte výsledky s vlastníkmi produktov.

4. Povoliť jednu úroveň pre jednu kohortu

Vyberte si úzky pracovný postup, ako je napríklad živá cesta odpovedí podpory alebo nočná súhrnná úloha. Povoľte príslušnú vrstvu brány pre malú kohortu nájomníkov. Zmerajte latenciu p50, latenciu p95, cenu, mieru zníženia verzie, chybovosť a obchodné metriky orientované na používateľa, ak sú k dispozícii.

5. Rozbaliť iba vtedy, keď to údaje podporujú

Ak prémiová úroveň zlepšuje latenciu, ale nie výsledky produktu, ponechajte ju obmedzenú. Ak dávkové spracovanie znižuje náklady bez poškodenia správania produktu, rozšírte ho. Ak je poskytnutá kapacita nečinná, prehodnoťte záväzok alebo doň nasmerujte predvídateľnejšiu prevádzku.

Vysvetlenie kompromisov

• Prémiové úrovne s nízkou latenciou môžu zlepšiť odozvu, ale môžu mať rovnaké frekvenčné limity alebo spúšťať obmedzenia. Nie sú náhradou za tvarovanie limitu sadzby.
• Pridelená kapacita zlepšuje predvídateľnosť, ale môže plytvať peniazmi, keď je využitie nízke. Štandardná alebo dávková kapacita môže byť lepšia pre špičku alebo prenos tolerantný voči latencii.
• Dávkové spracovanie môže znížiť náklady na token, ale mení správanie produktu, pretože odpovede sú asynchrónne a môžu prísť oveľa neskôr.
• Názvy vrstiev neutrálne voči poskytovateľom zjednodušujú kód aplikácie, ale brána musí udržiavať aktuálnu maticu schopností, pretože poskytovatelia používajú rôzne názvy, limity, fakturačné riadky a správanie pri prechode na nižšiu verziu.
• Automatický prechod na nižšiu verziu zlepšuje dostupnosť, môže však rozmazať očakávania SLO a fakturácie, pokiaľ brána nezaznamená skutočne použitú úroveň.
• Prísne kontroly nájomníkov zabraňujú prekvapivým výdavkom, ale príliš prísne pravidlá môžu blokovať naliehavé výrobné pracovné postupy, pokiaľ neexistuje riadená cesta prepísania.

Predpoveď: úroveň služieb sa stane prvotriednou dimenziou smerovania

Predpoveď: Ako modelové API dozrievajú, úroveň služieb bude pre smerovanie AI rovnako dôležitá ako výber modelu, oblasť a kontextové okno. Tímy sa nebudú pýtať iba „ktorý model by mal na to odpovedať? Budú sa pýtať „aký model, v akej kapacitnej triede, pre aký rozpočet nájomcu, s akou politikou downgradu?“

Odporúčanie: Navrhnite účtovnú knihu brány a model politiky už teraz, aby bolo možné pridať nové triedy kapacity poskytovateľa bez zmeny kódu aplikácie. Aj keď začínate len so štandardným a dávkovým, od začiatku použite polia ako requested_gateway_tier, selected_provider_tier a tier_outcome.

Akčný kontrolný zoznam

• Nedefinujte viac ako päť úrovní brány neutrálnej voči poskytovateľovi.
• Vyžadovať, aby každý kľúč API deklaroval, ktoré úrovne a pracovné postupy môže používať.
• Vytvorte maticu schopností poskytovateľa pre prémiové, štandardné, poskytované, dávkové a prelievacie správanie.
• Zaznamenajte požadovanú úroveň, vybratú úroveň, výsledok zníženia alebo preliatia, latenciu, využitie a vyrovnané náklady.
• Predvolené nové kľúče pre štandardné úrovne alebo úrovne na pozadí.
• Pridajte prémiové rozpočty, limity zdieľania návštevnosti a upozornenia.
• Urobte explicitné správanie pri prechode na nižší pracovný postup.
• Pred presadzovaním začnite s tieňovými metrikami.
• Najskôr zaveďte prémiovú alebo poskytovanú kapacitu pre malú kohortu.
• Rozšírte len vtedy, keď latencia, spoľahlivosť alebo obchodné metriky odôvodňujú náklady.

Záver

Smerovanie na úrovni služieb patrí do brány AI API, pretože ide o prierezové politické rozhodnutie. Ovplyvňuje latenciu, náklady, kvóty, povolenia nájomníkov, faktúry a prevádzkové očakávania. Aplikačné tímy by nemali pevne kódovať názvy vrstiev alebo triedy nasadenia špecifické pre poskytovateľa, len aby vyjadrili naliehavosť pracovného zaťaženia.

Praktická brána odhaľuje neutrálne úrovne, ako sú interactive_fast, interactive_standard, reserved_capacity a background_discount. Mapuje tieto úrovne na mechanizmy špecifické pre poskytovateľa, vynucuje povolenia nájomníkov, zaznamenáva skutočný výsledok a z prémiovej kapacity robí zámernú výnimku, nie predvolenú cestu.

Súvisiace informácie

• trvalý vzor brány pre asynchrónne dávkové úlohy
• fakturačná kniha pre cenovú ponuku, rezerváciu, vyrovnanie a vyrovnanie