Как Ethernet превосходит InfiniBand в сетях искусственного интеллекта

Ethernet бросает вызов доминированию InfiniBand

InfiniBand доминировал в высокопроизводительных сетях на заре генеративного ИИ благодаря своей превосходной скорости и низкой задержке. Однако Ethernet добился значительных успехов, используя экономическую эффективность, масштабируемость и непрерывные технологические достижения, чтобы сократить разрыв с сетями InfiniBand. Такие гиганты отрасли, как Amazon, Google, Oracle и Meta, внедрили высокопроизводительные решения Ethernet, сократив разрыв в производительности и, в некоторых случаях, превзойдя InfiniBand по определенным показателям. Даже NVIDIA, давний лидер InfiniBand, переключила внимание на решения на базе Ethernet, такие как Spectrum-X, которая теперь превосходит свои продукты Quantum InfiniBand в серии Blackwell GPU. Выпуск Консорциум Ultra EthernetСпецификация Release Candidate 1 (UEC) знаменует собой поворотный момент в этой эволюции, позиционируя Ethernet как грозного конкурента в сетях искусственного интеллекта и высокопроизводительных вычислениях (HPC).

Спецификация UEC 1.0: переосмысление Ethernet для конкуренции с искусственным интеллектом и InfiniBand

Спецификация Release Candidate 562 компании UEC объемом 1 страницы представляет усовершенствованную архитектуру Ethernet, разработанную специально для крупномасштабных сетей искусственного интеллекта и кластеров высокопроизводительных вычислений.

В отличие от стандартного Ethernet, который не может сравниться с производительностью InfiniBand без глубокой настройки, UEC оптимизирует транспортный уровень и уровень управления потоком для обеспечения производительности уровня InfiniBand с большей гибкостью и экономической эффективностью. Проект UEC направлен на обеспечение функциональности транспортного уровня и уровня управления потоком для сетевых интерфейсных карт (NIC) и коммутаторов Ethernet, оптимизируя эксплуатационную эффективность крупномасштабных высокоскоростных сетей центров обработки данных. Транспортный уровень гарантирует, что пользовательские данные достигают пункта назначения от источника, поддерживая при этом современные требования к командам AI и HPC. Между тем, уровень управления потоком гарантирует передачу данных на оптимальных скоростях, предотвращает перегрузку и обеспечивает динамическую перемаршрутизацию при сбоях в работе канала.

Основные компоненты UEC для конкуренции с InfiniBand

UEC, возглавляемый Linux Joint Development Foundation (JDF), стремится достичь задержки в оба конца в 1-20 микросекунд, что делает его идеальным для обучения ИИ, вывода ИИ и сетей HPC. Его спецификации предписывают, что физический уровень сети должен соответствовать стандартам Ethernet, а коммутаторы должны поддерживать современные возможности Ethernet. 

Ключевым техническим краеугольным камнем являются интерфейсы Open Fabric (LibFabric). Будучи широко распространенным API, LibFabric стандартизирует использование сетевых карт, подключая высокопроизводительные сетевые библиотеки, такие как NCCL от NVIDIA, RCCL от AMD и MPI, через существующие привязки или плагины, тем самым удовлетворяя потребности в коммуникации суперкомпьютерных кластеров ИИ. UEC предписывает поддержку LibFabric для сетевых карт, включая команды для отправки/получения, RDMA и атомарных операций, ускоряя производительность, подобную InfiniBand.

Проект UEC не является совершенно новым изобретением; он основывается на устоявшихся открытых стандартах для определения совместимой структуры для своих операций, с особым акцентом на неограниченное взаимодействие API с CPU/GPU. UEC требует, чтобы все сетевые карты поддерживали набор команд LibFabric, включая отправку, получение, RDMA и атомарные операции, что позволяет транслировать программный стек команд LibFabric в аппаратно-ускоренные наборы инструкций на сетевой карте.

Концепция «Job», представленная LibFabric, дополнительно уточнена в UEC. Каждое Job представляет собой набор совместных процессов на нескольких конечных точках, изолированных с помощью конечных точек Fabric (FEP) в NIC. Одна NIC может содержать несколько FEP, но каждый FEP принадлежит исключительно одному Job и может взаимодействовать только с FEP, имеющими тот же идентификатор Job. Создание и завершение Job управляются доверенной службой Fabric, которая также поддерживает зашифрованные домены для безопасной изоляции трафика. UEC дополнительно предоставляет гибкие механизмы членства для сценариев обслуживания, требующих динамического участия.

