AI API шлюзове, съобразени с ограничение на скоростта: Оформете RPM, TPM, Bursts и Tenant Fairness преди 429s Hit

429 от доставчик на LLM не е просто сигнал за повторен опит. В производството често е доказателство, че вашето приложение вече е загубило контрол върху допускането, справедливостта на наемателя, закъснението или отчитането на квотата, специфично за доставчика.

Общата корекция — експоненциално забавяне — е необходима, но непълна. Backoff реагира, след като доставчикът отхвърли трафика. AI API шлюз, съобразен с ограничение на скоростта, трябва да оформи трафика, преди заявките да напуснат вашата система: да оцени натиска на токена, да резервира квота, да изолира наемателите, да постави на опашка правилната работа, да отхвърли грешната работа и да се адаптира, когато ограниченията на доставчика се променят.

Тази статия описва практически регулатор на квота за шлюз за екипи, изпращащи производствени натоварвания към множество доставчици на LLM чрез унифициран API.

Проблемът с четеца: 429s са многоизмерни

Много екипи третират ограниченията на скоростта като че ли са едно число заявки на минута. Това предположение се разваля бързо с API на LLM.

Факти от текущата документация на доставчика:

• OpenAI документи, че ограниченията могат да бъдат наложени за по-кратки прозорци от рекламираното ограничение за минута, така че кратките серии могат да се провалят дори когато средната минута изглежда безопасна.
• Azure OpenAI квотата се определя по абонамент, регион, модел и тип на внедряване в токени на минута. Присвояването на TPM на внедряване също така определя ограниченията за RPM на принудително извеждане, а съотношенията RPM към TPM варират според модела.
• Azure OpenAI също така отбелязва, че изчисленията на токените за ограничение на скоростта се изчисляват при получаване на заявката и не са същите като крайните токени за таксуване.
• Anthropic документира отделни ограничения за заявки на минута, входни жетони на минута и изходни жетони на минута. Превишаването на ограниченията връща 429 със заглавка за повторен опит.
• Anthropic предупреждава, че рязкото увеличаване на трафика може да достигне ограниченията на ускорението и препоръчва постепенно увеличаване.
• За повечето Claude модели, Anthropic документи, които кешират входни жетони за четене, не се броят към лимитите за входни жетони на минута, което означава, че бързото кеширане може да промени ефективния резерв.
• Google Gemini API лимитите на скоростта са обвързани с нивата на използване на проекта, като по-високите нива зависят от настройката на таксуването, кумулативните разходи и изминалото време след основните етапи на плащането.

Оперативният урок е ясен: OpenAI-съвместима форма на заявка не предполага OpenAI-съвместимо поведение на квоти. Шлюзът с множество доставчици се нуждае от вътрешен квотен модел, който е по-богат от „опитайте отново, ако 429“.

Цел на дизайна: направете контрола на достъпа отговорност на портала

Шлюз, запознат с ограничение на скоростта, трябва да отговори на пет въпроса, преди да изпрати заявка:

1. Кой доставчик, модел, внедряване, регион, проект или работно пространство ще получи заявката?
2. Колко заявка, входен токен, изходен токен и капацитет за едновременност може да изразходва?
3. Кой наемател, екип, API ключ, клиент или клас на работно натоварване трябва да бъдат таксувани от споделения капацитет?
4. Трябва ли заявката да бъде приета сега, да бъде поставена на опашка за кратко, да бъде понижена, насочена другаде или отхвърлена?
5. Как трябва да се съгласува резервацията, след като доставчикът върне действителното използване?

Шлюзът става регулатор на квота. Не замества ограниченията на доставчика. Това прави ограниченията на доставчика видими, предвидими и справедливи във вашата собствена система.

Създаване на нормализиран квотен модел

Започнете с дефиниране на вътрешни ограничителни размери, които могат да представят основните доставчици, без да ги принуждават към една подвеждаща кофа.

Препоръчителни размери на ограничителя

