Kā izveidot pakalpojumu sniedzējam neitrālu likmes ierobežojumu starpnieku vairāku modeļu LLM API

Ja vairākas komandas izmanto vairākus LLM pakalpojumu sniedzējus, tarifu ierobežošana vairs nav pakalpojumu sniedzēja integrācijas detaļa. Tā kļūst par dalītas jaudas problēmu. Viens pakalpojumu sniedzējs var ierobežot pieprasījumus un ievades pilnvaras, cits var atdalīt ievades un izvades pilnvaras, bet trešais var piemērot kvotas projekta līmenī vai mainīgā tēriņu logā. Atkārtota mēģinājuma cilpa katrā SDK nevar koordinēt šos ierobežojumus starp nomniekiem, lietojumprogrammām, partneru atslēgām un modeļu maršrutiem.

Praktisks risinājums ir centrālais tarifu limita brokeris vārtejā. Brokeris novērtē pieprasījumu, rezervē jaudu pirms nosūtīšanas, sastāda rindas vai noraida darbu saskaņā ar politiku un saskaņo rezervāciju ar faktisko izmantošanu pēc pabeigšanas. Pakalpojumu sniedzēju atbildes pēc tam uzlabo brokera skatījumu uz pieejamo jaudu, nevis izraisa neatkarīgas atkārtotas mēģinājuma vētras.

Šī arhitektūra ir noderīga jebkurai uzņēmuma LLM API, kam nepieciešama paredzama caurlaidspēja starp iekšējām komandām, ražošanas lietojumprogrammām, automatizācijas aģentiem vai ārējiem partneriem.

Kāpēc pakalpojumu sniedzēja tarifu ierobežojumus nevar samazināt līdz pieprasījumiem minūtē

Fakts: Pakalpojumu sniedzēju kvotas izmanto dažādas dimensijas un darbības jomas. Parastie rādītāji ietver pieprasījumus minūtē, ievades pilnvaras minūtē, izvades pilnvaras minūtē, kopējo marķieru skaitu, pieprasījumus dienā, vienlaicīgumu, tēriņu logus un paātrinājuma vai ātruma ierobežojumus. Viens un tas pats pakalpojumu sniedzējs var noteikt dažādus ierobežojumus organizācijai, projektam, darbvietai, modelim vai API produktam.

Piemēram, pakalpojumu sniedzēja dokumentācijā ir aprakstītas šādas kombinācijas:

• Pieprasījumu un pilnvaru ierobežojumi ar atlikušo jaudu un atiestatīšanas informāciju atbilžu galvenēs.
• Atsevišķi ievades pilnvaru un izvades pilnvaru ierobežojumi ziņojumu API.
• Projekta līmeņa kvotas, nevis kvotas, kas pievienotas atsevišķām API atslēgām.
• Dienas pieprasījumu ierobežojumi, kas tiek atiestatīti pakalpojumu sniedzēja noteiktā laikā.
• Uz tēriņiem balstīti mainīgi logi, kas var noraidīt datplūsmu pat tad, ja pieprasījumu un pilnvaru likmes šķiet pieņemamas.
• Paātrinājuma ierobežojumi, kas reaģē uz strauju datplūsmas pieaugumu, pat ja līdzsvara stāvokļa lietojums ir mazāks par publicēto kvotu.

Vārteja, kas saglabā tikai vienu numuru ar nosaukumu provider RPM, galu galā pārsniegs trafiku vienā kategorijā vai nepietiekami izmantos jaudu citā. Tas arī nevar izskaidrot, vai noraidīšanas iemesls ir nomnieka politika, nodrošinātāja projekta kvota, dienas ierobežojums vai pārslodzes reakcija.

Atsauces arhitektūra likmes ierobežojumu brokerim

Novietojiet starpnieku pieprasījuma ceļā pirms nodrošinātāja adaptera. Katram pieprasījumam ir jāiet cauri vienai un tai pašai rezervācijas plūsmai neatkarīgi no tā, vai tas saņemts, izmantojot SDK, iekšējo pakalpojumu, automatizācijas aģentu vai partnera API atslēgu.

