Rate-Limit-Aware AI API átjárók: Forma RPM, TPM, sorozatfelvételek és bérlői méltányosság a 429-es elérés előtt
Praktikus átjáróarchitektúra a lépcsőzetes LLM API 429-ek megelőzésére: normalizálja a szolgáltatói korlátokat, becsülje meg a tokennyomást a feladás előtt, lefoglalja a kvótát bérlőnként, sima forgalmi rámpákat, és tegye auditálhatóvá a szabályozást.
A 429 egy LLM-szolgáltatótól nem csak egy újrapróbálkozási jel. Az éles folyamat során gyakran bizonyítja, hogy az alkalmazás már elvesztette az irányítást a beléptetés, a bérlői méltányosság, a várakozási idő vagy a szolgáltató-specifikus kvóta elszámolása felett.
A közös javítás – az exponenciális visszalépés – szükséges, de nem teljes. A Backoff reagál, miután a szolgáltató elutasítja a forgalmat. A sebességkorlátozást figyelembe vevő AI API-átjárónak a forgalmat még azelőtt alakítania kell, hogy a kérések elhagynák a rendszert: becsülje meg a tokennyomást, lefoglalja a kvótát, izolálja a bérlőket, állítsa sorba a megfelelő munkát, utasítsa el a rossz munkát, és alkalmazkodjon a szolgáltatói korlátok változásához.
Ez a cikk egy praktikus átjárókvóta-irányítót ír le olyan csapatok számára, amelyek termelési munkaterhelést küldenek több LLM-szolgáltatónak egy egységes API-n keresztül.
Az olvasó probléma: A 429-ek többdimenziósak
Sok csapat úgy kezeli a sebességkorlátokat, mintha egyetlen kérések percenkénti számként lennének. Ez a feltételezés gyorsan megtörik az LLM API-kkal.
Tények a jelenlegi szolgáltatói dokumentációból:
- Az OpenAI-dokumentumok, amelyek korlátai vannak, a meghirdetett percenkénti korlátnál rövidebb időtartamra érvényesíthetők, így a rövid sorozatok még akkor is meghiúsulhatnak, ha az átlagos perc biztonságosnak tűnik.
- Az Azure OpenAI-kvóta előfizetés, régió, modell és központi telepítési típus szerint van hozzárendelve percenkénti tokenben. A TPM-nek egy telepítéshez való hozzárendelése meghatározza a kényszerített következtetési RPM-korlátokat is, és az RPM-TPM arányok modellenként változnak.
- Az Azure OpenAI azt is megjegyzi, hogy a díjkorlátozási token számításait a rendszer a kérés beérkezésekor becsüli meg, és nem egyezik meg a végső számlázási tokenszámmal.
- Az antropikus dokumentumok különválasztják a percenkénti kérelmeket, a percenkénti bemeneti tokeneket és a percenkénti kimeneti tokeneket. A határértékek túllépése 429-et ad vissza egy újrapróbálkozás után fejléccel.
- Az Anthropic arra figyelmeztet, hogy a forgalom erőteljes növekedése elérheti a gyorsulási határokat, és fokozatos felfutást javasol.
- A legtöbb Claude-modell esetében a bemeneti tokeneket gyorsítótárazó Anthropic-dokumentumok nem számítanak bele a percenkénti bemeneti token-korlátokba, ami azt jelenti, hogy az azonnali gyorsítótárazás megváltoztathatja a tényleges mozgásteret.
- A Google Gemini API díjkorlátai a projekthasználati szintekhez vannak kötve, a magasabb szint pedig a számlázási beállításoktól, az összesített költéstől és a fizetési mérföldkövek után eltelt időtől függ.
A működési lecke egyértelmű: az OpenAI-kompatibilis kérésforma nem jelent OpenAI-kompatibilis kvótaviselkedést. A többszolgáltatós átjárónak olyan belső kvótamodellre van szüksége, amely gazdagabb, mint a „próbáld újra, ha 429”.
Tervezési cél: a beléptetés ellenőrzése átjáróvá tegye
A díjkorlátozást ismerő átjárónak öt kérdésre kell válaszolnia a kérés elküldése előtt:
- Melyik szolgáltató, modell, üzembe helyezés, régió, projekt vagy munkaterület fogja megkapni a kérést?
- Mekkora kérés, bemeneti token, kimeneti token és egyidejűségi kapacitást fogyaszthat?
- Melyik bérlőt, csapatot, API-kulcsot, ügyfelet vagy terhelési osztályt kell felszámítani a megosztott kapacitásért?
- A kérelmet most el kell fogadni, rövid ideig sorba kell helyezni, alacsonyabbra kell minősíteni, máshová kell irányítani vagy el kell utasítani?
- Hogyan kell egyeztetni a foglalást, miután a szolgáltató visszaküldi a tényleges használatot?
Az átjáró kvótakormányzóvá válik. Nem helyettesíti a szolgáltatói korlátokat. Láthatóvá, kiszámíthatóvá és igazságossá teszi a szolgáltatói korlátokat a saját rendszerén belül.
Hozzon létre normalizált kvótamodellt
Kezdje azzal, hogy meghatározza a belső korlátozó dimenziókat, amelyek képesek reprezentálni a főbb szolgáltatókat anélkül, hogy egy félrevezető gyűjtőkörbe kényszerítenék őket.
A határoló ajánlott méretei
- RPM: kérések percenként.
- Beviteli TPM: prompt, üzenet, eszköz és kontextus tokenek percenként.
- Kimeneti TPM: percenkénti befejezési tokenek, külön lefoglalva streamelés és hosszú generációk számára.
- Teljes TPM: olyan szolgáltatók vagy telepítések számára hasznos, amelyek kombinált tokennyomást tesznek ki.
- Pontosidő: aktív kérések, aktív adatfolyamok vagy repülés közbeni feladatok.
- Streamelés időtartama: a hosszú élettartamú adatfolyamok még alacsony RPM mellett is elfoglalhatják a csatlakozást és a kimeneti token szabad kapacitását.
- Szolgáltatóspecifikus hatókör: Azure-előfizetés/régió/telepítés, Antropikus munkaterület/modellosztály, Google-projekt/szint vagy OpenAI-szervezet/projekt/modellcsoport.
Ne rejtse el a szolgáltató-specifikus méreteket. Normalizálja őket egy közös sémává, de őrizzen meg elegendő részletet ahhoz, hogy később megmagyarázza az elutasítást.
{
"szolgáltató": "szolgáltató_a",
"model_profile": "gyors chat",
"provider_scope": {
"projekt": "termék",
"régió": "us-kelet",
"telepítés": "chat-large-01"
},
"korlátok": {
"rpm": 1200,
"input_tpm": 800000,
"output_tpm": 250000,
"egyidejűség": 200
}
}Ezt a belső objektumot explicit módon kell konfigurálni, nem csak a modellnevekből kell kikövetkeztetni. A szolgáltatói irányítópultok, a fiókszintek, a regionális telepítések és a munkaterület-beállítások mind megváltoztathatják ugyanazon modellcsalád tényleges kapacitását.
A tokennyomás becslése a feladás előtt
A szolgáltató oldali díjkorlátozás gyakran még azelőtt megtörténik, hogy a végső számlázási felhasználás ismertté válna. Az átjárónak ugyanilyen óvatos becslést kell végeznie a forgalom elküldése előtt.
Futtatás előtti foglalási bemenetek
- Sorozatos prompt és üzenet hossza.
- Modellspecifikus tokenizálás és többletfeltöltés szerepekhez, eszközökhöz, képekhez vagy strukturált kimeneti utasításokhoz.
max_completion_tokensvagy ezzel egyenértékű kimeneti korlát.- Ennek a végpontnak, a bérlőnek, a modellprofilnak és a kérési osztálynak a korábbi teljesítési aránya.
- A gyorsítótár-olvasási tokenek várható értékei, ha az azonnali gyorsítótár elérhető és mérhető.
- A streamelés jelzője és a közvetítés várható időtartama.
A kezdéshez gyakran elegendő egy egyszerű foglalási szabály:
estimated_input_tokens = tokenize(request_messages) + model_overhead
becsült_kimeneti_tokenek = min(
max_completion_tokens,
p95_historical_output_tokens_for_route
)
reserved_total_tokens = becsült_bemeneti_token + becsült_kimeneti_tokenIsmeretlen útvonalak esetén használjon konzervatív alapértelmezést. Stabil termelési útvonalak esetén a becsléseket folyamatosan frissítse a tényleges használat alapján.
Foglaljon le, majd egyeztetjen
A kvótafoglalások nem válhatnak állandó díjakká. Kezelje őket visszatartásként:
- Idézet: becsülje meg a bemeneti és kimeneti nyomást.
- Foglalás: feladás előtt vonja le a megfelelő token-gyűjteményekből.
- Elszámolás: cserélje ki a becslést a szolgáltató által jelentett használattal, ha elérhető.
- Visszatérítés vagy terhelés: szükség esetén a fel nem használt lefoglalt kapacitás visszaadása, vagy a túllépések felszámítása a következő időszakra.
Ez a legfontosabb a hosszú kontextusú és streaming hívások esetén. Ha csak a bemeneti TPM-et ellenőrzi a feladás előtt, egy adatfolyam sikeresen elindulhat, majd később kimeneti token nyomásba kerülhet. A kimeneti szabad tér külön lefoglalása csökkenti a közbenső meghibásodást és az elakadási kockázatot.
Használjon hierarchikus token-csoportokat a bérlői méltányosság érdekében
Egyetlen globális korlátozó védi a szolgáltatói fiókot, de nem védi a bérlőket egymástól. Egy hosszú kontextusú kötegelt munka felemésztheti a megosztott TPM-et, és a többi csapat interaktív kérései sikertelenséget okozhatnak.
Használjon hierarchikus tokencsoportokat:
szervezet
└── bérlő
└── csapat
└── api_key
└── modell_profil
└──szolgáltató_telepítésA kérésnek minden releváns csoporton át kell mennie. Ezzel egyszerre több irányelvet is érvényesíthet:
- A szervezet nem lépheti túl a szolgáltatói kapacitást.
- A bérlő nem fogyaszthat többet, mint a szerződésben foglalt részesedése.
- Egy API-kulcs nem haladhatja meg a tervezett környezet vagy alkalmazás korlátját.
- A kötegelt modellprofil nem tud kiéhezni egy interaktív modellprofilból.
- A szolgáltatói telepítést még akkor sem lehet túlterhelni, ha egy másik központi telepítésnek van tartalék kvótája.
Méltányos megosztás versus felhasználás
Javaslat: használjon súlyozott méltányos megosztást ellenőrzött sorozatfelvétellel.
A szigorú bérlőnkénti korlátok könnyen megmagyarázhatók, de a kihasználatlan kapacitást megterhelhetik. A sorozatos kölcsönzés javítja a kihasználtságot azáltal, hogy lehetővé teszi a bérlő számára, hogy ideiglenesen kihasználhassa a tétlen kvótát egy megosztott készletből. A kompromisszum az összetettség: az irányítópultoknak meg kell mutatniuk, hogy mire vállaltak garanciát, mit vettek fel kölcsön, és mikor vonták vissza a kölcsönt.
Gyakorlati szabály:
- Minden bérlőnek biztosítson egy garantált alapállapotot.
- Sorozatos kölcsönzés engedélyezése a fel nem használt megosztott kapacitásból.
- Ha magasabb prioritású vagy garantált forgalom jelenik meg, igényelje vissza a kölcsönzött kapacitást.
- Soha ne hagyja, hogy a kölcsönzött forgalom szolgáltatói szintű 429-eket hozzanak létre a garantált forgalom érdekében.
Válassza el a forgalmi osztályokat, mielőtt versengenek
Nem minden kérés érdemli meg ugyanazt a sor viselkedését. Helyezze a forgalmat modellprofilokba külön sorokkal és kvótakészletekkel.
A sorban állás javítja a sikerességi arányt, de növeli a farok késését. Az átjárónak ezt a kompromisszumot egyértelművé kell tennie. Például egy interaktív kérés akár 300 ezredmásodpercig is várhat a kvótára, majd visszaesik vagy meghiúsul. Előfordulhat, hogy az éjszakai kötegelt munka 20 percet vár, és továbbra is sikeresnek tekinthető.
A 429-ek normalizálása egyetlen hibasémává
A 429-es szolgáltató még jó beléptetési ellenőrzés mellett is előfordul. A korlátok változhatnak, a szolgáltató becslései eltérhetnek az Önétől, és a forgalom a vártnál élesebb sorozatokban érkezhet.
Minden szolgáltató 429 normalizálása átjáró hibaobjektummá:
{
"hiba": {
"type": "rate_limited",
"limiter": "output_tpm",
"szolgáltató": "szolgáltató_a",
"model_profile": "gyors chat",
"provider_model": "model-x",
"retry_after_ms": 2400,
"bérlő_azonosítója": "bérlő_123",
"api_key_id": "key_456",
"request_class": "interaktív",
"estimated_input_tokens": 4200,
"estimated_output_tokens": 800,
"gateway_decision": "admitted_then_provider_rejected",
"fallback_allowed": hamis,
"trace_id": "trace_abc"
}
}A kulcsmező a gateway_decision. A 429, miután az átjáró elfogadta a kérést, különbözik attól a kéréstől, amelyet az átjáró helyben utasított el a feladás előtt. Az első a korlátozó kalibrálási problémáját jelzi. A második a szándékos védelmet jelzi.
Alkalmazkodjon a szolgáltatói fejlécekből, de ne függjön tőlük
Egyes szolgáltatók hasznos fejléceket adnak vissza, például az újrapróbálkozás után vagy a fennmaradó kapacitás jelzőit. Ha elérhető, használja őket.
Javaslat: A szolgáltatói fejlécek hangolják a helyi kormányzót, ne cseréljék ki.
Ok:
- A fejléc elérhetősége szolgáltatónként és végpontonként eltérő.
- A fejlécek nem jeleníthetnek meg minden korlátozó dimenziót.
- Az újrapróbálkozás azt jelzi, hogy mikor kell újra próbálkozni, nem pedig azt, hogy melyik bérlő kapjon legközelebb kapacitást.
- A szolgáltató oldali token becslései eltérhetnek a számlázástól vagy a belső elszámolástól.
A robusztus megvalósítás a fejlécek alapján frissíti a helyi csoportok feltöltési arányát és lehűtését, miközben továbbra is érvényesíti a bérlői, API-kulcs, forgalmi osztály és szolgáltató telepítési korlátait az átjárón belül.
Rámpaszabályzók hozzáadása az áttelepítésekhez és az ütemezett feladatokhoz
Számos sebességkorlátozási esemény történik a tervezett változtatások során: egyik modellről a másikra való átállás, szolgáltatóváltás, új ügynöki munkafolyamat engedélyezése vagy ütemezett kiértékelés elindítása.
Javaslat: kezelje a forgalom növekedését ellenőrzött közzétételként.
- A funkciójelző modell migrációja bérlő, útvonal vagy a forgalom százalékos aránya szerint.
- Állítsa be a percenkénti növekedési plafont az új szolgáltatók telepítéséhez.
- Fokozatosan, órákon keresztül melegítse fel a forgalmat ahelyett, hogy az összes forgalmat azonnal átkapcsolná.
- A közzététel szüneteltetése, ha a 429-es arány, a leminősítési arány, a sormélység vagy a p95-késés átlép egy küszöböt.
- Tartson vészhelyzeti visszaállítási útvonalat kompatibilitási szabályzattal, ne csak tartalék modellel.
Előrejelzés: amint a szolgáltatói útválasztási módok, prioritási szintek és munkaterület-szintű vezérlők egyre gyakoribbá válnak, a felfutási irányítás szabványos átjárófunkcióvá válik, nem pedig incidens-válasz szkriptként.
A tartalék egy politikai döntés, nem csak kapacitásdöntés
Ha az egyik szolgáltató 429-et ad vissza, a másik szolgáltatóhoz való irányítás lehet a megfelelő válasz. Lehet, hogy nem is biztonságos.
A tartalék módosulhat:
- A kimenet minősége és a következő utasítások.
- Kontextus hossza.
- Eszközhívási viselkedés.
- Strukturált kimeneti megbízhatóság.
- Adatmegőrzés és tartózkodási hely.
- Költség és késleltetés.
A kvótaszabályzónak meg kell kérdeznie egy kompatibilitási réteget, hogy engedélyezett-e a tartalék erre a kérési osztályra. Ha nem, akkor sorba kell állnia vagy meghiúsulnia kell egyértelmű helyi sebességkorlát-válasz mellett, ahelyett, hogy csendesen megváltoztatná a szemantikát.
Kvóta-irányítópultok megjelenítése, amelyek elmagyarázzák a döntéseket
Azt a kvótarendszert, amelyet senki sem ért, megkerül. Építsen irányítópultokat a működési kérdések köré:
- Mely bérlők fogyasztják a legtöbb RPM-et, bemeneti TPM-et és kimeneti TPM-et?
- Mely modellprofilok állnak sorba, utasítják el vagy vonulnak vissza?
- Melyik szolgáltatói kör jelenti a szűk keresztmetszetet: projekt, régió, üzembe helyezés, munkaterület, modellosztály vagy fiókszint?
- Milyen gyakran térnek el az átjáró becslései a szolgáltató használatától?
- Mi az újrapróbálkozás utáni elosztás szolgáltató és korlátozó típusa szerint?
- Mennyire hatékony mozgásteret teremtenek a gyorsítótár-olvasások?
- Mely forgalmi osztályok kölcsönöznek sorozatkapacitást?
Az ügyfeleknek vagy partnereknek szánt termékeknél tegye ki a biztonságos kezelőszerveket:
- Kulcsonkénti díjkorlátok.
- csapatonkénti sorozatfelvételi korlátok.
- Ügyfelenkénti napi korlát.
- Vészszünet bérlő vagy kulcs esetén.
- Figyelmeztetések 429 kiugrásról, sornövekedésről és abnormális tokennyomásról.
- Partner API-végpontok a viszonteladói kvótakezeléshez.
Ezáltal a sebességkorlátozás egy rejtélyes szolgáltatói hibából a csapat API-irányításának auditálható részévé válik.
Megvalósítási ellenőrzőlista
1. fázis: megfigyelés és osztályozás
- Minden híváshoz naplózza a szolgáltatót, a modellt, a telepítést, a régiót, a munkaterületet, a projektet, a bérlőt, az API-kulcsot és a kérési osztályt.
- Rögzítse a 429-es szolgáltatókat az újrapróbálkozás után és a nyers hiba metaadatokkal.
- A becsült és a tényleges bemeneti/kimeneti tokeneket külön rögzítse.
- Elkülönítheti az interaktív, kötegelt, értékelő és háttérforgalmat a telemetriában.
2. fázis: helyi beléptetés ellenőrzése
- Hozzon létre belső korlátozó objektumokat az RPM-hez, a bemeneti TPM-hez, a kimeneti TPM-hez, a teljes TPM-hez és a párhuzamossághoz.
- Adja hozzá a vizsgálat előtti token becslését.
- Foglaljon le kvótát a feladás előtt, és egyezzen a szolgáltatói használat megérkezése után.
- Lokális elutasítás, ha egy kérelem nem fér bele a bérlői vagy szolgáltatói csoportba.
3. fázis: méltányosság és sorok
- Hozzáadhat hierarchikus gyűjtőcsoportokat a szervezettől a szolgáltatói telepítésig.
- Garantált bérlői részesedés hozzárendelése és szabályozott sorozatú kölcsönfelvétel.
- Hozzon létre külön sorokat forgalmi osztályok szerint.
- Állítsa be az osztályspecifikus maximális várakozási időt és a tartalék szabályokat.
4. fázis: adaptáció és műveletek
- Használja a szolgáltató fejléceit a lehűlés és az utántöltési feltételezések beállításához.
- Adjon hozzá rámpavezérlőket az áttelepítésekhez és az ütemezett feladatokhoz.
- Kvóta-irányítópultok és figyelmeztetések megjelenítése.
- Hetente tekintse át a becslési hibát és az elakadt kvótát.
Intézhető következtetés
Ha az átjáró csak a 429 másodpercet próbálja újra, a hiba után működik. Az éles szintű AI API-átjárónak meg kell akadályoznia a legtöbb sebességkorlátozási hibát azáltal, hogy eldönti, ki mit küldhet, mikor és melyik szolgáltatói kvótával szemben.
Kezdje egy normalizált korlátozó modellel, a repülés előtti jogkivonat-foglalással és a forgalmi osztályok soraival. Ezután adja hozzá a hierarchikus bérlői méltányosságot, a szolgáltató-fejléc adaptációt és a rámpaszabályzókat. Az eredmény nem csak kevesebb 429 másodperc. A mérnöki, pénzügyi és ügyféltámogatási csapatok tisztább kapacitáselosztást, kiszámíthatóbb késleltetést, biztonságosabb migrációt és sebességkorlátozási viselkedést tudnak megmagyarázni.