Pakalpojuma līmeņa maršrutēšana AI API vārtejā: ātrs, standarta, nodrošināts un pakešs bez cietā kodēšanas nodrošinātājiem

Šis līmeņu saraksts ir apzināti mazs. Ja izveidosit divdesmit līmeņus, izstrādātāji apies sistēmu. Vārteja joprojām var saistīt vienu neitrālu līmeni ar vairākiem pakalpojumu sniedzēja specifiskiem mehānismiem iekšēji.

Atdaliet pieprasīto līmeni no atlasītā līmeņa

Zvanītājam ir jānosūta pieprasītais līmenis, bet vārtejai ir jāreģistrē gan pieprasītais līmenis, gan faktiski atlasītais līmenis. Tie ne vienmēr ir vienādi.

Pieprasījuma metadatu piemērs:

{
  "modelis": "support-chat-default",
  "Ziņojumi": [...],
  "metadati": {
    "darbplūsma": "customer_support_reply",
    "īrnieka_id": "īrnieks_123",
    "requested_gateway_tier": "interactive_fast",
    "end_user_id": "u_789"
  }
}

Nosūtīšanas ieraksta piemērs:

{
  "request_id": "req_abc",
  "īrnieka_id": "īrnieks_123",
  "api_key_id": "key_live_456",
  "darbplūsma": "customer_support_reply",
  "model_alias": "support-chat-default",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "ātrs",
  "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"
}

Ja maksas pieprasījums tiek nosūtīts standarta apstrādei rampas ierobežojumu vai nomnieka budžeta noteikumu dēļ, tam ir jābūt redzamam:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standarta",
  "tier_outcome": "pazemināts",
  "downgrade_reason": "rentant_premium_budget_exhausted"
}

Šī atšķirība novērš maldinošu analīzi. Ja informācijas paneļos tiek rādīts tikai tas, ko pieprasījis zvanītājs, finansēs tiks rādīts augstākās kvalitātes nolūks, bet ne augstākās kvalitātes izpilde. Ja informācijas paneļos tiek rādīts tikai augšējais rezultāts, produktu komandas nezinās, kad viņu latentuma jutīgajai darbplūsmai tika liegta papildu jauda.

Pirms maršrutēšanas izveidojiet iespēju matricu

Pakalpojuma līmeņa maršrutētājam ir nepieciešama iespēju matrica. Matricai ir jāatbild: kādi jaudas mehānismi ir pieejami konkrētajam modelim, reģionam, nomniekam un darbplūsmai?

Minimālais lauks:

• nodrošinātājs
• model_or_deployment
• reģioni
• supports_Sync
• supports_batch
• atbalsta_premium_līmenis
• atbalsta_provisioned_capacity
• supports_spillover
• provider_tier_values
• norēķinu_rindas_vienumi
• known_downgrade_behavior
• tenant_allowlist

Vienkāršots piemērs:

gateway_tier_map:
  interactive_fast:
    vēlams:
      - sniedzējs: openai
        request_params:
          servisa līmenis: ātri
      - nodrošinātājs: antropisks
        request_params:
          pakalpojumu_līmenis: prioritāte
    atkāpšanās:
      - vārtejas_līmenis: interaktīvais_standarts
        allow_when: policy.allows_standard_downgrade
  background_discount:
    vēlams:
      - nodrošinātājs: antropisks
        režīms: partija
      - nodrošinātājs: dvīņi
        režīms: partija
    atkāpšanās:
      - rinda: aizkavēts_atkārtots mēģinājums
        atļauts_kad: patiess
  reserved_capacity:
    vēlams:
      - nodrošinātājs: azure_openai
        izvietošanas_klase: nodrošināts
    atkāpšanās:
      - nodrošinātājs: azure_openai
        izvietošanas_klase: standarts
        allow_when: policy.allows_spillover

