Hogyan hozzunk létre egy szolgáltató-semleges kamatlimit-brókert a többmodell LLM API-khoz

Ha több csapat több LLM-szolgáltatón osztozik, a díjkorlátozás többé nem csak szolgáltató-integrációs részlet. Ez a megosztott kapacitás problémája lesz. Az egyik szolgáltató korlátozhatja a kéréseket és a beviteli tokeneket, a másik elválaszthatja a bemeneti és kimeneti tokeneket, a harmadik pedig kvótákat alkalmazhat a projekt szintjén vagy egy gördülő költési ablakon keresztül. Az egyes SDK számokon belüli újrapróbálkozási hurok nem tudja koordinálni ezeket a megszorításokat a bérlők, alkalmazások, partnerkulcsok és modellútvonalak között.

A praktikus megoldás egy központi kamatlimit-bróker az átjárónál. A bróker megbecsüli a keresletet, lefoglalja a kapacitást a feladás előtt, sorba állítja vagy elutasítja a munkát a házirendnek megfelelően, és a foglalás befejezése után egyezteti a foglalást a tényleges felhasználással. A szolgáltató válaszai ezután a független újrapróbálkozási viharok kiváltása helyett finomítják a közvetítő nézetét a rendelkezésre álló kapacitásról.

Ez az architektúra hasznos minden vállalati LLM API számára, amely kiszámítható átvitelt igényel a belső csapatok, éles alkalmazások, automatizálási ügynökök vagy külső partnerek között.

Miért nem csökkenthetők a szolgáltatói díjkorlátok percenkénti kérésekre

Tény: A szolgáltatói kvóták különböző dimenziókat és hatóköröket használnak. A gyakori dimenziók közé tartoznak a percenkénti kérések, a percenkénti bemeneti tokenek, a percenkénti kimeneti tokenek, az összes tokenek, a napi kérelmek, az egyidejűség, a költési időtartamok és a gyorsulási vagy felfutási korlátok. Ugyanaz a szolgáltató különböző korlátokat állíthat fel egy szervezetre, projektre, munkaterületre, modellre vagy API termékre vonatkozóan.

Például a szolgáltatói dokumentáció olyan kombinációkat ír le, mint:

• Kérés- és tokenkorlátok a fennmaradó kapacitással és visszaállítási információkkal a válaszfejlécekben.
• Külön bemeneti és kimeneti token korlátozások az üzenet API-khoz.
• Projektszintű kvóták az egyes API kulcsokhoz csatolt kvóták helyett.
• Napi kéréskorlátok, amelyek a szolgáltató által meghatározott időpontban visszaállnak.
• Költésalapú gördülő ablakok, amelyek még akkor is visszautasíthatják a forgalmat, ha a kérések és a token díjak elfogadhatónak tűnnek.
• Gyorsulási korlátok, amelyek reagálnak a forgalom meredek növekedésére, még akkor is, ha az állandósult használat a közzétett kvóta alatt van.

Egy átjáró, amely csak egy provider RPM nevű számot tárol, az egyik dimenzióban túlzottan fogadja a forgalmat, vagy egy másikban nem használja a kapacitást. Azt sem tudja megmagyarázni, hogy az elutasítás bérlői szabályzat, szolgáltatói projektkvóta, napi limit vagy túlterhelési válasz miatt történt-e.

Referencia-architektúra kamatkorlátozási közvetítőhöz

Helyezze el a közvetítőt a kérési útvonalon a szolgáltatói adapter előtt. Minden kérésnek ugyanazon a foglalási folyamaton kell keresztülmennie, függetlenül attól, hogy SDK, belső szolgáltatás, automatizálási ügynök vagy partner API kulcson keresztül érkezett-e.

