Мы все учимся создавать модели машинного обучения, но очень мало осведомлены о том, как их развертывать и о том, в какой степени это влияет на решения, которые мы принимаем на этапе разработки модели.
Даже если ваша модель проходит все ваши метрики точности и если нет дрейфа данных или модели, все еще есть большая вероятность, что ваша модель может не соответствовать ожиданиям в производственной среде. Одной из причин этого может быть то, что ваша модель не может обрабатывать и обслуживать запросы в режиме реального времени.
Оценка и выбор модели машинного обучения для рабочей среды включает не только показатели прогнозирования, но и эксплуатационные/инфраструктурные затраты и задержку.
Попробуем разобраться в этом на примере Развертывание этих моделей в контейнере.
Эксплуатационные/инфраструктурные затраты — это затраты на выделение инфраструктурных ресурсов, необходимых для поддержания определенной задержки с учетом входного уровня запросов API (SLA — соглашение об уровне обслуживания).
Ресурсы, влияющие на общее время ответа модели =
- Масштабирование по вертикали — ресурсы CPU/GPU (vCPU) и память
- Масштабирование по горизонтали —нет узлов, на которых работает контейнер.
Общее затраченное время/время обработки = время, затраченное на то, чтобы конкретный запрос был предоставлен в качестве входных данных для модели + время, затраченное на выполнение логического вывода + постобработка
Масштабирование по вертикали. Развертывание этих моделей в виде контейнера требует определения запросов и ограничений ЦП/ГП и памяти. Эти инфраструктурные ресурсы можно рассчитать, но с помощью нагрузочных тестов, то есть путем параллельного воздействия на модель с разной скоростью ввода.
Например 10 запросов в секунду, 50 запросов в секунду…. на основе SLA, которое требуется для поддержки. Это можно сделать с помощью Vegeta или Locust — инструментов, помогающих имитировать тестирование в продакшене. Это указывает на то, сколько запросов модель может обрабатывать и обрабатывать параллельно, и какова задержка получения прогноза.
Выходы Вегета:
min— минимальная задержка всех запросов при атаке.mean— среднее арифметическое/среднее задержек всех запросов в атаке.50,90,95,99— 50-й, 90-й, 95-й и 99-й процентили соответственно латентности всех запросов в атаке.max— максимальная задержка всех запросов в атаке.
Эти измерения помогут вам понять, нужно ли вам выделять больше ресурсов для вашей модели, например, в случае, когда средняя задержка выше, чем указано в SLA.
Увеличение инфраструктурных ресурсов определенно уменьшит задержку, но только до определенного предела, после которого задержка будет насыщена для вывода, поскольку выделенных ресурсов больше, чем требуется.
Общее время обработки увеличится, хотя время вывода будет таким же, поскольку задержка будет медленно увеличиваться, если скорость обработки ‹ скорость входных запросов. Помните, что мы по-прежнему используем только один экземпляр, поэтому все вводимые данные обрабатываются моделью последовательно. Таким образом, когда скорость обработки ‹ скорость входных запросов, время, необходимое для того, чтобы конкретный запрос был предоставлен в качестве входных данных для модели, будет постепенно увеличиваться, увеличивая задержку вывода.
Горизонтальное масштабирование. Горизонтальное масштабирование обеспечивает параллельную обработку нескольких экземпляров. Скажем, если один экземпляр может обработать один запрос за 1 секунду, то 10 экземпляров могут обработать 10 запросов за 1 секунду, поскольку они будут обрабатывать их одновременно. Это уменьшает фактор задержки, который появляется, когда существует только один экземпляр. Но в этом случае есть момент, когда скорость ввода составляет 10 запросов в секунду и есть 15 экземпляров, тогда время все равно будет равно 1 секунде, а затем задержка снова насыщается.
Таким образом, тестирование производительности играет важную роль в понимании компромисса между стоимостью и SLA.
Задержка
На этапе разработки модели необходимо принимать решения, основанные на времени обработки и задержке. Существуют различные современные модели, которые можно использовать для варианта использования, но компромисс может быть слишком дорогим с очень небольшим увеличением показателей точности. Например, вывод Yolact можно сделать с использованием ЦП, но если мы используем более крупную модель, такую как HRnet, может потребоваться ГП или ЦП большего размера для соответствия той же задержке с небольшой разницей в показателях производительности.
Таким образом, компромисс между размером стоимости развертывания и точностью играет огромную роль при выборе модели для конкретного варианта использования.
