Cum să construiți un broker de limită de rată neutru pentru furnizor pentru API-uri LLM cu mai multe modele

Când mai multe echipe împărtășesc mai mulți furnizori LLM, limitarea ratelor nu mai este un detaliu de integrare a furnizorului. Devine o problemă de capacitate partajată. Un furnizor poate limita cererile și jetoanele de intrare, altul poate separa jetoanele de intrare și de ieșire, iar un al treilea poate aplica cote la nivel de proiect sau într-o fereastră de cheltuieli rulante. O buclă de reîncercare în fiecare SDK nu poate coordona aceste constrângeri între chiriași, aplicații, chei ale partenerilor și rute model.

Soluția practică este un broker central de limită a ratei la gateway. Brokerul estimează cererea, rezervă capacitatea înainte de expediere, pune la coadă sau respinge munca conform politicii și reconciliază rezervarea cu utilizarea reală după finalizare. Răspunsurile furnizorului rafinează apoi viziunea brokerului asupra capacității disponibile în loc să declanșeze furtuni independente de reîncercări.

Această arhitectură este utilă pentru orice întreprindere LLM API care are nevoie de un debit previzibil în cadrul echipelor interne, aplicațiilor de producție, agenților de automatizare sau partenerilor externi.

De ce limitele ratelor furnizorului nu pot fi reduse la solicitări pe minut

Realitate: Cotele furnizorilor folosesc dimensiuni și domenii diferite. Dimensiunile obișnuite includ solicitări pe minut, jetoane de intrare pe minut, jetoane de ieșire pe minut, jetoane totale, solicitări pe zi, concurență, ferestre de cheltuieli și limitele de accelerare sau rampă. Același furnizor poate expune limite diferite pentru o organizație, proiect, spațiu de lucru, model sau API produs.

De exemplu, documentația furnizorului descrie combinații precum:

• Limite de solicitare și de indicative cu informații despre capacitatea rămasă și resetare din anteturile răspunsului.
• Separați limitele indicativelor de intrare și ale jetonului de ieșire pentru API-urile pentru mesaje.
• Cote la nivel de proiect, mai degrabă decât cote atașate la API chei individuale.
• Limite zilnice de solicitare care se resetează la o oră definită de furnizor.
• Ferestre de rulare bazate pe cheltuieli care pot respinge traficul chiar și atunci când ratele de solicitare și de indicative par acceptabile.
• Limite de accelerare care reacționează la o creștere bruscă a traficului, chiar și atunci când utilizarea în regim de echilibru este sub cota publicată.

Un gateway care stochează un singur număr numit furnizor RPM va supraadmite în cele din urmă trafic într-o dimensiune sau capacitate insuficientă în alta. De asemenea, nu poate explica dacă o respingere a venit dintr-o politică de chiriaș, o cotă de proiect a furnizorului, o limită zilnică sau un răspuns la supraîncărcare.

Arhitectură de referință pentru un broker de limită de rată

Plasați brokerul în calea cererii înaintea adaptorului furnizorului. Fiecare solicitare ar trebui să treacă prin același flux de rezervare, indiferent dacă a sosit printr-o cheie SDK, un serviciu intern, un agent de automatizare sau o cheie API de partener.

1. Normalizarea identității. Rezolvați organizația, chiriașul, echipa, aplicația, mediul, partenerul, API cheia, traseul modelului și clasa de volum de lucru.
2. Estimați cererea. Calculați indicativele de intrare așteptate, simbolurile de ieșire maxime, cheltuielile estimate și orice cost de concurență.
3. Evaluați politica. Verificați bugetele chiriașilor, termenele de așteptare, eligibilitatea rutei, prioritatea și regulile alternative.
4. Rezervați capacitate. Rezervați atomic capacitatea în compartimentele interne relevante și orientate către furnizor.
5. Expediere. Trimiteți solicitarea numai după ce rezervarea reușește.
6. Reconciliere. Înlocuiți estimările cu utilizarea reală, eliberați rezervările neutilizate și înregistrați anteturile furnizorilor și clasificarea răspunsurilor.
7. Decideți următoarea acțiune. Returnați rezultatul, puneți în coadă lucrările, reîncercați central, retrageți-l sau respingeți-l conform contractului privind volumul de muncă.

