• Канал и фильтры. На этапах конвейера обрабатываются данные, причем, этапы управляют своим внутренним состоянием, которое можно узнать из данных.
• Компоновка. Конвейеры можно вкладывать друг в друга; например, целый конвейер можно трактовать как один этап в рамках другого конвейера. Эта конвейера не обязательно является конвейером, но конвейер как таковой по определению не менее чем этап конвейера.
• Ориентированные ациклические графы (DAG). Вывод этапа конвейера может направляться множеству других этапов, после чего результирующие выводы могут рекомбинироваться и так далее. Отметим: несмотря на то, что конвейеры ацикличны, они могут обрабатывать множество элементов один за другим, и, если их состояние меняется (например, при использовании метода fit_transform на каждом этапе), то их можно считать рекуррентно разворачивающимися во времени, сохраняющими при этом свои состояния (по образцу RNN).Это интересный ракурс, позволяющий рассматривать конвейеры как средство для онлайнового машинного обучения, после чего конвейеры можно переводить в продакшен и обучать на более обширных данных.

• fit для обучения на данных и приобретения состояния (напр., таким состоянием являются веса нейронной сети)
• transform (или predict) для фактической обработки данных и генерации прогноза.
• Примечание: если этапу конвейера не требуется один из этих методов, то этап может унаследовать от NonFittableMixin или NonTransformableMixin, где будет по умолчанию предоставляться такая реализация одного из этих методов, чтобы он ничего не дела.

• fit_transform для подгонки и последующего преобразования данных, но в один проход, что допускает потенциальную оптимизацию кода в случаях, когда два метода должны выполняться непосредственно один после другого.
• setup который будет вызывать метод setup на каждом из таких этапов конвейера. Например, если на этапе конвейера содержится нейронная сеть TensorFlow, PyTorch или Keras, то на этих этапах могли бы создаваться собственные нейронные графы и регистрироваться для работы с GPU в методе setup до подгонки. Не рекомендуется создавать графы прямо в конструкторах этапов до подгонки; на то есть несколько причин. Например, до запуска этапы могут многократно копироваться с разными гиперпапарметрами в рамках работы алгоритма Automatic Machine Learning, который подыскивает для вас наилучшие гиперпараметры.
• teardown, этот метод функционально противоположен setup: он сносит ресурсы.

• get_hyperparams возвращает словарь гиперпараметров. Если конвейер содержит другие (вложенные) конвейеры, то ключи гиперпараметров сцепляются при помощи двойных нижних подчеркиваний __.
• set_hyperparams позволяет задавать новые гиперпараметры в том же формате, в каком вы их получаете.
• get_hyperparams_space позволяет вам получить пространство гиперпараметра, которое будет непустым, если вы определили гиперпараметр. Поэтому, все отличие от get_hyperparams в данном случае таково, что вы получаете в качестве значений статистические распределения, а не точное значение. Например, один гиперпараметр, для количества слоев, может быть RandInt(1, 3) то есть, предусматривать от 1 до 3 слоев. Можно вызвать call .rvs() с этим словарем, чтобы случайным образом выбрать значение и отправить его к set_hyperparams, попытавшись таким образом организовать обучение.
• set_hyperparams_space может использоваться для задания нового пространства при помощи тех же классов для распределения гиперпараметров, что и в случае с get_hyperparams_space.

• Расстановка контрольных точек может ускорить процесс работы, если этапы программирования и отладки расположены в середине или в конце конвейера. Так отпадает необходимость каждый раз заново вычислять первые этапы конвейера.
• При выполнении оптимизации гиперпараметров (либо путем настройки вручную, либо с использованием метаобучения), вы будете только рады обойтись без пересчета первых этапов конвейера, пока занимаетесь настройкой следующих. Например, если начало вашего конвейера не содержит гиперпараметров, то оно всякий раз может быть одинаковым или почти одинаковым если гиперпараметров всего несколько. Следовательно, при работе с контрольными точками целесообразно возобновлять работу именно с тех мест, где они расставлены, если гиперпараметры и исходный код этапа, предшествующего контрольной точке, не изменились с момента последнего выполнения.
• Возможно, вы располагаете ограниченными вычислительными ресурсами, и единственный приемлемый вариант для вас прогонять по одному этапу за раз на имеющемся аппаратном обеспечении. Можно использовать контрольную точку, затем добавить после нее еще несколько этапов, а потом данные будут использоваться с того места, на котором вы остановились, если вы захотите повторно выполнить всю структуру.

• При этом используются диски, поэтому, если действовать неправильно, то выполнение вашего кода может замедляться. Чтобы ускорить работу, можно, как минимум, воспользоваться RAM Disk или монтировать папку кэша к вашей RAM.
• Для этого может потребоваться много дискового пространства. Либо много пространства RAM, при использовании каталога, монтированного к RAM.
• Состоянием, сохраненным на диске, управлять тяжелее: для вашей программы возникает дополнительная сложность, нужная, чтобы код работал быстрее. Обратите внимание, что, с точки зрения функционального программирования, ваши функции и код больше не будут чистыми, поскольку необходимо управлять побочными эффектами, связанными с использованием дисков. Побочные эффекты, связанные с управлением состоянием диска (вашим кэшем) могут становиться почвой для возникновения всевозможных страннейших багов

В Computer Science есть всего две по-настоящему сложные вещи: инвалидация кэша и именование сущностей. Фил Карлтон

ЭТАП КОНВЕЙЕРА НЕ ДОЛЖН УПРАВЛЯТЬ РАССТАНОВКОЙ КОНТРОЛЬНХ ТОЧЕК В ТЕХ ДАННХ, КОТОРЕ ВДАЮТ

• У вас будет простой выключатель, который позволит с легкостью полностью активировать или отменить расстановку контрольных точек перед развертыванием сделанного в продакшен.
• Когда требуется переучить систему на новых данных, окажется, что управление кэшированием поставлено настолько хорошо, что система сама заметит: ваши данные изменились и, следовательно, имеющийся кэш следует игнорировать. Вашего вмешательства при этом совершенно не потребуется, что позволит не допустить возникновения серьезных багов.
• Вам не придется самостоятельно иметь дело с дисками и писать операции ввода/вывода (I/O) на каждом этапе конвейера. Большинство программистов предпочитают пользоваться алгоритмами машинного обучения и строить конвейеры, а не заниматься созданием методов сериализации данных. Будем честны: вы же хотите просто запрограммировать готовенькие алгоритмы, а все остальное чтобы было сделано за вас. Верно?
• Теперь вы можете придумывать названия для каждого из ваших конвейерных экспериментов или каждой итерации, так, чтобы при каждом рестарте в кэше создавался новый подкаталог строго на данный случай даже если вы собираетесь переиспользовать одни и те же этапы конвейера. Причем, именовать этапы экспериментов даже не требуется, поскольку с изменением данных меняется и кэширование.
• Внутренний код классов, описывающих этапы вашего конвейера, хэшируется, после чего хэши сравниваются, чтобы посмотреть, нужно ли заново выполнить кэширование для того класса, в котором вы только что изменили код. Именно так избегаются баги, связанные с инвалидацией кэша. Ура.
• Теперь вы можете хэшировать промежуточные результаты обработки данных и пропускать этап вычисления конвейера на этих данных, если гиперпраметры не изменились, а ваш конвейер уже преобразовал (и, следовательно, хэшировал) данные ранее. Это может упростить тонкую настройку гиперпараметров в случаях, когда некоторые этапы конвейера (в том числе, промежуточные) могут меняться. Например, первые этапы конвейера могут оставаться кэшированными, поскольку изменения их не затрагивают, а, если у вас появятся дополнительные гиперпараметры, которые потребуется настроить на дальнейших этапах конвейера, то вы всегда сможете добавить нужное количество контрольных точек после этих этапов. Тогда полученные в результате многократного кэширования этапы сохраняются с уникальным именем, вычисленным на основе хэша. Можете считать такую систему блокчейном, так как это и есть блокчейн.