Šai matricai ir jābūt konfigurācijai, nevis izkliedētam kodam. Pakalpojumu sniedzēja nosaukumu izmaiņas, reģionālā pieejamība un norēķinu kārtība laika gaitā mainīsies. Vārtejas politikas atjaunināšana ir drošāka nekā katras lietojumprogrammas, kas izsauc API, atkārtota izvietošana.

Pirms jaudas izvēles klasificējiet darba slodzes

Sarežģītākā daļa nav pakalpojumu sniedzēja kartēšana. Tā izlemj, kuri pieprasījumi ir pelnījuši kādu līmeni.

Labi kandidāti interactive_fast

• Balss palīgi, ja kavēšanās pārtrauc sarunu.
• Klientu tērzēšana par augstvērtīgiem reklāmguvumu vai saglabāšanas ceļiem.
• cilvēka darbības, kurās aģents aktīvi gaida.
• Ražošanas incidenti, kuros latentums tieši ietekmē mazināšanu.

Labi kandidāti interactive_standard

• Iekšējie kopiloti.
• Atbalstiet uzmetumu, kur cilvēks var paciest normālu reakcijas laiku.
• Produkta funkcijas, kurām reakcijas laikam ir nozīme, taču tas nav kritisks.

Labi kandidāti background_discount

• Nakts kopsavilkums.
• Liels dokumentu bagātinājums.
• Novērtējumi bezsaistē.
• Lielapjoma iegulšana tiek atsvaidzināta.
• Analytics marķēšana un pārskatu ģenerēšana.

Labi kandidāti uz rezervēto_kapacitāti

• Pastāvīga liela apjoma ražošanas darba slodze.
• Līgumā noteiktas klientu darba slodzes ar paredzamām caurlaidspējas saistībām.
• Satiksme, kas nevar paciest trokšņainas kaimiņu atšķirības un ir pietiekami izmantota, lai attaisnotu atvēlēto jaudu.

Vienkāršs politikas noteikums ir šāds: neļaujiet zvanītājiem izvēlēties papildu jaudu tikai tāpēc, ka viņi dod priekšroku ātrumam. Nepieciešama deklarēta darbplūsma, nomnieka atļauja un budžeta aploksne.

Ieviesiet nomnieka un API atslēgas atļaujas

Katram nomniekam un API atslēgai ir jābūt iestatītam atļautajam līmenim. Jaunajām atslēgām pēc noklusējuma ir jābūt standarta un fona līmeņiem, nevis premium līmeņiem.

Īrnieku politikas piemērs:

{
  "īrnieka_id": "īrnieks_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "fona_atlaide"
  ],
  "premium_tier": {
    "iespējots": nepatiess,
    "monthly_budget_usd": "0,00",
    "approval_required": taisnība
  },
  "rezervēta_kapacitāte": {
    "iespējots": patiess,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": patiess,
    "spillover_monthly_budget_usd": "500,00"
  }
}

Atslēgas līmeņa ignorēšanas piemērs:

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

Atslēgas līmeņa politika novērš nejaušu izvēršanu. Izstrādātājs nevar paņemt balss datplūsmai paredzēto atslēgu un izmantot to lielapjoma kopsavilkuma skriptam, ja vien nav atļauta arī darbplūsma.

Tieši noformējiet lejupslīdes un pārnešanas darbību

Pazemināta versija ir lēmums par produktu, ne tikai lēmums par infrastruktūru. Ja premium vai nodrošinātā jauda nav pieejama, vārtejai ir jāizvēlas viens no četriem ceļiem:

• Turpināt uz standarta: noderīga, ja pieejamība ir svarīgāka par latentuma konsekvenci.
• Rinda: noderīga fona darbiem un pakešu darba slodzēm.
• Ātri neizdodas: noder, ja lēna atbilde būtu sliktāka nekā bez atbildes, piemēram, saspringtas reāllaika cilpas.
• Lūdziet zvanītājam mēģināt vēlreiz: noder, ja klients var droši mēģināt vēlreiz, izmantojot atkāpšanos un saglabātu idempotences atslēgu.

