MGModel Gate
Log indKom i gang
Vejledning og indsigt

Service-Tier Routing i en AI API Gateway: Hurtig, standard, klargjort og batch uden hårdkodningsudbydere

En praktisk arkitektur til at eksponere udbyderneutrale AI-arbejdsbelastningsniveauer ved gatewayen og derefter kortlægge hver anmodning til hurtig, standard, klargjort eller batchkapacitet med lejerkontroller, analyser og faktureringsposter.

12 min læstModel Gate Editorial Team

Service-tier routing er det politiklag, der afgør, om en AI-anmodning fortjener premium lav-latenskapacitet, normal on-demand-kapacitet, reserveret gennemløb eller nedsat asynkron behandling. Uden dette lag koder applikationsteams normalt udbyderspecifikke flag, implementeringsnavne og batchendepunkter direkte i produktkoden. Det gør ventetid, omkostninger, kvote og lejers faktureringsadfærd vanskelig at styre.

Gatewayen skal afsløre hensigten med arbejdsbelastning, ikke udbydermekanik. Et produktteam bør være i stand til at sige "dette er et interaktivt supportsvar" eller "dette er en natlig berigelsesjob", mens gatewayen kortlægger den hensigt til den rigtige opstrømskapacitetsmulighed og registrerer, hvad der rent faktisk skete.

Læserproblemet: kapacitetsklasser bliver til applikationslogik

Teams, der bruger mere end én modeludbyder, starter ofte med simpel modelrouting: Send dette model-id til denne udbyder. Routingen bliver sværere, når udbydere afslører forskellige kapacitetsklasser:

  • Premium lav-latens anmodningshåndtering for brugervendte stier.
  • Standard delt kapacitet for almindelig synkron trafik.
  • Dedikeret eller klargjort kapacitet til forudsigelig gennemstrømning.
  • Batch eller asynkrone API'er til latencytolerante arbejdsbelastninger.
  • Spillover-adfærd, når reserveret kapacitet er opbrugt.

Hvis hver applikation håndterer disse valg selv, mister organisationen kontrollen over fire ting: hvem der kan bruge premiumkapacitet, hvor meget det koster, hvad der sker, når kapaciteten ikke er tilgængelig, og om det valgte niveau forbedrede produktet nok til at retfærdiggøre forbruget.

Det praktiske mønster er at placere et udbyderneutralt servicekvalitetslag i AI API-gatewayen.

Fakta at bygge videre på

Detaljerne varierer fra udbyder til udbyder, men adskillige observerbare fakta understøtter et design på gateway-niveau.

  • Faktum: Nogle udbydere afslører et serviceniveau pr. anmodning for premium-behandling. OpenAI beskriver hurtig tilstand som en per-anmodningsmulighed ved hjælp af parameteren service_tier og siger, at den faktureres til en præmie i forhold til standardbehandling. OpenAI oplyser også, at prioritetsbehandling blev omdøbt til hurtig tilstand den 30. juli 2026, mens både service_tier=priority og service_tier=fast accepteres for API-anmodninger.
  • Faktum: Håndtering af premium-anmodninger er muligvis ikke et separat kvoteunivers. OpenAI bemærker, at hastighedsgrænser for hurtig tilstand deles med andre serviceniveauer, og at hurtige trafikstigninger kan udløse rampehastighedsadfærd, hvor noget trafik i stedet kan sendes til standardbehandling.
  • Faktum: Serviceniveau kan være en rapporterings- og faktureringsdimension. OpenAI siger, at API-kunder kan gruppere brugsdashboarddata efter serviceniveau og linjepost. Antropiske dokumenter standard, prioritet og batch som serviceniveauværdier i API-brugsrapportering.
  • Faktum: Batch-API'er kan reducere omkostningerne for asynkront arbejde væsentligt. Antropisk prisdokumentation siger, at dets Batch API understøtter asynkron storvolumenbehandling med 50 % rabat på input- og outputtokens. Googles Gemini Batch API-dokumentation beskriver store asynkrone arbejdsbelastninger til 50 % af standardomkostningerne, med afvejninger, f.eks. op til 24 timer for nogle højvolumenopgaver.
  • Faktum: Leveret gennemløb er en separat kapacitetsmodel. Microsoft dokumenterer Azure OpenAI klargjort gennemløb som dedikeret kapacitet, i modsætning til standardimplementeringer, hvor kapaciteten deles, og gennemløbet kan variere med efterspørgslen. Microsoft dokumenterer også afsmitning fra klargjorte implementeringer til standardimplementeringer i den samme Azure OpenAI-ressource.

