Usmjeravanje razine usluge u pristupniku AI API-ja: brzo, standardno, osigurano i paketno bez hard kodiranja pružatelja usluga

Ovaj popis razina namjerno je malen. Ako stvorite dvadeset razina, programeri će zaobići sustav. Gateway još uvijek može preslikati jednu neutralnu razinu na nekoliko internih mehanizama specifičnih za pružatelja usluga.

Odvojite zatraženu razinu od odabrane razine

Pozivatelj bi trebao poslati traženu razinu, ali pristupnik treba zabilježiti i traženu razinu i stvarno odabranu razinu. To nije uvijek isto.

Primjer metapodataka zahtjeva:

{
  "model": "podrška-za-razgovor",
  "poruke": [...],
  "metapodaci": {
    "workflow": "customer_support_reply",
    "stanar_id": "stanar_123",
    "requested_gateway_tier": "interaktivno_brzo",
    "end_user_id": "u_789"
  }
}

Primjer zapisa o otpremi:

{
  "request_id": "req_abc",
  "stanar_id": "stanar_123",
  "api_key_id": "ključ_live_456",
  "workflow": "customer_support_reply",
  "model_alias": "podrška-chat-default",
  "requested_gateway_tier": "interaktivno_brzo",
  "selected_provider": "provider_a",
  "selected_provider_tier": "brzo",
  "tier_outcome": "odabrano_kao_zatraženo",
  "downgrade_reason": null,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_ms": 1420,
  "estimated_cost_usd": "0,0312",
  "settled_cost_usd": "0,0308"
}

Ako se premium zahtjev šalje standardnoj obradi zbog ograničenja rampe ili pravila proračuna stanara, to mora biti vidljivo:

{
  "requested_gateway_tier": "interaktivno_brzo",
  "selected_provider_tier": "standard",
  "tier_outcome": "niže",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

Ova razlika sprječava lažnu analitiku. Ako nadzorne ploče prikazuju samo ono što je pozivatelj zatražio, financije će vidjeti premium namjeru, ali ne i premium izvršenje. Ako nadzorne ploče prikazuju samo uzlazne rezultate, proizvodni timovi neće znati kada je njihovom tijeku rada osjetljivom na latenciju odbijen premium kapacitet.

Izradite matricu mogućnosti prije usmjeravanja

Uslužni usmjerivač treba matricu mogućnosti. Matrica bi trebala odgovoriti: za određeni model, regiju, stanara i tijek rada, koji su mehanizmi kapaciteta dostupni?

Minimalni broj polja:

• pružatelj usluga
• model_or_deployment
• regije
• supports_sync
• supports_batch
• podržava_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Pojednostavljeni primjer:

gateway_tier_map:
  interaktivno_brzo:
    poželjno:
      - pružatelj: openai
        parametri_zahtjeva:
          service_tier: brzo
      - pružatelj: antropski
        parametri_zahtjeva:
          service_tier: prioritet
    zamjena:
      - gateway_tier: interaktivni_standard
        dozvoljeno_kada: politika.dopušta_standardno_spuštanje
  pozadinski_popust:
    poželjno:
      - pružatelj: antropski
        način rada: serija
      - pružatelj: gemini
        način rada: serija
    zamjena:
      - red čekanja: odgođeno_ponovni pokušaj
        dozvoljeno_kada: istina
  rezervirani_kapacitet:
    poželjno:
      - pružatelj: azure_openai
        deployment_class: omogućeno
    zamjena:
      - pružatelj: azure_openai
        klasa_ugradnje: standard
        dozvoljeno_kada: politika.allows_spillover

Ova matrica bi trebala biti konfiguracijski, a ne raspršeni kod. Promjene naziva davatelja, regionalna dostupnost i način naplate mijenjat će se s vremenom. Ažuriranje pravila pristupnika sigurnije je od ponovnog postavljanja svake aplikacije koja poziva API.

Klasificirajte radna opterećenja prije odabira kapaciteta

Najteži dio nije mapiranje pružatelja usluga. Odlučuje koji zahtjevi zaslužuju koju razinu.

Dobri kandidati za interactive_fast

• Glasovni pomoćnici gdje kašnjenje prekida razgovor.
• Chat s klijentima o konverzijama visoke vrijednosti ili putovima zadržavanja.
• Operacije čovjeka u petlji gdje agent aktivno čeka.
• Proizvodni incidenti gdje latencija izravno utječe na ublažavanje.

Dobri kandidati za interactive_standard

• Unutarnji kopiloti.
• Podržite izradu nacrta gdje čovjek može tolerirati normalno vrijeme odgovora.
• Značajke proizvoda kod kojih je vrijeme odgovora važno, ali nije kritično.

Dobri kandidati za background_discount

• Noćno sažimanje.
• Veliko obogaćivanje dokumenata.
• Izvanmrežne evaluacije.
• Skupno ugrađivanje osvježava.
• Analitičko označavanje i generiranje izvješća.

Dobri kandidati za reserved_capacity

• Stabilna radna opterećenja velike količine proizvodnje.
• Ugovorena radna opterećenja korisnika s predvidljivim obvezama protoka.
• Promet koji ne može tolerirati bučne varijacije susjeda i ima dovoljno iskorištenja da opravda namjenski kapacitet.

Jednostavno pravilo pravila glasi: nemojte dopustiti pozivateljima da odaberu vrhunski kapacitet samo zato što više vole brzinu. Zahtijeva deklarirani tijek rada, dozvolu stanara i proračunsku omotnicu.

Primjena dopuštenja stanara i API-ključa

Svaki stanar i API ključ trebaju imati dopušteni skup razina. Novi ključevi trebali bi imati standardne i pozadinske razine, a ne premium razine.

Primjer pravila zakupca:

{
  "stanar_id": "stanar_123",
  "allowed_gateway_tiers": [
    "interaktivni_standard",
    "background_discount"
  ],
  "premium_tier": {
    "omogućeno": netočno,
    "monthly_budget_usd": "0,00",
    "potrebno_odobrenje": točno
  },
  "rezervirani_kapacitet": {
    "omogućeno": istina,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": točno,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Primjer nadjačavanja na razini 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
}

Pravilo razine ključa sprječava slučajno proširenje. Razvojni programer ne može uzeti ključ namijenjen glasovnom prometu i koristiti ga za skupnu skriptu sažimanja osim ako tijek rada također nije dopušten.

Izričito osmislite ponašanje na nižu verziju i prelijevanje

Ponašanje na stariju verziju je odluka o proizvodu, a ne samo o infrastrukturi. Kada premium ili osigurani kapacitet nije dostupan, pristupnik bi trebao odabrati jedan od četiri puta:

• Nastavi prema standardu: Korisno kada je dostupnost važnija od dosljednosti latencije.
• Red čekanja: Korisno za pozadinske poslove i skupna radna opterećenja.
• Brza neuspjeh: Korisno kada bi spor odgovor bio gori od izostanka odgovora, kao što su uske petlje u stvarnom vremenu.
• Zamolite pozivatelja da pokuša ponovno: Korisno kada klijent može sigurno ponovno pokušati uz odustanak i sačuvani ključ idempotencije.

Primjer pravila:

downgrade_policy:
  petlja_glasovne_kontrole:
    tražena_razina: interaktivno_brzo
    ako_brzo_nedostupno: fail_fast
    error_code: nivo_kapaciteta_nedostupan
  korisnička_podrška_odgovor:
    tražena_razina: interaktivno_brzo
    ako_brzo_nedostupno: nastavi_standardno
    record_outcome: smanjeno
  noćno_obogaćivanje_dokumenta:
    traženi_nivo: pozadinski_popust
    if_batch_unavailable: red čekanja
    max_queue_delay_hours: 24
  ugovoreni_api_kupac:
    traženi_nivo: rezervirani_kapacitet
    if_reserved_exhausted: prelijevanje_na_standard
    require_spillover_budget: true

Ne skrivaj prelijevanje. Prelijevanje može poboljšati dostupnost, ali mijenja troškove i SLO tumačenje. Fakture i analitika trebaju pokazati zahtjev za rezerviranim kapacitetom, događaj prelijevanja, standardni kapacitet koji se stvarno koristi i razlog.

Povežite usmjeravanje na razini usluge s naplatom

Gateway ne može kontrolirati premijsku potrošnju ako izbor razine nije dio glavne knjige. Pohranite ova polja za svaki zahtjev ili posao:

• Zatražena razina pristupnika.
• Odabrana razina pružatelja ili klasa kapaciteta.
• Ishod razine: odabrano, smanjena, nadograđena, u redu čekanja, prelijevanje, odbijeno.
• Razlog ishoda.
• Identifikatori stanara, API ključa, korisnika i tijeka rada.
• Pseudonim modela i uzvodni model ili implementacija.
• Procijenjeni trošak prije otpreme.
• Troškovi podmireni nakon što je davatelj usluga poznat.
• Kašnjenje i broj ponovnih pokušaja za sinkrone zahtjeve.
• Vrijeme grupne predaje, vrijeme dovršetka i status unosa rezultata za asinkrone poslove.

S tim poljima pristupnik može odgovoriti na pitanja koja će postaviti financije i inženjering:

• Koji su stanari ovaj tjedan koristili premium kapacitet?
• Koji su tijekovi rada uzrokovali najveću potrošnju?
• Koliko su se često premium zahtjevi smanjivali na standardne?
• Je li interactive_fast dovoljno poboljšao kašnjenje p95 da opravda premiju?
• Koliko je pozadinska skupna obrada uštedjela u usporedbi sa sinkronom standardnom obradom?
• Koliko je standardnog prelijevanja generirao osigurani kapacitet?

Važna preporuka: fakturirajte stvarno korištenu razinu, dok također prikazujete traženu razinu za operativni kontekst. Inače će stanari biti iznenađeni cijenom ili zavedeni u pogledu kvalitete usluge.

Dodajte zaštitne ograde kako premium ne bi postao zadani

Jednom kad timovi otkriju bržu razinu, mogli bi je pretjerano koristiti. Stavite ograničenja u gateway prije širokog predstavljanja.

• Premijski proračun po stanarima: Čvrsti mjesečni i dnevni limiti.
• Odobrenje tijeka rada: Premium dopušten samo za imenovane tijekove rada.
• Ograničenje udjela prometa: Na primjer, ne više od 10% sinkronih zahtjeva stanara smije koristiti interactive_fast bez odobrenja.
• Upozorenje sa standardnog na premium: Upozorenje kada se nadogradi tijek rada koji inače koristi standard.
• Upozorenje o premium stopi sagorijevanja: Upozorenje kada predviđena potrošnja premaši odobrenu omotnicu.
• Automatski istek: Privremena hitna nadjačavanja trebala bi isteći bez ručnog čišćenja.
• Provjere prihvatljivosti paketa: blokirajte skupne poslove sa sinkronih premium razina kada zadovolje kriterije paketa.

Zaštitne ograde trebaju biti okretne. Tijekom incidenta, ovlašteni operater će možda morati odobriti privremeno nadjačavanje premije. To nadjačavanje mora imati razlog, odobravatelja, proračun, vrijeme isteka i revizijski zapis.

Slijed implementacije

Sigurno uvođenje ne počinje svugdje uključenim premium usmjeravanjem. Počnite s mjerenjem.

1. Dodajte klasifikaciju razine sjene

Klasificirajte svaki zahtjev u predloženu razinu pristupnika, ali još nemojte mijenjati usmjeravanje. Zabilježite predloženu razinu uz postojeće metapodatke o kašnjenju, cijeni i tijeku rada. Ovo otkriva koliko bi se prometa prebacilo na premium, serijski ili rezervirani kapacitet ako bi se pravila provodila.

2. Napravite matricu mogućnosti

Navedite mehanizme pružatelja usluga, podržane modele, regije, ograničenja, polja za izvješćivanje i poznato ponašanje prelaska na stariju verziju. Tretirajte nepoznato ponašanje na nižu verziju kao rizik dok se ne testira.

3. Nametnite dopuštenja stanara u načinu rada na suho

Zabilježite hoće li svaki zahtjev biti dopušten, smanjen, stavljen u red čekanja ili odbijen. Podijelite rezultate s vlasnicima proizvoda prije provedbe.

4. Omogućite jednu razinu za jednu skupinu

Odaberite uzak tijek rada, kao što je staza odgovora podrške uživo ili noćni posao sažimanja. Omogućite relevantnu razinu pristupnika za malu skupinu stanara. Mjerite latenciju p50, latenciju p95, trošak, stopu prelaska na stariju verziju, stopu pogreške i poslovne metrike okrenute korisniku, ako su dostupne.

5. Proširi samo kada podaci to podržavaju

Ako premium razina poboljšava kašnjenje, ali ne i rezultate proizvoda, ograničite je. Ako skupna obrada smanjuje troškove bez štete na ponašanje proizvoda, proširite je. Ako je osigurani kapacitet neiskorišten, ponovno pregledajte obvezu ili usmjerite više predvidljivog prometa u njega.

Kompromisi koje treba učiniti eksplicitnim

• Premijum razine niske latencije mogu poboljšati odziv, ali mogu dijeliti ograničenja brzine ili pokretati ograničenja rampe. Oni nisu zamjena za oblikovanje ograničenja brzine.
• Omogućeni kapacitet poboljšava predvidljivost, ali može uzalud trošiti novac kada je iskorištenost niska. Standardni ili skupni kapacitet može biti bolji za intenzivan promet ili promet tolerantan na kašnjenje.
• Skupna obrada može smanjiti trošak tokena, ali mijenja ponašanje proizvoda jer su odgovori asinkroni i mogu stići puno kasnije.
• Nazivi slojeva neutralni prema pružateljima usluga pojednostavljuju kod aplikacije, ali pristupnik mora održavati ažurnu matricu mogućnosti jer pružatelji usluga koriste različite nazive, ograničenja, linije naplate i ponašanje na niže verzije.
• Automatsko vraćanje na stariju verziju poboljšava dostupnost, ali može zamagliti SLO i očekivanja naplate osim ako pristupnik ne zabilježi stvarnu korištenu razinu.
• Stroge kontrole zakupaca sprječavaju iznenadnu potrošnju, ali pretjerano krute politike mogu blokirati hitne proizvodne tijekove osim ako ne postoji kontrolirani put nadjačavanja.

Predviđanje: razina usluge postat će prvorazredna dimenzija usmjeravanja

Predviđanje: Kako API-ji modela sazrijevaju, razina usluge postat će jednako važna za AI usmjeravanje kao izbor modela, regija i prozor konteksta. Timovi se neće pitati samo "koji bi model trebao odgovoriti na ovo?" Pitat će "koji model, pod kojom klasom kapaciteta, za koji proračun stanara, s kojom politikom niže razine?"

Preporuka: Sada dizajnirajte knjigu pristupnika i model pravila tako da se nove klase kapaciteta pružatelja mogu dodati bez mijenjanja koda aplikacije. Čak i ako počnete samo sa standardnim i serijskim, od početka koristite polja kao što su requested_gateway_tier, selected_provider_tier i tier_outcome.

Kontrolni popis za rad

• Definirajte najviše pet razina pristupnika neutralnih prema pružatelju usluga.
• Zahtijevati da svaki API ključ deklarira koje razine i tijekove rada može koristiti.
• Izradite matricu mogućnosti pružatelja usluga za premium, standardno, osigurano, serijsko i prelijevo ponašanje.
• Zabilježite traženu razinu, odabranu razinu, ishod snižavanja ili prelijevanja, kašnjenje, upotrebu i podmireni trošak.
• Zadani novi ključevi za standardne ili pozadinske razine.
• Dodajte premium proračune, ograničenja udjela prometa i upozorenja.
• Učinite eksplicitnim ponašanje prema tijeku rada.
• Počnite s metrikom u sjeni prije provedbe.
• Prvo uvedite premium ili osigurani kapacitet za malu skupinu.
• Proširite samo kada latencija, pouzdanost ili poslovna metrika opravdavaju trošak.

Zaključak

Usmjeravanje na razini usluge pripada pristupniku AI API-ja jer je to međusektorska politička odluka. Utječe na kašnjenje, troškove, kvote, dozvole stanara, fakture i operativna očekivanja. Aplikacijski timovi ne bi trebali kodirati nazive razina ili klase implementacije specifične za pružatelja usluga samo da bi izrazili hitnost radnog opterećenja.

Praktični pristupnik izlaže neutralne razine kao što su interactive_fast, interactive_standard, reserved_capacity i background_discount. Preslikava te razine u mehanizme specifične za pružatelja usluga, provodi dopuštenja stanara, bilježi stvarni ishod i čini premium kapacitet namjernom iznimkom, a ne zadanim putem.

Povezano čitanje

• oblikovanje ograničenja stope prije pružatelja 429
• trajni pristupni obrazac za asinkrone skupne poslove
• glavna knjiga naplate za ponudu, rezervu, poravnanje i usklađivanje