Компания Uber уже 8 лет применяет технологии машинного обучения (Machine Learning, ML). В 2016 году мы впервые начали использовать сложные ML-модели, основанные на правилах. Мы внедрили их в командах, которые занимались подбором водителей и пассажиров и ценообразованием. С тех пор мы многого добились. А именно, речь идёт о том, что сегодня модели глубокого обучения являются неотъемлемой частью большинства приложений, критически важных для деятельности компании. Мы, кроме того, активно исследуем возможности, предлагаемые генеративными ИИ-моделями (Artificial Intelligence, AI, искусственный интеллект). По мере того, как растут масштаб и сложность AI/ML-моделей, увеличивается и потребность в высокоэффективной инфраструктуре, которая способна достойно обеспечивать их работу. За последние несколько лет мы, руководствуясь стратегическими соображениями, внедрили целый ряд инфраструктурных решений, основанных как на CPU, так и на GPU. Эти решения ориентированы на динамическое масштабирование наших систем и на то, чтобы удовлетворять потребности всё новых и новых задач, возникающих в сфере машинного обучения. Развитие нашей инфраструктуры заключалось во внедрении уникальных конфигураций аппаратного обеспечения, в расширении программных библиотек, в интеграции различных фреймворков распределённого обучения и в непрерывном совершенствовании нашей платформы Michelangelo. Эта платформа обеспечивает полный цикл работы с моделями. Все эти постепенные улучшения происходили благодаря тем знаниям и опыту, которые мы получили в процессе работы, а так же благодаря тому, что мы, что-то меняя, постоянно сверялись с трендами индустрии и со стратегией развития Uber. В сущности, все эти улучшения нацелены на то, чтобы компания соответствовала бы постоянно меняющимся потребностям наших партнёров и пользователей.

Цель и важнейшие метрики

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

1. Максимизация использования существующей инфраструктуры.

2. Создание новых систем, способных поддерживать работу нагрузок новых типов, таких, как обеспечение работы генеративного ИИ.

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

Техническая возможность и надёжность обучения моделей. ML-пользователи ожидают, что их модели в процессе обучения будут успешно сходиться, что это будет происходить без ошибок и в заданное время (речь идёт, в зависимости от сложности моделей, о неделях или о месяцах). Например, обучение достаточно больших и сложных моделей, вроде Falcon 180B, может занимать много месяцев. А чем дольше ведётся решение подобных задач — тем выше риск возникновения проблем, связанных с надёжностью обучения моделей. Следовательно, наша цель здесь — достичь уровня доступности в 99% для всех компонентов, от которых зависит обучение, что позволит обеспечить стабильность и надёжность его результатов.

Эффективность обучения моделей. Наше стремление к эффективности работы систем предусматривает тщательный бенчмаркинг различных GPU-конфигураций и назначение им рейтингов в плане оценки показателей цены/производительности. Речь идёт о локальных и облачных системах, предназначенных для запуска на них различных нагрузок. Мы оцениваем эффективность обучения, используя метрики, подобные MFU (Model Flops Utilization, уровень использования моделью доступных вычислительных ресурсов), что позволяет нам гарантировать оптимальную загруженность GPU. Наша цель заключается в том, чтобы избежать простоев GPU, рационально запуская задачи обучения моделей в периоды низкой загрузки работающих систем, применяя реактивное масштабирование. Мы стараемся поддерживать высокие уровни загрузки систем, что позволяет максимизировать эффективность использования ресурсов. Мы, с одной стороны, стремимся к высокому уровню загрузки ресурсов, а с другой — к тому, чтобы обеспечивать справедливое распределение ресурсов между различными пользователями.

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

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

Оптимизация существующей локальной инфраструктуры

Федерация пакетных задач в Kubernetes

Наши GPU-ресурсы распределены по нескольким кластерам Kubernetes, находящимся в различных зонах доступности (Availability Zones) и регионах (Region). Такое распределение ресурсов определяется, с одной стороной, доступностью GPU, а с другой — ограничением на число узлов, которые можно разместить в одном кластере Kubernetes. Применение подобной архитектуры приводит к появлению двух основных проблем:

1. Инженерам по машинному обучению необходимо знать о том, как именно устроена инфраструктура.

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

Для преодоления этих проблем мы создали унифицированный федеративный уровень для пакетных нагрузок, в том числе — для задач Ray и Apache Spark, названный Michelangelo Job Controller. Этот компонент играет роль централизованного интерфейса для решения всех задач по планированию нагрузок. Он скрывает детали реализации базовых кластеров Kubernetes, доступ к которым он обеспечивает. Кроме того, он распределяет рабочие нагрузки, основываясь на различных политиках (учёт нагрузки, оптимальная упаковка задач). Здесь, кроме того, учитываются соображения, касающиеся использования наиболее подходящих вычислительных ресурсов, и того, где именно хранятся данные, необходимые для конкретной рабочей нагрузки. Мы планируем подробнее рассказать об этом в одном из следующих материалов.