Anbefalingen er ikke at afspejle hvert udbyderudtryk i applikationskoden. Anbefalingen er at normalisere disse mekanismer til forretningsorienterede gateway-niveauer.

Definer udbyderneutrale gateway-niveauer

Start med at navngive niveauer for arbejdsbelastningsadfærd, ikke leverandørterminologi. En nyttig første taksonomi er:

Gateway-niveau Typisk arbejdsbyrde Forventning af ventetid Omkostningsstilling Standard nedgraderingsadfærd interactive_fast Stemmesløjfer, livechat, brugerhandlinger af høj værdi Laveste praktiske latenstid Premium tilladt Fortsæt på standard eller fejl hurtigt, afhængigt af arbejdsgangen interactive_standard Normal chat, supportudkast, interne copiloter Synkron Standardpris Prøv igen, fald tilbage eller returner en kontrolleret fejl reserveret_kapacitet Forudsigelig produktionstrafik med konstant udnyttelse Forudsigelig gennemløb Forudbetalt eller forpligtet kapacitet Spil kun over, når politikken tillader det baggrundsrabat Evalueringer, berigelse, opsummering, indlejringer, rapporter Asynkron Rabat foretrækkes Sæt i kø, indtil en batchsti er tilgængelig emergency_fallback Hændelsesreaktion eller midlertidig kundeeskalering Politikafhængig Kontrolleret undtagelse Udløber automatisk efter godkendelsesvindue

Denne liste er bevidst lille. Hvis du opretter tyve niveauer, vil udviklere omgå systemet. Gatewayen kan stadig kortlægge ét neutralt niveau til flere udbyderspecifikke mekanismer internt.

Adskil det anmodede niveau fra det valgte niveau

Den, der ringer, skal sende et anmodet niveau, men gatewayen skal registrere både det anmodede niveau og det faktisk valgte niveau. De er ikke altid de samme.

Eksempel på anmodningsmetadata:

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

Eksempel på afsendelsespost:

