Шлюзы AI API с учетом ограничений скорости: формируйте RPM, TPM, пакеты и справедливость арендаторов до появления 429s

Ошибка 429 от поставщика LLM — это не просто сигнал повторной попытки. В рабочей среде это часто свидетельствует о том, что ваше приложение уже потеряло контроль над доступом, справедливостью клиентов, задержкой или учетом квот для конкретного поставщика.

Распространенное решение — экспоненциальная отсрочка — необходимо, но неполное. Backoff реагирует после того, как провайдер отклоняет трафик. Шлюз AI API с поддержкой ограничения скорости должен формировать трафик до того, как запросы покинут вашу систему: оценивать нагрузку на токены, резервировать квоту, изолировать клиентов, ставить в очередь нужную работу, отклонять неправильную работу и адаптироваться при изменении ограничений поставщика.

В этой статье описывается практический регулятор квот шлюза для команд, отправляющих производственные рабочие нагрузки нескольким поставщикам LLM через единый API.

Проблема читателя: 429 многомерны

Многие команды рассматривают ограничения скорости как одно число запросов в минуту. Это предположение быстро опровергается с помощью API-интерфейсов LLM.

Факты из текущей документации поставщика:

<ул>

В документах OpenAI указано, что ограничения могут применяться в течение более коротких окон, чем объявленный поминутный лимит, поэтому короткие всплески могут не сработать, даже если средняя минута выглядит безопасной.

Квота Azure OpenAI назначается в зависимости от подписки, региона, модели и типа развертывания в токенах в минуту. Назначение TPM развертыванию также определяет ограничения RPM принудительного вывода, а соотношение RPM и TPM варьируется в зависимости от модели.

Azure OpenAI также отмечает, что расчеты токенов ограничения скорости оцениваются при получении запроса и не совпадают с окончательным подсчетом токенов для выставления счетов.

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

Anthropic предупреждает, что резкое увеличение трафика может привести к превышению пределов ускорения, и рекомендует постепенно наращивать скорость.

Для большинства моделей Claude документы Anthropic, в которых кэшируются входные токены, не учитываются при расчете ограничений на количество входных токенов в минуту, что означает, что кэширование подсказок может изменить эффективный запас.

Ограничения на ставки Google Gemini API привязаны к уровням использования проекта, причем более высокие уровни зависят от настройки выставления счетов, совокупных расходов и времени, прошедшего после этапов оплаты.

Урок эксплуатации ясен: форма запроса, совместимая с OpenAI, не подразумевает поведение квот, совместимое с OpenAI. Шлюзу с несколькими провайдерами требуется модель внутренней квоты, более обширная, чем «повторить попытку, если 429».

Цель разработки: сделать контроль доступа обязанностью шлюза

Перед отправкой запроса шлюз, поддерживающий ограничение скорости, должен ответить на пять вопросов:

<ол>

Какой поставщик, модель, развертывание, регион, проект или рабочее пространство получит запрос?

Сколько запросов, входных токенов, выходных токенов и ресурсов одновременного выполнения он может потреблять?

За какой арендатор, команду, ключ API, клиента или класс рабочей нагрузки следует взимать плату за общую мощность?

Должен ли запрос быть принят сейчас, поставлен ненадолго в очередь, понижен, перенаправлен в другое место или отклонен?

Как следует согласовать резервирование после того, как поставщик сообщит о фактическом использовании?

Шлюз становится регулятором квот. Он не заменяет ограничения провайдера. Это делает ограничения поставщика видимыми, предсказуемыми и справедливыми в вашей собственной системе.

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

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

Рекомендуемые размеры ограничителя

<ул>

RPM: количество запросов в минуту.

Ввод TPM: токены приглашения, сообщения, инструмента и контекста в минуту.

Выходной TPM: токены завершения в минуту, зарезервированные отдельно для потоковой передачи и длинных генераций.

Общий TPM: полезен для поставщиков или развертываний, которые подвергаются комбинированному давлению токенов.

Параллелизм: активные запросы, активные потоки или выполняемые задания.

