Ako vytvoriť sprostredkovateľa s neutrálnou sadzbou pre poskytovateľa pre multi-modelové LLM API

Keď niekoľko tímov zdieľa viacerých poskytovateľov LLM, obmedzenie sadzieb prestane byť detailom integrácie poskytovateľa. Stáva sa to problémom zdieľanej kapacity. Jeden poskytovateľ môže obmedziť požiadavky a vstupné tokeny, iný môže oddeliť vstupné a výstupné tokeny a tretí môže uplatniť kvóty na úrovni projektu alebo v rámci pohyblivého okna výdavkov. Slučka opakovania vnútri každého SDK nemôže koordinovať tieto obmedzenia medzi nájomníkmi, aplikáciami, partnerskými kľúčmi a modelovými trasami.

Praktickým riešením je centrálny sprostredkovateľ limitov na bráne. Sprostredkovateľ odhadne dopyt, rezervuje kapacitu pred odoslaním, zaradí do radu alebo odmietne prácu podľa pravidiel a po dokončení zosúladí rezerváciu so skutočným využitím. Odpovede poskytovateľa potom upravia pohľad makléra na dostupnú kapacitu namiesto spúšťania nezávislých opakovaných búrok.

Táto architektúra je užitočná pre všetky podnikové LLM API, ktoré potrebujú predvídateľnú priepustnosť naprieč internými tímami, produkčnými aplikáciami, automatizačnými agentmi alebo externými partnermi.

Prečo sa limity sadzieb poskytovateľa nedajú znížiť na počet žiadostí za minútu

Fakt: Kvóty poskytovateľov používajú rôzne dimenzie a rozsahy. Bežné dimenzie zahŕňajú požiadavky za minútu, vstupné tokeny za minútu, výstupné tokeny za minútu, celkový počet tokenov, požiadavky za deň, súbežnosť, výdavkové okná a limity zrýchlenia alebo rýchlosti. Ten istý poskytovateľ môže poskytnúť rôzne limity pre organizáciu, projekt, pracovný priestor, model alebo API produkt.

Napríklad dokumentácia poskytovateľa popisuje kombinácie ako:

• Limity žiadostí a tokenov s informáciami o zostávajúcej kapacite a resetovaní v hlavičkách odpovedí.
• Oddelené limity vstupných a výstupných tokenov pre správy API.
• Kvóty na úrovni projektu namiesto kvót pripojených k jednotlivým kľúčom API.
• Denné limity žiadostí, ktoré sa resetujú v čase určenom poskytovateľom.
• Postupné okná založené na výdavkoch, ktoré dokážu odmietnuť návštevnosť, aj keď sa sadzby žiadostí a tokenov zdajú prijateľné.
• Limity zrýchlenia, ktoré reagujú na prudký nárast návštevnosti, aj keď je používanie v ustálenom stave pod zverejnenou kvótou.

Brána, ktorá ukladá iba jedno číslo s názvom RPM poskytovateľa, nakoniec nadmerne pripustí návštevnosť v jednej dimenzii alebo nedostatočne využije kapacitu v inej. Nedokáže tiež vysvetliť, či odmietnutie pochádza z pravidiel nájomcu, projektovej kvóty poskytovateľa, denného limitu alebo reakcie na preťaženie.

Referenčná architektúra pre makléra limitu sadzieb

Umiestnite makléra do cesty žiadosti pred adaptér poskytovateľa. Každá žiadosť by mala prejsť rovnakým rezervačným tokom bez ohľadu na to, či bola doručená prostredníctvom kľúča SDK, internej služby, automatizačného agenta alebo partnera API.

1. Normalizácia identity. Vyriešte organizáciu, nájomníka, tím, aplikáciu, prostredie, partnera, kľúč API, trasu modelu a triedu pracovného zaťaženia.
2. Odhadnúť dopyt. Vypočítať očakávané vstupné tokeny, maximálne výstupné tokeny, odhadované výdavky a všetky náklady na súbežné používanie.
3. Vyhodnoťte pravidlá. Skontrolujte rozpočty nájomníkov, termíny poradia, vhodnosť trasy, prioritu a pravidlá pre núdzové riešenia.
4. Rezervovaná kapacita. Atómová rezervácia kapacity v relevantných interných a poskytovateľských segmentoch.
5. Dispatch. Žiadosť odošlite až po úspešnom dokončení rezervácie.
6. Reconcile. Nahradiť odhady skutočným využitím, uvoľniť nevyužité rezervácie a zaznamenať hlavičky poskytovateľa a klasifikáciu odpovedí.
7. Rozhodnite sa o ďalšej akcii. Vráťte výsledok, zaraďte prácu do frontu, skúste to znova centrálne, ustúpte alebo ju odmietnite podľa zmluvy o pracovnom zaťažení.