{ "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": "hurtigt", "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 præmieanmodning sendes til standardbehandling på grund af rampegrænser eller lejerbudgetregler, skal det være synligt:

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

Denne sondring forhindrer vildledende analyser. Hvis dashboards kun viser, hvad den, der ringer, anmoder om, vil finans se premium-hensigter, men ikke premium-udførelse. Hvis dashboards kun viser upstream-resultatet, vil produktteams ikke vide, hvornår deres latensfølsomme arbejdsgang blev nægtet premiumkapacitet.

Byg en funktionsmatrix før routing

En service-tier-router har brug for en funktionsmatrix. Matrixen skal svare: Hvilke kapacitetsmekanismer er tilgængelige for en given model, region, lejer og arbejdsgang?

Minimum felter:

  • udbyder
  • model_or_deployment
  • regioner
  • understøtter_sync
  • understøtter_batch
  • understøtter_premium_tier
  • supports_provisioned_capacity
  • supports_spillover
  • provider_tier_values
  • billing_line_items
  • kendt_nedgraderingsadfærd
  • tenant_allowlist

Et forenklet eksempel:

gateway_tier_map:
  interaktiv_hurtig:
    foretrækkes:
      - udbyder: openai
        request_params:
          service_tier: hurtig
      - udbyder: antropisk
        request_params:
          service_tier: prioritet
    tilbagefald:
      - gateway_tier: interaktiv_standard
        tilladt_når: policy.allows_standard_downgrade
  baggrundsrabat:
    foretrækkes:
      - udbyder: antropisk
        tilstand: batch
      - udbyder: gemini
        tilstand: batch
    tilbagefald:
      - kø: forsinket_forsøg igen
        tilladt_når: sandt
  reserveret_kapacitet:
    foretrækkes:
      - udbyder: azure_openai
        deployment_class: klargjort
    tilbagefald:
      - udbyder: azure_openai
        deployment_class: standard
        allow_when: policy.allows_spillover

Denne matrix skal være konfiguration, ikke spredt kode. Ændringer af udbyderens navne, regional tilgængelighed og faktureringsbehandling vil ændre sig over tid. Opdatering af en gateway-politik er sikrere end at ominstallere alle programmer, der kalder API'en.

Klassificer arbejdsbelastninger, før du vælger kapacitet

Den sværeste del er ikke udbyderkortlægningen. Det er at bestemme, hvilke anmodninger der fortjener hvilket niveau.

Gode kandidater til interactive_fast

  • Stemmeassistenter, hvor forsinkelse bryder samtalen.
  • Kundevendt chat på konverterings- eller fastholdelsesstier af høj værdi.
  • Human-in-the-loop operationer, hvor en agent aktivt venter.
  • Produktionshændelser, hvor ventetid direkte påvirker afbødning.

Gode kandidater til interactive_standard

  • Interne copiloter.
  • Støt udarbejdelse, hvor et menneske kan tolerere normal responstid.
  • Produktfunktioner, hvor responstiden er vigtig, men ikke er kritisk.

Gode kandidater til baggrundsrabat

  • Natlig opsummering.
  • Stor dokumentberigelse.
  • Offlineevalueringer.
  • Masseindlejring opdateres.
  • Analytics-mærkning og rapportgenerering.

Gode kandidater til reserved_capacity

  • Konstant produktionsbelastning i store mængder.
  • Kontrakterede kundearbejdsbelastninger med forudsigelige gennemløbsforpligtelser.
  • Trafik, der ikke kan tolerere støjende nabovariationer og har tilstrækkelig udnyttelse til at retfærdiggøre dedikeret kapacitet.

En simpel politikregel er: Tillad ikke opkaldere at vælge premiumkapacitet, blot fordi de foretrækker hastighed. Kræv en erklæret arbejdsgang, lejertilladelse og budgetkonvolut.

Håndhæv lejer- og API-nøgletilladelser

Hver lejer og API-nøgle bør have et tilladt niveausæt. Nye nøgler skal som standard være standard- og baggrundsniveauer, ikke premium-niveauer.

Eksempel på lejerpolitik:

{ "tenant_id": "tenant_123", "allowed_gateway_tiers": [ "interactive_standard", "baggrundsrabat" ], "premium_tier": { "enabled": falsk, "monthly_budget_usd": "0,00", "godkendelse_påkrævet": sand }, "reserved_capacity": { "aktiveret": sandt, "deployment_pool": "support-prod-ptu", "allow_spillover_to_standard": sandt, "spillover_monthly_budget_usd": "500,00" } }

Eksempel på tilsidesættelse af nøgleniveau:

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

Nøgleniveaupolitikken forhindrer utilsigtet udvidelse. En udvikler kan ikke tage en nøgle beregnet til stemmetrafik og bruge den til et masseopsummeringsscript, medmindre arbejdsgangen også er tilladt.

Design nedgradering og afsmittende adfærd eksplicit

Downgrade-adfærd er en produktbeslutning, ikke kun en infrastrukturbeslutning. Når premium eller klargjort kapacitet ikke er tilgængelig, bør gatewayen vælge en af fire stier:

  • Fortsæt på standard: Nyttigt, når tilgængelighed betyder mere end latenskonsistens.
  • Kø: Nyttigt til baggrundsjob og batch-arbejdsbelastninger.
  • Fejl hurtigt: Nyttigt, når en langsom respons ville være værre end ingen respons, såsom tætte realtidsløkker.
  • Bed den, der ringer om at prøve igen: Nyttigt, når klienten sikkert kan prøve igen med en backoff og en bevaret idempotensnøgle.

Eksempel på politik:

downgrade_policy:
  stemmestyringsløkke:
    requested_tier: interaktiv_hurtig
    if_fast_unavailable: fail_fast
    fejlkode: tier_capacity_unavailable
  kundesupport_svar:
    requested_tier: interaktiv_hurtig
    if_hurtig_ikke tilgængelig: fortsæt_på_standard
    record_outcome: nedgraderet
  natlig_dokumentberigelse:
    requested_tier: baggrundsrabat
    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: sand

Skjul ikke afsmitning. Spillover kan forbedre tilgængeligheden, men det ændrer omkostninger og SLO-fortolkning. Fakturaer og analyser skal vise anmodningen om reserveret kapacitet, afsmitningshændelsen, den faktisk anvendte standardkapacitet og årsagen.

Forbind service-tier routing til fakturering

En gateway kan ikke kontrollere præmieudgifter, hvis niveauvalg ikke er en del af hovedbogen. Gem disse felter for hver anmodning eller opgave:

  • Anmodet gateway-niveau.
  • Valgt udbyderniveau eller kapacitetsklasse.
  • Tierresultat: valgt, nedgraderet, opgraderet, i kø, afsmittende, afvist.
  • Årsag til resultatet.
  • Lejer-, API-nøgle-, bruger- og workflow-id'er.
  • Modelalias og opstrømsmodel eller implementering.
  • Anslået pris før afsendelse.
  • Afregnet pris, efter at udbyderens brug er kendt.
  • Latency og genforsøg tæller for synkrone anmodninger.
  • Batchindsendelsestid, afslutningstid og resultatoptagelsesstatus for asynkrone opgaver.

Med disse felter kan gatewayen besvare de spørgsmål, finans og teknik vil stille:

  • Hvilke lejere brugte premiumkapacitet i denne uge?
  • Hvilke arbejdsgange forårsagede det største forbrug?
  • Hvor ofte blev premium-anmodninger nedgraderet til standard?
  • Forbedrede interactive_fast p95-forsinkelsen nok til at retfærdiggøre præmien?
  • Hvor meget sparede batchbehandling i baggrunden sammenlignet med synkron standardbehandling?
  • Hvor meget standardafsmitning genererede den klargjorte kapacitet?

Den vigtige anbefaling: fakturer det faktiske anvendte niveau, mens du også viser det anmodede niveau for operationel sammenhæng. Ellers vil lejere enten blive overrasket over omkostninger eller vildledt om servicekvalitet.

Tilføj autoværn, så premium ikke bliver standard

Når teams opdager et hurtigere niveau, kan de overbruge det. Sæt grænser i gatewayen før bred udrulning.

  • Premiumbudget pr. lejer: Hårde månedlige og daglige lofter.
  • Workflow-godkendelse: Premium tilladt kun for navngivne workflows.
  • Trafikandelsloft: For eksempel må ikke mere end 10 % af en lejers synkrone anmodninger bruge interactive_fast uden godkendelse.
  • Standard-til-premium-advarsel: Advarsel, når en arbejdsgang, der normalt bruger standard, opgraderes.
  • Advarsel om høj forbrændingshastighed: Advarsel, når det forventede forbrug overstiger den godkendte ramme.
  • Automatisk udløb: Midlertidige nødtilsidesættelser bør udløbe uden manuel oprydning.
  • Batch-kvalificeringstjek: Bloker massejob fra synkrone premium-niveauer, når de opfylder batchkriterier.

Rækværk skal være vendbare. Under en hændelse kan en autoriseret operatør være nødt til at give en midlertidig præmietilsidesættelse. Denne tilsidesættelse skal have en årsag, godkender, budget, udløbstid og revisionsregistrering.

Implementeringssekvens

En sikker udrulning starter ikke med at aktivere premium-routing overalt. Start med måling.

1. Tilføj shadow tier-klassificering

Klassificer hver anmodning i et foreslået gateway-niveau, men skift ikke routing endnu. Registrer det foreslåede niveau ud for eksisterende metadata for ventetid, omkostninger og arbejdsgange. Dette afslører, hvor meget trafik der ville flytte til premium-, batch- eller reserveret kapacitet, hvis politikken blev håndhævet.

2. Opret kapacitetsmatrixen

Liste udbydermekanismer, understøttede modeller, regioner, grænser, rapporteringsfelter og kendt nedgraderingsadfærd. Behandl ukendt nedgraderingsadfærd som en risiko, indtil den er testet.

3. Håndhæv lejertilladelser i tørløbstilstand

Log, om hver anmodning vil blive tilladt, nedgraderet, sat i kø eller afvist. Del resultaterne med produktejere før håndhævelse.

4. Aktiver ét niveau for én kohorte

Vælg en snæver arbejdsgang, såsom en live-svarsti til support eller et opsummeringsjob om natten. Aktiver det relevante gateway-niveau for en lille lejerkohorte. Mål p50-latens, p95-latens, omkostninger, nedgraderingsrate, fejlrate og brugervendte forretningsmetrics, hvor de er tilgængelige.

5. Udvid kun, når dataene understøtter det

Hvis premium-tier forbedrer latens, men ikke produktresultater, skal du holde det begrænset. Hvis batchbehandling reducerer omkostningerne uden at skade produktets adfærd, skal du udvide den. Hvis den klargjorte kapacitet er inaktiv, skal du gense forpligtelsen eller dirigere mere forudsigelig trafik ind i den.

Afvejninger at gøre eksplicit

  • Premium-niveauer med lav latens kan forbedre reaktionsevnen, men de kan dele hastighedsgrænser eller udløse rampebegrænsninger. De er ikke en erstatning for hastighedsgrænseudformning.
  • Tilsat kapacitet forbedrer forudsigeligheden, men det kan spilde penge, når udnyttelsen er lav. Standard- eller batchkapacitet kan være bedre til spiky eller latenstid-tolerant trafik.
  • Batchbehandling kan reducere tokenomkostninger, men det ændrer produktadfærd, fordi svarene er asynkrone og kan komme meget senere.
  • Udbydersneutrale niveaunavne forenkler applikationskoden, men gatewayen skal opretholde en opdateret funktionsmatrix, fordi udbydere bruger forskellige navne, grænser, faktureringslinjer og nedgraderingsadfærd.
  • Automatisk nedgradering forbedrer tilgængeligheden, men det kan sløre SLO- og faktureringsforventninger, medmindre gatewayen registrerer det faktiske anvendte niveau.
  • Strenge lejerkontrol forhindrer overraskende udgifter, men alt for stive politikker kan blokere presserende produktionsarbejdsgange, medmindre der er en kontrolleret tilsidesættelsessti.

Forudsigelse: Serviceniveauet bliver en førsteklasses routingdimension

Forudsigelse: Efterhånden som model-API'er modnes, bliver serviceniveauet lige så vigtigt for AI-routing som modelvalg, region og kontekstvindue. Hold vil ikke kun spørge "hvilken model skal svare på dette?" De vil spørge "hvilken model, under hvilken kapacitetsklasse, for hvilket lejerbudget, med hvilken nedgraderingspolitik?"

Anbefaling: Design gateway-ledger- og politikmodellen nu, så nye udbyderkapacitetsklasser kan tilføjes uden at ændre applikationskoden. Selvom du kun begynder med standard og batch, skal du bruge felter såsom requested_gateway_tier, selected_provider_tier og tier_outcome fra starten.

Aktiv tjekliste

  • Definer ikke mere end fem udbyderneutrale gateway-niveauer.
  • Kræv, at hver API-nøgle erklærer, hvilke niveauer og arbejdsgange den må bruge.
  • Byg en matrix for udbyderkapacitet til premium-, standard-, provisioned-, batch- og spillover-adfærd.
  • Registrer det anmodede niveau, det valgte niveau, nedgraderings- eller afsmittende resultat, latens, brug og afgjorte omkostninger.
  • Nye standardnøgler til standard- eller baggrundsniveauer.
  • Tilføj premiumbudgetter, trafikandelslofter og advarsler.
  • Gør nedgraderingsadfærd eksplicit pr. workflow.
  • Start med skyggemålinger før håndhævelse.
  • Rul først præmie eller klargjort kapacitet til en lille kohorte.
  • Udvid kun, når ventetid, pålidelighed eller forretningsmålinger retfærdiggør omkostningerne.

Konklusion

Service-tier-routing hører hjemme i AI API-gatewayen, fordi det er en tværgående politisk beslutning. Det påvirker latenstid, omkostninger, kvoter, lejertilladelser, fakturaer og driftsforventninger. Applikationsteams bør ikke fastkode udbyderspecifikke niveaunavne eller implementeringsklasser bare for at udtrykke, hvor meget arbejdsbyrden er.

En praktisk gateway afslører neutrale niveauer såsom interactive_fast, interactive_standard, reserved_capacity og background_rabat. Det kortlægger disse niveauer til udbyderspecifikke mekanismer, håndhæver lejertilladelser, registrerer det faktiske resultat og gør premium-kapacitet til en bevidst undtagelse snarere end standardstien.

Relateret læsning

FAQ

Ofte stillede spørgsmål

Skal applikationer vælge udbyderspecifikke serviceniveauer direkte?
Normalt nej. Applikationer skal sende arbejdsbelastningsintentioner eller et udbyderneutralt gateway-niveau. Gatewayen bør oversætte det til udbyderspecifikke parametre, implementeringer, batch-API'er eller afsmittende regler.
Er premium lav-latenskapacitet en erstatning for styring af hastighedsgrænser?
Nej. Premium-niveauer kan stadig dele hastighedsgrænser eller blive påvirket af rampeadfærd. Gatewayen har stadig brug for kvotevurdering, burst-udjævning, lejers retfærdighed og politik for genforsøg.
Hvornår skal en arbejdsbelastning bruge batch i stedet for synkron standardkapacitet?
Brug batch, når produktet kan tåle asynkron færdiggørelse: offlineevalueringer, dokumentberigelse, natlige oversigter, masseindlejringer og rapportgenerering er almindelige kandidater.
Hvad skal registreres for fakturering?
Registrer det anmodede gatewayniveau, faktiske udbyderniveau eller kapacitetsklasse, nedgraderings- eller afsmittende resultat, årsag, lejer, nøgle, arbejdsgang, tokenbrug, latens, estimerede omkostninger og afregnede omkostninger.
Fortsæt med at læse

Relaterede artikler

Se alle artikler →