Лимит провайдера — это не одно число, а шесть разных ограничений, и упереться можно в любое из них по отдельности. Система, которая спокойно работает на десяти проверочных запросах, ложится в первый же час пиковой нагрузки: рекламная рассылка, утро понедельника, разбор пачки из 500 счетов. Причём отказывает она не там, где ждали, — обычно первым срабатывает не счётчик запросов, а лимит на объём текста в минуту.
Цифру для разговора с поставщиком можно посчитать заранее из уже имеющейся статистики. Для типичного потока в 6 000 обращений в месяц пиковая минута — 3,4 обращения, что превращается в 17 вызовов модели и около 75 000 токенов в минуту с двойным запасом. Ниже — как получаются эти числа за шесть действий и что делать, если тариф поставщика их не покрывает.
Отдельно разбираем то, что почти всегда остаётся неназванным: как система ведёт себя в момент упора в лимит. Отказ, очередь и деградация до шаблонного ответа — три разных проектных решения с разной ценой, и выбирает их не поставщик, а вы. Все числа — модельные, по состоянию на сентябрь 2026 года, ставка инженера 3 000 ₽/час.
Шесть ограничений, которые есть у любого поставщика
Названия в кабинетах разных провайдеров отличаются, суть — нет. Правая колонка показывает, как посчитать своё значение по каждому пункту, не дожидаясь первого сбоя.
| Ограничение | Где срабатывает первым | Как посчитать своё значение |
|---|---|---|
| Запросы в минуту | Утренний пик обращений и любая рассылка с призывом написать в чат | Пиковая минута, умноженная на число вызовов модели в одном обращении |
| Токены в минуту | Длинные документы: десять запросов по 30 000 токенов бьют по лимиту раньше, чем сто коротких | Пиковые вызовы, умноженные на средний размер запроса вместе с ответом |
| Параллельные обращения | Пакетная обработка: разбор архива, ночная миграция, выгрузка 500 счетов разом | Размер пачки, делённый на приемлемое время её обработки |
| Длина контекста | Ответ по базе знаний, когда в запрос кладут много найденных фрагментов | Самый длинный документ плюс инструкция плюс история диалога |
| Суточная квота | Разовые работы: первичная загрузка архива, повторный прогон после правки промпта | Дневной объём, умноженный на три — на день разбора накопленного |
| Месячная квота или предоплаченный пакет | Конец месяца, обычно неожиданно и целиком | Месячный объём плюс 30 % на рост и повторы |
Первые три ограничения — про скорость, вторые три — про объём, и путать их нельзя: месячный пакет, купленный с запасом, никак не спасает от упора в минутный лимит во вторник в 10 часов утра. Общая механика ограничений во внешних интерфейсах — от маркетплейсов до облачных сервисов — разобрана отдельно в материале про лимиты API и что бывает при превышении; здесь речь только о поставщиках моделей, у которых к обычным лимитам добавляется длина контекста.
Схема с четырьмя блоками сценариев слева и шестью блоками лимитов справа, соединёнными стрелками. Слева: «Утренний пик обращений», «Разбор длинного договора», «Пачка из 500 счетов», «Первичная загрузка архива». Справа: «Запросы в минуту», «Токены в минуту», «Параллельные обращения», «Длина контекста», «Суточная квота», «Месячный пакет». Стрелки: от пика — к первому и второму; от длинного договора — ко второму и четвёртому; от пачки — к третьему; от загрузки архива — к пятому и шестому. Внизу подпись: «запас по одному лимиту не спасает от упора в другой». Чертёжный стиль, подписи по-русски.
Что происходит при упоре: три поведения
Поставщик в момент превышения возвращает отказ — и на этом его роль заканчивается. Всё остальное решает ваша система, и решает так, как её собрали. Три варианта, между которыми выбирают на этапе проектирования.
| Поведение | Что видит клиент | Когда уместно | Чем платим |
|---|---|---|---|
| Отказ сразу | Сообщение об ошибке или молчание в чате, обращение теряется | Практически никогда — это результат того, что решение не принимали | Потерянными обращениями и репутацией |
| Очередь с повторами | Ответ приходит через 10–90 секунд вместо обычных 5–8 | Внутренние задачи, пакетная обработка, ночные операции | Временем ответа и усложнением системы |
| Деградация до правил | Шаблонный ответ по частым вопросам или честное «передал специалисту, ответим в течение часа» | Клиентский поток в рабочее время, где ждать полторы минуты нельзя | Долей обращений, ушедших к людям |
На практике почти всегда работает комбинация: обращение сначала уходит в очередь на 10–15 секунд, и если за это время лимит не освободился, включается деградация. Как устроен буфер, лестница повторов и карантин для сообщений, которые не проедут никогда, разобрано в материале про очереди и повторные попытки. Важное правило: деньги, здоровье и правовые темы не ставятся в очередь никогда — они сразу уходят человеку по списку стоп-тем.
Расчёт пиковой минуты из своей статистики
Считается в шесть действий из одного числа, которое у вас уже есть, — месячного количества обращений. Каждый коэффициент ниже можно и нужно заменить своим, если вы знаете точнее: почасовой профиль обычно виден в выгрузке из CRM или из журнала чата.
Токены получаются из последней строки умножением: 17 вызовов на 4 400 токенов среднего обращения — 4 000 входных и 400 выходных — даёт 74 800. Это же обращение стоит 1,04 ₽, и месячный счёт составит 6 240 ₽; разбор того, из чего складывается цена и как она растёт с объёмом, — в материалах про стоимость одного обращения и расчёт на 2 000, 6 000 и 20 000 обращений.
Одно обращение клиента — это не один запрос к модели. В типовом ассистенте с базой знаний их два-три: поиск фрагментов, основной ответ и повтор при невалидном формате. Если в системе есть ещё и классификация темы, множитель доходит до четырёх. Именно на этом месте расчёт лимита обычно занижают втрое.
Двухосевой график. Ось X — часы рабочего дня с 8:00 до 20:00, ось Y — вызовов модели в минуту от 0 до 20. Ломаная линия суточного профиля с двумя горбами: утренним около 10:00 и послеобеденным около 16:00, максимум подписан «пик: 8,2 вызова в минуту». Горизонтальная штриховая линия на уровне 1,1 подписана «средняя минута: 0,45 обращения, то есть 1,1 вызова». Верхняя сплошная горизонтальная линия на уровне 17 подписана «лимит, который нужно запросить: 17 вызовов и 75 000 токенов в минуту». Область между пиком и лимитом затонирована и подписана «запас × 2». Внизу подпись «поток 6 000 обращений в месяц, модельный расчёт, сентябрь 2026». Чертёжный стиль, подписи по-русски.
Что зафиксировать письменно
Устная договорённость про лимиты не переживает смены менеджера у поставщика. Шесть пунктов, которые должны быть в договоре или в приложении к нему числами, а не словами «достаточные для работы сервиса».
- 1Лимиты тарифа числами по всем шести видам сразу, а не только по запросам в минуту.
- 2Порядок повышения лимита: за какой срок и по какой процедуре, платно или в рамках тарифа, есть ли верхний предел.
- 3Срок реакции на обращение о превышении: часы в рабочее время и часы вне его — то, что в договоре обычно называется SLA.
- 4Поведение при превышении на стороне поставщика: отказ, задержка ответа или тарификация сверх пакета по повышенной цене. Третий вариант встречается чаще, чем ожидают, и обнаруживается в счёте.
- 5Уведомление об изменении условий заранее и в письменном виде — вместе с правом расторгнуть договор без штрафа, если новые лимиты вас не устраивают.
- 6Предел ответственности поставщика за простой. Он почти всегда ограничен абонентской платой; знать это надо до того, как считать риски, а не после.
Шестой пункт — не повод отказываться от договора, а повод перенести риск в свою архитектуру: если поставщик отвечает за простой в размере месячной платы, страховкой становится резервный провайдер, а не претензия. Как это устроено, разобрано в материалах про зависимость от одного поставщика и план на 48 часов при закрытии доступа.
Сравнение в две колонки одинаковой ширины, заголовки «Условия записаны числами» и «Условия обсуждались устно». Четыре строки в каждой: «Что делает система» — «очередь 15 секунд, затем шаблонный ответ» против «ошибка в чате, обращение потеряно»; «Кто узнаёт первым» — «мониторинг» против «клиент»; «Срок реакции поставщика» — «4 часа по договору» против «когда ответят»; «Цена часа» — «7 140 ₽ ручного разбора» против «7 140 ₽ плюс потерянные обращения». Внизу общая подпись: «поток 6 000 обращений в месяц, пиковый час — 204 обращения». Чертёжный стиль, подписи по-русски.
Нагрузочный прогон перед запуском
Прогон делается на пиковом профиле, а не на среднем, и заканчивается не отчётом, а правками в системе. Успешным считается результат, при котором на 100 % пикового профиля в течение 30 минут нет ни одной ошибки лимита, девять ответов из десяти укладываются в обычное время, а на 150 % профиля система деградирует предсказуемо: очередь, потом шаблон, потом человек — и ни одного потерянного обращения.
Сравнивать эти 34 326 ₽ надо не с нулём, а с ценой часа сбоев. В пиковый час через процесс проходит 204 обращения; если половина из них уходит к людям, это 102 разбора по 6 минут — 10,2 часа операторов по ставке 700 ₽/час, то есть 7 140 ₽ за один час. Прогон окупается пятью часами предотвращённых сбоев, а на длинном ответе к тому же вылезает вторая проблема — латентность, которую на средней нагрузке не видно вовсе.
Когда о лимитах можно не думать
Расчёт пиковой минуты и нагрузочный прогон нужны не всегда. Четыре случая, где эти 34 326 ₽ честнее не тратить.
- Поток меньше 500 обращений в месяц. Пиковая минута там — меньше одного обращения, любой стартовый тариф покрывает её с многократным запасом. Достаточно один раз посмотреть в кабинете, какие лимиты у вас есть.
- Задача не в реальном времени. Ночная обработка архива, еженедельная выгрузка, разбор почты раз в час: если ответ никто не ждёт, очередь решает всё, и лимит превращается в вопрос длительности, а не работоспособности.
- Внутренний ассистент без клиентов снаружи. Двадцать сотрудников не создают пика, а если создают, задержка в минуту никому не мешает. Здесь дороже обходится контекстное окно, а не число запросов.
- Пилот, который заведомо перепишут. На пилоте проверяют гипотезу, а не эксплуатацию. Но решение «лимиты считать не будем» стоит записать в протокол вместе со сроком, когда к нему вернутся, — иначе пилот тихо станет промышленной системой.
Лимит поставщика — не техническая деталь, а описание того, что произойдёт с вашим клиентом в самый нужный момент. Поэтому его считают до запуска рекламы, а не после.
