РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-06
Очередь запросов к LLM API: как ограничить параллельную нагрузку
Неограниченный запуск задач может перегрузить клиент ещё до ответа сервиса. Разберём очередь, число активных вызовов и контроль отказных сценариев.
Ограничьте число активных вызовов и размер ожидающей очереди отдельно от rate limit по запросам и токенам. Задайте срок ожидания, отмену и правила повторов. Семафор управляет одновременными задачами, но сам по себе не гарантирует соблюдение RPM, TPM или бюджета внешнего сервиса.
1. Разделите ограничения
Запишите, сколько запросов может быть активно, сколько допустимо запускать за период и как учитываются токены. Лимиты метода могут относиться к проекту, ключу или модели; сверяйте область по документации фактического сервиса. Один длинный вызов занимает слот иначе, чем короткий, а одинаковое число запросов может иметь разный токенный расход. Семафор регулирует число одновременных операций, rate limiter — темп их запуска. Ни один из них не заменяет финансовый бюджет. Не увеличивайте внешние или денежные лимиты ради демонстрации производительности очереди.
2. Ограничьте ожидание и размер очереди
Определите максимальное число ожидающих заданий и срок, после которого задача уже не нужна пользователю. При заполнении возвращайте понятный статус, а не сохраняйте бесконечный список в памяти процесса. Различайте ожидание до отправки и таймаут уже отправленного вызова: у них разные последствия. Для долгих задач используйте устойчивое хранилище, если сценарий требует переживать перезапуск. Не называйте принятие задания завершением обработки. Пользователь должен видеть предусмотренные состояния и иметь возможность отменить ещё не отправленную задачу без запуска лишней генерации.
3. Проверьте освобождение слотов
Захват и освобождение слота должны работать при успехе, исключении и отмене. Для asyncio используйте примитивы согласно их области применения; локальный семафор одного процесса не управляет другими экземплярами. Для распределённого приложения отдельно определите общий контроль запуска и восстановление после сбоя воркера. Не держите слот занятым бесконечно при потерянном соединении. Если задача передана сервису, локальная отмена не всегда доказывает остановку его работы. Сохраняйте идентификатор вызова и фактическое состояние вместо автоматической повторной отправки неизвестно завершившейся операции.
4. Обработайте перегрузку без лавины повторов
Для временного отказа предусмотрите ограниченные повторы и задержку по контракту сервиса. Не позволяйте каждому воркеру независимо повторять запрос без учёта общего лимита. Повтор возвращается в тот же управляемый процесс, а не обходит очередь. Для операций с побочными эффектами соблюдайте правила идемпотентности. Если сервис передаёт допустимое время ожидания, используйте его в рамках максимального срока задачи. Увеличение числа параллельных вызовов после 429 без анализа причины может ухудшить ситуацию. Готовый результат и ошибка модели не должны маскироваться под транспортный таймаут.
5. Измерьте очередь и выполните offline-приёмку
Смотрите число ожидающих и активных задач, время в очереди, длительность вызова и причины отказов отдельно. На mock transport проверьте всплеск нагрузки, заполнение очереди, отмену, исключение, освобождение слота и ограничение повторов. Это доказывает работу диспетчера, но не пропускную способность реального поставщика. Для сетевого нагрузочного теста нужен отдельный согласованный бюджет и условия сервиса. В Tokenmost соблюдайте текущие лимиты проекта и опубликованный контракт API. Материал не предлагает их менять: сначала проверьте архитектуру клиента и прозрачные состояния на локальных fixtures.
Частые вопросы
Семафор гарантирует отсутствие 429?
Нет. Он ограничивает одновременность, а сервис может ограничивать темп запросов, токены и другие параметры. Нужен контроль соответствующих лимитов.
Очередь можно оставить без предела?
Нет для управляемого приложения. Задайте размер, срок ожидания и поведение при заполнении, чтобы перегрузка не стала неконтролируемым накоплением.
Отмена клиента означает остановку генерации?
Не автоматически. Проверяйте возможности отмены и фактическое состояние у сервиса; локальное закрытие соединения не является подтверждением.
Что доказывает тест с mock API?
Правильность очереди, слотов, отмены и повторов в проверенных условиях. Реальную пропускную способность, стоимость и доступность модели он не подтверждает.