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 също така отбелязва, че изчисленията на токените за ограничение на скоростта се оценяват при получаване на заявката и не са същите като окончателните токени за таксуване.
• Антропичните документи разделят ограниченията за заявки на минута, входни жетони на минута и изходни жетони на минута. Превишаването на ограниченията връща 429 със заглавка за повторен опит.
• Anthropic предупреждава, че рязкото увеличаване на трафика може да достигне границите на ускорението и препоръчва постепенно увеличаване.
• За повечето модели на Claude документите на Anthropic, които кешират входни токени за четене, не се броят към лимитите за входни токени на минута, което означава, че бързото кеширане може да промени ефективното пространство.
• Ограниченията за скоростта на приложния програмен интерфейс (API) на Google Gemini са обвързани с нивата на използване на проекта, като по-високите нива зависят от настройката на таксуването, кумулативните разходи и изминалото време след основните етапи на плащането.

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

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

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

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

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

Изграждане на нормализиран квотен модел

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

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

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

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

<пре><код>{ "доставчик": "доставчик_a", "model_profile": "бърз чат", "обхват_доставчик": { "проект": "продукция", "регион": "нас-изток", "deployment": "chat-large-01" }, "ограничения": { "rpm": 1200, "input_tpm": 800 000, "output_tpm": 250000, "едновременност": 200 } }

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

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

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

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

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

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

estimated_input_tokens = tokenize(request_messages) + model_overhead
оценени_изходни_токени = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reserved_total_tokens = оценени_входящи_токени + оценени_изходни_токени

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

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

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

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

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

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

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

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

организация
  └── наемател
      └── екип
          └── api_key
              └── модел_профил
                  └── provider_deployment

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

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

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

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

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

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

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

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

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

<таблица> Клас на трафик Типична политика Защо Интерактивен чат Къса опашка, нисък бюджет за забавяне, бърз отказ или съвместим резервен вариант Потребителите забелязват бързо забавяне на опашката Агентни работни процеси Умерена опашка, бюджети, съобразени с инструментите, изходен капацитет Многоетапните повиквания могат да увеличат натиска върху символите Пакетни задачи По-дълга опашка, планирано изглаждане, по-нисък приоритет Обикновено толерантно към забавяне и много токени ОценкиСпециална квота, пауза по време на инциденти Може да създава внезапни изкуствени пикове Обобщение на фона Поставяне на опашка или отлагане, строго TPM ограничение Полезно, но рядко спешно

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

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

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

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

<пре><код>{ "грешка": { "type": "rate_limited", "ограничител": "изход_tpm", "доставчик": "доставчик_a", "model_profile": "бърз чат", "provider_model": "модел-x", "retry_after_ms": 2400, "tenant_id": "tenant_123", "api_key_id": "ключ_456", "request_class": "интерактивен", "estimated_input_tokens": 4200, "estimated_output_tokens": 800, "gateway_decision": "приет_след това_доставчик_отхвърлен", "fallback_allowed": невярно, "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. Това е по-ясно разпределение на капацитета, по-предсказуема латентност, по-безопасни миграции и поведение при ограничаване на скоростта, които вашите инженерни, финансови и екипи за поддръжка на клиенти всъщност могат да обяснят.

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

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