• RPM: заявки в минута.
• Входен TPM: подкана, съобщение, инструмент и контекстни токени на минута.
• Изходен TPM: токени за завършване на минута, запазени отделно за поточно предаване и дълги поколения.
• Общо TPM: полезно за доставчици или внедрявания, които излагат комбиниран натиск върху токени.
• Едновременност: активни заявки, активни потоци или задания по време на полет.
• Продължителност на поточно предаване: дълготрайните потоци могат да заемат пространство за свързване и изходящ токен дори когато RPM е нисък.
• Специфичен обхват на доставчика: Абонамент/регион/внедряване на Azure, Anthropic работно пространство/клас на модела, Google проект/ниво или OpenAI организация/проект/моделна група.

Не скривайте измерения, специфични за доставчика. Нормализирайте ги в обща схема, но запазете достатъчно подробности, за да обясните отхвърлянето по-късно.

{
  "provider": "provider_a",
  "model_profile": "fast-chat",
  "provider_scope": {
    "project": "prod",
    "region": "us-east",
    "deployment": "chat-large-01"
  },
  "limits": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "concurrency": 200
  }
}

Този вътрешен обект трябва да бъде конфигуриран изрично, а не да се извежда само от имена на модели. Таблата за управление на доставчици, нивата на акаунти, регионалните внедрявания и настройките на работното пространство могат да променят ефективния капацитет на едно и също семейство модели.

Оценете налягането на токена преди изпращане

Ограничаването на тарифите от страна на доставчика често се случва, преди да е известно окончателното използване на таксуването. Вашият шлюз трябва да направи същия вид консервативна оценка, преди да изпрати трафик.

Входни данни за предполетна резервация

• Сериализирана подкана и дължина на съобщението.
• Специфично за модела токенизиране и допълнителни разходи за роли, инструменти, изображения или инструкции за структуриран изход.
• max_completion_tokens или еквивалентно ограничение на изхода.
• Исторически коефициент на изпълнение за тази крайна точка, клиент, профил на модел и клас на заявка.
• Очаквани токени за четене на кеша, ако е налично и измеримо бързото кеширане.
• Флаг за поточно предаване и очаквана продължителност на потока.

Често е достатъчно просто правило за резервация, за да започнете:

estimated_input_tokens = tokenize(request_messages) + model_overhead
estimated_output_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reserved_total_tokens = estimated_input_tokens + estimated_output_tokens

За неизвестни маршрути използвайте консервативна стойност по подразбиране. За стабилни производствени маршрути, актуализирайте прогнозите непрекъснато от действителното използване.

Резервирайте, след това съгласувайте

Резервациите за квоти не трябва да се превръщат в постоянни такси. Отнасяйте се към тях като към задържане:

1. Цитат: изчислете входното и изходното налягане.
2. Резерв: приспадане от съответните жетонни кофи преди изпращане.
3. Уреждане: заменете прогнозата с докладваното от доставчика използване, когато е налично.
4. Възстановяване или дебитиране: връщане на неизползван резервиран капацитет или таксуване на излишъци към следващия прозорец, ако е необходимо.

Това е от най-голямо значение за повиквания с дълъг контекст и поточно предаване. Ако проверите само входен TPM преди изпращане, потокът може да стартира успешно и след това да се сблъска с натиска на изходен токен по-късно. Резервирането на изходна височина отделно намалява повредата по средата на потока и риска от спиране.

Използване на йерархични кофи с токени за справедливост на наемателя

Един глобален ограничител защитава акаунта на доставчика, но не защитава наемателите един от друг. Едно пакетно задание с дълъг контекст може да изразходва споделен TPM и да причини неуспех на интерактивни заявки от други екипи.

Използване на йерархични кофи с токени:

organization
  └── tenant
      └── team
          └── api_key
              └── model_profile
                  └── provider_deployment

Заявката трябва да премине всяка подходяща група. Това ви позволява да наложите няколко правила наведнъж:

• Организацията не може да надхвърля капацитета на доставчика.
• Наемателят не може да консумира повече от своя договорен дял.
• Ключ API не може да надхвърли ограничението за предвидената среда или приложение.
• Профил на партиден модел не може да изглади профил на интерактивен модел.
• Внедряване на доставчик не може да бъде претоварено дори ако друго внедряване има свободна квота.

Справедливо споделяне срещу използване

Препоръка: използвайте претеглено справедливо споделяне с контролирано пакетно заемане.