Концепции Job и FEP формируют основу сетевых операций UEC и являются обязательными компонентами реализации команд LibFabric.

Транспортный уровень UEC доставляет команды и данные LibFabric в FEP, в идеале используя Ethernet и поддерживая дополнительные уровни расширения.

• Интерфейсы Open Fabric (LibFabric): стандартизированный API, который интегрируется с высокопроизводительными библиотеками, такими как NCCL от NVIDIA, RCCL от AMD и MPI, обеспечивая бесперебойную связь в суперкомпьютерных кластерах ИИ. UEC предписывает поддержку LibFabric для сетевых карт, включая команды для отправки/получения, RDMA и атомарных операций, ускоряя производительность, подобную InfiniBand.
• Модель Job и Fabric End Point (FEP): UEC представляет концепцию Job, где совместные процессы на конечных точках изолируются через FEP в NIC. Это обеспечивает безопасную, масштабируемую связь, конкурируя с фирменными протоколами InfiniBand.
• Архитектура Multi-Rail: конструкция «толстой сети» UEC использует несколько последовательных путей (например, 8 каналов по 100 Гбит/с для интерфейса 800GbE) для максимизации пропускной способности и избыточности, предлагая масштабируемость, которая бросает вызов Сети InfiniBand.

Проектирование уровня пакетов

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

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

Архитектура Multi-Rail

UEC разработан для «толстых сетей», включающих несколько физически равноудаленных, равноскоростных путей — обычно реализуемых как конфигурации «многоканальных». Например, интерфейс NIC 800GbE может включать восемь полос 100 Гбит/с, каждая из которых подключена к отдельному коммутатору. Поскольку каждый коммутатор поддерживает 512 портов 100 Гбит/с, система может вмещать до 512 FEP.

Сетевые карты UEC используют механизм «энтропии» для назначения пакетов по полосам с помощью хеширования для балансировки нагрузки. Отправитель выбирает значения энтропии для равномерного распределения пакетов, максимизируя совокупную пропускную способность. Приложения CPU/GPU не обращают внимания на эту сложность, просто ставя отправку в очередь через LibFabric, в то время как сетевой адаптер автоматически обрабатывает распределение.

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

Помимо повышения масштабируемости кластера и упрощения развертывания сети, многочисленные пути позволяют сетевым картам UEC обеспечивать:

• Сверхбыстрое восстановление после потери пакетов
• Управление потоком в микросекундном масштабе
• Стабильная пропускная способность, несмотря на неоптимальное планирование приложений или случайные колебания соединения

UEC-CC: расширенный контроль перегрузки для конкурента InfiniBand

Управление перегрузкой UEC (UEC-CC) — это революционный подход к производительности сетей ИИ. С точностью менее 500 наносекунд UEC-CC независимо измеряет задержки прямого и обратного пути, требуя абсолютной синхронизации времени между сетевыми картами. В отличие от InfiniBand, который опирается на собственные механизмы, UEC-CC использует явное уведомление о перегрузке (ECN) и поддерживает обрезку пакетов для минимизации потерь пакетов. Устраняя устаревшие протоколы, такие как RoCE, DCQCN и Priority Flow Control (PFC), UEC-CC обеспечивает более плавные потоки данных, что делает Ethernet сильным претендентом на сети с низкой задержкой.

Благодаря двунаправленному измерению UEC-CC может точно определить, возникает ли перегрузка у отправителя или получателя. Когда UEC-CC включен, коммутаторы должны поддерживать явное уведомление о перегрузке (ECN), и рекомендуются современные варианты ECN: в частности, установка флагов перегрузки для каждого класса трафика и выполнение измерений непосредственно перед передачей пакета. Такой подход обеспечивает самую актуальную информацию о перегрузке и позволяет дифференцированно обрабатывать каждый класс трафика.

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

Учитывая, что время приема-передачи (RTT) в центре обработки данных составляет всего несколько микросекунд, отправитель может передавать данные только в течение чрезвычайно короткого периода времени, не дожидаясь подтверждений. Поэтому принимающий FEP (Front-End Processor, вероятно, относится к логике NIC/приемника) отвечает за управление скоростью передачи.

Получатель собирает богатую многополосную, многоклассовую информацию о состоянии потока с помощью флагов ECN. На основе этого он определяет, сколько новых пакетных кредитов предоставить, и уведомляет отправителя с помощью ACK и специальных команд Credit CP (Control Packet). Это позволяет приостанавливать отправителя на уровне микросекунд, эффективно предотвращая потерю пакетов.