• Метод подгонки и/или преобразования можно вызывать много раз подряд, чтобы улучшить подгонку при помощи новых мини-батчей.
• Многопоточные очереди внутри конвейера используются так, как в проблеме поставщика-потребителя. Между любыми двумя этапами конвейера, передаваемыми по потоковому принципу, нужна одна очередь.
• Можно обеспечить параллельную репликацию этапов конвейера, чтобы на каждом этапе параллельно преобразовывать множество элементов. Это можно делать до того, как по всему конвейеру будут вызваны методы setup. В противном случае конвейер необходимо сериализовать, клонировать и перезагрузить с использованием механизмов, сохраняющих этапы. Код, использующий TensorFlow, и иной импортированный код, написанный на других языках, например, на C++, сложно распределить на потоки в Python, особенно если он использует память GPU. Даже joblib не так легко справляется с некоторыми из таких проблем. Поэтому благоразумно избегать подобных проблем при помощи грамотной сериализации.
• Параметр конвейера может быть важен, а может быть и не важен для поддержания данных в правильном порядке перед отправкой их на следующий этап. По умолчанию он важен, а если нет то конвейер может продолжать обработку данных в произвольном порядке, по мере поступления, причем, так и бывает, если на разные этапы требуется разное количество времени.
• Будет можно использовать барьерные объекты между этапами конвейера. Они будут представлять собой не настоящие этапы, а указания конвейеру, как обращаться с данными между этапами; например, должны или нет данные сохранять определенный порядок в заданных ключевых местах. Например, можно использовать барьеры, предусматривающие соблюдение порядка, не предусматривающие соблюдения порядка, либо дожидающиеся всех данных блокирующие барьеры (мы назвали такой барьер Joiner). Эти барьеры добавляют информацию о том, как обрабатывать данные между этапами или группами этапов. Например, на конкретном этапе я могу задавать или переопределять длину очереди и указывать, сколько раз нужно параллельно прогнать этап конвейера, как распараллелить этот этап.

• В коде для машинного обучения целесообразно использовать конвейеры, и каждый этап конвейера определять как экземпляр класса.
• Затем вся такая структура может быть оптимизирована при помощи контрольных точек, помогающих найти наилучшие гиперпараметры и многократно выполнять код над одними и теми же данными (но, возможно, с разными гиперпараметрами или с измененным исходным кодом).
• Также целесообразно выполнять подгонку и преобразование данных последовательно, чтобы не раздувать RAM. Затем всю такую структуру можно распараллелить, когда переключаешься с последовательного конвейера на потоковый.
• Наконец, можно программировать собственные этапы конвейеров для этого достаточно наследовать от класса BaseStep, показанного в этой статье, и реализовать нужные вам методы.

Принцип работы

• Чаще всего приходится ехать прямо, поэтому обучающая выборка сильно не сбалансирована, и после обучения такая модель будет иметь тенденцию проезжать сквозь повороты. Исправить это можно отсечением примеров преобладающего класса (down-sample the majority class)
• Когда автопилот попадает в критические ситуации, модель не знает что с этим делать, т.к. этого не было в обучающих данных. В моей версии машинка просто врежется, но решением было бы телепортировать машинку в критическую ситуацию и показать, как из нее выруливать.

Модель и обучение

class Model(nn.Module):    def __init__(self, in_features=24, hidden=[56, 48, 48], out_features=3):        super().__init__()        layer_sizes = [in_features] + hidden        layers = []        for i in range(len(layer_sizes) - 1):            layers.append(nn.Linear(layer_sizes[i], layer_sizes[i + 1]))            layers.append(nn.ReLU(inplace=True))        layers.append(nn.Linear(layer_sizes[-1], out_features))        self.layers = nn.Sequential(*layers)    def forward(self, x):        return self.layers(x)

criterion = nn.CrossEntropyLoss()optimizer = torch.optim.Adam(model.parameters(), lr=0.005)epochs = 7000for i in range(epochs):    y_pred = model.forward(X_train)    loss = criterion(y_pred, y_train)    if i % 100 == 1:        print(f'epoch: {i:2}  loss: {loss.item():10.8f}')    optimizer.zero_grad()    loss.backward()    optimizer.step()

В нескольких предыдущих заметках данной серии мы уже упоминали понятие дифференциального рендеринга. Сегодня пришло время разъяснить что это такое и с чем это едят.

Мы поговорим о том, почему традиционный пайплайн рендеринга не дифференцируем, зачем исследователям в области 3D ML потребовалось сделать его дифференцируемым и как это связано с нейронным рендерингом. Какие существуют подходы к конструированию таких систем, и рассмотрим конкретный пример SoftRasterizer и его реализацию в PyTorch 3D. В конце, с помощью этой технологии, восстановим все пространственные характеристики Моны Лизы Леонардо Да Винчи так, если бы картина была не написана рукой мастера, а отрендерена с помощью компьютерной графики.

Серия 3D ML на Хабре:

1. Формы представления 3D данных
2. Функции потерь в 3D ML
3. Датасеты и фреймворки в 3D ML
4. Дифференциальный рендеринг

Репозиторий на GitHub для данной серии заметок.

Заметка от партнера IT-центра МАИ и организатора магистерской программы VR/AR & AI компании PHYGITALISM.

Rendering pipeline: forward and inverse

Если мы рассматриваем все возможные задачи, в которых требуется как-то взаимодействовать с 3D моделями, то глобально появляется возможность разделить их на два класса задач:

• Задачи, в которых из 3D сцены мы хотим сгенерировать изображение (такие задачи можно отнести к традиционным задачам компьютерной графике) т.н. forward rendering;
• Задачи, где по изображению нам требуется восстанавливать параметры 3D объектов (такие задачи относятся скорее к компьютерному зрению) т.н. inverse rendering.

До недавнего времени два этих класса задач обычно рассматривались отдельно друг от друга, но сегодня все чаще приходится иметь дело с алгоритмами, которые должны работать в обе стороны (особенно это касается области машинного обучения).

Рис.1 Из презентации TensorFlow Graphics (github page).

В качестве примера такой задачи, можно рассмотреть задачу 3D mesh reconstruction from single image, которую мы уже упоминали в предыдущих заметках. С одной стороны, эту задачу можно решать сравнивая ошибку рассогласования между исходной моделью и предсказанной с помощью функций потерь для 3D объектов (заметка 2 данной серии). С другой стороны, можно генерировать 3D объект сначала, а после его отрендеренную картинку сравнивать с изображением-образцом (пример на рис.2).

Рис.2 Модель деформации меша с помощью модуля дифференциального рендеринга SoftRas (github page).

Далее, при разговоре про рендеринг, мы будем рассматривать несколько основных компонентов 3D сцены:

• 3D объект, описываемый своим мешем;
• камера с набором характеристик (позиция, направление, раствор и т.д.);
• источники света и их характеристики;
• глобальные характеристики расположения объекта на сцене, описываемые матрицами преобразований.

Процедура прямого рендеринга заключается в функциональном сочетании этих основных компонент, а процедура обратного рендеринга заключается в восстановлении этих компонент по готовому изображению.

Давайте поговорим сначала о том, из каких этапов состоит традиционный пайплайн прямого рендеринга и почему он не является дифференцируемым.

Why is rendering not differentiable?

Рис.3 Схема традиционного рендеринга и рендеринга методом Soft Rasterizer [1]. Здесь: меш объекта на сцене, модель камеры, модель источника освещения, модель текстуры, карта нормалей для меша, карта глубины получаемого изображения, матрица преобразования 3D в 2D для получения плоского изображения, растеризованное изображение, вероятностные карты метода Soft Rasterizer, изображения полученные традиционным рендерингом и методом SoftRas соответственно. Красные блоки недифференцируемые операции, синии дифференцируемые.

Процедуру рендеринга можно подразделить на несколько взаимозависимых этапов (этапы традиционного рендеринга приведены на рис.3 врехняя линия в правой части). Какие-то этапы, к примеру вычисления освещения и позиции камеры, являются дифференцируемыми, поскольку в них участвуют непрерывные функциональные зависимости (см. модель Фонга, на Хабре о ней и моделях освещения писали здесь и здесь), но два последних этапа не являются дифференцируемыми. Давайте разберемся почему.

Последние два этапа, которые являются по сути и ключевыми это растеризация и шейдинг. (Про реализацию этих этапов на JavaScript на Хабре писали здесь).

Грубо говоря, проблему недифференцируемости растеризации можно описать так: пиксели дискретные структуры, с постоянным цветом, а исходная модель непрерывна, поэтому при проецировании из 3D в 2D часть информации теряется.

Проиллюстрируем две основные проблемы с дифференцируемостью при вычислении цвета и расстояния.

Проблема 1 (недифференцируемость цвета по глубине)

