Rambler's Top100
Статьи
Николай НОСОВ  09 октября 2024

Специфика сетей для искусственного интеллекта

Учет особенностей задач искусственного интеллекта при построении сети вычислительного комплекса позволит повысить скорость обучения моделей. Но адекватные архитектурные решения пока не разработаны.

Требования к сети

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

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

Графические процессоры, обработав свои данные, делятся результатом со всеми другими графическими процессорами. Тут в повышении производительности системы начинает играть важную роль сеть. «Передача больших объемов данных от множества хостов ко всем остальным хостам предъявляет серьезные требования к сети вычислительной системы», – отметил на конференции IT Elements руководитель группы сетевых пресейлов компании «Инфосистемы Джет» Алексей Цемарков. Прежде всего сеть должна быстро, надежно и бережно передавать большие синхронизированные потоки данных, не допуская потерь. Кроме того, время передачи пакета должно быть постоянным, поскольку задержка даже одного пакета может существенно влиять на время выполнения задачи. Если на всех GPU цикл вычислений завершился и все начали обмениваться информацией со всеми, а из-за перегрузки канала или коллизий данные одного GPU задержались, то вычислительный кластер будет ждать, пока все процессоры не предоставят свои результаты. Еще одно требование к сети – равномерное распределение потоков и мониторинг узких мест. Чем больше сеть, тем труднее все эти требования выполнить, не говоря уже о том, что они плохо согласуются со ставшей практически стандартом технологией Ethernet.

Сетевая карта вместо CPU

В классической сети сетевые пакеты записываются в буфер ядра, затем СPU копирует их в буферы приложений. На этом теряется время. Учитывая, что в системах ИИ по сути выполняется одно приложение, процесс можно ускорить – передавать данные из памяти удаленного узла в локальную память инициатора запроса непосредственно сетевым контроллером без участия CPU. Такой подход обеспечивает технология удаленного прямого доступа к памяти (Remote Direct Memory Access, RDMA). При этом используются пары очередей, которые отображаются в областях памяти пользовательского пространства, а сетевая карта напрямую, минуя CPU и ОС, через сеть считывает/записывает данные в эти области. 

RDMA поддерживает технология InfiniBand, широко используемая в высокопроизводительных вычислениях и суперкомпьютерах, в том числе в пяти из первой на июнь 2024 г. десятки суперкомпьютеров рейтинга Top500 и в замыкающем тройку лидеров американском Eagle. Сеть InfiniBand используется и в большинстве российских суперкомпьютеров, например, в Christofari Сбера, базирующемся на GPU Nvidia DGX-2.

Сетевое оборудование, поддерживающее InfiniBand, дорого и сильно зависит от вендора – компании Nvidia, которая купила ключевого разработчика технологии, компанию Mellanox. В условиях санкций для России перспективнее выглядит использование сетей Ethernet, тем более что производительность их значительно выросла и уже не кажутся экзотикой сетевые карты, обеспечивающие скорость до 400 Гбит/с. 

Для работы RDMA поверх традиционных сетей Ethernet разработан протокол RoCE (RDMA over Converged Ethernet).
 
Источник: «Инфосистемы Джет»
Рис. 1. Структура кадра Ethernet в протоколах RoCE версии 1 и 2

Первая версия (RoCE v1) работала на канальном (L2) уровне, осуществляя связь между любыми двумя хостами в одном и том же широковещательном домене Ethernet. Вторая версия протокола (RoCE v2) обеспечивает маршрутизацию пакетов и их передачу без потерь. Она улучшена включением в заголовок поля UDP/IP (рис. 1), поддерживает возможность работы в L3 сетях и сигнал явного уведомления о перегрузке (Explicit Congestion Notification, ECN). 

Распределение нагрузки на каналы

Цикл обработки данных может удлиниться из-за неправильного распределения нагрузки, когда пакеты стоят в очереди на обработку к одному хосту, в то время как остальные свободны. Для балансировки нагрузки на каналы в сетевых фабриках применяется технология ECMP (Equal Cost Multi-Path), позволяющая одновременно задействовать для передачи данных несколько равнозначных маршрутов, что повышает эффективность и надежность передачи сетевого трафика. В этом случае набор из пяти полей в заголовке пакета – IP-адрес источника (ip-src), IP-адрес назначения (ip-dst), номер порта источника (port-src), номер порта назначения (port-dst), протокол (например, TCP или UDP) – служит уникальным идентификатором соединения в сети. Обычно в ЦОДе работает много приложений, и порты используются разные, что дает возможность балансировать трафик по соединениям. Однако в сетях для ИИ порт назначения в основном один и тот же, поскольку, как уже говорилось, в вычислительной системе работает по сути одно приложение. Стандартных методов балансировки по портам недостаточно, и это приводит к перегрузке отдельных каналов.

Вендоры по-разному подходят к проблеме. Одни применяют отдельные контроллеры для анализа загруженности, другие пытаются заложить алгоритмы балансировки на уровне чипов. Единого стандартизированного подхода нет, что усложняет жизнь разработчикам вычислительных комплексов для ИИ.

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

И здесь предлагаются разные методы, ни один из которых не решает проблему полностью. Самый простой – использование больших буферов памяти на коммутаторах или сетевых картах. Но при современных скоростях этого недостаточно, поскольку буферы быстро переполняются поступающими пакетами. Другой метод состоит в том, чтобы при переполнении канала на хост источника или вышестоящий коммутатор посылать сигнал «пауза» или снижать скорость передачи пакетов. Делать это можно, например, при помощи механизма ECN (рис. 2), позволяющего сетевым устройствам уведомлять отправителей о перегрузках в сети. 
Источник: «Инфосистемы Джет»
Рис. 2. Реализация механизма ECN

Сетевая карта источника, получив сигнал о переполнении канала, дает указание своему серверу о снижении скорости обработки. Ограничение метода – в том, что все устройства сети должны поддерживать ECN.

Нужен общий подход

В настоящее время ни для одной из описанных выше проблем нет всеобъемлющего и общепринятого решения. «Разброд и шатания. Каждый пытается решить проблемы по-своему, но на уровне индустрии они не закрыты. Нет готового дизайн-гайда – делай так, и будешь прав», – описал текущее состояние рынка А. Цемарков. Чтобы навести порядок, год назад был создан консорциум UEC (Ultra Ethernet Consortium), в который вошли ведущие ИТ-компании, в том числе AMD, Arista, Broadcom, Cisco, Intel, Juniper, Huawei и Microsoft. И даже Nvidia, хотя и считает InfiniBand лучшим интерконнектом для ИИ-кластеров и является фактически единственным поставщиком данной технологии, в мае 2024 г. тоже присоединилась к консорциуму.

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

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

UEC Stack должен быть обратно совместим с существующим стеком, на транспортном уровне (L4) поддерживать синтаксис общения устройств для получения сквозной информации о происходящем в сети и выравнивания нагрузки.

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

Вопросов много, но можно надеяться, что подходы к построению сетей для ИИ удастся упорядочить, новые подходы внедрить и выработать если не стандарты, то хотя бы общие рекомендации.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!