Лимит API LLM — это не только число запросов в минуту. Провайдер может отдельно ограничивать запросы, входные и выходные токены, одновременные задачи и дневное использование. Поэтому интеграция, которая работает на пяти ручных запросах, способна начать возвращать ошибки при первом параллельном запуске.
Проверка квот API LLM до релиза помогает понять три вещи: какой лимит применим к вашему аккаунту и модели, как быстро приложение упирается в него при ожидаемой нагрузке и что происходит с запросом после ответа 429. Ниже — практический тест без попыток вывести лимит из одного удачного вызова.
Сначала уточните, какой именно лимит действует
Провайдеры не всегда используют одинаковые единицы измерения. OpenAI описывает ограничения по запросам и токенам, Anthropic указывает лимиты запросов и токенов, а Gemini API документирует ограничения, которые зависят, среди прочего, от модели и уровня проекта. Точные значения следует смотреть в документации и панели именно своего аккаунта: опубликованные цифры не обязательно совпадают с вашей квотой.
Перед тестированием запишите:
- провайдера и точное имя модели;
- проект, организацию или уровень доступа, к которому привязан ключ;
- ограничение запросов за минуту и токенов за минуту, если они указаны;
- дневные ограничения или лимиты расходов;
- правила для параллельных запросов, пакетной обработки и отдельных конечных точек.
Не переносите значения между моделями или проектами. Если провайдер меняет квоту по мере использования сервиса, старый скриншот или запись в конфигурации могут быть неактуальны. Проверьте панель непосредственно перед тестом и сохраните дату проверки в заметках к релизу.
Как оценить потребление токенов до нагрузки
Для грубой оценки используйте ожидаемый поток запросов и средний размер одного обращения. Если приложение отправляет 20 запросов в минуту, а каждый содержит около 1 500 входных и 500 выходных токенов, получится примерно 30 000 входных и 10 000 выходных токенов в минуту. Это оценка нагрузки, а не гарантия того, как именно провайдер считает квоту.
Среднее значение скрывает длинные запросы и всплески. Возьмите реальные обезличенные примеры или синтетические данные, похожие на рабочие, и посчитайте токены для каждого запроса подходящим токенизатором. Затем проверьте медиану, 95-й перцентиль и максимум. Если точный токенизатор для модели недоступен, измерения следует считать приближёнными и оставить запас.
Для расчёта включайте не только текст пользователя. В запрос могут входить системные инструкции, история диалога, описания инструментов, структурированная схема вывода и документы из RAG. При каждом ходе диалога часть истории может отправляться повторно. Поэтому короткое сообщение пользователя не обязательно означает короткий запрос к модели.
Воспроизводимый тест на квоту
Проведите тест в отдельном проекте или среде, где случайный всплеск не затронет рабочий трафик. Используйте тот же ключевой уровень, модель, формат запросов и настройки, что планируете для приложения. Не вставляйте настоящие персональные данные: для проверки лимитов достаточно синтетического корпуса с похожими размерами запросов.
Отправьте несколько последовательных запросов с небольшим интервалом. Запишите код ответа, задержку, размер входа и ответа, а также доступные заголовки.
2. Повторите тест с ростом параллельности, например 1, 2, 4 и 8 одновременных запросов. Значения — ступени эксперимента, а не рекомендованная нагрузка для любого API.
3. На каждой ступени выдерживайте одинаковое окно и постепенно увеличивайте темп. Не начинайте с массового запуска сотен запросов.
4. Зафиксируйте момент появления 429, если он возникает, и сохраните тело ошибки и заголовки ответа.
5. Остановите рост нагрузки, когда достигнут лимит, появились заметные задержки либо тестовый бюджет приблизился к установленному пределу.
6. После паузы повторите более низкую ступень, чтобы проверить, восстанавливается ли доступ и корректно ли клиент продолжает работу.
Не пытайтесь «вычислить истинную квоту» единичным стресс-тестом. На результат могут влиять другие клиенты того же проекта, изменившаяся квота, сетевые задержки и внутренние механизмы распределения нагрузки. Практическая цель — убедиться, что система выдерживает ожидаемый профиль и предсказуемо деградирует при ограничении.
Что читать в заголовках и ответе 429
Некоторые API возвращают заголовки с информацией о текущих лимитах и оставшемся запасе. Имена и доступность таких заголовков зависят от провайдера и метода. Сохраняйте заголовки ответа целиком, затем сверяйте их с документацией конкретного API — не закладывайте обработку по чужому примеру без проверки.
HTTP 429 обычно означает, что запрос ограничен по частоте или квоте, но причина и срок восстановления могут различаться. Проверьте тело ответа: оно может уточнить тип лимита. Если сервер передал `Retry-After`, учитывайте его; если нет, клиенту нужна собственная стратегия ожидания. Не считайте 429 доказательством, что исчерпан именно токенный лимит: это может быть ограничение запросов или другая политика аккаунта.
Полезно логировать не секреты, а диагностические поля: модель, время, статус, длительность, оценку входных токенов, размер ответа и безопасные идентификаторы запроса. Удаляйте ключи API, персональные данные и содержимое пользовательских обращений. Логи должны помогать различить лимит, сетевой сбой и ошибку формата, не превращаясь в копию чувствительных запросов.
Как настроить повторы, чтобы не усугубить ограничение
Повторять каждый неудачный запрос немедленно — плохая стратегия: при общей перегрузке клиенты синхронно создадут ещё больше трафика. Для временных ошибок применяют экспоненциальную задержку с разбросом (jitter): интервал постепенно растёт, а случайная добавка не даёт всем клиентам повторять одновременно. Установите верхний предел задержки и число попыток, после которого задача возвращается в очередь или передаётся на ручную обработку.
Для 429 сначала используйте указание сервера, если оно есть, затем применяйте ограниченный backoff. Для ошибок, не предполагающих временное восстановление, например неверного запроса или отказа в доступе, автоматический повтор обычно не исправляет причину. Классифицируйте ответы по кодам и типам ошибок согласно документации провайдера.
Есть и отдельный риск: клиент может не получить ответ после того, как сервер уже обработал запрос. Повтор тогда способен привести к повторной генерации и дополнительному расходу. Если API и приложение поддерживают механизм идемпотентности, изучите его документацию. Иначе храните состояние задачи и не отправляйте дубль вслепую: сначала определите, можно ли безопасно установить результат предыдущей попытки.
Проверка на примере небольшого клиента
В простом тестовом клиенте измеряйте длительность и сохраняйте статус, не выводя ключ в консоль. Псевдокод последовательности:
text
для каждой ступени параллельности:
запустить ограниченное число запросов
для каждого ответа сохранить:
статус, длительность, модель, оценку токенов, заголовки лимитов
при 429:
прочитать Retry-After и тело ошибки
прекратить увеличение нагрузки
дождаться завершения окна
сравнить фактические результаты с ожидаемым профилем
Если используете Python или Node.js, не создавайте сразу неограниченный список задач. Задайте семафор или пул фиксированного размера, добавьте таймаут, ограниченное число повторов и отмену оставшихся задач при остановке теста. Иначе проверка квоты незаметно превратится в нагрузку, которую сложно контролировать.
Сравнивайте не только долю успешных ответов. Запишите задержку p50 и p95, число 429, максимальную параллельность, количество повторов и фактически потраченные токены, если провайдер показывает их в панели. Разделите результаты по моделям и типам задач: один общий средний показатель может скрыть проблему только у длинных запросов или конкретной модели.
Когда тест можно считать достаточным
Тест полезен, если он воспроизводит ожидаемый пик, включает запросы разных размеров и показывает контролируемое поведение при ограничении. Он не доказывает, что квота останется неизменной или что производительность будет такой же в другой период. Ограничения могут зависеть от аккаунта, модели и политики поставщика; для критичного сервиса оставляйте запас и мониторьте фактические ошибки после запуска.
Перед релизом проверьте четыре пункта: значения лимитов подтверждены в актуальной панели, запросы измеряются на реалистичных данных, 429 не вызывает бесконечные повторы, а таймауты и повторы не создают неконтролируемые дубли. После изменения модели, системной инструкции, объёма контекста или параллельности повторите тест: профиль потребления мог измениться даже без правок API-клиента.
