Usmerjanje na ravni storitev v prehodu AI API: hitro, standardno, omogočeno in paketno brez ponudnikov trdega kodiranja

Ta seznam ravni je namenoma majhen. Če ustvarite dvajset stopenj, bodo razvijalci zaobšli sistem. Prehod lahko še vedno preslika eno nevtralno raven v več notranjih mehanizmov, specifičnih za ponudnika.

Ločite zahtevano raven od izbrane ravni

Klicatelj mora poslati zahtevano raven, vendar mora prehod zabeležiti tako zahtevano raven kot dejansko izbrano raven. Niso vedno enaki.

Primer metapodatkov zahteve:

{
  "model": "podpora-klepet-privzeto",
  "sporočila": [...],
  "metapodatki": {
    "workflow": "customer_support_reply",
    "tenant_id": "najemnik_123",
    "requested_gateway_tier": "interaktivno_hitro",
    "end_user_id": "u_789"
  }
}

Primer zapisa o odpremi:

{
  "request_id": "req_abc",
  "tenant_id": "najemnik_123",
  "api_key_id": "key_live_456",
  "workflow": "customer_support_reply",
  "model_alias": "podpora-klepet-privzeto",
  "requested_gateway_tier": "interaktivno_hitro",
  "selected_provider": "ponudnik_a",
  "selected_provider_tier": "hitro",
  "tier_outcome": "izbrano_kot_zahtevano",
  "downgrade_reason": nič,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_ms": 1420,
  "estimated_cost_usd": "0,0312",
  "settled_cost_usd": "0,0308"
}

Če je premijska zahteva poslana v standardno obdelavo zaradi omejitev rampe ali proračunskih pravil najemnika, mora biti to vidno:

{
  "requested_gateway_tier": "interaktivno_hitro",
  "selected_provider_tier": "standard",
  "tier_outcome": "znižano",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

To razlikovanje preprečuje zavajajoče analize. Če je na nadzornih ploščah prikazano samo tisto, kar je klicatelj zahteval, bodo finance videle premium namen, ne pa tudi premium izvedbe. Če nadzorne plošče prikazujejo samo rezultat navzgor, produktne ekipe ne bodo vedele, kdaj je bila njihovemu na zakasnitev občutljivemu delovnemu toku zavrnjena premijska zmogljivost.

Izdelajte matriko zmogljivosti pred usmerjanjem

Storitveni usmerjevalnik potrebuje matriko zmogljivosti. Matrika mora odgovoriti: kateri mehanizmi zmogljivosti so na voljo za dani model, regijo, najemnika in potek dela?

Najmanjše število polj:

• ponudnik
• model_or_deployment
• regije
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Poenostavljen primer:

gateway_tier_map:
  interactive_fast:
    prednostno:
      - ponudnik: openai
        request_params:
          service_tier: hitro
      - ponudnik: anthropic
        request_params:
          service_tier: prioriteta
    nadomestni:
      - raven_prehoda: interaktivni_standard
        dovoljeno_kdaj: policy.allows_standard_downgrade
  background_discount:
    prednostno:
      - ponudnik: anthropic
        način: serija
      - ponudnik: gemini
        način: serija
    nadomestni:
      - čakalna vrsta: delayed_retry
        dovoljeno_kdaj: res
  rezervirana_kapaciteta:
    prednostno:
      - ponudnik: azure_openai
        deployment_class: oskrbovan
    nadomestni:
      - ponudnik: azure_openai
        razpored_razreda: standard
        dovoljeno_ko: policy.allows_spillover

Ta matrika mora biti konfiguracija, ne razpršena koda. Spremembe poimenovanja ponudnika, regionalna razpoložljivost in obračunavanje se bodo sčasoma spremenili. Posodobitev pravilnika prehoda je varnejša kot ponovna namestitev vsake aplikacije, ki kliče API.

Razvrstite delovne obremenitve, preden izberete zmogljivost

Najtežje ni preslikava ponudnika. Odloča se, katere zahteve si zaslužijo katero raven.

Dobri kandidati za interactive_fast

• Glasovni pomočniki, kjer zakasnitev prekine pogovor.
• Klepet, obrnjen k strankam, o poteh konverzije ali zadrževanja z visoko vrednostjo.
• Operacije človeka v zanki, kjer agent aktivno čaka.
• Proizvodni incidenti, pri katerih zakasnitev neposredno vpliva na ublažitev.

Dobri kandidati za interactive_standard

• Notranji kopiloti.
• Podpora za pisanje, kjer človek lahko prenese običajni odzivni čas.
• Funkcije izdelka, pri katerih je odzivni čas pomemben, vendar ni kritičen.

Dobri kandidati za background_discount

• Nočno povzemanje.
• Velika obogatitev dokumentov.
• Ocenjevanja brez povezave.
• Množična vdelava se osveži.
• Označevanje analitike in ustvarjanje poročil.

Dobri kandidati za reserved_capacity

• Stalne delovne obremenitve velikega obsega proizvodnje.
• Pogodbene delovne obremenitve strank s predvidljivimi obveznostmi prepustnosti.
• Promet, ki ne prenaša hrupnih sosednjih variacij in je dovolj izkoriščen, da upraviči namensko zmogljivost.

Preprosto pravilo politike je: ne dovolite klicateljem, da izberejo vrhunsko zmogljivost samo zato, ker imajo raje hitrost. Zahtevajte deklariran potek dela, dovoljenje najemnika in proračunsko ovojnico.

Uveljavi dovoljenja najemnika in ključa API

Vsak najemnik in ključ API-ja bi moral imeti dovoljen nabor ravni. Novi ključi bi morali privzeto uporabljati standardne ravni in ravni v ozadju, ne pa premium ravni.

Primer politike najemnikov:

{
  "tenant_id": "najemnik_123",
  "allowed_gateway_tiers": [
    "interaktivni_standard",
    "background_discount"
  ],
  "premium_tier": {
    "omogočeno": napačno,
    "monthly_budget_usd": "0,00",
    "potrebna_odobritev": res
  },
  "reserved_capacity": {
    "omogočeno": res,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": drži,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Primer preglasitve na ravni ključ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
}

Politika na ravni ključa preprečuje nenamerno razširitev. Razvijalec ne more vzeti ključa, namenjenega glasovnemu prometu, in ga uporabiti za skript množičnega povzemanja, razen če je dovoljen tudi potek dela.

Izrecno načrtujte znižanje in prelivanje

Vedenje za znižanje je odločitev o izdelku, ne le o infrastrukturi. Ko premium ali predvidena zmogljivost ni na voljo, mora prehod izbrati eno od štirih poti:

• Nadaljuj standardno: Uporabno, ko je razpoložljivost pomembnejša od doslednosti zakasnitev.
• Čakalna vrsta: Uporabno za opravila v ozadju in paketna delovna obremenitev.
• Hitra napaka: Uporabno, ko bi bil počasen odziv slabši kot brez odziva, kot so tesne zanke v realnem času.
• Prosi klicatelja, naj poskusi znova: Uporabno, ko lahko odjemalec varno znova poskusi z odmikom in ohranjenim ključem idempotence.

Primer pravilnika:

downgrade_policy:
  voice_control_loop:
    zahtevana_stopnja: interaktivno_hitro
    če_hitro_ni na voljo: neuspešno_hitro
    error_code: tier_capacity_ninavailable
  customer_support_reply:
    zahtevana_stopnja: interaktivno_hitro
    če_hitro_ni na voljo: nadaljuj_standardno
    record_outcome: znižan
  nightly_document_enrichment:
    zahtevana_stopnja: osnovni_popust
    if_batch_unavailable: čakalna vrsta
    max_queue_delay_hours: 24
  contracted_api_customer:
    zahtevana_nivo: rezervirana_zmogljivost
    if_reserved_exhausted: prelivanje_na_standard
    require_spillover_budget: true

Ne skrivaj prelivanja. Prelivanje lahko izboljša razpoložljivost, vendar spremeni stroške in razlago SLO. Računi in analitika morajo prikazati zahtevo za rezervirano zmogljivost, dogodek prelivanja, dejansko uporabljeno standardno zmogljivost in razlog.

Povežite usmerjanje na ravni storitve z obračunavanjem

Prehod ne more nadzorovati premijske porabe, če izbira stopnje ni del glavne knjige. Shranite ta polja za vsako zahtevo ali opravilo:

• Zahtevana stopnja prehoda.
• Izbrana raven ponudnika ali razred zmogljivosti.
• Izid stopnje: izbrano, znižano, nadgrajeno, v čakalni vrsti, prelivanje, zavrnjeno.
• Razlog za izid.
• Identifikatorji najemnika, ključa API-ja, uporabnika in poteka dela.
• Vzdevek modela in predhodni model ali uvedba.
• Predvideni stroški pred odpremo.
• Poravnani stroški, potem ko je znana uporaba ponudnika.
• Zakasnitev in število ponovnih poskusov za sinhrone zahteve.
• Čas paketne oddaje, čas dokončanja in stanje vnosa rezultatov za asinhrona opravila.

S temi polji lahko prehod odgovori na vprašanja, ki si jih zastavijo finance in inženiring:

• Kateri najemniki so ta teden uporabljali premium zmogljivost?
• Kateri poteki dela so povzročili največ premijske porabe?
• Kako pogosto so se premijske zahteve znižale na standardne?
• Ali je interactive_fast dovolj izboljšal zakasnitev p95, da bi upravičil premijo?
• Koliko je paketna obdelava v ozadju prihranila v primerjavi s sinhrono standardno obdelavo?
• Koliko standardnega prelivanja je ustvarila predvidena zmogljivost?

Pomembno priporočilo: fakturirajte dejansko uporabljeno raven, hkrati pa prikažite zahtevano raven za operativni kontekst. V nasprotnem primeru bodo najemniki presenečeni nad stroški ali zavedeni glede kakovosti storitev.

Dodajte zaščitne ograje, da premium ne postane privzeta

Ko ekipe odkrijejo hitrejšo raven, jo lahko pretiravajo. Postavite omejitve v prehod pred široko uvedbo.

• Premijski proračun na najemnika: stroge mesečne in dnevne zgornje meje.
• Odobritev delovnega toka: Premium je dovoljen samo za imenovane delovne tokove.
• Omejitev deleža prometa: Na primer, največ 10 % najemnikovih sinhronih zahtev lahko uporablja interactive_fast brez odobritve.
• Opozorilo s standardnega na premium: Opozorilo, ko je potek dela, ki običajno uporablja standard, nadgrajen.
• Opozorilo o višji stopnji izgorevanja: Opozorilo, ko predvidena poraba preseže odobreno ovojnico.
• Samodejni potek: Začasne preglasitve v sili bi morale poteči brez ročnega čiščenja.
• Paketna preverjanja primernosti: Blokiraj množična opravila iz sinhronih premijskih stopenj, ko izpolnjujejo paketna merila.

Zaščitne ograje morajo biti obrnljive. Med incidentom bo pooblaščeni operater morda moral odobriti začasno preglasitev premije. Ta preglasitev mora imeti razlog, odobritelja, proračun, čas poteka in revizijski zapis.

Zaporedje izvajanja

Varna uvedba se ne začne z vklopom premium usmerjanja povsod. Začnite z merjenjem.

1. Dodajte klasifikacijo senčnih stopenj

Vsako zahtevo razvrstite v predlagano stopnjo prehoda, vendar še ne spreminjajte usmerjanja. Zabeležite predlagano raven poleg obstoječih metapodatkov o zakasnitvi, stroških in delovnem toku. To razkriva, koliko prometa bi se premaknilo na premium, paketno ali rezervirano zmogljivost, če bi bil pravilnik uveljavljen.

2. Ustvarite matriko zmogljivosti

Seznam mehanizmov ponudnika, podprtih modelov, regij, omejitev, polj za poročanje in znanega vedenja za znižanje na prejšnjo različico. Obravnavajte neznano vedenje na znižanje na prejšnjo različico kot tveganje, dokler ni testirano.

3. Uveljavite dovoljenja najemnika v načinu brezplačnega delovanja

Vbeležite, ali bo vsaka zahteva dovoljena, znižana, v čakalni vrsti ali zavrnjena. Delite rezultate z lastniki izdelkov pred uveljavitvijo.

4. Omogočite eno stopnjo za eno kohorto

Izberite ozek potek dela, kot je pot odgovora podpore v živo ali nočno povzemanje. Omogočite ustrezno stopnjo prehoda za majhno kohorto najemnikov. Izmerite zakasnitev p50, zakasnitev p95, ceno, stopnjo znižanja na prejšnjo različico, stopnjo napak in uporabniške poslovne meritve, kjer so na voljo.

5. Razširi le, če podatki to podpirajo

Če premijska stopnja izboljša zakasnitev, ne pa rezultatov izdelka, naj bo omejena. Če paketna obdelava zmanjša stroške brez škode za obnašanje izdelka, jo razširite. Če omogočena zmogljivost miruje, ponovno preglejte zavezo ali vanjo usmerite bolj predvidljiv promet.

Kompromisi, ki naj bodo eksplicitni

• Plavne stopnje z nizko zakasnitvijo lahko izboljšajo odzivnost, vendar si lahko delijo omejitve hitrosti ali sprožijo omejitve ramp. Niso nadomestek za oblikovanje omejitve hitrosti.
• Zagotovljena zmogljivost izboljša predvidljivost, vendar lahko zapravlja denar, ko je izkoriščenost nizka. Standardna ali paketna zmogljivost je morda boljša za promet s pikami ali zakasnitvami tolerantnim.
• Paketna obdelava lahko zmanjša stroške žetonov, vendar spremeni vedenje izdelka, ker so odgovori asinhroni in lahko prispejo veliko pozneje.
• Imena ravni, ki so nevtralna glede ponudnika, poenostavljajo kodo aplikacije, vendar mora prehod vzdrževati posodobljeno matriko zmogljivosti, ker ponudniki uporabljajo različna imena, omejitve, vrstice zaračunavanja in obnašanje v nižji različici.
• Samodejno znižanje izboljša razpoložljivost, vendar lahko zamegli SLO in pričakovanja glede zaračunavanja, razen če prehod zabeleži dejansko uporabljeno raven.
• Strogi nadzori najemnikov preprečujejo nepričakovano porabo, vendar preveč togi pravilniki lahko blokirajo nujne delovne tokove proizvodnje, razen če obstaja nadzorovana preglasitvena pot.

Napoved: raven storitve bo postala prvorazredna dimenzija usmerjanja

Predvidevanje: Ko API-ji modela dozorijo, bo raven storitve postala tako pomembna za usmerjanje z umetno inteligenco kot izbira modela, regija in kontekstno okno. Ekipe se ne bodo spraševale samo "kateri model bi moral odgovoriti na to?" Spraševali se bodo, "kateri model, pod katerim razredom zmogljivosti, za kateri proračun najemnika, s katero politiko nižje stopnje?"

Priporočilo: Oblikujte glavno knjigo prehoda in model pravilnika zdaj, tako da bo mogoče dodati nove razrede zmogljivosti ponudnika brez spreminjanja kode aplikacije. Tudi če začnete samo s standardnim in paketnim, že od začetka uporabite polja, kot so requested_gateway_tier, selected_provider_tier in tier_outcome.

Uporabni kontrolni seznam

• Določite največ pet stopenj prehoda, nevtralnih glede ponudnika.
• Zahtevajte, da vsak ključ API navede, katere ravni in poteke dela lahko uporablja.
• Izdelajte matriko zmogljivosti ponudnika za premium, standardno, oskrbovano, paketno in prelivno vedenje.
• Zabeležite zahtevano stopnjo, izbrano raven, znižanje ali rezultat prelivanja, zakasnitev, uporabo in poravnane stroške.
• Privzeti novi ključi za standardne ali ozadne ravni.
• Dodajte premijske proračune, omejitve deleža prometa in opozorila.
• Vedenje znižanja na prejšnjo različico naj bo eksplicitno za vsak potek dela.
• Začnite s senčnimi meritvami pred uveljavitvijo.
• Najprej uvedite premium ali oskrbljeno zmogljivost za majhno kohorto.
• Razširite se le, če zakasnitev, zanesljivost ali poslovne meritve upravičijo stroške.

Zaključek

Usmerjanje na nivoju storitev sodi v prehod AI API, ker je medsektorska politična odločitev. Vpliva na zakasnitev, stroške, kvote, dovoljenja najemnikov, račune in operativna pričakovanja. Aplikacijske skupine ne bi smele trdo kodirati imen ravni ali razredov uvajanja, specifičnih za ponudnika, samo za izražanje nujnosti delovne obremenitve.

Praktičen prehod izpostavlja nevtralne stopnje, kot so interactive_fast, interactive_standard, reserved_capacity in background_discount. Te ravni preslika v mehanizme, specifične za ponudnika, uveljavlja dovoljenja najemnikov, beleži dejanski izid in naredi premium zmogljivost namerno izjemo in ne privzeto pot.

Sorodno branje

• oblikovanje omejitve stopnje pred ponudnikom 429
• trajni vzorec prehoda za asinhrona paketna opravila
• knjiga obračunavanja za ponudbo, rezervacijo, poravnavo in uskladitev