Politikas piemērs:

downgrade_policy:
  voice_control_loop:
    pieprasītais_līmenis: interactive_fast
    if_fast_navailable: fail_fast
    error_code: tier_capacity_navailable
  customer_support_reply:
    pieprasītais_līmenis: interactive_fast
    if_fast_unavailable: turpināt_standarta
    record_outcome: pazemināta
  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: rinda
    max_queue_delay_hours: 24
  contracted_api_customer:
    pieprasītais_līmenis: rezervētā_kapacitāte
    if_reserved_exhausted: spillover_to_standard
    request_spillover_budget: true

Neslēpiet pārnešanu. Spillover var uzlabot pieejamību, taču tas maina izmaksas un SLO interpretāciju. Rēķinos un analīzēs ir jāparāda rezervētās jaudas pieprasījums, papildu notikums, faktiski izmantotā standarta jauda un iemesls.

Savienojiet pakalpojumu līmeņa maršrutēšanu ar norēķiniem

Vārteja nevar kontrolēt papildu izdevumus, ja līmeņa izvēle nav daļa no virsgrāmatas. Saglabājiet šos laukus katram pieprasījumam vai darbam:

• Pieprasītais vārtejas līmenis.
• Atlasītais nodrošinātāja līmenis vai jaudas klase.
• Līmeņa iznākums: atlasīts, pazemināts, jaunināts, rindā, spillover, noraidīts.
• Iznākuma iemesls.
• Īrnieka, API atslēgas, lietotāja un darbplūsmas identifikatori.
• Modeļa aizstājvārds un augšējais modelis vai izvietošana.
• Paredzamās izmaksas pirms nosūtīšanas.
• Norēķinātā maksa pēc pakalpojumu sniedzēja lietošanas ir zināma.
• Sinhrono pieprasījumu latentuma un atkārtoto mēģinājumu skaits.
• Asinhrono darbu paketes iesniegšanas laiks, pabeigšanas laiks un rezultātu saņemšanas statuss.

Izmantojot šos laukus, vārteja var atbildēt uz jautājumiem, ko uzdos finanses un inženierzinātnes.

• Kuri nomnieki šonedēļ izmantoja augstākās kvalitātes jaudu?
• Kuras darbplūsmas izraisīja lielākos papildu izdevumus?
• Cik bieži premium pieprasījumi tika pazemināti uz standarta?
• Vai interactive_fast pietiekami uzlaboja p95 latentumu, lai attaisnotu piemaksu?
• Cik daudz tika ietaupīta fona pakešu apstrāde salīdzinājumā ar sinhrono standarta apstrādi?
• Cik lielu standarta izplatību radīja nodrošinātā jauda?

Svarīgs ieteikums: izrakstiet faktisko izmantoto līmeni, vienlaikus parādot arī pieprasīto līmeni darbības kontekstam. Pretējā gadījumā īrniekus pārsteigs izmaksas vai maldinās par pakalpojumu kvalitāti.

Pievienojiet aizsargmargas, lai premium nekļūtu par noklusējuma vērtību

Tiklīdz komandas atklāj ātrāku līmeni, tās var to pārmērīgi izmantot. Nosakiet ierobežojumus vārtejai pirms plašas izlaišanas.