Предположим, что вдоль направления луча, проходящего через пиксель, есть несколько полигонов разных цветов, как на иллюстрации выше. Если придать малый сдвиг полигонов друг относительно друга, может случиться ситуация, когда ближайшим полигоном становится полигон другого цвета и при этом резко меняется цвет, в который нужно разукрашивать соответствующий пиксель. На правом графике иллюстрации изображена зависимость цвета пикселя (в барицентрических координатах) от расстояния до ближайшего пикселя конкретной модели. Из данного примера видно, что малому приращению расстояния до ближайшего полигона может соответствовать скачкообразному изменению в цвете, что приводит к недифференцируемости в классическом смысле.

Проблема 2 (недифференцируемость цвета при сдвигах)

Вторая проблема недифференцируемости аналогична первой, только теперь полигон будет один, а двигать мы его будем не вдоль луча, проходящего через данный пиксель, а в сторону от этого луча. Опять наблюдаем ситуацию, когда малому приращению координаты полигона соответствует скачок в цвете пикселя.

Make it differentiable! Soft Rasterizer

Процесс рендеринга недифференцируемый, но если бы он таковым являлся, можно было бы решать много актуальных задач в области 3D ML мы определили проблему, посмотрим как ее можно решить.

Основные подходы к реализации дифференцируемого рендеринга можно проследить в следующей подборке публикаций:

• Loper, M.M. and Black, M.J., 2014, September. OpenDR: An approximate differentiable renderer. In European Conference on Computer Vision (pp. 154-169). Springer, Cham.
• Kato, H., Ushiku, Y. and Harada, T., 2018. Neural 3d mesh renderer. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 3907-3916).
• Li, T.M., Aittala, M., Durand, F. and Lehtinen, J., 2018. Differentiable monte carlo ray tracing through edge sampling. ACM Transactions on Graphics (TOG), 37(6), pp.1-11.
• Liu, S., Li, T., Chen, W. and Li, H., 2019. Soft rasterizer: A differentiable renderer for image-based 3d reasoning. In Proceedings of the IEEE International Conference on Computer Vision (pp. 7708-7717).
• Chen, W., Ling, H., Gao, J., Smith, E., Lehtinen, J., Jacobson, A. and Fidler, S., 2019. Learning to predict 3d objects with an interpolation-based differentiable renderer. In Advances in Neural Information Processing Systems (pp. 9609-9619).

Подходы основаны на разных идеях и приемах. Мы подробно остановимся только на одном, Soft Rasterizer, по двум причинам: во-первых, идея данного подхода математически прозрачна и легко реализуема самостоятельно, во-вторых, данный подход реализован и оптимизирован внутри библиотеки PyTorch 3D [6].

Подробно со всеми аспектами реализации дифференциального рендеринга этим методом можно ознакомиться в соответствующей статье [1], мы же отметим основные моменты.

Для решение проблемы 2, авторы метода предлагают использовать размытие границы полигонов, которое приводит к непрерывной зависимости цвета пикселя от координат смещения полигона.

Размытие границ предполагает введение некоторой гладкой вероятностной функции , которая каждой внутренней или внешней точки пространства ставит в соответствие число от 0 до 1 вероятности принадлежности к данному полигону (чем-то похоже на подход нечеткой логики). Здесь параметр размытия (чем больше , тем больше размытие), кратчайшее расстояние в проекционной плоскости от проекции точки до границы проекции полигона (данное расстояние обычно выбирают Евклидовым, но авторы метода отмечают, что здесь есть простор для экспериментов и, например, использование барицентрического расстояния или также подходит для их метода), функция, которая равна 1 если точка находится внутри полигона и -1 если вне (на границе полигона можно доопределить значение нулем, однако это все равно приводит к тому, что на границе полигона данная функция разрывна, поэтому для точек границ она не применяется), сигмоидная функция активации, которая часто применяется в глубоком обучении.

Для решения проблемы 1, авторы метода предлагают использовать смешение цветов k ближайших полигонов (blending).

Коротко этот прием можно описать следующим образом: для вычисления итогового цвета -го пикселя , производят нормированное суммирование цветовых карт для k ближайших полигонов , причем цветовые карты получают путем интерполяции барицентрических координат цвета вершин данных полигонов. Индекс в формуле отвечает за фоновый цвет (background colour), а оператор оператор агрегирование цвета. глубина -го пикселя относительно -го полигона, а параметр смешивания (чем он меньше, тем сильнее превалирует цвет ближайшего полигона).

Итоговой подход Soft Rasterizer, заключается в комбинировании этих двух идей, для одновременного плавного размытия границы и цвета.

Рис.4 Схема реализации дифференциального рендеринга в PyTorch 3D (слайд из презентации фреймворка).

Реализация Soft Rasterizer внутри библиотеки PyTorch 3D выполнена так, чтобы максимально эффективно и удобно использовать возможности как базового фреймворка PyTorch, так и возможности технологии CUDA. По сравнению с оригинальной реализацией [github page], разработчикам фреймворка удалось добиться 4-х кратного приращения скорости обработки (особенно для больших моделей), при этом возрастает расход памяти за счет того, что для каждого типа данных (ката глубины, карта нормалей, рендер текстур, карта евклидовых расстояний) нужно просчитать k слоев и хранить их в памяти.

Рис.5 Сравнение характеристик дифференциального рендеринга в PyTorch 3D (слайд из презентации фреймворка).

Поэкспериментировать с настройками дифференциального рендера можно как в PyTorch 3D, так в библиотеке с оригинальной реализацией алгоритма Soft Rasterizer. Давайте рассмотрим пример, демонстрирующий зависимость итоговой картинки отрендеренной модели от параметров дифференциального рендера \sigma, \gamma.

Удобнее всего работать с этой библиотекой в виртуальном окружении anaconda, так как данная библиотека работает уже не с самой актуальной версией pytorch 1.1.0. Также обратите внимание что вам потребуется видеокарта с поддержкой CUDA.

import matplotlib.pyplot as pltimport osimport tqdmimport numpy as npimport imageioimport soft_renderer as srinput_file = 'path/to/input/file'output_dir = 'path/to/output/dir'

Зададим начальные параметры камеры для рендеринга, загрузим меш объекта с текстурами (есть мод для работы без текстур, в этом случае нужно указать texture_type=vertex), инициализируем дифференциальный рендер и создадим директорию для сохранения результатов.

# camera settingscamera_distance = 2.732elevation = 30azimuth = 0# load from Wavefront .obj filemesh = sr.Mesh.from_obj(                         input_file,                          load_texture=True,                          texture_res=5,                          texture_type='surface')# create renderer with SoftRasrenderer = sr.SoftRenderer(camera_mode='look_at')os.makedirs(args.output_dir, exist_ok=True)

Сначала, посмотрим на нашу модель с разных сторон и для этого отрендерим анимацию пролета камеры по кругу с помощью рендера.

# draw object from different viewloop = tqdm.tqdm(list(range(0, 360, 4)))writer = imageio.get_writer(                            os.path.join(output_dir, 'rotation.gif'),                              mode='I')for num, azimuth in enumerate(loop):    # rest mesh to initial state    mesh.reset_()    loop.set_description('Drawing rotation')    renderer.transform.set_eyes_from_angles(                                            camera_distance,                                             elevation,                                             azimuth)    images = renderer.render_mesh(mesh)    image = images.detach().cpu().numpy()[0].transpose((1, 2, 0))    writer.append_data((255*image).astype(np.uint8))writer.close()

Теперь поиграемся со степенью размытия границы и степенью смешения цветов. Для этого будем в цикле увеличивать параметр размытия и одновременно увеличивать параметр смешения цвета .

# draw object from different sigma and gammaloop = tqdm.tqdm(list(np.arange(-4, -2, 0.2)))renderer.transform.set_eyes_from_angles(camera_distance, elevation, 45)writer = imageio.get_writer(                            os.path.join(output_dir, 'bluring.gif'),                             mode='I')for num, gamma_pow in enumerate(loop):    # rest mesh to initial state    mesh.reset_()    renderer.set_gamma(10**gamma_pow)    renderer.set_sigma(10**(gamma_pow - 1))    loop.set_description('Drawing blurring')    images = renderer.render_mesh(mesh)    image = images.detach().cpu().numpy()[0].transpose((1, 2, 0))    writer.append_data((255*image).astype(np.uint8))writer.close()# save to textured objmesh.reset_()mesh.save_obj(              os.path.join(args.output_dir, 'saved_spot.obj'),               save_texture=True)

Итоговый результат на примере стандартной модели текстурированной коровы (cow.obj, cow.mtl, cow.png удобно скачивать, например, с помощью wget) выглядит так:

Neural rendering

