Если вы уже используете Triton-inference-server в производственной среде для обслуживания моделей глубокого обучения, вам может пригодиться Triton-model-analyzer, чтобы найти оптимальные параметры конфигурации для каждого модель, оптимизирующая пропускную способность и задержку. В этом посте я хочу рассказать о том, как я это делал и о своих результатах.
Модели глубокого обучения добились значительных успехов в ряде областей, от анализа изображений и видео до обработки естественного языка. Однако развертывание этих моделей в производственных средах может оказаться сложной задачей, особенно в больших масштабах. Одним из ключевых вопросов является пропускная способность моделей или количество прогнозов, которые они могут сделать за данный период времени.
Повышение производительности моделей глубокого обучения в производственной среде важно по ряду причин. Во-первых, это может помочь уменьшить задержку и улучшить взаимодействие с пользователем для приложений, которые полагаются на прогнозы в реальном времени. Это также может позволить более эффективно использовать ресурсы, такие как графические процессоры, которые могут быть дорогими при масштабировании.
Существует несколько способов повысить производительность моделей глубокого обучения в производственной среде, включая оптимизацию архитектуры модели, использование более эффективного оборудования и распараллеливание процесса прогнозирования. В этом посте мы рассмотрим одну стратегию повышения производительности моделей глубокого обучения в производственных средах.
Triton-inference-server — это высокопроизводительное программное обеспечение для обслуживания логических выводов с открытым исходным кодом, разработанное NVIDIA. Он позволяет пользователям развертывать обученные модели машинного обучения в производственной среде и обслуживать их по сети, предоставляя простой и масштабируемый способ предоставления прогнозов широкому кругу клиентов.
Triton-inference-server поддерживает большинство популярных платформ моделей, включая TensorFlow, PyTorch и ONNX. Он также предоставляет ряд функций для оптимизации производительности моделей в производстве, таких как динамическая пакетная обработка, ускорение графического процессора и поддержка параллельного и распределенного логического вывода.
Помимо обслуживания моделей машинного обучения, tritonserver поставляется с инструментом под названием Triton-model-analyzer. Этот инструмент предоставляет ряд функций, помогающих пользователям понять и оптимизировать производительность своих моделей.
Некоторые из функций, предлагаемых Triton-model-analyzer, включают анализ производительности модели, поиск оптимальных параметров и создание отчетов. Эти инструменты могут быть особенно полезны в производственных средах, где важно обеспечить определенную пропускную способность при определенных ограничениях.
Настраивать
Triton-model-analyzer упакован в виде образа Docker, и его тег совпадает с тегом основного сервера triton. Это означает, что версия инструмента Triton Model Analyzer совпадает с версией сервера triton, с которым он используется. Это обеспечивает совместимость и позволяет легко интегрировать инструмент с самим сервером.
Triton-model-analyzer может работать в четырех различных режимах:
- В локальном режиме по умолчанию модель-анализатор запускает tritonserver в текущей среде. Необходимо создать образ докера, который содержит исполняемые файлы анализатора модели и тритонсервера в одном образе докера (файл Docker предоставляется в репозитории).
- В режиме docker модель-анализатор извлечет и запустит док-контейнер tritonserver. Сокет Docker должен быть привязан как том, что вызовет проблемы при попытке запустить его в Kubernetes, хотя на локальном движке Docker он работает без проблем:
volumes: - /var/run/docker.sock:/var/run/docker.sock
- В удаленном режиме модель-анализатор попытается подключиться к существующему док-контейнеру tritonserver. Обратите внимание, что в этом режиме в настоящее время невозможно просматривать различные конфигурации моделей.
- режим C API аналогичен модели local, за исключением того, что запросы на вывод отправляются напрямую через C-API, а не через GRPC или HTTP.
Конфигурация поиска
Triton-model-analyzer поддерживает режимы грубой силы и быстрого поиска. В режиме грубой силы он будет охватывать все конфигурации модели за счет увеличения параллелизма. В быстром режиме он будет использовать алгоритм восхождения на холм, чтобы найти оптимальную конфигурацию при заданных ограничениях: это должно давать результаты быстрее и почти так же хорошо, как подход грубой силы .
Еще одна полезная функция – мультимодельный поиск сценариев, когда ряд моделей можно запускать параллельно. Веса и цели могут быть установлены по-разному для каждой модели. К сожалению, это не поддерживает развертку по количеству экземпляров, параллелизму или максимальному размеру пакета.
Также можно настроить последовательный поиск по нескольким моделям для одного запуска модели-анализатора. Этот подход имеет смысл, когда мы хотим оптимизировать каждую модель отдельно с различными параметрами конфигурации для количества экземпляров модели, динамической пакетной обработки или параллелизма. Пример конфигурации может выглядеть примерно так:
run_config_search_disable: False run_config_search_max_concurrency: 16 profile_models: my_classifier: model_config_parameters: max_batch_size: [1, 4, 8, 16] dynamic_batching: max_queue_delay_microseconds: [100, 1000, 2000] instance_group: - kind: KIND_GPU count: [1, 2, 3] my_detector: model_config_parameters: max_batch_size: [1, 4, 8] dynamic_batching: max_queue_delay_microseconds: [100, 1000, 2000] instance_group: - kind: KIND_GPU count: [1, 2]
В приведенном выше примере Triton-model-analyzer будет охватывать 37 конфигураций для my-classifier и 19 конфигураций для my-detector с различными значениями динамического пакетирования, максимальным размером пакета и экземплярами модели. Количество одновременных запросов будет экспоненциально увеличиваться с 1 до 2, 4, 8 и 16 или до тех пор, пока пропускная способность не перестанет расти.
Полученные результаты
Мы обучили модель детектора (семейство yolov5) работать с потоком изображений и модель классификатора (семейство efficientnet), чтобы определять, какой объект в каждой ограничивающей рамке. Хотя эти модели уже достаточно быстры во время логического вывода, мы хотели дать им дополнительный импульс для увеличения количества данных, обрабатываемых в производственной среде.
К счастью, репозиторий Triton-model-analyzer уже предоставляет диаграммы управления для запуска анализа в кластере Kubernetes. После нескольких настроек мне удалось запустить его на нашем сервере разработки с графическим процессором Tesla T4. Однако для этого потребовалось создать образ Docker, содержащий исполняемые файлы tritonserver, model-analyzer и perf_analyzer, поскольку только Для kubernetes был доступен локальный режим запуска. Моя команда запуска выглядела так:
containers: name: analyzer image: "{{ .Values.images.analyzer.image }}:{{ .Values.images.analyzer.tag }}" args: [ "/bin/bash", "-c", "model-analyzer profile --model-repository /models --output-model-repository-path /output_models/output --override-output-model-repository --checkpoint-directory /checkpoints/ --triton-launch-mode local --config-file /config/config.yaml --export-path /results"] volumeMounts: - name: data mountPath: /results subPath: triton_model_analyzer/results - name: data mountPath: /models subPath: models - name: data mountPath: /output_models subPath: triton_model_analyzer/output_models - name: data mountPath: /checkpoints subPath: triton_model_analyzer/checkpoints - name: config mountPath: /config resources: limits: cpu: "1" memory: "4Gi" nvidia.com/gpu: "1" volumes: - name: data persistentVolumeClaim: claimName: <YOUR_PVC> - name: config configMap: name: analyzer-config runtimeClassName: nvidia
Выше приведен отрывок из файла job.yaml, находящегося в папке helm-chart/templates. Это означает, что имя образа docker и значения тега указаны в файле values.yaml, а ваш PVC содержит подпапку models, где модели поиска хранятся в формате triton. Результаты будут доступны после завершения во вложенной папке triton_model_analyzer.
Результаты включают сводный отчет в формате PDF для каждой модели и файл csv со всеми измерениями. Отчет в формате pdf представляет собой очень описательный обзор лучших конфигураций модели и сравнение с измерением по умолчанию. При более глубоком анализе производительности можно также создавать более подробные отчеты.
В нашем случае классификатор достиг пропускной способности 138 выводов в секунду, что обеспечило улучшение на 14% по сравнению с конфигурацией по умолчанию. Детектор выдал 49 логических выводов в секунду с приростом 22 % по сравнению с настройками по умолчанию. Лучшая конфигурация выглядела так:
# detector config.pbtxt name: "my_detector" max_batch_size: 4 instance_group { count: 2 kind: KIND_GPU } dynamic_batching { preferred_batch_size: 4 max_queue_delay_microseconds: 100 } backend: "onnxruntime" # ======================== # classifier config.pbtxt name: "my_classifier" max_batch_size: 4 instance_group { count: 2 kind: KIND_GPU } dynamic_batching { max_queue_delay_microseconds: 2000 } backend: "onnxruntime"
Заключение
В целом Triton Inference Server — это мощный инструмент для развертывания и обслуживания моделей машинного обучения в производственной среде. Предоставляя простой и масштабируемый способ обслуживания прогнозов, он позволяет организациям создавать и развертывать интеллектуальные приложения, которые могут повысить ценность бизнеса.
С помощью Triton-model-analyzer можно еще больше повысить производительность логического вывода, найдя оптимальную конфигурацию модели. К счастью, модель-анализатор предоставляет набор функций для сквозного анализа, в том числе:
- установка докера или пипа
- конфигурация поиска, включая поиск по нескольким моделям и оптимизацию определенных показателей при определенных ограничениях
- контрольно-пропускной пункт
- развертывание кубернетов
В этом посте мы увидели, как Triton-model-analyzer может повысить производительность наших моделей, обслуживаемых Triton-inference-server. Если это было для вас полезно, не стесняйтесь поделиться с единомышленниками.
Это сообщение было частично сгенерировано с помощью chatGPT.