Brány AI API s vedomím rýchlosti: RPM tvaru, TPM, zhluky a férovosť nájomníkov pred dosiahnutím 429 s

Číslo 429 od poskytovateľa LLM nie je len signál na opätovný pokus. V produkcii je to často dôkaz, že vaša aplikácia už stratila kontrolu nad prístupom, spravodlivosťou nájomníkov, latenciou alebo účtovaním kvót špecifických pre poskytovateľa.

Spoločná oprava – exponenciálne ustupovanie – je potrebná, ale nie je úplná. Backoff reaguje potom, čo poskytovateľ odmietne prenos. Brána AI API zohľadňujúca rýchlosť by mala ovplyvniť návštevnosť predtým, ako požiadavky opustia váš systém: odhadnúť tlak tokenov, rezervovať kvótu, izolovať nájomníkov, zaradiť do frontu správnu prácu, odmietnuť nesprávnu prácu a prispôsobiť sa zmenám limitov poskytovateľa.

Tento článok popisuje praktického správcu kvót brány pre tímy, ktoré odosielajú produkčné úlohy viacerým poskytovateľom LLM prostredníctvom jednotného rozhrania API.

Problém čitateľa: 429 sú viacrozmerné

Mnoho tímov zaobchádza s limitmi sadzieb, ako keby išlo o jeden počet žiadostí za minútu. Tento predpoklad sa s LLM API rýchlo rozbije.

Fakty z aktuálnej dokumentácie poskytovateľa:

• Dokumenty OpenAI, ktorých limity môžu byť presadzované počas kratších období, než je inzerovaný limit za minútu, takže krátke série môžu zlyhať, aj keď priemerná minúta vyzerá bezpečne.
• Kvóta Azure OpenAI sa prideľuje podľa predplatného, regiónu, modelu a typu nasadenia v tokenoch za minútu. Priradenie TPM k nasadeniu tiež určuje vynútené limity RPM a pomery RPM k TPM sa líšia podľa modelu.
• Azure OpenAI tiež poznamenáva, že výpočty limitov sadzby sa odhadujú pri prijatí požiadavky a nie sú rovnaké ako konečné počty fakturačných tokenov.
• Antropické dokumenty oddeľujú limity žiadostí za minútu, vstupných tokenov za minútu a výstupných tokenov za minútu. Prekročenie limitov vráti 429 s hlavičkou opakovania.
• Anthropic varuje, že prudký nárast premávky môže naraziť na limity zrýchlenia, a odporúča postupné zvyšovanie.
• V prípade väčšiny modelov Claude sa antropické dokumenty, ktoré vstupné tokeny na čítanie z vyrovnávacej pamäte nezapočítavajú do limitov vstupných tokenov za minútu, čo znamená, že rýchle ukladanie do vyrovnávacej pamäte môže zmeniť efektívnu rezervu.
• Limity sadzieb rozhrania Google Gemini API sú viazané na úrovne využitia projektu, pričom vyššie úrovne závisia od nastavenia fakturácie, kumulatívnych výdavkov a uplynutého času po míľnikoch platieb.

Prevádzková lekcia je jasná: tvar požiadavky kompatibilný s OpenAI neznamená správanie kvóty kompatibilné s OpenAI. Brána viacerých poskytovateľov potrebuje interný model kvót, ktorý je bohatší ako „opakovať, ak 429“.

Cieľ dizajnu: urobiť z kontroly prístupu zodpovednosť brány

Brána zohľadňujúca rýchlostné limity by mala pred odoslaním žiadosti odpovedať na päť otázok:

1. Ktorý poskytovateľ, model, nasadenie, región, projekt alebo pracovný priestor dostane žiadosť?
2. Koľko požiadavky, vstupného tokenu, výstupného tokenu a súbežnej kapacity môže spotrebovať?
3. Ktorý nájomník, tím, kľúč API, zákazník alebo trieda pracovného zaťaženia by sa mali účtovať na základe zdieľanej kapacity?
4. Mala by byť žiadosť teraz prijatá, krátko zaradená do frontu, znížená úroveň, presmerovaná inam alebo zamietnutá?
5. Ako by sa mala rezervácia zosúladiť potom, čo poskytovateľ vráti skutočné využitie?

Brána sa stane správcom kvót. Nenahrádza limity poskytovateľa. Vďaka tomu sú limity poskytovateľa viditeľné, predvídateľné a spravodlivé vo vašom vlastnom systéme.

Vytvorte normalizovaný model kvót

Začnite definovaním interných rozmerov obmedzovačov, ktoré môžu reprezentovať hlavných poskytovateľov bez toho, aby ste ich nútili do jedného zavádzajúceho segmentu.

Odporúčané rozmery obmedzovačov

• RPM: požiadavky za minútu.
• Vstup TPM: tokeny výzvy, správy, nástroja a kontextu za minútu.
• Výstupné TPM: tokeny dokončenia za minútu, vyhradené samostatne pre streamovanie a dlhé generácie.
• Celkový TPM: užitočné pre poskytovateľov alebo nasadenia, ktoré vystavujú kombinovaný tlak tokenov.
• Súbežnosť: aktívne požiadavky, aktívne streamy alebo úlohy počas letu.
• Trvanie streamovania: streamy s dlhou životnosťou môžu zaberať priestor na pripojenie a výstupný token, aj keď sú otáčky nízke.
• Rozsah špecifický pre poskytovateľa: Predplatné/región/nasadenie Azure, antropický pracovný priestor/trieda modelu, projekt/vrstva Google alebo organizácia/projekt/modelová skupina OpenAI.

Neskrývajte dimenzie špecifické pre poskytovateľa. Normalizujte ich do spoločnej schémy, ale zachovajte dostatok podrobností na to, aby ste mohli neskôr vysvetliť odmietnutie.

