Лимиты TPM в Azure OpenAI: как найти причину ошибки 429

Если Azure OpenAI возвращает 429 Too Many Requests, а график расхода токенов остаётся низким, сначала сопоставьте настройки конкретного развёртывания с заголовками его ответов. TPM — это лимит токенов в минуту, RPM — лимит запросов в минуту. Для ограничения TPM Azure оценивает возможную обработку запроса при его поступлении, а оплаченные токены подсчитывает после обработки. Поэтому невысокий расход в Azure Monitor сам по себе не исключает превышения лимита. Это различие прямо описано в руководстве Microsoft по квотам.

Практическая задача — определить, какое ограничение сработало, изменить соответствующий параметр и повторить нагрузку с теми же исходными условиями. Ниже — порядок проверки для Standard-развёртываний; особенности API Management и выделенной мощности PTU разобраны отдельно. Интерфейс и правила сверены с документацией на 5 сентября 2026 года, но значения вашей квоты нужно смотреть в подписке.

Сохраните один отказ вместе с контекстом

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

Сохраните время в UTC, имя развёртывания, модель и версию, тип размещения, HTTP-статус, код и сообщение из тела ошибки, доступный идентификатор запроса. Отдельно запишите длину входа, заданный предел ответа, номер попытки и время отправки. Секреты доступа и содержимое пользовательских документов для такой диагностики не нужны.

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

Сохраняйте значения reset как получены: не приписывайте им единицы по аналогии с другим API. Отсутствующий заголовок означает, что данных нет. Шлюз или прокси может удалить либо изменить заголовки; тогда потребуется его журнал или трассировка.

Теперь определите, кто вернул отказ. При вызове через корпоративный шлюз сопоставьте одну попытку с его трассировкой: ушёл ли запрос в Azure OpenAI, какой ответ пришёл от сервиса и на каком этапе появился итоговый статус. Если запрос остановила политика шлюза, увеличение TPM у модели не изменит этот счётчик.

Проверьте выделенные TPM, а затем область общей квоты

Квота подписки и доля, выделенная развёртыванию, отвечают на разные вопросы. Первая определяет, сколько можно распределить между развёртываниями в соответствующей области. Вторая задаёт лимит выбранного развёртывания. Например, общий пул в 120 000 TPM не даёт обработчику автоматически 120 000 TPM, если ему выделено 30 000. Это пример распределения, а не тариф Azure.

В новом портале Microsoft Foundry включите New Foundry, откройте Manage → Quota → Token per minute и найдите нужное развёртывание. В его сведениях проверьте распределение и раздел Affiliated deployments using shared quota. Microsoft описывает изменение доли через значок карандаша, а запрос увеличения общего пула — через Request quota. Для просмотра квоты минимальная рекомендуемая роль — Cognitive Services Usages Reader на уровне подписки; она сама по себе не даёт права редактирования. См. инструкцию по управлению квотами.

Перед созданием второго развёртывания в другом регионе посмотрите столбец Scope. Microsoft начала переход к общим квотам подписки после 7 мая 2026 года; применимость нового порядка определяется для конкретной модели, а не только календарной датой. Правила проверки Scope дают такую развилку:

• Global — после перехода все развёртывания Global Standard одной модели и версии используют общий пул подписки во всех регионах.
• Data Zone — у переведённых моделей Data Zone Standard общий пул действует в пределах соответствующей зоны данных.
• Название региона — для этой подписки и модели сохраняется управление квотой по регионам.

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

После изменения выделенной доли Microsoft рекомендует дать настройкам до 15 минут на распространение, затем обновить страницу и проверить результат. Этот срок не является сроком одобрения заявки на увеличение квоты.

Если вы собираете эти сведения программно, Usages API и Model Capacities API решают разные задачи. В Usages значение currentValue показывает объём квоты, занятый развёртываниями; это не число токенов, обработанных за текущую минуту. Model Capacities показывает доступную мощность для размещения модели. При сохранении ответа оставляйте идентификатор модели и типа развёртывания, unit и описание единиц: некоторые строки квоты выражены в тысячах TPM.

Почему при низком расходе токенов возникают 429

Предел ответа завышает оценку нагрузки

Документированный расчёт ограничения учитывает вход и заданный максимум ответа — например, max_tokens в API, где этот параметр поддерживается. Также может учитываться best_of, но он применим только к поддерживающим его API. Оценка частично основана на числе символов и не совпадает с точным подсчётом токенизатором. Нельзя универсально представить её как точную формулу «вход плюс фактический ответ». Microsoft объясняет состав оценки и причины расхождения с метриками.

Возьмём условный сервис, который обрабатывает 12 заявок в минуту. В каждой около 1 500 входных токенов; ожидаемый ответ — 250 токенов, однако допустимый максимум выставлен в 4 000. Для иллюстрации получаются два разных масштаба:

Это расчётный пример, не измерение Azure и не точный прогноз момента отказа. Он показывает, почему короткие полученные ответы не оправдывают произвольно большой предел генерации.