Serviciul de rezervare ar trebui să fie scalabil pe orizontală, dar decizia sa trebuie să fie atomică pentru fiecare solicitare. Un contor distribuit care permite doi lucrători să observe aceeași capacitate rămasă poate recrea problema furnizorului 429 în interiorul gateway-ului.

Utilizați un model canonic de cotă fără a ascunde diferențele dintre furnizori

Definiți un model canonic care poate reprezenta constrângeri specifice furnizorului în loc să forțați fiecare furnizor să facă o singură abstracție.

Reprezentați fiecare limită ca o găleată cu un domeniu de aplicare, capacitate, regulă de reîncărcare sau resetare, unitate și sursă. Un grup de proiect al furnizorului poate conține solicitări și jetoane de intrare. O găleată de spațiu de lucru poate conține jetoane de ieșire. O politică internă pentru parteneri poate adăuga concurență și limite de cheltuieli. Decizia de admitere este reușită numai dacă toate rezervările necesare reușesc.

Nu tratați anteturile furnizorilor ca pe o sursă completă de adevăr. Folosiți-le pentru a corecta estimările brokerului, dar păstrați un model configurat pentru limitele care nu sunt expuse la fiecare răspuns. Numele antetului, disponibilitatea și semantica de resetare variază în funcție de furnizor și rută.

Rezervați jetoanele înainte de expediere, apoi reconciliați-le

Rezervarea jetonului este cea mai importantă diferență dintre un broker și un wrapper de reîncercare. Brokerul are nevoie de o estimare a cererii înainte de a trimite solicitarea.

Pentru jetoanele de intrare, estimare din mesajele seriate, definițiile instrumentelor, schema de ieșire structurată și orice context preluat. Pentru jetoanele de ieșire, utilizați cererea maximă atunci când este disponibilă sau o estimare specifică modelului și sarcinii de lucru atunci când clientul nu furnizează una. Păstrați estimarea atașată rezervării, astfel încât să poată fi comparată mai târziu cu utilizarea reală.

O înregistrare simplă de rezervare poate conține:

• O solicitare unică și un ID de rezervare.
• Chiriaș, aplicație, API cheie, rută și clasa de sarcină de lucru.
• Jetoane de intrare estimate, jetoane de ieșire, jetoane totale și cheltuieli.
• Fiecare grup taxat de rezervare.
• Timpul de creare, timpul de expirare, termenul limită la coadă și cheia de idempotnță.
• Utilizarea reală finală și suma eliberată sau debitată în timpul reconcilierii.

Estimările prudente reduc răspunsurile furnizorului 429, dar pot limita capacitatea. Măsurați eroarea de estimare după model, traseu, familie de prompturi, lungime a contextului și modul de ieșire structurată. Apoi ajustați estimările utilizând corecții delimitate în loc să permiteți unei singure solicitări neobișnuite să distorsioneze întregul model.

Transmiterea în flux necesită o politică specifică. Puteți rezerva alocația maximă de ieșire și puteți elibera partea nefolosită când fluxul se termină sau puteți rezerva capacitatea de ieșire în trepte mai mici pe măsură ce sosesc jetoanele. Prima abordare este mai ușor de raționat; al doilea poate îmbunătăți utilizarea, dar necesită o anulare fiabilă, expirare și o gestionare a deconectării.

Aplicați cotele ierarhic

Capacitatea trebuie verificată de la cea mai restrânsă politică la cea mai largă resursă partajată. O ierarhie tipică este:

1. API cheie sau identitate de serviciu.
2. Aplicație și mediu.
3. Chiriaș pentru echipă sau client.
4. Cont de partener sau de reseller.
5. Spațiu de lucru sau subcont al furnizorului.
6. Proiect sau organizație furnizor.
7. Model și traseu.

O solicitare din partea unei aplicații partenere poate necesita, prin urmare, patru rezervări reușite: politica de concurență a partenerului, bugetul de indicativ al chiriașului clientului, alocarea rutei gateway-ului și cota disponibilă a proiectului furnizorului. Dacă vreo rezervare eșuează, eliberați rezervările deja obținute și aplicați decizia grupului eșuat.

