Service-Tier Routing i en AI API Gateway: Snabb, Standard, Provisioned och Batch Without Hard-Coding Providers

Den här nivålistan är medvetet liten. Om du skapar tjugo nivåer kommer utvecklare att kringgå systemet. Gatewayen kan fortfarande mappa en neutral nivå till flera leverantörsspecifika mekanismer internt.

Separera begärd nivå från vald nivå

Uppringaren ska skicka en begärd nivå, men gatewayen bör spela in både den begärda nivån och den faktiska valda nivån. De är inte alltid desamma.

Exempel på metadata för begäran:

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

Exempel på leveranspost:

{
  "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": "snabb",
  "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"
}

Om en premiebegäran skickas till standardbearbetning på grund av rampgränser eller regler för hyresgästbudget, måste det vara synligt:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standard",
  "tier_outcome": "nedgraderad",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

Denna distinktion förhindrar vilseledande analys. Om instrumentpaneler bara visar vad den som ringer begärde, kommer finans att se premiumavsikt men inte premiumutförande. Om instrumentpaneler bara visar uppströmsresultatet kommer produktteam inte att veta när deras latenskänsliga arbetsflöde nekades premiumkapacitet.

Skapa en kapacitetsmatris före routing

En router på servicenivå behöver en kapacitetsmatris. Matrisen bör svara: för en given modell, region, hyresgäst och arbetsflöde, vilka kapacitetsmekanismer finns tillgängliga?

Minsta fält:

• leverantör
• model_or_deployment
• regioner
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• faktureringsrader
• känd_nedgraderingsbeteende
• tenant_allowlist

Ett förenklat exempel:

gateway_tier_map:
  interaktiv_snabb:
    föredragen:
      - leverantör: openai
        request_params:
          service_tier: snabb
      - leverantör: antropisk
        request_params:
          service_tier: prioritet
    reserv:
      - gateway_tier: interaktiv_standard
        allow_when: policy.allows_standard_downgrade
  bakgrundsrabatt:
    föredragen:
      - leverantör: antropisk
        läge: batch
      - leverantör: gemini
        läge: batch
    reserv:
      - kö: delayed_retry
        tillåtna_när: sant
  reserverad_kapacitet:
    föredragen:
      - leverantör: azure_openai
        deployment_class: provisioned
    reserv:
      - leverantör: azure_openai
        deployment_class: standard
        allow_when: policy.allows_spillover

Denna matris ska vara konfigurerad, inte spridd kod. Namnändringar för leverantörer, regional tillgänglighet och faktureringsbehandling kommer att ändras över tiden. Att uppdatera en gateway-policy är säkrare än att omdistribuera alla program som anropar API:et.

Klassificera arbetsbelastningar innan du väljer kapacitet

Det svåraste är inte leverantörskartläggningen. Det är att avgöra vilka förfrågningar som förtjänar vilken nivå.

Bra kandidater för interactive_fast

• Röstassistenter där fördröjning bryter konversationen.
• Kundvändande chatt på högvärdiga konverterings- eller retentionsvägar.
• Human-in-the-loop-operationer där en agent aktivt väntar.
• Produktionsincidenter där latens direkt påverkar begränsningen.

Bra kandidater för interactive_standard

• Interna copiloter.
• Stöd utkast där en människa kan tolerera normal svarstid.
• Produktfunktioner där svarstiden är viktig men inte avgörande.

Bra kandidater för background_discount

• Nattlig sammanfattning.
• Stor dokumentberikning.
• Offlineutvärderingar.
• Massinbäddning uppdateras.
• Analytics-märkning och rapportgenerering.

Bra kandidater för reserved_capacity

• Stadig produktionsbelastning i stora volymer.
• Kontrakterade kundarbetsbelastningar med förutsägbara genomströmningsåtaganden.
• Trafik som inte kan tolerera bullriga variationer mellan grannar och som har tillräckligt med utnyttjande för att motivera dedikerad kapacitet.

En enkel policyregel är: låt inte uppringare välja premiumkapacitet bara för att de föredrar hastighet. Kräv ett deklarerat arbetsflöde, hyresgästbehörighet och budgetkuvert.

Tillämpa klient- och API-nyckelbehörigheter

Varje klient- och API-nyckel bör ha en tillåten nivåuppsättning. Nya nycklar bör som standard vara standard- och bakgrundsnivåer, inte premiumnivåer.

