Прослушал курс "MLOps for ML Engineers", МФТИ, весна 2024

В одном MLOps чате я увидел ссылку на плейлист с видео этого курса. В первую очередь меня заинтересовал контент, связанный с NVIDIA GPU и Triton Inference Server.

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

Читайте мои впечатления от курса и конспект.

А ещё вам могут быть полезны следующие материалы

Как подготовиться и пройти System Design Interview — конспект и анализ выступления Александра Поломодова.
Прочитал и разобрал на молекулы книгу Building Microservices, 2nd Edition - Sam Newman.
Мой план обучения: ссылки на книги, курсы, каналы по темам дизайна масштабируемых и надежных ML систем, разработки программного обеспечения на Python, DevOps, MLOps и Data Engineering, SRE.

Впечатления от курса

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

Многое из курса я уже знал и использовал ранее в своей работе. Но это лишь подтверждает, что он полезен для инженеров.

Читали: Владислав Гончаренко и Евгений Астафуров. Выяснилось, что Владислав — хороший практик. Он постоянно приводил примеры, как он решал те или иные задачи и какие технологии для чего применимы в реальной жизни. Я считаю, что это самое ценное в обучении. Евгений подкупил глубоким познанием технологий NVIDIA. Конспект по его лекциям и семинарам получился самым большим.

При этом, некоторый материал показался сложным в понимании для новичков в индустрии. Например, на лекции по Docker студенты признавались, что впервые о нём услышали. А на лекции по ООП длительностью чуть менее 1 часа рассказывали про ООП и паттерны проектирования. Это очень сжато. То есть их буквально вывезли на середину реки и выбросили в воду.

Я не знаю, какие у них получились итоговые результаты. Но если они положительные, то студенты в МФТИ действительно способны изучать сложные концепции на лету.

По результатам прослушивания курса я стал более эффективным инженером и еще немного приблизился к своей цели. А ещё я наметил направления для дальнейшего изучения. В первую очередь это касается технологий NVIDIA и направления DeepLearning Engineering в части повышения performance и GPU utilization.

Ссылка на плейлист.

Конспект

1. Лекция: Introduction to MLOps

Motivation for MLOps:
1. Фреймворк CRISP-DM. Широко известен в индустрии.
2. Фреймворк Team Data Science Process (TDSP) от Microsoft. Концентрируется на ролях в команде.
Что такое MLOps:
1. Дали определение DevOps, но при этом не рассказали про метрики Dora. Слабенько.
2. Дали определение MLOps — он лежит на пересечении ML, DevOps и Data Engineering. Я бы добавил еще Software Engineering и SRE.
3. Область деятельности, которая подразумевает интеграцию между собой разных дисциплин.
4. MLOps наиболее развит в big tech: Amazon, Google, Nvidia, Yandex, Databricks. Понравилась эта схема:
  MLOps maturity vs Models in production. Источник: AWS Machine Learning Blog.
5. Дали ссылку на Data + AI Summit от Databricks. Зашёл посмотреть. Понравился доклад "A Practitioner’s perspective on LLMOps".
MLOps subtasks:
1. Хранение и управление кодовой базой.
2. Хранение и управление данными.
3. Логирование экспериментов и продакшена.
4. Вычислительные мощности.
5. Хранение и оптимизация работы моделей.
6. Эффективное применение моделей.
7. Оптимизация весов эмбеддингов и поиска ближайших соседей.
8. Разметка данных и краудсорс.
Big tech MLOps tech stacks overview:
1. Amazon SageMaker for MLOps.
2. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines in machine learning.
3. CI — continuous integration.
4. CD — continuous delivery.
5. CT — continuous training.
6. NVIDIA — What Is MLOps?.
7. Microsoft Azure — MLOps: Model management, deployment, and monitoring with Azure Machine Learning.
8. Yandex: YTSaurus + Nirvana + Toloka.
9. Databricks — Glossary: MLOps.
MLOps at academia:
1. It just doesn't exist :-)
2. FOSS требует больших усилий по интеграции. Необходимо писать glue code самому.