Pentru corectitudine, utilizați cozile de așteptare ponderate sau round-robin deficitare, în loc să permiteți lucrătorului care sosește primul să consume grupul comun. Atribuiți ponderi mai mari traficului de producție și ponderi mai mici lucrărilor de fundal, păstrând în același timp creditele de explozie pentru fiecare locatar. Partiționarea hard este mai ușor de explicat, dar poate lăsa capacitatea inactivă atunci când un chiriaș este tăcut. Partajarea ponderată utilizează în general capacitatea mai eficient, cu condiția ca locatarii zgomotoși să aibă limite de explozie limitate.

Proiectați cozi în jurul contractelor de volum de muncă

O coadă nu este automat o caracteristică de fiabilitate. Poate transforma un 429 vizibil într-o întârziere invizibilă de zece minute. Fiecare clasă de coadă are nevoie de un termen limită, comportament de anulare, adâncime maximă și acțiune de supraîncărcare.

• Interactiv: Termen limită scurt, coadă mică, respingere previzibilă sau degradare a modelului atunci când capacitatea nu este disponibilă.
• Baza de producție: Termen limită mai lung, coadă durabilă, cheie de idempotnță și buget controlat pentru reîncercări.
• Partener: Cote specifice locatarului, metadate de răspuns publicate și nici un acces la starea în coadă a altui chiriaș.
• Batchable: Execuție întârziată, coadă mai mare și rutare opțională către un lot furnizor API atunci când volumul de lucru permite acest lucru.

Admiterea în coadă ar trebui să returneze o decizie clară. În funcție de contractul API, expuneți un răspuns de supraîncărcare 429 sau specific gateway-ului cu o valoare de reîncercare după, un identificator de coadă și un cod motiv. Nu promiteți un termen de finalizare decât dacă sistemul poate aplica această promisiune.

Procesarea în loturi poate elimina munca neinteractivă din capacitatea sincronă, dar modifică sincronizarea rezultatelor, comportamentul reîncercării, anularea și reconcilierea. Tratați-o ca pe o cale de execuție separată, mai degrabă decât să plasați pur și simplu cereri sincrone într-o coadă foarte lungă. Pentru sarcinile de lucru în fundal, comparați compromisurile operaționale cu politicile de control al costurilor AI API și operațiunile existente pe lot.

Centralizarea reîncercării și gestionarea supraîncărcării

Realitate: Răspunsurile cu limita de rată temporară folosesc de obicei HTTP 429, în timp ce condițiile de supraîncărcare a furnizorului pot folosi 503 sau un cod de eroare specific furnizorului. Unii furnizori returnează un antet Retry-After, iar documentația furnizorului recomandă să-l onoreze atunci când este prezent. O rampă de trafic rapidă poate produce, de asemenea, un comportament de accelerare sau încetinire fără epuizarea obișnuită a găleții.

Recomandare: Tratați Retry-After ca o limită inferioară, nu ca o sugestie opțională. Întrerupeți domeniul de aplicare al furnizorului afectat până în acel moment, adăugați fluctuații delimitate pentru a preveni trezirile sincronizate și lăsați-l pe broker să decidă ce cereri din coadă pot folosi capacitatea recuperată.

Când Retry-After este absent sau invalid, utilizați limitare exponențială limitată cu fluctuație. Păstrați bugetul de reîncercare în broker, nu separat în fiecare SDK și adaptor de furnizor. În caz contrar, o solicitare logică poate produce o reîncercare a gateway-ului, o SDK reîncercare, o HTTP reîncercare client și o reluare la nivelul furnizorului.

Clasificați erorile înainte de a reîncerca:

• Capacitate care poate fi reîncercată: Răspuns temporar 429 sau cotă tranzitorie documentat.
• Supraîncărcare care poate fi reîncercată: Semnal de supraîncărcare temporar 503 sau echivalent al furnizorului.
• Eșecul politicii care nu se poate reîncerca: Cotă zilnică, plafon de cheltuieli, proiect dezactivat sau limită de chiriași.
• Eșec de solicitare care nu poate fi reîncercată: Schemă nevalidă, parametru neacceptat, eșec de autentificare sau intrare incorectă.
• Eșec la termen limită: O solicitare al cărei termen limită pentru utilizator sau flux de lucru rămas este mai scurt decât următoarea încercare sigură.