Дифференциальный рендеринг как базовый инструмент для 3D ML, позволяет создавать очень много интересных архитектур глубокого обучения в области, которая получила названия нейронный рендеринг (neural rendering). Нейронный рендеринг позволяет решать множество задач, связанных с процедурой рендеринга: от добавления новых объектов на фото и в видеопоток до сверхбыстрого текстурирования и рендеринга сложных физических процессов.

Сегодня мы оставим приложение дифференциального рендеринга к конструированию нейронного рендеринга за скобками повествования, однако порекомендуем всем заинтересовавшимся следующие источники:

• большая обзорная статья SOTA архитектур в области нейронного рендеринга [7] на основе прошедшей CVPR 2020;
• видео с записью утренней и дневной сессией по нейтронному рендерингу с CVPR 2020, на основе которых и была написана статья из предыдущего пункта;
• видеолекция MIT DL Neural rendering с кратким обзором основных подходов и введении в тему;
• заметка на Medium на тему дифференциального рендеринга и его приложений;
• видео с youtube канала two minute papers на данную тему.

Experiment: Mona Liza reconstruction

Разберем пример применения дифференциального рендеринга для восстановления параметров 3D сцены по исходному изображению человеческого лица, представленный в пуле примеров библиотеки redner, которая является реализацией идей, изложенных в статье [ 4 ].

В данном примере, мы будем использовать т.н. 3D morphable model [8] технику текстурированного трехмерного моделирования человеческого лица, ставшую уже классической в области анализа 3D. Техника основана на получение такого крытого представления признаков 3D данных, которое позволяет строить линейные комбинации, сочетающие физиологические особенности человеческих лиц (если так можно выразиться, то это своеобразный Word2Vec от мира 3D моделирования человеческих лиц).

Для работы с примером вам потребуется датасет Basel face model (2017 version). Файл model2017-1_bfm_nomouth.h5 необходимо будет разместить в рабочей директории вместе с кодом.

Для начала загрузим необходимы для работы библиотеки и датасет лиц.

import torchimport pyrednerimport h5pyimport urllibimport timefrom matplotlib.pyplot import imshow%matplotlib inlineimport matplotlib.pyplot as pltfrom IPython.display import display, clear_outputfrom matplotlib import animationfrom IPython.display import HTML

# Load the Basel face modelwith h5py.File(r'model2017-1_bfm_nomouth.h5', 'r') as hf:    shape_mean = torch.tensor(hf['shape/model/mean'],                               device = pyredner.get_device())    shape_basis = torch.tensor(hf['shape/model/pcaBasis'],                                device = pyredner.get_device())    triangle_list = torch.tensor(hf['shape/representer/cells'],                                  device = pyredner.get_device())    color_mean = torch.tensor(hf['color/model/mean'],                               device = pyredner.get_device())    color_basis = torch.tensor(hf['color/model/pcaBasis'],                                device = pyredner.get_device())

Модель лица в таком подходе разделена отдельно на базисный вектор формы shape_basis (вектор длины 199 полученный методом PCA), базисный вектор цвета color_basis (вектор длины 199 полученный методом PCA), также имеем усредненный вектор формы и цвета shape_mean, color_mean. В triangle_list хранится геометрия усредненного лица в форме полигональной модели.

Создадим модель, которая на вход будет принимать векторы скрытого представления цвета и формы лица, параметры камеры и освещения в сцене, а на выходе будет генерировать отрендеренное изображение.

indices = triangle_list.permute(1, 0).contiguous()def model(        cam_pos,         cam_look_at,         shape_coeffs,         color_coeffs,         ambient_color,         dir_light_intensity):    vertices = (shape_mean + shape_basis @ shape_coeffs).view(-1, 3)    normals = pyredner.compute_vertex_normal(vertices, indices)    colors = (color_mean + color_basis @ color_coeffs).view(-1, 3)    m = pyredner.Material(use_vertex_color = True)    obj = pyredner.Object(vertices = vertices,                           indices = indices,                           normals = normals,                           material = m,                           colors = colors)    cam = pyredner.Camera(position = cam_pos,                          # Center of the vertices                                                    look_at = cam_look_at,                          up = torch.tensor([0.0, 1.0, 0.0]),                          fov = torch.tensor([45.0]),                          resolution = (256, 256))    scene = pyredner.Scene(camera = cam, objects = [obj])    ambient_light = pyredner.AmbientLight(ambient_color)    dir_light = pyredner.DirectionalLight(torch.tensor([0.0, 0.0, -1.0]),                                           dir_light_intensity)    img = pyredner.render_deferred(scene = scene,                                    lights = [ambient_light, dir_light])    return img

Теперь посмотрим как выглядит усредненное лицо. Для этого зададим первоначальные параметры освещения и позиции камеры и воспользуемся нашей моделью. Также загрузим целевое изображение, параметры которого мы хотим восстановить и взглянем на него:

cam_pos = torch.tensor([-0.2697, -5.7891, 373.9277])cam_look_at = torch.tensor([-0.2697, -5.7891, 54.7918])img = model(cam_pos,             cam_look_at,             torch.zeros(199, device = pyredner.get_device()),            torch.zeros(199, device = pyredner.get_device()),            torch.ones(3),             torch.zeros(3))imshow(torch.pow(img, 1.0/2.2).cpu())face_url = 'https://raw.githubusercontent.com/BachiLi/redner/master/tutorials/mona-lisa-cropped-256.png'urllib.request.urlretrieve(face_url, 'target.png')target = pyredner.imread('target.png').to(pyredner.get_device())imshow(torch.pow(target, 1.0/2.2).cpu())

Зададим начальные значения параметров, которые будем пытаться восстановить для целевой картины.

# Set requires_grad=True since we want to optimize them latercam_pos = torch.tensor([-0.2697, -5.7891, 373.9277],                        requires_grad=True)cam_look_at = torch.tensor([-0.2697, -5.7891, 54.7918],                            requires_grad=True)shape_coeffs = torch.zeros(199, device = pyredner.get_device(),                            requires_grad=True)color_coeffs = torch.zeros(199, device = pyredner.get_device(),                            requires_grad=True)ambient_color = torch.ones(3, device = pyredner.get_device(),                            requires_grad=True)dir_light_intensity = torch.zeros(3, device = pyredner.get_device(),                                   requires_grad=True)# Use two different optimizers for different learning ratesoptimizer = torch.optim.Adam(                             [                              shape_coeffs,                               color_coeffs,                               ambient_color,                               dir_light_intensity],                              lr=0.1)cam_optimizer = torch.optim.Adam([cam_pos, cam_look_at], lr=0.5)

Остается организовать, оптимизационный цикл и логировать происходящее с функцией ошибки (в нашем случае это попиксельный MSE + квадратичные регуляризаторы параметров) и с самой 3D моделью.

plt.figure()imgs, losses = [], []# Run 500 Adam iterationsnum_iters = 500for t in range(num_iters):    optimizer.zero_grad()    cam_optimizer.zero_grad()    img = model(cam_pos, cam_look_at, shape_coeffs,                 color_coeffs, ambient_color, dir_light_intensity)    # Compute the loss function. Here it is L2 plus a regularization     # term to avoid coefficients to be too far from zero.    # Both img and target are in linear color space,     # so no gamma correction is needed.    loss = (img - target).pow(2).mean()    loss = loss          + 0.0001 * shape_coeffs.pow(2).mean()          + 0.001 * color_coeffs.pow(2).mean()    loss.backward()    optimizer.step()    cam_optimizer.step()    ambient_color.data.clamp_(0.0)    dir_light_intensity.data.clamp_(0.0)    # Plot the loss    f, (ax_loss, ax_diff_img, ax_img) = plt.subplots(1, 3)    losses.append(loss.data.item())    # Only store images every 10th iterations    if t % 10 == 0:        # Record the Gamma corrected image        imgs.append(torch.pow(img.data, 1.0/2.2).cpu())     clear_output(wait=True)    ax_loss.plot(range(len(losses)), losses, label='loss')    ax_loss.legend()    ax_diff_img.imshow((img -target).pow(2).sum(dim=2).data.cpu())    ax_img.imshow(torch.pow(img.data.cpu(), 1.0/2.2))    plt.show()

Чтобы лучше понимать что происходило со сценой в процессе обучения можем сгенерировать анимацию из наших логов:

fig = plt.figure()# Clamp to avoid complainsim = plt.imshow(imgs[0].clamp(0.0, 1.0), animated=True)def update_fig(i):    im.set_array(imgs[i].clamp(0.0, 1.0))    return im,anim = animation.FuncAnimation(fig, update_fig,                                frames=len(imgs), interval=50, blit=True)HTML(anim.to_jshtml())

Conclusions

Дифференциальный рендеринг новое интересное и важное направление на стыке компьютерной графики, компьютерного зрения и машинного обучения. Данная технология стала основой для многих архитектур в области нейронного рендеринга, который в свою очередь расширяет границы возможностей компьютерной графики и машинного зрения.

Существуют несколько популярных библиотек глубокого вычисления (например Kaolin, PyTorch 3D, TensorFlow Graphics), которые содержат дифференциальный рендеринг как составную часть. Также существуют отдельные библиотеки, реализующие функционал дифференциального рендеринга (Soft Rasterizer, redner). С их помощью можно реализовывать множество интересных проектов, вроде проекта с восстановлением параметров лица и текстуры портрета человека.

В ближайшем будущем, мы можем ожидать появление новых техник и библиотек для дифференциального рендеринга и их применения в области нейронного рендеринга. Возможно, уже завтра может появится способ делать реалистичную графику в реальном времени или генерировать 2D и 3D контент приемлемого для людей качества с помощью этой технологии. Мы будем следить за развитием этого направления и постараемся рассказывать о всех новинках и интересных экспериментах.

• Мой обзор будет со стороны ComputerVision. Не стоит забывать что ML это не только CV. Это ещё классические алгоритмы бустинга, это различный NLP (от трансформеров до синтеза речи). И далеко не все задачи ML можно будет исполнять на тех фреймворках про которые я буду говорить.
• Из обозначенных технологий я сам работал где-то с третью. Про остальные читал/минимально щупал/общался с людьми которые интегрировали. Отсюда могут возникнуть какие-то ошибки в статье. Если вы видите что-то что вас покоробило/с чем вы не согласны пишите в комментариях/в личку попробую поправить.
• Мир стремительно меняется. Я пробую верифицировать то что пишу на момент выхода статьи. Но не факт что даже существующая документация соответствует истинному положению дел. Не говоря уже о том, что в ближайшие пару недель любой из указанных фреймворков может катастрофически измениться. Если вдруг такие апдейты вам будут интересны то скорее всего я буду разбирать их в своём блоге CVML (он же в телеге), где я такую мелочь пишу. Тут буду стараться оставлять ссылки на разбор.

Часть 1. Что такое инференс

• обучение
• использование

Часть 2. Железо.

• Серверный инференс. Мы не полезем в него глубоко. Обычно когда вам нужно чтобы сеть выполнялась на сверхпроизводительном сервере редко нужно чтобы данный алгоритм крутился на старой мобилке. Но, тем не менее, тут будет что помянуть
• Десктопный инференс. Это то, что может крутиться у вас на домашнем компе. Обработка фотографий. Анализ видео, компы которые ставятся на предприятия, и прочее и прочее будет именно здесь.
• Мобильный инференс всё что касается телефонов, Android и Ios. Тут огромное поле. Есть GPU, есть специальные ускорители, есть сопроцессоры, и прочее и прочее.
• Embedded. Частично эта часть пересекается с десктопами, а частично с мобильными решениями. Но я вынес её в отдельную ветку, так как часть ускорителей ни на что не похожи.

Специализированное железо: Gyrfalcon, Khadas, Hikvision, и.т.д.

• Не все слои поддерживаются
• Софт часто не выложен в OpenSource. Поставляется вместе с аппаратной частью или требует подписания дополнительного NDA

Специализированное железо но от крупных фирм

Nvidia TensorRT

• Серверные платформы (Tesla)
• Десктопы (видеокарты обычные и полу специализированные)
• Embedded платформы серии Jetson.

Triton Inference Server

Intel OpenVino

• Серверных вычислителей (Intel FPGA, Xe GPU, Xeon)
• Десктопов (с i3 начиная года с 2015 поддерживается почти всё). Intel GPU работает но не сверх круто.
• Embedded платформ (movidius)

Google Edge

• TensorFlow Edge
• TensorFlow lite
• TensorFlow JS
• TensorFlow (чистый, или оптимизированный под какую-то платформу, например Intel TensorFlow)

Универсализация с хорошей аппаратной поддержкой

OpenCV

• Очень мало актуальной документации. Попробуйте найти где-нибудь гайд по всем бекендам модуля DNN в OpenCV и по поддержке их на всех платформах?:) Конечно, можно изучить хедеры, но это не говорит о том что где будет работать. Порог входа и первого прототипа достаточно высок. Не в пример того же OpenVino.
• Нейронные сети под Android поддерживаются ( docs.opencv.org/master/d0/d6c/tutorial_dnn_android.html ). Но я не находил актуального гайда про аппаратную поддержку GPU или других вычислителей.