1. Normalizējiet identitāti. Atrisiniet organizāciju, nomnieku, komandu, lietojumprogrammu, vidi, partneri, API atslēgu, modeļa maršrutu un darba slodzes klasi.
2. Aprēķiniet pieprasījumu. Aprēķiniet paredzamos ievades marķierus, maksimālos izvades marķierus, aptuvenos tēriņus un visas vienlaicīgas izmaksas.
3. Novērtējiet politiku. Pārbaudiet nomnieku budžetus, rindu termiņus, maršruta piemērotību, prioritāti un rezerves noteikumus.
4. Rezerves jauda. Atomiski rezervējiet jaudu attiecīgajās iekšējās un pakalpojumu sniedzējam vērstajās grupās.
5. Nosūtīšana. Nosūtiet pieprasījumu tikai pēc veiksmīgas rezervācijas.
6. Saskaņot. Aizstājiet aprēķinus ar faktisko lietojumu, atbrīvojiet neizmantotās rezervācijas un ierakstiet nodrošinātāja galvenes un atbilžu klasifikāciju.
7. Izlemiet par nākamo darbību. Atgrieziet rezultātu, ievietojiet darbu rindā, mēģiniet vēlreiz centralizēti, atkāpieties vai noraidiet to saskaņā ar darba slodzes līgumu.

Rezervācijas pakalpojumam ir jābūt horizontāli mērogojamam, taču katram pieprasījumam tā lēmumam ir jābūt kodolīgam. Sadalīts skaitītājs, kas ļauj diviem darbiniekiem novērot to pašu atlikušo jaudu, var atkārtoti izveidot pakalpojumu sniedzēja 429 problēmu vārtejā.

Izmantojiet kanonisko kvotas modeli, neslēpjot nodrošinātāja atšķirības

Definējiet kanonisku modeli, kas var atspoguļot pakalpojumu sniedzējam raksturīgus ierobežojumus, nevis piespiest katru pakalpojumu sniedzēju izmantot vienu abstrakciju.

Attēlot katru ierobežojumu kā kopu ar tvērumu, ietilpību, uzpildes vai atiestatīšanas kārtulu, vienību un avotu. Pakalpojumu sniedzēja projektu segmentā var būt pieprasījumi un ievades pilnvaras. Darbvietas segmentā var būt izvades marķieri. Iekšējā partnera politika var pievienot vienlaicības un tēriņu ierobežojumus. Lēmums par uzņemšanu ir veiksmīgs tikai tad, ja visas nepieciešamās rezervācijas ir veiksmīgas.

Neuztveriet pakalpojumu sniedzēja galvenes kā pilnīgu patiesības avotu. Izmantojiet tos, lai labotu brokera aplēses, taču saglabājiet konfigurētu modeli ierobežojumiem, kas netiek atklāti katrā atbildē. Galvenes nosaukumi, pieejamība un atiestatīšanas semantika atšķiras atkarībā no pakalpojumu sniedzēja un maršruta.

Rezervēt marķierus pirms nosūtīšanas un pēc tam saskaņot tos

Marķiera rezervēšana ir vissvarīgākā atšķirība starp starpnieku un atkārtotā mēģinājuma iesaiņojumu. Pirms pieprasījuma nosūtīšanas brokerim ir nepieciešams pieprasījuma aprēķins.

Ievades marķieriem veiciet aprēķinus no serializētajiem ziņojumiem, rīku definīcijām, strukturētās izvades shēmas un jebkura izgūtā konteksta. Izvades marķieriem izmantojiet pieprasījuma maksimumu, ja tas ir pieejams, vai modelim un darba slodzei raksturīgu aprēķinu, ja klients to nenodrošina. Saglabājiet tāmi pievienotai rezervācijai, lai vēlāk to varētu salīdzināt ar faktisko lietojumu.

Vienkāršā rezervācijas ierakstā var būt:

• Unikāls pieprasījuma un rezervācijas ID.
• Īrnieks, lietojumprogramma, API atslēga, maršruts un darba slodzes klase.
• Aprēķinātie ievades marķieri, izvades marķieri, kopējie marķieri un tēriņi.
• Katrs rezervācijas maksājums.
• Izveides laiks, derīguma termiņš, rindas termiņš un idempotences atslēga.
• Pēdējais faktiskais lietojums un summa, kas atbrīvota vai iekasēta saskaņošanas laikā.

Konservatīvie aprēķini samazina pakalpojumu sniedzēja 429 atbildes, taču var samazināt jaudu. Izmēriet aplēses kļūdu pēc modeļa, maršruta, uzvedņu saimes, konteksta garuma un strukturētās izvades režīma. Pēc tam pielāgojiet aprēķinus, izmantojot ierobežotas korekcijas, nevis ļaujiet vienam neparastam pieprasījumam izkropļot visu modeli.

Straumēšanai ir nepieciešama īpaša politika. Varat rezervēt maksimālo izvades apjomu un atbrīvot neizmantoto daļu, kad straume beidzas, vai rezervēt izvades jaudu ar mazākiem soļiem, tiklīdz tiek saņemti marķieri. Pirmo pieeju ir vieglāk pamatot; otrais var uzlabot izmantošanu, taču tai ir nepieciešama uzticama atcelšana, taimauts un atvienošanas apstrāde.

Ieviest kvotas hierarhiski

Kapacitāte ir jāpārbauda no šaurākās politikas līdz plašākajam koplietotajam resursam. Tipiska hierarhija ir:

1. API atslēga vai pakalpojuma identitāte.
2. Lietojumprogramma un vide.
3. Komanda vai klienta nomnieks.
4. Partnera vai tālākpārdevēja konts.
5. Nodrošinātāja darbvieta vai apakškonts.
6. Pakalpojumu sniedzēja projekts vai organizācija.
7. Modelis un maršruts.

Tāpēc pieprasījumam no partnera lietojumprogrammas var būt nepieciešamas četras veiksmīgas rezervācijas: partnera vienlaicības politika, klienta nomnieka pilnvaras budžets, vārtejas maršruta piešķiršana un nodrošinātāja projekta pieejamā kvota. Ja kāda rezervācija neizdodas, atlaidiet jau iegūtās rezervācijas un piemērojiet neveiksmīgās grupas lēmumu.

Godīguma labad izmantojiet svērto godīgo rindu vai deficīta aprēķinu, nevis ļaujiet tam darbiniekam, kurš ierodas pirmais, izmantot koplietojamo baseinu. Piešķiriet lielākas nozīmes ražošanas datplūsmai un zemākas nozīmes fona darbiem, vienlaikus saglabājot katra nomnieka sērijas kredītus. Cieto sadalīšanu ir vieglāk izskaidrot, taču tā var atstāt jaudu dīkstāvē, kad viens nomnieks ir kluss. Svērtā koplietošana parasti efektīvāk izmanto jaudu, ja trokšņainajiem īrniekiem ir ierobežoti sērijveida datu pārraides ierobežojumi.

Izstrādājiet rindas ap darba slodzes līgumiem

Rinda automātiski nav uzticamības līdzeklis. Tas var pārvērst redzamu 429 par neredzamu desmit minūšu kavēšanos. Katrai rindas klasei ir nepieciešams termiņš, atcelšanas darbība, maksimālais dziļums un pārslodzes darbība.

• Interaktīvs: Īss termiņš, neliela rinda, paredzama noraidīšana vai modeļa pasliktināšanās, ja jauda nav pieejama.
• Ražošanas fons: Garāks termiņš, ilgstoša rinda, idempotences atslēga un kontrolēts atkārtotā mēģinājuma budžets.
• Partneris: Nomniekam noteiktas kvotas, publicēti atbilžu metadati un nav piekļuves cita nomnieka rindas stāvoklim.
• Batchable: Aizkavēta izpilde, lielāka rinda un izvēles maršrutēšana uz pakalpojumu sniedzēja grupu API, ja to atļauj darba slodze.

Iekļaušanai rindā ir jāatgriež skaidrs lēmums. Atkarībā no API līguma, parādiet 429 vai vārtejai raksturīgu pārslodzes atbildi ar atkārtotas mēģinājuma vērtību, rindas identifikatoru un iemesla kodu. Nesoliet pabeigšanas laiku, ja vien sistēma nevar izpildīt šo solījumu.