2. Лекция: Python Environments

Управление виртуальными окружениями:
1. venv;
2. virtualenv;
3. poetry— я использую его в своих проектах;
4. conda— по умолчанию включено много пакетов; может устанавливать non-python зависимости:
  1. miniconda — без пакетов, только инструменты управления;
  2. mamba;
5. pyenv.
6. pipx;
7. pipenv
Управление зависимостями:
1. pip;
2. pip-tools;
3. poetry;
4. Pipfile (via pipenv).
5. Автор использует в качестве менеджера окружений conda и в качестве менеджера зависимостей poetry. Для этого в конфиге poetry нужно указать:
```
poetry config virtualenvs.create false
```
Альтернатива — изоляция внутри Docker-контейнера.

Command Line Interfaces (CLI):

builtin — argparse. По мнению автора неудобен.

fire.

import fire

def hello(name):
  return 'Hello {name}!'.format(name=name)

if __name__ == '__main__':
  fire.Fire()

$ python example.py hello World
Hello World!

click.

3. Лекция: Docker & co

von Neumann architecture.
OS: Unix (MacOs), Linux, Windows. POSIX.
Scaling: vertical, horizontal.
Balancing.
Database.
Local cache.
SLA.
Docker, Docker Compose, Podman.
Kubernetes.

4. Семинар: Практика работы с контейнерами

docker export, docker import, docker save.
Посмотрели слои образов путем распаковки их .tar.

5. Лекция: Software Development

YAGNI.
DRY.
KISS.
Базовые принципы в части ООП (лектор приводит скриншоты их книги А. Швеца):
1. Программируйте на уровне интерфейса, а не на уровне реализации.
2. Композиция лучше наследования.
3. SOLID.
High cohesion & Low coupling (особенно актуально для микросервисной архитектуры):
1. Cohesion — степень, в которой модуль представляет логически атомарную единицу.
2. Coupling — степень, в которой один модуль зависит от другого модуля.
  Хорошо выбранные границы
  
  Плохо выбранные границы
3. Невозможно добиться минимального coupling (decoupling) без нарушения целостности (cohesion) и наоборот. Иначе получится деструктивный decoupling. В общем, нужно знать меру.
Google Python Style Guide.

6. Лекция: Управление кодом и git servers

Version Control Systems (VCS).
1. Local only.
2. Client-server.
3. Distributed. В эту категорию входит git.
Git servers:
1. GitHub (proprietary).
2. GitLab (open source, but not free).
3. Gitea (FOSS).
4. Gogs (FOSS).
Сайт поиска FOSS альтернатив для proprietary software.
Attlassian Getting Git right (особенно полезны Advanced Tips).
Дистрибуция кода:
1. Source code → git pull на сервере.
2. Packages → pip install, pip update.
3. Еще можно использовать git submodules там, где это обоснованно.
CI/CD

7. Лекция: Code quality tools

Code styles: PEP 8, PEP 257 (docstrings).
black, yapf, autopep8.
isort.
flake8, pylint.
bandit.
mypy.
nbQA — code quality for Jupyter notebooks.
prettier.
pre-commit.
sphinx.
pathlib.
pytest, pytest-cov.

От себя добавлю: ruff, wemake-python-styleguide, pyright, yamllint, mkdocs-material, .editorconfig, commitizen, плагины в IDE.

Конфиги для таких тулов я сохраняю в специальном репо styleguide-config и импортирую в новые проекты с помощью nitpick.

8. Лекция: Хранение и управление данными и конфигурацией