Rezervačná služba by mala byť horizontálne škálovateľná, ale jej rozhodnutie musí byť atomické pre každú požiadavku. Distribuované počítadlo, ktoré umožňuje dvom pracovníkom sledovať rovnakú zostávajúcu kapacitu, môže v bráne znovu vyvolať problém poskytovateľa.

Použite kanonický model kvót bez skrytia rozdielov medzi poskytovateľmi

Definujte kanonický model, ktorý dokáže reprezentovať obmedzenia špecifické pre poskytovateľa namiesto toho, aby ste každého poskytovateľa nútili do jednej abstrakcie.

Predstavujte každý limit ako segment s rozsahom, kapacitou, pravidlom doplňovania alebo resetovania, jednotkou a zdrojom. Segment projektu poskytovateľa môže obsahovať požiadavky a vstupné tokeny. Segment pracovného priestoru môže obsahovať výstupné tokeny. Interná politika partnera môže pridať limity súbežnosti a výdavkov. Rozhodnutie o prijatí je úspešné iba vtedy, ak budú úspešné všetky požadované rezervácie.

Nepovažujte hlavičky poskytovateľa za úplný zdroj pravdy. Použite ich na opravu odhadov makléra, ale ponechajte si nakonfigurovaný model pre limity, ktoré nie sú vystavené pri každej odpovedi. Názvy hlavičiek, dostupnosť a sémantika obnovenia sa líšia podľa poskytovateľa a trasy.

Rezervujte si tokeny pred odoslaním a potom ich zosúlaďte

Rezervácia tokenov je najdôležitejším rozdielom medzi maklérom a obálkou opakovania. Pred odoslaním žiadosti potrebuje maklér odhad dopytu.

Pre vstupné tokeny odhadnite zo serializovaných správ, definícií nástrojov, schémy štruktúrovaného výstupu a akéhokoľvek načítaného kontextu. Pre výstupné symboly použite maximum požiadavky, ak je k dispozícii, alebo odhad špecifický pre model a pracovné zaťaženie, ak ho klient neposkytne. Odhad si ponechajte priložený k rezervácii, aby ho bolo možné neskôr porovnať so skutočným využitím.

Jednoduchý záznam rezervácie môže obsahovať:

• Jedinečné ID žiadosti a rezervácie.
• Nájomca, aplikácia, kľúč API, trasa a trieda pracovného zaťaženia.
• Odhadované vstupné tokeny, výstupné tokeny, celkové tokeny a výdavky.
• Každý vedro účtované pri rezervácii.
• Čas vytvorenia, čas vypršania platnosti, termín poradia a kľúč idempotencie.
• Konečné skutočné využitie a suma uvoľnená alebo účtovaná počas vyrovnania.

Konzervatívne odhady znižujú počet odpovedí poskytovateľa 429, ale môžu obmedziť kapacitu. Zmerajte chybu odhadu podľa modelu, trasy, skupiny výziev, dĺžky kontextu a režimu štruktúrovaného výstupu. Potom upravte odhady pomocou obmedzených opráv namiesto toho, aby ste umožnili skreslenie celého modelu jedinej nezvyčajnej požiadavke.

Streamovanie vyžaduje špecifické pravidlá. Môžete si rezervovať maximálny povolený výstup a nepoužitú časť uvoľniť, keď sa tok skončí, alebo si môžete rezervovať výstupnú kapacitu v menších prírastkoch, keď prídu tokeny. O prvom prístupe je jednoduchšie uvažovať; druhý môže zlepšiť využitie, ale vyžaduje spoľahlivé zrušenie, časový limit a spracovanie odpojenia.

Hierarchicky presadzovať kvóty

Kapacitu treba kontrolovať od najužšej politiky po najširší zdieľaný zdroj. Typická hierarchia je:

1. API kľúč alebo identita služby.
2. Aplikácia a prostredie.
3. Nájomník tímu alebo zákazníka.
4. Účet partnera alebo predajcu.
5. Pracovný priestor alebo podúčet poskytovateľa.
6. Projekt alebo organizácia poskytovateľa.
7. Model a trasa.

Žiadosť z partnerskej aplikácie si preto môže vyžadovať štyri úspešné rezervácie: pravidlá súbežnosti partnera, rozpočet tokenov nájomníka zákazníka, pridelenie trasy brány a dostupná kvóta projektu poskytovateľa. Ak akákoľvek rezervácia zlyhá, uvoľnite už získané rezervácie a použite rozhodnutie neúspešného segmentu.

