На самом деле, сама nvidia-smi — обертка над библиотекой libnvidia-ml.so, которая является частью cuda.
Она позволяет делать довольно сложные запросы к железу, например — вывести всякие важные показатели в формате csv, повторять раз в секунду:
вывод этой команды можно ловить однострочником и складывать в графит или другую БД с метриками )
А мы пока что, по историческим причинам, используем libnvidia-ml.so напрямую — делать это тривиально, а библиотека прекрасно документирована. Выглядит примерно так (проверка ошибок опущена):
#include <nvml.h>
nvmlInit();
int device_id = 0;
nvmlDevice_t device;
nvmlDeviceGetHandleByIndex(id, &device);
nvmlTemperatureSensors_t sensors = NVML_TEMPERATURE_GPU;
unsigned int t = 0;
nvmlDeviceGetTemperature(device, sensors, &t); // в t записывается температура GPU
Снимаем, насколько помню, как минимум температуру, память и утилизацию.
В настоящее время от сотни до двух сотен серверов. На сервере в подавляющем большинстве случаев 4 видеокарты.
Я немного сомневаюсь на счет того, что могу указать тут прямо конкретные модели видеокарт, поэтому просто скажу — nvidia.
Насчет выхода из строя, примерно так: один раз за два года в одной видеокарте сломались вентиляторы.
И иногда, примерно раз в полгода, на некоторых видеокартах возникает ситуация, когда любое обращение к GPU провоцирует ошибку наподобие «GPU is lost. Reboot the system to recover this GPU» — на такие ошибки, конечно, должен быть настроен мониторинг.
PS: кстати, насчет конкретных моделей видеокарт. разные поколения GPU поддерживают разные наборы команд. поэтому, в том числе, приходится собирать нейросетевые фреймворки «руками», вручную указывая набор поддерживаемых архитектур.
Да, результат работы исследователя — это файлик модели и скрипт, который ее запускает (на том же питоне или, скажем, луа). На этом этапе модель еще очень далека от продакшена. Как правило, скрипт принимает на вход картинку, а на выход выдает некий тензор или просто число.
Чтобы эту модель было возможно (и удобно) эксплуатировать в продакшене, нужно, как минимум:
— написать для нее «человеческое» HTTP API, которое будет возвращать вместо тензоров и весов названия классов («собака», «кошка»), вероятности или что-то подобное;
— настроить очереди задач и мониторинги для новой модели;
— если исследователь использует фреймворк, о котором vision еще не знает, то предстоит написать оболочку вокруг этого фреймворка и встроить ее в vision;
— полностью переписать скрипт исследователя, т.к. vision для запуска нейросетей использует С++ код;
Насчет фреймворков и оболочек над ними. Нейросетевых фреймворков существует довольно много — некоторые удобны для исследователей, у некоторых богаче набор слоев, у некоторых — быстрый инференс. Vision, навскидку, умеет работать с torch, pytorch, caffe, caffe2, tensorflow, но абстракции верхнего уровня мало что знают о конкретных реализациях — это позволяет иметь один и тот же код для работы с очередями задач, метриками, изображениями и прочей обвязкой.
Нет, у нас ничего такого на серверах не стоит.
Только драйверы к gpu.
Она позволяет делать довольно сложные запросы к железу, например — вывести всякие важные показатели в формате csv, повторять раз в секунду:
вывод этой команды можно ловить однострочником и складывать в графит или другую БД с метриками )
А мы пока что, по историческим причинам, используем libnvidia-ml.so напрямую — делать это тривиально, а библиотека прекрасно документирована. Выглядит примерно так (проверка ошибок опущена):
Снимаем, насколько помню, как минимум температуру, память и утилизацию.
Я немного сомневаюсь на счет того, что могу указать тут прямо конкретные модели видеокарт, поэтому просто скажу — nvidia.
Насчет выхода из строя, примерно так: один раз за два года в одной видеокарте сломались вентиляторы.
И иногда, примерно раз в полгода, на некоторых видеокартах возникает ситуация, когда любое обращение к GPU провоцирует ошибку наподобие «GPU is lost. Reboot the system to recover this GPU» — на такие ошибки, конечно, должен быть настроен мониторинг.
PS: кстати, насчет конкретных моделей видеокарт. разные поколения GPU поддерживают разные наборы команд. поэтому, в том числе, приходится собирать нейросетевые фреймворки «руками», вручную указывая набор поддерживаемых архитектур.
можете немного раскрыть мысль? почему Turbo Boost отключается в режиме performance?
Чтобы эту модель было возможно (и удобно) эксплуатировать в продакшене, нужно, как минимум:
— написать для нее «человеческое» HTTP API, которое будет возвращать вместо тензоров и весов названия классов («собака», «кошка»), вероятности или что-то подобное;
— настроить очереди задач и мониторинги для новой модели;
— если исследователь использует фреймворк, о котором vision еще не знает, то предстоит написать оболочку вокруг этого фреймворка и встроить ее в vision;
— полностью переписать скрипт исследователя, т.к. vision для запуска нейросетей использует С++ код;
Насчет фреймворков и оболочек над ними. Нейросетевых фреймворков существует довольно много — некоторые удобны для исследователей, у некоторых богаче набор слоев, у некоторых — быстрый инференс. Vision, навскидку, умеет работать с torch, pytorch, caffe, caffe2, tensorflow, но абстракции верхнего уровня мало что знают о конкретных реализациях — это позволяет иметь один и тот же код для работы с очередями задач, метриками, изображениями и прочей обвязкой.