Источники данных:
1. Первичные (primary): ввод с клавиатуры, web (Kafka → Hadoop → Airflow → ML), фото и видео (беспилотники).
2. Вторичные (secondary) — обработанные первичные данные, sql-запросы к БД, web scraping, LLM, синтетические данные (3D моделирование).
Классы данных:
1. Структурированные → SQL.
2. Неструктурированные → NoSQL.
Хранение данных:
1. Локально.
2. Удаленно.
3. Распределённо:
  1. небольшие данные:
    1. DVC;
    2. git LFS.
  2. большие данные:
    1. MapReduce;
    2. Hadoop или YTsaurus.
DVC: код + данные + конфигурация → модель (бинарный артефакт).
ETL, ELT.
DataHub.
Experiments parametrization:
1. Системы управления конфигурациями:
  1. pydantic;
  2. python-decouple;
  3. dynaconf;
  4. hydra.
2. Feature Flags.
3. Vault.

9. Семинар: DVC и hydra

Демо работы DVC.
Демо работы hydra.
Осенью в МФТИ будет проходить курс по продуктовой аналитике данных.
В МФТИ читают курс по BigData.

10. Лекция: логирование и управление экспериментами

Логировать имеет смысл долго длящиеся эксперименты. Это позволит понять, когда и почему процесс упал.
Tensorboard (standalone), MLFlow, ClearML, Kubeflow, etc.
MLFlow:
1. Записывает метаданные в СУБД (например, PostgreSQL) и артефакты в другое хранилище (например, S3).
2. Tracking. Record and query experiments: code, data, configs, results.
3. Projects. Package DS code in a format to reproduce runs on any platform.
4. Models. Deploy ML models in diverse serving environments.
5. Model Registry. Store, annotate, discover and manage models in a central repo.
6. Нет RBAC из коробки. Нужно устанавливать и настраивать плагины.
7. Отсутствие масштабирования.
ClearML:
1. Позиционируется как более production ready MLOps платформа.
2. Часть функций платная.
3. Обращать внимание не лицензию.
4. Можно добавлять workers.
5. UI более современный.
Kubeflow:
1. Нужен Kubernetes.
2. Можно сервить модели с помощью KServe (на базе Knative).
3. Прим: есть аналог от RedHat — RHODSAI.
Proprietary:
1. W&B, neptune.ai и т.п.
2. Из-за санкций нам не подходят зарубежные решения.
Визуализации:
1. Примеры, в каких библиотеках реализовано — The Data Visualisation Catalogue.
2. Примеры, как делать не надо — Friends Don't Let Friends Make Bad Graphs.
Фреймворки для обучения:
1. PyTorch (DL, ecosystem):
  1. PyTorch Lightning — самый популярный, низкий порог входа.
  2. Catalyst — написана Сергеем Колесниковым, R&D в Т-Банк. Больше всего нравится преподавателю.
  3. PyTorch Ignite — официальная, наименее популярная.
  4. Hugging Face — перспективная библиотека, растущая популярность.
2. Ray.
3. DVC Experiments.
4. MLFlow Experiments.
5. pachyderm.
6. fast.ai (very poor coding level).

11. Семинар: Lightning & MLFlow

Доступ к документации Lightning теперь закрыт из РФ.
Смотрели код приложения.

12. Лекция: Вычислительные ресурсы

Контуры вычислений

Offline:
1. Могут занимать произвольное количество времени и ресурсов.
2. Могут падать без последствий для бизнеса.
3. Имеют относительно низкий приоритет выполнения.
4. Примеры: построение ежедневной аналитики, EDA датасетов, обучение моделей.
Online (realtime):
1. Must meet estimated time of arrival (ETA) (usually < 1 sec).
2. Use predefined amount of resources.
3. Failure causes apps to break.
4. Have highest priority.
5. Примеры: кредитный скоринг, рекомендательные системы, поисковые системы, чат боты, генерация маршрутов, рекламные системы, HFT.
Near realtime (NRT):
1. Четкого определения не предоставили. Время обработки больше RT, но меньше batch.
2. Must meet estimated time of arrival (ETA) (usually < 10 minutes).
3. Use predefined amount of resources.
4. Failure needs to be fixed with a bit relaxed deadline.
5. Have high priority.
6. Примеры: антиспам, антивирусная защита в облаках, speech-to-text, site monitoring, video processing (transcoding, video generation), ALS models computing (модели для рекомендательных систем), CI/CD processes.
Edge:
1. Must meet estimated time of arrival (ETA) (usually < 10-100 ms).
2. Use predefined amount of resources (stored on device).
3. Failure causes apps to break.
4. Have high priority.
5. Примеры: IoT, visual editors on smartphones, bio-identification, self-driving cars.