Кроме того, UEC-CC поддерживает динамическую настройку «емкости энтропии» для перебалансировки путей маршрутизации, тем самым оптимизируя стратегии распыления сообщений. Он стандартизирует механизм отчетности для частичных показателей исправления ошибок и показателей потери пакетов, позволяя системе обнаруживать слабые связи и маршрутизировать их в обход. Используя хэш-маршрутизацию на основе энтропии на каждом переходе, даже при уровнях энтропии на порядок больше, чем количество полос, слабые связи могут быть изолированы, что минимизирует их влияние на общую емкость пути.

UEC-CC прекращает поддержку нескольких устаревших механизмов управления потоком:

• RoCE и DCQCN: не рекомендуются к использованию, поскольку их неспособность динамически обновлять стратегии управления потоком на основе фактического местоположения проблем с потоком ухудшает производительность UEC-CC.
• PFC (управление потоком на основе приоритетов): не требуется между коммутаторами и может даже блокировать легитимный трафик, поэтому его следует отключить. Он также больше не рекомендуется для соединений NIC-коммутатор из-за его недостаточной точности по сравнению с UEC-CC.
• Управление потоком на основе кредитов: также устарело, поскольку конфликтует с механизмом UEC-CC.

Безопасность на транспорте для безопасной работы сетей ИИ

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

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

UEC рекомендует использовать постквантовый криптографический алгоритм DES (Data Encryption Standard) в качестве метода шифрования и подчеркивает защитные операции, включая правила ротации значений nonce. Домен шифрования может быть подмножеством FEP в Job, а также поддерживает адаптивную конфигурацию домена для динамических сценариев обслуживания, когда клиенты часто присоединяются или покидают систему.

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

Для обеспечения безопасности центр обработки данных должен включать в себя надежные компоненты:

• Сущность Security Domain Manager, отвечающая за создание и поддержку домена шифрования.
• Сетевые карты оснащены доверенными аппаратными модулями для управления доступом к портам в пределах домена.

Хотя проверка версий этих компонентов выходит за рамки спецификации UEC, существуют открытые стандарты для эталонных реализаций поставщиков.

Другие слои

Уровень 4: Сетевой уровень (сетевой уровень UE): в первую очередь обсуждается механизм обрезки пакетов — дополнительная мера управления перегрузкой, используемая для уменьшения объема полезной нагрузки данных при перегрузке сети.

Уровень 5: Канальный уровень (UE Link Layer): Нацелен на повышение общей производительности за счет замены пакетов на уровне канала и механизмов управления потоком между коммутаторами. Однако, учитывая, что UEC-CC уже обеспечивает высокоэффективное управление потоком, эта конструкция кажется в значительной степени избыточной в средах с задержками приема-передачи на уровне микросекунд. Особенно учитывая, что CBFC (Credit-Based Flow Control) устарел в разделе UEC-CC, эта функциональность, похоже, не дает существенных преимуществ. Она необязательна, не ожидается ее широкого распространения в будущем, но может усложнить тестирование совместимости.

Уровень 6: Физический уровень (физический уровень UE): рекомендует использовать несколько линий Ethernet 100 Гбит/с, придерживаясь стандартов IEEE 802.3/db/ck/df. В документе кратко отмечается, что ссылка на стандарты 200 Гбит/с в настоящее время невозможна, поскольку они еще официально не опубликованы. Напротив, спецификация UALink явно поддерживает 200 Гбит/с, что указывает на тенденцию отрасли двигаться в этом направлении. UEC также следует рассмотреть возможность начать с этой точки в будущем, а не пассивно следовать ей позже.

UEC против UALink и SUE: конкурентная среда для альтернатив InfiniBand

В то время как UEC нацелена на масштабируемые сети Scale-Out для тысяч конечных точек, такие конкуренты, как UALink и Scale Up Ethernet (SUE) от Broadcom, фокусируются на сетях Scale-Up, аналогичных NVLink от NVIDIA.

UALink поддерживает до 1024 конечных точек с 200GbE-линками, в то время как SUE делает акцент на однорельсовых сетях. Оба включают интерфейсы с отображением памяти для эффективной передачи данных, но комплексный подход UEC, включая многоуровневую коммутацию и расширенный контроль перегрузки, позиционирует его как более сильного конкурента InfiniBand для крупномасштабных кластеров ИИ и HPC.