Pakešapstrāde var noņemt neinteraktīvu darbu no sinhronās jaudas, taču tā maina rezultātu laiku, atkārtota mēģinājuma darbību, atcelšanu un saskaņošanu. Uztveriet to kā atsevišķu izpildes ceļu, nevis vienkārši novietojiet sinhronus pieprasījumus ļoti garā rindā. Fona darba slodzei salīdziniet darbības kompromisus ar AI API izmaksu kontroles politikām un esošajām pakešu operācijām.

Centralizēt atkārtotu mēģinājumu un pārslodzes apstrādi

Fakts: Pagaidu ātruma ierobežojuma atbildēs parasti tiek izmantots HTTP 429, savukārt pakalpojumu sniedzēja pārslodzes apstākļos var izmantot 503 vai pakalpojumu sniedzējam raksturīgu kļūdas kodu. Daži pakalpojumu sniedzēji atgriež galveni Retry-After, un pakalpojumu sniedzēja dokumentācijā ir ieteikts to ievērot, kad tas ir pieejams. Ātra satiksmes uzbrauktuve var izraisīt arī paātrinājumu vai palēnināšanos bez parastas kausa izsmelšanas.

Ieteikums: Uztveriet Retry-After kā apakšējo robežu, nevis kā neobligātu ieteikumu. Apturiet ietekmēto pakalpojumu sniedzēja darbības jomu līdz šim brīdim, pievienojiet ierobežotu nervozitāti, lai novērstu sinhronizētu pamodināšanu, un ļaujiet brokerim izlemt, kuri rindā ievietotie pieprasījumi var izmantot atgūto jaudu.

Ja Retry-After nav vai tas nav derīgs, izmantojiet ierobežotu eksponenciālo atkāpšanos ar nervozitāti. Saglabājiet atkārtotā mēģinājuma budžetu brokerī, nevis atsevišķi katrā SDK un nodrošinātāja adapterī. Pretējā gadījumā viens loģisks pieprasījums var radīt vārtejas atkārtotu mēģinājumu, SDK atkārtotu mēģinājumu, HTTP klienta atkārtotu mēģinājumu un nodrošinātāja puses atkārtotu atskaņošanu.

Pirms atkārtotas mēģinājuma klasificējiet kļūdas:

• Atkārtoti izmēģināma jauda: Pagaidu 429 vai dokumentēta īslaicīga kvotas atbilde.
• Atkārtoti izmēģināma pārslodze: Pagaidu 503 vai līdzvērtīga nodrošinātāja pārslodzes signāls.
• Nepārbaudāma politikas kļūme: Dienas kvota, tēriņu ierobežojums, atspējots projekts vai nomnieka ierobežojums.
• Nepārbaudāma pieprasījuma kļūme: Nederīga shēma, neatbalstīts parametrs, autentifikācijas kļūme vai nepareizi veidota ievade.
• Termiņa kļūme: Pieprasījums, kura atlikušais lietotāja vai darbplūsmas termiņš ir īsāks nekā nākamajam drošajam mēģinājumam.

Atkāpšanās ir atsevišķs lēmums. Dažādam pakalpojumu sniedzējam var būt atšķirīga izvades darbība, cenas, latentums, dzīvesvieta vai konteksta ierobežojumi. Izmantojiet atkāpšanos tikai tad, ja maršruta politika apstiprina, ka darba slodzes līgums var izturēt šīs atšķirības.

Atklājiet lēmumus un novērtējiet piesātinājumu

Komandas nevar novērst ierobežošanu, ja vārteja atgriež tikai vispārīgu 429. Atgrieziet drošus metadatus, piemēram, piemērojamo ierobežojumu, atlikušo jaudu, atiestatīšanas laiku, rindas lēmumu, darba slodzes klasi un noraidīšanas iemeslu. Neatklājiet cita īrnieka lietojuma datus vai neapstrādātus pakalpojumu sniedzēja akreditācijas datus.

