Яндекс поделился практическим опытом, как они научились приоритизировать ML-трафик в InfiniBand‑сетях GPU‑кластеров, чтобы важные задачи не «проседали» по скорости из‑за соседних запусков.
Ключевые моменты:
InfiniBand использует централизованный Subnet Manager (OpenSM), который управляет адресацией, маршрутизацией и QoS‑политиками через связку Service Level (SL) и Virtual Lanes (VL).
QoS строится так: трафик разных типов «красят» в разные SL, которые маппятся в VL с разным приоритетом и весами; в тестовой схеме SL1 получает 80% полосы, SL0 — 20%.
В кластерах YATI несколько обучений разных пользователей делят одну InfiniBand‑фабрику, поэтому без QoS крупные и критичные обучения легко «топятся» параллельными задачами.
На FatTree‑кластерe с HDR они сначала не увидели эффекта, пока искусственно не создали переподписку (отключили часть spine‑коммутаторов), после чего трафик SL1 реально начал выдавливать SL0 при конкуренции.
В DragonFly+ всё сложнее: там маршрутизация использует разные VL для прямого пути и +1/+3 hop, чтобы избежать credit loop deadlock в lossless‑сети, поэтому SL→VL‑маппинг становится частью Control Plane, а доступное число «красок» фактически сокращается.
В итоге Яндекс превратил QoS в продуктовый механизм: планировщик обучения помечает крупные обучения (по порогу GPU на кластер, настраиваемому для каждого кластера) как приоритетные, агент на хосте перекрашивает их трафик в SL1, остальные идут в SL0 — даже если пользователь пытался проставить свои SL.
Дальше этот же подход планируют использовать для разведения обучения и мультихостового инференса, отдавая приоритет real‑time‑инференсу по сети.
QoS в InfiniBand — это не просто «очереди на порту», а тесная связка с топологией и routing engine (особенно в DragonFly+), иначе легко получить либо отсутствие эффекта, либо ризик deadlock’ов.
#yandex #infiniband #qos #gpu #ml #mlops #networking #dragonflyplus #cloud #infrastructure