Tjenestelagsruting i en AI API-gateway: rask, standard, klargjort og batch uten hardkodingsleverandører

Denne nivålisten er bevisst liten. Hvis du oppretter tjue nivåer, vil utviklere omgå systemet. Gatewayen kan fortsatt kartlegge ett nøytralt nivå til flere leverandørspesifikke mekanismer internt.

Skill forespurt nivå fra valgt nivå

Anroperen skal sende et forespurt nivå, men gatewayen skal registrere både det forespurte nivået og det faktisk valgte nivået. De er ikke alltid de samme.

Eksempel på forespørselsmetadata:

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

Eksempel på utsendelsespost:

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

Hvis en premiumforespørsel sendes til standardbehandling på grunn av rampegrenser eller leietakerbudsjettregler, må dette være synlig:

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

Dette skillet forhindrer villedende analyser. Hvis dashbord bare viser det innringeren ba om, vil finans se premium-intensjon, men ikke premium-utførelse. Hvis dashbord bare viser oppstrømsresultatet, vil ikke produktteam vite når deres latenssensitive arbeidsflyt ble nektet premiumkapasitet.

Bygg en kapasitetsmatrise før ruting

En ruter på tjenestenivå trenger en funksjonsmatrise. Matrisen skal svare: Hvilke kapasitetsmekanismer er tilgjengelige for en gitt modell, region, leietaker og arbeidsflyt?

Minimumsfelt:

• leverandør
• modell_eller_distribusjon
• regioner
• støtter_synkronisering
• støtter_batch
• støtter_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• faktureringslinje
• kjent_nedgraderingsadferd
• tenant_allowlist

Et forenklet eksempel:

gateway_tier_map:
  interaktiv_rask:
    foretrukket:
      - leverandør: openai
        request_params:
          service_tier: rask
      - leverandør: antropisk
        request_params:
          service_tier: prioritet
    fallback:
      - gateway_tier: interaktiv_standard
        allow_when: policy.allows_standard_downgrade
  bakgrunnsrabatt:
    foretrukket:
      - leverandør: antropisk
        modus: batch
      - Leverandør: Gemini
        modus: batch
    fallback:
      - kø: delayed_retry
        tillatt_når: sant
  reservert_kapasitet:
    foretrukket:
      - Leverandør: azure_openai
        deployment_class: klargjort
    fallback:
      - Leverandør: azure_openai
        deployment_class: standard
        allow_when: policy.allows_spillover

Denne matrisen skal være konfigurasjon, ikke spredt kode. Endringer i navn på leverandør, regional tilgjengelighet og faktureringsbehandling vil endres over tid. Å oppdatere en gateway-policy er tryggere enn å omdistribuere alle applikasjoner som kaller API.

Klassifiser arbeidsbelastninger før du velger kapasitet

Den vanskeligste delen er ikke leverandørkartleggingen. Det er å bestemme hvilke forespørsler som fortjener hvilket nivå.

Gode kandidater for interactive_fast

• Taleassistenter der forsinkelse bryter samtalen.
• Kundevendt chat på konverterings- eller oppbevaringsbaner med høy verdi.
• Human-in-the-loop-operasjoner der en agent aktivt venter.
• Produksjonshendelser der ventetid direkte påvirker reduksjon.

Gode kandidater for interactive_standard

• Interne copiloter.
• Støtt utkast der et menneske kan tolerere normal responstid.
• Produktfunksjoner der responstiden er viktig, men ikke er kritisk.

Gode kandidater for background_discount

• Nattlig oppsummering.
• Stor dokumentberikelse.
• Evalueringer uten nett.
• Masseinnbygging oppdateres.
• Analytics-merking og rapportgenerering.

Gode kandidater for reserved_capacity

• Jevne høyvolumsproduksjonsarbeidsmengder.
• Kontraktet kundearbeidsmengde med forutsigbare gjennomstrømningsforpliktelser.
• Trafikk som ikke tåler støyende nabovariasjoner og har nok utnyttelse til å rettferdiggjøre dedikert kapasitet.

En enkel policyregel er: ikke la innringere velge premiumkapasitet bare fordi de foretrekker hastighet. Krev en deklarert arbeidsflyt, leietakertillatelse og budsjettkonvolutt.

Håndheve tillatelser for leietaker og API-nøkler

Hver leietaker og API-nøkkel bør ha et tillatt nivåsett. Nye nøkler skal som standard være standard- og bakgrunnsnivåer, ikke premium-nivåer.

