Brány rozhraní API pro umělou inteligenci s ohledem na rychlost: RPM tvaru, TPM, shluky a férovost nájemců před zásahem 429 s

Číslo 429 od poskytovatele LLM není jen signál opakování. V produkci je to často důkaz, že vaše aplikace již ztratila kontrolu nad přístupem, spravedlností nájemců, latencí nebo účtováním kvót specifických pro poskytovatele.

Obvyklá oprava – exponenciální ústup – je nezbytná, ale neúplná. Backoff reaguje poté, co poskytovatel odmítne provoz. Brána AI API s ohledem na rychlostní limit by měla ovlivňovat provoz předtím, než požadavky opustí váš systém: odhadnout tlak tokenů, rezervovat kvótu, izolovat nájemce, zařadit do fronty správnou práci, odmítnout nesprávnou práci a přizpůsobit se, když se změní limity poskytovatele.

Tento článek popisuje praktického správce kvót brány pro týmy odesílající produkční úlohy více poskytovatelům LLM prostřednictvím jednotného rozhraní API.

Problém čtenáře: 429 jsou vícerozměrné

Mnoho týmů zachází s limity sazeb, jako by šlo o jeden počet požadavků za minutu. Tento předpoklad se s LLM API rychle rozbije.

Fakta z aktuální dokumentace poskytovatele:

• Dokumenty OpenAI, jejichž limity mohou být vynucovány v kratších oknech, než je inzerovaný limit za minutu, takže krátké dávky mohou selhat, i když průměrná minuta vypadá bezpečně.
• Kvóta Azure OpenAI je přiřazena podle předplatného, oblasti, modelu a typu nasazení v tokenech za minutu. Přiřazení TPM k nasazení také určuje vynucené limity RPM a poměry RPM k TPM se liší podle modelu.
• Azure OpenAI také poznamenává, že výpočty limitu tokenů se odhadují, když je požadavek přijat, a nejsou stejné jako konečný počet fakturačních tokenů.
• Antropické dokumenty oddělují limity požadavků za minutu, vstupních tokenů za minutu a výstupních tokenů za minutu. Překročení limitů vrátí 429 s retry-after hlavičkou.
• Anthropic varuje, že prudký nárůst provozu může narazit na limity zrychlení, a doporučuje postupné navyšování.
• U většiny modelů Claude, Antropické dokumenty, které vstupní tokeny čtení z mezipaměti nezapočítávají do limitů vstupních tokenů za minutu, což znamená, že rychlé ukládání do mezipaměti může změnit efektivní prostor.
• Limity sazeb Google Gemini API jsou vázány na úrovně využití projektu, přičemž vyšší úrovně závisí na nastavení fakturace, kumulativní útratě a době, která uplynula po milnících plateb.

Provozní poučení je jasné: tvar požadavku kompatibilní s OpenAI neznamená chování kvót kompatibilní s OpenAI. Brána pro více poskytovatelů potřebuje model interní kvóty, který je bohatší než „opakovat, pokud 429“.

Cíl návrhu: učinit z řízení přístupu odpovědnost brány

Brána s ohledem na rychlostní limit by měla před odesláním požadavku zodpovědět pět otázek:

1. Který poskytovatel, model, nasazení, region, projekt nebo pracovní prostor obdrží žádost?
2. Kolik požadavku, vstupního tokenu, výstupního tokenu a souběžné kapacity může spotřebovat?
3. Který tenant, tým, klíč API, zákazník nebo třída zátěže by měla být účtována ze sdílené kapacity?
4. Měl by být požadavek nyní přijat, krátce zařazen do fronty, převeden na nižší verzi, směrován jinam nebo zamítnut?
5. Jak by měla být rezervace odsouhlasena poté, co poskytovatel vrátí skutečné využití?

Brána se stane správcem kvót. Nenahrazuje limity poskytovatele. Díky tomu jsou limity poskytovatelů viditelné, předvídatelné a spravedlivé ve vašem vlastním systému.

Vytvoření normalizovaného modelu kvót

Začněte definováním vnitřních omezovacích rozměrů, které mohou reprezentovat hlavní poskytovatele, aniž byste je nutili do jednoho zavádějícího segmentu.

Doporučené rozměry omezovače

• RPM: požadavky za minutu.
• Vstupní TPM: tokeny výzvy, zprávy, nástroje a kontextu za minutu.
• Výstupní TPM: tokeny dokončení za minutu, vyhrazené zvlášť pro streamování a dlouhé generace.
• Celkový TPM: užitečné pro poskytovatele nebo nasazení, která vystavují kombinovaný tlak tokenů.
• Souběh: aktivní požadavky, aktivní streamy nebo úlohy za letu.
• Délka streamování: dlouhotrvající streamy mohou zabírat prostor pro připojení a výstupní token, i když jsou otáčky nízké.
• Rozsah specifický pro poskytovatele: Předplatné/oblast/nasazení Azure, pracovní prostor/třída modelu Antropický, projekt/vrstva Google nebo organizace/projekt/modelová skupina OpenAI.