Типы вычислительных ресурсов

Bare-metal.
Virtual.
1. classical VM: KVM, VMWare.
2. Docker.
Создаваемые под задачу:
1. MapReduce.
2. Serverless computing.
3. Очереди задач для offline контура (slurm, clearml).
4. Kubernetes, Kubeflow.
Job runners:
1. Docker Swarm.
2. Kubernetes/OpenShift.
3. Очереди задачи (slurm workload manager, clearml).
4. Serverless.
5. Airflow.
6. cron.

13. Семинар: Apache Airflow

См. раздел Apache Airflow в моей записной книжке.

Не подходит для потоковой передачи данных и realtime обработки событий.
Порог входа низкий, но не нулевой.
Рассмотрели: DAGs, способы их запуска, Control Flow, Trigger rules, Operators, Task states, Zombie & Undead tasks, UI.

14. Лекция: NVIDIA

1. NVIDIA CUDA

Модель вычислений PTX Machine

Parallel Thread Executor (PTX) — низкоуровневоя виртуальная машина параллельного выполнения потоков.
PTX и ISA (Instruction Set Architecture) представляет собой GPU как устройство параллельных вычислений с данными.
Масштабируемое вычисление:
1. параллельные вычисления с данными;
2. высокая арифметическая интенсивность;
3. соотношение арифметических операций к операциям с памятью (арифметическая интенсивность; следует её повышать).
Со-процессор:
1. Компиляция функции ядра в набор инструкций PTX.
2. Перевод в целевой набор инструкций для GPU.

Иерархия потоков CUDA

Grid with Clusters: Cluster → Cooperative Thread Arrays (CTAs).

Согласованные массивы потоков

Ядро — специальная функция, написанная для выполнения на GPU.
Cooperative Thread Array (CTA) — массив потоков, выполняющих ядро одновременно или параллельно. В каждом потоке CTA выполняется одна и та же функция ядра, но как правило на разных частях данных (на разных элементах батча, на разных частях тензора или матрицы). Внутри CTA могут общаться друг с другом. Для этого указываются точки синхронизации. У каждого потока CTA есть ID.
Single Instruction Multiple Threads (SIMT) — режим выполнения CTA.
Варп — максимальное подмножество потоков из CTA, выполняющих одни и те же инструкции одновременно (выполняющиеся в режиме SIMT). Размер варпа машинозависимый, от 32 потоков и выше в современных GPU.
Кластер согласованных потоков — группа CTA, которая выполняется параллельно или одновременно и синхронизируются между собой через shared memory. Барьеры на уровне кластера используются для синхронизации всех потоков в кластере (барьер — это примитив синхронизации).

Иерархия памяти

Набор мультипроцессоров SIMT

Масштабируемая архитектура.
Блоки сетки распределяются по мультипроцессорам для параллельного выполнения.
«Конвейерное выполнение» — новые блоки запускаются на освободившихся ресурсах.
Мультипроцессор содержит ядра Scalar Processor (SP) (CUDA ядра) и встроенную shared memory.
«Нулевой» оверхэд шедулера.
Барьерная синхронизация в SP.
Мелкозернистый параллелизм.

Модель выполнения

На каждом этапе выполнения инструкции блок SIMT выбирает варп, готовый к выполнению и выдает следующую инструкцию активным потокам варпа.
Варп выполняет одну инструкцию за один раз.

Независимое планирование потоков