1. Az identitás normalizálása. Oldja meg a szervezetet, a bérlőt, a csapatot, az alkalmazást, a környezetet, a partnert, a API kulcsot, a modellútvonalat és a munkaterhelési osztályt.
2. Becsülje meg a keresletet. Számítsa ki a várható bemeneti tokeneket, a maximális kimeneti tokeneket, a becsült ráfordítást és az esetleges párhuzamossági költségeket.
3. Értékelje ki a házirendet. Ellenőrizze a bérlői költségkereteket, a várólista határidejét, az útvonal alkalmasságát, a prioritást és a tartalék szabályokat.
4. Tartalékkapacitás. Atomikusan tartalékkapacitás a megfelelő belső és a szolgáltató felé eső tárolókban.
5. Kiküldés. Csak a foglalás sikeressége után küldje el a kérést.
6. Összeegyeztetés. Cserélje le a becsléseket a tényleges használattal, engedje fel a fel nem használt foglalásokat, valamint rögzítse a szolgáltató fejléceit és a válaszok besorolását.
7. Döntse el a következő műveletet. Az eredmény visszaküldése, a munka sorba állítása, újrapróbálkozás központilag, visszalépés vagy elutasítás a munkaterhelési szerződés szerint.

A foglalási szolgáltatásnak vízszintesen méretezhetőnek kell lennie, de döntésének minden kérésnél atomi jellegűnek kell lennie. Egy elosztott számláló, amely lehetővé teszi, hogy két dolgozó megfigyelje ugyanazt a fennmaradó kapacitást, újra létrehozhatja a 429-es szolgáltatói problémát az átjárón belül.

Használjon kanonikus kvótamodellt a szolgáltatói különbségek elrejtése nélkül

Határozzon meg egy kanonikus modellt, amely szolgáltató-specifikus megszorításokat tud reprezentálni ahelyett, hogy minden szolgáltatót egyetlen absztrakcióra kényszerítene.

Minden korlátot gyűjtőcsoportként ábrázoljon hatókörrel, kapacitással, újratöltési vagy visszaállítási szabállyal, egységgel és forrással. A szolgáltatói projektcsoport kéréseket és beviteli tokeneket tartalmazhat. Egy munkaterületi gyűjtőtár tartalmazhat kimeneti tokeneket. A partner belső szabályzata párhuzamossági és költési korlátokat adhat. A felvételi döntés csak akkor sikeres, ha minden szükséges foglalás sikeres.

Ne tekintse a szolgáltatói fejléceket az igazság teljes forrásának. Használja őket a bróker becsléseinek korrigálására, de tartsa meg a konfigurált modellt a limitekhez, amelyek nem jelennek meg minden válasz esetén. A fejlécek nevei, a rendelkezésre állás és a visszaállítási szemantika szolgáltatónként és útvonalonként eltérőek.

Foglalja le a tokeneket feladás előtt, majd hangolja össze őket

A token foglalás a legfontosabb különbség a közvetítő és az újrapróbálkozás burkolója között. A brókernek szüksége van egy igénybecslésre a kérelem elküldése előtt.

A bemeneti tokenek esetében becslést végezzen a sorosított üzenetekből, az eszközdefiníciókból, a strukturált kimeneti sémából és bármely letöltött kontextusból. Kimeneti tokenek esetén használja a kérés maximumát, ha elérhető, vagy modell- és munkaterhelés-specifikus becslést, ha az ügyfél nem biztosít ilyet. Tartsa a becslést a foglaláshoz csatolva, hogy később össze lehessen hasonlítani a tényleges használattal.

Egy egyszerű foglalási rekord a következőket tartalmazhatja:

• Egyedi kérelem és foglalási azonosító.
• Bérlő, alkalmazás, API kulcs, útvonal és terhelési osztály.
• Becsült beviteli tokenek, kimeneti tokenek, teljes tokenek és ráfordítás.
• Minden, a foglalás által felszámított összeg.
• Létrehozási idő, lejárati idő, sor határideje és idempotencia kulcsa.
• Végső tényleges felhasználás és az egyeztetés során felszabaduló vagy felszámított összeg.