Neskrývejte dimenze specifické pro poskytovatele. Normalizujte je do společného schématu, ale zachovejte dostatek podrobností, aby bylo možné později vysvětlit odmítnutí.

{
  "provider": "poskytovatel_a",
  "model_profile": "rychlý chat",
  "provider_scope": {
    "project": "prod",
    "region": "us-východ",
    "deployment": "chat-large-01"
  },
  "limity": {
    "ot./min": 1200,
    "input_tpm": 800 000,
    "output_tpm": 250 000,
    "souběh": 200
  }
}

Tento interní objekt by měl být nakonfigurován explicitně, nikoli odvozen pouze z názvů modelů. Řídicí panely poskytovatelů, úrovně účtů, regionální nasazení a nastavení pracovního prostoru mohou změnit efektivní kapacitu stejné rodiny modelů.

Před odesláním odhadněte tlak tokenu

K omezení sazeb na straně poskytovatele často dochází ještě předtím, než je známo konečné využití fakturace. Vaše brána by měla před odesláním provozu provést stejný konzervativní odhad.

Vstupy předletové rezervace

• Serializovaná výzva a délka zprávy.
• Tokenizace specifická pro model a režie pro role, nástroje, obrázky nebo pokyny pro strukturovaný výstup.
• max_completion_tokens nebo ekvivalentní omezení výstupu.
• Historický poměr dokončení pro tento koncový bod, tenanta, profil modelu a třídu požadavků.
• Očekávané tokeny čtení z mezipaměti, pokud je rychlé ukládání do mezipaměti dostupné a měřitelné.
• Příznak streamování a očekávaná délka streamu.

Pro začátek často stačí jednoduché pravidlo rezervace:

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

Pro neznámé trasy použijte konzervativní výchozí nastavení. U stabilních produkčních tras průběžně aktualizujte odhady ze skutečného využití.

Rezervujte a poté odsouhlaste

Rezervace kvót by se neměly stát trvalými poplatky. Zacházejte s nimi jako s držadlem:

1. Citace: odhad vstupního a výstupního tlaku.
2. Rezerva: před odesláním odečtete z příslušných skupin tokenů.
3. Vyrovnat: nahraďte odhad používáním nahlášeným poskytovatelem, bude-li k dispozici.
4. Vrácení peněz nebo debet: v případě potřeby vraťte nevyužitou rezervovanou kapacitu nebo naúčtovejte přebytky do dalšího okna.

To je nejdůležitější u hovorů s dlouhým kontextem a streamování. Pokud před odesláním zkontrolujete pouze vstupní TPM, stream se může úspěšně spustit a později naběhnout na tlak výstupního tokenu. Samostatné vyhrazení výstupního prostoru snižuje riziko selhání a zablokování středního proudu.

Používejte hierarchické skupiny tokenů pro spravedlivost nájemců

Jediný globální omezovač chrání účet poskytovatele, ale nechrání tenanty před sebou navzájem. Jedna dávková úloha s dlouhým kontextem může spotřebovat sdílený modul TPM a způsobit selhání interaktivních požadavků jiných týmů.

Používejte hierarchické skupiny tokenů:

organizace
  └── nájemce
      └── tým
          └── api_key
              └── profil_modelu
                  └── provider_deployment

Požadavek musí projít každým relevantním segmentem. To vám umožní vynutit několik zásad najednou:

• Organizace nemůže překročit kapacitu poskytovatele.
• Nájemník nemůže spotřebovat více, než je jeho smluvní podíl.
• Klíč API nesmí překročit zamýšlený limit prostředí nebo aplikace.
• Profil dávkového modelu nemůže vyhladovět profil interaktivního modelu.
• Nasazení poskytovatele nemůže být přetíženo, i když má jiné nasazení náhradní kvótu.

Spravedlivé sdílení versus využití

Doporučení: použijte vážené spravedlivé sdílení s řízeným shlukovým výpůjčkami.

Přísné limity pro jednotlivé nájemce se snadno vysvětlují, ale mohou narušit nevyužitou kapacitu. Nárazové půjčování zlepšuje využití tím, že tenantovi umožňuje dočasně používat nečinnou kvótu ze sdíleného fondu. Kompromisem je složitost: řídicí panely musí ukazovat, co bylo zaručeno, co bylo vypůjčeno a kdy bylo vypůjčení odvoláno.

Praktické pravidlo:

• Poskytněte každému nájemníkovi zaručený základ.
• Povolit nárazové půjčování z nevyužité sdílené kapacity.
• Získejte zpět vypůjčenou kapacitu, když se objeví provoz s vyšší prioritou nebo zaručený provoz.
• Nikdy nedovolte, aby vypůjčený provoz vytvořil 429 na úrovni poskytovatele pro zaručený provoz.

Oddělte třídy provozu, než se utkají

Ne všechny požadavky si zaslouží stejné chování ve frontě. Umístěte provoz do modelových profilů se samostatnými frontami a fondy kvót.

{
  "chyba": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "poskytovatel_a",
    "model_profile": "rychlý chat",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interaktivní",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": nepravda,
    "trace_id": "trace_abc"
  }
}