Směrování na úrovni služeb v bráně AI API: rychlé, standardní, zajišťované a dávkové bez poskytovatelů pevného kódování

Tento seznam úrovní je záměrně malý. Pokud vytvoříte dvacet vrstev, vývojáři systém obejdou. Brána může stále mapovat jednu neutrální vrstvu na několik mechanismů specifických pro poskytovatele interně.

Oddělte požadovanou úroveň od vybrané úrovně

Volající by měl odeslat požadovanou úroveň, ale brána by měla zaznamenat požadovanou úroveň i skutečně vybranou úroveň. Ty nejsou vždy stejné.

Příklad metadat požadavku:

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

Příklad záznamu o odeslání:

{
  "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": "poskytovatel_a",
  "selected_provider_tier": "rychle",
  "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"
}

Pokud je požadavek na prémii odeslán ke standardnímu zpracování kvůli limitům rampy nebo pravidlům rozpočtu nájemce, musí to být viditelné:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standardní",
  "tier_outcome": "sníženo",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

Toto rozlišení zabraňuje zavádějícím analýzám. Pokud řídicí panely zobrazují pouze to, co volající požadoval, finance uvidí prémiový záměr, ale nikoli provedení prémie. Pokud řídicí panely zobrazují pouze předřazený výsledek, produktové týmy nebudou vědět, kdy byla jejich pracovnímu postupu citlivému na latenci odepřena prémiová kapacita.

Před směrováním vytvořte matici schopností

Směrovač na úrovni služeb potřebuje matici schopností. Matice by měla odpovídat: jaké kapacitní mechanismy jsou pro daný model, region, tenanta a pracovní postup k dispozici?

Minimální počet polí:

• poskytovatel
• model_or_deployment
• oblasti
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Zjednodušený příklad:

gateway_tier_map:
  interaktivní_rychlý:
    preferováno:
      - poskytovatel: openai
        request_params:
          service_tier: rychle
      - poskytovatel: antropický
        request_params:
          service_tier: priorita
    záložní:
      - gateway_tier: interactive_standard
        allow_when: policy.allows_standard_downgrade
  pozadí_sleva:
    preferováno:
      - poskytovatel: antropický
        režim: dávkový
      - poskytovatel: gemini
        režim: dávkový
    záložní:
      - fronta: delayed_retry
        allow_when: true
  rezervovaná_kapacita:
    preferováno:
      - poskytovatel: azure_openai
        Třída_nasazení: zajištěno
    záložní:
      - poskytovatel: azure_openai
        Třída_nasazení: standardní
        allow_when: policy.allows_spillover

Tato matice by měla být konfigurace, nikoli rozptýlený kód. Změny pojmenování poskytovatelů, regionální dostupnost a způsob fakturace se časem změní. Aktualizace zásad brány je bezpečnější než opětovné nasazení každé aplikace, která volá rozhraní API.

Před výběrem kapacity klasifikujte pracovní zatížení

Nejtěžší na tom není mapování poskytovatele. Rozhoduje, které požadavky si zaslouží jakou úroveň.

Dobrí kandidáti na interactive_fast

• Hlasoví asistenti, u kterých zpoždění přeruší konverzaci.
• Chat zaměřený na zákazníka na vysoce hodnotných konverzních nebo retenčních cestách.
• Operace typu Human-in-the-loop, kde agent aktivně čeká.
• Produkční incidenty, kdy latence přímo ovlivňuje zmírnění.

Dobrí kandidáti pro interactive_standard

• Interní kopiloti.
• Podporujte navrhování, kde člověk snese normální dobu odezvy.
• Funkce produktu, kde doba odezvy je důležitá, ale není kritická.

Dobrí kandidáti na background_discount

• Noční shrnutí.
• Velké obohacení dokumentu.
• Offline hodnocení.
• Hromadné vkládání se obnovuje.
• Označování Analytics a generování přehledů.

Dobrí kandidáti na rezervovaná_kapacita