Tensorflow lite

ONNX runtime

PyTorch

TensorFlow

Китайское вторжение

JS Tensorflow.JS, ONNX.js

Как небольшое резюме

• Если вам нужно максимально широкое использование на всех платформах, то, похоже, наиболее универсален ONNX runtime. Единственное, он может местами сыроват + ios поддержан весьма просто. Не уверен, что все ускорители одинаково хорошо работают. Вариант Tencent-ncnn
• Если вам нужно максимум платформ, без мобильных, то я бы взял OpenCV. Он достаточно удобен и стандартен.
• Если вам не нужны десктопные платформы, тогда я бы использовал TFlite
• Если же вы хотите делать на какой-то стандартной платформе, и чётко понимаете что никуда за её пределы не пойдёте то я бы использовал специализированную платформу под эту платформу. Будь это TensorRT или OpenVino. И на TensorRT и на OpenVino мы разворачивали очень сложные проекты. Непреодолимых проблем не встретили.

P.S.

TensorDash

Применение TensorDash

1. Установите TensorDash из Play Store. Поддержка устройств iOS скоро появится.
2. Cоздайте учетную запись.
3. Установите пакет TensorDash для Python, выполнив команду pip install tensor-dash.
4. Следуйте приведенным ниже инструкциям о том, как использовать TensorDash с фреймворками.

Поддержка Keras/tf.keras

from tensordash.tensordash import Tensordashhistories = Tensordash(    ModelName = '<YOUR_MODEL_NAME>',    email = '<YOUR_EMAIL_ID>',     password = '<YOUR PASSWORD>')    try:    model.fit(    X_train,     y_train,     epochs = epochs,     validation_data = validation_data,     batch_size = batch_size,     callbacks = [histories])except:    histories.sendCrash()

Поддержка PyTorch

from tensordash.torchdash import Torchdashhistories = Torchdash(    ModelName = '<YOUR_MODEL_NAME>',    email = '<YOUR_EMAIL_ID>',     password = '<YOUR PASSWORD>')try:    for epoch in range(epochs):        losses = []        for data in trainset:            X, y = data            net.zero_grad()            output = net(X.view(data_shape))            loss = F.nll_loss(output, y)            loss.backward()            optimizer.step()        losses = np.asarray(losses)        histories.sendLoss(loss = np.mean(losses), epoch = epoch, total_epochs = epochs) // Add this line to your training loopexcept:    histories.sendCrash()

Поддержка Fast.ai

from tensordash.fastdash import Fastdashmy_cb = Tensordash(    ModelName = '<YOUR_MODEL_NAME>',    email = '<YOUR_EMAIL_ID>',     password = '<YOUR PASSWORD>')try:    learn.fit(epochs, learning_rate, callbacks = my_cb)except:    my_cb.sendCrash()

Поддержка TensorFlow

from tensordash.tensordash import Customdashhistories = Customdash(    ModelName = '<YOUR_MODEL_NAME>',    email = '<YOUR_EMAIL_ID>',     password = '<YOUR PASSWORD>')try:    for epoch in range(num_epochs):        epoch_loss_avg = tf.keras.metrics.Mean()        epoch_accuracy = tf.keras.metrics.SparseCategoricalAccuracy()        for x, y in train_dataset:            loss_value, grads = grad(model, x, y)            optimizer.apply_gradients(zip(grads, model.trainable_variables))            epoch_loss_avg(loss_value)            epoch_accuracy(y, model(x, training=True))        train_loss_results.append(epoch_loss_avg.result())        train_accuracy_results.append(epoch_accuracy.result())        histories.sendLoss(loss = epoch_loss_avg.result(), accuracy = epoch_accuracy.result(), epoch = epoch, total_epochs = epochs) // Add this line to your training loopexcept:    histories.sendCrash()

Заключение