A konzervatív becslések csökkentik a 429-es szolgáltatói válaszokat, de megszakíthatják a kapacitást. Mérje meg a becslési hibát modell, útvonal, prompt család, kontextushossz és strukturált kimeneti mód szerint. Ezután módosítsa a becsléseket korlátos korrekciókkal, ahelyett, hogy egyetlen szokatlan kérés torzíthatná a modellt.

A streameléshez speciális szabályzat szükséges. Lefoglalhatja a maximális kimeneti engedményt, és felszabadíthatja a fel nem használt részt, amikor az adatfolyam véget ér, vagy lefoglalhatja a kimeneti kapacitást kisebb lépésekben, ahogy megérkeznek a tokenek. Az első megközelítést könnyebb érvelni; a második javíthatja a kihasználtságot, de megbízható törlést, időtúllépést és leválasztási kezelést igényel.

Kvóták hierarchikus érvényesítése

A kapacitást a legszűkebb irányelvtől a legszélesebb megosztott erőforrásig kell ellenőrizni. Egy tipikus hierarchia a következő:

1. API kulcs vagy szolgáltatásazonosító.
2. Alkalmazás és környezet.
3. Csapat vagy ügyfél bérlő.
4. Partner- vagy viszonteladói fiók.
5. Szolgáltatói munkaterület vagy alfiók.
6. Szállítói projekt vagy szervezet.
7. Modell és útvonal.

A partneralkalmazásból érkező kéréshez ezért négy sikeres foglalásra lehet szükség: a partner egyidejűségi szabályzatára, az ügyfél bérlőjének token költségvetésére, az átjáró útvonal-kiosztására és a szolgáltatói projekt rendelkezésre álló kvótájára. Ha valamelyik foglalás sikertelen, engedje fel a már megszerzett foglalásokat, és alkalmazza a sikertelen csoport döntését.

A méltányosság kedvéért használjon súlyozott méltányos sorban állást vagy hiányos körmérkőzést, ahelyett, hogy az előbb érkező munkavállalónak engedélyezné a megosztott készlet felhasználását. Rendeljen nagyobb súlyokat a termelési forgalomhoz és alacsonyabb súlyokat a háttérfeladatokhoz, miközben megőrzi az egyes bérlők sorozatos jóváírásait. A kemény particionálást könnyebb megmagyarázni, de tétlenül hagyhatja a kapacitást, ha az egyik bérlő csendes. A súlyozott megosztás általában hatékonyabban használja fel a kapacitást, feltéve, hogy a zajos bérlők korlátozzák a sorozatfelvételi korlátokat.

Várólisták tervezése a munkaterhelési szerződések körül

A várólista nem jelent automatikusan megbízhatósági funkciót. A látható 429-et láthatatlan tízperces késleltetéssé tudja változtatni. Minden sorosztálynak szüksége van egy határidőre, a törlési viselkedésre, a maximális mélységre és a túlterhelési műveletre.

• Interaktív: Rövid határidő, kis sor, kiszámítható elutasítás vagy modellromlás, ha a kapacitás nem áll rendelkezésre.
• Gyártási háttér: Hosszabb határidő, tartós várólista, idempotenciakulcs és ellenőrzött újrapróbálkozási költségkeret.
• Partner: Bérlőspecifikus kvóták, közzétett válasz metaadatok, és nincs hozzáférés más bérlő sorállapotához.
• Kötegezhető: Késleltetett végrehajtás, nagyobb várakozási sor és opcionális útvonalválasztás a szolgáltatói köteghez API, ha a munkaterhelés ezt lehetővé teszi.

A sorba lépésnek egyértelmű döntést kell eredményeznie. A API szerződéstől függően tegyen közzé egy 429-es vagy egy átjáró-specifikus túlterhelési választ egy újrapróbálkozás utáni értékkel, sorazonosítóval és okkóddal. Ne ígérjen befejezési időt, hacsak a rendszer nem tudja érvényesíteni ezt az ígéretet.