Returul este o decizie separată. Un alt furnizor poate avea un comportament de ieșire, prețuri, latență, rezidență sau limite de context diferite. Utilizați alternativă numai atunci când politica de rută confirmă că contractul de volum de muncă poate tolera aceste diferențe.

Expunerea deciziilor și măsurarea saturației

Echipele nu pot depana limitarea dacă gateway-ul returnează doar un 429 generic. Returnează metadate sigure, cum ar fi limita aplicabilă, capacitatea rămasă, timpul de resetare, decizia de coadă, clasa de sarcină de lucru și motivul respingerii. Evitați să expuneți utilizarea altui chiriaș sau acreditările brute ale furnizorului.

Cel puțin, monitorizați:

• Succesul rezervării și rata de respingere în funcție de locatar, rută și grupă.
• Adâncimea cozii, timpul de așteptare în coadă, expirările termenului limită și anulările.
• Tarifele furnizorului 429 și 503, frecvența reîncercării după și respingerea ratei rampe.
• Utilizarea token-ului estimată față de cea reală și capacitatea irosită prin suprarezervare.
• Saturația simultană și cota de capacitate consumată de fiecare chiriaș.
• Reîncercați pentru fiecare solicitare logică și frecvența de rezervă.
• Cota zilnică și spațiul de lucru al ferestrei de cheltuieli.

Testurile de încărcare ar trebui să includă trafic în rafală, solicitări de context lung, solicitări de ieșire maximă, deconectări în flux, epuizarea zilnică a cotei, răspunsurile furnizorului 429 și 503 și un chiriaș zgomotos care concurează cu traficul de producție. Validați nu numai dacă solicitările se finalizează în cele din urmă, ci și dacă termenele limită, corectitudinea și bugetele de reîncercare rămân intacte.

Lista de verificare pentru implementare

• Definiți dimensiuni canonice fără a elimina limitele specifice furnizorului.
• Atribuiți fiecărei solicitări un chiriaș normalizat, o rută, o clasă de sarcină de lucru și o cheie de idempotitate.
• Estimați și rezervați intrarea, ieșirea, totalul de jetoane, cheltuielile, solicitările și concurența înainte de expediere.
• Atomizați rezervările cu mai multe compartimente și expirați în siguranță rezervările abandonate.
• Reconciliați utilizarea efectivă a furnizorului și anteturile de răspuns după fiecare încercare.
• Utilizați corectitudinea ponderată, creditele de explozie și clasele de prioritate explicită.
• Oferiți fiecărei cozi un termen limită, adâncime maximă și acțiune de supraîncărcare.
• Centralizează reîncercările și onorează valorile furnizorului Retry-After.
• Separați erorile temporare de capacitate de politica permanentă și solicitați erori.
• Publicați metadatele de limitare și monitorizați saturația în funcție de locatar și rută.
• Epuizarea cotei furnizorului de testare, limitele rampei, fluxul în flux, alternativă și comportamentul zgomotos al vecinului.

Concluzie

Un gateway cu mai multe modele ar trebui să gestioneze cota de furnizor ca capacitate de infrastructură partajată, nu ca o colecție de setări independente SDK. Un broker de limită de tarif neutru pentru furnizor oferă echipelor platformei o cale de admitere, o politică de corectitudine, un buget de reîncercare și un loc pentru a reconcilia estimările cu realitatea.

Designul necesită mai mult decât un grup de jetoane generice. Trebuie să reprezinte cereri, jetoane de intrare și de ieșire, cote zilnice, ferestre de cheltuieli, concurență, domeniul de aplicare al furnizorului și rata de rampă. Odată ce aceste dimensiuni sunt explicite, gateway-ul poate face alegeri previzibile: trimiteți acum, puneți la coadă cu un termen limită, renunțați la lucru, reîncercați central sau utilizați o soluție de rezervă sigură pentru contract. Acesta este modul în care controlul debitului devine mai degrabă o capacitate operațională decât o sursă recurentă de incidente de producție 429 și 503.

Lectură asociată

• procesare în serie pentru sarcini de lucru LLM neinteractive