Средняя задержка ML API хорошая, p95 плохой: что меняет размер батча

Команда увеличила размер батча для модели, и GPU стал работать эффективнее. Среднее время вычисления на один объект уменьшилось, но пользователи начали жаловаться на редкие долгие ответы. Между поступлением запроса и запуском модели появилась очередь: запрос ждёт, пока соберётся пакет. Если мерить только время вычисления, улучшение выглядит бесспорным; пользователь ощущает всю цепочку.

Считайте время от входа запроса до ответа

Для каждого запроса запишите момент получения, ожидание батча, время preprocessing, инференса и формирования ответа. p95 означает порог, ниже которого в наблюдаемом окне лежат примерно 95% длительностей. Метод интерполяции квантиля должен быть одинаковым в сравниваемых отчётах. В миниатюрном следе ниже 20 запросов: 18 быстрых и два медленнее. Сравним среднее и p95 двух вариантов настройки; числа учебные, не измерения оборудования.

import numpy as np

small_batch_ms = np.array([20.0] * 20)
large_batch_ms = np.array([8.0] * 18 + [40.0, 180.0])
for name, values in (("малый", small_batch_ms), ("большой", large_batch_ms)):
    print(name, "mean:", round(float(values.mean()), 2),
          "p95:", round(float(np.percentile(values, 95)), 2))
assert large_batch_ms.mean() < small_batch_ms.mean()
assert np.percentile(large_batch_ms, 95) > np.percentile(small_batch_ms, 95)

В учебном следе среднее падает с 20 до 18,2 мс, а p95 растёт с 20 до 47 мс. Два медленных запроса из двадцати меняют хвост сильнее, чем среднее. На стенде нужно измерить несколько размеров батча при одинаковой нагрузке и длине окна; эти искусственные числа не позволяют выбрать размер батча для настоящего сервиса.

У батчинга два разных выигрыша: больше объектов за один вызов модели и меньше накладных расходов на один объект. Оба могут сосуществовать с увеличением времени ответа конкретного запроса. При низком потоке запрос ждёт заполнения пакета, при высоком — очередь может расти из-за насыщения устройства. Поэтому вместе с p95 смотрите глубину очереди, время ожидания и утилизацию исполнителя. Настройка max batch size без max wait time оставляет хвост плохо управляемым; предел ожидания делает поведение более предсказуемым при вечернем спаде трафика.

Как выбрать режим

Разделите время ожидания пакета и вычисления. Если задержка формируется в очереди, ограничьте максимальное ожидание или размер пакета, затем повторите замер. Сравнивайте p50, p95, пропускную способность и долю ошибок вместе; ускорение отдельных операций может ухудшить время пользовательского ответа. Особенно важно проверять низкую нагрузку: при редких запросах крупный батч заполняется дольше.

На двадцати измерениях p95 нестабилен: новая медленная заявка резко передвинет оценку. Для релизного сравнения соберите достаточно запросов в одинаковых условиях, покажите число наблюдений и доверяйте не одному измерению, а серии прогонов. Разбейте задержки по размерам входа и времени суток. Если крупные запросы стали чаще во втором прогоне, рост p95 нельзя целиком приписать батчингу. Метрику пользователя и метрику времени самой модели храните раздельно.

В курсе «Data Scientist: от данных до деплоя моделей» есть model serving и мониторинг после релиза. Откройте программу курса, если хотите связать метрику качества модели с измеряемой работой сервиса.