Vismaz uzraugiet:

• Rezervācijas panākumi un noraidīšanas rādītājs pēc nomnieka, maršruta un segmenta.
• Rindas dziļums, gaidīšanas laiks rindā, termiņu beigas un atcelšana.
• Nodrošinātāja 429. un 503. tarifi, atkārtota mēģinājuma pēc biežums un rampas ātruma noraidījumi.
• Aptuvenais un faktiskais marķiera lietojums un pārmērīgas rezervācijas dēļ iztērētā jauda.
• Vienlaikus piesātinājums un katra nomnieka patērētās jaudas daļa.
• Mēģiniet vēlreiz pēc loģiskā pieprasījuma un atkāpšanās biežuma.
• Dienas kvota un tēriņu logs.

Slodzes testos jāiekļauj sērijveida trafika, gara konteksta pieprasījumi, maksimālie izvades pieprasījumi, straumēšanas atvienojumi, ikdienas kvotas izsmelšana, nodrošinātāja 429 un 503 atbildes un viens trokšņains nomnieks, kas konkurē ar produkcijas trafiku. Pārbaudiet ne tikai to, vai pieprasījumi beidzot tiek pabeigti, bet arī to, vai rindu termiņi, godīgums un atkārtotā mēģinājuma budžeti paliek nemainīgi.

Ieviešanas kontrolsaraksts

• Definējiet kanoniskās dimensijas, neatmetot pakalpojumu sniedzējam noteiktos ierobežojumus.
• Piešķiriet katram pieprasījumam normalizētu nomnieku, maršrutu, darba slodzes klasi un idempotences atslēgu.
• Pirms nosūtīšanas aprēķiniet un rezervējiet ievadi, izvadi, kopējos marķierus, tēriņus, pieprasījumus un vienlaicību.
• Pārveidojiet vairāku grupu rezervācijas un droši beidziet atcelto rezervāciju derīguma termiņu.
• Pēc katra mēģinājuma saskaņojiet faktisko pakalpojumu sniedzēja lietojumu un atbilžu galvenes.
• Izmantojiet svērto godīgumu, sērijveida kredītus un skaidras prioritātes klases.
• Piešķiriet katrai rindai termiņu, maksimālo dziļumu un pārslodzes darbību.
• Centralizējiet atkārtojumus un ievērojiet nodrošinātāja Retry-After vērtības.
• Atdaliet pagaidu jaudas kļūdas no pastāvīgās politikas un pieprasiet kļūdas.
• Publicēt ierobežojošos metadatus un pārraudzīt piesātinājumu pēc nomnieka un maršruta.
• Pārbaudes nodrošinātāja kvotas izsmelšana, rampas ierobežojumi, straumēšana, atkāpšanās un trokšņaina kaimiņa rīcība.

Secinājums

Vairāku modeļu vārtejai pakalpojumu sniedzēja kvota jāpārvalda kā koplietota infrastruktūras jauda, nevis kā neatkarīgu SDK iestatījumu kopums. Pakalpojumu sniedzēja neitrāla likmes ierobežojumu brokeris platformu komandām nodrošina vienu uzņemšanas ceļu, vienu godīguma politiku, vienu atkārtotas mēģinājuma budžetu un vienu vietu, kur saskaņot aprēķinus ar realitāti.

Dizains prasa vairāk nekā tikai vispārīgu pilnvaru kopu. Tam ir jāatspoguļo pieprasījumi, ievades un izvades pilnvaras, dienas kvotas, tēriņu periodi, vienlaicība, nodrošinātāja darbības joma un ātruma palielināšanas ātrums. Kad šīs dimensijas ir skaidri norādītas, vārteja var izdarīt paredzamas izvēles: nosūtīt tūlīt, rindu ar noteiktu termiņu, pamest darbu, mēģināt vēlreiz centralizēti vai izmantot līguma drošu atkāpšanos. Tādā veidā caurlaidspējas kontrole kļūst par darbības iespēju, nevis par periodisku 429. un 503. gadījumu ražošanas avotu.

Saistīta informācija

• pakešu apstrāde neinteraktīvām LLM darbslodzēm