• Nomnieka prēmiju budžets: stingri mēneša un dienas griesti.
• Darbplūsmas apstiprināšana: Premium ir atļauta tikai nosauktām darbplūsmām.
• Datplūsmas daļas ierobežojums: piemēram, ne vairāk kā 10% nomnieka sinhrono pieprasījumu var izmantot parametru interactive_fast bez apstiprinājuma.
• Brīdinājums no standarta uz augstākās klases: brīdinājums, kad tiek jaunināta darbplūsma, kas parasti izmanto standarta.
• Brīdinājums par papildu degšanas ātrumu: brīdinājums, ja plānotie tēriņi pārsniedz apstiprināto aploksni.
• Automātiska derīguma termiņa beigas: pagaidu ārkārtas ignorēšanas derīguma termiņš beigsies bez manuālas tīrīšanas.
• Pakešu piemērotības pārbaudes: bloķējiet lielapjoma darbus no sinhroniem premium līmeņiem, ja tie atbilst pakešu kritērijiem.

Aizsargmargām jābūt atgriezeniskām. Negadījuma laikā pilnvarotajam operatoram, iespējams, būs jāpiešķir pagaidu prēmijas ignorēšana. Šai ignorēšanai ir jābūt iemeslam, apstiprinātājam, budžetam, derīguma termiņam un revīzijas ierakstam.

Ieviešanas secība

Droša izlaišana nesākas, visur ieslēdzot augstākās kvalitātes maršrutēšanu. Sāciet ar mērīšanu.

1. Pievienojiet ēnu līmeņa klasifikāciju

Klasificējiet katru pieprasījumu piedāvātajā vārtejas līmenī, taču vēl nemainiet maršrutēšanu. Ierakstiet piedāvāto līmeni blakus esošajiem latentuma, izmaksu un darbplūsmas metadatiem. Tas atklāj, cik daudz trafika tiktu pārvietota uz maksas, pakešu vai rezervētu jaudu, ja politika tiktu ieviesta.

2. Izveidojiet iespēju matricu

Saraksta nodrošinātāja mehānismi, atbalstītie modeļi, reģioni, ierobežojumi, atskaites lauki un zināmās pazemināšanas darbības. Uztveriet nezināmu pazemināšanas uzvedību kā risku līdz pārbaudei.

3. Piespiediet nomnieka atļaujas sausās darbības režīmā

Reģistrējiet, vai katrs pieprasījums tiks atļauts, pazemināts, ievietots rindā vai noraidīts. Pirms ieviešanas kopīgojiet rezultātus ar produktu īpašniekiem.

4. Iespējot vienu līmeni vienai kohortai

Izvēlieties šauru darbplūsmu, piemēram, tiešsaistes atbalsta atbildes ceļu vai ikvakara kopsavilkuma darbu. Iespējojiet attiecīgo vārtejas līmeni nelielai nomnieku grupai. Izmēriet p50 latentumu, p95 latentumu, izmaksas, pazemināšanas līmeni, kļūdu biežumu un lietotāju biznesa rādītājus, ja tie ir pieejami.

5. Izvērst tikai tad, ja dati to atbalsta

Ja premium līmenis uzlabo latentumu, bet ne produkta rezultātus, ierobežojiet to. Ja pakešu apstrāde samazina izmaksas, nekaitējot produkta darbībai, paplašiniet to. Ja nodrošinātā jauda ir dīkstāvē, atkārtoti pārbaudiet saistības vai novirziet tai paredzamāku trafiku.

Tiek izteikti kompromisi

• Premium zema latentuma līmeņi var uzlabot atsaucību, taču tie var koplietot ātruma ierobežojumus vai izraisīt rampas ierobežojumus. Tie neaizstāj likmes ierobežojumu noteikšanu.
• Paredzēta jauda uzlabo paredzamību, taču tā var izšķiest naudu, ja noslodze ir zema. Standarta vai pakešu ietilpība var būt labāka straujai vai latentuma izturīgai datplūsmai.
• Pakešapstrāde var samazināt marķiera izmaksas, taču tā maina produkta darbību, jo atbildes ir asinhronas un var saņemt daudz vēlāk.
• Pakalpojumu sniedzējam neitrāli līmeņu nosaukumi vienkāršo lietojumprogrammas kodu, taču vārtejai ir jāuztur atjaunināta iespēju matrica, jo pakalpojumu sniedzēji izmanto dažādus nosaukumus, ierobežojumus, norēķinu rindas un pazemināšanas darbību.
• Automātiska pazemināšana uzlabo pieejamību, taču tā var aizmiglot SLO un rēķinu aprēķinus, ja vien vārteja nereģistrē faktiski izmantoto līmeni.
• Stingra nomnieka kontrole novērš negaidītus tēriņus, taču pārāk stingras politikas var bloķēt steidzamas ražošanas darbplūsmas, ja vien nav kontrolēta ignorēšanas ceļa.