Eksempel på leietakerpolicy:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "bakgrunnsrabatt"
  ],
  "premium_tier": {
    "aktivert": falsk,
    "monthly_budget_usd": "0,00",
    "godkjenning_påkrevd": sant
  },
  "reserved_capacity": {
    "aktivert": sant,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": sant,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Eksempel på overstyring på nøkkelnivå:

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

Retningslinjene på nøkkelnivå forhindrer utilsiktet utvidelse. En utvikler kan ikke ta en nøkkel beregnet for taletrafikk og bruke den til et masseoppsummeringsskript med mindre arbeidsflyten også er tillatt.

Utform nedgradering og spillover-atferd eksplisitt

Nedgraderingsadferd er en produktbeslutning, ikke bare en infrastrukturbeslutning. Når premium eller klargjort kapasitet ikke er tilgjengelig, bør gatewayen velge en av fire baner:

• Fortsett på standard: Nyttig når tilgjengelighet er viktigere enn latenskonsistens.
• Kø: Nyttig for bakgrunnsjobber og batcharbeidsbelastninger.
• Feil raskt: Nyttig når en langsom respons ville være verre enn ingen respons, for eksempel tette sanntidsløkker.
• Be den som ringer om å prøve på nytt: Nyttig når klienten trygt kan prøve på nytt med en backoff og en bevart idempotensnøkkel.

Eksempel på retningslinjer:

downgrade_policy:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable
  kundestøtte_svar:
    requested_tier: interactive_fast
    if_fast_unavailable: fortsett_på_standard
    record_outcome: nedgradert
  nattlig_dokumentberikelse:
    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

Ikke skjul spillover. Spillover kan forbedre tilgjengeligheten, men det endrer kostnad og SLO-tolkning. Fakturaer og analyser bør vise forespørselen om reservert kapasitet, spillover-hendelsen, standardkapasiteten som faktisk brukes, og årsaken.

Koble tjenestenivåruting til fakturering

En gateway kan ikke kontrollere premiumutgifter hvis nivåvalg ikke er en del av hovedboken. Lagre disse feltene for hver forespørsel eller jobb:

• Forespurt gateway-nivå.
• Valgt leverandørnivå eller kapasitetsklasse.
• Nivåutfall: valgt, nedgradert, oppgradert, satt i kø, spillover, avvist.
• Årsak til utfallet.
• Leier-, API-nøkkel-, bruker- og arbeidsflytidentifikatorer.
• Modellalias og oppstrømsmodell eller distribusjon.
• Estimert kostnad før forsendelse.
• Avregnet kostnad etter at leverandørbruken er kjent.
• Latens og gjenforsøk teller for synkrone forespørsler.
• Batchinnsendingstid, gjennomføringstid og resultatinntaksstatus for asynkrone jobber.

Med disse feltene kan gatewayen svare på spørsmålene finans og ingeniørfag vil stille:

• Hvilke leietakere brukte premiumkapasitet denne uken?
• Hvilke arbeidsflyter forårsaket mest premiumforbruk?
• Hvor ofte ble premiumforespørsler nedgradert til standard?
• Har interactive_fast forbedret p95-forsinkelsen nok til å rettferdiggjøre premien?
• Hvor mye sparte batchbehandling i bakgrunnen sammenlignet med synkron standardbehandling?
• Hvor mye standard spillover genererte tilordnet kapasitet?

Den viktige anbefalingen: fakturer det faktiske nivået som brukes, mens du også viser det forespurte nivået for operasjonell kontekst. Ellers vil leietakere enten bli overrasket over kostnader eller villedet om tjenestekvalitet.

Legg til rekkverk slik at premium ikke blir standard

Når team oppdager et raskere nivå, kan de overbruke det. Sett grenser i gatewayen før bred utrulling.

• Premiumbudsjett per leietaker: Harde månedlige og daglige tak.
• Arbeidsflytgodkjenning: Premium tillatt kun for navngitte arbeidsflyter.
• Trafikkandelstak: For eksempel kan ikke mer enn 10 % av en leietakers synkrone forespørsler bruke interactive_fast uten godkjenning.
• Standard-til-premium-varsel: Varsling når en arbeidsflyt som vanligvis bruker standard oppgraderes.
• Premium burn-rate advarsel: Varsling når anslått forbruk overstiger den godkjente konvolutten.
• Automatisk utløp: Midlertidige nødoverstyringer bør utløpe uten manuell opprydding.
• Batchkvalifiseringskontroller: Blokker massejobber fra synkrone premium-nivåer når de oppfyller batchkriteriene.

Rekkverk skal være vendbart. Under en hendelse kan en autorisert operatør måtte gi en midlertidig premieoverstyring. Denne overstyringen bør ha en årsak, godkjenner, budsjett, utløpstid og revisjonsregistrering.

Implementeringssekvens

En sikker utrulling starter ikke med å slå på premium-ruting overalt. Start med måling.

1. Legg til klassifisering av skyggelag

Klassifiser hver forespørsel i et foreslått gateway-nivå, men ikke endre ruting ennå. Registrer det foreslåtte nivået ved siden av eksisterende metadata for ventetid, kostnader og arbeidsflyt. Dette avslører hvor mye trafikk som ville flyttet til premium-, batch- eller reservert kapasitet hvis policyen ble håndhevet.

2. Lag kapasitetsmatrisen

Liste leverandørmekanismer, støttede modeller, regioner, grenser, rapporteringsfelt og kjent nedgraderingsatferd. Behandle ukjent nedgraderingsatferd som en risiko inntil testet.

3. Håndheve leietakertillatelser i tørrkjøringsmodus

Logg om hver forespørsel vil bli tillatt, nedgradert, satt i kø eller avvist. Del resultatene med produkteiere før håndhevelse.

4. Aktiver ett nivå for én kohort

Velg en smal arbeidsflyt, for eksempel en direkte svarbane for støtte eller en nattlig oppsummeringsjobb. Aktiver det relevante gateway-nivået for en liten leietakerkohort. Mål P50-forsinkelse, P95-forsinkelse, kostnad, nedgraderingsrate, feilfrekvens og brukervendte forretningsberegninger der dette er tilgjengelig.

5. Utvid bare når dataene støtter det

Hvis premium-nivået forbedrer ventetiden, men ikke produktresultatene, må du holde det begrenset. Hvis batchbehandling reduserer kostnadene uten å skade produktets oppførsel, utvid den. Hvis den tilrettelagte kapasiteten er inaktiv, kan du gå tilbake til forpliktelsen eller rute mer forutsigbar trafikk inn i den.

Avveininger å gjøre eksplisitt

• Premiumnivåer med lav latens kan forbedre responsen, men de kan dele hastighetsgrenser eller utløse rampebegrensninger. De er ikke en erstatning for utforming av rategrense.
• Tilsatt kapasitet forbedrer forutsigbarheten, men det kan kaste bort penger når utnyttelsen er lav. Standard- eller batchkapasitet kan være bedre for pigg eller ventetid-tolerant trafikk.
• Batchbehandling kan redusere tokenkostnadene, men det endrer produktadferd fordi svarene er asynkrone og kan komme mye senere.
• Tilbydersnøytrale nivånavn forenkler applikasjonskoden, men gatewayen må ha en oppdatert funksjonsmatrise fordi leverandørene bruker forskjellige navn, grenser, faktureringslinjer og nedgraderingsatferd.
• Automatisk nedgradering forbedrer tilgjengeligheten, men det kan gjøre SLO og faktureringsforventninger uskarpe med mindre gatewayen registrerer det faktiske nivået som brukes.
• Strenge leietakerkontroller forhindrer overraskende utgifter, men altfor rigide retningslinjer kan blokkere presserende produksjonsarbeidsflyter med mindre det er en kontrollert overstyringsbane.

Prediksjon: Tjenestenivået vil bli en førsteklasses rutedimensjon

Prediksjon: Etter hvert som modell-API-er modnes, vil tjenestenivået bli like viktig for AI-ruting som modellvalg, region og kontekstvindu. Lagene vil ikke bare spørre "hvilken modell skal svare på dette?" De vil spørre "hvilken modell, under hvilken kapasitetsklasse, for hvilket leietakerbudsjett, med hvilken nedgraderingspolitikk?"

Anbefaling: Design gateway-reskontro- og policymodellen nå slik at nye leverandørkapasitetsklasser kan legges til uten å endre applikasjonskoden. Selv om du begynner med bare standard og batch, bruk felt som requested_gateway_tier, selected_provider_tier og tier_outcome fra starten.

Aktiv sjekkliste

• Definer ikke mer enn fem leverandørnøytrale gateway-nivåer.
• Krev at hver API-nøkkel erklærer hvilke nivåer og arbeidsflyter den kan bruke.
• Bygg en leverandørkapasitetsmatrise for premium-, standard-, klargjort-, batch- og spillover-atferd.
• Registrer forespurt nivå, valgt nivå, nedgradering eller spillover-utfall, ventetid, bruk og avgjorte kostnader.
• Standard nye nøkler til standard- eller bakgrunnsnivåer.
• Legg til premiumbudsjetter, trafikkandelsbegrensninger og varsler.
• Gjør nedgraderingsadferd eksplisitt per arbeidsflyt.
• Begynn med skyggeberegninger før håndhevelse.
• Rull ut premium eller klargjort kapasitet til en liten kohort først.
• Utvid bare når ventetid, pålitelighet eller forretningsberegninger rettferdiggjør kostnadene.

Konklusjon

Tjenestelagsruting hører hjemme i AI API-gatewayen fordi det er en tverrgående policybeslutning. Det påvirker ventetid, kostnader, kvoter, leietakertillatelser, fakturaer og driftsforventninger. Applikasjonsteam bør ikke hardkode leverandørspesifikke nivånavn eller distribusjonsklasser bare for å uttrykke at det haster med arbeidsbelastning.

En praktisk gateway avslører nøytrale nivåer som interactive_fast, interactive_standard, reserved_capacity og background_rabatt. Den kartlegger disse nivåene til leverandørspesifikke mekanismer, håndhever leietakertillatelser, registrerer det faktiske resultatet og gjør premiumkapasitet til et tilsiktet unntak i stedet for standardbanen.

Relatert lesing

• tenrpm-gateways/ shaping before provider 429s
• holdbart gatewaymønster for asynkrone batchjobber
• faktureringsreskontro for tilbud, reservere, avregne og avstemme