Для проведения всех этапов тестирования система должна соответствовать следующим требованиям:
Рекомендуется запускать генератор нагрузки на том же узле, где и проводятся тесты. Создаваемая им нагрузка на локальном узле меньше, чем вероятные помехи и нагрузка при запуске на удаленном хосте.
Хорошим критерием является наличие ядер CPU, загруженных менее чем на 20% во время теста.
Действия для запуска тестов MLPerf содержат команды автоматизации следующего вида:
make run RUN_ARGS="…"
Данная команда производит компиляцию TensorRT engine и затем запускает генератор нагрузки и прочие элементы. При необходимости, данные действия можно разбить на два этапа: компиляция и генератор нагрузки. Далее приведены инструкции, как выполнять каждый этап раздельно.
Для выполнения этапа компиляции необходимо выполнить следующую команду:
make generate_engines
Для запуска генератора нагрузки при условии, что TensorRT engine уже скомпилированы, необходимо выполнить следующую команду:
make run_harness
По умолчанию, переменная «RUN_ARGS» содержит параметр, отвечающий за проверку и производительности и скорости:
--test_mode=SubmissionRun
Для измерения производительности следует указать
--test_mode=PerformanceOnly
Для измерения аккуратности следует указать
--test_mode=AccuracyOnly
Перед началом проведения работ по тестированию необходимо произвести установку необходимых компонентов и первичную настройку:
#runfile-nouveau-ubuntu
$ sudo add-apt-repository ppa:graphics-drivers/ppa $ sudo apt-get update $ sudo apt-get install nvidia-driver-418\\ $ sudo reboot
$ sudo apt install -y git
$ curl -s -L \ https://nvidia.github.io/nvidia-container-runtime/gpgkey | \ sudo apt-key add – $ distribution=$(. /etc/os-release;echo $ID$VERSION_ID) $ curl -s -L \ https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list | \ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list $ sudo apt-get update $ sudo apt install -y nvidia-container-runtime $ sudo systemctl restart docker
Перед началом проведения работ по тестированию необходимо произвести установку необходимых компонентов и первичную настройку:
$ sudo yum install -y git
$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID) $ curl -s -k -L \ https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.repo | \\\ sudo tee /etc/yum.repos.d/nvidia-container-runtime.repo $ sudo yum install -y nvidia-container-runtime\\ $ sudo systemctl restart docker
Для завершения первичной настройки необходимо выполнить следующие шаги:
{ "default-runtime":"nvidia", "runtimes": { "nvidia": { "path": "nvidia-container-runtime", "runtimeArgs": [] } } }
"data-root": "/path/to/docker/images"
$ sudo systemctl restart docker
$ sudo systemctl --now enable nvidia-persistenced\\ $ sudo nvidia-smi -e 0\\ $ sudo shutdown -r 0
$ nvidia-smi -i 0 -q -d SUPPORTED_CLOCKS | grep Memory | head -n 1
$ nvidia-smi -i 0 -q -d SUPPORTED_CLOCKS |grep Graphics |head -n 1
$ sudo nvidia-smi -ac <частота памяти в МГц>,<частота GPU в МГц>
$ nvidia-smi -i 0 -q -d SUPPORTED_CLOCKS|grep Memory | head -n 1 Memory : 3003 MHz $ nvidia-smi -i 0 -q -d SUPPORTED_CLOCKS|grep Graphics| head -n 1 Graphics : 1531 MHz $ sudo nvidia-smi -ac 3003,1531\\ Applications clocks set to "(MEM 3003, SM 1531)" for GPU 00000000:03:00.0 All done.
На данном этапе производятся подготовительные работы по созданию основным компонентов повторяющихся тестов:
$ mkdir -p ~/mlperf_gnmt/compose
$ cd ~/mlperf_gnmt/
$ git clone https:%%//%%github.com/mlperf/inference_results_v0.5.git
$ cp compose/Dockerfile.original.replacement inference_results_v0.5/closed/NVIDIA/docker/Dockerfile
$ cd compose
$ sudo docker-compose build
ENV GIT_SSL_NO_VERIFY\\ RUN echo "check_certificate = off" >> ~/.wgetrc
Для воспроизведения тестов в режиме «Offline» рекомендуется использовать эталонную конфигурацию оборудования с четырьмя, восьмью или двадцатью GPU NVIDIA Tesla T4. Полное описание систем доступно по ссылкам в таблице:
Эталонные результаты теста MLPerf Inference для систем выше приведены в следующей таблице (полная таблица доступна по ссылке: https://mlperf.org/inference-results/)
ResNet | GNMT | |
---|---|---|
4 x Tesla T4 | 22438.00 | 1417.62 |
8 x Tesla T4 | 44977.80 | 2834.75 |
20 x Tesla T4 | 113592.00 | 7154.88 |
Для определения удельных результатов системы на одном GPU, в следующей таблице приведены результаты тестов, разделённые на количество GPU:
ResNet | GNMT | |
---|---|---|
4 x Tesla T4 | 5609.50 | 354.41 |
8 x Tesla T4 | 5622.23 | 354.34 |
20 x Tesla T4 | 5679.60 | 357.74 |
Таким образом наблюдается почти линейное масштабирование результатов бенчмарка с количеством GPU. Аппаратные отличия тестируемых конфигураций, от конфигураций выше, могут приводить к снижению производительности до 30%.
По завершению каждого теста необходимо остановить контейнер, иcпользуя следующие действия:
$ sudo docker-compose up
$ sudo docker-compose down
Для проведения теста «MLPerf Inference GNMT» в режиме «Offline» следует выполнить следующие действия:
$ sudo docker-compose up
**«~/mlperf_gnmt/compose»**. $ cd ~/mlperf_gnmt/compose
$ sudo docker-compose exec mlperf-gnmt /bin/bash
$ ./download_dataset.sh
make run RUN_ARGS="--benchmarks=gnmt --scenarios=Offline --test_mode=SubmissionRun"
По окончанию тестирования будет выдан результат исполнения. В качестве единицы измерения принимается показатель «количество сэмплов в секунду». Будет выведено сообщение о статусе тестирования на точность.
По завершению всех операций останавливаем контейнер, как указано в разделе Проведение тестирования для режима «Offline».
Для проведения теста «MLPerf Inference ResNet» в режиме «Offline» следует выполнить следующие действия:
$ mkdir -p /tmp/preprocessed_data
$ cd ~/mlperf_gnmt/compose
- /tmp/preprocessed_data:/work/build/preprocessed_data - "/mnt/hdd/datasets/imagenet:/work/build/data/imagenet"
$ sudo docker-compose up
$ cd ~/mlperf_gnmt/compose
$ sudo docker-compose exec mlperf-gnmt /bin/bash
$ cd /work
$ python3 scripts/preprocess_data.py -d build/data -o build/preprocessed_data \ -b resnet --val_only -t fp32 $ python3 scripts/preprocess_data.py \ -d build/data -o build/preprocessed_data \ -b resnet --val_only
$ make run RUN_ARGS="--benchmarks=resnet --scenarios=Offline --test_mode=SubmissionRun "
По окончанию тестирования будет выдан результат исполнения. В качестве единицы измерения принимается показатель «количество сэмплов в секунду». Будет выведено сообщение о статусе тестирования на точность.
По завершению всех операций останавливаем контейнер, как указано в разделе Проведение тестирования для режима «Offline».
Для воспроизведения тестов в режиме «Server» рекомендуется использовать эталонную конфигурацию с четырьмя, восьмью или двадцатью GPU NVIDIA Tesla T4. Полное описание систем доступно по ссылкам в таблице:
Эталонные результаты теста MLPerf Inference для систем выше приведены в следующей таблице (полная таблица доступна по ссылке: https://mlperf.org/inference-results/)
ResNet | GNMT | |
---|---|---|
4 x Tesla T4 | 20742.83 | 828.57 |
8 x Tesla T4 | 41546.64 | 1581.20 |
20 x Tesla T4 | 103532.10 | 3776.07 |
Для определения удельных результатов системы на одном GPU, в следующей таблице приведены результаты тестов, разделённые на количество GPU:
ResNet | GNMT | |
---|---|---|
4 x Tesla T4 | 5185.71 | 207.14 |
8 x Tesla T4 | 5193.33 | 197.65 |
20 x Tesla T4 | 5176.61 | 188.80 |
Таблица 1. Удельные показатели системы на одном GPU
Таким образом наблюдается почти линейное масштабирование результатов бенчмарка с количеством GPU. Аппаратные отличия тестируемых конфигураций, от конфигураций выше, могут приводить к снижению производительности до 30%.
По завершению каждого теста необходимо остановить контейнер, иcпользуя следующие действия:
$ sudo docker-compose up
$ sudo docker-compose down
Тестирование в режиме «Server» подразумевает, что результаты валидны только если от постановки каждого сэмпла в очередь до поучения ответа проходило бы меньше времени, чем заданное пороговое значение, которое можно найти в таблице
Основные параметры, влияющие на прохождение теста системой, описаны в данной секции, Таблица 2. Файл gnmt/Server/config.json и Таблица 4. Файл resnet/Server/config.json. Дополнительные параметры также могут иметь влияние на производительность и на валидность бенчмарка. Более подробное описание влияния параметров на производительность и валидность теста, и алгоритм подбора оптимальных содержатся в документе https://github.com/mlperf/inference_results_v0.5/blob/master/closed/NVIDIA/performance_tuning_guide.adoc
Валидность результатов обозначается словом «VALID» в выводе, невалидность словом «INVALID». Для получения валидных результатов необходимо задать подходящие для системы параметры тестирования.
Основной параметр, влияющий на валидность результатов — «server_target_qps», целевое количество запросов в секунду, которое будет отсылать генератор нагрузки. Частично код, который уточняет это значение с помощью бинарного поиска инкорпорирован в сам генератор нагрузки LoadGen1), однако результаты теста зависят от исходного значения.
Получение валидных результатов не гарантирует, что получены максимальные возможные результаты тестирования, так как они зависят от многих параметров, указанных в конфигурационных файлах, и при некоторых комбинациях могут быть валидными, но заниженными. Заниженными считаются результаты, при которых можно увеличить значение «server_target_qps» на 5% и подобрать такую конфигурацию параметров, что пять запусков теста подряд выдадут валидные результаты.
make run RUN_ARGS="--benchmarks=gnmt --scenarios=Server --test_mode=SubmissionRun "
Если результаты невалидны, изменим параметр «server_target_qps» и иные параметры в конфигурационных файлах. Основные параметры, влияющие на результат описаны в таблицах ниже.
Параметр | Ключ | Описание |
---|---|---|
server_target_qps | gnmt → server_target_qps | Целевое значение количества обрабатываемых семплов в секунду. Если указано слишком большое значение, не все запросы будут вовремя выполнены и результат тестирования окажется невалидным. Если указано слишком маленькое значение, результат тестирования будет валиден, но занижен. Изначальное значение рекомендуется выбирать по Таблица 1. Удельные показатели системы на одном GPU. Частично код, который уточняет это значение с помощью бинарного поиска инкорпорирован в сам генератор нагрузки LoadGen2), однако результаты теста зависят от исходного значения. |
batch_sizes | gnmt → batch_sizes | Количество сэмплов, которые собираются в один батч для отправки на GPU. Могут компилироваться несколько возможных batch_size одновременно. |
concurrency | gnmt → concurrency | Количество одновременно исполняющихся на GPU батчей инференса. |
precision | gnmt → precision | Аппаратная точность вычислений. |
Таблица 2. Файл gnmt/Server/config.json
Параметр | Ключ | Описание |
---|---|---|
server_target_qps | *.Server.target_qps | Значение необходимо устанавливать в точноcти равным значению в файле gnmt/Server/config.json. Смотри Таблица 2. Файл gnmt/Server/config.json |
Остальные параметры | Заданы правилами MLPerf и не подлежат изменению. |
Таблица 3. Файл gnmt/Server/user.conf
Для редактирования файлов:
$ cd ~/mlperf_gnmt/compose
$ sudo docker-compose exec mlperf-gnmt /bin/bash
make run RUN_ARGS="--benchmarks=resnet --scenarios=Server --test_mode=SubmissionRun "
По окончанию тестирования будет выдан результат исполнения. В качестве единицы измерения принимается показатель «количество сэмплов в секунду». Будет выведено сообщение о том, успешно ли система прошла тест на точность и сообщение, валидны результаты или невалидны.
Если результаты невалидны, изменим параметр «server_target_qps» и иные параметры в конфигурационных файлах. Основные параметры, влияющие на результат описаны в таблицах ниже.
Параметр | Ключи | Описание |
---|---|---|
server_target_qps | resnet → server_target_qps | Целевое значение количества обрабатываемых семплов в секунду. Если указано слишком большое значение, не все запросы будут вовремя выполнены и результат тестирования окажется невалидным. Если указано слишком маленькое значение, результат тестирования будет валиден, но занижен. Изначальное значение рекомендуется выбирать по Таблица 1. Удельные показатели системы на одном GPU. Частично код, который уточняет это значение с помощью бинарного поиска инкорпорирован в сам генератор нагрузки LoadGen3), однако результаты теста зависят от исходного значения. |
deque_timeout_us | resnet → deque_timeout_us | Только для бенчмарка resnet. Число миллисекунд, после которого на GPU в любом случае отправляется батч, даже если он ещё не заполнился запросами целиком |
gpu_batch_size | resnet → gpu_batch_size | Количество сэмплов, которые собираются в один батч для отправки на GPU. |
gpu_inference _streams | resnet → gpu_inference _streams | Количество одновременно исполняющихся на GPU батчей инференса. |
Таблица 4. Файл resnet/Server/config.json
Параметр | Ключ | Описание |
---|---|---|
server_target_qps | *.Server.target_qps | Значение необходимо устанавливать в точноcти равным значению в файле resnet/Server/config.json. Смотри Таблица 4. Файл resnet/Server/config.json |
Остальные параметры | Заданы правилами MLPerf и не подлежат изменению. |
Таблица 5. Файл resnet/Server/user.conf
Для редактирования файлов:
$ cd ~/mlperf_gnmt/compose
$ sudo docker-compose exec mlperf-gnmt /bin/bash
Для выполнения теста «Kaldi» необходимо проделать следующие действия:
$ docker run --gpus all -it --ipc=host --name kaldi nvcr.io/nvidia/kaldi:20.03-py3
$ cd /workspace/nvidia-examples/librispeech/
$ ./prepare.sh
$ ./run_benchmark.sh
$ ./run_multigpu_benchmark.sh
По окончанию тестирования будет выдан результат тестирования в режиме полной загрузки. В качестве единицы измерения пропускной способности принимается показатель «ускорение относительно реального времени» (RTF, Real Time Factor), который измеряет отношение между длительностью всех распознанных во время бенчмарка фраз и временем, затраченным на их распознавание. В качестве единицы измерения точности применяется WER (Word Error Rate) — среднее нормированное расстояние Левенштейна в словах между сказанными и предсказанными фразами. Будет выведено сообщение о том, успешно ли система прошла тест на точность и сообщение, валидны результаты или невалидны.
Проведём в том же контейнере тест «Kaldi» в онлайн сценарии, когда на сервер генерируется динамическая нагрузка и измеряется не только пропускная способность, но и задержки. Результаты теста зависят от параметра «ONLINE_NUM_PARALLEL_STREAMING_CHANNELS» — целое число, количество одновременно транслируемых на сервер каналов. Значение этого параметра необходимо вычислить по формуле
числоканалов > floor(RTF \ast 0.8)$**,**
где RTF ускорение относительно реального времени, измеренное в пункте 5.
$ ONLINE=1 ONLINE_NUM_PARALLEL_STREAMING_CHANNELS=<число каналов> \ ./run_benchmark.sh
$ ONLINE=1 ONLINE_NUM_PARALLEL_STREAMING_CHANNELS=<число каналов> \ ./run_multigpu_benchmark.sh
По окончанию тестирования будет выдан результат исполнения. В качестве единицы измерения задержки принимается показатель «95-й перцентиль задержки» (Latency @ 95%), который измеряет время между отправкой фрагмента на распознавание и получением распознанного фрагмента в секундах при количестве запросов, установленном на 80% от пропускной способности в режиме полной загрузки. Будет выведено сообщение о том, успешно ли система прошла тест на точность и сообщение, валидны результаты или невалидны.
Для получения наилучших результатов тестов рекомендуется проводить измерения без использования мониторинга.
При необходимости получения данных по мониторингу, рекомендуется производить запуск тестов в два прохода: с включенным мониторингом и без него.
Рекомендуется использовать DCGM для наблюдения за GPU. Документация с описанием процесса установки доступна по ссылке (скачать данный пакет можно по адресу: https://developer.nvidia.com/dcgm): https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-user-guide/getting-started.html#installation
Для получения результатов мониторинга в формате Prometheus, рекомендуется использовать следующий репозиторий и код: https://github.com/NVIDIA/gpu-monitoring-tools/tree/master/dcgm-exporter
Система мониторинга Zabbix версии 4.2 и выше поддерживает сбор данных в формате Prometheus: https://www.zabbix.com/documentation/4.2/manual/config/i"tems/itemtypes/prometheus
Сбор метрических данных можно осуществлять при помощи утилиты «nvidia-smi» . Пример команды сбора различных метрик раз в секунду в csv файл ~/mlperf_gnmt/nvidia-smi-metrics.csv приведен ниже:
nvidia-smi \--query-gpu=timestamp,name,pci.bus_id,driver_version,pstate,pcie.link.gen.max,pcie.link.gen.current,temperature.gpu,power.draw,power.limit,utilization.gpu,utilization.memory,memory.total,memory.free,memory.used --format=csv -l 1 | \ tee -a ~/mlperf_gnmt/nvidia-smi-metrics.csv
Интерактивный вариант отображения метрических данных можно производить следующей командой:
nvidia-smi dmon
Copyright: НИИ МАСШТАБ