V záujme spravodlivosti použite radšej vážené spravodlivé radenie do poradia alebo deficitné cyklovanie namiesto toho, aby ktokoľvek z pracovníkov, ktorý príde prvý, mohol využiť zdieľaný fond. Priraďte vyššiu váhu produkčnej prevádzke a nižšiu váhu úlohám na pozadí, pričom zachováte zhlukové kredity pre každého nájomcu. Pevné rozdelenie na oddiely je jednoduchšie vysvetliť, ale môže nechať kapacitu nečinnú, keď je jeden nájomca ticho. Vážené zdieľanie vo všeobecnosti využíva kapacitu efektívnejšie za predpokladu, že hluční nájomníci majú obmedzené limity.

Navrhnite fronty okolo zmlúv o pracovnej záťaži

Rok nie je automaticky funkciou spoľahlivosti. Dokáže zmeniť viditeľnú 429-ku na neviditeľné desaťminútové oneskorenie. Každá trieda frontu potrebuje termín, zrušenie, maximálnu hĺbku a akciu preťaženia.

• Interaktívne: Krátky termín, malý rad, predvídateľné odmietnutie alebo degradácia modelu v prípade nedostupnosti kapacity.
• Produkčné pozadie: Dlhší termín, trvalý rad, kľúč idempotencie a kontrolovaný rozpočet na opakovanie.
• Partner: Kvóty špecifické pre nájomníkov, zverejnené metadáta odpovedí a žiadny prístup k stavu poradia iného nájomníka.
• Batchable: Oneskorené vykonávanie, väčší front a voliteľné smerovanie do dávky poskytovateľa API, keď to pracovné zaťaženie umožňuje.

Vstup do poradia by mal priniesť jasné rozhodnutie. V závislosti od zmluvy API vystavte odpoveď na preťaženie 429 alebo špecifickú pre bránu s hodnotou opätovného pokusu, identifikátorom frontu a kódom príčiny. Nesľubujte čas dokončenia, pokiaľ systém tento sľub nedokáže presadiť.

Dávkové spracovanie môže odstrániť neinteraktívnu prácu zo synchrónnej kapacity, ale zmení načasovanie výsledkov, správanie opakovania, zrušenie a odsúhlasenie. Považujte to skôr za samostatnú cestu vykonávania, než jednoducho umiestňujte synchrónne požiadavky do veľmi dlhého frontu. V prípade záťaže na pozadí porovnajte prevádzkové kompromisy s pravidlami riadenia nákladov AI API a existujúcimi dávkovými operáciami.

Centralizácia opakovania a spracovania preťaženia

Fakt: V odpovediach s dočasným limitom rýchlosti sa bežne používa HTTP 429, zatiaľ čo podmienky preťaženia poskytovateľa môžu používať kód 503 alebo kód chyby špecifický pre daného poskytovateľa. Niektorí poskytovatelia vracajú hlavičku Retry-After a dokumentácia poskytovateľa odporúča dodržiavať ju, ak je prítomná. Prudký nárast premávky môže tiež spôsobiť zrýchlenie alebo spomalenie bez bežného vyčerpania vedra.

Odporúčanie: Opakovať-po berte ako spodnú hranicu, nie ako voliteľný návrh. Do tohto času pozastavte rozsah ovplyvneného poskytovateľa, pridajte ohraničené chvenie, aby ste zabránili synchronizovanému prebudeniu, a nechajte makléra rozhodnúť, ktoré požiadavky vo fronte môžu využiť obnovenú kapacitu.

Ak funkcia Retry-Aft chýba alebo je neplatná, použite obmedzené exponenciálne stiahnutie s jitterom. Rozpočet na opätovný pokus ponechajte u makléra, nie samostatne v každom SDK a adaptéri poskytovateľa. V opačnom prípade môže jedna logická požiadavka vyvolať opätovný pokus brány, opakovanie SDK, HTTP opakovanie klienta a prehratie na strane poskytovateľa.

Pred opätovným pokusom klasifikujte chyby:

• Opakovateľná kapacita: Dočasná 429 alebo zdokumentovaná prechodná odpoveď na kvótu.
• Opakovateľné preťaženie: Dočasný signál 503 alebo ekvivalentný signál preťaženia poskytovateľa.
• Neopakovateľné zlyhanie pravidiel: Denná kvóta, limit výdavkov, zakázaný projekt alebo limit nájomníka.
• Zlyhanie požiadavky bez možnosti opakovania: Neplatná schéma, nepodporovaný parameter, zlyhanie overenia alebo chybný vstup.
• Zlyhanie termínu: Žiadosť, ktorej zostávajúci termín pre používateľa alebo pracovný postup je kratší ako nasledujúci bezpečný pokus.

