Топология — это скелет сети: от неё зависят максимальная масштабируемость, предсказуемость задержек, устойчивость к отказам и возможность эволюции без полного переделывания всего ЦОДа. Ошибка на этом уровне обычно обнаруживается уже тогда, когда кластер вырос и перестроить его почти нереально.
Ошибка 1. Копировать классический дизайн ЦОДа
В традиционных ЦОДах преобладает north‑south‑трафик (клиент‑сервер, фронтенд‑бэкенд, запрос‑ответ), и трехуровневые схемы Core–Aggregation–Access работают вполне предсказуемо. В GPU‑кластере все наоборот: доминирует east‑west‑трафик, причем не просто произвольный, а плотный, синхронный и часто "все со всеми" передающий огромные массивы данных.
Классический дизайн здесь приводит к нескольким проблемам:
- Длинные и неоднородные пути между узлами (разное количество транзитных узлов, непредсказуемые задержки).
- Сложность масштабирования: любое добавление стоек нагружает промежуточные уровни, которые изначально не планировались под такие объмы.
Так сеть, «поднятая по учебнику», внезапно оказывается непригодной для стабильной работы распределённого обучения.
Лучше ориентироваться на fabric‑подход — различные варианты Clos/fat‑tree, иногда Dragonfly и другие многокорневые топологии, где закладывается практически равная полоса и предсказуемое число переходов между любыми двумя хостами.
Ошибка 2. Не учитывать характер операций обучения ИИ
В распределённом обучении каждую эпоху модель выполняет коллективные операции AllReduce, AllGather, Broadcast и Scatter, и они чувствительны к тому, как именно трафик «ложится» на топологию. Если при проектировании считались только «средние» нагрузки или синтетический трафик типа iperf, сеть может выглядеть здоровой, пока не появится реальная нагрузка.
Типичные симптомы:
- Эпохи обучения занимают существенно больше времени, чем показывали расчёты.
- Отдельные ноды постоянно «догоняют» остальных, а логика синхронизации упирается в медленные коллективные операции.
Мы рекомендуем моделировать именно шаблонные коллективные операции хотя бы на уровне «каждый со всеми» или «подгруппы внутри стойки/фабрики». Под такие шаблоны проще выбирать между чистым Clos, иерархическими схемами или, например, гибридом с локальной «фабрикой» внутри стойки.
Ошибка 3. Строить пилот без учёта будущего масштаба
Маленький кластер на 8–16 GPU можно запустить практически на любой разумной схеме: пара ToR‑ов, несколько uplink‑ов и аккуратные настройки уже дают впечатляющую производительность. Проблема в том, что успешный пилот часто становится «эталоном» и его архитектуру просто масштабируют вширь, не проверяя, как она поведёт себя на сотнях GPU.
На больших масштабах всплывают:
- Неожиданные узкие места на spine‑уровне, которого в пилоте вообще не было.
- Резкий рост переподписки внутри фабрики.
- Нечёткая адресация и схемы размещения, которые невозможно красиво расширить.
Даже для пилота лучше выбирать топологию, у которой заранее понятен путь масштабирования: какие уровни будут добавляться, как будет расти количество spine коммутаторов, какие стойки станут «единицей масштабирования». Пилот можно делать маленьким, но схема должна быть «фрагментом будущей фабрики», а не отдельным экспериментом.
Ошибка 4. Неправильный выбор переподписки
Бывает два полюса. С одной стороны, пытаются сделать идеальную фабрику без переподписки (1:1), не считаясь с ценой, и в итоге получают очень дорогую сеть с небольшим выигрышем по сравнению с разумно спроектированной схемой. С другой — переносят старые привычки (1:4, 1:8) из обычных серверных сетей, где запросы могут пережить очереди и очередные миллисекунды.
В GPU‑кластерe переподписка бьет по:
- Времени синхронизации градиентов и параметров.
- Возможности одновременно запускать несколько тяжелых задач без взаимного «удушения» по сети.
Мы советуем:
- Считать реальное отношение вычислений к коммуникации для типичного набора моделей.
- Делать нагрузочные тесты на пилотной фабрике (пусть и небольшой), проверяя влияние переподписки на время эпохи, а не только на среднюю загрузку линков.
Ошибка 5. Смотреть только на полосу, а не на зедержки
Многие даташиты коммутаторов больше описывают пропускную способность: 10G, 100G, 400G и т.д. Но для синхронного обучения критичен не только объем данных в секунду, а то, насколько равномерно и быстро эти данные доходят до всех участников.
Даже небольшое увеличение задержек (latency) на части каналов приводит к тому, что:
- Все узлы ждут самых медленных участников, так как общая скорость выполнения задачи определяется не средним, а самым медленным потоком данных.
- GPU простаивают, а метрики «средняя загрузка» скрывают реальное падение эффективности.
Ошибка 6. Совмещать GPU‑фабрику со всем остальным трафиком
Идея «пусть всё ходит по одной большой фабрике, там же много пропускной способности» выглядит экономно на бумаге. На практике фоновый трафик (backup, репликации, тяжелая аналитика, массивный импорт данных) легко отбирает критичные ресурсы у обучающих задач, особенно на участках, где топология уже предрасположена к узким местам.
Характерные эффекты:
- Обучение замедляется или становится нестабильным «по ночам», когда запускаются бэкапы.
- Появляется лавинообразный рост задержек на каналах, важных для GPU‑кластера.
Необходимо разводить критичный трафик по выделенной фабрике либо по чётким VRF/tenant‑ам с приоритизацией и ограничением приложений, не относящихся к обучению. А так же четко определять, какой трафик имеет право конкурировать с общими операциями, а какой должен быть ограничен по полосе.
Ошибка 7. Некритичное отношение к выбору технологии (Ethernet vs IB итд)
Решение «Ethernet или InfiniBand» иногда принимается на уровне общего ощущения, маркетинга или личного опыта отдельных инженеров. При этом не анализируется, какие именно возможности фабрики будут реально использоваться и как топология повлияет на дальнейшую эволюцию.
Риски:
- Сложный для эксплуатации стек (RDMA, специфичный контроль перегрузок), который команда не успевает освоить.
- Отсутствие нужных средств аналитики, из‑за чего топология кажется «чёрным ящиком» при деградациях в сети.
Мы рекомендуем выбирать технологию с учётом того, как конкретная топология будет жить 3–5 лет и переживать смену поколений GPU.
Ошибка 8. Проектировать логическую топологию в отрыве от физики
Даже идеально спроектированный Clos на диаграмме может превратиться в «паутину» при реальном размещении в зале. Если стойки с GPU рассыпаны по разным зонам, между ними длинные трассы, ограниченные лотки, а кроссы перегружены, топология теряет свою простоту и предсказуемость.
Последствия:
- Дополнительные задержки из‑за длинных линий и неоднородности среды.
- Рост вероятности ошибок при обслуживании и перекоммутации кабелей.
Лучше проектировать логическую топологию параллельно с планом зала: зоны, «острова» GPU‑стоек, точки агрегации, магистральные лотки. Решения по размещению должны помогать топологии, а не бороться с ней.
Ошибка 9. Не моделировать отказоустойчивость на уровне топологии
Фраза «у нас всё задублировано» часто означает только наличие резервных линков и LAG’ов, но не гарантирует, что топология сохранит свои свойства при отказе. В реальности отключение одного spine‑коммутатора или одного сегмента кабельной системы может резко изменить схему сети, распределение нагрузок и задержки.
Типичные проблемы:
- В нормальном режиме работы всё отлично, а при отказе одного узла время эпохи вырастает на 20–50%.
- Из‑за состояния после отказа начинают срабатывать защитные механизмы сети, которые ещё сильнее ухудшают ситуацию.
Рекомендация:
- На этапе дизайна моделировать отказ отдельных узлов и линков, проверяя, как изменятся метрики для реальных задач ИИ, а не только для «голого» трафика.
- Прописывать допустимую деградацию (например, не более х % роста времени эпохи при отказе любого одного spine коммутатора) и проверять её тестами.
Ошибка 10. Сетевики и ML‑команда живут в разных мирах
Иногда топология рождается в сетевом отделе в почти полном отрыве от того, какие задачи планирует запускать ML‑команда. В лучшем случае обсуждаются пропускная способность и общее количество хостов, но не типы моделей, целевые время обучения и чувствительность к задержкам.
Это приводит к тому, что:
- Сеть оптимизирована под абстрактный HPC или микросервисные нагрузки, но не под конкретный микс обучения, дообучения (fine‑tuning ) и инференса (inference).
- При появлении новых сценариев (например, смешанное обучение и онлайновый инференс в одном кластере) топология неожиданно перестаёт удовлетворять требованиям.
Как делать лучше:
- Делать совместные сессии планирования: сетевики, команда ML, платформенная команда, разработчики моделей.
- Описывать кластеры не только в терминах портов и стоек, но и в терминах «профилей задач»: какие модели, объемы данных, какие SLA по времени обучения и сколько параллельных задач требуется поддерживать.
Наши инженеры помогут вам пройти все этапы выбора сетевого оборудования - от аудита текущей инфраструктуры и формирования технических требований до подбора конкретных моделей коммутаторов и маршрутизаторов, их тестирования и поэтапного внедрения.
Если у Вас остались вопросы, свяжитесь с нами удобным способом:- по телефону +7 (495) 127-01-64
- по электронной почте info@vectortechnologies.ru
- заполнением формы на сайте