И SUE, и UALink прямо упоминают в своих спецификациях каналы 200GbE, из-за чего UEC немного отстает по скорости.

Подобно UEC, UALink распыляет трафик по рельсам, но он предоставляет подробное определение для своего механизма управления потоком на основе кредитов. Напротив, SUE делегирует этот аспект реализации Ethernet и предлагает полагаться на координацию клиентского программного обеспечения. Это приводит к более четкому проектированию спецификации для SUE, хотя практическая разница минимальна. UALink также объединяет несколько полос вместе (например, 4×200Г) для повышения эффективности передачи, тогда как SUE и UEC считают одну полосу 200G достаточно быстрой. Поэтому UALink вводит здесь дополнительную сложность для ограниченного выигрыша.

SUE рекомендует использовать PFC или, что предпочтительнее, Credit-Based Flow Control (CBFC) для управления потоком. В одноуровневых коммутационных средах этот подход является жизнеспособным, поскольку PFC хорошо работает в таких сценариях, а CBFC обеспечивает более плавную работу.

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

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

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

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

Для всех этих систем, включая UEC, требования высокой скорости и низкой задержки в центрах обработки данных заставляют конечные точки приближаться к чипу хоста, а не оставаться «устаревшими» устройствами шины ввода-вывода, расположенными удаленно от хоста. Сегодняшняя тенденция больше похожа на то, чтобы рассматривать конечные точки (например, сетевые карты) как еще одно ядро ​​в многоядерной системе. Это упрощает процесс отправки команд с вычислительных ядер (например, потоковых графических процессоров или традиционных процессоров) и позволяет конечным точкам более эффективно получать доступ к памяти хоста.

Ожидается, что SUE и UALink будут все больше интегрироваться как IP-блоки в хост-чипы, а не существовать как отдельные чипы. NVLink был разработан таким образом с самого начала, и чипы, такие как Intel Gaudi 3 или Microsoft Maia 100, используют аналогичные подходы по Ethernet-соединениям. Хотя это упрощает конструкцию IP-блоков, это также требует, чтобы они оставались достаточно компактными, чтобы минимизировать занимаемое ими пространство на хост-чипе.

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

Основные преимущества UEC перед InfiniBand

Аппаратно-ускоренная библиотека LibFabric: улучшает совместимость с существующими высокопроизводительными библиотеками.

• Масштабируемая модель работы: сочетает в себе современное шифрование и гибкое управление конечными точками.
• Расширенный контроль перегрузки: UEC-CC превосходит традиционные протоколы, такие как RoCE и DCQCN.
• Открытые стандарты: поддерживает плагины CCL, MPI, SHMEM и UD для широкой совместимости экосистемы.
• Стоимость и масштабируемость: доступность и гибкость Ethernet делают его жизнеспособной альтернативой InfiniBand.

Проблемы и соображения по внедрению UEC

Хотя UEC предлагает значительные преимущества, проблемы остаются. Функциональная совместимость между поставщиками требует тщательного тестирования для обеспечения стабильной производительности, особенно когда задействованы несовместимые с UEC устройства. EFA от Amazon, хотя и основан на LibFabric, подчеркивает потенциальные проблемы совместимости плагинов с экосистемой NVIDIA. Обеспечение поддержки ECN в промежуточных устройствах имеет решающее значение для поддержания производительности на уровне InfiniBand.

Будущее сетей искусственного интеллекта: может ли UEC пересмотреть правила?

По мере роста моделей ИИ производительность сети становится критическим узким местом. Подход UEC на основе открытых стандартов бросает вызов доминированию InfiniBand, объединяя LibFabric, многоканальную архитектуру и расширенный контроль перегрузки. Его масштабируемость, безопасность и экономичность делают его убедительным выбором для будущих сетей центров обработки данных ИИ. Хотя InfiniBand остается сильным игроком, инновации UEC могут изменить ландшафт, подтолкнув отрасль к открытым стандартизированным сетевым решениям ИИ.

Спецификация UEC 1.0 знаменует собой поворотный момент в битве между Ethernet и InfiniBand. Устраняя разрывы в производительности с помощью аппаратного ускорения, расширенного управления потоками и надежной безопасности, UEC позиционирует Ethernet как масштабируемую, экономически эффективную альтернативу для сетей ИИ и HPC. По мере развития центров обработки данных открытые стандарты и гибкость UEC могут переопределить правила, бросив вызов монополии InfiniBand и проложив путь для инфраструктуры ИИ следующего поколения.