Модернизация сети, нацеленная на повышение эффективности обучения LLM

Расширяя инфраструктуру в расчёте на удовлетворение потребностей приложений, основанных на генеративных ИИ-моделях, важно обратить особое внимание на масштабирование пропускной способности сетей в конфигурациях, предусматривающих и вертикальное, и горизонтальное масштабирование ресурсов. То же самое касается и расширения инфраструктуры, ориентированного на повышение эффективности распределённого обучения моделей, применяемого для тонкой настройки опенсорсных LLM (Large Language Model, большая языковая модель), Это влечёт за собой необходимость внедрения целого ряда чрезвычайно важных решений. Среди них, кроме прочего — связь видеокарт с помощью NVlink, модернизация сетевых соединений, эффективное управление перегрузками каналов связи, контроль QoS (качества обслуживания), внедрение специализированных монтажных стоек и сетевых топологий.

Вот — краткий обзор результатов, полученных в ходе изучения показателей обучения LLM. Здесь ярко видно значительное влияние увеличения пропускной способности сети и механизмов управления перегрузками на повышение эффективности обучения и улучшение соотношения цена/производительность. Обучение модели в обновлённой сети мы сравнивали с обучением с применением конфигурации, используемой до обновления. Наблюдения выявили почти двукратное увеличение скорости обучения и значительное сокращение длительности обучения. В ходе обучения модели на нескольких узлах дублирование данных на различных узлах приводит к росту потребности в локальной памяти и повышает нагрузку на подсистемы ввода/вывода. Проведённый нами анализ позволяет рекомендовать 4-кратное увеличение пропускной способности сетевых каналов (с 25 Гб/с до 100 Гб/с) на каждом из GPU-серверов. Это может удвоить возможности системы по обучению моделей. Реализуя подобные решения, важно сделать так, чтобы продолжительные и объёмные потоки данных, генерируемые при проведении сеансов обучения серьёзных моделей, не оказывали негативного влияния на другие высокоприоритетные службы. Делается это путём правильной изоляции трафика и посредством контроля QoS.

Модернизация памяти для улучшения показателей выделения памяти, необходимой GPU

Современные AI/ML-задачи требуют большего объёма системной памяти на один GPU-воркер, чем те задачи, в расчёте на которые мы проектировали систему. Неустранимые физические ограничения подсистемы памяти — такие, как фиксированное количество каналов памяти на каждом из серверов, и такие, как объём DIMM-модулей, установленных при введении новых серверов в строй, снизили наши возможности по масштабированию выделения памяти, необходимой GPU. Для решения этой проблемы мы инициировали проект по удвоению объёма памяти на этих серверах (с 16 Гб до 32 Гб на один DIMM-канал). Мы, кроме того, занимаемся созданием процедуры, позволяющей изменять назначение и повторно использовать DIMM-модули из списанных серверов. Подобные оптимизации позволяют максимизировать уровень использования существующей ML-инфраструктуры и наилучшим образом использовать имеющиеся в нашем распоряжении ресурсы. Мы расскажем о том, как всё это помогло повысить эффективность нашей системы, в одном из следующих материалов. Параллельно мы начали работы по оптимизации требований к ресурсам, предъявляемым заданиями по обучению моделей. Как показано в этом исследовании, ручной подбор оптимальных конфигураций ресурсов — это очень сложная задача. Автоматизация этого процесса способна помочь в деле повышения эффективности выделения памяти, необходимой видеокартам.

Создание новой инфраструктуры

Оценка соотношения цена/производительность конфигураций различных облачных систем

В конце 2022 года, начиная проект по переходу к облачной инфраструктуре, мы проанализировали множество моделей CPU и GPU, предлагаемых различными облачными провайдерами. Мы хотели сравнить их показатели соотношения цена/производительность, используя проверенные бенчмарки: от тестовых систем, основанных на деревьях решений и моделей глубокого обучения — до больших языковых моделей. Вдобавок к этому мы применяли собственные наборы данных и модели Uber — такие, как deepETA и deepCVR. Этот анализ, проведённый как с точки зрения возможностей обучения моделей, так и с точки зрения их практического использования, позволил нам выбрать наиболее подходящие конфигурации оборудования, оптимально подходящие именно для наших рабочих нагрузок с учётом таких факторов, как техническая возможность решения наших задач, цена, пропускная способность и задержки. В 2023 году мы глубоко протестировали 17 различных конфигураций GPU и CPU, задействовав самые разные библиотеки и оптимизаторы, в том числе — Nvidia TensorRT (TRT) и TRT-LLM. Например, как показано на двух следующих рисунках, мы выяснили, что, хотя GPU Nvidia A10 и не отличаются уровнем пропускной способности, позволяющей экономно решать с их помощью задачи обучения моделей, они оказались оптимальным решением для обслуживания уже обученных моделей. Они, при использовании TRT, показывают на подобных задачах наилучшую пропускную способность, обеспечивая приемлемый уровень предоставления услуг (SLA, Service-Level Agreement).