• Онлайн-буткемп по Data Science
• Обучение профессии Data Analyst с нуля
• Онлайн-буткемп по Data Analytics
• Обучение профессии Data Science с нуля
• Курс Python для веб-разработки

Рекомендуемые статьи

• Как стать Data Scientist без онлайн-курсов
• 450 бесплатных курсов от Лиги Плюща
• Как изучать Machine Learning 5 дней в неделю 9 месяцев подряд
• Сколько зарабатывает аналитик данных: обзор зарплат и вакансий в России и за рубежом в 2020
• Machine Learning и Computer Vision в добывающей промышленности

ИИ для мониторинга вредителей

Построение решения машинного обучения

Многозадачная модель

Оценка модели

• Пропущенный сигнал тревоги (MAR): в процентах случаев, когда рекомендация должна была касаться опрыскивания, но система предлагала обратное.
• Скорость ложной тревоги (FAR): в процентах случаев, когда не следует предпринимать никаких действий, но система предложила распыление.

Сжатие модели

Развертывание модели

class Model(torch.nn.Module):    def __init__(self, param1, param2):        self.module1 = NeuralNet(param1)        self.module2 = torch.jit.script(FooFunc(param2))        def forward(self, x):        y1 = self.module1(x)        if some_condition:            return self.module2(y1)        else:            return y1traced_model = torch.jit.trace(Model, torch.randn(1,3,300,300))

Развертывание в облаке

Развертывание на смартфонах

Лучшие практики

• Контейнеризация. Docker широко используется для обеспечения того, чтобы все зависимости, необходимые для репликации эксперимента, были упакованы в единую изолированную среду.
  
• Управление версиями данных. Поскольку наборы данных продолжают развиваться с течением времени, разделения на наборы тренировки, валидации и тестирования не могут быть статичными. Явно версионируйте данные, чтобы сделать снимки образцов, используемых для обучения любого конкретного эксперимента. На данный момент мы явно сохраняем разбиения в файле версии данных. Мы с нетерпением ждем перехода на артефакты от Weights & Biases.
  
• Управление версиями эксперимента: мы сохраняем все гиперпараметры для каждого эксперимента в файле конфигурации вместе с идентификатором коммита Git и конкретным начальным значением.
  

• Курс по Machine Learning
• Обучение профессии Data Science
• Обучение профессии Data Analyst
• Онлайн-буткемп по Data Analytics
• Курс Python для веб-разработки

Рекомендуемые статьи

• Как стать Data Scientist без онлайн-курсов
• 450 бесплатных курсов от Лиги Плюща
• Как изучать Machine Learning 5 дней в неделю 9 месяцев подряд
• Сколько зарабатывает аналитик данных: обзор зарплат и вакансий в России и за рубежом в 2020
• Machine Learning и Computer Vision в добывающей промышленности

Сделка OpenAI и Microsoft

ruGPT3 от Сбера

Отчет State of AI 2020

Открытые мультиязычные модели от Google и Facebook

mT5

M2M-100

Достижения в области видеоконференций

StyleGAN2

NeMo

Maxine

Новые разработки Google

MakeItTalk

BeyondBelief

Hi-Fi 3D Face

SkyAR

Sea-thru

Модель от MIT для диагностики Covid-19

Для кого эта статья?

Как использовать Sharded вместе с PyTorch

from argparse import ArgumentParserimport torchimport torch.nn as nnimport pytorch_lightning as plfrom pytorch_lightning.metrics.functional import accuracyfrom transformers import BertModelclass LitBertClassifier(pl.LightningModule):    def __init__(self, n_classes, pretrained_model_name='bert-base-uncased'):        super().__init__()        self.save_hyperparameters()        self.bert = BertModel.from_pretrained(pretrained_model_name)        self.drop = nn.Dropout(p=0.3)        self.out = nn.Linear(self.bert.config.hidden_size, n_classes)        self.loss_fn = nn.CrossEntropyLoss()    def forward(self, input_ids, attention_mask):        outputs = self.bert(            input_ids=input_ids,            attention_mask=attention_mask,            return_dict=False        )        pooled_output = outputs[1]        output = self.drop(pooled_output)        return self.out(output)    def training_step(self, batch, batch_idx):        loss, acc = self._shared_step(batch, batch_idx)        self.log("acc", acc)        return loss    def validation_step(self, batch, batch_idx):        _, acc = self._shared_step(batch, batch_idx)        self.log("val_acc", acc)    def _shared_step(self, batch, batch_idx):        input_ids = batch["input_ids"]        attention_mask = batch["attention_mask"]        targets = batch["targets"]        outputs = self.forward(            input_ids=input_ids,            attention_mask=attention_mask        )        _, preds = torch.max(outputs, dim=1)        loss = self.loss_fn(outputs, targets)        acc = accuracy(preds, targets)        return loss, acc    def configure_optimizers(self):        return torch.optim.AdamW(self.parameters(), lr=2e-5)if __name__ == '__main__':    # TODO: add your own dataset    train_dataloader = ...    val_dataloader = ...    bert = LitBertClassifier()    trainer = pl.Trainer(gpus=8, plugins='ddp_sharded')    trainer.fit(bert, train_dataloader)

Интуитивно понятное объяснение работы Sharded

Использование какого-либо распределённого режима

• Курс по Machine Learning
• Обучение профессии Data Science
• Обучение профессии Data Analyst

MuZero

Infinite Nature

Time Travel Rephotography

pi-GAN

Neural Scene Flow Fields

YolactEdge

ModNet

Svoice

Hypersim

ArtLine

Важность вопросов

Предварительно обученные модели

device = "cuda" if torch.cuda.is_available() else "cpu"import torchvision.models as modelsvgg16 = models.vgg16(pretrained=True)vgg16.eval()vgg16.to(device)

• vgg16
• resnet18
• alexnet
• densenet
• inception

Создаём изображения с шумом

import numpy as npfrom PIL import Image def gen_image():    image = (np.random.standard_normal([256, 256, 3]) * 255).astype(np.uint8)    im = Image.fromarray(image)         return im  

Преобразование изображений

def xform_image(image):         transform = transforms.Compose([transforms.Resize(256),                                    transforms.CenterCrop(224),                                    transforms.ToTensor(),                                    transforms.Normalize([0.485, 0.456, 0.406],                                                         [0.229, 0.224, 0.225])])         new_image = transform(image).to(device)    new_image = new_image.unsqueeze_(0)         return new_image

Получаем предсказания

with torch.no_grad():    vgg16_res = vgg16(image_xform)    vgg16_output = F.softmax(vgg16_res, dim=1)    vgg16score, pred_label_idx = torch.topk(vgg16_output, 1)

Результаты

На изображении представлены слон, люди, большой, мяч.

Перспективы

result = resnet18(image_xform)result = F.softmax(result, dim=1)score, pred_label_idx = torch.topk(result, 1) integrated_gradients = IntegratedGradients(resnet18)attributions_ig = integrated_gradients.attribute(image_xform, target=pred_label_idx,                                                  internal_batch_size=50, n_steps=200) default_cmap = LinearSegmentedColormap.from_list('custom blue',                                                  [(0, '#ffffff'),                                                  (0.25, '#000000'),                                                  (1, '#000000')], N=256) _ = viz.visualize_image_attr(np.transpose(attributions_ig.squeeze().cpu().detach().numpy(), (1,2,0)),                             np.transpose(image_xform.squeeze().cpu().detach().numpy(), (1,2,0)),                             method='heat_map',                             cmap=default_cmap,                             show_colorbar=True,                             sign='positive',                             outlier_perc=1)

noise_tunnel = NoiseTunnel(integrated_gradients) attributions_ig_nt = noise_tunnel.attribute(image_xform, n_samples=10, nt_type='smoothgrad_sq', target=pred_label_idx, internal_batch_size=50)_ = viz.visualize_image_attr_multiple(np.transpose(attributions_ig_nt.squeeze().cpu().detach().numpy(), (1,2,0)),                                      np.transpose(image_xform.squeeze().cpu().detach().numpy(), (1,2,0)),                                      ["original_image", "heat_map"],                                      ["all", "positive"],                                      cmap=default_cmap,                                      show_colorbar=True)

occlusion = Occlusion(resnet18) attributions_occ = occlusion.attribute(image_xform,                                       strides = (3, 8, 8),                                       target=pred_label_idx,                                       sliding_window_shapes=(3,15, 15),                                       baselines=0) _ = viz.visualize_image_attr_multiple(np.transpose(attributions_occ.squeeze().cpu().detach().numpy(), (1,2,0)),                                      np.transpose(image_xform.squeeze().cpu().detach().numpy(), (1,2,0)),                                      ["original_image", "heat_map"],                                      ["all", "positive"],                                      show_colorbar=True,                                      outlier_perc=2,                                     )

