Для проведения всех этапов тестирования система должна соответствовать следующим требованиям:
Рекомендуется запускать генератор нагрузки на том же узле, где и проводятся тесты. Создаваемая им нагрузка на локальном узле меньше, чем вероятные помехи и нагрузка при запуске на удаленном хосте.
Хорошим критерием является наличие ядер 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
Перед началом проведения работ по тестированию необходимо произвести установку необходимых компонентов и первичную настройку:
Отключаем драйвер «nouveau», согласно инструкции: https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#runfile-nouveau-ubuntu
#runfile-nouveau-ubuntu
$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt-get update
$ sudo apt-get install nvidia-driver-418
$ sudo reboot
</code>
Устанавливаем пакет «git»
$ 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
</code>
Перед началом проведения работ по тестированию необходимо произвести установку необходимых компонентов и первичную настройку:
Устанавливаем пакет «git»
$ 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
</code>
Для завершения первичной настройки необходимо выполнить следующие шаги:
{
“default-runtime”:“nvidia”,
“runtimes”: {
“nvidia”: {
“path”: “nvidia-container-runtime”,
“runtimeArgs”: []
}
}
} </file>
При необходимости изменения места хранения образов docker следует добавить в файл:
"data-root": "/path/to/docker/images"
После чего сервис «docker» должен быть перезагружен
$ sudo systemctl restart docker
$ sudo systemctl –now enable nvidia-persistenced
$ sudo nvidia-smi -e 0
$ sudo shutdown -r 0
</code>
Для получения максимальной частоты памяти
$ nvidia-smi -i 0 -q -d SUPPORTED_CLOCKS | grep Memory | head -n 1
Для получения максимальной частоты GPU
$ 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.
</code>
На данном этапе производятся подготовительные работы по созданию основным компонентов повторяющихся тестов:
Создаем папку «compose»
$ mkdir -p ~/mlperf_gnmt/compose
Переходим в общий каталог теста «mlperf_gnmt»
$ cd ~/mlperf_gnmt/
Клонируем основной репозиторий «mlperf inference results»
$ git clone https:%%//%%github.com/mlperf/inference_results_v0.5.git
$ cp compose/Dockerfile.original.replacement inference_results_v0.5/closed/NVIDIA/docker/Dockerfile </code>
Переходим в папку
$ cd compose
Произвести сборку docker-образа
$ 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» следует выполнить следующие действия:
Запускаем docker-образ
$ sudo docker-compose up
$ cd ~/mlperf_gnmt/compose </code>
Подключаемся к контейнеру
$ 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» следует выполнить следующие действия:
Создаём папку /tmp/preprocessed_data
$ mkdir -p /tmp/preprocessed_data
Переходим в общий каталог теста «~/mlperf_gnmt/compose»
$ cd ~/mlperf_gnmt/compose
</code>
Запускаем docker-образ
$ sudo docker-compose up
Открываем дополнительный терминал и переходим в папку «~/mlperf_gnmt/compose».
$ cd ~/mlperf_gnmt/compose
Подключаемся к контейнеру
$ sudo docker-compose exec mlperf-gnmt /bin/bash
Переходим в папку «/work» внутри контейнера
$ cd /work
-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
</code>
Производим запуск теста
$ 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
Для редактирования файлов:
Открываем дополнительный терминал и переходим в папку «~/mlperf_gnmt/compose».
$ 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 |