Сколько запросов в час выдержит ваша интеграция

Вопрос «сколько запросов в час мы вытянем» почти всегда задают про модель, а упирается всё в другое: в лимиты провайдера, в то, сколько запросов вы отправляете одновременно, и в длину ответов. Типичная интеграция, написанная в лоб, отправляет запросы по одному, ждёт каждый ответ и использует доступную полосу процентов на десять — при этом на графике всё выглядит как «медленная модель». Разбираем, из чего складывается пропускная способность, как её считать, где обычно узкое место и почему очередь, которая справляется в среднем, всё равно однажды переполнится.

Из чего складывается предел

Четыре ограничения, и они действуют одновременно.

Лимит по числу запросов в минуту. Сколько обращений провайдер принимает от вас за минуту.

Лимит по токенам в минуту. Сколько суммарного объёма. Именно он чаще всего и есть настоящее ограничение: сто запросов по десять тысяч токенов выберут полосу быстрее, чем тысяча коротких.

Ваша параллельность. Сколько запросов вы держите в полёте одновременно. Если один — всё остальное не имеет значения.

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

Как эти четыре ограничения выглядят на типичных сценариях.

Отсюда первое практическое следствие: прежде чем спрашивать про лимиты, посмотрите на свою параллельность. В большинстве случаев узкое место там.

Как посчитать свой потолок

Порядок на полчаса, без нагрузочного тестирования.

1. Замерьте среднюю длительность ответа и 95-й перцентиль — как это делать.
2. Посчитайте средний размер запроса и ответа в токенах — методика. Не забудьте служебный контекст маршрута: он входит в ваш объём — почему prompt_tokens больше.
3. Прикиньте потолок по числу запросов: параллельность, делённая на среднюю длительность, умноженная на 3600.
4. Прикиньте потолок по токенам: лимит токенов в минуту, делённый на объём одного запроса, умноженный на 60.
5. Возьмите меньшее из двух. Это и есть ваш час.

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

Что делать с параллельностью

Практическая часть, дающая самый быстрый прирост.

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

Ограничьте параллельность явным числом. Не «сколько получится»: без предела вы упрётесь в лимит провайдера и получите поток отказов вместо ускорения.

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

Учитывайте, что предел придётся пересматривать. При смене модели меняются и длительность, и объём — что ещё ломается при переходе.

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

Очередь и пик

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

Система, которая в среднем справляется с потоком, при пике не «немного отстаёт» — очередь растёт неограниченно, пока пик не кончится. Если пик длится дольше, чем у вас есть буфер, задачи начинают теряться или ждать часами.

Отсюда три требования к любой пакетной обработке:

Считайте по пику, а не по среднему. Дневной объём, делённый на 24, — бесполезная цифра, если восемьдесят процентов приходят за два часа.

Стройте очередь с видимой глубиной. Вы должны видеть, сколько задач ждёт, а не только сколько обработано.

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

Где узкое место обычно не там, где ищут

Четыре частых случая.

Обвиняют модель, а виновата последовательность. Один запрос за раз при трёхсекундных ответах — это 1200 в час, сколько бы полосы вам ни выделили.

Обвиняют лимиты, а виноват объём. Полоса по токенам выбирается длинными контекстами; сокращение отправляемого даёт больше, чем повышение лимита.

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

Обвиняют сеть, а виновата обработка результата. Разбор ответа, запись в базу, генерация файла — всё это тоже время, и оно не параллелится само.

Как сократить объём, а не наращивать полосу

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

Обрезайте историю. В диалоговых сценариях она и есть основной объём.

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

Сократите системный промпт. Он уходит при каждом обращении — как его чистить.

Ограничьте длину ответа. Освобождает слот раньше.

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

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

Как это устроено у нас

Коротко и по делу.

В каталоге на 6 сентября 2026 года 56 позиций в шестнадцати семействах, у 34 открыт чат-протокол. Ставка одна и не зависит от режима обработки: отложенной очереди с половинной ценой у нас нет, как нет и ускоренного режима с наценкой — как это устроено у вендоров.

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

Отдельный ключ под нагруженный сценарий полезен не только для учёта: по нему видно, какая часть потока упирается в лимиты — как разводить ключи.

Что проверить перед запуском в объём

Короткий список, который отделяет удачный пилот от работающего конвейера.

Поведение при отказе. Не «мы повторим», а сколько раз, с какой паузой и что произойдёт после последней попытки. Задача, потерянная молча, — худший исход из возможных.

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

Видимость очереди. Сколько задач ждёт прямо сейчас. Без этой цифры вы узнаете о переполнении от пользователей.

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

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

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

Чего мы не утверждаем

Не публикуем конкретных лимитов. Они зависят от аккаунта и меняются; смотрите свои значения и заголовки ответов.

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

Не сравниваем модели по скорости. Своих замеров мы не делали.

Что нужно, чтобы замерить

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

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

Что держать в голове

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

И считайте по пику. Система, которая справляется со средним потоком, при пике не отстаёт понемногу — её очередь растёт, пока пик не закончится.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Найти свой потолок: keydealer.ru/login.