• Stálé velké objemové produkční zatížení.
• Nasmlouvané zákaznické pracovní zátěže s předvídatelnými závazky propustnosti.
• Provoz, který nedokáže tolerovat hlučné odchylky od sousedů a má dostatečné využití, aby ospravedlnil vyhrazenou kapacitu.

Jednoduché pravidlo zní: nedovolte volajícím vybrat si prémiovou kapacitu pouze proto, že preferují rychlost. Vyžadujte deklarovaný pracovní postup, povolení nájemce a obálku rozpočtu.

Vynucení oprávnění tenanta a klíče API

Každý tenant a klíč API by měl mít nastavenou povolenou úroveň. Nové klíče by měly mít výchozí úrovně standardní a na pozadí, nikoli prémiové úrovně.

Příklad zásad pro nájemce:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "sleva na pozadí"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0,00",
    "approval_required": true
  },
  "rezervovaná_kapacita": {
    "povoleno": true,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": true,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Příklad přepsání na úrovni klíče:

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

Zásady na úrovni klíče brání náhodnému rozšíření. Vývojář nemůže vzít klíč určený pro hlasový provoz a použít jej pro hromadný souhrnný skript, pokud není povolen také pracovní postup.

Explicitně navrhněte chování při přechodu na nižší verzi a přelévání

Chování na nižší verzi je rozhodnutím o produktu, nikoli pouze rozhodnutím o infrastruktuře. Pokud není k dispozici prémiová nebo zřízená kapacita, brána by měla zvolit jednu ze čtyř cest:

• Pokračovat standardně: Užitečné, když na dostupnosti záleží více než na konzistenci latence.
• Fronta: Užitečné pro úlohy na pozadí a dávkové úlohy.
• Rychlé selhání: Užitečné, když by pomalá odezva byla horší než žádná odezva, jako jsou těsné smyčky v reálném čase.
• Požádejte volajícího, aby to zkusil znovu: Užitečné, když to klient může bezpečně opakovat s odstoupením a zachovaným klíčem idempotence.

Příklad zásady:

zásady pro downgrade:
  loop_control_loop:
    požadovaná_úroveň: interaktivní_rychle
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable
  customer_support_reply:
    požadovaná_úroveň: interaktivní_rychle
    if_fast_unavailable: continue_on_standard
    record_outcome: downgraded
  nightly_document_enrichment:
    požadovaná_úroveň: sleva na pozadí
    if_batch_unavailable: fronta
    max_queue_delay_hours: 24
  contracted_api_customer:
    požadovaná_úroveň: vyhrazená_kapacita
    if_reserved_exhausted: spillover_to_standard
    require_spillover_budget: true

Neschovávejte přelévání. Přelévání může zlepšit dostupnost, ale mění náklady a interpretaci SLO. Faktury a analýzy by měly ukazovat požadavek na rezervovanou kapacitu, událost přelévání, skutečně využitou standardní kapacitu a důvod.

Připojit směrování na úrovni služeb k fakturaci

Brána nemůže kontrolovat prémiové výdaje, pokud volba úrovně není součástí účetní knihy. Uložte tato pole pro každý požadavek nebo úlohu:

• Požadovaná úroveň brány.
• Vybraná úroveň poskytovatele nebo třída kapacity.
• Výsledek úrovně: vybráno, sníženo, upgradováno, ve frontě, přelévání, odmítnuto.
• Důvod pro výsledek.
• Nájemce, klíč API, uživatel a identifikátory pracovního postupu.
• Alias modelu a upstream model nebo nasazení.
• Odhadovaná cena před odesláním.
• Uhrazené náklady poté, co je známo využití poskytovatelem.
• Latence a počet opakování pro synchronní požadavky.
• Čas hromadného odeslání, čas dokončení a stav zpracování výsledků pro asynchronní úlohy.

S těmito poli může brána odpovědět na otázky, které bude klást finance a inženýrství:

• Kteří nájemci tento týden využili prémiovou kapacitu?
• Které pracovní postupy způsobily nejvyšší prémiové výdaje?
• Jak často se požadavky prémiového typu snížily na standardní?
• Zlepšil interactive_fast latenci p95 natolik, aby ospravedlnil prémii?
• Kolik ušetřilo dávkové zpracování na pozadí ve srovnání se synchronním standardním zpracováním?
• Kolik standardního přelévání vytvořila zřízená kapacita?

Důležité doporučení: fakturujte skutečně použitou úroveň a zároveň zobrazte požadovanou úroveň pro provozní kontext. V opačném případě budou nájemci buď překvapeni cenou, nebo budou uvedeni v omyl ohledně kvality služeb.

Přidejte zábradlí, aby se prémiový nestal výchozím

Jakmile týmy objeví rychlejší úroveň, mohou ji nadměrně používat. Před širokým zavedením nastavte v bráně limity.

• Prémiový rozpočet na nájemce: Pevné měsíční a denní stropy.
• Schválení pracovního postupu: Premium povoleno pouze pro pojmenované pracovní postupy.
• Omezení podílu provozu: Například ne více než 10 % synchronních požadavků nájemce může bez schválení používat interactive_fast.
• Výstraha ze standardního na prémiové: Výstraha při upgradu pracovního postupu, který běžně používá standard.
• Upozornění na prémiovou rychlost vypalování: Upozornění, když předpokládané výdaje překročí schválenou obálku.
• Automatické vypršení platnosti: Platnost dočasných nouzových přepsání by měla vypršet bez ručního čištění.
• Kontroly vhodnosti pro dávky: Blokujte hromadné úlohy ze synchronních prémiových úrovní, když splňují kritéria pro dávky.

Zábradlí by mělo být oboustranné. Během incidentu může oprávněný operátor vyžadovat dočasné přepsání pojistného. Toto přepsání by mělo mít důvod, schvalovatele, rozpočet, dobu vypršení platnosti a záznam auditu.

Posloupnost implementace

Bezpečné zavedení nezačíná tím, že všude zapnete prémiové směrování. Začněte měřením.

1. Přidejte klasifikaci stínové vrstvy

Zařaďte každý požadavek do navrhované úrovně brány, ale zatím neměňte směrování. Zaznamenejte navrhovanou úroveň vedle existujících metadat latence, nákladů a pracovního postupu. To odhaluje, kolik provozu by se přesunulo na prémiovou, dávkovou nebo vyhrazenou kapacitu, pokud by byly zásady vynuceny.

2. Vytvořte matici schopností

Uveďte seznam mechanismů poskytovatelů, podporovaných modelů, regionů, limitů, polí přehledů a známého chování při přechodu na nižší verzi. Neznámé chování při downgradu považujte za riziko, dokud nebude testováno.

3. Vynutit oprávnění tenanta v režimu suchého provozu

Zaznamenejte, zda bude každý požadavek povolen, snížen na nižší verzi, zařazen do fronty nebo zamítnut. Před vynucením sdílejte výsledky s vlastníky produktů.

4. Povolit jednu úroveň pro jednu kohortu

Vyberte úzký pracovní postup, jako je například cesta odpovědi na živou podporu nebo noční shrnutí. Povolte příslušnou vrstvu brány pro malou kohortu tenantů. Změřte latenci p50, latenci p95, náklady, míru downgradu, míru chyb a obchodní metriky orientované na uživatele, pokud jsou k dispozici.

5. Rozbalte pouze tehdy, když to data podporují

Pokud prémiová úroveň zlepšuje latenci, ale ne výsledky produktu, ponechte ji omezenou. Pokud dávkové zpracování snižuje náklady bez poškození chování produktu, rozšiřte jej. Pokud je zřízená kapacita nečinná, znovu se vraťte k závazku nebo do něj nasměrujte předvídatelnější provoz.

Vyjádření kompromisů

• Prémiové úrovně s nízkou latencí mohou zlepšit odezvu, ale mohou sdílet limity rychlosti nebo spouštět omezení rampy. Nenahrazují tvarování rychlostního limitu.
• Zřízená kapacita zlepšuje předvídatelnost, ale při nízkém využití může plýtvat penězi. Standardní nebo dávková kapacita může být lepší pro špičatý provoz nebo provoz tolerantní k latenci.
• Dávkové zpracování může snížit náklady na token, ale mění chování produktu, protože odpovědi jsou asynchronní a mohou dorazit mnohem později.
• Názvy úrovní neutrální vůči poskytovatelům zjednodušují kód aplikace, ale brána musí udržovat aktuální matici schopností, protože poskytovatelé používají různé názvy, limity, fakturační řádky a chování při přechodu na nižší verzi.
• Automatický downgrade zlepšuje dostupnost, ale může rozmazat očekávání SLO a fakturace, pokud brána nezaznamená skutečnou použitou úroveň.
• Přísné kontroly nájemců zabraňují překvapivým výdajům, ale příliš rigidní zásady mohou blokovat urgentní produkční pracovní postupy, pokud neexistuje řízená cesta k přepsání.

Předpověď: úroveň služeb se stane prvotřídní dimenzí směrování

Předpověď: Jak modelová API dozrávají, úroveň služeb bude pro směrování AI stejně důležitá jako výběr modelu, oblast a kontextové okno. Týmy se nebudou ptát pouze „který model by na to měl odpovědět? Budou se ptát „jaký model, pod jakou třídou kapacity, pro jaký rozpočet nájemce, s jakou politikou downgradu?“

Doporučení: Navrhněte účetní knihu brány a model zásad již nyní, aby bylo možné přidat nové třídy kapacity poskytovatele bez změny kódu aplikace. I když začínáte pouze se standardním a dávkovým režimem, použijte od začátku pole jako requested_gateway_tier, selected_provider_tier a tier_outcome.

Akční kontrolní seznam

• Nedefinujte více než pět úrovní brány neutrální vůči poskytovateli.
• Vyžadovat, aby každý klíč API deklaroval, které úrovně a pracovní postupy může používat.
• Vytvořte matici schopností poskytovatele pro prémiové, standardní, zajišťované, dávkové a přelévací chování.
• Zaznamenejte požadovanou úroveň, vybranou úroveň, výsledek snížení nebo přelití, latenci, využití a stanovené náklady.
• Výchozí nové klíče pro standardní úrovně nebo úrovně na pozadí.
• Přidejte prémiové rozpočty, limity podílu návštěvnosti a upozornění.
• Uveďte chování při přechodu na nižší verzi explicitně pro každý pracovní postup.
• Před vynucením začněte se stínovými metrikami.
• Nejprve zaveďte prémiovou nebo zřízenou kapacitu pro malou kohortu.
• Rozšiřte pouze tehdy, když latence, spolehlivost nebo obchodní metriky ospravedlní náklady.

Závěr

Směrování na úrovni služeb patří do brány AI API, protože se jedná o průřezové politické rozhodnutí. Ovlivňuje latenci, náklady, kvóty, oprávnění nájemců, faktury a provozní očekávání. Aplikační týmy by neměly napevno kódovat názvy vrstev nebo třídy nasazení specifické pro poskytovatele, jen aby vyjádřily naléhavost pracovní zátěže.

Praktická brána odhaluje neutrální úrovně, jako jsou interactive_fast, interactive_standard, reserved_capacity a background_discount. Mapuje tyto úrovně na mechanismy specifické pro poskytovatele, vynucuje oprávnění tenantů, zaznamenává skutečný výsledek a činí z prémiové kapacity záměrnou výjimku spíše než výchozí cestu.

Související informace

• trvalý vzor brány pro asynchronní dávkové úlohy
• fakturační kniha pro nabídku, rezervaci, vypořádání a odsouhlasení