Если вы спрашиваете, что произойдет при превышении ограничения скорости в середине расчетного периода, начните с ответа, полученного вашим приложением. Ограничение скорости обычно означает, что клиенту нужно подождать, повторить попытку позже или сократить объем новых задач. Само по себе оно не подтверждает, что баланс учетной записи исчерпан, что тарифный план можно изменить или что поставщик выставит счет за запрос. Прежде чем решать, что это означает, проверьте актуальную документацию по учетной записи и сервису.
Разделите обработку инцидента на две части. Защитите уже выполняющиеся задачи, затем соберите достаточно контекста, чтобы решить, следует ли подождать, снизить нагрузку или спросить владельца сервиса о доступной мощности.
Сначала определите, что именно ограничено
Не считайте каждый неудачный запрос ограничением скорости. Сбои аутентификации, недоступность вышестоящих сервисов, недействительные запросы, исчерпанные балансы и ограничения параллелизма требуют разных действий. Начните со статуса и сообщения ответа, временной метки запроса, маршрута или модели, а также количества запросов, активных в тот момент.
Если ответ содержит статус HTTP 429, ознакомьтесь с актуальными рекомендациями сервиса относительно времени повторной попытки. Некоторые сервисы предоставляют значение Retry-After. Если время не указано, используйте краткую политику повторных попыток с ограничениями вместо немедленной повторной отправки того же запроса. Повторные немедленные попытки могут ухудшить ситуацию с очередью и скрыть первый полезный сигнал.
Если возможно, зафиксируйте измерение, по которому применяется ограничение. Ограничение числа запросов в минуту, пропускной способности по токенам, количества одновременных задач, а также условия по расходам или кредитам — это разные механизмы контроля. Увеличение числа работников может помочь решить одну проблему и усугубить другую.
Защитите работу пользователей, пока возможности клиента ограничены
Прекратите создавать неограниченный параллельный объём работы. Поместите новые задания в устойчивую очередь, ограничьте одновременное выполнение заданий несколькими пользователями и позвольте работникам брать задания с той скоростью, с которой сервис может их принимать. Для интерактивной функции покажите пользователю, что работа ожидает завершения, вместо того чтобы отправлять то же действие повторно.
Используйте экспоненциальную задержку с дрожанием для получения ответов с возможностью повторной отправки. Функция Backoff распределяет попытки повторного выполнения во времени. Джиттер предотвращает возврат множества воркеров через один и тот же интервал. Установите максимальное число попыток и крайний срок, соответствующий задаче пользователя. Цикл повторных попыток без ограничений может превратить короткий инцидент в более крупную очередь невыполненных задач.
Обеспечьте безопасность повторяемых операций записи ещё до инцидента. Ключ идемпотентности, идентификатор задания или запись на стороне приложения могут помочь клиенту определить, был ли принят задержанный запрос до выполнения повторной попытки. Если приложение не может сделать запрос идемпотентным, сохраните исходное состояние запроса и передайте неопределённость человеку или в компенсирующий рабочий процесс.
receive retryable limit signal
-> preserve request and correlation ID
-> queue or delay new work
-> retry with bounded exponential backoff and jitter
-> stop after the attempt or time budget
-> surface the result or route for reviewРешите, ждать ли, снижать ли нагрузку или эскалировать проблему
Используйте собранные доказательства, чтобы внести минимальное безопасное изменение. Эта таблица является операционным руководством, а не заявлением о политике выставления счетов какого-либо поставщика.
Ситуация | Первоначальная реакция | Какие данные сохранить |
|---|---|---|
Кратковременный всплеск ответов о повторяемом ограничении | Замедлите потребителей, поставьте работу в очередь и используйте ограниченное число повторных попыток. | Статус ответа, время повторных попыток, объём запросов и параллелизм. |
Устойчивое ограничение во время запланированного запуска | Сократите второстепенную работу и проверьте документированные возможности учётной записи, прежде чем менять архитектуру. | Прогноз запуска, пиковая скорость, затронутые маршруты и влияние на пользователей. |
Ограничение появляется после развёртывания | Сравните новый шаблон запросов с предыдущим и приостановите источник усиления. | Время развёртывания, разветвление запросов, число повторных попыток и частота ошибок. |
Ответ явно не является ограничением скорости | Не следует предполагать, что добавление в очередь решит проблему. Следуйте соответствующему пути аутентификации, проверки, баланса или сбоя. | Полный, прошедший санитарную обработку класс ошибки, метка времени и идентификатор корреляции запроса. |
Эскалация работает лучше, когда начинается с фактов. Укажите контекст учетной записи, который служба поддержки имеет право проверять, наблюдаемый временной интервал, маршрут или модель, шаблон запроса и параллельного выполнения, а также влияние на пользователя. Не отправляйте секреты, необработанные заголовки авторизации или персональные данные в заявке об инциденте.
Подготовьтесь к следующей неожиданности в расчётном цикле
Обработка ограничений скорости работает лучше всего, когда является частью проектирования сервиса. Измеряйте обычную и пиковую частоту запросов, определите политику очереди, решите, какие задания могут ждать, и выберите тайм-аут, видимый пользователю. Протестируйте путь повторных попыток с помощью безопасной симуляции сбоя, чтобы первый реальный инцидент не выявил неограниченный цикл или дублирование работы.
Ведите краткую инструкцию, отвечающую на четыре вопроса: какой сигнал указывает на ограничение скорости? Какую работу можно отложить? Где контролируется параллелизм? Кто проверяет политику, специфичную для учётной записи, когда доступная мощность кажется недостаточной? Пересматривайте её перед запусками, которые меняют структуру трафика, использование моделей или объём фоновых заданий.
Используйте актуальные источники OdiRouter для решений по учётной записи
OdiRouter описывает платформу, ориентированную на разработчиков, для моделей API, безопасного выполнения агентов и оптимизации нагрузок GPU. Его Pricing page сообщает, что текущие варианты можно оценивать с учётом стоимости, скорости и доступности моделей. Используйте этот актуальный источник, когда вам нужно сравнить варианты, а не полагаться на общую статью для решений, специфичных для учётной записи.
Для работ по интеграции Getting Started guide охватывает ключи API, авторизацию, идентификаторы моделей и настройку первого запроса. Команды с существующим OpenAI SDK project могут ознакомиться с документированным путём интеграции OdiRouter. Эти источники помогают с конфигурацией; они не заменяют актуальную документацию по ограничениям и выставлению счетов для активной учётной записи.