Строгите ограничения за всеки наемател са лесни за обяснение, но могат да блокират неизползвания капацитет. Бурното заемане подобрява използването, като позволява на наемателя да използва временно неактивна квота от споделен пул. Компромисът е сложността: таблата за управление трябва да показват какво е гарантирано, какво е взето назаем и кога заемането е отменено.

Практическо правило:

• Дайте на всеки наемател гарантирана базова линия.
• Разрешаване на пакетно заемане от неизползван споделен капацитет.
• Възстановете заетия капацитет, когато се появи трафик с по-висок приоритет или гарантиран.
• Никога не позволявайте на зает трафик да създава 429 на ниво доставчик за гарантиран трафик.

Разделете класовете трафик, преди да се борят

Не всички заявки заслужават едно и също поведение на опашка. Поставете трафик в профили на модела с отделни опашки и пулове от квоти.

Поставянето на опашка подобрява процента на успех, но увеличава латентността на опашката. Шлюзът трябва да направи този компромис ясен. Например, интерактивна заявка може да изчака до 300 милисекунди за квота, след което да отпадне или да се провали. Нощна пакетна работа може да изчака 20 минути и пак да се счита за успешна.

Нормализиране на 429s в една схема за грешка

Дори при добър контрол на допускането, 429 на доставчика все още ще се появяват. Ограниченията могат да се променят, оценките на доставчика може да се различават от вашите и трафикът може да пристига в по-резки изблици от очакваното.

Нормализиране на всеки доставчик 429 в обект за грешка на шлюза:

{
  "error": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "fast-chat",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interactive",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": false,
    "trace_id": "trace_abc"
  }
}

Ключовото поле е gateway_decision. 429, след като шлюзът приеме заявката, е различен от заявката, която шлюзът е отхвърлил локално преди изпращане. Първият показва проблем с калибрирането на ограничителя. Второто показва умишлена защита.

Адаптирайте се от заглавките на доставчика, но не зависете от тях

Някои доставчици връщат полезни заглавки, като индикатори за повторен опит или оставащ капацитет. Използвайте ги, когато са налични.

Препоръка: хедърите на доставчика трябва да настройват вашия местен управител, а не да го заменят.

Причини:

• Наличността на заглавката се различава според доставчика и крайната точка.
• Заглавките може да не показват всяко измерение на ограничител.
• Retry-after ви казва кога да опитате отново, а не кой наемател следва да получи капацитет.
• Прогнозите за токени от страна на доставчика може да се различават от вашето таксуване или вътрешно счетоводство.

Стабилното внедряване актуализира местните нива на зареждане на кофи и времена на охлаждане въз основа на заглавки, като същевременно налага ограничения за клиент, API ключ, клас на трафик и разгръщане на доставчик вътре в шлюза.

Добавете регулатори на рампи за миграции и планирани задания

Много инциденти с ограничение на скоростта се случват по време на планирани промени: преминаване от един модел към друг, смяна на доставчици, активиране на нов работен процес на агент или стартиране на планирано изпълнение на оценка.

Препоръка: третирайте нарастването на трафика като контролирано внедряване.

• Миграции на модела с флаг на функция по клиент, маршрут или процент от трафика.
• Задаване на тавани за растеж на минута за внедряване на нови доставчици.
• Загрявайте трафика постепенно в продължение на часове, вместо незабавно да превключвате целия трафик.
• Поставяне на пауза на разпространението, когато скоростта 429, скоростта на понижаване, дълбочината на опашката или забавянето на p95 премине праг.
• Поддържайте маршрут за аварийно връщане назад с политика за съвместимост, а не само с резервен модел.

Прогноза: тъй като режимите на маршрутизиране на доставчика, нивата на приоритет и контролите на ниво работно пространство стават все по-често срещани, управлението на рампата ще се превърне в стандартна функция на шлюза, а не в скрипт за реакция при инцидент.

Резервният вариант е политическо решение, а не просто решение за капацитет

Когато един доставчик върне 429, маршрутизирането към друг доставчик може да е правилният отговор. Може също да е опасно.

Резервният вариант може да се промени:

• Качество на изхода и следващи инструкции.
• Дължина на контекста.
• Поведение при извикване на инструмент.
• Надеждност на структурирания изход.
• Запазване на данни и позиция на пребиваване.
• Разходи и забавяне.

Управителят на квотата трябва да попита слой за съвместимост дали резервният вариант е разрешен за този клас на заявка. Ако не, трябва да се постави на опашка или да се провали с ясен локален отговор за ограничение на скоростта, вместо тихо да променя семантиката.

Разкриване на табла за управление на квотите, които обясняват решенията

Система от квоти, която никой не може да разбере, ще бъде заобиколена. Създайте табла за управление около оперативни въпроси:

• Кои наематели консумират най-много RPM, входен TPM и изходен TPM?
• Кои профили на модели чакат на опашка, отхвърлят или се връщат?
• Кой обхват на доставчика е тясното място: проект, регион, внедряване, работно пространство, клас модел или ниво на акаунт?
• Колко често оценките на шлюза се различават от използването на доставчика?
• Какво представлява разпределението след повторен опит по доставчик и тип ограничител?
• Колко ефективно пространство се създава чрез бързо четене на кеша?
• Кои класове трафик заемат пакетен капацитет?

За продукти, насочени към клиенти или партньори, изложете безопасни контроли:

• Ограничения на скоростта на ключ.
• Ограничения за избухване на екип.
• Дневни ограничения за клиент.
• Спешна пауза за наемател или ключ.
• Сигнали за 429 скока, нарастване на опашката и необичаен натиск на токена.
• Партньор API крайни точки за управление на квоти за дистрибутори.

Това превръща ограничаването на скоростта от мистериозна грешка на доставчика в подлежаща на проверка част от управлението на екип API.

Контролен списък за внедряване

Фаза 1: наблюдавайте и класифицирайте

• Доставчик на журнал, модел, внедряване, регион, работно пространство, проект, клиент, API ключ и клас на заявка за всяко повикване.
• Улавяне на доставчик 429 с повторен опит и необработени метаданни за грешка.
• Записвайте приблизителните и действителните входно/изходни токени отделно.
• Разделете интерактивния, пакетния, eval и фоновия трафик в телеметрията.

Фаза 2: локален приемен контрол

• Създаване на обекти за вътрешен ограничител за RPM, входен TPM, изходен TPM, общ TPM и едновременност.
• Добавете предварителна оценка на токена.
• Запазване на квота преди изпращане и съгласуване след пристигане на потреблението от доставчика.
• Отхвърляне локално, когато заявка не може да се побере в контейнера на наемателя или доставчика.

Фаза 3: справедливост и опашки

• Добавяне на йерархични кофи от организация към внедряване на доставчик.
• Присвояване на гарантирани дялове на наематели и контролирано спукване на заеми.
• Създайте отделни опашки по клас трафик.
• Задаване на специфични за клас максимални времена на изчакване и резервни правила.

Фаза 4: адаптация и операции

• Използвайте заглавките на доставчика, за да коригирате допусканията за охлаждане и презареждане.
• Добавете регулатори на рампи за миграции и планирани задания.
• Показване на табла за управление и предупреждения за квоти.
• Преглед на грешката в оценката и блокираната квота всяка седмица.

Приложимо заключение

Ако вашият шлюз опитва само 429s, той работи след повредата. Производствен клас AI API шлюз би трябвало да предотвратява повечето неизправности при ограничаване на скоростта, като решава кой има право да изпраща какво, кога и спрямо квотата на кой доставчик.

Започнете с нормализиран модел на ограничител, резервация на токен преди полет и опашки за клас на трафика. След това добавете йерархична справедливост на наемателя, адаптация на заглавката на доставчика и регулатори на рампи. Резултатът не е просто по-малко 429s. Това е по-ясно разпределение на капацитета, по-предсказуема латентност, по-безопасни миграции и поведение при ограничаване на скоростта, които вашите инженерни, финансови и екипи за поддръжка на клиенти всъщност могат да обяснят.

Свързано четене

• резервация преди полет и съпоставяне на използването
• кеш за подкани счетоводство и анализ на попадения в кеша
• съвместими политики за резервно маршрутизиране