До Volta варпы использовали общий программный счетчик для всех потоков в варпе → потоки из одного варпа не могли сигнализировать друг другу о чем-то или обмениваться данными → алгоритмы, требующие частого и мелкозернистого обмена данными с мьютексами, могли привести к дэдлокам, в зависимости от того, из какого варпа исходили конкурирующие потоки.
Начиная с Volta появилось независимое планирование потоков → позволило достичь полной конкурентности между потоками независимо от варпа.
Сам шедулер определяет, как группировать активные потоки вместе в SIMT блоке → дает высокую пропускную способность при гораздо большей гибкости.

Встроенная общая память (On-Chip Shared Memory)

Каждый мультипроцессор (SM) имеет встроенную память 4-х типов:

Один набор локальных 32-битных регистров на процессор.
Параллельный кэш данных, который используется всеми скалярными ядрами процессора, где располагается shared memory.
Кэш констант read-only, который используется всеми скалярными ядрами процессора и ускоряет чтение из shared memory.
Текстурный кэш read-only, который используется всеми скалярными ядрами процессора и ускоряет чтение из текстурной памяти.

Типы данных

Основные (фундаментальные) типы PTX:

Basic Type	Fundamental Type Specifiers
Signed integer	`.s8`, `.s16`, `.s32`, `.s64`
Unsigned integer	`.u8`, `.u16`, `.u32`, `.u64`
Floating-point	`.f16`, `.f16x2`, `.f32`, `.f64`
Bits (untyped)	`.b8`, `.b16`, `.b32`, `.b64`, `.b128`
Predicate	`.pred`

Альтернативные типы для вычислений с плавающей точкой:

bf16 — 16-битный формат с плавающей точкой с 8 битами для экспоненты и 7 битами для мантиссы.
e4m3 — 8-битный формат с плавающей точкой с 4 битами для экспоненты и 3 битами для мантиссы. Кодирование e4m3 не поддерживает бесконечность.
e5m2 — 8-битный формат с плавающей точкой с 5 битами для экспоненты и 2 битами для мантиссы.
tf32 — специальный 32-битный формат с плавающей точкой, поддерживаемый инструкциями умножения и аккумуляции матриц с тем же диапазоном, что и .f32, и с уменьшенной точностью (>=10 бит).

Упакованные:

.f16x2 — содержит 2 значения с плавающей точкой .f16.
.bf16x2 — содержит 2 значения альтернативного формата с плавающей точкой .bf16.
.e4m3x2 — содержит 2 значения альтернативного формата с плавающей точкой e4m3.
.e5m2x2 — содержит 2 значения альтернативного формата с плавающей точкой e5m2.
Тип .f16x2 подерживается как основной тип. Но типы .bf16x2, .e4m3x2, .e5m2x2 не могут использоваться как фундаментальные типы. Они поддерживаются как типы для определенных инструкций. Например, если мы кладем в переменную регистра тип .bf16x2, то она должна быть объявлена с типом .b32. Переменная регистра, содержащая .e4m3x2 или .e5m2x2, должна быть объявлена с типом .b16.

Целочисленные:

PTX поддерживает 2 варианта типов упакованных целочисленных данных: .u16x2 и .s16x2.
Упакованный тип данных состоит из 2 значений .u16 или .s16.
Переменная регистра, содержащая данные .u16x2 или .s16x2, должна быть объявлена с типом .b32.
Типы упакованных целочисленных значений данных не могут использоваться как фундаментальные типы. Они поддерживаются только для определенных инструкций.

Тензоры

Тензор — многомерная матричная структура в памяти.

Свойства:

размерность;
размеры в каждом измерении;
типы отдельных элементов;
Tensor stride — шаг тензора в каждом измерении.

Инструкции для GPU в PTX для тензоров, кроме прочего, включают:

копирование данных между глобальной и общей памятью;
уменьшение данных в тензоре.

Размерность, размер и формат тензора:

Для GPU: 1D, 2D, 3D, 4D, 5D.
Битовый тип: .b32, .b64.
Целое число: .u8, .u16, .u32, .s32, .u64, .s64.
Числа с плавающей точкой и альтернативные: .f16, bf16, .tf32, f32, .f64.

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

2. NVIDIA GPU

Преимущества использования GPU

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

CUDA

CUDA (Compute Unified Device Architecture) — универсальная платформа параллельных вычислений и программная модель. Представлена NVIDIA в ноябре 2006 года.

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

Performance Guidelines

Все уже предусмотрено в PyTorch, но лучше знать базовые принципы.

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

Максимизация утилизации

Полная утилизация достигается, когда планировщики варпов всегда имеют какую-то инструкцию для выдачи для какого-то варпа в каждом тактовом цикле в течение периода latency.
Если какой-либо входной операнд находится в памяти вне чипа, latency намного выше: обысно сотни тактовых циклов.

Максимизация memory throughput

Передача данных между хостом и GPU: pinned memory (флаг in-memory в pytorch), page locked memory, mapped memory. DMA — Direct Memory Access, передача данных между GPU и хостом выполняется более эффективно. По сути — блокирование памяти хоста, чтобы GPU с ней работала.
Доступ к памяти устройства: global memory. Лучше, когда все адреса сгруппированы в памяти, а не разбросаны по ней → меньше транзакций памяти → быстрее работа.
Практическое применение в pytorch. Использовать тензоры подходящей формы и размеров.

Максимизация пропускной способности инструкций

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

Пропускные способности в количестве операций на цикл на один мультипроцессор

Pytorch автоматически обнуляет денормализованные (субнормальные) числа — близкие к нулю числа с плавающей точкой.

Recap

Мультипроцессор — базовая вычислительная единица GPU.
Streaming Multiprocessor (SM) — другое название мультипроцессора в контексте CUDA. SM содержит набор функциональных единиц, таких как: SP, блоки памяти и прочее.
Scalar Processor (SP) — также известен как CUDA Core / Tensor Core / RT Core. Базовая вычислительная единица внутри SM.

GPU состоит из множества SM, которые состоят из множества SP (CUDA-ядер).

3. Deep Learning Performance

Цели

Научиться определять, где bottleneck: в памяти или в арифметике.
Как от него избавиться.
Как подогнать обучение и инференс под конкретную архитектуру.

Арифметическая интенсивность

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

Уважительное использование тензорных ядер

Тензорные ядра наиболее эффективны, когда ключевые параметры операции:

Кратны 4 при использовании TF32.
Кратны 8 при использовании FP16.
Кратны 16 при использовании INT8.

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

Ключевыми параметрами являются:

Для полносвязных слоев ключевыми параметрами являются размер батча и количество входов и выходов.
Для сверточных слоев — количество входных и выходных каналов.
Для рекуррентных слоев — размер батча и скрытая размерность.

Размер батча

Кратен большим степеням 2, как минимум 65.
Использование кратности > 512 особого прироста не даёт.
Делимость на степень 2 наиболее важна для малых параметров. Выбор 512 вместо 520 дает больший прирост, чем выбор 5120 вместо 5218.
Чтобы большие степени 2 улучшили эффективность, операция должна быть ограничена арифметически, а не по памяти.

Линейные слои

Для эффективной работы на Tensor Cores, размер батча и количество входов и выходов выбирать так, чтобы они делились нацело на:

4 (TF32).
8 (FP16).
16 (INT8).

В случае А100 параметры должны делиться нацело на:

32 (TF32).
64 (FP16).
128 (INT8).

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

Полносвязные слои в трансформерах

Сверточные слои