Prognoze: pakalpojuma līmenis kļūs par pirmās klases maršrutēšanas dimensiju

Paredzēšana: modeļu API nobriedus, pakalpojumu līmenis AI maršrutēšanai kļūs tikpat svarīgs kā modeļa izvēle, reģions un konteksta logs. Komandas nejautās tikai “kuram modelim vajadzētu atbildēt uz šo?” Viņi jautās: “kurš modelis, saskaņā ar kuru jaudas klasi, kādam nomnieka budžetam, ar kādu pazemināšanas politiku?”

Ieteikums: jau tagad izveidojiet vārtejas virsgrāmatu un politikas modeli, lai varētu pievienot jaunas pakalpojumu sniedzēja jaudas klases, nemainot lietojumprogrammas kodu. Pat ja sākat tikai ar standartu un pakešu, no sākuma izmantojiet tādus laukus kā requested_gateway_tier, selected_provider_tier un tier_outcome.

Pārbaudāms kontrolsaraksts

• Definējiet ne vairāk kā piecus pakalpojumu sniedzējam neitrālus vārtejas līmeņus.
• Pieprasīt, lai katra API atslēga deklarētu, kurus līmeņus un darbplūsmas tā var izmantot.
• Izveidojiet nodrošinātāja iespēju matricu, lai nodrošinātu augstākās kvalitātes, standarta, nodrošināto, pakešu un papildu darbību.
• Ierakstiet pieprasīto līmeni, atlasīto līmeni, pazemināšanas vai papildu iznākumu, latentumu, lietojumu un nokārtotās izmaksas.
• Noklusējuma jaunās atslēgas standarta vai fona līmeņiem.
• Pievienojiet premium budžetus, datplūsmas daļas ierobežojumus un brīdinājumus.
• Norādiet uz zemāku versiju katrā darbplūsmā.
• Pirms izpildes sāciet ar ēnu metriku.
• Vispirms izlaidiet maksas vai nodrošināto jaudu nelielai grupai.
• Izvērst tikai tad, ja latentums, uzticamība vai uzņēmējdarbības rādītāji attaisno izmaksas.

Secinājums

Pakalpojuma līmeņa maršrutēšana ietilpst AI API vārtejā, jo tas ir transversāls politikas lēmums. Tas ietekmē latentumu, izmaksas, kvotas, nomnieka atļaujas, rēķinus un darbības cerības. Lietojumprogrammu komandām nevajadzētu kodēt pakalpojumu sniedzējam specifiskus līmeņu nosaukumus vai izvietošanas klases, lai tikai izteiktu darba slodzes steidzamību.

Praktiska vārteja atklāj neitrālus līmeņus, piemēram, interactive_fast, interactive_standard, rezervēta_kapacitāte un background_discount. Tas kartē šos līmeņus ar pakalpojumu sniedzēja specifiskiem mehānismiem, ievieš nomnieka atļaujas, reģistrē faktisko iznākumu un padara premium ietilpību par apzinātu izņēmumu, nevis par noklusējuma ceļu.

Saistīta informācija

• likmes limita noteikšana pirms pakalpojumu sniedzēja 429s
• unified-batch-away/ vārtejas modelis asinhroniem pakešu darbiem
• norēķinu virsgrāmata piedāvājumam, rezervēšanai, norēķiniem un saskaņošanai