A kötegelt feldolgozás eltávolíthatja a nem interaktív munkát a szinkron kapacitásból, de megváltoztatja az eredmények időzítését, az újrapróbálkozás viselkedését, a törlést és az egyeztetést. Kezelje külön végrehajtási útvonalként, ahelyett, hogy egyszerűen nagyon hosszú sorba helyezné a szinkron kéréseket. A háttérmunka során hasonlítsa össze a működési kompromisszumokat az AI API költségszabályozási irányelveivel és a meglévő kötegelt műveletekkel.

Az újrapróbálkozás és a túlterhelés kezelésének központosítása

Tény: Az ideiglenes sebességkorlát-válaszok általában a HTTP 429-es kódot használják, míg a szolgáltatói túlterhelés esetén az 503-as vagy egy szolgáltató-specifikus hibakód használható. Egyes szolgáltatók egy Retry-After fejlécet adnak vissza, és a szolgáltatói dokumentáció azt javasolja, hogy tartsa tiszteletben, ha van. Egy gyors forgalmi rámpa gyorsulást vagy lassítást is eredményezhet a szokásos kanál kimerülése nélkül.

Javaslat: Kezelje az Újrapróbálkozás után alsó korlátot, ne opcionális javaslatként. Addig szüneteltesse az érintett szolgáltatói hatókört, adjon hozzá korlátozott jittert a szinkronizált ébresztések elkerülése érdekében, és hagyja, hogy a közvetítő döntse el, mely sorba állított kérések használhatják fel a visszanyert kapacitást.

Ha a Retry-After hiányzik vagy érvénytelen, használja a korlátozott exponenciális visszalépést remegéssel. Tartsa az újrapróbálkozási költségkeretet a közvetítőben, ne külön minden SDK és szolgáltatói adapterben. Ellenkező esetben egyetlen logikai kérés létrehozhat egy átjáró-újrapróbálkozást, egy SDK újrapróbálkozást, egy HTTP ügyfél-ismétlést és egy szolgáltatóoldali újrajátszást.

Osztályozza a hibákat az újrapróbálkozás előtt:

• Újrapróbálható kapacitás: Ideiglenes 429-es vagy dokumentált átmeneti kvótaválasz.
• Újrapróbálható túlterhelés: Ideiglenes 503-as vagy azzal egyenértékű szolgáltatói túlterhelési jel.
• Nem újrapróbálható irányelvhiba: Napi kvóta, költségplafon, letiltott projekt vagy bérlői korlát.
• Nem újrapróbálható kéréshiba: Érvénytelen séma, nem támogatott paraméter, hitelesítési hiba vagy hibás bevitel.
• Határidő hiba: Olyan kérés, amelynek hátralévő felhasználói vagy munkafolyamat-határideje rövidebb, mint a következő biztonságos próbálkozásé.

A tartalék egy külön döntés. Egy másik szolgáltató eltérő kimeneti viselkedéssel, árképzéssel, késleltetéssel, tartózkodási hellyel vagy környezeti korlátokkal rendelkezhet. Csak akkor használja a tartalékot, ha az útvonalszabályzat megerősíti, hogy a munkaterhelési szerződés elviseli ezeket a különbségeket.

Döntések közzététele és telítettség mérése

A csapatok nem tudják elhárítani a korlátozást, ha az átjáró csak egy általános 429-et ad vissza. Biztonságos metaadatokat küld vissza, például az alkalmazandó korlátot, a fennmaradó kapacitást, az alaphelyzetbe állítási időt, a sorról szóló döntést, a terhelési osztályt és az elutasítás okát. Kerülje el egy másik bérlő használati vagy nyers szolgáltatói hitelesítő adatainak felfedését.

Minimum figyelje:

• A foglalás sikeressége és az elutasítások aránya bérlő, útvonal és csoport szerint.
• Várólista mélysége, várakozási ideje, határidők lejárta és lemondások.
• 429-es és 503-as szolgáltatói díjak, újrapróbálkozás utáni gyakoriság és felfutási sebesség elutasítása.
• A becsült és a tényleges tokenhasználat és a túlfoglalás miatt elpazarolt kapacitás összehasonlítása.
• A párhuzamosság telítettsége és az egyes bérlők által felhasznált kapacitás részesedése.
• Próbálkozzon újra logikai kérés és tartalék gyakoriság szerint.
• Napi kvóta és ráfordítási ablak.

A terhelési teszteknek tartalmazniuk kell a sorozatforgalmat, a hosszú kontextusra vonatkozó kéréseket, a maximális kimeneti kéréseket, a streaming leválasztását, a napi kvóta kimerülését, a 429-es és 503-as szolgáltatói válaszokat, valamint egy zajos bérlőt, aki versenyez az éles forgalommal. Nem csak azt ellenőrizze, hogy a kérelmek végül befejeződnek-e, hanem azt is, hogy a várakozási határidők, a méltányosság és az újrapróbálkozási költségkeretek változatlanok-e.

Megvalósítási ellenőrzőlista

• Határozza meg a kanonikus méreteket anélkül, hogy elvetné a szolgáltató-specifikus korlátozásokat.
• Minden kéréshez rendeljen normalizált bérlőt, útvonalat, terhelési osztályt és idempotenciakulcsot.
• A feladás előtt becsülje meg és foglalja le a bemenetet, a kimenetet, a teljes tokeneket, a ráfordítást, a kérelmeket és a párhuzamosságot.
• A több gyűjtőhelyes foglalások atomossá tétele és az elhagyott foglalások biztonságos lejáratása.
• Minden próbálkozás után hangolja össze a tényleges szolgáltatóhasználatot és a válaszfejlécet.
• Használjon súlyozott igazságosságot, sorozatjeleket és kifejezett prioritási osztályokat.
• Minden sorhoz rendeljen határidőt, maximális mélységet és túlterhelési műveletet.
• Az újrapróbálkozások központosítása és a szolgáltató Retry-After értékek tiszteletben tartása.
• Válassza el az ideiglenes kapacitáshibákat az állandó házirendtől és kérje le a hibákat.
• Tegye közzé a korlátozó metaadatokat, és figyelje a telítettséget bérlő és útvonal szerint.
• Tesztellátói kvóta kimerülése, rámpakorlátok, streamelés, tartalék és zajos szomszéd viselkedés.

Következtetés

A több modellből álló átjárónak megosztott infrastruktúrakapacitásként kell kezelnie a szolgáltatói kvótát, nem pedig független SDK beállítások gyűjteményeként. Egy szolgáltatósemleges díjkorlátozási bróker egy belépési utat, egy méltányossági politikát, egy újrapróbálkozási költségkeretet és egy helyet biztosít a platformcsapatok számára, ahol összeegyeztethetik a becsléseket a valósággal.

A tervezéshez többre van szükség, mint egy általános tokengyűjtőre. Meg kell jelenítenie a kéréseket, a bemeneti és kimeneti tokeneket, a napi kvótákat, a költési időszakokat, a párhuzamosságot, a szolgáltatói hatókört és a felfutási sebességet. Ha ezek a dimenziók egyértelműek, az átjáró kiszámítható döntéseket tud hozni: elküldi most, sorba állítja a határidőt, leállítja a munkát, újrapróbálkozik központilag, vagy szerződésbiztos tartalékot használ. Így válik az átviteli vezérlés működési képességgé, nem pedig a 429-es és 503-as incidensek visszatérő forrásává.

Kapcsolódó olvasmány

• kötegelt feldolgozás nem interaktív LLM-munkaterhelésekhez