Количество входных и выходных каналов, делящихся на 8 (для FP16) и 4 (для TF32), чтобы эффективно работать с Tensor Cores.
Размер батча, количество входных и выходных каналов, делящихся хотя бы на 64 и идеально на 256, чтобы уменьшить эффект квантования волн.
Библиотеки NVIDIA предлагают набор различных алгоритмов свертки с различными характеристиками производительности, зависящими от параметров свертки. Когда размер входных данных, обрабатываемых сетью, одинаков в каждой итерации, автотюнинг является эффективным методом для обеспечения выбора идеального алгоритма для каждой свертки в сети. Для PyTorch включите автотюнинг, добавив torch.backends.cudnn.benchmark = True.
Выбирайте расположение тензоров в памяти, чтобы избежать транспонирования входных и выходных данных. Существует две основные конвенции, каждая из которых названа в соответствии с порядком размерностей: NHWC и NCHW. Рекомендуется использовать формат NHWC, где это возможно.

Performance Background

Execution Model Background

Understanding Performance

Размер батча, высота и ширина

15. Лекция + демо: деплой моделей; NVIDIA Triton Inference Server

Общие сведения

Triton Inference Server

Enterprise grade, security, API stability.
Concurrent model execution.
Dynamic batching.
Many supported frameworks out of the box.
Live updates.
Allowed both CPU and GPU instances.
Allowed multiple instances for the same model.
Support for arbitrary function execution.
Model ensemble out of the box (DAG).
Optimized and certified to deploy anywhere: cloud, datacenter, edge...

Архитектура

NVIDIA Triton Inference Server architecture

Dynamic batching

Ensembling

16. Лекция: Annotation

Разметка требуется для supervised моделей.

Annotation pipeline: overlap, honeypots

Owners:
1. Составляют подробную инструкция для разметки: мотивации, корнер-кейсы. Лучше всего делать её, попробовав выполнить задание самому по сэмплам.
2. PMs, MLEs и т.п. Занимаются разметкой временно, для решения задачи. Далее переключаются на основную деятельность и передают эстафету Experts.
Experts:
1. Им передается знание об инструкции в поддержку.
2. 100% времени занимаются инструкцией и тем, чтобы она дошла до финальной разметки.
3. Обычно переписывают инструкции в удобочитаемый вид для исполнителей; 100 страничный документ ассессоры читать не будут.
Leaders:
1. Кураторы ассессоров. Более доверенные ассессоры.
Assessors:
1. Финальные исполнители, которые получают инструкцию в работу.

Honeypots (Golden Set) — раз в N вопросов ассессору подмешивается вопрос с заранее известным ответом, по которым оценивается качество его ответов. Формулируют Experts или Leaders.

Overlap — обычно Majority Vote от 3. Для дорогих разметок можно продвинутые техники агрегации.

People management: in-house, crowd

Characteristic	In-house	Crowd
Scalability	low	high
Quality	high	low
Cost	moderate	low

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

Experts должны наниматься full time, Assessors с оплатой per label. Можно нанимать субподрядчиков, агрегаторов.

Лучше иметь более или менее постоянных ассессоров. Будет полезно самому поработать ассессором на Я.Толоке. Это поможет составлять более качественные ТЗ. Можно попробовать быть фродером, чтобы понять, как нужно выстраивать контроль качества.

Tools

List of Open-Source Annotation Tools for Machine Learning Research.

Yandex Toloka. Отличный продукт. Я сам в 2020 году уже запускал проекты разметки на этой платформе. Мне понравилось.
Amazon Mechanical Turk.
Self-hosted:
1. Standalone — VIA.
2. Server based — CVAT.
3. Label Studio.
Super-simple:
1. brat.
Supervisely.

Project management

Можно создать Pool, из которого мы будем брать honeypots, положим в него только наших Leaders, overlap 3 (без экономии), уровень скилла - высокий.

Другой Pool сделаем общий. Из Pool Leaders мы будем брать honeypots и грузить их в общей Pool.

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

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

Что дальше?

Нашли эту статью полезной? Поделитесь ею и помогите распространить знания!
Нашли ошибку или есть идеи 💡 о том, что и как я могу улучшить? Напишите мне в Telegram.
Хотите узнать обо мне больше? Читайте здесь.