# Открытая и закрытая модель нагрузки для inference API

Почему фиксированная конкурентность может скрыть перегрузку inference API и как сравнить открытый поток запросов с закрытой моделью в ограниченном тесте.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-open-closed-load-tests/
Language: ru

## Описать источник запросов

Нагрузочный тест измеряет не только сервер, но и способ создания работы. В закрытой модели фиксированное число клиентов начинает следующий запрос после завершения предыдущего. В открытой модели поступление задаётся независимо от длительности ответов. [Документация k6](https://grafana.com/docs/k6/latest/using-k6/scenarios/concepts/open-vs-closed/) объясняет это различие и проблему coordinated omission. Если генерация замедлилась, закрытый тест сам сокращает интенсивность, иногда скрывая накопление очереди, которое возникло бы при независимом пользовательском спросе. Оба режима полезны, но отвечают на разные вопросы. Поэтому число виртуальных клиентов без описания цикла отправки недостаточно для интерпретации графика задержек или оценки предельной пропускной способности.

## Удержать одинаковую полезную работу

Для сравнения сохраняют модель, распределение входной длины, лимиты вывода и набор режимов ответа. Иначе изменение token workload легко принять за эффект модели нагрузки. В одном опыте задают фиксированную конкурентность, в другом — ограниченное расписание arrivals. Значения являются параметрами эксперимента, а не рекомендацией для любой инфраструктуры. Для каждого режима заранее устанавливают максимальное время, число запросов, общий объём токенов и условие остановки по очереди. Тест не должен продолжать создавать работу бесконечно, когда сервис уже перестал принимать запросы. Отклонённые и неотправленные задания сохраняют отдельно от успешных, не удаляя их из отчёта.

## Проверить возможности генератора

Открытый сценарий требует, чтобы клиентская машина успевала выполнять расписание. Если ей не хватает соединений, процессорного времени или доступных исполнителей, фактические arrivals отстают от заданных. Это ещё не доказательство ограничения inference-сервера. Отчёт сравнивает запланированное, реально отправленное, принятое и завершённое количество запросов. Отдельно измеряют задержку самого генератора. В [рекомендациях Prometheus](https://prometheus.io/docs/practices/instrumentation/) полезно разделение текущей работы, завершений и ошибок. Для streaming также фиксируют момент начала и окончания чтения: быстро полученные заголовки не означают, что клиент успевает принимать весь поток без локального накопления данных в памяти.

## Сопоставить задержку и очередь

Диагностическая развилка начинается с фактической интенсивности. Если она снизилась вместе с ростом времени ответа в закрытом тесте, проверяют саморегулирование нагрузки. Если открытый тест сохраняет arrivals, а очередь растёт, исследуют admission, ограничения ресурсов и отказы. [Метрики vLLM](https://docs.vllm.ai/en/stable/usage/metrics/) дают примеры наблюдений на стороне движка, но их имена и доступность зависят от версии. Сравнивать только медиану завершённых ответов опасно: незавершённые запросы могут не попасть в выборку. Вместе с распределением задержки показывают число активных запросов на окончании опыта, причины остановки и долю отказов в соответствующем окне наблюдения.

## Ограничить выводы эксперимента

Артефакт включает расписание, фактические arrivals, состав workload, версии компонентов и правила учёта незавершённой работы. Полезны [команда vLLM bench serve](/ru/journal/vllm-bench-serve-command/) и [методика benchmark](/ru/journal/inference-benchmark-method/). Закрытый режим хорошо описывает фиксированную группу активных клиентов; открытый помогает исследовать независимое поступление заданий. Ни один короткий прогон не предсказывает автоматически коммерческий трафик, поведение всех моделей или длительную стабильность оборудования. Результат имеет смысл только вместе с ограничениями генератора и исследованным диапазоном нагрузки. Повторять опыт следует после объяснения расхождения, а не усреднять несовместимые режимы до одного привлекательного числа.