Exempel på hyresgästpolicy:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "bakgrundsrabatt"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0,00",
    "approval_required": sant
  },
  "reserved_capacity": {
    "enabled": sant,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": sant,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Exempel på åsidosättande på nyckelnivå:

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

Nyckelnivåpolicyn förhindrar oavsiktlig expansion. En utvecklare kan inte ta en nyckel som är avsedd för rösttrafik och använda den för ett bulksummeringsskript om inte arbetsflödet också är tillåtet.

Utforma nedgradering och spridningsbeteende uttryckligen

Nedgraderat beteende är ett produktbeslut, inte bara ett infrastrukturbeslut. När premium- eller provisionerad kapacitet inte är tillgänglig bör gatewayen välja en av fyra vägar:

• Fortsätt på standard: Användbart när tillgänglighet är viktigare än latenskonsistens.
• Kö: Användbar för bakgrundsjobb och batch-arbetsbelastningar.
• Fast misslyckas: Användbart när ett långsamt svar skulle vara värre än inget svar, till exempel snäva realtidsslingor.
• Be den som ringer att försöka igen: Användbart när klienten säkert kan försöka igen med en backoff och en bevarad idempotensnyckel.

Exempel på policy:

nedgraderingspolicy:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable
  kundsupport_svar:
    requested_tier: interactive_fast
    if_fast_unavailable: fortsätt_på_standard
    record_outcome: nedgraderad
  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: kö
    max_queue_delay_hours: 24
  contracted_api_customer:
    requested_tier: reserved_capacity
    if_reserved_exhausted: spillover_to_standard
    require_spillover_budget: true

Göm inte spillover. Spillover kan förbättra tillgängligheten, men det förändrar kostnad och SLO-tolkning. Fakturor och analyser bör visa begäran om reserverad kapacitet, spillover-händelsen, standardkapaciteten som faktiskt används och orsaken.

Koppla routing på tjänstenivå till fakturering

En gateway kan inte styra premiumutgifter om nivåval inte är en del av reskontran. Lagra dessa fält för varje förfrågan eller jobb:

• Begärd gateway-nivå.
• Vald leverantörsnivå eller kapacitetsklass.
• Nivåresultat: valt, nedgraderat, uppgraderat, köat, spillover, avvisat.
• Orsak till resultatet.
• Genant-, API-nyckel-, användar- och arbetsflödesidentifierare.
• Modellalias och uppströmsmodell eller implementering.
• Uppskattad kostnad före avsändning.
• Avtalad kostnad efter att leverantörens användning är känd.
• Latens och försök igen räknas för synkrona förfrågningar.
• Batchinlämningstid, slutförandetid och resultatinmatningsstatus för asynkrona jobb.

Med dessa fält kan gatewayen svara på frågorna som ekonomi och teknik kommer att ställa:

• Vilka hyresgäster använde premiumkapacitet den här veckan?
• Vilka arbetsflöden orsakade mest premiumutgifter?
• Hur ofta nedgraderades premiumförfrågningar till standard?
• Förbättrade interactive_fast p95-latens tillräckligt för att motivera premien?
• Hur mycket sparade batchbearbetning i bakgrunden jämfört med synkron standardbearbetning?
• Hur mycket standardspillover genererade tillhandahållen kapacitet?

Den viktiga rekommendationen: fakturera den faktiska nivån som används, samtidigt som den begärda nivån visas för operativt sammanhang. Annars kommer hyresgästerna antingen att bli förvånade över kostnader eller vilseledda om servicekvalitet.

Lägg till skyddsräcken så att premium inte blir standard

När lag upptäcker en snabbare nivå kan de överanvända den. Sätt gränser i gatewayen innan bred utrullning.

• Premiumbudget per hyresgäst: Hårda månatliga och dagliga tak.
• Arbetsflödesgodkännande: Premium tillåts endast för namngivna arbetsflöden.
• Trafikandelstak: Till exempel får inte mer än 10 % av en hyresgästs synkrona förfrågningar använda interactive_fast utan godkännande.
• Standard-till-premium-varning: Varning när ett arbetsflöde som normalt använder standard uppgraderas.
• Premium burn-rate varning: Varning när beräknade utgifter överstiger det godkända kuvertet.
• Automatiskt upphörande: Tillfälliga nödåterkopplingar bör upphöra utan manuell rengöring.
• Kontroller för gruppberättigande: Blockera massjobb från synkrona premiumnivåer när de uppfyller batchkriterierna.

Räcken bör vara vändbara. Under en incident kan en auktoriserad operatör behöva bevilja en tillfällig åsidosättande av premien. Den åsidosättningen bör ha en orsak, godkännare, budget, utgångstid och revisionspost.

Implementeringssekvens

En säker lansering börjar inte med att aktivera premium-routing överallt. Börja med mätning.

1. Lägg till skuggnivåklassificering

Klassificera varje begäran i en föreslagen gateway-nivå, men ändra inte routing ännu. Registrera den föreslagna nivån bredvid befintlig latens, kostnad och arbetsflödesmetadata. Detta avslöjar hur mycket trafik som skulle flyttas till premium-, batch- eller reserverad kapacitet om policyn tillämpades.

2. Skapa kapacitetsmatrisen

Lista leverantörsmekanismer, modeller som stöds, regioner, gränser, rapporteringsfält och känt nedgraderingsbeteende. Behandla okänt nedgraderingsbeteende som en risk tills det testats.

3. Framtvinga hyresgästbehörigheter i torrkörningsläge

Logga om varje begäran skulle tillåtas, nedgraderas, köas eller avvisas. Dela resultaten med produktägare innan verkställighet.

4. Aktivera en nivå för en kohort

Välj ett snävt arbetsflöde, till exempel en livesvarsväg för support eller ett nattligt sammanfattningsjobb. Aktivera den relevanta gateway-nivån för en liten hyresgästkohort. Mät P50-latens, P95-latens, kostnad, nedgraderingsfrekvens, felfrekvens och användarinriktade företagsstatistik där det är tillgängligt.

5. Expandera endast när data stöder det

Om premiumnivån förbättrar latensen men inte produktresultaten, håll den begränsad. Om batchbearbetning minskar kostnaderna utan att skada produktens beteende, utöka den. Om den provisionerade kapaciteten är inaktiv, gå tillbaka till åtagandet eller dirigera in mer förutsägbar trafik till den.

Avvägningar att tydliggöra

• Premiumnivåer med låg latens kan förbättra responsen, men de kan dela hastighetsgränser eller utlösa rampbegränsningar. De är inte ett substitut för utformning av hastighetsgränser.
• Avsatt kapacitet förbättrar förutsägbarheten, men det kan slösa pengar när utnyttjandet är lågt. Standard- eller batchkapacitet kan vara bättre för taggig eller latens-tolerant trafik.
• Batchbearbetning kan minska tokenkostnaden, men det ändrar produktens beteende eftersom svaren är asynkrona och kan komma mycket senare.
• Leverantörsneutrala nivånamn förenklar applikationskoden, men gatewayen måste ha en uppdaterad funktionsmatris eftersom leverantörer använder olika namn, gränser, faktureringsrader och nedgraderingsbeteende.
• Automatisk nedgradering förbättrar tillgängligheten, men det kan sudda ut SLO- och faktureringsförväntningar om inte gatewayen registrerar den faktiska nivån som används.
• Strikta hyresgästkontroller förhindrar överraskande utgifter, men alltför stela policyer kan blockera brådskande produktionsarbetsflöden om det inte finns en kontrollerad åsidosättningsväg.

Prognos: servicenivån kommer att bli en förstklassig routingdimension

Prognos: När modell-API:er mognar kommer tjänstenivån att bli lika viktig för AI-routing som modellval, region och sammanhangsfönster. Lag kommer inte bara att fråga "vilken modell ska svara på detta?" De kommer att fråga "vilken modell, under vilken kapacitetsklass, för vilken hyresgästbudget, med vilken nedgraderingspolicy?"

Rekommendation: Designa gatewayreskontran och policymodellen nu så att nya leverantörskapacitetsklasser kan läggas till utan att ändra applikationskoden. Även om du bara börjar med standard och batch, använd fält som requested_gateway_tier, selected_provider_tier och tier_outcome från början.

Handlig checklista

• Definiera högst fem leverantörsneutrala gatewaynivåer.
• Kräv att varje API-nyckel ska deklarera vilka nivåer och arbetsflöden den kan använda.
• Skapa en leverantörskapacitetsmatris för premium-, standard-, provisioned-, batch- och spilloverbeteende.
• Registrera begärd nivå, vald nivå, nedgradering eller spillover-resultat, latens, användning och fastställd kostnad.
• Nya standardnycklar till standard- eller bakgrundsnivåer.
• Lägg till premiumbudgetar, trafikandelstak och varningar.
• Gör nedgraderingsbeteende explicit per arbetsflöde.
• Börja med skuggstatistik innan verkställighet.
• Rulla först ut premium eller reserverad kapacitet till en liten kohort.
• Utöka endast när latens, tillförlitlighet eller affärsstatistik motiverar kostnaden.

Slutsats

Service-tier routing hör hemma i AI API-gatewayen eftersom det är ett tvärgående policybeslut. Det påverkar latens, kostnad, kvoter, hyresgästbehörigheter, fakturor och driftsförväntningar. Applikationsteam bör inte hårdkoda leverantörsspecifika nivånamn eller distributionsklasser bara för att uttrycka brådskande arbetsbelastning.

En praktisk gateway avslöjar neutrala nivåer som interactive_fast, interactive_standard, reserved_capacity och background_discount. Den mappar dessa nivåer till leverantörsspecifika mekanismer, upprätthåller hyresgästbehörigheter, registrerar det faktiska resultatet och gör premiumkapacitet till ett avsiktligt undantag snarare än standardvägen.

Relaterad läsning

• hållbart gatewaymönster för asynkrona batchjobb
• faktureringsreskontra för offert, reservera, avräkna och stämma av