Продолжительность потоковой передачи. Долгоживущие потоки могут занимать пространство для подключения и выходных токенов даже при низком уровне частоты вращения.

Область действия зависит от поставщика: подписка/регион/развертывание Azure, рабочая область/класс модели Anthropic, проект/уровень Google или группа организации/проекта/модели OpenAI.

Не скрывайте параметры, специфичные для поставщика. Нормализуйте их в общую схему, но сохраните достаточно деталей, чтобы позже объяснить отказ.

{
  "провайдер": "провайдер_а",
  "model_profile": "быстрый чат",
  "provider_scope": {
    "проект": "продюсер",
    "регион": "нас-восток",
    "deployment": "chat-large-01"
  },
  "пределы": {
    «об/мин»: 1200,
    «input_tpm»: 800000,
    "output_tpm": 250000,
    «параллелизм»: 200
  }

Этот внутренний объект должен быть настроен явно, а не выведен только из названий моделей. Панели мониторинга поставщиков, уровни учетных записей, региональные развертывания и настройки рабочей области могут изменить эффективную мощность одного и того же семейства моделей.

Оцените нагрузку на токен перед отправкой

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

Вводы предполетного бронирования

<ул>

Сериализованное приглашение и длина сообщения.

Токенизация и накладные расходы для конкретных моделей для ролей, инструментов, изображений или инструкций структурированного вывода.

max_completion_tokens или эквивалентное ограничение вывода.

Исторический коэффициент завершения для этой конечной точки, клиента, профиля модели и класса запроса.

Ожидаемые токены чтения кэша, если кэширование запросов доступно и измеримо.

Флаг потоковой передачи и ожидаемая продолжительность трансляции.

Для начала часто бывает достаточно простого правила резервирования:

estimated_input_tokens = tokenize(request_messages) + model_overhead
оцененные_выходные_токены = мин(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
зарезервированные_тотал_токены = оцененные_входные_токены + оцененные_выходные_токены

Для неизвестных маршрутов используйте консервативное значение по умолчанию. Чтобы обеспечить стабильные маршруты производства, постоянно обновляйте оценки на основе фактического использования.

Зарезервируйте, затем согласуйте

Резервирование квот не должно становиться постоянной оплатой. Относитесь к ним как к запретам:

<ол>

Цитата: оцените входное и выходное давление.

Резерв: вычитается из соответствующих сегментов токенов перед отправкой.

Урегулировать. Замените оценку данными об использовании, сообщенными поставщиком, если таковые имеются.

Возврат или дебет: при необходимости верните неиспользованную зарезервированную емкость или спишите излишек в следующее окно.

Это особенно важно для длинных контекстных и потоковых вызовов. Если вы проверяете только входной TPM перед отправкой, поток может запуститься успешно, а затем позже столкнуться с давлением выходных токенов. Отдельное резервирование выходного запаса снижает риск сбоев и остановок в середине потока.

Используйте иерархические сегменты токенов для обеспечения справедливости между арендаторами

Единый глобальный ограничитель защищает учетную запись поставщика, но не защищает клиентов друг от друга. Одно пакетное задание с длинным контекстом может использовать общий TPM и привести к сбою интерактивных запросов от других команд.

Используйте иерархические сегменты токенов:

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

Запрос должен пройти каждый соответствующий сегмент. Это позволяет одновременно применять несколько политик:

<ул>

Организация не может превышать возможности поставщика.

Арендатор не может потреблять больше, чем предусмотрено договором.

Ключ API не может превышать пределы предполагаемой среды или приложения.

Профиль пакетной модели не может истощать профиль интерактивной модели.

Развертывание поставщика не может быть перегружено, даже если у другого развертывания есть свободная квота.

Справедливое распределение или использование

Рекомендация: используйте взвешенное справедливое распределение с контролируемым пакетным заимствованием.

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

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

<ул>

Дайте каждому арендатору гарантированный базовый уровень.

Разрешить пакетное заимствование из неиспользуемой общей емкости.

Возвратите заемные ресурсы при появлении трафика с более высоким приоритетом или гарантированного трафика.

Никогда не позволяйте заимствованному трафику создавать 429 на уровне поставщика для гарантированного трафика.

Разделяйте классы трафика, прежде чем они будут конфликтовать

Не все запросы заслуживают одинакового поведения в очереди. Поместите трафик в профили модели с отдельными очередями и пулами квот.

<таблица> <голова> <тр> Класс трафика Типичная политика Почему <тело> <тр> Интерактивный чат Короткая очередь, малая задержка, быстрый отказ или совместимый резервный вариант Пользователи быстро замечают задержку <тр> Рабочие процессы агентов Умеренная очередь, бюджеты с учетом инструментов, запас выходных данных Многоэтапные вызовы могут усилить давление на токены <тр> Пакетные задания Более длинная очередь, запланированное сглаживание, более низкий приоритет Обычно терпим к задержкам и требует большого количества токенов <тр> ОценкиВыделенная квота, пауза во время инцидентов Может создавать внезапные искусственные всплески <тр> Подведение итогов Поставить в очередь или отложить, строгое ограничение TPM Полезно, но редко срочно

Очередь повышает вероятность успеха, но увеличивает задержку. Шлюз должен сделать этот компромисс явным. Например, интерактивный запрос может ожидать квоты до 300 миллисекунд, а затем откатиться назад или завершиться ошибкой. Ночное пакетное задание может подождать 20 минут и все равно считаться успешным.

Нормализация ошибок 429 в одну схему ошибок

Даже при хорошем контроле доступа ошибки 429 у поставщика все равно будут возникать. Лимиты могут меняться, оценки провайдера могут отличаться от ваших, а трафик может приходить более резкими всплесками, чем ожидалось.

Нормализация каждого поставщика 429 в объект ошибки шлюза:

{
  "ошибка": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "провайдер": "провайдер_а",
    "model_profile": "быстрый чат",
    "provider_model": "модель-х",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "интерактивный",
    «estimated_input_tokens»: 4200,
    «estimated_output_tokens»: 800,
    "gateway_decision": "admitted_then_provider_rejected",
    «fallback_allowed»: ложь,
    "trace_id": "trace_abc"
  }

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

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

Некоторые поставщики возвращают полезные заголовки, например индикаторы повторной попытки или оставшейся емкости. Используйте их, когда они доступны.

Рекомендация: заголовки провайдера должны настраивать ваш местный губернатор, а не заменять его.

Причины:

<ул>

Доступность заголовка зависит от поставщика и конечной точки.

Заголовки не могут отображать все ограничительные размеры.

Retry-after сообщает вам, когда повторить попытку, а не какой арендатор должен получить ресурсы следующим.

Оценки токенов на стороне поставщика могут отличаться от данных, указанных в ваших счетах или внутренней отчетности.

Надежная реализация обновляет скорость пополнения локального сегмента и время восстановления на основе заголовков, сохраняя при этом соблюдение ограничений клиента, ключа API, класса трафика и ограничений развертывания поставщика внутри шлюза.

Добавить регуляторы скорости для миграции и запланированных заданий

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

Рекомендация: рассматривайте рост трафика как контролируемое развертывание.

<ул>

Миграция моделей с указанием функций по арендаторам, маршрутам или процентам трафика.

Установите поминутные ограничения роста для развертывания новых поставщиков.

Подогревайте трафик постепенно в течение нескольких часов, а не мгновенно переключайте весь трафик.

Приостанавливайте внедрение, когда частота 429, скорость перехода на более раннюю версию, глубина очереди или задержка p95 пересекают пороговое значение.

Сохраняйте резервный маршрут отката с политикой совместимости, а не просто запасную модель.

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

Резервный вариант – это политическое решение, а не только решение о мощности

Когда один провайдер возвращает код 429, правильным ответом может быть маршрутизация к другому провайдеру. Это также может быть небезопасно.

Резервный вариант может измениться:

<ул>

Качество вывода и соблюдение инструкций.

Длина контекста.

Поведение при вызове инструмента.

Надежность структурированного вывода.

Положение о хранении и размещении данных.

Стоимость и задержка.

Регулятор квот должен запросить уровень совместимости, разрешен ли откат для этого класса запросов. В противном случае он должен поставиться в очередь или завершиться сбоем с четким ответом на локальное ограничение скорости, а не молча менять семантику.

Отображение информационных панелей квот, объясняющих решения

Система квот, которую никто не может понять, будет обойдена. Создайте информационные панели по оперативным вопросам:

<ул>

Какие арендаторы потребляют больше всего RPM, входного TPM и выходного TPM?

Какие профили моделей ставятся в очередь, отклоняются или возвращаются к использованию?

Какая область поставщика является узким местом: проект, регион, развертывание, рабочая область, класс модели или уровень учетной записи?

Как часто оценки шлюза отличаются от показателей использования поставщика?

Каково распределение повторных попыток по поставщикам и типам ограничителей?

Какой эффективный запас создается при чтении кэша запросов?

Какие классы трафика используют пакетную мощность?

Для продуктов, ориентированных на клиентов или партнеров, предоставьте безопасные элементы управления:

<ул>

Ограничения скорости для каждого ключа.

Ограничения на количество пакетов для каждой команды.

Дневные ограничения для каждого клиента.

Аварийная пауза для арендатора или ключа.

Оповещения о всплесках 429, росте очереди и аномальной нагрузке на токены.

Конечные точки партнерского API для управления квотами реселлера.

Это превращает ограничение скорости из загадочной ошибки поставщика в проверяемую часть командного управления API.

Контрольный список реализации

Этап 1: наблюдать и классифицировать

<ул>

Поставщик журналов, модель, развертывание, регион, рабочая область, проект, клиент, ключ API и класс запроса для каждого вызова.

Захватывать сообщения 429 поставщика с помощью метаданных повторной попытки и необработанных ошибок.

Записывайте расчетные и фактические токены ввода/вывода отдельно.

Разделение интерактивного, пакетного, оценочного и фонового трафика в телеметрии.

Этап 2: местный контроль доступа

<ул>

Создайте внутренние объекты-ограничители для RPM, входного TPM, выходного TPM, общего TPM и параллелизма.

Добавить предполетную оценку токена.

Зарезервируйте квоту перед отправкой и согласуйте ее после поступления использования поставщика.

Отклонять локально, если запрос не может соответствовать сегменту клиента или поставщика.

Этап 3: справедливость и очереди

<ул>

Добавьте иерархические сегменты от организации к развертыванию поставщика.

Назначайте гарантированные доли арендаторам и контролируйте резкое заимствование.

Создавайте отдельные очереди по классам трафика.

Установите максимальное время ожидания и резервные правила для конкретного класса.

Этап 4: адаптация и эксплуатация

<ул>

Используйте заголовки поставщиков, чтобы настроить время восстановления и предположения о пополнении.

Добавьте регуляторы скорости для миграции и запланированных заданий.

Открывать информационные панели и оповещения о квотах.

Проверяйте ошибку оценки и неиспользованную квоту еженедельно.

Практическое заключение

Если ваш шлюз повторяет только 429-й код, он работает после сбоя. Шлюз AI API промышленного уровня должен предотвращать большинство ошибок ограничения скорости, решая, кому разрешено отправлять, что, когда и в соответствии с квотой какого поставщика.

Начните с нормализованной модели ограничителя, предполетного резервирования токенов и очередей по классам трафика. Затем добавьте иерархическую справедливость арендаторов, адаптацию заголовков поставщиков и регуляторы линейного изменения. Результат – не просто меньше 429-х. Это более четкое распределение мощности, более предсказуемая задержка, более безопасная миграция и поведение при ограничении скорости, которые могут объяснить ваши специалисты по проектированию, финансам и поддержке клиентов.

Связанное чтение

• предварительное резервирование и использование сверка
• оперативный учет кэша и аналитика попаданий в кэш
• совместимые политики резервной маршрутизации