Záložná reklama je samostatné rozhodnutie. Iný poskytovateľ môže mať odlišné výstupné správanie, ceny, latenciu, bydlisko alebo kontextové limity. Záložnú možnosť použite len vtedy, keď pravidlá trasy potvrdzujú, že zmluva o pracovnom zaťažení dokáže tolerovať tieto rozdiely.

Odhaliť rozhodnutia a zmerať saturáciu

Tímy nemôžu riešiť problémy s obmedzovaním, ak brána vracia iba všeobecný kód 429. Vráťte bezpečné metadáta, ako je príslušný limit, zostávajúca kapacita, čas resetovania, rozhodnutie o rade, trieda pracovného zaťaženia a dôvod odmietnutia. Vyhnite sa odhaleniu používania iného nájomníka alebo nespracovaných poverení poskytovateľa.

Sledujte minimálne:

• Miera úspešnosti a odmietnutia rezervácií podľa nájomníka, trasy a segmentu.
• Hĺbka frontu, čas čakania vo fronte, uplynutie termínu a zrušenia.
• Sadzby poskytovateľov 429 a 503, frekvencia opakovaného pokusu a odmietnutia postupnej rýchlosti.
• Odhadované verzus skutočné využitie tokenu a plytvanie kapacitou nadmernou rezerváciou.
• Nasýtenie súbežnosti a podiel kapacity spotrebovanej každým nájomníkom.
• Pokusy zopakovať podľa logickej požiadavky a frekvencie záložných reklám.
• Denná kvóta a voľný priestor v okne výdavkov.

Záťažové testy by mali zahŕňať nárazovú premávku, požiadavky s dlhým kontextom, požiadavky na maximálny výstup, odpojenia streamovania, vyčerpanie dennej kvóty, odpovede poskytovateľa 429 a 503 a jedného hlučného nájomníka, ktorý konkuruje prevádzke z produkcie. Overte nielen to, či sú žiadosti nakoniec dokončené, ale aj to, či zostávajú nedotknuté termíny poradia, spravodlivosť a rozpočty na opakovanie pokusov.

Kontrolný zoznam implementácie

• Definujte kanonické dimenzie bez toho, aby ste zrušili limity špecifické pre poskytovateľa.
• Priraďte každej žiadosti normalizovaného nájomníka, smerovanie, triedu pracovného zaťaženia a kľúč idempotencie.
• Pred odoslaním odhadnite a rezervujte vstup, výstup, celkový počet tokenov, výdavky, požiadavky a súbežnosť.
• Urobte z viacsegmentových rezervácií atómové a bezpečne ukončite platnosť opustených rezervácií.
• Po každom pokuse zosúladiť skutočné využitie poskytovateľa a hlavičky odpovedí.
• Používajte váženú spravodlivosť, jednorázové kredity a explicitné triedy priority.
• Každému frontu uveďte termín, maximálnu hĺbku a akciu preťaženia.
• Centralizujte pokusy a rešpektujte hodnoty poskytovateľa Retry-After.
• Oddeľte dočasné chyby kapacity od trvalých chýb pravidiel a žiadostí.
• Zverejňujte metadáta obmedzovania a monitorujte saturáciu podľa nájomníka a cesty.
• Testujte vyčerpanie kvóty poskytovateľa, limity rampy, streamovanie, záložné a hlučné susedské správanie.

Záver

Brána s viacerými modelmi by mala spravovať kvótu poskytovateľa ako zdieľanú kapacitu infraštruktúry, nie ako súbor nezávislých SDK nastavení. Sprostredkovateľ limitov sadzieb, ktorý je neutrálny voči poskytovateľom, poskytuje platformovým tímom jednu cestu prijatia, jednu zásadu spravodlivosti, jeden rozpočet na opakovanie a jedno miesto na zosúladenie odhadov s realitou.

Dizajn si vyžaduje viac než len všeobecnú skupinu tokenov. Musí predstavovať požiadavky, vstupné a výstupné tokeny, denné kvóty, výdavkové okná, súbežnosť, rozsah poskytovateľa a rýchlosť rampy. Akonáhle sú tieto dimenzie explicitné, brána môže robiť predvídateľné voľby: odoslanie teraz, zaradenie do frontu s termínom, odloženie práce, zopakovanie centrálne alebo použitie núdzového riešenia bezpečného pre zmluvu. Takto sa riadenie priepustnosti stáva operačnou schopnosťou a nie opakujúcim sa zdrojom produkčných incidentov 429 a 503.

Súvisiace čítanie

• dávkové spracovanie pre neinteraktívne pracovné zaťaženia LLM