{
  "provider": "poskytovateľ_a",
  "model_profile": "rýchly rozhovor",
  "provider_scope": {
    "project": "prod",
    "región": "us-východ",
    "deployment": "chat-large-01"
  },
  "limity": {
    "rpm": 1200,
    "input_tpm": 800 000,
    "output_tpm": 250 000,
    "súbežnosť": 200
  }
}

Tento interný objekt by mal byť nakonfigurovaný explicitne a nemal by byť odvodený iba z názvov modelov. Panely poskytovateľa, úrovne účtov, regionálne nasadenia a nastavenia pracovného priestoru môžu zmeniť efektívnu kapacitu rovnakej rodiny modelov.

Odhadnite tlak tokenu pred odoslaním

K obmedzeniu sadzieb na strane poskytovateľa často dochádza ešte predtým, ako je známe konečné využitie fakturácie. Vaša brána by mala pred odoslaním návštevnosti vykonať rovnaký druh konzervatívneho odhadu.

Vstupy predletovej rezervácie

• Serializovaná výzva a dĺžka správy.
• Tokenizácia špecifická pre model a režijné náklady pre roly, nástroje, obrázky alebo pokyny pre štruktúrovaný výstup.
• max_completion_tokens alebo ekvivalentný limit výstupu.
• Historický pomer dokončenia pre tento koncový bod, nájomníka, profil modelu a triedu požiadaviek.
• Očakávané tokeny čítania z vyrovnávacej pamäte, ak je rýchle ukladanie do vyrovnávacej pamäte dostupné a merateľné.
• Príznak streamovania a očakávané trvanie streamu.

Na začiatok často stačí jednoduché pravidlo rezervácie:

estimated_input_tokens = tokenize(request_messages) + model_overhead
odhadované_výstupné_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
Reserved_total_tokens = odhadované_vstupné_tokeny + odhadované_výstupné_tokeny

Pre neznáme trasy použite konzervatívne predvolené nastavenie. V prípade stabilných produkčných trás priebežne aktualizujte odhady zo skutočného používania.

Rezervujte, potom zosúlaďte

Rezervácie kvóty by sa nemali stať trvalými poplatkami. Zaobchádzajte s nimi ako s držaním:

1. Citácia: odhadnite vstupný a výstupný tlak.
2. Rezerva: pred odoslaním odpočítajte z príslušných skupín tokenov.
3. Vyrovnať: nahraďte odhad použitím nahláseným poskytovateľom, keď bude k dispozícii.
4. Vrátenie peňazí alebo debet: v prípade potreby vráťte nevyužitú rezervovanú kapacitu alebo účtujte prekročenia do ďalšieho okna.

To je najdôležitejšie pri hovoroch s dlhým kontextom a streamovaných hovoroch. Ak pred odoslaním skontrolujete iba vstupné TPM, stream sa môže úspešne spustiť a neskôr sa môže spustiť tlak výstupného tokenu. Samostatné rezervovanie priestoru na výstupe znižuje riziko zlyhania a zaseknutia v strednom prúde.

Používajte hierarchické skupiny tokenov pre spravodlivosť nájomníkov

Jeden globálny obmedzovač chráni účet poskytovateľa, ale nechráni nájomníkov navzájom. Jedna dávková úloha s dlhým kontextom môže spotrebovať zdieľaný modul TPM a spôsobiť zlyhanie interaktívnych požiadaviek iných tímov.

Použite hierarchické skupiny tokenov:

organizácia
  └── nájomca
      └── tím
          └── api_key
              └── profil_modelu
                  └── nasadenie_poskytovateľa

Žiadosť musí prejsť každým relevantným segmentom. To vám umožní presadzovať niekoľko pravidiel naraz:

• Organizácia nemôže prekročiť kapacitu poskytovateľa.
• Nájomca nemôže spotrebovať viac, než je jeho zmluvný podiel.
• Kľúč API nemôže prekročiť limit prostredia alebo aplikácie.
• Profil dávkového modelu nemôže vyhladzovať profil interaktívneho modelu.
• Nasadenie poskytovateľa nemôže byť preťažené, aj keď iné nasadenie má rezervnú kvótu.

Spravodlivé zdieľanie verzus využitie

Odporúčanie: používajte vážené spravodlivé zdieľanie s riadeným nárazovým požičiavaním.

Prísne obmedzenia na jedného nájomníka sa dajú ľahko vysvetliť, ale môžu spôsobiť stratu nevyužitej kapacity. Nárazové požičiavanie zlepšuje využitie tým, že umožňuje nájomcovi dočasne využívať nečinnú kvótu zo zdieľaného fondu. Kompromisom je zložitosť: informačné panely musia zobrazovať, čo bolo zaručené, čo bolo požičané a kedy bolo požičanie odvolané.

Praktické pravidlo:

• Poskytnite každému nájomníkovi zaručený základ.
• Povoliť hromadné pôžičky z nevyužitej zdieľanej kapacity.
• Získajte späť vypožičanú kapacitu, keď sa objaví návštevnosť s vyššou prioritou alebo zaručenou návštevnosťou.
• Nikdy nedovoľte, aby vypožičaná návštevnosť vytvárala 429 na úrovni poskytovateľa pre zaručenú návštevnosť.

Oddeľte triedy premávky skôr, ako budú bojovať

Nie všetky požiadavky si zaslúžia rovnaké správanie v poradí. Vložte návštevnosť do modelových profilov so samostatnými frontami a kvótami.

{
  "chyba": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "poskytovateľ_a",
    "model_profile": "rýchly rozhovor",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interaktívne",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": nepravda,
    "trace_id": "trace_abc"
  }
}