В Uber множество приложений, использующих генеративные модели, требуют применения новейших GPU Nvidia H100, которые позволяют удовлетворить жёсткие требования таких моделей. Эти требования обусловлены возможностями H100. Эти GPU, в сравнении с GPU предыдущего поколения A100, показывают 4-кратный рост производительности и удвоенную пропускную способность памяти. Экспериментируя с моделями серии Meta Llama2, применяя различные конфигурации, различающиеся размерами пакетов, подходами к квантованию, параметрами моделей, мы оценили различные фреймворки, как опенсорсные, так и с закрытым кодом, позволяющие оптимизировать производительность использования больших языковых моделей. На двух следующих рисунках показаны результаты одного из экспериментов, в ходе которого мы исследовали две ключевые метрики: задержку в расчёте на один токен (ms/token) и количество токенов в секунду на один GPU (tokens/sec/gpu). С помощью этих метрик мы надеялись оценить и сравнить производительность моделей при использовании двух самых быстрых фреймворков (TensorRT-LLM и Framework B — фреймворк, название которого мы сейчас не раскрываем). При этом все остальные параметры моделей не меняются и используется квантование FP16.

Эти результаты экспериментов ясно указали на то, что применение Framework B, в сравнении с TensorRT-LLM даёт двукратное улучшение задержек и шестикратное увеличение пропускной способности. Такие результаты, в очередной раз, подчёркивают важность интегрированного подхода к проектированию аппаратных и программных решений, который позволяет наиболее полноценно использовать возможности аппаратного обеспечения. Оптимальные решения необходимо использовать на всех уровнях стека применяемых технологий.

Повышение эффективности обучения LLM за счёт ослабления нагрузки на память GPU

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

Результаты экспериментов показали значительное расширение наших возможностей по обучению масштабных моделей. Ранее нас, при работе с такими моделями, ограничивал размер памяти, доступной GPU. Выгрузка данных из памяти GPU в оперативную память или даже на NVMe-устройства помогла нам повысить эффективность обучения, дав возможность использовать пакеты более крупных размеров при том же количестве GPU. Это изменение привело к 2-кратному увеличению показателя MFU, одновременно снизив нагрузку на GPU на 34%. Правда, стоит отметить, что этому улучшению сопутствует снижение пропускной способности сети. Мы подробно рассказывали об этом на конференции Open Compute Project (OCP).

Итоги

В заключение мы хотели бы поделиться с вами тремя главными выводами. Во-первых — проектирование единой AI/ML-системы в условиях бурного развития приложений и моделей (от XGboost-моделей, до рекомендательных моделей глубокого обучения и больших языковых моделей) — это нетривиальная задача. Например, LLM требуют большой вычислительной мощности, а модели глубокого обучения нуждаются в огромных объёмах памяти. Во-вторых — для повышения экономической эффективности используемых систем обязательным становится анализ решений, оптимизированных под конкретную рабочую нагрузку. Подобный анализ основывается на изучении показателей, или метрик эффективности систем, таких — как стоимость их обслуживания и соотношение цена/производительность при поддержании необходимого уровня предоставления услуг. В-третьих — для максимизации эффективности инфраструктуры необходимо, на всех её уровнях, применять подход, предусматривающий совместное проектирование аппаратного и программного обеспечения. Мы, с учётом вышесказанного, привели в этом материале различные примеры, отвечающие на вопрос о том, как эффективно использовать существующую инфраструктуру, занимаясь при этом созданием новых механизмов, позволяющих эффективно масштабировать имеющиеся ресурсы. И наконец — мы выступаем за укрепление партнёрства между компаниями, работающими в AI/ML-индустрии. Мы призываем всех желающих к участию в оптимизации опенсорсного ПО, к обмену идеями и полезными находками, связанными с эффективным масштабированием вычислительной инфраструктуры. Всё это поможет всем нам успешно справляться со всё более сложными и масштабными задачами, которые возникают в сфере искусственного интеллекта и машинного обучения.