Проверьте поддерживаемый параметр ограничения ответа для своей модели, уменьшите его до значения, достаточного для задачи, и повторите одинаковые запросы с прежним темпом отправки. Следите одновременно за 429 и полнотой ответа: исчезновение отказов ценой обрезанных результатов не считается исправлением. Не переносите max_tokens или best_of в запрос другой модели без проверки её API.

Ошибочные попытки тоже могут влиять на ограничение. В частности, Microsoft указывает, что некоторые запросы, отклонённые с HTTP 400 из-за длины входа, могут учитываться при ограничении, хотя не появятся в метрике оплаченных токенов. Устраните такие ошибки до сравнения нагрузки.

Минутное среднее скрывает всплеск запросов

RPM зависит от модели и выделенной мощности; универсального отношения «6 RPM на 1 000 TPM» для всех моделей нет. Кроме того, Azure может проверять частоту на коротких интервалах, обычно в 1 или 10 секунд. В официальном примере для 600 RPM при секундной проверке ограничение соответствует 10 поступлениям за секунду.

Для такого примера 20 запросов, отправленных одновременно, могут дать отказы, даже если за всю минуту других запросов не было. Те же 20 запросов с интервалом 0,2 секунды создают темп 5 запросов в секунду. Это сравнение графиков отправки; оно не гарантирует успеха, поскольку остаются TPM и доступная мощность.

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

Повторяйте запросы с задержкой и конечным сроком

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

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

1. При 429 используйте корректный retry-after-ms; при наличии применимого Retry-After соблюдайте указанную им задержку. Например, retry-after-ms: 2000 означает 2 секунды.
2. Если сервер не дал пригодного значения, увеличивайте задержку между попытками и добавляйте случайный разброс, чтобы клиенты не просыпались одновременно.
3. Ограничьте и число попыток, и общее время выполнения. Если рекомендованная пауза выходит за оставшееся время, завершите задачу контролируемой ошибкой либо перенесите её в разрешённую очередь; не сокращайте паузу ради немедленного повтора.
4. Оставьте один механизм повторов: SDK или внешнюю обёртку. При собственной обёртке настройка max_retries=0 отключает повторы клиента openai, как показано в документации Microsoft.

Если внешняя обёртка разрешает 4 попытки, а SDK внутри каждой делает исходную попытку и ещё 2 повтора, одна задача может породить до 12 отправок. Такой множитель нужно учитывать в журнале нагрузки. Ошибки авторизации, неподдерживаемые параметры и постоянные ошибки входа требуют исправления причины, а не цикла ожидания.

Переход на другой сервис — отдельное решение с проверкой модели, данных и допустимости маршрутизации. Для этого есть разбор повторных попыток и резервной модели; он не заменяет диагностику исходного развёртывания.

Когда изменение TPM не решает проблему

Отказ создаёт API Management. Политика llm-token-limit имеет собственный счётчик по counter-key. Превышение скорости расхода токенов даёт 429, превышение квоты за заданный период — 403. Проверьте применённую политику, ключ счётчика и трассировку. Сам по себе статус 403 ещё не доказывает срабатывание этой политики. Исправление выполняют в рамках разрешённых настроек шлюза; обход корпоративного шлюза не является способом увеличить квоту.

Эффективный лимит временно ниже настроенного. Standard использует общую инфраструктуру, и сервис может временно снижать эффективное ограничение. Сопоставьте x-ratelimit-limit-tokens с выделенными TPM для одного и того же развёртывания. Устойчивое расхождение после проверки шлюза и распространения настроек — основание для обращения в поддержку. Microsoft описывает временную корректировку и условия эскалации; увеличение квоты подписки не гарантирует устранения дефицита мощности.

Развёртывание использует PTU. Выделенная пропускная способность резервирует вычислительную мощность, однако при её исчерпании тоже возможен 429. Размер рассчитывают под модель и профиль входных и выходных токенов. Единого перевода PTU в TPM нет, а одобрение квоты PTU ещё не гарантирует доступности мощности для размещения. Начните с описания provisioned throughput, если требуется именно подбор выделенной мощности.

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

Подтвердите восстановление на сопоставимой нагрузке

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

Считайте отдельно исходные задачи, все попытки отправки, первичные 429 и задачи, завершившиеся успешно после повторов. Добавьте время ожидания в очереди, полное время выполнения и пригодность результата. Иначе 100 % конечных успехов могут скрывать многократные повторы и неприемлемую задержку.

Проверьте несколько последовательных минут и отдельно характерный всплеск. Одиночный успешный ответ после паузы подтверждает только то, что этот запрос прошёл; он не подтверждает восстановление необходимой пропускной способности. Исправление можно считать подтверждённым, когда целевая нагрузка выполняется в допустимое время, очередь остаётся устойчивой, а число отказов и повторов соответствует принятому для приложения уровню.

Если при умеренной равномерной нагрузке отказы сохраняются, передайте в поддержку время UTC, идентификаторы запросов, модель и версию, тип развёртывания, Scope, выделенный и наблюдаемый лимиты, частоту отправки и результаты проверки шлюза. Такой набор позволяет расследовать конкретный отказ вместо повторного сравнения 429 с общим графиком расхода токенов.