Недавно три наших новых GPU-кластера заняли 19, 36 и 40 места в рейтинге суперкомпьютеров Top500. Это лучшие результаты среди всех участвующих в нём суперкомпьютеров России. Но сегодня мы поговорим не о местах в рейтинге, а о том, чем полезно на практике участие в подобных замерах.
Из этого поста вы узнаете про наши первые попытки создать свои кластеры и грабли на этом пути. Расскажем, как устроены суперкомпьютеры для машинного обучения и почему мы в итоге пришли к собственной архитектуре. Важная часть истории будет посвящена разбору проблем замеров производительности, которые, вопреки первым впечатлениям, принесли нам не только места в рейтинге, но и реальную пользу для наших ML-проектов.
Поможет мне в этом Дмитрий Монахов dmtrmonakhov. Он уже известен читателям Хабра по докладу о разработке ядра Linux. Передаю ему слово.
Привет! На связи Дмитрий. Последний год был очень необычным в Яндексе. Мы собрали и запустили три новых GPU-кластера для задач в области машинного обучения. (К примеру, теперь именно на них обучаются гигантские нейросетевые модели Поиска, Алисы и других наших сервисов.) Может показаться, что для запуска такого кластера самое сложное — это купить вагон GPU-карточек. В условиях «чипагеддона» это отчасти правда, но нет, самое сложное не в этом. Тут-то и начинается наша история.
Пробный подход к снаряду
В 2019 году произошла так называемая «революция трансформеров»: был опубликован ряд статей, которые показали, что применение гигантских нейросетей-трансформеров даёт удивительные результаты на задачах анализа текста. В частности, эти сети очень хорошо подходят для решения задачи ранжирования документов по запросу и для машинного перевода. Более того, их применение не ограничивается сугубо языковыми задачами: трансформерная архитектура позволяет генерировать голос из текста и наоборот, предсказывать действия пользователя и многое другое. В общем, именно трансформеры сейчас определяют качество основных продуктов Яндекса. (Если вам интересны детали, коллеги уже рассказывали на Хабре о внедрении этой архитектуры в нашем поиске.)
Но проблема была в том, что обучение таких моделей требует огромных вычислительных мощностей. Например, если обучать модель с нуля на обычном сервере, на это потребуется 40 лет, а если на одном GPU-ускорителе V100 — 10 лет. Но хорошая новость в том, что задача обучения легко параллелится, и если задействовать хотя бы 256 тех же самых V100, соединить их быстрым интерконнектом, то задачу можно решить всего за две недели. (Сейчас мы такую задачу можем решить за несколько часов, но об этом позже.)
Мы попробовали собрать «нулевой» кластер буквально из того, что было под рукой. Взяли несколько серверов, вставили в них по восемь GPU V100 от NVIDIA, а в качестве интерконнекта использовали две карты Mellanox ConnectX-5 EN в режиме RoCEv2. Попробовали. Расстроились.
Результаты замеров показали низкий КПД масштабирования. В попытках понять причину придумали методику оценки, которая не требовала глубокого понимания алгоритма работы конкретного обучения. Достаточно построить график потребления энергии и обмена трафиком в одном масштабе. Здесь приведён реальный график тех времен, полученный на «нулевом» клаcтере:
Даже без глубоких познаний в ML-моделях всё понятно. Обучение идет повторяющимися итерациями:
- Каждый GPU получает свой batch и обсчитывает его (синяя ступенька)
- Затем GPU обменивается по сети с соседями посчитанными результатами (зелёная ступенька)
- GOTO 1
На графике сразу же виден корень проблемы. Время обмена по сети составило 50%, а GPU всё это время простаивал. Не самый эффективный способ использовать железо, согласитесь. Причина была в том, что серверы, которые у нас были под рукой, использовали PCIe Gen3 x8, и больше 62 Гбит/с по сети мы получить не могли. Эксперименты на таком кластере проводить можно, но считать что-то серьёзное — нереально. Поэтому стали собирать новое решение, «расшивая» все узкие места интерконнекта. Попутно столкнулись и с другими сложностями. Например, оказалось, что большинство стандартных утилит для работы с HPC (High Performance Computing) поддерживают только IPv4. Яндекс, в свою очередь, уже много лет живёт в дата-центрах IPv6-only. «Из коробки» мало что заработало сразу, пришлось фиксить. Фиксы, кстати, выкладываем в опенсорс.
- Поддержка RDMA в fio была почти сломана. Фикс здесь.
- perftest не умеет в IPv6. Фикс здесь.
- openmpi неправильно работает, когда на интерфейсе больше одного IPv6-адреса. Забавно, что параллельно были написаны два фикса: первый и второй.
- nccl-test с перебором всех возможных маршрутов.
Времени прошло мало, поэтому многие патчи ещё не удалось донести до mainstream, но мы постараемся это сделать в ближайшее время.
Первые кластеры
Первый мини-кластер GPU, созданный специально под задачи применения трансформеров c учётом описанных выше узких мест, появился у нас во владимирском дата-центре летом 2020 года. Он был построен из стандартных серверов c NVIDIA Tesla V100-SXM2-32GB. В кластере было 62 узла по 8 GPU в каждом — всего 496 видеокарт. Казалось бы, сотни видеокарт! Но этого по-прежнему было мало для наших задач, хотя кластер и помог нам начать внедрять трансформеры для улучшения Поиска.
Затем в другом нашем ДЦ, в городе Сасово в Рязанской области, появился первый большой кластер. Мы назвали его в честь Алексея Ляпунова — знаменитого математика, чьи работы лежат в основе кибернетики и теории машинного обучения.
«Ляпунова» мы уже строили из серверов на базе NVIDIA HGX A100, в каждом из которых было:
- 2x AMD EPYC 7662, 512GB RAM
- 8x A100-40G
- 4x Mellanox ConnectX-6 IB 200Gib
В теории скорость обмена по сети между хостами должна была составить 96 ГБ/с, но первые замеры показали жалкие 40 ГБ/с. Мы вновь где-то потеряли 50%. В ходе многочасового хакатона с инженерами NVIDIA выяснилось, что проблема в скорости обмена по PCIe-шине между GPU и сетевой картой. Пришлось искать причины и оптимизировать.
- Оптимизация числа NUMA-нод. Переключение в NPS2 позволило нам выиграть 15% производительности памяти.
- Отключение IOMMU/ACS. Включённый IOMMU стоил до 30% производительности, потому что трафик шёл не P2P, а через CPU.
- Оптимальные настройки сетевой карты при обмене PCIe позволили выжать заветные 200 Гбит/с из одного сетевого интерфейса и дали недостающие 20%.
Так мы получили 90 ГБ/с на тесте nccl-test/all_reduce_per и решили, что «Ляпунов» готов. Коллеги из локального офиса NVIDIA посоветовали потратить ещё несколько дней на замеры производительности, чтобы зарегистрировать кластер в списке Top500. Но в тот момент мы от этого отказались: торопились отдать кластер нашим ML-инженерам, чтобы загрузить его работой уже на новогодние праздники. Тем более, что тогда мы ещё не осознавали никакой практической пользы от замеров.
Первый кластер собственной архитектуры
У нас сильная команда R&D и мы уже давно проектируем собственные серверы, благодаря чему экономия на охлаждении может достигать 50%. Логично было распространить этот опыт и на GPU.
Для размещения кластеров выбрали недавно переданные в эксплуатацию модули в дата-центрах Сасово и Владимира. Сами кластеры назвали соответственно «Червоненкис» (в честь Алексея Червоненкиса, одного из крупнейших теоретиков машинного обучения) и «Галушкин» (Александр Галушкин — один из главных исследователей теории нейронных сетей).
Кластеры строили по модульной схеме, где к каждому серверу подключается JBOG-и (Just a bunch of GPUs). Разберём, как устроены стойки в кластере:
- Четырёхюнитный JBOG c x8 NVIDIA А100-80G, x6 NVSwitch, 4x Mellanox ConnectX-6 IB HDR 200G. Размер обусловлен встроенной системой охлаждения.
- Сервер половинной ширины 2x AMD 7702, 1024GB RAM на два юнита. В нём находится пятая сетевая карта Mellanox ConnectX-6 100G Ethernet.
- Сетевые карты IB HDR JBOG-ов скоммутированы оптическими кабелями в Infiniband через патч-панель в середине стойки. Они связывают GPU для вычислений.
- Серверные сетевые карты 100GE обеспечивают связность кластера и доступ к хранилищам данных.
- В каждой стойке по три комплекта оборудования. Это продиктовано энергопотреблением — до 20 кВт.
(Кстати, такие же NVIDIA А100-80G мы сейчас открываем для клиентов Yandex.Cloud, но об этом поговорим в другой раз.)
Обратите внимание на отсутствие любых декоративных пластиковых элементов. Зато есть много свободного места, чтобы воздух мог обдувать огромные радиаторы GPU в центре, именно за счёт этого получается экономить электричество на охлаждении.
В кластере 199 серверов с GPU — такое количество обусловлено экономической целесообразностью сборки ядра Infiniband по стандартной схеме на 800 портов с использованием 40-портовых 1U HDR-коммутаторов. Двухсотый сервер не имеет GPU в своем составе и используется для управления сетью Infiniband.
Легко заметить: в отличие от стандартной DGX-A100 от NVIDIA со схемой 8(1-GPU + 1-IB_NIC), мы построили своё решение по схеме 4(2-GPU + 1-IB_NIC). Это позволило создавать кластеры в два раза большего размера по сравнению с коробочным решением SuperPod. Дело в том, что NVIDIA SuperPod — это решение общего назначения, которое решает любые задачи одинаково хорошо. А мы оптимизировали наши кластеры под решение именно наших задач и показали, что сети 768 Гбит/с на хост вполне достаточно. Например, вот так выглядят типичные итерации обучения.
Видно, что на фазу обмена по сети тратится совсем мало времени, поэтому дальнейшее расширение интерконнекта не целесообразно.
Первый подход к замерам
Вскоре после запуска новых кластеров у нас появилось немного времени, чтобы позволить себе прогнать стандартный тест и зарегистрировать кластеры в рейтинге Top500. Казалось бы, что могло пойти не так?
Официальным тестом Top500 является HPL — High Performance Linpack. Это распределённый алгоритм решения системы линейных уравнений. Первые попытки прогона linpack'а показали, что всё очень плохо, и даже на одном хосте результат в десять раз ниже ожидаемого. Мы что-то явно делали не так. Решили посоветоваться с коллегами из NVIDIA. Выяснилось, что, по их мнению, linpack — один из лучших интеграционных тестов для GPU-кластера и если он не показывает нужный результат, значит, это проблема и, скорее всего, продуктовое обучение ML-моделей тоже будет страдать. Начали копать. И началось…
Дальше я опишу примеры проблем, с которыми мы столкнулись, на сугубо техническом языке, чтобы мои коллеги по индустрии могли извлечь из нашего опыта максимум пользы. Но если вам интересен только финал истории, то смело переходите к разделу с результатами замеров.
Также, по нашим замерам, hpcx-v2.9.0 работает чуть хуже hpcx-v2.8.1 (разница — около 1%).
Периодически находились отдельные GPU, которые перегревались и снижали собственную частоту. При этом проверочные нагрузочные тесты этого не ловили: их задача — убедиться, что GPU выдерживает максимальную нагрузку. А вот теста на перегрев не было, и Linpack оказался отличным способом искать такие проблемы. Наши инженеры проверяли систему охлаждения, и всё налаживалось.
К локальному перегреву случайных GPU приводил рваный темп их работы. Наши дата-центры охлаждаются атмосферным воздухом, а в это время на улице стояла страшная июльская жара. Как тогда выяснили, запуск linpack приводил к повышению температуры в ДЦ на 2 градуса. Пришлось запускать замеры по ночам, с 2 до 5 часов утра. Но проблема перегрева была лишь следствием рваного темпа работы GPU, который, в свою очередь, был вызван проблемами в интерконнекте Infiniband. Мы починили это, перенастроив PID controller охлаждения в JBOG.
- Как выяснилось, мы прокидывали не все нужные устройства внутрь контейнера, из-за чего тест не падал, но работал неоптимально. Всегда начинайте тестирование со сравнения bare metal vs container.
- Высокий рейт отказов нового железа приводил к тому, что при обнаружении проблемы на хосте автоматика пересоздавала контейнеры с нуля. Это очень сильно осложняло отладку. На сыром нестабильном железе использование средств автоматизации скорее вредит.
- Порядок созданных контейнеров всегда был случайным. Но, как выяснилось позже, порядок хостов имеет значение, поэтому любой детерминизм сильно упрощает поиск проблем. Если есть проблема, фиксируйте всё, что можно, даже если это кажется малозначительным.
В результате на этапе отладки пришлось отказаться от автоматизации создания контейнеров и создавать всё shell-скриптом с явной привязкой по хостам. Дальше действовали итеративно:
- запускаем linpack на каждом хосте, отсеиваем все хосты с плохими результатами, вызванными проблемами в железе;
- объединяем хосты в пары и прогоняем тест для всех пар, должны получить результат x2;
- повторяем шаг 2, сливая две группы хостов в одну, и проводим замер.
Когда у нас было 4 группы по 32 хоста, выяснился любопытный эффект: объединение двух групп, g1 и g2, давало ожидаемое линейное масштабирование, а при объединении g3 и g4 получался перфоманс на уровне g3 или g2 по отдельности. После этого стало понятно, что проблема не в отдельных хостах, а где-то в районе Infiniband-сети.
Мы сообщили о проблеме в Mellanox и попутно выяснили: в адаптивном роутинге существуют «прóклятые маршруты», по которым данные передаются в тысячу раз медленнее, чем должны. Это сразу объяснило причину нестабильности работы linpack'а. Но что делать, было совершенно непонятно. Коллеги из Mellanox ушли думать, а мы на свой страх и риск обновили FW на свичах и карточках на самую свежую версию от Mellanox, и проблема исчезла. Версии прошивок с фиксами: FW-HCA — 20.30.1004, FW_SWITCH — 27.2008.2500. Мораль: Infiniband, как и любая сложная система, требует внимания. Нужно явно тестировать все маршруты на фабрике, чтобы убедиться в её полной работоспособности.
Замеры
После успешного решения этих и других проблем мы наконец-то получили заветное линейное масштабирование на 152 хостах, доступных на тот момент. Получилось 15,2 петафлопса. Но была одна проблема: пока мы настраивали кластер, закрылось окно подачи в июньский рейтинг. Мы опоздали буквально на одну неделю. Поэтому решили взять паузу с замерами linpack до осени. За это время мы внедрили все найденные оптимизации на новых кластерах и отдали их пользователям — разработчикам и инженерам внутри компании. Кластер «Ляпунов» решили пока не выводить на обслуживание, потому что он в два раза меньше и у нас не было уверенности, что в нём проявится баг с адаптивным роутингом. Обслуживание означало задержку в расчётах критически важных ML-обучений. Поэтому тоже решили отложить до осени.
Первый замер
8 октября мы провели первый замер всех трёх кластеров. ML-инженеры согласились отдать кластеры всего на несколько часов: за это время нужно было сделать несколько прогонов, чтобы подобрать оптимальные параметры. Вот какие результаты у нас получились:
- Кластер «Червоненкис» (SAS-GPUIB2), 196 узла — 21,52 петафлопса,
- Кластер «Галушкин» (VLA-GPUIB3), 104 узла — 11,5 петафлопса
- Кластер «Ляпунов» (SAS-GPUIB1), 134 узла — 9,46 петафлопса
Результаты хорошие, но «Ляпунов» явно не дотягивал до ожидаемых значений. Стало очевидно, что проблема с адаптивным роутингом влияет на него больше, чем мы полагали. Дальнейшие разбирательства показали, что потери производительности на «Ляпунове» проявлялись уже на масштабе 8 хостов, а на масштабе всего кластера составляли около 30%. Мы решили выводить кластер на обслуживание как можно раньше.
Второй замер
19 октября «Ляпунов» был успешно обновлён. Теперь самое интересное. Сравните результаты:
- Было 9,46 петафлопса
- Стало 12,81 петафлопса
Итого рост +35% к масштабируемости всего кластера. Это очень круто. В реальности с обучением ML-моделей на масштабах 8-24 хостов мы ожидаем получить приращение 10-15%.
В процессе второго замера обратили внимание, что график сети продолжает быть нестабильным. Как выяснилось, проблема в эффекте резонанса мониторинговых сервисов. У нас есть несколько таких сервисов, которые периодически опрашивали состояние GPU через утилиту nvidia-smi, что на больших запусках приводило к деградации в 2-4%. Мораль: опрос перфоманс-метрик в драйвере NVIDIA не бесплатный, не нужно проводить его слишком часто.
Третий замер
Буквально на прошлой неделе мы закончили монтаж новых стоек — число узлов в кластере «Галушкин» должно увеличиться со 104 до 195. Очень хотелось успеть обновить результат до закрытия окна подачи в Top500, то есть до 7 ноября. Но к этому моменту мы успели подключить и проверить только 136 узлов. Зато у нас уже было гораздо больше опыта, и мы починили проблему с излишним влиянием мониторингов. Поэтому результат получился очень хороший: 16,02 петафлопса. В сумме по трём кластерам вышло 50,3 петафлопса. В ближайшее время нужно проверить оставшиеся узлы. Нам ещё есть над чем работать, но это уже другая история.
Чему мы научились
Мы строили свои кластеры для решения реальных задач машинного обучения, руководствуясь имеющимся опытом (в серверах, сетях, средах окружения и так далее). Linpack мы рассматривали как незначительную вспомогательную задачу. В результате мы поняли, что строить и валидировать такие системы — совершенно новый и полезный опыт для нас. Также оказалось, что linpack — отличный инструмент интеграционного тестирования. Он позволил найти и починить сразу несколько багов в продакшене, которые мы раньше просто не замечали.
Возникает вопрос: почему именно linpack оказался настолько хорошим инструментом? Чтобы ответить, нужно посмотреть на график обмена данными за 1 секунду.
Видно, что за секунду он успевает сделать 4,5 синхронных итерации — это в 2-4 раза чаще, чем наши реальные обучения. Именно поэтому linpack гораздо чувствительнее к различным задержкам на узлах. Например, альтернативный тест HPCG показал себя намного хуже: он не загоняет GPU в критические температурные режимы и использует лишь 10% сети.
Итоги
Построение и эксплуатация суперкомпьютеров — интересная, но сложная задача. Экспертизы очень сильно не хватает: абсолютное большинство компаний не собирают свои суперкомпьютеры. В то же время учиться на собственных ошибках — дорогое удовольствие: простой кластера стоит десятки тысяч долларов в сутки. Поэтому для нас обмен опытом — критически важная вещь. Она экономит время и деньги всем, кто двигает индустрию вперёд. Если у вас есть опыт или идеи в области HPC/GPU, не держите их в себе, делитесь. Буду рад вашим комментариям. Со своей стороны постараюсь вскоре вернуться с новой историей, на этот раз посвящённой проблемам, c которыми столкнулись наши ML-инженеры при использовании кластера.
Upd. Изначально составители рейтинга ошиблись в графе Manufacturer. Сейчас поправили. Стало: YANDEX,NVIDIA.
Upd2. Кстати, уже скоро выступлю с докладом, в котором расскажу, чему ещё мы научились при подготовке к Top500. Приходите послушать.
Комментарии (51)
Rutel_Nsk
16.11.2021 14:42Производители сетевого оборудования на предложения идей высокоскоростной передачи и коммутации (сеть с производительностью 100Тбит и задержкой коммутации 1нс на коммутатор) отвечают что сейчас нет необходимости в таких параметрах.
В тексте статьи проскакивают цифры близкие к 1Т.
dmtrmonakhov
16.11.2021 15:04+1Почему близкие, на пике трафик по кластеру был 15TB/s
Rutel_Nsk
16.11.2021 15:16Я предлагал в качестве интерфейса (шины) процессора использовать сеть основнную на плезиохронных каналах связи (6 каналов по 100Т). Получится трехмерный куб, часть процессоров в нем заменить на общую память (если интересно: habr.com/ru/post/577810 ). Скорость доступа получается больше чем у локальной DDR и смысла в дополнительных (PCI USB Ethernet) интерфейсах отсутствует.
PereslavlFoto
16.11.2021 14:53+2Скажите пожалуйста, кто из российских разработчиков в области суперкомпьютеров и кто из российских производителей в области суперкомпьютеров участвовал в вашей работе, кроме собственной команды R&D?
Будут ли фотографии ваших суперкомпьютеров доступны для неограниченного использования по свободной лицензии?
Спасибо.
order227
16.11.2021 15:40+3кроме собственной команды R&D
А зачем кто-то нужен в данном процессе, кроме собственной команды R&D?)
gus26
16.11.2021 16:26-18Мда уж. Когда кэш девать некуда, можно не экономить и покупать ТОПовое железо...
Konstantinus
16.11.2021 18:23+1Спасибо, интересно. Вопрос: в рейтинге топ-500 не указана ваша энергоэффективность. Вы не делали замеров?
dmtrmonakhov
17.11.2021 08:38+5Меряли, но почему-то забыли добавить данные, сейчас уже боюсь соврать по какой причине. Вообще на сайте https://yandex.ru/supercomputers есть данные по средней потребляемой мощности. На Червоненкис во время теста на пике был 1.01MW, Ляпунов в пике 530kW. В следующем июньском рейтинге добавим.
eigrad
16.11.2021 18:54+2Да, это вам не pytorch syntetic benchmark на паре Tyan 8x2080ti PCIe3 2x10Gbit гонять, ради таких штук в Яндекс вернуться можно :).
Когда с 16.04 то переедете и на что?..
dmtrmonakhov
17.11.2021 08:16+3В ближайших планах, на ubuntu 20.04. Кстати про то как "правильно" запускать pythorch в распределенном виде будет в следующем посте
eigrad
16.11.2021 19:02+1Например, оказалось, что большинство стандартных утилит для работы с HPC (High Performance Computing) поддерживают только IPv4. Яндекс, в свою очередь, уже много лет живёт в дата-центрах IPv6-only.
Пытался через openmpi году примерно в 2016м запустить ipycluster на нодах hahn, не осилил :).
serebryakovsergey
16.11.2021 22:58Очень круто! По ходу чтения появилось пару вопрсоов:
90 GB/s в all-reduce тестах удалось достичь при запуске теста на всех 137 машинах (т.е. используя 137 * 8 = 1,096 карт)?
Если это не является коммерческой тайной, то какие бенчмарки вы запускали что-бы оценить 4 vs 8 сетевых карт на узел? В частности, оценивали ли вы, например, влияние конфигурации с 4ми картами на узел на тренировку таких моделей, как GPT-3 (Megatron-LM), в которой есть все 3 типа паралелизма (tensor/pipeline/data) и которой нужно 16 узлов с 8 GPU каждой для одной реплики?
dmtrmonakhov
17.11.2021 08:29+3(1) 90GB/s был получен в момент когда у нас было всего 64хоста и сразу-же отдали в продакшен потому что время поджимало. Остальные подключили через пару недель . В этом и была наша ошибка. Если бы стали прогонять на всех машинах то скорее всего поймали-бы баг c adaptive-route-ами.
(2) Очень хороший вопрос, у нас чуть хитрее тест выглядел, так как у нас все хосты уже собраны с 4сетевыми карточками, поэтому мы делали обратный тест. Сравнивали результаты где на хосте используется только 4GPU, и 8 GPU, тоесть в первом случае у нас получалось соотношение GPU:NET 1:1. На linpack разница получалась ~3%. Коллеги из ML хотели сделать такой-же эксперимент на Megatron-LM, но результат я не знаю. Но раз не пришли ругаться значит значительной разницы не заметили.
dmtrmonakhov
17.11.2021 11:57Кстати, составители рейтинга ошиблись в графе Manufacturer, теперь поправили и теперь все правильно: YANDEX,NVIDIA: https://www.top500.org/system/180029/
walhi
17.11.2021 13:46+1Не сочтите за наглую рекламу, но раз уж речь пошла про суперкомпьютеры, то стоит упомянуть одно мероприятие. Национальный Суперкомпьютерный Форум, который скоро будет проходить уже в десятый раз в Институте программных систем им. А.К. Айламазяна РАН (Переславль-Залесский). Он посвящен различным аспектам суперкомпьютерной отрасли, в том числе вопросам машинного обучения. Неплохая площадка для общения со специалистами, налаживания контактов между компаниями. Подать доклад уже не выйдет, так как прошли сроки, а вот приехать послушать вполне возможно. Пандемия накладывает ряд ограничений на подобные мероприятия, так что мы работаем с возможностью участия онлайн (Zoom) и ведем трансляцию докладов на YouTube (уже не первый год, записи докладов можно посмотреть по ссылке https://www.youtube.com/channel/UC1yFLfcOBeqHRTeZgs3UCzA).
P.S. Пора бы мне написать небольшую статейку про то, как мы ведем трансляцию конференции. Думаю, местной аудитории будет интересно. Да и чего полезного может подскажут.
kshvakov
18.11.2021 10:18+1Через nvidia-smi сборка метрик и в правду очень не бесплатна, особенно на Теслах. Для этих целей лучше использовать NVML (биндинг на Go) и писать свой экспортер делая 1 раз Initialize на старте.
У автора биндинга есть готовый экспортер для Prometheus (можно в коде подглядеть как и что), но там, как минимум, не было метрик по NVENC/NVDEC.dmtrmonakhov
18.11.2021 10:26Да, именно в этом и была проблема, у нас уже есть центральный хостовый демон типа dcgm который управляет gpu через nvml и у него все эти метрики есть, но параллельно еще другие сервисы написали свой код который для простоты зовет nvidia-smi, раз в несколько секунд. Тоесть по факту они делали лишную работу, проще было у демона по unix-socket-у получить эту статистику. Я привел этот случай в качестве примера том как простой казалось бы баг может стоит 3-4%
AlexeyAB
20.11.2021 04:00Как видно из top500.org, не все кластеры используют Mellanox Infiniband, есть ещё некоторые стандартные или совсем кастомные интерконнекты: Tofu, Sunway, TH Express-2, Slingshot-10, Atos BXI V2, Aries interconnect, Intel Omni-Path, ...
Раз уж вы строите свои кластеры, то не пробовали пойти ещё глубже и реализовать собственный интерконнект или соединять сервера напрямую по PCI-Express 4.0 x 128 lanes через PLX PCIe-switch, который поддерживает virtual Ethernet NICs, NIC DMA and Tunneled Window Connection (TWC) http://www.alexeyab.com/2017/04/the-fastest-interconnect-for-hundreds.html
В принципе, даже в одну PCIe сеть можно объединить множество CPU и GPU без Ethernet/Infiniband, гораздо больше, чем 8.
Чтобы использовать
GPU-nVLink-GPU-CPU -> PCIe -> CPU-GPU-nVLink-GPU или
GPU-nVLink-GPU -> PCIe -> GPU-nVLink-GPU
вместо
GPU-nVLink-GPU-CPU -> PCIe -> Infiniband -> PCIe -> CPU-GPU-nVLink-GPU
order227
20.11.2021 10:17Вероятно будет слишком дорого, каждый свитч pcie gen 4 стоит баксов 400-500, а их в вашем решение надо мешок на каждый сервер, сеть выглядит дешевле и не надо изобретать велосипед очередной. Компьютер этот все таки коммерческий проект. Все перечисленные вами "нестандартные" проекты в основном велосипеды под узкий круг задач и связаны в основном с наукой/военкой/etc.
maksasila
23.11.2021 11:05Эта цепочка не правильная:
GPU-nVLink-GPU-CPU -> PCIe -> Infiniband -> PCIe -> CPU-GPU-nVLink-GPUИспользуется RDMA, это значит данные идут напрямую из GPU на Infiniband, а не через CPU:
GPU-nVLink-GPU -> PCIe -> Infiniband -> PCIe -> GPU-nVLink-GPU
AlexeyAB
23.11.2021 18:53Если не используется PCIe-switch, как было предложено, то GPU и Infiniband физически подключены не напрямую, а через CPU, поэтому не могут обойти CPU в принципе. В этом случае RDMA позволяет обойти RAM и ожидание свободных CPU-Cores, но всегда использует CPU-PCIe-Controller.
CPU состоит из (Cores, Cache L1/L2/L3, North Bridge (PCIe-controller, ...), ...).
-
Без RDMA и Без PLX-PCIe-switch, сигнал идет:
GPU->PCIe->CPU(PCIe-controller)->CPU(RAM/cache-L3)->CPU(Core)->CPU(PCIe-controller)->PCIe->Infiniband->PCIe->CPU(PCIe-controller)->CPU(RAM/cache-L3)->CPU(Core)->CPU(PCIe-controller)->PCIe->GPU
(CPU-cache-L3 снупит данные, которые идут из GPU в CPU-RAM)
-
С RDMA и Без PLX-PCIe-switch, сигнал идет:
GPU->PCIe->CPU(PCIe-controller)->PCIe->Infiniband->PCIe->CPU(PCIe-controller)->PCIe->GPU
-
С RDMA и С PLX-PCIe-switch, сигнал идет:
GPU->PCIe->PLX-PCIe-switch->PCIe->GPU
или GPU->PCIe->PLX-PCIe-switch->PCIe->PLX-PCIe-switch->PCIe->GPU
-
С RDMA и Без PLX-PCIe-switch и Без Infiniband:
GPU->PCIe->CPU(PCIe-controller)->PCIe->GPU
или GPU->PCIe->CPU(PCIe-controller)->PCIe->CPU(PCIe-controller)->PCIe->GPU->...
Можно и сотни CPU, GPU и FPGA подключить между собой без Infiniband/Ethernet/PCI-switch/..., расшаривая Mapped Memory Windows через NTB PCIe-Bars. Вот 4 CPU подключены между собой по PCIe без Infiniband/Ethernet/PCI-switch/.... Эти окна физической памяти, в том числе память GPU-RAM по GPUDirect3.0, можно мапить в другой CPU и затем мапить через PT/VMA в виртуальную user-space, которая видна другому GPU по GPUDirect1.0(UVA) http://www.alexeyab.com/2017/04/the-fastest-interconnect-for-hundreds.html
maksasila
23.11.2021 21:16Я могу ошибаться, но насколько я помню, North Bridge это часть чипсета, а не CPU. https://en.wikipedia.org/wiki/Northbridge_(computing)
А значит RDMA всё-таки не идёт череp CPU.
Плюс пару вопросов:
как подключать напрямую PCIe серверов, которые находятся в разных стойках?
Какая топология подключения будет, если всё подключать через PCIe?
AlexeyAB
23.11.2021 21:47+1Уже 10 лет как North Bridge интегрирован в CPU (Intel/AMD/...). По вашей же ссылке: Modern Intel Core processors have the northbridge integrated on the CPU die, where it is known as the uncore or system agent.
Два CPU соединяются между собой напрямую оптоволоконным PCIe-кабелем длинной 30 метров.
Можно Tree, например, CPU со 128 lanes PCIe4.0 = 256 GB/s = 2048 Gbit/s на CPU, две ветки вниз по 512 Gbit/s и одна вверх 1024 Gbit/s. Но CPU должен поддерживать NTB, иначе PCIe-switch-и нужны. Это может выглядеть или как обычная TCP/IP сеть IPoPCIe, или память всех CPU/GPU может выглядеть как обычные массив/массивы в user-space куда можно писать по raw-указателю: somearray[713] = 123. (Там есть пару нюансов с реальной битностью физической адресации CPU, и нюанс с QPI)
maksasila
23.11.2021 22:51Если топология tree и в каждой ветке только 2 ноды, выглядит не очень, особенно если нодам нужно гонять данный с самых дальних веток и с самого низа. Между прочим, Infiniband HDR делает 200 Gbit/s на один порт. Плюс топология fat tree.
-
czz
20.11.2021 16:45+1Очень интересно!
1) Я правильно понял, у вас из сервера выходит пачка кабелей c разъемами вродe slimsas 8i, подключенных с одной стороны прямо в материнскую плату сервера, с другой стороны в плату JBOG со свитчами?
2) Не видно, как устроено питание JBOG. Там есть блоки питания в корпусе или есть отдельно полки питания?
3) Подобные корпуса для JBOG существуют ли в фабричных вариантах, которые можно было бы купить?order227
23.11.2021 10:161) Всё так, pcie прокинуты по кабелями через slimline x8
3) весь дизайн кастомный, включая механику и электронику, так что купить не получится на внешнем рынке такое же решение
PereslavlFoto
23.11.2021 19:31Но ведь можно было использовать решение со внутреннего рынка, решение от российских производителей? Чем оно хуже?
czz
23.11.2021 22:09Так Яндекс — это же и есть российский производитель :)
PereslavlFoto
23.11.2021 23:02-1Ускорители иностранные. Интерконнект иностранный. А разработкой занимается Яндекс — то есть компания из Нидерландов. Как говорил Сегалович, «иностранные акционеры вследствие отсутствия правильного закона об акционерных компаниях в России боятся создавать тут юридическое лицо».
czz
23.11.2021 23:131) Нет смысла делить ускорители на иностранные и неиностранные, когда среди всех стран мира есть только одна, где их могут разрабатывать, и одна, где могут производить.
2) Какая разница, где у Яндекса юрлицо? Работают-то конкретные люди в России, а не юрлицо.PereslavlFoto
23.11.2021 23:141) Две страны. Россия и США.
order227
24.11.2021 01:221) Две страны. Россия и США.
А вы шутник :)) Откуда в России то GPU взялись, да ещё и конкурентоспособные с nVidia?
Вообще правильно даже не "одна страна умеет", а всего "одна компания", конкретно зелёные. AMD и Intel что-то пытаются, но пока как-то не очень.
PereslavlFoto
24.11.2021 01:28czz
24.11.2021 01:33Это уже технически устарело на много лет.
Разница в производительности с современным железом — в десятки раз, если не больше.
order227
24.11.2021 01:19Решения с внутреннего рынка? Это какие? Типовые Dell и прочие? Это дорого и требует кондиционеров в дата-центре. В дизайне Яндекса же фрикулинг и кастомизация под свои задачи - такого на рынке просто нет, особенно на внутреннем. Если бы было и стоило дешевле, чем сделать самим, то просто пошли бы купили. Большими компаниями управляют люди явно умеющие считать деньги :))
PereslavlFoto
24.11.2021 01:25Решения с внутреннего рынка — это решения, которые предлагают российские разработчики, в том числе институты Академии наук.
Возможно, на рынке нет фрикулинга, зато есть погружное охлаждение.czz
24.11.2021 01:36+1Это еще сложнее в обслуживании, чем кондиционер. Представьте, что у вас не аквариум, а целый бассейн этой техники.
И обслуживание самого оборудования затрудняет очень-очень сильно. Поэтому используется преимущественно для одноразовой техники, типа майнеров.PereslavlFoto
24.11.2021 01:38Ну, честно говоря, используется это преимущественно для военной техники.
В обслуживании несколько сложнее, зато намного дешевле и позволяет отводить гораздо больше тепла.order227
24.11.2021 11:42В обслуживании несколько сложнее, зато намного дешевле и позволяет отводить гораздо больше тепла
Не дешевле, даже близко. В любой системе где появляется жидкость стоимость сразу стоит умножать на 3, и это минимум.
Больше тепла отводить это конечно прекрасно, но зачем если решение проигрывает воздуху по экономике? Для начала начните разделять "пилить бабло и танки" и "частные коммерческие компании". Последние не готовы платить за иллюзорное преимущество х3 ценник, просто потому что проиграют конкуренцию тут же другим игрокам с рынка. Для вояк в принципе плевать какая цена, как и для гос сектора, им наоборот чем дороже, тем лучше - проще выдернуть лишний миллиард из контракта.
order227
24.11.2021 11:38в том числе институты Академии наук
То есть вы предлагаете закупаться у государственных насквозь коррумпированных структур, которые еще до коммерческого предложения начинают обсуждать размер отката?))) Удачи вам в построение бизнеса с таким подходом.
нет фрикулинга
Вы сами ответили на свой вопрос почему не закупаются решения с внутреннего рынка - их просто нет.
Вы хоть представляете насколько это дороже и сложнее в обслуживании, чем воздух? Я так понимаю Яндексу и прочим Фейсбукам хочется зарабатывать деньги на продаже сервисов, а не на откатах, поэтому соотношение "цена/результат" решающее и все сидят на воздухе.
aklimano
24.11.2021 10:14Статья греет душу приятными воспоминаниями о работе в суперкомпьютерном центре одного НИИ. Так давно не следил за топ500, а тут Mellanox, Infiniband - помню на ощупь эти приятные коннекторы, провода. Помню шум в старом ДЦ и насколько же тише в серверной с жидкостным охлаждением...
Если не секрет, какой используете планировщик, что-то свое? Я так понимаю, режим загрузки вашего кластера - все мощности под одну задачу, потом под другую? Думаю, это сильно отличается от режима в НИИ, где часто людям выделялось по 1-2 узла на время от нескольких часов до нескольких дней.
Кстати, не думали ещё в рейтинге топ-50 суперкомпьютеров СНГ отметиться? На первом месте там сейчас Сбер с 6.7 петафлопс на Линпак. У вас вроде бы теперь все призовые места - не припомню таких масштабных смещений раньше) Максимум когда кто-то 1 новый кластер собирал и вырывался вперёд на пару строчек:
dmtrmonakhov
29.11.2021 12:14+2Планировщик задач у нас свой называется YT. Он чем то похож на SLURM. По факту это дефолтный job-процессор для большинства задач в яндекс. Забавно что до появления GPU-задач его очень долго оптимизировали для повышения общей утилизации ресурсов (cpu,mem,disk) на обычных задачах (компиляция, map-reduce), а в случае GPU-задач это оказалось вредным потому что минимальный недостаток CPU приводил к просадке RDMA. Так что тут было много интерестного. Зато теперь YT умеет решать обе задачи хорошо. У нас средний размер задач 1-4хоста. Ребята сначала отлаживаются, а потом уже запускают на большое количество нод.
В Российский top-50 заявились. скоро должно обновится
daduskacpokus
Прочитал с упоением, вообще возбуждаюсь от такого рода занятий как сборка и настройка железа.
Спасибо!