Визуализация шума

Заключение

Каждый раз, когда встает заветный вопрос, апгрейдить ли карточки в серверной или нет, я просматриваю подобные статьи и смотрю такие видосы (нет, маркетинговым материалам от Nvidia конечно верить нельзя, как показал недавний кейс с числом CUDA-ядер).

Канал "Этот Компьютер" очень сильно недооценен, но автор не занимается ML. А в целом при анализе сравнений акселераторов для ML в глаза как правило бросаются несколько вещей:

• Авторы учитывают как правило только "адекватность" для рынка новых карт в США;
• Рейтинги далеки от народа и делаются на весьма стандартных сетках (что наверное в целом хорошо) без деталей;
• Популярная мантра тренировать все более гигантские сетки вносит свои коррективы в сравнения;

Не нужно быть семи пядей во лбу, чтобы знать очевидный ответ на вопрос "а какая карта лучше?": карточки серии 20* в массы не пошли, 1080 Ti с Авито до сих очень привлекательны (и не особо дешевеют как ни странно, вероятно по этой причине).

Все это прекрасно и вряд ли стандартные бенчмарки сильно врут, но недавно я узнал про существование технологии Multi-Intance-GPU для видеокарт А100 и нативную поддержку TF32 и мне пришла идея поделиться своим опытом реального тестирования карточек на архитектуре Ampere (3090 и А100). В этой небольшой заметке я постараюсь ответить на вопросы:

• Стоит ли свеч обновление на Ampere? (спойлер для нетерпеливых да);
• Стоят ли своих денег A100 (спойлер в общем случае нет);
• Есть ли кейсы, когда A100 все-таки интересны (спойлер да);
• Полезна ли технология MIG (спойлер да, но для инференса и для очень специфичных случаев для обучения);

За деталями прошу под кат.

Простые Вещи

Давайте сразу обратим внимание на слона в комнате. На момент написания этой заметки:

• 3090 довольно сложно купить и продаются они примерно с 30-40% премией. Причем нехватки новых карт есть не только в СНГ;
• A100 почти невозможно купить. Партнеры Nvidia говорили что в РФ наличии есть 1 штука, потом приедет еще несколько штук;
• Я не особо искал, но с наскоку я не нашел информации насколько PCIE версия A100 совместима с обычными ATX платформами (именно на этот вопрос партнеры Nvidia не ответили, но я предполагаю, что в картах нет своего кулера и предполагается установка в серверное шасси с "громким" феном);
• 3080 и более младшие модели (хотя они очень интересны по цене, а особенно для игр) не тестировали, т.к. у нас их нет, а не рассматривали их из-за размера памяти (я наивно предполагал, что получится крутить несколько сеток на 1 карте, но там все работает несколько иначе);

По понятным причинам холивор кормить или не кормить Амазон выносим за скобки. Уверен, что среди комментаторов найдутся свидетели церкви Амазона, но свой риг как правило "окупается" против облачных цен (особенно если собирать из дешевых компонентов) где-то за полгода-год использования.

Охлаждение

Если верить утилитам от Nvidia, то 3090 и А100 на 15-20 градусов холоднее, чем Maxwell и Pascal. Я не проводил точные замеры, но в среднем ситуация такая:

• 4 * 1080 Ti (Pascal) с минимальными хаками по охладжению работают в диапазоне 75-80С под 100% нагрузкой;
• 3 * Titan X (Maxwell) работали в районе 85С под 100% нагрузкой;
• 3 * 3090 (Ampere) работают в диапазоне 60-70С под 100% нагрузкой;
• Нигде не применялся ни разгон, ни ограничения по питанию карт или скорости кулеров, все "из коробки";
• Все карты имеют "турбину", то есть выталкивают тепло из корпуса;

На вопрос "почему" есть 3 гипотезы:

• Новый техпроцесс;
• У 3090 немного другая форма самой карты, размер вентилятора заметно больше, размер отверстия на задней панельке сильно больше;
• 3090 кажется тяжелее (может кто-то знает где найти точные цифры, карт нет под рукой сейчас);

Наглядная иллюстрация отличий карточек, может кто-то из комментариев подскажет диаметр вентилятора?

Наивные Метрики

Сначала, чтобы удостовериться, что драйвера работают верно (а когда они работали неверно, цифры были другие совсем), давайте протестируем все доступные карточки с помощью gpu-burn. Получается такая картина, которая очень сильно коррелирует с тем, что рисуют в обзорах.

MIG не тестировался тут, дальше в статье увидите почему.

Цена Вопроса

Тут важно отметить, что 1080 Ti и Titan X мы покупали с рук условно "новые" (менее года использования). Не будем останавливаться лишний раз на холиворах про майнеров и политику ценообразования Nvidia, но если бережно использовать даже б/у игровые карты их срок службы где-то 3-4 года. Цены и характеристики указаны примерные. A100 по информации от партнеров Nvidia в России в продаже имеется до нового года одна. Когда 1080Ti были доступны новыми, цены колебались примерно от 50к до 100к рублей.

Думаю очевидные выводы дальше читатели сделают сами.

Пробуем 3090 и A100 c MIG

Пробуем 3090

А теперь переходим к самому интересному к реальным тестам и собираем грабли на реальных задачах. В теории кажется, что если по памяти и вычислительным способностям 3090 или А100 в 2-3 раза превосходят 1080 Ti, то 1 такая карточка может заменить 2-3 1080 Ti и на стандартном сервере с 4 полноценными PCIE портами можно получить аналог сервера с 12 картами? Ну или можно ли взять допустим 3-4 PCIE версии A100 и получить очень мощный сервер, разделив каждую из них на несколько compute instance с использованием MIG?

Короткий ответ нет, более длинный ответ тоже нет, но с многочисленными оговорками.

Зачем спросите? Да просто серверные решения, которые полноценно поддерживают 8 16 видеокарт даже в минимальной разумной конфигурации по цене выходят в 4-5 раз дороже, чем стандартные ATX решения. А DGX Workstation или DGX продаются еще с примерно 50% премией к своей аналогичной сборке, если собирать на базе платформ от Mikrotik или Gigabyte.

Производители карт не торопятся выпускать полноценные однослотовые решения (кроме PNY c серией Quadro, но это отдельная история и скорее для дизайна или инференса). Конечно можно собрать кастомный водяной контур на 7 карточек (было несколько моделей материнских плат с 7 полноценными PCIE портами), но это "сложно" и неясно где такое размещать (да и игра не стоит свеч). С приходом PCIE 4.0 привлекательность таких решений по идее должна вырасти, но я пока не видел ничего интересного на рынке.

Пара огоровок про задачу на которой тестировали:

• Задача тренировка Spech-to-Text сетки на украинском датасете;
• Из-за самой задачи экспериментально оптимальный размер батча на один процесс 50 не получается увеличивать без потерь в скорости сходимости;
• Именно на этой задаче AMP у нас не работает (хотя работает на других при прочих равных, мы пока не поняли почему), но это скорее оптимизация. То есть дело не в железе, а в задаче. На других задачах работает, поэтому вынесем за скобки;
• Важая оговорка поскольку по сути эта задача это sequence-to-sequence, то в общем случае построение батчей тут не совсем тривиально. Файлы разной длины попадают в батч только с файлами примерно такой же длины (чтобы снизить впустую потраченные ресурсы на обработку падинга), но размер батча статический для упрощения сравнений и более быстрой сходимости;
• Динамический размер батча и просто его увеличение тестировали, но это особо не влияет на скорость и скорость сходимости (или ухудшает);

Вопреки тренду делать все более гигантские сети, мы наоборот занимаемся миниатюризацией наших алгоритмов и пытаемся делать наши сети все более эффективными. Поэтому вопрос параллелизации и ускорения обучения сетей интересен в первую очередь за счет увеличения числа воркеров, а не размера сетей и вычислительных возможностей ускорителей.

И тут мы наталкиваемся на первый подводный камень Distributed Data Parallel из PyTorch (DDP, оптимальный способ масштабирования сетей на "много" видеокарт) из коробки по сути настроен только на 1 процесс на 1 карте. То есть 1 процесс может использовать 1+ карту. 2 процесса не могут использовать 1 карту, даже если там есть большой запас по IO / compute / RAM. В старых версиях драйверов явного ограничения нет и на 1080 Ti 2 процесса на 1 карта запускаются (но получется прирост по скорости всего на 5-10% вместо 40-50%). На новых картах туда уже впилили exception.

RuntimeError: NCCL error in: /opt/conda/conda-bld/pytorch_1603729096996/work/torch/lib/c10d/ProcessGroupNCCL.cpp:784, invalid usage, NCCL version 2.7.8

Но не все так печально и плохо. Может из-за какой-то низкоуровневой магии в драйверах, может из-за TF32 (надеюсь тут знатоки подскажут), может из-за наработок в MPS 3090 ведут себя немного иначе на нашем бенчмарке:

• При прочих равных и неизменных параметрах они используют больше памяти чем Titan X и 1080 Ti (~16 GB вместо 7-8 GB);
• Скорость примерно в 3 раза выше, чем с Titan X (Maxwell);
• [Нужно еще точно замерить скорость на 1080 Ti];
• Утилизация карт на высоком уровне более 90%;

При попытках запускать 2 DDP воркера на 1 карте мы просто получаем ошибку, при попытке тренировать 2 сетки "одновременно" мы получаем кратное замедление, при увеличении батча прирост по скорости незначительный. Тайминги на 2 * 3090 примерно такие:

| Epoch   time, m | Type | Workers | Batch   | Params               ||-----------------|------|---------|---------|----------------------|| exception       | DDP  | 4       | 50 * 4  |                      || 3.8             | DDP  | 2       | 50 * 2  |                      || 3.9             | DDP  | 2       | 50 * 2  | cudnn_benchmark=True || 3.6             | DDP  | 2       | 100 * 2 |                      |

Для полноты рассказа, важно еще отметить что у Nvidia есть MPS который якобы позволяет крутить 2 процесса на картах без переключения контекста а в PyTorch есть встроенный RPC-фреймворк. Но первый я просто не смог адекватно использовать без очень непонятных низкоуровневых ошибок, а второй требует радикального переписывания кода и радикально усложняет код для тренировки моделей (хотя очень интересен долгосрочно).

Так, с 3090 все понятно. Две карточки она не заменит конечно, но сама по себе, даже имея "лишнюю" память (повторюсь, мы тренируем маленькие сети), работает в 2-3 раза быстрее. Эквивалентно ли это наличию 2-3 карт, зависит от задачи.

TLDR:

• Вы можете просто заменить карты с турбиной в своем риге на 3090 (единственный момент в 3090 2 8-пиновых коннектора для питания, но на рынке есть блоки питания по 2000-Ватт которые точно могут запитать 4-5 таких карт, опять же никто не отменял синхронизацию 2 блоков питания);
• При это скорее всего температура карт снизится на 10-20 градусов Цельсия;
• Эти карты сейчас стоят дорого и находятся в дефиците (и, наверное вряд ли пойдут в массы), но если для вас самый дорогой ресурс это время то это интересный вариант;
• Если большой размер памяти для вас критичен у вас по сути нет выбора;

Пробуем A100 с MIG

Посмотрев на метрики, доступность и цену карт, А100 на первый взгляд вообще не кажется интересным вариантом, разве что в облаке на 3 дня натренировать 1 большую сетку на небольшом не сильно приватном датасете. Также если вашим алгоритмам сильно помогает AMP / FP16, то А100 может существенно добавить скорости.

Но в A100 есть интересная технология MIG (Multi Instance GPU). По сути она позволяет разбить одну "большую и мощную" карточку на набор маленьких "подкарточек" и дальше создать виртуальные Compute Instances, к которым можно обращаться как к отдельным картам.

Там довольно много деталей, за ними откройте документацию, но там доступны такие пресеты:

+--------------------------------------------------------------------------+| GPU instance profiles:                                                   || GPU   Name          ID    Instances   Memory     P2P    SM    DEC   ENC  ||                           Free/Total   GiB              CE    JPEG  OFA  ||==========================================================================||   0  MIG 1g.5gb     19     0/7        4.75       No     14     0     0   ||                                                          1     0     0   |+--------------------------------------------------------------------------+|   0  MIG 2g.10gb    14     0/3        9.75       No     28     1     0   ||                                                          2     0     0   |+--------------------------------------------------------------------------+|   0  MIG 3g.20gb     9     0/2        19.62      No     42     2     0   ||                                                          3     0     0   |+--------------------------------------------------------------------------+|   0  MIG 4g.20gb     5     0/1        19.62      No     56     2     0   ||                                                          4     0     0   |+--------------------------------------------------------------------------+|   0  MIG 7g.40gb     0     0/1        39.50      No     98     5     0   ||                                                          7     1     1   |+--------------------------------------------------------------------------+

Доступные конфигурации

Возникает вопрос, а что если наша сетка маленькая, и A100 в теории (хотя бы на FP16) должна быть в 2 раза мощнее чем 3090? Можно ли взять 4 A100 и сделать из них допустим 12 видеокарт аналогичных по памяти и мощности 1080 Ti? Можно ли на этих многочисленных "микро-картах" тренировать нейросети так же как на нескольких обычных?

Ответим на вопросы по одному. Тут нам поможет как сама документация, так и совсем свежий блог пост от самой Nvidia.

В документации есть такой абзац:

MIG supports running CUDA applications by specifying the CUDA device on which the application should be run. With CUDA 11, only enumeration of a single MIG instance is supported.CUDA applications treat a CI and its parent GI as a single CUDA device. CUDA is limited to use a single CI and will pick the first one available if several of them are visible. To summarize, there are two constraints:- CUDA can only enumerate a single compute instance- CUDA will not enumerate non-MIG GPU if any compute instance is enumerated on any other GPUNote that these constraints may be relaxed in future NVIDIA driver releases for MIG.

Сначала, когда я его прочитал, мне показалось, что он означал только что нельзя распилить 2 карты, а можно использовать только одну. После того, как я попробовал поиграться с реальной картой, оказалось, что фреймворк внутри контейнера видит только 1 "карту" (причем видимо выбирает он только "первую"). Причем если мы внимательно прочитаем те примеры, которые Nvidia приводит в своем блоге, они по сути все относятся к сценарию "1 контейнер 1 кусочек карты" или "тюнинг 7 маленьких моделей параллельно".

Еще там есть вот такой пассаж:

There is no GPU-to-GPU P2P (both PCIe and NVLINK) support in MIG mode, so MIG mode does not support multi-GPU or multi-node training. For large models or models trained with a large batch size, the models may fully utilize a single GPU or even be scaled to multi-GPUs or multi-nodes. In these cases, we still recommend using a full GPU or multi-GPUs, even multi-nodes, to minimize total training time.

Если использовать MIG по прямому назначению, то есть делить карту на физические кусочки (slices), назначать им Compute Instances и прокидывать их в изолированные контейнеры то все работает как надо. It just works.

Итоговые Замеры

Тут не совсем идеальные сравнения (на Титане у меня был DP а не DDP), да и на A100 в итоге я не стал гонять эксперименты на 10, 20, 30 часов и впустую (зачем греть атмосферу), но я замерил время на 1 эпохе.

Когда крутишь 1 сетку на A100 утилизация не достигает даже и половины ну то есть если бы ее можно было распилить на 2-3 карты, все было бы прекрасно

На 1080 Ti ресурсы были только чтобы прогнать 1 эпоху.

Выводы

Выводы про 3090:

• Если вынести за скобки вопрос доступности, то апгрейд стоит делать. Вы получите минимум x2 по скорости. Если у вас работает AMP то может даже и все x3-x4;
• С учетом роста производительности, цена кажется немного завышенной, но не заоблачной. Понижение цены где-то на 30-40% как мне кажется было бы адекватным;
• Когда выходило новое поколение карт все беспокоились насчет охлаждения. Она на удивление холодная;
• Единственная беда карточка просит 2 8-пиновых коннектора для питания;

Выводы про A100:

• Если судить по цене деленной на производительность, карта не очень интересная (наценка в 2-3 раза против 3090);
• То, что Nvidia сделала технологию для эффективного использования для инференса это круто, а то карты стали уж слишком большими и крутыми;
• Если вы можете использовать обычные игровые карты (те же 1080 Ti или PNY Quadro) для инференса, то они представляют сильно больший value for money;
• Есть большой нераскрытый потенциал в развитии технологии MIG;
• Если вам нужно реально 40 GB памяти и много compute, то альтернатив особо нет;
• Неясен вопрос с установкой PCIE версии в обычные ATX корпуса без кастома, "колхоза" или воды ;